Category Archives: Programación

El futuro de la programación

En los comentarios de hace unos días Amnio comentaba los problemas a los que se tiene que enfrentar cuando programa. Cuando tarda horas en detectar un pequeño fallo absurdo que afecta paralelamente a todo el sistema haciendo que no funcione. Este ha sido uno de los grandes problemas de la programación y creación de software desde sus inicios que nunca hemos logrado solucionar. Todo lo que se ha conseguido han sido parches que no han conseguido solucionar realmente este problema endémico.

Los gurús de Sun Microsystems trabajan a día de hoy pensando en como solucionar el problema de los bugs incontrolables cuando estamos trabajando con grandes proyectos. Dos de los mejores artículos que he encontrado por la red son el de Jaron Lanier, critica que no somos capaces de crear software potente sin bugs:

I think the whole way we write and think about software is wrong. If you look at how things work right now, it’s strange — nobody — and I mean nobody — can really create big programs in a reliable way. If we don’t find a different way of thinking about and creating software, we will not be writing programs bigger than about 10 million lines of code, no matter how fast our processors become. [After publication of this interview, Jaron Lanier realized that his sentence should read: “bigger than about 20 to 30 million lines of code…”.]

Pero luego se remonta a los orígenes haciéndonos pensar sobre la verdadera naturaleza de la programación actual. Argumenta que la forma de programar de hoy en día está muy influenciada por los orígenes electrónicos de la informática.

If you look at the way we write software, the metaphor of the telegraph wire sending pulses like Morse code has profoundly influenced everything we do. For instance, a variable passed to a function is a simulation of a wire. If you send a message to an object, that’s a simulation of a wire. And it’s not that there’s anything wrong with this, but I can make an empirical observation: If you have a time-based protocol to send codes on a wire, it’s inefficient to make that kind of coding error-tolerant. It’s much more efficient to make it error-intolerant. So errors tend to be catastrophic. You tend to create a situation where, if you get one bit wrong in passing a variable to a function, the function does something that’s not just wrong, but chaotically wrong, arbitrarily wrong, terribly wrong

Finalmente nos propone librarnos de cualquier influencia anterior que tengamos sobre la informática para poder crear cosas realmente nuevas en este campo.

So, now, when you learn about computer science, you learn about the file as if it were an element of nature, like a photon. That’s a dangerous mentality. Even if you really can’t do anything about it, and you really can’t practically write software without files right now, it’s still important not to let your brain be bamboozled. You have to remember what’s a human invention and what isn’t. And you have to think about files in the same way you think about grocery carts. They are a particular invention with positive and negative elements. It’s very important to keep that sense of skepticism alive. If you do that, it will really have an influence on the quality of code that you create today.

Leeros el artículo entero que vale la pena. En él nos explica como será la programación el futuro, y como cree él que se podrán solucionar los problemas del software. Para continuar si os ha gustado este primero, leed el de Victoria Livschitz que continua hablando sobre el mismo tema. Sobre los problemas de la naturaleza del software, y como sería posible solucionarlo creando un modelo de programación más cercano a la realidad (Más aún que la programación orientada a objetos)

Software is a product of our imagination, like a book, a painting or a movie, designed to synthesize a particular representation of the real world. But unlike all other forms of pure art, software is constructed for utilitarian purposes to do more then merely reflect the real world; software interacts with the world and in many cases even controls it. And what is truly amazing — software is replicable: instantaneously, in arbitrary numbers, at zero cost!

Una conclusión que he sacado yo después de la lectura es que cuando tenemos por ejemplo un programa de 5.000 clases, con montones de relaciones entre ellas es imposible saber los efectos que tendrá un simple cambio, porque se propagará por todo el programa creando efectos secundarios. La orientación a objetos está mal diseñada en este aspecto y sería mejor crear un nuevo modelo donde las clases tenga entre ellas otro tipo de relaciones diferentes a las clásicas “Is a” y “Has a”. Pero ¿Como hacerlo? ¿Como eliminar el problema de los bugs y la manutención del software?, si encuentras la solución serás uno de los informáticos más importantes de la historia. ¿No sería mejor crear un nuevo método de programación más cercano al pensamiento humano y adecuado a la potencia de las máquinas actuales?


Java y C#

La verdad es que no estoy en contra de ninguno de los dos lenguajes. Pero voy a criticar ciertas cosas de ambos. C# ha copiado inteligentemente muchos de los conceptos que se idearon con Java en cuanto a una programación orientada a clases elegante pero también es verdad que han introducido nuevas cosas para hacer más agradable el trabajo del programador. Una de las cosas que más me han tocado las narices de Java son los casts (supongo que otros compartiran este sentimiento y se habrán facilitado las cosas con Java 1.5). Me refiero a cosas como esta (El código funciona compilando con Java y C#, que casualidad 😉 :

   String cadena=”22″;
    int numero=Integer.parseInt(cadena);

¿Para qué usar un método estático? No sería mejor algo más intuitivo que lo siguiente:

   String cadena=”22″;
    int numero=cadena.toInt();

Supongo que en Java 1.5 esto ya estará solucionado de la forma que comento. ¿Pero no sería incluso mejor poder hacer esto?:

   String cadena=”22″;
    int numero=cadena;

Y que el compilador se encargue de hacer el cast automáticamente si es que se puede. Esto que comento es la eterna discusión entre los lenguajes que te permiten un control total tipo C, a lenguajes restrictivos como Java. Yo pienso que un lenguaje muy restrictivo crea programadores malos porque no saben realmente lo que están haciendo. Por otra parte si el compilador “se lo traga todo” sin avisar haciendo casts a lo bestia puede dar lugar a bugs difíciles de detectar. Lo ideal creo que es poder el escoger el nivel de restricción. ¿Qué pensais que es mejor, que el compilador haga lo que tu quieras (C,C++ …) o hacer lo que te mande el compilador (Java, C# …)?


Bruce Eckel


Todo programador Java conoce a Bruce Eckel y sus libros que se pueden encontrar de forma gratuita en la Web. Resulta que ayer paseando por la Fnac vi que ya venden su libro más famoso por 45 euros, lo cual es un precio razonable por unas 1400 páginas y un CD. El título del libro es “Pensando en Java” y lo edita Prentice Hall. Ya era hora de que lo editaran en España, hace 3 años lo ví en las estanterías de una tienda de libros de Canadá. Como siempre aquí vamos unos años por detrás del resto del mundo.
Además me he enterado de que el autor tiene un blog en el que expone su perspectiva actual de Java, .NET etc. También está escribiendo un Libro nuevo sobre J2EE del cual os podeís bajar una versión de borrador que ya está bastante avanzada. Para los que queráis iniciaros en Java Enterprise está realmente bien. Explorando por la web os podéis bajar otros libros entre los cuales están los famosos Thinking in Java y Thinking in C++.


Java 1.5 Beta


Ya está disponible la nueva versión de Java en forma de beta para bajar. Supuestamente va a ser una revolución, yo espero lo mejor de esta versión. Teneis más info en Java Sun y para enteraros de las noticias del mundillo y ver fotos geeks como la de este post lo mejor es Java.Net. Donde podeis encontrar los weblogs de los super-gurús de Java. Mi blog preferido es el de James Gosling el creador de la tecnología java.