Programación funcional en alza?

42

Últimamente he notado que los lenguajes de programación funcionales están ganando popularidad . Recientemente vi cómo el Índice Tiobe muestra un aumento en su popularidad en comparación con el año pasado, aunque la mayoría de ellos ni siquiera llegan a los 50 idiomas más populares según este índice.

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

Sin embargo, he visto un interés renacido en el poder de la programación funcional, y ahora que los multinúcleos son cada vez más populares, los desarrolladores han comenzado a mostrar interés en otros modelos de concurrencia ya explorados en el pasado por lenguajes como Haskell y Erlang.

Veo con gran interés el hecho de que, a pesar de su falta de aceptación significativa por parte de la comunidad, siguen surgiendo más y más idiomas de este tipo. Clojure (2007), Scala (2003), F # (2002) son solo tres ejemplos de la última década.

Yo mismo he invertido algo de tiempo aprendiendo Haskell y Scala. Y encuentro un gran potencial en el paradigma que para mí era nuevo a pesar de estar ahí por tanto tiempo.

Y, por supuesto, mi mayor pregunta es si alguno de estos se volverá lo suficientemente popular como para considerar poner algún esfuerzo en ellos, pero esta es una pregunta que ni siquiera Mandrake podría responder, a pesar de todo el alboroto que la gente está haciendo sobre ellos.

Lo que sí quiero preguntar es:

  • ¿En qué escenarios debería considerar un lenguaje de programación funcional más adecuado para realizar una tarea determinada? Además del problema multinúcleo tan popular de la programación paralela.
  • Si decidiera cambiar a un lenguaje de programación funcional, ¿cuál consideraría que son los mayores escollos que enfrentaría? (Además del cambio de paradigma y la dificultad de evaluar el rendimiento debido a la evaluación perezosa).
  • Con tantos lenguajes de programación funcionales, ¿cómo elegiría el que mejor se adapte a sus necesidades?

Cualquier recomendación para futuras investigaciones será más que bienvenida.

He buscado opiniones en la web, y parece que toda esta popularidad renovada proviene de la idea de que ahora estamos a punto de llegar al muro de la Ley de Moore y que vendrán lenguajes de programación funcionales y nos salvarán heroicamente. Pero si este es el caso, diría que hay más probabilidades de que los lenguajes populares existentes se adapten al paradigma.

Algunos de ustedes, con más experiencia trabajando todos los días con estos idiomas tal vez, pueden ofrecer más información sobre el tema. Todas sus opiniones serán mejor apreciadas y consideradas cuidadosamente.

¡Gracias por adelantado!

programming-languages functional-programming edalorzo
fuente
44
Es Erlang, no Earlang (hubiera editado su publicación, pero el Sistema no permite ediciones de 1 letra).
quant_dev
66
Vale la pena decir que no hay una línea dura entre los lenguajes funcionales e imperativos. Los lenguajes familiares de ML no están libres de efectos secundarios y admiten declaraciones y estructuras imperativas y variables mutables. Algunos lenguajes imperativos, Python y Javascript, tienen características importantes extraídas de la programación funcional. Personalmente, espero ver ideas más funcionales en el uso convencional, especialmente la coincidencia de patrones.
Steve314
1
Tener algunas características comunes a los lenguajes funcionales no necesariamente hace que un lenguaje sea "funcional". La programación funcional se trata tanto de una forma de pensar y diseñar programas como de características específicas del lenguaje.
mipadi
2
@mipadi, y por lo tanto, puede aplicar la filosofía funcional en cualquier idioma, en la medida en que lo permitan las herramientas disponibles. Puede escribir código de estilo funcional en Python (dentro de los límites), y hasta ese punto Python es un lenguaje funcional. Y puede escribir código de estilo imperativo en ML, y hasta ese punto ML es un lenguaje imperativo. Esto no es lo mismo que "los malos programadores pueden escribir Fortran en cualquier idioma", aunque obviamente es una trampa fácil de caer si malinterpretas mi punto.
Steve314
1
@mipadi, pero si el lenguaje imperativo tuviera todas las construcciones funcionales normales, podría hacer cualquier cosa con él en un lenguaje funcional; la brecha se cerraría y la pregunta sería "¿cuál es la mejor manera de hacer esto" en lugar de "¿Cuál es la forma funcional / imperativa". La familia ML ya ha cerrado esa brecha, realmente, pero debido a que se llama funcional, pensamos en su estilo como estilo funcional en lugar de simplemente un buen estilo.
Steve314

Respuestas:

24

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

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

Básicamente, 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 realizan 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 SQL, pero no tan generalizada. Esto es seguido por una serie de cálculos de datos derivados. Todo esto son solo transformaciones funcionales.

La aplicación está escrita en Python, pero está escrita en un estilo funcional usando funciones generadoras y tuplas inmutables con nombre. 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 considera que 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 adapte a sus necesidades?

No importa al principio. Elige cualquier idioma para aprender. Una vez que sepa algo, puede elegir otro para que se ajuste mejor a sus necesidades.

He leído sobre Haskell solo para entender las cosas que le faltan a Python.

S.Lott
fuente
55
@edalorzo: Python no está tipeado débilmente. Está muy, muy fuertemente escrito. No hay operador de transmisión, por lo que está más fuertemente tipado que Java o C ++.
S.Lott
55
@ S.Lott: ¿la comprobación de tipos estáticos no ayuda con las herramientas de refactorización IDE y las cosas de tipo intellisense? Si tiene una compilación en segundo plano y está comprobando estáticamente los tipos, ¿no significa eso que puede automatizar más en sus herramientas? Estoy de acuerdo en que si tiene una cobertura de código del 100% en sus pruebas, lo detectará. Sin embargo, debe darse cuenta de que probablemente menos del 50% del código de producción en la empresa realmente tiene cobertura de prueba unitaria, ¿verdad? :) Hay un mundo real en el que tenemos que vivir.
Scott Whitlock
8
@ S.Lott "La verificación de tipo estático no es tan útil. No importa mucho si hay una verificación estática por parte de un compilador o una verificación en tiempo de ejecución. Todavía se escribe la misma cantidad de código y la misma cantidad de pruebas unitarias. " Err, no. El objetivo de la verificación de tipo estático es que detecta errores, por lo tanto, reduce enormemente la cantidad de pruebas requeridas.
Jon Harrop
3
@ S.Lott "Python no está tipeado débilmente. Está muy, muy fuertemente tipado". Python convierte implícitamente entre tipos numéricos, que se está escribiendo débilmente.
Jon Harrop
3
@ Steve314 "Después de todo, la verificación de tipo estático detecta algunos errores que se ajustan a algunas reglas básicas. Las pruebas unitarias, en principio, pueden detectar todos esos errores y muchos más". No. La comprobación estática demuestra la corrección de un aspecto de un programa. Las pruebas unitarias buscan refutar la corrección pero no prueban la corrección de nada. Las pruebas unitarias no sustituyen la verificación de tipo estático ni ningún otro tipo de prueba.
Jon Harrop
23

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

Inmutabilidad

Ahora que estoy familiarizado con él, cada vez que puedo evitar devolver 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 de valor. Por lo general, necesita mutabilidad para cosas como GUI y cuellos de botella de rendimiento. Mis entidades (que usan NHibernate) también son mutables (lo cual tiene sentido porque están modelando datos almacenados en una base de datos).

Funciones como tipos de primera clase

Como quiera llamarlo, pasar delegados, acciones o funciones, es una forma realmente útil de resolver una clase completa de problemas del mundo real, como el "agujero en el patrón intermedio". También descubrí que pasar un delegado, acción o función a un objeto es más limpio que hacer que esa clase declare un evento y enganche ese evento (suponiendo que normalmente haya un solo "oyente"). Cuando sepa que hay un oyente, la acción de devolución de llamada puede pasarse como un parámetro de constructor (¡y almacenarse en un miembro inmutable!)

Ser capaz de componer funciones (por ejemplo, convertirse Action<T>en solo una Actiontambié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 promocionas 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 entiendo que los flujos de trabajo computacionales en F #, como el asyncflujo de trabajo, son una mónada. Esta es una construcción sutil pero muy poderosa. Es tan poderoso como la yieldpalabra clave utilizada para crear IEnumerableclases en C #. Esencialmente está construyendo una máquina de estado para ti bajo las sábanas, pero tu lógica parece lineal.

Evaluación perezosa y recursión

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 a lenguajes imperativos que ya es difícil llamarlos funcionales.

Expresiones S

Creo que no estoy seguro de dónde poner esto, pero la capacidad de tratar el código no compilado como un objeto (e inspeccionarlo / modificarlo), como Lisp S-Expressions o LINQ Expressions, es, de alguna manera, La herramienta más poderosa de programación funcional. La mayoría de las nuevas interfaces "fluidas" de .NET y DSL utilizan una combinación de sintaxis lambda y expresiones LINQ 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 considera que 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 obstáculo que enfrenté fue tratar de encontrar la línea entre el uso de soluciones funcionales y las soluciones imperativas. Sin embargo, después de probar ambos enfoques varias veces, comienza a tener una idea de cuál funcionará mejor.

Con tantos lenguajes de programación funcionales, ¿cómo elegiría el que mejor se adapte 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 ya disponibles allí.

Scott Whitlock
fuente
@ Scott Gracias por tu explicación detallada. Supongo que lo que usted describe como el mayor obstáculo se eliminaría de la ecuación utilizando un lenguaje de programación funcional puro como Haskell. Es por eso que comencé con él, porque he sido un programador imperativo toda mi vida, y no quiero protagonizar un lenguaje de programación impuro y arriesgarme a no aprender de la buena manera. Si no le molesta que haga otra pregunta: dos cosas que me preocupan son las herramientas y las bibliotecas. ¿Qué tan buena es la integración de F # con otras herramientas y bibliotecas .Net?
edalorzo
No entiendo por qué agregas código en tiempo de ejecución y generación e inspección de código de tiempo de ejecución con programación funcional. Los dos no tienen relación entre sí. Las capacidades de metaprogramación que usted describe se pueden agregar a casi cualquier lenguaje, funcional o no. Creo que lisp comenzó el código como tendencia de datos, pero ahora está disponible en ruby ​​y otros lenguajes no funcionales.
davidk01
1
La integración de @edalorzo - F # con .NET es muy buena, con solo una pequeña excepción: ningún diseñador de GUI. Puede solucionarlo diseñando su GUI en un ensamblaje de C # y haciendo referencia a ella desde F #, o generando la GUI dentro de F # solo en código (no con un diseñador).
Scott Whitlock
@ davidk01: buena pregunta sobre metaprogramación. Acabo de encontrar que la sintaxis lambda y la metaprogramación se componen entre sí, pero tienes razón, podrían separarse. Parece que es más probable que obtengas meta-programación con un lenguaje funcional.
Scott Whitlock
1
@Scott: Creo que en muchos sentidos es más fácil; por ejemplo, cuando no tiene que preocuparse por los efectos secundarios, puede modificar una sección de código sobre la marcha con mucha más confianza; limita lo que tiene que cambiar.
Michael K
15

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

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

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

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

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

Además, cuando tiene requisitos de "corrección" particularmente difíciles de satisfacer, en una forma que es difícil de probar (común en computación científica / análisis de datos grandes donde el objetivo es obtener resultados previamente desconocidos y, como tales, no especificables) FP puede ofrecer ventajas

Si decidiera cambiar a un lenguaje de programación funcional, ¿cuáles considera que son los mayores escollos que enfrentaré?

  • falta de soporte de herramientas (F # y algunos Lisps son la excepción, Scala está en camino)
  • es más difícil exprimir el último rendimiento de su hardware
  • Las comunidades a menudo se centran en problemas diferentes a los que enfrenta un gran grupo de proyectos de desarrollo de software comercial
  • muy pocos desarrolladores con experiencia en el uso de FP 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 resultados en una larga cadena de funciones compuestas generalmente no es posible en la mayoría de los depuradores (¿todos?)

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

  • ¿Cuántos de sus problemas se pueden resolver al salir de bibliotecas / marcos en qué plataforma (por ejemplo, JVM o .Net) cuántos son 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?

  • ¿Cuán estrictos son sus requisitos de "corrección"?

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

Alexander Battisti
fuente
+1 @Alexander esta es sin duda una de las mejores respuestas en esta discusión. Trajo una nueva dimensión de argumentos a la discusión al introducir el factor humano, la dificultad de encontrar desarrolladores expertos y mantenerlos motivados. Estoy totalmente de acuerdo con su visión de las características asesinas de FP langs, porque cada día veo que los lenguajes más imperativos también las adoptan. Pero su publicación me ha abierto los ojos para darme cuenta de que hay muchas cosas que todavía no sé sobre FP. Finalmente, su punto de basarse en una plataforma existente como .Net o Java es ciertamente muy válida y totalmente sensata.
edalorzo
9

Si decidiera cambiar a un lenguaje de programación funcional, ¿cuáles considera que 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).

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

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

Si eres un programador web, entonces la mayor dificultad probablemente será tu cabello.

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

Comenzarí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 geniales en la JVM.
Jon Harrop
fuente
1
Cuando leí "Prepárate para compañeros gruñones que no quieren aprender nada". Quería gritar: "¡Tan cierto! ¡Tan malditamente cierto!" pero es muy triste
Zelphir Kaltstahl
3

Para una perspectiva (ciertamente sesgada) sobre esta pregunta, puede consultar el blog de Bob Harper, Tipo existencial . Carnegie Mellon ha reelaborado recientemente su plan de estudios de CS para enseñar primero la programación funcional, con otros paradigmas enseñados solo una vez que se ha establecido una base sólida en la programación funcional, y Harper está dando un golpe a golpe a medida que el nuevo plan de estudios se implementa 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 asunto se puede adivinar de antemano, y ciertamente no se asusta de las declaraciones controvertidas al argumentar por esta posición, pero hace Su caso bien.

jimwise
fuente
1
+1 Este artículo es ciertamente muy interesante y lo guardaré en mis favoritos de ahora en adelante. Creo que enseñar FP primero es ciertamente un buen enfoque, porque es realmente difícil deshacerse del pensamiento imperativo si lo haces de otra manera, y sobre todo si no usas un lenguaje de programación puramente funcional, es difícil romper el viejo Hábitos También veo que los principales lenguajes de OOP están incorporando características funcionales y, por lo tanto, adquirir las habilidades y el estado mental de un programador funcional debe ser realmente útil en el futuro cercano. Perspectiva interesante, gracias!
edalorzo
@jimwise: +1 para el artículo de Harper. Su enfoque me parece muy apropiado. @edalorzo: Cuando comienzas a pensar funcionalmente, ves el paradigma imperativo como último recurso que debes aplicar para optimizar tu programa cuando no es lo suficientemente rápido. He estado escribiendo algunas herramientas pequeñas en Scala recientemente, no muy grandes pero no triviales y con alguna funcionalidad real. Para mi sorpresa, no he usado varni ninguna colección mutable una sola vez. Entonces, el pensamiento imperativo es IMO algún tipo de optimización prematura que, como todos sabemos, es la raíz de todo mal.
Giorgio
2

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

No existe una fórmula mágica que le indique cuándo utilizar 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 programas en términos de otro conjunto de abstracciones.

Si decidiera cambiar a un lenguaje de programación funcional, ¿cuáles considera que 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 comprender la 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 debido al hecho de que 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 funcionales puros. Clean tiene tipos únicos y algunos otros lenguajes en desarrollo tienen otras cosas.

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

Entre los lenguajes de programación que conozco, diría que solo Haskell y Clean pueden llamarse lenguajes funcionales. Todos los demás permiten efectos secundarios sin hacer que esos efectos sean explícitos en el sistema de tipos. Entonces, si va a dedicar tiempo a aprender programación funcional, entonces Haskell es probablemente el único que se ajusta a la ley. Todos los otros que conozco, Erlang, Scala, Clojure, etc., solo proporcionan abstracciones funcionales además de un lenguaje imperativo. Entonces, si desea abordar el paradigma funcional en bits, le recomendaría Scala o Erlang y si desea abordar todo de una vez y posiblemente renunciar a la frustración, entonces debería ir con Haskell.

davidk01
fuente
@ Dadivk01 +1 Me gusta el razonamiento de que los langs FP son solo una herramienta competitiva como cualquier otra y pueden usarse para resolver los mismos problemas que los resueltos con otros modelos. ¿Por qué crees que son menos populares, entonces? Y, ¿aún estaría de acuerdo en que son más adecuados para resolver el problema de la computación paralela que, por ejemplo, la mayoría de los OOP langs? ¿Diría que el tipo de datos inmutable tiene alguna influencia en la huella de memoria y el rendimiento en comparación con los langs imperativos? Le estaba dando una oportunidad a Haskell, ¿por qué dirías "rendirse en la frustración", me estás asustando, amigo :)
edalorzo
@edalorzo: No creo que la programación funcional sea mejor para algoritmos paralelos. La gente confunde la programación declarativa con la programación funcional. Lo que la programación funcional tiene es su naturaleza declarativa y un grupo de personas realmente inteligentes que escriben excelentes compiladores para traducir el código declarativo al código de la máquina. Cualquier otro lenguaje que se inclina más hacia la descripción de problemas en lugar de explicar explícitamente detalles menores será igual de bueno para la programación paralela.
davidk01
@edalorzo: En cuanto a "darse por vencido por la frustración", digo eso porque si la programación imperativa es todo lo que sabe, entonces el sistema de tipos de Haskell y su enfoque monádico para describir los efectos podría ser demasiado. Creo que es mejor comenzar con un lenguaje que adopte un enfoque más pragmático para los efectos secundarios como Erlang y Scala.
davidk01
0

Atribuiría el aumento actual de interés en lenguajes funcionales al hecho de que son ideales para la computación paralela. Por ejemplo, toda la idea de map-reduce se basa en el paradigma funcional. Y no hay duda de que la computación paralela irá en aumento, ya que está claro que el escalamiento actual es mucho más fácil y económico que el escalamiento. 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 efectos secundarios, significa que no tiene un estado compartido, por lo tanto, no necesita mecanismos de sincronización, que de lo contrario serían necesarios mientras se ejecuta simultáneamente. La sincronización es la parte más difícil de cualquier software concurrente / paralelo, por lo que es puramente funcional, básicamente no tiene que lidiar con la parte más difícil.

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 programación funcional pura.

Pocos ejemplos de FP utilizados para el paralelismo:

  • CouchDB - construido en Erlang
  • Chat de Facebook: construye sobre Erlang
  • Twitter: gran parte construida en Scala
vartec
fuente
3
Todos hacen la afirmación de programación paralela, pero hay muy pocos datos para respaldarla. Si conoce alguna de esas fuentes, debe citarlas. Los cálculos complejos a menudo tienen dependencias de datos complejas y si utiliza un paradigma de programación funcional, la interdependencia de datos inherente de algunos modelos no desaparece mágicamente. La programación de la GPU es tan paralelo como se pone pero consiguen mediante el uso de lenguajes imperativos bien porque los modelos con los que trabajan han construido en el paralelismo.
davidk01
44
@vartec: En aras de la objetividad, sería bueno si pudieras proporcionar una referencia que respalde tus afirmaciones. Sería de gran ayuda a los lectores ignorantes mucho más que una contra-pregunta ...
blubb
1
@vartec: En realidad no, nunca se me ocurrió que mucha gente haciendo alguna afirmación lo hizo realidad. Culpo a mi formación en matemáticas, pero bueno, no todos creemos en cosas como hechos concretos y justificaciones concretas de nuestras afirmaciones, y su edición aún no responde a mi comentario.
davidk01
1
@vartec Puede hacer referencia a una fuente creíble que respalde sus reclamos.
quant_dev
1
+1 @ davidk01 "Todos hacen el reclamo de programación paralela pero hay muy pocos datos para respaldarlo". Soy consciente de una gran cantidad de evidencia de lo contrario. Por ejemplo, los documentos de Cilk describen cómo la mutación en el lugar es esencial si desea una buena complejidad de caché, que es un requisito de paralelismo escalable en un multinúcleo.
Jon Harrop