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?
