Barrapunto

¿Por qué? Me dirás por el rendimiento, pero muchas veces el rendimiento no es lo más importante. ¿Debemos sacrificar la coherencia (tener tipos primitivos y objetos en Java) por velocidad? ¿La seguridad y simplicidad?

Lo de que los lenguajes de alto nivel están reñidos con el rendimiento es una etapa que me gustaría que se pudiera superar ya de una vez.

Esto era cierto en la época de las arquitecturas Von Neuman puras, cuando los lenguajes de alto nivel eran bastante primitivos, y las arquitecturas de los ordenadores eran simples.

Actualmente, las arquitecturas son tan complejas (pipelines, cachés, procesadores RISC) que sólo un programador especializado en eso, les saca todo el jugo programando a bajo nivel. Y no digamos con las futuras arquitecturas cuánticas y esas cosas, como dice alguien por aquí abajo.

Eiffel está diseñado desde el principio con esta idea: que el programador se ocupe de crear un código lógicamente bien estructurado, y dejar la tarea de optimización a los creadores del lenguaje, el compilador y las librerías.

Lo de los efectos secundarios ya es más complicado. Dado que tratamos con ordenadores que tienen 'estado', es natural que los funcionales no acaben de encajar; esto es, hacer I/O, acceso a bases de datos, etc... no me acaba de encajar en un lenguaje funcional. Vi lo de las mónadas de Haskell y casi me explota la cabeza.

Siempre he imaginado un lenguaje dual imperativo/funcional... parte imperativa donde sea necesario y un interfaz limpio con la parte funcional que lleva toda la lógica.

Es que Eiffel es justamente eso, si lo usas tal como explica Meyer en sus libros. Yo he tenido largos debates con mi hermano, que le dio bastante al Haskell en su día, y llegamos a esta conclusión. Siempre que se pueda, programa en modo funcional. Y cuando haya que manejar estados, los encapsulas en una clase y los modelas como una máquina de estados o autómata regular. De esa manera, están formalizados y no se descontrolan como ocurre de otra manera.

Programando así, en teoría se podría hacer un compilador que hiciera las cositas curiosas de Haskell, pero con objetos.

¡No! Un lenguaje no es igual para todas las aplicaciones. Acabas con monstruosidades como el C++, que tienen de todo; el lenguaje en sí está muy bien, pero todos los desarrolladores de C++ hablan dialectos diferentes. Mejor lenguajes pequeñitos para propósitos limitados.

Sin embargo, un lenguaje bien hecho, modular y flexible, pero simple, con buenas librerías y herramientas, puede ser muy versátil. O quizá la combinación de dos lenguajes, uno de bajo nivel (el C) y otro de alto (Eiffel o Python).