Las ciencias de la computación avanzan... ¿creo?

A finales de los ochenta y comienzos de los noventa, cuando me sumergí en el asunto de la informática y la programación, la moda era la programación estructurada en entornos MS-DOS. En aquel momento hacía programas en QuickBASIC, TurboPascal y Turbo C.

Pero cuando uno leía literatura sobre el futuro de la carrera, no podía menos que atemorizarse. Se hablaba de computadoras que reconocerían lenguaje natural y podrían ser programadas simplemente diciéndole lo que quieres hacer; inclusive en los foros electrónicos de la época (los BBS) y en las clases que recibía para graduarme de TSU, profesores y especialistas hablaban con cierta desesperanza sobre lo que nos depararía el futuro a quienes quisiéramos ser programadores, pues en el futuro -decían- programar sería tan sencillo que hasta una secretaria podría hacerlo.

Un golpe bajo recibí al poco tiempo; adicto yo a la programación en QuickBASIC, donde un programa típico que pudiera leer, modificar y eliminar registros de una tabla medía unas 200 líneas de código, de pronto me presentan al mundo de la programación en dBase (pseudomanejador de base de datos de la época) y su versión compilada, Clipper, donde ese mismo trabajo que yo hacía en 200 líneas, ellos lo podían hacer con tres comandos: USE, SELECT y BROWSE().

Al parecer, los lenguajes de programación se simplificarían aún más. Imaginaba que, para el 2005, con computadoras con lenguajes casi naturales y nuevos adelantos en el reconocimiento de voz (que ya existía en esa época), yo estaría desempleado o, tal vez, estudiando alguna otra carrera muy distinta a la computación.

Simple

En vez de eso, hoy, para poder hacer una típica aplicación web que muestre algunos registros de una o dos tablas (la cual, en efecto, obedece al paradigma cliente-servidor), requerimos:

• Conocer HTML (lenguaje de marcas de hipertexto), un lenguaje de presentación para determinar cómo se mostrarán las cosas.
• Conocer CSS (hojas de estilo en cascada), otro lenguaje que permite reutilizar formatos y aplicar estilos a los datos que vamos a mostrar.
• Conocer JavaScript, un lenguaje que normalmente corre en el cliente y permite, entre otras, validar las acciones del usuario antes de que éste las mande al servidor (por ejemplo, asegurarse de que no coloque letras en la cédula de identidad y darle un error en casod e que lo haga).
• Conocer ASP, ASP.NET, PHP, Perl, JSP o ColdFusion, lenguajes que se ejecutan en el servidor y permite realizar todo el procesamiento de la aplicación. Cada uno de estos lenguajes es muy diferente a los otros; algunos incluso están atados a una plataforma de software/hardware específica.
• Conocer alguna variante de SQL, que es el lenguaje que utilizan los manjeadores de bases de datos para consultar la información, insertar, actualizar o eliminar datos o crear nuevas estructuras. Cada manejador tiene su variante específica de SQL y sus propias particularidades, si bien supuestamente hay un SQL ANSI que debería correr bien en todos lados (supuestamente...).
• Conocer XML, un lenguaje que permite, entre otras cosas, el intercambio de información entre dos o más empresas o entidades (por ejemplo, para obtener una lista de los artículos que vende un proveedor). No sólo hay que conocer la estructura de XML, sino los formatos derivados del mismo, las formas de especificar su formato (DTD, Schemas) y las formas de convertir de un formato a otro (por ejemplo, un proveedor puede darte un listado en un formato distinto al que usas en tu empresa y tienes que hacer la conversión).
• Conocer los servidores de aplicaciones (Apache, Tomcat, Resin, IIS, Orion, etc.), los servidores de bases de datos (MS SQL Server, Oracle, MySQL, PostgreSQL, etc.) y los sistemas operativos (Windows Server, Linux, AIX, etc.), sus particularidades, su forma de configurarlos y optimizarlos, así como la manera de solucionar problemas.

Por supuesto que hoy día tienes que utilizar una metodología para crear tu aplicación. ¡No puedes programar a lo loco, como nos enseñaban en los institutos tecnológicos a comienzos de los noventa!

• Tienes la metodología clásica de los tres patos (algunos los llaman "tres amigos", pero aún no se sabe de quién caraj... son amigos) de Rumbaugh, Jacobson y Booch, que consiste en separar el desarrollo de la aplicación en cuatro etapas: diseño, análisis, implementación y pruebas, cada una delas cuales cuenta con varias subfases.
• Pero además de aprenderte la metodología, tienes que documentar lo que hiciste. Entonces llega UML (lenguaje unificado de modelado), también creado por los 3 citados señores, que te enseña los diferentes podemos y diagramas para representar cómo hacer una aplicación. Hay por lo menos siete vistas distintas, pero el lenguaje puede extenderse así que otros autores han propuesto sus propios modelos para casos particulares.
• Pero además, tienes que crear y documentar la interfaz de usuario... ¡y no puedes hacerla a lo loco! Hay lineamientos y estándares específicos dependiendo del tipo de aplicación que vayas a realizar, y para más colmo también tienes que documentar eso utilizando una forma de documentación y reutilización denominada "patrones". Hay patrones de dominio, de sistema, de tareas, de usuario...
• Dependiendo de la empresa para la que trabajes o de tu metodología de trabajo, posiblemente quieras utilizar paradigmas como el MVC (modelo-vista-control), que exige separar la lógica de negocios de la presentación, y añadir además una capa que coordine o dé circulación a los usuarios a través de los diferentes puntos de la aplicación.
• Si cometes el terrible error de usar MVC con las tecnologías Sun, tendrás que aprender -además de JSP y del lenguaje Java en general- las particularidades en el uso de Servlets, Enterprise Java Beans, JDO o alguna de esas tecnologías. La curva de aprendizaje es muy fuerte, y aún después de dominarlo, créeme: tardarás mucho más que utilizando los JSP tradicionales (los cuales también pueden usarse para implementar MVC si eres lo suficientemente ordenado y planteas reglas estrictas).
• Una vez tengas tu aplicacioncita montada en un servidor web, el día menos pensado te dará un error. ¿Qué hacer? Depende de quien tenga la culpa, porque una aplicación web es muy compleja y puede reventar en cualquier lado: en el servidor de base de datos, en el servidor de aplicaciones, puede ser que el hosting haya salido del aire, puede ser que tu proveedor de Internet haya salido del aire, puede ser que tu computadora tenga un virus o un spyware bloqueándote el acceso a Internet, puede ser que alguien la haya hackeado... en fin, te conviene conocer bastante de redes, TCP/IP y seguridad en la web para saber dónde está reventando tu aplicación y reclamarle al responsable correspondiente... si es que no eres tú mismo.
• Pero también tienes que tomar en cuenta que, si estás transmitiendo datos más o menos confidenciales por Internet, tienes que usar tecologías que garanticen la seguridad, la confiabilidad y la integridad de los datos. Así que te tocará aprender de SSL, SET, certificados, y otros detallitos. Ah, y más te vale que conozcas al menos superficialmente las implicaciones legales y jurídicas de todo eso.

Por algún motivo, alguien se aseguró de que ninguno de los lenguajes de programación y presentación se parezca a los demás. HTML y XML no se parecen a CSS, PHP es muy diferente a JSP el cual es aún más distinto a ASP. Y ninguno de estos lenguajes se parece ni de retruque a SQL. UML es un lenguaje lleno de muñequitos, rombos y cuadritos, sacado de Viaje a Las Estrellas, así que no se parece en nada a los anteriores.

Aún así, a pesar de todo, a los computistas que tardan años en conocer todo esto se les paga entre 1,2 millones y 1,5 millones de bolívares mensuales, un sueldo mísero entendiendo que todos estos conocimientos tienen que ser actualizados periódicamente mediante cursos y libros costosos. Y es que los lenguajes y estándares nunca se quedan quietos; siempre están en constante actualización, y hay que conocer dichas actualizaciones.

Fíjense: HTML va en su quinta versión, y PHP también va en la versión 5.0 (en el caso de PHP, cada versión mayor rompe la compatibilidad con las anteriores en puntos importantes); ASP.NET es la cuarta encarnación del lenguaje script de Microsoft; Java lleva cinco desafortunadas y patéticas revisiones importantes (y como 500 revisiones menores); los Enterprise Java Beans sacaron una versión 2.0 que rompió con el estándar de la 1.x. CSS va en la versión 2.0, UML también tiene varias revisiones importantes (va por la 2.0 y creo que han habido 3 o 4 revisiones, cada una con más rombos, cuadros y muñequitos) y XML sigue en la 1.0 pero todos los días aparecen estándares nuevos basados en ésta.

Microsoft Visual Basic fue, hasta la versión 6, un lenguaje muy práctico (aunque a veces muy problemático, con un patético manejo de objetos y para nada ejemplar a nivel académico), utilizado por los TSU para programar aplicaciones rápidamente, pero entonces llegó la pesadilla: VB.NET. El lenguaje fue rehecho completamente, y las aplicaciones programadas en la versión vieja deben pasar por largos procesos de conversión a VB.NET, que en muchos casos tardarán años. Y, según me cuentan, lo que antes se hacía con 4 líneas de código en VB 6, ahora requiere del doble o el triple en la versión .NET.

A la veeeeeeeeeerg..., ¿saben qué? Yo creo que la mayoría de los programadores hubieran querido quedarse con Clipper, dBase y GW-Basic :)

Pero si programar eso es facilito...

Por lo general, los empresarios, gerentes y las personas que provienen de otras carreras ignoran todo esto, y piensan que hacer una aplicación de comercio electrónico a través de Internet es algo tan fácil que un chamito de 16 años puede hacer pagándole 300 mil bolívares. Al poco tiempo los ves refunfuñando y quejándose de que Internet no sirve para nada, porque gastó 300 mil bolívares en una página web que le montaron en Geocities y nunca sirvió.

En fin, además de saber todo eso, hay que saber venderse: sentarse con un empresario o con el director de una empresa o un ente público o privado, y explicarle pacientemente por qué hay que hacer estas cosas para que funcione un sistema web, y por qué ello es más conveniente que el USE... SELECT... BROWSE... de dBase (aunque no lo crean, muchísimas empresas aún mantienen aplicaciones que corren en dBase y Clipper).

Realmente, no sé cual será el futuro de todo esto. ¿Más estándares?

Tampoco sé hasta qué punto todo esto sirve para ayudar a Venezuela a salir del problema grave de pobreza que enfrenta hoy por hoy. A veces siento que perdemos el tiempo discutiendo sobre casos de uso o sobre si es mejor usar Java Beans o tecnologías .NET, cuando hay una cantidad *enorme* de personas que más bien están preocupadas en este país por conseguir empleo o cómo dar de comer a sus hijos.

Y la triste realidad es que en muchos sitios, particularmente en la Escuela de Computación de la UCV de donde provengo, nos enseñan cómo trabajar para ese 1 o 2 por ciento que es constituido por las grandes empresas y transnacionales que existen en el país, y no para el noventa y pico por ciento formado por las empresas pequeñas o medianas, que no pueden saber nada de Oracle, servidores Sun corriendo aplicaciones Java o de enlaces de frame relay que cuestan decenas de millones de bolívares mensuales. Mucho menos nos enseñan cómo trabajar para que ese 80 por ciento de la población venezolana salga de la pobreza.