¿Programación funcional en aumento?

  

¿En qué situaciones debería considerar un lenguaje de programación funcional más adecuado para realizar una tarea determinada? Además del recientemente popular problema multinúcleo de la programación en paralelo.

Cualquier cosa que implique crear una secuencia de elementos de datos derivados mediante una serie de pasos de transformación.

Esencialmente, el "problema de la hoja de cálculo". Tiene algunos datos iniciales y un conjunto de cálculos fila por fila para aplicar a esos datos.

Nuestras aplicaciones de producción hacen una serie de resúmenes estadísticos de datos; Todo esto se aborda mejor funcionalmente.

Una cosa común que hacemos es una combinación de combinaciones entre tres conjuntos de datos monstruosos. Similar a una unión de SQL, pero no tan generalizada. Esto es seguido por una serie de cálculos de datos derivados. Todo esto es solo transformaciones funcionales.

La aplicación está escrita en Python, pero está escrita en un estilo funcional utilizando funciones de generador y tuplas con nombres inmutables. Es una composición de funciones de nivel inferior.

Aquí hay un ejemplo concreto de una composición funcional.

for line in ( l.split(":") for l in ( l.strip() for l in someFile ) ):
    print line[0], line[3]

Esta es una forma en que la programación funcional influye en lenguajes como Python.

A veces, este tipo de cosas se escribe como:

cleaned = ( l.strip() for l in someFile )
split = ( l.split(":") for l in cleaned )
for line in split:
     print line[0], line[3]

  

Si decidiera cambiar a un lenguaje de programación funcional, ¿cuáles consideras son los mayores escollos que enfrentaré? (Además del cambio de paradigma y la dificultad de evaluar el rendimiento debido a la evaluación perezosa).

Los objetos inmutables son el obstáculo más difícil.

A menudo, terminará calculando valores que crean nuevos objetos en lugar de actualizar objetos existentes. La idea de que es un atributo mutable de un objeto es un hábito mental difícil de romper.

Una propiedad derivada o función de método es un mejor enfoque. Los objetos con estado son un hábito difícil de romper.

  

Con tantos lenguajes de programación funcionales, ¿cómo elegiría el que mejor se adapta a sus necesidades?

No importa al principio. Elige cualquier idioma para aprender. Una vez que sepas algo, estás en una posición, considera elegir otro para que se adapte mejor a tus necesidades.

He leído en Haskell solo para entender las cosas que Python carece.

"Funcional" es un conjunto de características diferentes, cada una de las cuales es útil de forma independiente, y me parece más útil mirarlas individualmente.

Inmutabilidad

Ahora que estoy familiarizado con él, cada vez que puedo obtener un resultado inmutable, siempre trato de hacerlo, incluso en un programa orientado a objetos. Es más fácil razonar sobre el programa si tiene datos de tipo valor. Por lo general, necesita mutabilidad para cosas como las GUI y los cuellos de botella de rendimiento. Mis entidades (usando NHibernate) también son mutables (lo cual tiene sentido porque son modelos de datos almacenados en una base de datos).

Funciones como tipos de primera clase

Lo que sea que quieras llamar, pasar a los delegados, las acciones o las funciones, es una manera realmente útil de resolver toda una clase de problemas del mundo real, como el "agujero en el patrón del medio". También descubrí que pasar un delegado, una acción o una función a un objeto es más limpio que hacer que esa clase declare un evento y enganche ese evento (suponiendo que normalmente solo hay un "oyente"). Cuando sabes que hay un oyente, entonces la acción de devolución de llamada se puede pasar como un parámetro de constructor (y se almacena en un miembro inmutable)

Ser capaz de componer funciones (por ejemplo, convertir Action<T> en solo un Action también es bastante útil en algunos escenarios.

También debemos tener en cuenta la sintaxis de Lambda aquí, porque solo obtienes la sintaxis de Lambda cuando promueves funciones a tipos de primera clase. La sintaxis de Lambda puede ser muy expresiva y concisa.

Mónadas

Es cierto que este es mi punto débil, pero mi entendimiento es que los flujos de trabajo computacionales en F #, como el flujo de trabajo async , son una mónada. Este es un constructo sutil pero muy poderoso. Es tan poderoso como la palabra clave yield utilizada para crear las clases IEnumerable en C #. Esencialmente, está construyendo una máquina de estado para usted bajo las sábanas, pero su lógica parece lineal.

Evaluación perezosa & Recursion

Los puse juntos porque, si bien siempre están agrupados como características de la programación funcional, se han abierto camino tan rápidamente en lenguajes imperativos que ya no es posible llamarlos funcionales.

Expresiones S

Supongo que no estoy seguro de dónde colocar esto, pero la capacidad de tratar el código no compilado como un objeto (y de inspeccionarlo / modificarlo), como Lisp S-Expressions o LINQ Expressions, es, en De alguna manera, la herramienta más poderosa de la programación funcional. La mayoría de las nuevas interfaces "fluidas" de .NET y las DSL utilizan una combinación de sintaxis lambda y LINQ Expressions para crear algunas API muy concisas. Sin mencionar Linq2Sql / Linq2Nhibernate donde su código C # se ejecuta "mágicamente" como SQL en lugar de como código C #.

Esa fue la respuesta larga a la primera parte de su pregunta ... ahora ...

  

Si decidiera cambiar a un lenguaje de programación funcional, ¿cuáles consideras son los mayores escollos que enfrentaré? (Además del cambio de paradigma y la dificultad de evaluar el rendimiento debido a la evaluación perezosa).

El mayor escollo que enfrenté fue tratar de encontrar la línea entre usar soluciones funcionales y soluciones imperativas. Sin embargo, después de probar ambos enfoques varias veces, comienza a tener una idea de lo que funcionará mejor.

  

Con tantos lenguajes de programación funcionales, ¿cómo elegiría el que mejor se adapta a sus necesidades?

Si está familiarizado con .NET, le recomiendo F #. Por otro lado, si está más familiarizado con la JVM, siempre hay Clojure . Si eres más académico que práctico, entonces iría con Common Lisp o Scheme. Si ya conoces Python, creo que hay muchas construcciones funcionales disponibles allí.

  

Y este ha sido el caso durante bastante   algun tiempo. Programacion funcional   simplemente no se ha vuelto tan popular como   otros modelos (es decir, orientados a objetos   programación).

Esto es cierto si cuenta los programas desarrollados por programadores profesionales (o al menos las personas se ven a sí mismas como tales). Si extiende su red más amplia para incluir programas desarrollados por personas que no se consideran a sí mismas, la FP (o al menos la programación en un estilo funcional) es bastante cercana a la OO (Excel, Mathematica, Matlab, R ... incluso "moderno" JavaScript ).

  

¿En qué escenarios debo considerar un   lenguajes de programación funcionales   ¿Más adecuado para hacer una tarea determinada?   Además del tan recientemente popular   problema multinúcleo de paralelo   programación.

Mi opinión personal es que el multinúcleo no es la característica principal de FP (al menos hasta que los compiladores de Haskell, Scala, Clojure y F # resuelvan el problema de la localidad de caché). La característica asesina es map , filter , fold y amigos que permiten una expresión más concisa de un gran grupo de algoritmos. Esto se compone de lenguajes de PF que tienen una sintaxis más concisa que la mayoría de las contrapartes OO populares.

Además, el hecho de que la FP esté más cerca del modelo relacional reduce la falta de coincidencia de impedancia con RDBMS ... lo cual es, de nuevo al menos para los no programadores, muy bueno.

También cuando es particularmente difícil cumplir con los requisitos de "corrección", en una forma que es difícil de probar (común en la computación científica / análisis de grandes datos donde el objetivo es obtener resultados desconocidos previamente y, como tal, resultados no especificables) FP puede ofrecer ventajas.

  

Si decidiera cambiar a un funcional   lenguaje de programación que haces   Considerar son los mayores escollos que   Me voy a enfrentar?

• falta de soporte de herramientas (F # y algunos Lisps son la excepción, Scala está en camino)
• más difícil de exprimir el último bit de rendimiento de su hardware
• las comunidades a menudo se centran en problemas diferentes a los que enfrentan un gran grupo de proyectos de desarrollo de software comercial
• muy pocos desarrolladores con experiencia en el uso de PF en un entorno industrial y si puede encontrarlos, probablemente tenga que competir con el salario y los beneficios que la industria financiera puede ofrecer
• el estilo funcional de programación tiende a ser más difícil de depurar; es decir, la observación entre los resultados en una larga cadena de funciones compuestas generalmente no es posible en la mayoría (¿todos?) los depuradores

  

Con tanta programación funcional   idiomas por ahí, ¿cómo lo harías   Elige el que mejor se adapte a tu   necesidades?

• ¿Cuántos de sus problemas se pueden resolver al salir de las bibliotecas / marcos en qué plataforma (por ejemplo, JVM o .Net) cuántos son completamente nuevos? ¿Existen construcciones de lenguaje capaces de expresar estos problemas directamente?

• ¿Cuánto control de bajo nivel necesita sobre el rendimiento de espacio y tiempo de su aplicación?

• ¿Qué tan estrictos son sus requisitos de "corrección"?

• ¿Puede permitirse el lujo de volver a capacitar a los desarrolladores y / o competir con los beneficios que ofrecen algunos nichos altamente rentables en el desarrollo de software?

  

Si decidiera cambiar a un lenguaje de programación funcional, ¿cuáles consideras son los mayores escollos que enfrentaré? (Además del cambio de paradigma y la dificultad de evaluar el rendimiento debido a la evaluación perezosa).

Suponiendo que eres un desarrollador de C ++ / C # / Java en la industria ...

Esté preparado para los compañeros gruñones que no quieren aprender nada. Prepárese para los jefes de pelo puntiagudo que imponen malas elecciones de lenguaje "porque fueron programadores una vez". Prepárese para académicos en los foros que lo patrocinan sobre los monoides. Prepárate para interminables guerras de lenguaje porque Scala ni siquiera tiene eliminación de llamadas de cola y Clojure realmente requiere pedales para todos los soportes y no me hagas comenzar con Erlang.

Si eres un programador web, el mayor escollo probablemente será tu cabello.

  

Con tantos lenguajes de programación funcionales, ¿cómo elegiría el que mejor se adapta a sus necesidades?

Empezaría con la plataforma:

• OCaml es excelente en Linux y horrible en Windows.
• F # es excelente en Windows y horrible en Linux.
• Scala y Clojure son excelentes en la JVM.

Para una perspectiva (ciertamente parcial) sobre esta pregunta, puede consultar el blog de Bob Harper, Tipo existencial . Carnegie Mellon ha rediseñado recientemente su currículo de CS para enseñar primero la programación funcional, y otros paradigmas se enseñan solo una vez que se ha establecido una base sólida en la programación funcional, y Harper está dando un golpe por golpe mientras se implementa el nuevo currículo en la práctica. .

Harper es uno de los principales desarrolladores del lenguaje de programación Standard ML, por lo que es justo decir que su propia opinión sobre el tema puede adivinarse con anticipación, y ciertamente no se escapa de las declaraciones polémicas al defender esta posición. pero él hace bien su caso.

  

¿En qué situaciones debería considerar un lenguaje de programación funcional más adecuado para realizar una tarea determinada? Además del recientemente popular problema multinúcleo de la programación en paralelo.

No hay una fórmula mágica que le indique cuándo usar la programación funcional. No es que la programación orientada a objetos se adapte mejor a nuestras situaciones de programación actuales. Es solo otra forma de estructurar los programas en términos de otro conjunto de abstracciones.

  

Si decidiera cambiar a un lenguaje de programación funcional, ¿cuáles consideras son los mayores escollos que enfrentaré? (Además del cambio de paradigma y la dificultad de evaluar el rendimiento debido a la evaluación perezosa).

La programación funcional no tiene nada que ver con la pereza. ML y OCaml son lenguajes funcionales y estrictos. El mayor obstáculo que enfrentará es estructurar las cosas en términos de valores inmutables y envolver su cabeza en torno a cualquier abstracción que se use en el sistema de tipos para los efectos secundarios. Los lenguajes funcionales son más adecuados para la optimización porque hacen que los efectos secundarios sean muy explícitos en el sistema de tipos. Haskell usa mónadas pero hay otros enfoques para usar efectos en lenguajes puramente funcionales. Clean tiene tipos de singularidad y algunos otros lenguajes en desarrollo tienen otras cosas.

  

Con tantos lenguajes de programación funcionales, ¿cómo elegiría el que mejor se adapta a sus necesidades?

Entre los lenguajes de programación que conozco, diría que solo a Haskell y Clean se les puede llamar lenguajes funcionales. Todos los demás permiten efectos secundarios sin hacer que esos efectos sean explícitos en el sistema de tipos. Entonces, si vas a dedicar tiempo a aprender programación funcional, entonces Haskell es probablemente el único que se adapta a la factura. Todos los demás que conozco, Erlang, Scala, Clojure, etc. simplemente proporcionan abstracciones funcionales sobre un lenguaje imperativo. Así que si quieres enfocar el paradigma funcional en bits, te recomendaría Scala o Erlang y si quieres enfrentarte a todo de una vez y, posiblemente, rendirte a la frustración, deberías ir con Haskell.

Yo atribuiría el aumento de interés actual en los lenguajes funcionales al hecho de que son ideales para la computación paralela. Por ejemplo, toda la idea de map-reduce se basa en un paradigma funcional. Y no hay duda de que la computación paralela aumentará, ya que está claro que la ampliación de escala en la actualidad es mucho más sencilla y económica que la ampliación. Incluso en el mercado de consumo, las CPU obtienen más núcleos, no más GHz.

EDITAR: ya que no es obvio para todos.

En la programación funcional pura, una función toma entrada, produce salida y no tiene efectos secundarios. Al no tener ningún efecto secundario, significa que no tiene un estado compartido, por lo que no necesita mecanismos de sincronización, que de lo contrario serían necesarios mientras se ejecutan de forma simultánea. La sincronización es la parte más difícil de cualquier software concurrente / paralelo, por lo tanto, hacerlo puramente funcional, básicamente no tiene que lidiar con la parte más difícil en absoluto.

En cuanto a map-reduce, incluso el nombre proviene de la programación funcional (tanto el mapeo como la reducción son operaciones típicas en el paradigma funcional). Ambos pasos de map-reduce son funciones que se ejecutan en paralelo, toman entrada, producen salida y no tienen efectos secundarios. Así que esta es exactamente la idea de la programación funcional pura.

Algunos ejemplos de FP utilizados para el paralelismo:

• CouchDB - construir sobre Erlang
• chat de Facebook: construir sobre Erlang
• Twitter: gran parte de compilación en Scala