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

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?

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.

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.

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.

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.

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.

Hora de comprar

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

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.

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.

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.

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.

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.

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.

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.