- "La programación funcional (FP) es difícil de aprender, pero hará que tu código produzca menos sorpresas desagradables"
- En FP, "less is more"
- Resolver el problema de las referencias nulas (con Maybe/Option)
- FP tiene una curva de aprendizaje pronunciada
- El futuro de FP
- Si queremos desarrollar más con menos desarrolladores, debemos usar todas las herramientas posibles, y FP es el boleto para lograrlo
- A empresas poco glamorosas como la nuestra les cuesta contratar desarrolladores. Pero sí es posible contratar desarrolladores de primer nivel que quieran trabajar en una base de código FP
- Adoptar FP mejorará la calidad y la solidez, y reducirá el tiempo dedicado a bugs que en FP no ocurren
- El hecho de que las funcionalidades de FP empiecen a aparecer cada vez más en lenguajes mainstream significa que la industria del software se está preparando para un cambio de paradigma
- Hará falta mucho trabajo para que la industria haga la transición completa, pero como las ventajas de hacerlo son claras, no hay dudas sobre hacia dónde se dirige
13 comentarios
Parece cierto que la curva de aprendizaje es alta. Incluso en los comentarios hay contenido que demuestra que realmente no conocen por completo la programación funcional. Claro, también hay comentarios escritos por gente que sí sabe bien del tema. La programación funcional es difícil; yo también sigo estudiándola todavía. snif snif
Solo cuando aparezcan casos en los que el lenguaje de programación deje de ser una cuestión de preferencia del equipo de desarrollo y se convierta en un asunto de supervivencia para la empresa, podremos volver a hablar de la necesidad de la programación funcional.
Yo lo resumiré. En la gestión de memoria y algunos algoritmos, todavía no supera a la programación orientada a objetos. Se puede usar de forma adecuada según la situación y el costo.
Mmm... no puedo estar de acuerdo con la afirmación de que la curva de aprendizaje sea pronunciada.
Para empezar, simplemente es fácil, hay menos margen para cometer errores y, por lo tanto, la productividad aumenta.
Con eso basta, ¿no?
Es difícil formalizar por completo el pensamiento y el trabajo humanos como hacen los lenguajes de programación funcional pura. Viendo cosas como
free monad, parece querxjsmás o menos es el límite máximo aceptable.Llega un momento en que en FP el costo termina siendo mayor que el beneficio.
Incluso los efectos de FP existentes apenas separan los datos y los métodos,
y con solo ver que
Optionalno se usa tan bien como uno pensaría, la abstracción de tipos parece una abstracción innecesaria (ajustar los tipos termina comiéndose demasiado la productividad).A menos que vaya en una dirección como la de Clojure, abstraer más los datos y las operaciones, hay límites para aprovechar los lenguajes existentes.
La inmutabilidad es solo una herramienta que se usa con frecuencia en el paradigma de programación funcional.
Hasta donde yo sé, el paradigma de programación funcional es un paradigma que busca controlar al máximo los "efectos secundarios" (Side effect).
Al intentar controlar los efectos secundarios, naturalmente se da importancia a cosas como la transparencia referencial, la inmutabilidad y las funciones puras.
En ese sentido, incluso sin usar necesariamente un lenguaje de programación funcional, creo que lo deseable es tener una comprensión clara de los efectos secundarios de las funciones o métodos que uno escribe y poder controlarlos adecuadamente. Esto tiene muchas ventajas, como reducir los malos olores del código (Code smell) y facilitar la escritura de pruebas unitarias.
También hay textos traducidos que explican esto con más detalle.
Desde esta perspectiva, un libro que se enfoca en el refactoring para minimizar los efectos secundarios es Codificación funcional clara y fácil de entender: domar software complejo con código simple. Como aborda el tema desde una perspectiva práctica y orientada al trabajo real más que desde la teoría, vale totalmente la pena leerlo y aprender de él si quieres escribir buen código. Creo que si después de leerlo aunque sea empiezas a prestar mucha más atención a los efectos secundarios al escribir código, el libro ya justifica de sobra su precio.
Gracias, tendré que buscarlo y leerlo.
¡Ah! ¡No sabía que ya había salido la traducción! Tendré que leerla.
¡¡Gracias por la recomendación del libro!! ¡Lo voy a comprar de inmediato y lo leeré!
¡Ese libro es realmente muy bueno!
Desde la perspectiva de la refactorización, también es muy cómodo de usar al escribir.
Por supuesto, también creo que la programación funcional es un buen enfoque, pero parece que no hay mucha gente que logre transmitir sus ventajas de forma convincente. Si solo dicen que es buena, no termina de sentirse tan claro, ¿no?
A continuación va una opinión personal: dado que prácticamente todos los programas modernos están construidos, en esencia, sobre máquinas de Turing, a nivel abstracto pueden dividirse en funciones y datos, y por eso creo que la programación procedimental, en su raíz, también es funcional. Entonces, ¿cuál sería la verdadera ventaja de lo funcional frente a lo procedimental? Pienso que, simplemente, es "no usar variables globales o variables en ámbitos equivalentes". Gracias a esa ventaja, también resulta eficiente para el "aislamiento entre funciones" y para la "computación multihilo".
Pero, si preguntamos si ese beneficio solo puede obtenerse con programación funcional, diría que no. Incluso en lenguajes procedimentales se recomienda el aislamiento a nivel de clases y funciones mediante el concepto de dependency injection (de hecho, todos los frameworks modernos ya lo adoptan por defecto), y en el lenguaje Rust se busca una computación concurrente conveniente mediante restricciones impuestas por el propio lenguaje.
En resumen, los lenguajes funcionales son buenos lenguajes y una buena metodología, pero más que ser "superiores en un sentido evolutivo", creo que son, como Go o Rust, lenguajes que intentan excluir a nivel de lenguaje las posibilidades de fallo, aunque sean difíciles de usar.
¿Quiere decir que incluso en lenguajes procedimentales es posible hacer cosas como la composición de funciones?
Si definimos "composición de funciones" de forma estrecha, podríamos pensar que solo es posible en lenguajes funcionales, pero si lo pensamos bien, su ejecución de todos modos corre sobre lenguaje máquina o ensamblador, que son lenguajes procedurales. Es decir, no es un problema de "posible o imposible", sino de "intereses, preferencias y filosofía del lenguaje". Si ampliamos la definición de "composición de funciones" y la vemos no como "una característica específica de cierto lenguaje", sino como "la composición entre funciones lógicas", entonces es totalmente posible. Y como claramente existen ventajas en los lenguajes funcionales, hay cosas como
rxjsosparkque han adoptado activamente esas ideas.Como todos aprendimos en la carrera de computación, abajo se muestra el mismo resultado; lo único que cambia es la forma de expresión. Y al prefijo muchas veces se le llama funcional.
Notación prefija: + 1 1
Notación infija: 1 + 1
Notación posfija: 1 1 +