¿Cuál es su opinión más fuerte contra la programación funcional? [cerrado]

25

La programación funcional es uno de los paradigmas de programación más antiguos. Sin embargo, no se usa mucho en la industria en comparación con los paradigmas más populares. Pero se ha enfatizado en gran medida en la academia.

¿Cuál es su opinión más fuerte contra la programación funcional?

Jonas
fuente
55
LINQ? .NET delegados? ¿DSL como Mathematica?
Jon Harrop
55
Por cierto, el término "programación funcional" es utilizado por diferentes personas para significar cosas diferentes, por lo que debe aclarar qué significado está utilizando.
Jon Harrop
2
Nunca, jamás, encontrarás personas para codificar en tu base de código funcional. No es una gran decisión comercial, ya que limita tu grupo de talentos.
Patrick Hughes

Respuestas:

52

El problema es que el código más común involucra intrínsecamente el estado: aplicaciones comerciales, juegos, interfaz de usuario, etc. No hay problema con que algunas partes de una aplicación sean puramente funcionales; de hecho, la mayoría de las aplicaciones podrían beneficiarse en al menos un área. Pero forzar el paradigma por todas partes se siente contra-intuitivo.

Nota para uno mismo - piense en un nombre
fuente
19
Absolutamente. La programación funcional pura NO es adecuada para aplicaciones muy orientadas al estado. Por eso me gustan los lenguajes híbridos que pueden hacer ambas cosas. Utilice paradigmas funcionales para problemas funcionales, paradigmas imperativos para problemas imperativos.
Matt Olenik el
8
¡Convenido! El estado es una parte esencial de la programación. Esta es la razón por la que incluso Haskell, de alguna manera el más puro de los lenguajes FP, permite el uso de estado e IO: simplemente impone una distinción entre el código IO / código de estado mutable y el código puro, lo cual es muy bueno para probar y facilitar la comprensión. .
Bill
8
Por eso amo a Haskell. Alienta a minimizar esos códigos con estado. En OO, mi objetivo es escribir código reutilizable, fácil de entender y fácil de probar. La mayoría de las veces termino con código que no escribiría muy diferente en Haskell.
LennyProgrammers
44
"simplemente impone una distinción entre el código IO / código de estado mutable y el código puro, lo cual es muy bueno para probar". Ni siquiera puede imprimir mensajes de depuración sin eludir el sistema de tipos o introducir monad creep.
Jon Harrop
2
Presumiblemente, un programa de función pura dejaría el mundo totalmente sin cambios al ejecutarlo.
Martin Beckett
24

El problema con la programación funcional no es la programación funcional en sí misma: son la mayoría de las personas que lo hacen y (peor) la mayoría de las personas que diseñan lenguajes para hacerlo.

El problema surge del hecho de que, a pesar de ser muy inteligentes (a veces francamente brillantes), demasiadas personas son demasiado fanáticas acerca de la pureza, la perfección y la aplicación de su propia visión (a menudo bastante limitada) del mundo y la programación en el lenguaje y todos los que lo usan.

Uno de los resultados es la falta de compromiso. Esto lleva (entre otras cosas) a aproximadamente 10,000 idiomas y dialectos que son lo suficientemente diferentes como para molestar, pero rara vez lo suficientemente diferentes para que uno tenga una ventaja realmente significativa sobre los demás. Muchos también miran el mundo real y deciden que, dado que no se ajusta muy bien al modelo funcional, básicamente está mal y es mejor ignorarlo.

La incapacidad para comprometerse también ha dado lugar a bastantes idiomas que son absolutamente hermosos para un tipo específico de problema (o algunos tipos específicos de problemas) pero que realmente apestan para muchos otros. Algo de eso probablemente sea causado por el modelo funcional en sí, pero parece que mucho más (al menos para mí) es causado por el tipo básico de personalidad que se siente atraído por esta área.

Eso lleva a una serie de problemas. En primer lugar, aprender "programación funcional" es principalmente de valor filosófico. Con la mayoría de los otros tipos de idiomas, conocer un idioma de un género en particular es de gran ayuda para aprender otro. Si mi proyecto usa el lenguaje XI, generalmente puedo contratar a alguien que sepa el idioma Y (pero no X) con bastante seguridad. Con lenguajes funcionales, eso es mucho menos cierto. Es posible que conozca a Erlang bastante bien, pero aún encuentre a las mónadas de Haskell completamente extrañas e incomprensibles.

Si combina la cantidad de idiomas con la portabilidad limitada del talento entre ellos, obtendrá una situación fea: es casi imposible que un idioma o dialecto forme la "masa crítica" necesaria para que tenga un uso razonablemente general. Eso está cambiando lentamente, pero todavía se parece mucho a que Linux se convierta en el sistema operativo de escritorio dominante: cada año, la gente presenta argumentos convincentes de que finalmente este será el año, y al igual que las personas que han estado prediciendo que cada año año durante décadas, se equivocarán una vez más. Eso no quiere decir que (cualquiera de los dos) nunca pueda suceder, solo que las personas que miran las predicciones y piensan "no, no este año" han sido las correctas hasta ahora.

Jerry Coffin
fuente
44
Quizás habría más cruce entre lenguajes funcionales si hubiera más lenguajes funcionales.
Barry Brown el
55
No puedes ser "funcional" sin esa pureza. Una vez que cruza la línea, todo el concepto se desmorona y termina con un lenguaje estándar desordenado, paralelo y sin ninguna de las ventajas.
Patrick Hughes
77
¿Entonces su primer problema es que los lenguajes funcionales no son lo suficientemente diferentes como para tener una ventaja sobre el otro, y su segundo problema es que son demasiado diferentes para pasar fácilmente?
Tikhon Jelvis
2
Para mí, esta respuesta se lee como una diatriba. Su argumento sería mucho más convincente si tuviera que dar algunos ejemplos.
Benjamin Hodgson
1
...roughly 10,000 languages and dialects that are enough different to annoy but only rarely enough different for one to have a truly significant advantage over the others...No, eso suena como todos estos problemas de procedimiento. Java, Scala, Kotlin, C ++, C #, Groovy, Cheddar, ES6, Ceylon, Python, la lista sigue y sigue: todas son iteraciones aburridas de C que no resuelven los problemas reales. Esa es mi opinión despectiva para complementar esta respuesta desatinada: D
cat
17

Creo que la razón por la que la programación funcional no se usa ampliamente es porque se interpone demasiado en tu camino. Es difícil analizar seriamente, por ejemplo, Lisp o Haskell, sin decir "todo este lenguaje es una gran inversión de abstracción". Cuando establece abstracciones de referencia que el codificador no puede entender cuando es necesario, establece cosas que el lenguaje simplemente no puede hacer, y cuanto más funcional es el lenguaje, más de estas tiende a tener.

Tome Haskell, por ejemplo. En nombre de la pureza funcional, debe usar inversiones de abstracción que rompan el cerebro que nadie entiende para administrar el estado y las E / S, ¡ las dos partes más fundamentales de cualquier programa de computadora que interactúa con cualquier cosa! Eso envejece rápido.

Mason Wheeler
fuente
99
+1, aunque a veces siento lo mismo cuando programo en lenguajes imperativos de alto nivel. Por ejemplo, ¿por qué necesito hacer una clase de método único que implemente una única interfaz de método en Java en lugar de usar un puntero de función como lo haría en C?
dsimcha
14
Diría que no es que "no puedas entender" esas abstracciones, es más que solo se necesita mucho trabajo. Estamos acostumbrados a recoger un plátano y comerlo en un idioma imperativo; Haskell (por ejemplo) hace que primero llenes un formulario de 20 páginas porque prioriza la garantía de que nunca se comerá misteriosamente un plátano cuando no estés mirando. Lo que ayuda al razonar sobre los plátanos, pero a veces solo tienes hambre.
j_random_hacker
44
@dsimcha: esta es una peculiaridad de Java más que una tendencia en lenguajes imperativos de alto nivel. De hecho, es probable que los lenguajes de alto nivel tengan la función de objeto de primera clase.
Muhammad Alkarouri
3
La necesidad de las mónadas en Haskell no se debe a la pureza funcional, sino al hecho de que los efectos secundarios y la evaluación perezosa son dos sabores excelentes que NO saben muy bien juntos. Las mónadas fuerzan la evaluación secuencial. (Realmente, deberían llamarse Computation Builders o algo así. 'Mónada' es un nombre pésimo para cualquiera que no sea un teórico de la categoría). ¡Y puedes hacer FP felizmente (usando a sabiendas) mónadas!
Frank Shearar
44
Una cosa a tener en cuenta: dadas estas "inversiones de abstracción", el lenguaje puede ser más limitado, pero el compilador y el tiempo de ejecución tienen más garantías sobre su código y pueden hacer más. Esto es como la recolección de basura: en un lenguaje gc, no puede simplemente malloc space (lo que podría ser útil), pero a cambio, el tiempo de ejecución puede administrar toda su memoria por usted, potencialmente más eficientemente de lo que podría hacerlo manualmente. Es lo mismo con la pureza funcional.
Tikhon Jelvis
8

Con el debido respeto, creo que su pregunta está mal planteada. La programación funcional es una herramienta, o más bien un conjunto de herramientas que son útiles para resolver ciertos tipos de problemas. Tener una opinión al respecto solo tiene sentido en el contexto de un problema o aplicación específicos. Tener una opinión en contra de ella en general, es como tener una opinión en contra de pinzas o llaves.

Dima
fuente
44
Ese es un punto lógicamente válido, pero puede remediarse agregando "para el tipo de problemas de programación que encuentra con frecuencia" en la oración final de la pregunta del OP. (No importa que los lectores individuales encuentren problemas diferentes, siempre que describan lo que son)
J_random_hacker
4

Incluso si lo hubiera dominado, podría no estar dispuesto a usar un lenguaje funcional para un producto comercial por la simple razón de que no se entiende ampliamente y si esperaba que el negocio creciera, me preocuparía la posibilidad de encontrar otros desarrolladores capaces de mantenerlo o extenderlo en el tiempo.

No es inconcebible, y probablemente obtendría un estándar más alto de desarrollador porque un graduado de javaschool sin habilidades reales de piratería no sabría por dónde comenzar en un proyecto de ese tipo, pero el grupo limitado de desarrolladores capaces sin duda sería una consideración necesaria desde una perspectiva empresarial.

glenatron
fuente
2

Hora de comprar

Difícil deshacerse de un panorama de TI completo de código de procedimiento y mantras.

Jé Queue
fuente
1
Los programas funcionales son a menudo más fáciles de probar. Y son más cortos. Muy en desacuerdo. Creo que responde otra pregunta "¿Cuál es su opinión más fuerte en contra de cambiar a la programación funcional?".
Jonas
2

en primer lugar, no acepto ninguno de los argumentos con respecto a la programación de estado y fp. investigue la mónada estatal en Haskell y encontrará una serie de nuevas e interesantes formas de evaluar el impacto del estado en su código.

Si tuviera que presentar un argumento significativo en contra de fp, sería que aprender un lenguaje funcional serio como Haskell es como aprender a conducir un auto de Fórmula Uno ... estimulante y educativo, pero lamentablemente inútil para la codificación industrial cotidiana porque, en promedio , sus compañeros de trabajo conducen camrys y están muy contentos de hacerlo. todavía es extremadamente difícil encontrar trabajo en un entorno amigable para fp, y no veo que esto cambie a menos que uno esté dispuesto a atacar por su cuenta o buscar a algunos de los conocidos practicantes de fp.

supongo que mi respuesta me muestra como un fanático de fp. sugiero darle un giro serio a un lenguaje fp real como haskell antes de preocuparse por encontrar razones por las que no debería hacerlo.

Brad Clawsie
fuente
66
Creo que su primer párrafo describe exactamente lo que está mal con la mentalidad FP. No queremos "nuevas formas interesantes de evaluar el impacto del estado en nuestro código". ¿¡¿Y eso que significa?!? Solo queremos que el estado esté allí y sea de fácil acceso porque lo necesitamos para hacer las cosas.
Mason Wheeler
2
El Camry que conduzco tiene sus problemas, pero no requiere que revise constantemente debajo del capó para ver si hay fugas de espacio . Haskell es más como un lenguaje que se parece a un auto de F1, pero en realidad no puede hacer altas revoluciones durante un período prolongado de tiempo. :-P
j_random_hacker
1
@Mason Wheeler: "No queremos nuevas e interesantes formas de evaluar el impacto del estado en nuestro código". En cambio, preferimos pasar una semana rastreando un error muy desagradable debido a un efecto secundario no deseado (hablo por experiencia personal).
Giorgio
@brad clawsie: creo que todo el problema del control de los efectos secundarios en FP puede servir para hacer que la codificación sea mucho más productiva: lleva más tiempo escribir pero menos tiempo para solucionarlo. Desafortunadamente, primero hay que esforzarse mucho para aprender, y muchos programadores no tienen este pensamiento a largo plazo: las cosas deben hacerse rápidamente. No hay tiempo para hacerlo correctamente la primera vez, pero siempre hay tiempo para depurarlo y arreglarlo más tarde. :-)
Giorgio
@Mason Wheeler: desde un punto de vista funcional, tener un estado compartido solo es útil para fines de optimización: copiar valores requiere demasiado tiempo y memoria, por lo que comparte un objeto de datos para evitar copias innecesarias. Pero hacer cumplir un estado compartido como regla desde el principio es una especie de optimización prematura.
Giorgio
2

Soy un gran admirador y defensor de la programación funcional. Pero aquí están mis puntos:

  • fácil de aprender
    Los lenguajes de programación como python y ruby ​​(y muchos otros idiomas) son fáciles de aprender. La programación funcional avanzada, con lenguajes como Haskell, Agda, Coq, ATS, etc., es bastante difícil de aprender. Algunos usan el término "programación estructurada matemática". Es fácil si está familiarizado con la teoría de categorías y las matemáticas abstractas, pero bastante trabajo si no tiene idea de qué son, por ejemplo, las "mónadas".

  • programar con un lenguaje de script puede significar más productividad.
    En algunas situaciones, usar lenguajes de script como python y ruby ​​puede conducir a una mayor productividad. Esto significa creación rápida de prototipos y pegado de diferentes paquetes o bibliotecas. Incluso el uso de lenguajes dinámicos (por ejemplo, programación orientada a objetos dinámicos) puede ser algo bueno en este contexto. Por lo general, la escritura estática es mejor, pero las secuencias de comandos con tipos dinámicos pueden tener un efecto positivo.

  • Consideraciones comerciales La
    programación es solo un pequeño subconjunto de proyectos de software exitosos. El software tiene que funcionar, los usuarios deben estar contentos y esto no depende necesariamente del lenguaje de programación utilizado. Los gerentes deben pensar en los beneficios y el riesgo al evaluar nuevas tecnologías y lenguajes de programación. ¿Pueden los nuevos programadores aprender rápidamente el nuevo lenguaje de programación? ¿Hay experiencia en la empresa con la tecnología? ¿Existe algún riesgo y será difícil discutirlo con la alta gerencia?

En el contexto empresarial, la programación funcional se puede utilizar en sistemas que se suman a los componentes centrales del software, por ejemplo, componentes que no son tan críticos para la misión. Por ejemplo, un banco que difícilmente cambiará el software central, pero agregará nuevas partes (GUI, software de monitoreo, etc.) en un nuevo lenguaje de programación. (Tal vez hay excepciones, pero esta es mi experiencia con los bancos).

Además, la programación funcional es muy útil cuando la verificación formal es un beneficio o una necesidad.

mrsteve
fuente
3
"fácil de aprender": no encuentro el dominio de Haskell más difícil que el dominio de C ++ moderno. Creo que tendemos a considerar mucho lo que no estamos familiarizados.
Giorgio
1

No me opongo a FP como un paradigma útil, pero me opongo a él como el único paradigma disponible en un lenguaje de programación.

Ofrece ventajas para resolver muchos problemas. Sin embargo, FP puede, y ha sido, aplicado en lenguajes de procedimiento como C.

Huperniketes
fuente
De acuerdo con la primera oración, en desacuerdo con la segunda. Básicamente no puedes hacer FP sin recolección de basura.
dsimcha
No es necesario que el sistema de tiempo de ejecución de un idioma carezca de una administración de memoria transparente (con recolección de basura) para que quepa en la etiqueta de "procedimiento", por lo que es irónico que haya redactado su segunda oración de esa manera. BÁSICO es uno de esos idiomas.
Huperniketes
"Básicamente no puedes hacer FP sin recolección de basura". - ¿Por qué?
quant_dev
+1 La programación funcional en el nivel más básico es la programación sin estado. No creo que haya ningún lenguaje que no pueda hacer esto hasta cierto punto. He escrito funciones en C, C ++, Java, ensamblaje, C #, incluso Basic. Todo lo que se requiere es que la función no tenga efectos secundarios o retenga el estado entre llamadas.
Michael K
Por otro lado, si su lenguaje es completamente puro, el compilador tiene más margen de maniobra en sus optimizaciones. Además, el código se vuelve más fácil de probar y razonar. Ser funcional en todo momento ofrece algunos beneficios sobre un enfoque híbrido; Si va a tener la mayoría de su código sin estado de todos modos, también puede ir un poco más lejos y cosechar los beneficios adicionales.
Tikhon Jelvis
1
  1. (y, con mucho, el más importante) La fuerza laboral del programador no está capacitada en esos idiomas o estilos
  2. Muchos de los evangelistas funcionales salen como huecos o pasteles de frutas debido a la forma en que intentan vender funcionales. A nadie le gusta un agujero, y nadie va a tirar dinero detrás de un pastel de frutas. Eso sí, me gustan mucho las cosas funcionales y me gustaría incorporarlo, pero sé que en mi lugar de trabajo sería la única persona que podría desarrollarlo sin gastar dinero en capacitación (venta difícil), y casi todo lo bueno referencias hablar hacia abajo en el lector.

Funcionará cuando tengamos cientos de núcleos y nos demos cuenta de que los bloqueos no se escalan. Entonces, los datos anidados en paralelo serán la única forma de ir para los programas de "gran hierro", y funcional sobresale en eso.

luego
fuente
0

FP es genial en la academia porque es genial escribir buenos programas cortos, mientras se ignora el rendimiento. No hay ninguna conspiración contra ella en el mundo real. También, por ejemplo, implementar algunas cosas (clasificación de radix, por ejemplo) parece un dolor total en FP. Ah, y el código generado es IMHExperience sloooooooooooooooooooow.

NoSenseEtAl
fuente
44
Sí, eso es evidentemente falso. El código de Haskell suele estar a la par con C y Java, y mucho más rápido que Python y sus amigos. Por lo general, también es trivial paralelizar, lo que puede dar aún más velocidad.
Tikhon Jelvis
0

Algunos tienen una curva de aprendizaje bastante empinada, que lleva mucho tiempo (especialmente si vienes de OOP; agitarás la cabeza varias veces antes de obtener el cambio de paradigma).

Aunque comencé a obtener programación funcional (viniendo de Java e yendo a Clojure), todavía me resulta bastante difícil. La comunidad no parece escribir código tan expresivo como Java.

Parece que hay una pequeña pérdida en la expresividad y un pequeño aumento en la complejidad.

Belun
fuente
Creo que las personas sin experiencia previa en programación dirían que OOP tiene una curva de aprendizaje más pronunciada que FP, ya que FP está más cerca de las matemáticas. No entiendo lo que quieres decir con "La comunidad no parece escribir código tan expresivo como Java", ¿cuál es tu punto?
Jonas
Nunca escuché que el lenguaje funcional perdiera expresividad. Pero tampoco he usado un lenguaje menos expresivo que Java, así que puedo tener una definición diferente de "expresivo".
glenatron
@Jonas: debido a una cosa simple: atajos de nombres para funciones, variables, etc ... quiero decir, ¿por qué no simplemente nombrar las cosas por lo que son o se supone que deben hacer? ¿Por qué "pmap"?
Belun
1
@Belun: Eso no tiene nada que ver con la programación funcional. Debe referirse a un lenguaje de programación específico. Map es una función común en muchos lenguajes de programación funcionales, y tiene un buen nombre . pmapa lo que se refiere puede ser una variante paralela.
Jonas
Dije "la comunidad no parece escribir". significa que es lo que experimenté y se refiere a la comunidad que vi. no tiene que aplicarse a todos, aunque lo dudo. tiene que ver con la programación funcional, es como su estilo
Belun
0

Aunque tengo poca experiencia con lenguajes de programación funcionales (conozco algunos de Haskell y Lisp), encuentro el paradigma FP muy poderoso y, a menudo, más elegante que otros paradigmas. Desearía tener la oportunidad de trabajar en un proyecto serio usando FP.

La única área en la que tengo algunas dudas serias con respecto a la efectividad de FP es en cómo puede manejar estructuras de datos complejas que no pueden definirse inductivamente, por ejemplo, gráficos. Por ejemplo, si tengo que implementar un algoritmo que funciona en un gráfico grande, posiblemente recorriendo el gráfico y haciendo pequeños cambios locales, me pregunto si un enfoque de FP puede coincidir con un enfoque imperativo en el que el programa puede moverse de un nodo a otro. nodo utilizando punteros.

Giorgio
fuente