it-swarm-es.com

¿Por qué la programación funcional no es más popular en la industria? ¿Se da cuenta ahora?

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.

61
Jonas

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!

38
ennuikiller

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 tal carro. 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.

67
Mike Dunlavey

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, los idiomas que do hacen que sea una prioridad (es decir, los idiomas más populares OOP) tienden a robar algunas de las características más geniales que surgen de los más académicos lenguajes funcionales y así mantenerse en la cima.

25
Fishtoaster

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

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

  • Productividad - aprendizaje 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, lo que tiene enormes beneficios para las aplicaciones concurrentes que necesitan ejecutarse efectivamente en múltiples núcleos. Y nos guste o no, correr en múltiples núcleos es el futuro. Ver http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey para 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 complejos OO. Todavía no he descubierto todas las razones para esto, pero parte de esto se debe al hecho de que no tienes toda la "complejidad incidental" que OO modelos arrastran con ellos). on Radical Simplicity 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 OOP que limitan 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. 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.

24
mikera

Falta de aplicación asesina

Hola, este de aquí parece nuevo. (Dig dig Dig)

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 grado, 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: Juego scripting , 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 usado en 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)
  • LISP común: "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 significa que estoy completamente equivocado al ver la popularidad del lenguaje de esta manera. También podría significar que un lenguaje suficientemente bueno puede hacerse 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.

12
Jesse Millikan

Por la misma razón que LISP nunca se dio cuenta (¡que comience la guerra 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.

9
Chinmay Kanchi

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, realizar 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.

6
David Thornley

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 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 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.

2
Calmarius

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.

1
John Fisher

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 vigencia 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).

0
Martin York