¿Por qué muchos programadores piensan que FP es casi solo para investigadores? ¿Por qué no se dan cuenta de su poder para mejorar el desarrollo de software convencional?

En la década de 1990, la mayoría de los programadores pensaban que la recolección de basura era solo para investigadores y no entendían su capacidad para mejorar el desarrollo de software convencional. Luego, Java desplazó a C ++ como el lenguaje de programación más común para nuevos proyectos.

En la década de 2000, la mayoría de los programadores pensaban que el polimorfismo paramétrico (también conocido como “genéricos”) era casi solo para investigadores y no entendían su capacidad para mejorar el desarrollo de software convencional. Luego, C # trajo genéricos a las masas sin lavar y Java lo copió, por lo que la gran mayoría de los programadores del mundo comenzaron a usar genéricos a diario.

En la década de 2010, la mayoría de los programadores pensaban que la programación funcional (cierres léxicos de primera clase y llamadas de cola) era casi solo para investigadores y no entendían su capacidad para mejorar el desarrollo de software convencional. Para 2016, todos los lenguajes de programación convencionales ofrecen características funcionales como lambdas en C #, Java e incluso C ++.

Esto se debe a que la mayoría de los programadores son luditas: no quieren aprender nada nuevo y no pueden molestarse en modernizarse.

Escribo lo que podría considerarse software ‘convencional’, aplicaciones de escritorio.

Utilizo FP (como lambdas) en mi trabajo de manera bastante extensa, hacen que muchas cosas sean muy convenientes.

Uso bastante FP, podría ser el 0.5% de la base del código, probablemente menos.

FP es una construcción útil para muchos propósitos, pero no es de uso general como la programación imperativa o la programación orientada a objetos.

La programación funcional es el Python en el mundo de los paradigmas de programación, es:

1. Perfectamente decente.
2. No nuevo.
3. No especial.

Sí, FP * mejora * la programación para mí y * ha * mejorado mi vida como programador, pero OOP aún más. Sé que es blasfemo, pero como programador que trabaja en el mundo real, es la verdad.

FP ha mejorado mi vida como programador, pero también tiene unos auriculares decentes.

FP no es mágico, es otra herramienta de programación.

FP realmente mejora el desarrollo de software convencional para mí, y en ese sentido, es una gran característica, y nada especial.

Cuando dices “muchos programadores”, ¿estás hablando de programadores del mundo real que no están de acuerdo con los programadores del mundo real acerca de la programación del mundo real? Eso podría decirte algo.

Probablemente dice algo que tuve que buscar en Google para darme cuenta de que querías decir ‘programación funcional’ en lugar de programación procesal.

Para mis propias prácticas de programación y trabajo de producto, encuentro que la programación funcional es confusa y difícil de razonar cuando se vuelve compleja. Incluso estando expuesto en la escuela de posgrado por problemas relativamente pequeños, no me gustó.

Los lenguajes funcionales / de procedimiento híbridos como F # parecen ser más prometedores, ya que ofrecen algunos de los mejores de ambos mundos. He visto cosas increíbles en F #, aunque es difícil separar cuál es el programador y cuál es el lenguaje para esa muestra.

C ++ parece estar evolucionando, por lo que puede admitir una programación de estilo funcional para aquellos que * realmente * quieren usarla. Vi algunos en Google, y aunque era francamente compacto, era confuso como el infierno. C ++ también le permite escribir lenguaje ensamblador en línea, no llamaría su inclusión de una característica un respaldo de su atractivo principal.

Si comenzara un nuevo producto, elegiría un lenguaje de programación de procedimientos para escribirlo, punto. En mi experiencia, el programa funcional no proporciona suficientes beneficios para compensar el golpe de adoptarlo.

Para mí, la programación funcional es como elegir hacer lo mejor, genial, para resolver realmente algo. Algunas personas dicen “en el mundo real, la gente nunca lo intentaría, porque están acostumbrados a pensar de cierta manera”, o “Si intentas resolver un problema en la PF, te dará dolor de cabeza, así que hagámoslo”. como siempre hemos estado haciendo “. No me gusta este tipo de “¿por qué tratar de ir allí, si estamos luchando para resolver los problemas aquí?”. No podemos usar como argumento no usar FP porque ya somos demasiado adictos a nuestros “juguetes” actuales. Si todos los programadores intentaron estudiar profundamente a Haskell, por algún tiempo, hasta que entiendan por qué tiene sentido usar curry, funciones de orden superior, combinar contextos con mónadas y todas las matemáticas detrás de esto, estoy seguro de que las respuestas de la mayoría de ellos a esta misma pregunta, serían inmensamente diferentes de lo que responderían hoy.

Alguien dijo una vez que “No hay atajo para la felicidad”, bloquear la FP, para mí, es como tratar de obtener un atajo en lugar de mejorar nuestra comprensión … No hay atajo para la felicidad y la PF pura está en esto camino. Como humanos, debemos ser más apasionados en mejorar la condición de todos, incluso cuando el tema está codificando. Esta es la razón por la que hay tanta depresión y personas desesperadas en el mundo: nunca podemos dejar que la esperanza de hacer las cosas bien muera. Si nos damos cuenta de que algo está mal o simplemente no es suficiente, es porque tenemos el poder, aunque sea a veces indirectamente, para resolverlo.

Tal vez muchas corporaciones (léase: gerencia media) se sienten de esta manera, pero muchos programadores tienen al menos un lenguaje de programación funcional (Haskell, Scala o Scheme) en su lista de lenguajes favoritos. Sin embargo, muchos programadores suelen decir que les resulta difícil descubrir cómo dar un buen uso a un lenguaje como Haskell en un entorno de producción.

No sabía que “muchos programadores” se sintieran así …

De cualquier manera, la programación funcional es solo un patrón de diseño, nada más. Algunos patrones de diseño son más fáciles de entender para ciertas personas y más efectivos para resolver ciertos tipos de problemas. Solo me enfocaría en usar lo que sea que funcione para usted como individuo, y cuando esté en un equipo, siguiendo el patrón que el equipo decida.

En cuanto a discutir sobre qué patrón es mejor, creo que es una pérdida de tiempo. ¿Por qué alguno de ellos tiene que ganar, de todos modos? Para algunas personas, la programación funcional es una experiencia agradable, pero no todos los programadores pueden ver sus beneficios, ni les importa intentarlo, ya que el procedimiento parece funcionar perfectamente bien para ellos. Yo no me preocuparía por eso.

Podrían estar cansados ​​de que todos los hackers inconformistas reflexionen sobre lo increíble que es FP …

Eso o el hecho de que la mayoría de los desarrolladores piensan de manera imperativa y procesal. FP es una forma realmente diferente de pensar y escribir código que la mayoría de los desarrolladores están acostumbrados. ¿Por qué invertir tiempo en él cuando hay tantos otros problemas laborales y las nuevas tecnologías que demandan su tiempo?