Durante mis cuatro años en la universidad, hemos estado usando mucha programación funcional en varios lenguajes de programación funcional. Pero también he usado mucha programación orientada a objetos y, de hecho, uso más los lenguajes orientados a objetos cuando hago mi propio proyecto pequeño para prepararme para mi primer trabajo. Pero a menudo desearía estar codificando en un lenguaje de programación funcional al hacer estos proyectos.

Sin embargo, cuando se busca un trabajo, es muy raro ver un trabajo donde se requiere el conocimiento de un lenguaje de programación funcional.

¿Por qué los lenguajes de programación funcional no se usan más en la industria? Hay muchas noticias sobre los lenguajes de programación funcional en estos días, así que me pregunto si la programación funcional se está imponiendo en la industria ahora.

Diría que una de las razones por las que la programación funcional no es más frecuente es la falta de base de conocimiento. Mi experiencia es que las corporaciones son muy reacias al riesgo en términos de implementación de tecnologías que no son la corriente principal y prefieren invertir en marcos probados y verdaderos (Java, C ++, C #). Solo cuando hay una necesidad comercial (como en Ericsson) se consideran 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 cuán renuentes son las corporaciones para implementar nuevas tecnologías!

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

La programación funcional es un carro de este tipo. Claro que tiene muchas preguntas interesantes para investigar, y muchos artículos de conferencias interesantes para escribir. 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 tener.

Dado que, la programación funcional es solo una flecha para tener en su carcaj, no la única, así como OOP no es la única.

Mi problema con la academia de informática 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 clasificar los problemas y los rangos de soluciones a ellos, con compensaciones, en lugar de solo los últimos vagones.

Porque el mayor problema en el desarrollo de software en estos días es la capacidad de gestionar la complejidad. Este no es el foco de la mayoría de los lenguajes de programación funcionales. Como tal, las lenguas que hacen hacen que una prioridad (es decir, los lenguajes de POO más populares) tienden a robar solo algunas de las características más frescas que salen de los lenguajes funcionales más académicos y así mantenerse en la cima.

La programación funcional definitivamente está comenzando a ponerse al día, lenta pero seguramente.

Por ejemplo, la startup que estoy construyendo usa un lenguaje funcional (Clojure) como lenguaje de desarrollo primario por las siguientes razones:

• Productividad : aprender FP es difícil, pero una vez que lo dominas es muy difícil de superar en términos de poder y expresividad. Probablemente estoy escribiendo aproximadamente 1/10 del número de líneas para implementar cualquier funcionalidad dada en comparación con lo que hubiera necesitado en C # o Java

• Fiabilidad : 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, que tiene enormes beneficios para las aplicaciones concurrentes que necesitan ejecutarse de manera efectiva en múltiples núcleos. Y nos guste o no, correr en múltiples núcleos es el futuro. Consulte http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey para obtener una explicación brillante de por qué esto es tan importante.

• Composabilidad / modularidad : los lenguajes funcionales parecen prestarse para conectar componentes más fácilmente 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 simplicidad radical de Stuart Halloway explora estas ideas con mucha más profundidad.

EDITAR : 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 se pueden componer objetos y pasarlos como estructuras compuestas sin un Análisis 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 funcionales puras.

Falta de aplicación asesina

Oye, este de aquí parece nuevo. (cavar cavar cavar)

Creo que la mayoría de los lenguajes de programación prosperaron al tener una "aplicación asesina", algo atractivo 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ó el 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 de GUI (principios de los 90)
• Java: Applets y servlets (a finales de los 90)
• Objective-C: aplicaciones iOS (antes de eso, aplicaciones OS X)
• Ruby: rieles
• C #: ASP.NET, WinForms
• PHP: Wordpress, etc.
• Javascript: AJAX, especialmente a través de frameworks
• 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 medida, los idiomas de Microsoft), creando efectivamente su propio nicho.

Una nota muy importante sobre esa lista: el "nicho" del lenguaje, como lo indica la aplicación asesina, se vuelve cada vez más específico a medida que pasan las décadas. Tenga en cuenta el último en la lista: secuencias de comandos del juego , específicamente. Cada vez es más difícil para los idiomas llamar la atención debido a la lista de cosas que otro idioma ya ha hecho lo suficientemente bien.

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

• Emacs Lisp: uso constante desde los años 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: Finanzas (Llamemos a estos funcionales, por el bien del argumento)
• Common Lisp: "AI" - Esto es para lo que la gente tiende a decir que se usa, lo cual es una bendición y una maldición.

Ahora, el único idioma principal que siento que he dejado fuera de esta discusión es Python. Python ha hecho algo muy interesante; Ha tenido éxito sin parecer ser el ganador en ningún nicho importante. Esto podría significar que estoy completamente equivocado al ver la popularidad del lenguaje de esta manera. También podría significar que un lenguaje lo suficientemente bueno puede volverse popular sin una aplicación asesina para impulsar la adopción y la aceptación, pero es muy difícil y puede llevar mucho tiempo. (Perl tiene una historia similar, pero llegó unos años antes 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, estos días) - JVM sin Java

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

Por la misma razón por la que Lisp nunca se dio cuenta (¡que comiencen las guerras de llamas!). 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, comenzó con C y avanzó a C ++ / Java, tiende a no querer aprender a pensar de una manera completamente ortogonal a la forma en que normalmente piensa.

Consideremos negocios y programación.

Hay empresas que usan su software como un activo estratégico. Esto no es típico. Para la mayoría de las empresas, TI es algo que respalda los negocios reales 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 va bien, y perderán mucho si todo sale mal.

Además, en las empresas, lo más barato es lo que hicieron ayer. El cambio, sin embargo, deseable, es costoso. Si una empresa cambiara, por ejemplo, de una solución C # / .NET, incluso a F #, tendrían problemas. Sus programadores (que probablemente no sean los mejores programadores) tendrían que aprender un nuevo idioma y ser competentes en 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 costoso.

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

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

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

Cuando se requiere que realice pruebas unitarias para su código, tiende a escribir funciones comprobables, que no crean ni dependen de los efectos secundarios, y siempre devuelve el mismo resultado en los mismos argumentos (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 funcionales, los lenguajes imperativos obtendrán características funcionales. Hoy en día casi todos los lenguajes de programación tienen cierres y lambdas.

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

Aquí está:

• Los arquitectos de software proporcionan soluciones en las que confían 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 confían en el uso de lenguajes funcionales se están convirtiendo en arquitectos y eligen usarlo para los proyectos en los que trabajan.

El verdadero problema 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 se representa un libro mayor o un conjunto de transacciones) incluso si algunas funciones a pequeña escala no lo requieren realmente (procesamiento de un libro mayor).

Pero estamos ejecutando código en máquinas de arquitectura Von-Neuman que son inherentemente completas. 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 escena y administrarlo.

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

Entonces, la pregunta es si 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. Pero las aplicaciones que no se preocupan por caer en la trampa de agotar el hardware cuando la presión de la memoria se vuelve intensa (agitar el hardware 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 manejen esto bien.

En el lado inverso de la moneda, el programador de estado completo tiene control directo sobre el estado y, por lo tanto, puede compensar las condiciones de poca memoria. Aunque no he visto 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. Lanzas a un equipo de desarrolladores al problema de que pueden 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 estamos viendo cómo las aplicaciones manejan el estado subyacente de manera eficiente aquí, no la mejora general del programa).

Entonces, para la industria, creo que se trata de la capacidad de medir las mejoras en el código.

Desde una perspectiva de contratación

Hay muchos programadores con 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 entraría en acción si la industria cambiara a una programación de estilo funcional y eso no es algo que quieran que suceda (los programadores son lo suficientemente caros como es).

Esta pregunta tiene una premisa ligeramente incorrecta. Por las siguientes razones:

1. La programación funcional es bastante común en la industria. Pero solo se usa donde 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 tratarán con 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) realmente no pueden pedir experiencia en programación funcional. Cualquier persona en proyectos que requiera programación funcional ya ha estado en la misma compañía durante 15 años.
3. Las universidades están comenzando a enseñarlo, porque ya saben que el conocimiento de programación funcional será muy útil en 30 años. Su rango de tiempo es de 30 años, no el medio año normal como en las empresas.
4. Estos puntos son la razón por la cual las personas se decepcionan 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 eventualmente será útil, es solo que las empresas están usando las cosas simples, las cosas que pueden esperar que la gente sepa.
5. También sería arrogante si piensa que después de unos años de universidad, conoce la programación funcional lo suficientemente bien como para usarla en proyectos de software reales. Comience desde las cosas simples primero. Realmente no necesita hacer el software más complejo como su primera tarea cuando comienza a trabajar. Eventualmente llegarás a las cosas complejas, pero lleva tiempo.

Porque es más difícil depurar FP.