Vamos a ver quien me para

Estoy muy cómodo haciendo clases, aunque no me gusta ni me onviene hablando en plata, es divertido jugar al guru por un par de meses, además me refresca recuerdos y conocimientos muy queridos de los años en que empecé a programar.

Comparto con el Dr. Chuck esa idea de que la programación es una actividad creativa y fascinante, sin embargo es el único profesor universitario de computación que he conocido que piensa así, la mayoría de los profesores son unos verdaderos brutos que reproducen su ideología nefasta sobre generaciónes de estudiantes de computación. Si yo hubiese estudiado Ingeniería de Sistemas no habría soportado ni un solo semestre. Por culpa de esos tipos y su ideología los que se dedican a eso son llamados computines, que es sinónimo de alguien limitado, lineal y de pensamiento mecánico.

Desgraciadamente los brutos son indispensables en programación, porque los computadores son brutos y es mucho más útil tener programadores capaces de seguir normas y protocolos mecánicamente que tener tipos creativos, los creativos pueden ser muy dañinos en un equipo de trabajo porque tienden a escribir código fuera de norma, que nadie más entiende. Este embrutecimiento del trabajo del programador, alentado por el fanatismo de algunos profesores universitarios que se convirtieron en canutos cuando apareció la programación orientada a objetos, ha sido muy triste, pero indispensable para hacer programas complicados donde trabajan cientos de personas al mismo tiempo.

Menos mál que todavía queda una ventanita de luz para micro aplicaciones hechas por una sola persona, son cada vez menos pero todavía quedan y hay campo para la creatividad, la diversión y los lenguajes permisivos. Así es como ha aparecido Python y Ruby on Rails, que son de la misma filosofía que el Basic y hoy en algunas universidades, donde el estándar es C++ y Java, se estudian como "programación avanzada", que increible vuelco.

Yo tuve un enamoramiento violento con la programación en 1969, cuando leí un artículo en Mecánica Popular sobre los computadores y mostraban un ejemplo de código en Fortran, lo copié y lo estuve revisando por mi cuenta durante años, hasta que lo entendí al revés y al derecho. En 1982, cuando tuve mi primer curso de programación en la Universidad ya tenía completamente internalizada la forma de pensar en Fortran, escribí buen código desde el primer día.

Un par de años empecé a trabajar vendiendo programas en CA-Basic: inventarios, contabilidad, cuentas corrientes eran mis caballitos de batalla y empecé a acumular una biblioteca enorme de subrutinas de código de propósito general que eran mi maletín de gásfiter. Creo que todos los que trabajábamos en eso por esos años ya habíamos inventado intuitivamente todo lo importante de la Teoría de Objetos, menos la jerigonza y las analogías absurdas con la Teoría de Conjuntos, que al final solo sirven para que los profesores reprueben a los que les caen mal.

En 1982 iba caminando por calle Maipú, al llegar a Luis Schmidt y se me ocurrió la idea más brillante que he tenido en mi vida y era la solución a un problema que me tenía atascado por más de un año. En esos años se usaban archivos secuenciales para guardar los datos y los chorizos  de datos separados por coma no solo eran enredados de manejar sino terriblemente lentos en equipos con 32 KB de memoria y CPU Z80 como los computadores que yo programaba, era imposible programar un sistema que rebajara el inventario en tiempo real desde la caja, que era mi sueño en esa época.

Ese día lo vi en mi imaginación, como un golpe eléctrico se me ocurrió el concepto de archivo relacional con todos sus detalles, de un golpe, vi clarito hasta la rutina para llenar de espacios para dejar los string de largo fijo, en esos años todo había que codificarlo. Ni siquiera existía el visi-calc, el concepto de un archivo relacional lo inventé, junto con los métodos de acceso, la búsqueda binaria era un algoritmo estándar pero la idea de usar un índice en memoria también se me ocurrió junto con todo eso. Me sentí un pequeño Einstein.

Claro que todo eso ta se había inventado antes, en 1960, en el Jet Propulsion Laboratory un tipo ya había inventado el concepto de base de datos y vendió la idea a Ashton-Tate para el mítico programa Dbase, que fue el rey de los métodos de almacenamineto de datos desde fines de los 80s. Pero en Chile no se de nadie que tuviese idea de eso, menos los que trabajaban como yo, en las empresas, no haciendo clases an la universidad. Cuando conocí el Dbase casi me caigo muerto, era mi idea pero totalmente implementada, diablos.

Tal vez por eso siempre he tenido antipatía por las bases de datos relacionales, ¡me robaron la idea!, no, hablando en serio hay muchas cosas que no me gustan de las bases de datos que, igual que la OOP, han creado una ideología fanática sobre el modelamiento de datos. No me gusta el principio del ocultamiento de los datos, creo que es una equivocación y la seguridad debiese estar basada en la criptografía sobre archivos de texto planos, no en grabar datos en un formato propietario inaccesible para el programador.

El año 2005 conversaba con Stephen Gutknecht, un genio de la programación que trabajó mano a mano con Wosniak y tuvo su propia empresa de software por años. Le decía que la programación ya no me gustaba por el fanatismo exagerado hacia la OOP y el modelamiento de datos, recuerdo que en ese año me dijo que no me preocupara porque esas cosas se estaban revirtiendo, las bases de datos estaban volviendo al texto plano gracias a una cosa nueva para mi en esos años, llamada XML, tenía tremenda razón.

Bueno, de cosas malas sale algo bueno. Las clases me despertaron el interés dormido que tenía por hacer la segunda parte de mi curso Visual Basic Para Oficinas. La primera parte fue extremadamente básica pero entrega prácticamente todas las herramientas que se necesitan para empezar a programar en VBA, sin embargo tiene una sola aplicación. La segunda parte a mi modo de ver, debe tener una aplicación práctica.

Por los años que pasé programando me di cuenta de algo que es muy bonito: cosas que parece que no tuviesen nada que ver entre si son análogas y cuando uno va viendo unidad en cosas dispersas, simetrías, ve todo más lindo. En tantos años de hacer programas en empresas e instituciones con cientos de aplicaciones distintas, me di cuenta que todas las aplicaciones en que he trabajado y contienen datos siguen uno de los tres modelos: el modelo de agenda, el de inventario o el de cuentas corrientes. Son estructuras que se encuentran más allá de sus aplicaciones obvias.

Por ejemplo en el control del flujo de caja estructuralmente es identico a una cuenta corriente, los deudores cambian por cuentas de gastos o ingresos, etc. y así, está lleno de simetrías de esa clase. Así es que partí enseñando eso antes de enseñarles a programar y aprovecharé también que sea mi primera clase para el nuevo curso VBA Práctico: Inventarios y Cuentas Corrientes. Ya empecé, vamos a ver ahora quien me para.