Unos consejos para los interesados en programar (bien)

Programar es fácil, programar bien es muy difícil. No hay que engañar, que luego abandonan decepcionados a la primera complicación. Problemas complejos + estructuras complejas requieren dominio de algoritmos básicos fundamentales, y conocer la complejidad de cada uno.

[#201 frankiegth]

Para #135. Te sorprenderias de lo que algunos ingerieros de software hacen con lenguajes funcionales.

Con un lenguaje funcional a nivel profesional puede modificarse el código en tiempo de ejecución sin tener que parar ni servidores ni servicios, como lo oyes.

En una presentación que realizó el ingeniero de software jefe de una empresa nórdica nos enseñaron como cogian una porción de código funcional, y desde el mismo copilador/editor, con un simple comando se visualizaba el código ensamblador que esa porción de código generaba. Como las funcionalidades en lenguajes funcionales tienden a generar un código muy compacto el código ensamblador generado también lo era y eso les servía para intentar optimizar el propió código ensamblado o incluso para detectar errores.

Nos explicaron que su empresa inició un proyecto online cliente/servidor/web que temporalmente pretendian implementar con LISP, un lenguage funcional, para al mismo tiempo reimplementar el proyecto definitivo orientado a objetos con lenguages convencionales, por alguna razón les salia a cuenta hacerlo así. El caso es que la implementación funcional acabó funcionando tan bien que decidieron dejarlo todo como estaba y era la versión que mantenian y desarrollaban actualmente. Lamentablemente no recuerdo el nombre de la empresa, pero creo recordar que tenía cierta relación con temas bursátiles o algo relacionado.

Los lenguages funcionales no son un juguete y van camino de integrarse internamente en los compiladores de lenguajes orientados a objetos.

[#202 musg0]

#201 Te agradezco el mensaje, pero no he dicho que los lenguajes funcionales fueran de juguete, sino que Racket en concreto me parecía un entorno de juguete, como Logo, que para aprender está muy bien pero luego no aparenta ser potente para un uso en proyectos reales.

Con respecto al paradigma funcional, me pareció que con tanta recursividad y tener que aprender patrones en la creación de funciones para que todo encajara la programación se complicaba y necesitabas amueblar muy bien la cabeza antes de programar algo serio.
La programación imperativa parece más obvia y parece permitir más trucos y hacks, por lo que cualquier programador mediocre puede salir del paso aún haciendo chapuzas.
En programación funcional me pareció que esos trucos no eran posibles y si no entendías realmente lo que estabas haciendo te metías en un pozo del que no podrías salir.

Creo que en el entorno empresarial no ha funcionado el paradigma funcional porque no puedes meter a programadores malos, que harán mal código pero tiran líneas y cobran poco, ni puedes tener a juniors aprendiendo durante un mes cosas relativamente básicas sin ser minimamente productivos.

También me ha dado la impresión a veces de que con tantas funciones genéricas que llaman a funciones y pasan los datos a otras funciones que los vuelven a procesar y pasan los datos a otras funciones como no documentes muy bien lo que haces, el código es de sólo lectura y que aunque pueda parecer muy elegante luego no hay dios que entienda lo que quería hacer el programador.

[#203 frankiegth]

Para #202. Racket es un entorno que se usa en universidades, y creo que está pensado en buena medida para experimentar con los lenguajes funcionales. Tengo constancia de que existen entornos profesionales del lenguage LISP que pueden abarcar cualquier proyecto profesional de software. Aquí un ejemplo : www.lispworks.com/products/lispworks.html

En mi experiencia de un semestre con Racket puedo resumirte que fue lo que entendí y aprendí. Una vez que se dominan los conceptos generales y el formato del lenguaje es sí se entra en una dinámica en la que como programador te da la impresión de que no programas tu sino que está programando la estructura del propio lenguaje y como programador te limitas a que todo encaje para que cumpla con su cometido. El premio es que se optiene un código extremadamente compacto y una solución final a un determinado problema que suele ser muy óptima.

Entendí que con un lenguage funcional determinadas funcionalidades de determinadas estructuras de datos podian terminar siendo incluso más fáciles de programar y casi a prueba de errores. Entiendo que la idea en un futuro muy próximo será enlazar ciertas prociones de código funcional con el resto del código orientado a objetos, aunque un lenguaje funcional por si solo permite sacar adelante cualquier proyecto, para introducirlo en las empresas probablemente opten por la mezcla de paradigmas de programación.

[#204 musg0]

#203 Quizás con algo tipo Scala o Clojure veamos programación funcional en las empresas. Se supone que con el paradigma funcional es más fácil paralelizar. Quizás por ahí sería una punta de lanza, y aunque no se use para un proyecto completo, quizás se pueda usar en partes concretas o para implementar algoritmos del núcleo de un desarrollo.
Al estar basados en la máquina virtual de Java, muchas empresas pueden seguir aprovechando lo que ya tienen y no partir de cero.

Por otro lado en juegos casi todos tienen un lenguaje de scripting para la IA de los personajes y ahí también parece que podría ser útil un lenguaje funcional, porque crearía un código compacto y relativamente ligero.