Estuve entretenido en un largo chat con Gemini discutiendo algunas de mis ideas y experiencias sobre lenguajes de programación y sus características. Hablar con la IA acerca de programación es como hablar con un traumatólogo de esguinces, creo que tienen el mejor conocimiento disponible.
Transcribí el chat en este documento donde revisamos las grandes tendencias y los conceptos en la historia de la computación, junto con algunas de mis ideas y dudas sobre diversos asuntos. Si les interesa la programación pueden leerlo aquí, a mi me pareció una conversación fascinante. Solo faltaron las piscolas
Microsoft mató al VB6
He estado viendo muchos videos sobre el Visual Basic 6.0, que Microsoft descontinuó oficialmente su entorno de desarrollo (IDE) el año 2008, es decir hace la friolera de 18 años. Pero se les podría decir perfectamente eso de "Los muertos que vos matasteis, gozan de buena salud".
Porque son miles las aplicaciones escritas en VB6 y están en plena producción en negocios, consultas médicas, notarías. municipalidades, en fin, levantas una piedra y aparece el VB6, Y para qué hablar del Visual Basic para Aplicaciones, que no han podido matar y sigue en el Office.
Si no me creen pueden probarlo desde cualquier documento de Word, hoja de Excel o lo que sea, presiones simultáneamente las teclas Alt F11 y se encontrarán con la sorpresa: la IGE de VBA, ni más ni menos
Tipo Fortran y tipo Pascal
Yo conocí esta historia muy de cerca y de primerísima mano, porque usé el Visual Basic 1.0 que venía para MS-DOS y todavía traía el aviso de copyright con el nombre de Alan Cooper, que fue su inventor. Desde esos años empecé a migrar mis programas en Qbasic, debe haber sido el 92 o 93.
También tuve muchos amigos programadores que trabajaron con Turbo Pascal y Delphi las dos herramientas de Borland que usaban lo que yo llamaría el "paradigma Pascal" del que después salieron C, C++ y Java, entre otros.
Desde principios de los años 80 los lenguajes de programación se bifurcaron en dos grandes corrientes, los que eran del "tipo Fortran" con listados lineales de instrucciones y los que eran "tipo Pascal" con módulos encerrados entre corchetes. Y se llenó de discusiones sobre cual era el mejor enfoque.
Las guerra santas
Los argumentos de esas guerras santas siempre me parecieron muy chantas. Los lenguajes tipo Pascal se tomaron rápidamente la academia, recuerdo que mis amigos que estudiaban ingeniería en computación miraban con desprecio a los lenguajes tipo Fortran, recitando lo que sus profesores les habían indoctrinado.
Recuerdo bien los argumentos que se daban para descalificar el Visual Basic y para endiosar el C++ el Java y otros por el estilo que tenían la misma estética de los corchetitos. Siempre tuve la idea que eran discusiones bizantinas, ideológicas y se reducían a alabar exageradamente lo que ya sabíamos y atacar lo que no dominábamos.
Pascal en la Academia, Basic en la calle
Peleas estériles. Mientras en las universidades e institutos se desterraba el Basic como un lenguaje "poco profesional", en el mundo real dos de cada tres programas de aplicación estaba escrito en Visual Basic. así, el recién egresado perdía 5 o 6 años sin aprender lo que muchas veces tendría que usar.
Eso fue una consecuencia del desconocimiento casi total que tenían los profesores de computación sobre la programación de aplicaciones. Muchos ni siquiera sabían qué era eso y que el mundo de la programación era dividido.
Programación de aplicaciones vs de sistemas
Por un lado estaba la programación de aplicaciones: sistemas relativamente pequeños para solucionar problemas muy específicos como inventarios, cuentas corrientes y toda clase de aplicaciones de control y gestión que no se adaptaban a requerimientos estándar.
Hubo y todavía hay miles de programadores que escriben aplicaciones en VB o VBA, pese a que el primero está descontinuado hace 18 años; Comercio, consultorios, municipalidades y muchos por el estilo con necesidades demasiado específicas para usar grandes paquetes estandarizados como el SAP.
Por otra parte existe la programación de sistemas, mucho más grandes y complejos que necesitan lenguajes restrictivos, muy rígidos, con un manejo de la memoria en profundidad y seguros por diseño. Ese es otro mundo on características muy diferentes.
Programadores independientes vs obreros del código
La programación de aplicaciones se puede hacer por grupos pequeños que son relativamente fáciles de coordinar. Incluso todavía hay aplicaciones que las puede escribir una sola persona con algunos cientos de líneas.
La programación de sistemas pueden trabajar cientos y hasta miles de personas cubriendo los diferentes roles: programación, prueba, documentación, coordinación, etc. Mantener un control de versiones ordenado se puede convertir en una pesadilla, para eso existen herramientas como GIT.
Si las universidades se hubiesen mantenido "como antes" con profesores prácticos junto con los master y doctores que jamás hicieron otra cosa que estudiar y hacer clases, se habrían dado cuenta de esta diferencia y se habrían evitado generaciones de ingenieros en computación trabajando en Uber.
Hoy los programadores son tan indispensables como antes, solo que cada vez necesitan escribir menos líneas de código, buena parte de ese trabajo sucio lo hace mucho mejor la IA. ¿Para qué se necesitan entonces?
Para lo más importante: tomar un problema y transformarlo en una petición precisa para la IA y luego ir probando y refinando. Yo dejé de programar hace más de 15 años pero con ese método pude hacer programas de data scraping que en condiciones normales, jamás habría podido hacer. Gracias IA.
La venganza de Basic
Ahora si, después de muchas vueltas y revueltas el viejo y despreciado Basic ha vuelto en gloria y majestad. Hoy se llama Python. lo promovió nada menos que Google y debe ser el lenguaje dominante en el desarrollo de aplicaciones. Por fin se dieron cuenta después de décadas.
Basic y Python son prácticamente idénticos, aunque Python es un lenguaje moderno que admite la orientación a objetos, el encapsulamiento y todo eso, en estilo y estructura son iguales, yo estaba programando en Python en un par de minutos y hasta escribí Aprenda Python en tres días, que ha recibido varios miles de visitas, especialmente de India
Python tiene -en mi opinión- una sola diferencia importante que son las esctrictas reglas de indentación, que debe ser lo más difñicil de dominar.
También en mi antiguo sitio El Programador Casual, que dejé de actualizar el año 2001, coloqué dos pequeños ensayos que 25 años después, creo que siguen teniendo vigencia.
Uno fue el El Programador Hereje y el otro se llamaba Computadores que se equivocan, un artículo escrito hace muchos años por Claudio Gutiérrez donde decía que las computadoras empezarían a ser inteligentes recién cuando tuvieran la capacidad de equivocarse.
Ha leído el caso de Margaret Hamilton? se murió hace poco y por tanto la homenajearon. Fue programadora jefe de la NASA y su obsesión era no producir un "bug" que se revelara en mitad de un vuelo a la Luna, digamos. Creo un "Universal System Lenguage" (USL) del cual nunca había oído hablar. Su interés era que el programador probara todo lo que se pudiese de que cada línea al momento de escribirla y que no fuera posible avanzar con el error puesto. Fuera de esta definición, no tengo la menor idea de cómo lo hacía. Uls
ResponderBorrarSI, el código fuente del Apolo 11 está publicado en Github y se puede leer en
Borrarhttps://github.com/chrislgarry/Apollo-11/blob/master/README.md
Los programas están escritos en Assembler, es increíble revisarlos porque aparece la forma antigua de programar con nombres de variables y comentarios divertidos donde los programadores colocaban su "firma" de manera camuflada.
Entiendo que lo que estableció Hamilton fue un procedimiento o metodología que ahora debe ser estándar en la programación de tareas críticas que consiste en probar para cada módulo de código todos los posibles errores humanos en la operación de la consola (apretar teclas cambiadas y cosas así). COn todo esa metodología no fue infalible, tengo entendido que en el Apolo 11 y en otra misión posterior el sistema no respondió bien a una equivocación al momento de alunizar y la cosa casi terminó en desastre.
El programa Apolo fue suicida por el límite de tiempo que puso Kennedy, fue un milagro que no ocurrieran más tragedias