Yo diría que una de las razones por las que la programación funcional no prevalece es la falta de conocimiento. Mi experiencia es que las corporaciones son muy contrarias al riesgo en términos de implementación de tecnologías que no son la corriente principal y prefieren invertir en marcos probados (java, c ++, c #). Es solo cuando hay una necesidad comercial (como en Ericsson) que se consideran los nuevos paradigmas. Pero incluso en el caso de Ericsson, escuché que la gerencia exigió que se usara c ++ y Joe Armstrong se vio obligado a codificar las llamadas de Erlang en c ++. ¡Esto debería mostrar cómo las empresas reacias a implementar nuevas tecnologías!

Fui profesor y, al igual que los programadores, los profesores siempre están buscando la próxima gran cosa. Cuando creen que han encontrado uno, lo convierten en un carro y todos se amontonan. Ya que están predicando a los estudiantes que piensan que los profesores deben ser realmente inteligentes, de lo contrario, ¿por qué serían profesores? No obtienen resistencia.

La programación funcional es un carro de este tipo. Seguro que tiene muchas preguntas interesantes para investigar y muchos artículos interesantes para escribir en conferencias. No es una idea particularmente nueva, y puede hacerlo en casi cualquier lenguaje moderno, y las ideas no tienen que ser nuevas para ser interesantes. También es una buena habilidad para tener.

Dado que, la programación funcional es solo una flecha para tener en tu carcaj, no la única, de la misma manera que OOP no es la única.

Mi trabajo con la academia de ciencias de la computación es la falta de interacción práctica con la industria para determinar lo que realmente tiene sentido en el mundo real, es decir, el control de calidad. Si ese control de calidad estuviera allí, podría haber un énfasis diferente en la clasificación de los problemas y las gamas de soluciones para ellos, con compensaciones, en lugar de solo los últimos carros de banda.

Porque el mayor problema en el desarrollo de software en estos días es la capacidad de administrar la complejidad. Este no es el enfoque de la mayoría de los lenguajes de programación funcionales. Como tales, los lenguajes que hacen hacen que una prioridad (es decir, los lenguajes OOP más populares) tienden a robar algunas de las características más geniales que surgen de los lenguajes funcionales más académicos y, por lo tanto, se mantienen en la parte superior.

La programación funcional está empezando a ponerse en marcha, de manera lenta pero segura.

Por ejemplo, el inicio que estoy creando está usando un lenguaje funcional (Clojure) como el lenguaje de desarrollo principal por las siguientes razones:

• Productividad : aprender FP es difícil, pero una vez que lo aprendes, es muy difícil de superar en términos de poder y expresividad. Probablemente estoy escribiendo aproximadamente la décima parte del número de líneas para implementar cualquier pieza de funcionalidad en comparación con lo que habría necesitado en C # o Java

• Confiabilidad : las funciones puras son mucho más fáciles de razonar y probar que los objetos con estado. Por lo tanto, puede escribir mejores pruebas y validar la corrección de su código mucho más fácilmente.

• Concurrencia : los lenguajes funcionales enfatizan la inmutabilidad, lo que tiene enormes beneficios para las aplicaciones concurrentes que la necesidad de ejecutar de manera efectiva en múltiples núcleos. Y nos guste o no, correr en múltiples núcleos es el futuro. Consulte enlace para obtener una explicación brillante de por qué esto es tan importante

• Composición / modularidad : los lenguajes funcionales parecen prestarse a conectar componentes con mayor facilidad que los sistemas OO complejos. Todavía no he descubierto todas las razones de esto, pero parte de esto se debe al hecho de que no tienes toda la "complejidad incidental" que los modelos OO arrastran con ellos. La charla sobre Radical Simplicity de Stuart Halloway explora estas ideas con mucha más profundidad.

EDIT : en respuesta al comentario de Despertar, un ejemplo de la "complejidad incidental" de los sistemas OOP que limita la modularidad son los problemas con la clonación profunda frente a la clonación superficial: no puede componer objetos juntos y pasarlos como estructuras compuestas sin un análisis muy cuidadoso de la semántica de clonación y mutación. En casos pequeños, esto es manejable, pero en sistemas complejos se convierte rápidamente en un problema importante. Este problema no existirá en primer lugar si confía en estructuras de datos puramente funcionales.

Falta de aplicación asesina

Hey, este de aquí parece fresco. (dig dig dig)

Creo que la mayoría de los lenguajes de programación prosperaron al tener una "aplicación asesina", algo convincente que era exclusivo del lenguaje (o visto de esa manera). Esto no quiere decir que toda la aceptación fue esa aplicación, sino que llevó al lenguaje a una mayor aceptación.

Aquí está mi visión no terriblemente precisa de qué nicho ha impulsado la adopción de algunos de los idiomas que tenemos hoy:

• C: Funciona en todas partes (esto fue a finales de los 70 y 80)
• C ++: marcos GUI (principios de los 90)
• Java: applets y servlets (a finales de los 90)
• Objective-C: aplicaciones de iOS (antes de eso, aplicaciones de OS X)
• Ruby: Rails
• C #: ASP.NET, WinForms
• PHP: Wordpress, etc.
• Javascript: AJAX, especialmente a través de marcos
• lua: secuencias de comandos del juego, especialmente WoW

Aparte de eso, muchos lenguajes propietarios han entrado en la puerta a través de poderosas organizaciones de ventas (Oracle, y en menor grado los lenguajes de Microsoft), creando efectivamente su propio nicho.

Una nota muy importante sobre esa lista: el "nicho" del idioma, como lo indica la aplicación asesina, se vuelve más y más específico a medida que pasan las décadas. Note el último en la lista: Juego scripting , específicamente. Es cada vez más difícil que los idiomas llamen la atención debido a la lista de cosas que ya están bien hechas por otro idioma.

Entonces, lo que cualquier lenguaje funcional necesita para despegar es un nicho. En realidad, todavía no hay lenguajes funcionales enormes, pero hay muchos nichos más pequeños:

• Emacs Lisp: uso constante desde los 80 en Emacs por los desarrolladores. ( Casi nunca se usa en ningún otro lugar.)
• Erlang: en cualquier lugar que desee muchos agentes concurrentes.
• Esquema: Educación
• APL / J / K: Finance (Llamemos a esto funcional, por el bien del argumento)
• Common Lisp: "AI": esto es lo que la gente suele decir que se usa, lo cual es una bendición y una maldición.

Ahora, el único lenguaje importante que siento que he dejado fuera de esta discusión es Python. Python ha hecho algo muy interesante; ha tenido éxito sin que parezca ser el ganador en ningún nicho importante. Esto podría significar que estoy totalmente equivocado por ver la popularidad del idioma de esta manera. También podría significar que un lenguaje suficientemente bueno puede volverse popular sin una aplicación asesina para impulsar la adopción y aceptación, pero es muy difícil y puede llevar mucho tiempo. (Perl tiene una historia similar, pero llegó hace unos años y ahora tiene menos aceptación).

A partir de esto, puedo decir qué lenguajes funcionales creo que están en aumento:

• Clojure: programación web, esp. a través de Heroku
• Scala: Lift (o quizás Play, en estos días) - JVM sin Java

Si me pregunta dónde buscar los lenguajes funcionales populares, diría que busque un lenguaje funcional con el desarrollo de la nube llave en mano (a la Heroku o GAE) o el desarrollo de aplicaciones móviles llave en mano.

Por la misma razón por la que Lisp nunca se dio cuenta (¡que comiencen los flamewars!). La programación funcional es un paradigma muy extraño en comparación con la programación imperativa y orientada a objetos. Si, como la gran mayoría de los estudiantes de CS, comenzaste con C y progresaste a C ++ / Java, tiendes a no querer aprender a pensar de una manera que sea completamente ortogonal a la forma en que piensas normalmente.     

Consideremos negocios y programación.

Hay empresas que utilizan su software como un activo estratégico. Esto no es típico. Para la mayoría de las empresas, la TI es algo que apoya el negocio real de la compañía. Es un gasto necesario. Son conservadores porque saben que por $ X pueden obtener la TI que necesitan, mientras que si cambian a algo diferente, ahorrarán menos de $ X si todo sale bien y perderán mucho si todo sale mal.

Además, en las empresas, lo más barato que se puede hacer es lo que hicieron ayer. El cambio, sin embargo, deseable, es costoso. Si una empresa cambiara, por ejemplo, una solución C # / .NET, incluso a F #, tendrían problemas. Sus programadores (que probablemente no son los programadores más hábiles) tendrían que aprender un nuevo idioma, dominar ambos y usar ambos con frecuencia. Habría rutinas escritas en ambos durante mucho tiempo. Si se mudaran a algo como Haskell, o si estuvieran usando C ++ / MFC en primer lugar, estarían cambiando mucho más, y eso sería mucho más caro.

Además, habrá un suministro de programadores de C # y soporte continuo de Microsoft durante mucho tiempo. Se puede contar con las prácticas informáticas actuales. No existe el mismo nivel de soporte institucional o garantía de disponibilidad continua de los programadores.

Por lo tanto, para la mayoría de las empresas, hacer un cambio en la programación funcional sería costoso desde el principio, y solo se pagará si la reducción de los costos de TI es suficiente a largo plazo, excepto que el largo plazo es potencialmente dudoso.

Ya escribes código en estilo funcional, pero no lo sabes.

Cuando se le solicita que realice pruebas unitarias para su código, tiende a escribir funciones comprobables, que no crean o dependen de los efectos secundarios, y siempre devuelve el mismo resultado en los mismos argumentos (las llamadas funciones puras). Esta es la principal ventaja de los programas funcionales.

Creo que los lenguajes funcionales son demasiado limitantes. Entonces, en lugar de reemplazar los lenguajes imperativos por lenguajes funcionales, los imperativos obtendrán características funcionales. Hoy en día casi todos los lenguajes de programación tienen cierres y lambdas.

El problema real es el estado.

Los lenguajes funcionales no tienen estado global. La mayoría de los problemas industriales requieren un estado a gran escala (¿cómo representa usted un libro mayor o un conjunto de transacciones) incluso si algunas funciones en la pequeña escala no lo requieren realmente (procesar un libro mayor)?

Pero estamos ejecutando código en máquinas de arquitectura Von-Neuman que están inherentemente llenas de estado. Entonces, en realidad no nos hemos librado del estado, los lenguajes funcionales simplemente ocultan la complejidad del estado al desarrollador. Esto significa que el lenguaje / compilador tiene que lidiar con el estado detrás de la escena y administrarlo.

Entonces, aunque los lenguajes funcionales no tienen un estado global, su información de estado se pasa como parámetros y resultados.

  

Entonces, la pregunta es: ¿el lenguaje puede manejar el estado de manera eficiente detrás del sentido? Especialmente cuando el tamaño de los datos supera con creces el tamaño de la arquitectura.

Mirándolo desde el lado del hardware

El sistema operativo ha ayudado mucho en los últimos años en la visualización del espacio de direcciones para que las aplicaciones no tengan que preocuparse oficialmente por ello. Pero las aplicaciones que no se preocupan por caer en la trampa de golpear el hardware cuando la presión de la memoria se vuelve más intensa (el hardware de la paliza ralentizará sus procesos).

Como el programador no tiene control directo sobre el estado en el lenguaje funcional, debe confiar en el compilador para manejar esto y no he visto lenguajes funcionales que lo manejen bien.

En el lado opuesto de la moneda, el programador de estado completo tiene control directo sobre el estado y por lo tanto puede compensar las condiciones de memoria baja. Aunque no he visto a muchos programadores que sean lo suficientemente inteligentes como para hacerlo.

Mirando desde el lado de la industria:

La industria tiene muchos programadores ineficientes llenos de estado.

Pero es fácil medir las mejoras en estos programas a lo largo del tiempo. El problema es que un equipo de desarrolladores puede mejorar el código al mejorar la forma en que el programa maneja el estado.

Para los programas funcionales, las mejoras son más difíciles de medir , ya que necesita mejorar las herramientas que mejorarán los programas (solo observamos cómo las aplicaciones manejan el estado subyacente de manera eficiente, no la mejora general). del programa).

Entonces, para la industria, creo que todo se reduce a la capacidad de medir mejoras en el código.

Desde una perspectiva de contratación

Hay muchos programadores de estadísticas completas disponibles para contratar. Los programadores funcionales son difíciles de encontrar. Por lo tanto, su modelo básico de oferta y demanda se activaría si la industria cambiara a la programación de estilo funcional y eso no es algo que quieran que suceda (los programadores son lo suficientemente caros).

Creo que solo hay una respuesta real a tu pregunta. Puede entrar en muchas razones relacionadas por las que esta respuesta es así, pero esas son preguntas diferentes.

Aquí está:

• Los arquitectos de software proporcionan soluciones que confían en que funcionarán.
• La mayoría de los arquitectos no trabajan en lenguajes funcionales.
• Una vez que se eligen las tecnologías y los idiomas, las empresas encuentran personas que pueden trabajar con ellos.

¿Se está poniendo de moda? Todo depende de si las personas que tienen confianza en el uso de lenguajes funcionales se están convirtiendo en arquitectos y eligen utilizarlo para los proyectos en los que trabajan.

Esta pregunta tiene una premisa ligeramente errónea. Por las siguientes razones:

1. La programación funcional es bastante común en la industria. Pero solo se usa cuando hay programadores experimentados disponibles. No se puede esperar que los principiantes lo sepan. Casi todos los grandes proyectos de programación lo están utilizando, pero solo lo mantienen en áreas que son manejadas por programadores experimentados. Los principiantes se ocuparán de los módulos fáciles que no requieren programación funcional.
2. Dada esta realidad, las empresas que contratan personas (generalmente jóvenes que vienen de la universidad) no pueden realmente pedir experiencia de programación funcional. Cualquier persona en proyectos que requiera programación funcional ya lleva 15 años en la misma compañía.
3. Las universidades están empezando a enseñarlo, porque ya saben que el conocimiento de la programación funcional será muy útil en 30 años. Su rango de tiempo es de 30 años, no el semestre normal como en las empresas.
4. Estos puntos son la razón por la cual las personas se sienten decepcionadas cuando ingresan a la fuerza laboral y ven que las cosas que aprendieron en la universidad no se usan. Pero fueron diseñados para un período de tiempo de 30 años, y será útil en el futuro, es solo que las empresas están usando cosas simples, cosas que pueden esperar que la gente sepa.
5. También serías arrogante si piensas que después de algunos años de universidad, conoces la programación funcional lo suficientemente bien como para usarla en proyectos de software reales. Comience desde lo simple primero. Realmente no necesita hacer la pieza de software más compleja como su primera tarea cuando comienza a trabajar. Eventualmente llegarás a lo complejo, pero lleva tiempo.

Porque es más difícil depurar FP.