Se te quedas en la base y no pasas de 4 chorradas, claro, pero las abstracciones matemáticas no las pilla el Copilot o el ChatGPT si no se las das bien mascadas.. A ver como carajo, si no, te sale con una solución doble de monada Eff y profunctor abstracto con composición de funciones de high-order ante un problema de transcompilación de una expresión escrita en el lenguaje A a otra en el B. Cosa bastante frecuente en el mundillo web, donde las transcompilaciones están a la orden del día.
Nada que ver con las rutinas que hacen los javeros y pythonero, trivial de comprensión para que el GPT entienda los requerimientos de hasta un pacoPaliller de carnicera: " psss ejque necesito un cliente que me haga la siguiente request a una BBDD en azure con C#". y La maquinita te sale con una solución CRUD en unos segundos que deja en el paro a todos los picatecleros Cchaperos de la carnicerita.
Pues lo obvio,lo que ya se ha repetido hasta la saciedad desde Dijsktra, Knuth, etc que la programación es un campo aplicado de las matemáticas, y que por tanto la corrección de un programa debe ser probada matemáticamente. Porque si no, no se hace programación, sino tomarle el pelo a la gente programando sencilladas que valen para lo que valen, para ganar dinero engañando al prójimo.
Así que lo primero saber de álgebra, teoría de grupos y categorias y esas cosillas para entender lo que es demostrar que el programa que hagas va a ser correcto antes de darle al run o que no casque de manera imprevista 1 mes después. Qué tipo de programación permite esto, pues la que tenga detrás una prueba matemática (funcional, declarativa y parte de la procedural con el formalismo de los triples Hoare) . La OOP desde luego no, carece de toda prueba matemática que evite pegarse tiros en la cabeza todo el rato. Mira tú por donde, es precisamente la fruta hez que causa furor en las corporaciones y empresas , la fruta hez esa de la OOP.
Desde luego donde hay sistemas críticos, a nadie se le pasa por la cabeza hacer OOP. EL llamado mercado informático, es por eso en su inmensa mayoría un chiringuito vendeburras que no hay por donde cogerlo.
Debes ser programador de Haskell por tu retórica.
Pero te equivocas mucho con Java. Entiendo que durante las primeras language wars, Java era un lenguaje bastante punto medio en todo, con poca evolución, extremadamente lento, inconsistente, etc. Y que los Ansi Ceros, Haskellianos, Pythonianos etc.. le colgaron esa etiqueta y queda muy de moda decir algunos tópicos porque da rabia que sea el elegido como estándar para la programación web. Pero es un lenguaje que cuando iba a morir se puso las pilas, y ahora mismo tiene una de las mejores supervisiones y grupos de revisión del mundo, con actualizaciones constantes y mejorías muy notables. La JDK es alabada por muchísimos entendidos, más allá de que programen en Java o no, y los últimos frameworks son top-notch y con un mantenimiento y evolución mezcla de comunidad y privado exquisito. Es verdad que el core del lenguaje mantiene alguna limitación, pero se reinventa día a día (la última son los virtual threads, que se van a cargar la programación reactiva seguramente, por permitir las operaciones non-blocking al estilo event loop de js).
Java tiene mónadas, high-order functions, te puedes montar un profunctor o importar algunos de librerías desde la JDK8 del 2014 (y sealed types desde la JDK15, aunque con lombok ya lo usaba todo el mundo desde hace eones). Es más, son el pan de cada día desde hace al menos 7 años. En Java el paradigma funcional es la norma desde hace mucho tiempo, y todos los developers que se precien trabajan intentando mantener la mutabilidad al mínimo o 0 directamente, incluso Spring se basa en intentar hacer todo stateless, hasta el punto que se considera un code smell. Las funciones deben ser puras y nunca debes meter side-effects. Java tiene una comunidad muy muy grande de Clean Coders y Software Craftmanships. Sí, el sistema de tipado no es perfecto ni es irrompible a extremos TOC como el de Haskell (que en un diagrama con 8 o 10 ejes de las dimensiones típicas de programación, Haskell sería el representante extremo de entre los infinitos que existen), y no está limitado al paradigma funcional al 100%, aunque tienes otros lenguages sobre la jdk de java dedicados a ello (clojure, scala), pero en una escala del 1 al 10, si metes todos los lenguages de programación del mundo, Java es un 9 en funcional, un 9 en OOP y un 9 en tipado.
No entiendo que te pasa con OOP, es un paradigma completamente ortogonal al funcional. OOP no implica mutabilidad en ningún momento, se puede perfectamente combinar ambos paradigmas. OOP es útil para modelar de un modo más semejante a la mente humana (encapsulación, polimorfismo, composición de objetos), por eso ha triunfado. Para mí mezclar los dos es lo ideal. Tratar cada línea de un programa como si fuera una expresión matemática con mil nombres y conceptos abstractos está muy bien, y Haskell tiene que ser curioso y te debes sentir en cada línea como si estuvieras haciendo un examen de 3ero de exactas, pero por lo general los códigos que se necesitan deben responder a necesidades de negocio, y por eso se modelan como tal. Y sí, la filosofīa de base no es fundamentada en el talibanismo desde el bajo nivel de prohibir cualquier tipo de cagada de tipaje que se coma el compilador, o de mutabilidad vulnerable a concurrencia, pero tampoco es un lenguaje totalmente permisivo y tiene mil herramientas para programar en tu filosofía. Porque lo que no le quita nadie a Java es que esté en el top 3 de lenguajes con más librerías disponibles.
Para que quieres transcompilar funciones high-order etc.. Lo que la mayoría de iniciativas empresariales requieren son servicios online a usuario final, SAAS, producto interno. Quieren desarrollo rápido, leíble y escalable, y Java es un lenguaje cojonudo si pillas a gente con experiencia para eso, como lo es Javascript etc (que aún son más lejanos a la filosofía de Haskell por lo general). Me gustaría ver que pasa si coges una charcutera, pagas 20k a 20 tíos recién salidos del horno, y les pides hacer un código en Haskell o Erlang. Pasaría lo mismo que criticas con Java. No es el lenguaje, es el programador. Go está diseñado con el paradigma funcional en mente y es una escabechina igual porque es reclamado en entornos con una cultura donde a menudo se contrata a gente que no son experimentados.
En proyectos Java serios, con tests bien hechos, se puede salir a producción sin un solo bug reportado en meses.
Y asumo que estás a favor de los tests, al menos los e2e/integración, porque eso va más allá de que el código falle, hoy en día son necesarios para. asegurar que se cumple un contrato determinísticamente, y que puedes refactorizar cualquier cosa sin temor a que cambie (precisamente un proyecto grande, complejo y con muchos requisitos funcionales, se requiere de varias personas, y en ese momento es donde no puedes de una sola que tenga todo el contexto de requisitos y arquitectura del código en la cabeza). Lo puedes hacer cuan determinísitico desees, pero obviamente cada lenguaje tiene su nicho, y a nadie se le ocurriría programar la necesidad más ultraperformant a nivel de milisegundo o el firmware más low-level en Java (y hasta Minecraft, videojuegos), por ejemplo; y si te prima que el lenguaje sea ultraultraparanoico hasta el punto que te haga programar de una manera antinatural o poco intuitiva para asegurar al 99.99% que no permita un error del factor humano = programador porque vidas humanas dependen de ello, pues entiendo que no se escoja, pero no es el caso de la mayoría de iniciativas. Y aún así, la puedes soltar igual, porque siempre puede suceder un "pensaba que me habías dicho que tenía que hacer esto"
De todos modos, comparar lenguajes no me parece fácil, creo que se necesita mucha experiencia y uso avanzado de uno para poder dar una opinión autoritativa, solo por la cantidad de apis, frameworks y experiencias en producción en proyectos grandes, y es muy difícil que alguien trabaje a ese nivel con dos lenguajes no-complementarios como para compararlos. Yo he programado también en Ensamblador, Visual Basic, Ansi C, C++, Perl, PHP, JS, pero en distintas épocas, y ahora mismo no tengo ni idea del estado de las cosas de ninguno de estos, ya no trabajo en el sector, aunque sigo jugando con el Java a título personal de vez en cuando