Yo no soy como Guti, o como muchos programadores, que empezaron a escribir código desde los años ochenta en que comenzó a popularizarse la informática doméstica. Empecé alrededor del año 1995, aunque ya antes había estado devorando libros de programación, aunque sin poder acceder, por desgracia, a un ordenador.
Así y todo, me doy cuenta que han pasado nada menos que veintidós años. Algunos de los que visitáis esta página puede que ni hubiéseis nacido. Un montón de años, en suma.
Cuando Google lanzó su Android, intentó hacerlo lo más cercano posible, y en su página de Google Code lanzó al público (no recuerdo si llegó a pasar de fase beta) una herramienta online para hacer aplicaciones. Decidí probarla para ver qué ofrecía aquel nuevo sistema operativo, que casi es hoy estándar en pequeños ordenadores (como los smartphones), y compararla con el pesadísimo SDK de Symbian que, por aquel entonces, yo usaba.
Google intentó con ella "alegrarnos la vida" a los programadores, y consistía en que ibas colocando "bloques" en un contenedor hasta formar tu aplicación. Solo podías crear aplicaciones muy sencillas, de los elementos propios de su interfaz, pero así y todo era llamativo que sin casi escribir ni una sola línea de código, uno pudiera crear una app.
Probablemente por sus enormes limitaciones (o porque ya habían logrado su objetivo, que pudiera ser) Google la acabó retirando. Luego volverían a dejar como única alternativa su pesadísimo SDK.
El caso es que todo eso me hizo recordar las grandes diferencias entre mis tiempos de programador, y ahora. Ahora la mayoría de tareas se han automatizado, el código se genera "automáticamente" (como en el ejemplo de la herramienta de Google) y se recurre a frameworks y máquinas virtuales para todo. Es cierto que se ha ganado en una relativa flexibilidad (digo "relativa" porque las máquinas virtuales son un engañabobos: por muy multisistema que sea tu aplicación, si el usuario final no puede instalar -o no quiere- la máquina virtual, o los pesados y asquerosos frameworks que, encima, tienen agujeros y debilidades por todos sitios, estás vendido, y al menos antes podías retocar tú el programa y hacerlo más portable, y ahora no). Claro que eso puede solucionarse (o paliarse) con sistemas en la nube, pero creo que entonces sería ir de Guatemala, a Guatepeor.
Sé que lo que estoy diciendo es un grito en el desierto, y las cosas no van a cambiar porque a las multinacionales del software les interesa que sea así, para anclarte y esclavizarte más a ellos (que tu Sistema Operativo tenga que activarse online, que no puedas impedir actualizaciones, etc., etc.), pero es lamentable que nadie haya hecho nada al respecto.
Tengo un conocido que trabaja en el departamento de informática de una compañía, y aunque él no es programador (es diseñador) se encarga de escribir en HTML5 sites webs. Lo que antes lo hacía un programador, lo hace ahora un diseñador y, si me apuráis, incluso un webmaster. La razón es sencilla: usan editores que les escriben el código y luego ellos solamente tienen que conocer cómo funciona el editor, y no el lenguaje en sí. Y así, uno abre cualquier página web y se encuentra un caos, un batiburrillo de código preformateado que mejor no meterse en él.
No voy a poner el grito en el cielo: todos los programadores llevamos haciendo lo mismo con nuestras RADs desde tiempos inmemorables, pero era muy diferente, el concepto era distinto. Además, la RAD te permitía agilizar el trabajo visual, pero para el código de bajo nivel y eventos tenías que apañártelas tú. Aún así, era poco lo que influenciaba la RAD en el resultado final, y mucho lo que dependía de tu intervención. Hoy es justo al revés: tienes que ceñirte a lo que esa RAD (o ese editor) escriba, de manera que acabas aprendiendo a trabajar con un editor, pero no con su lenguaje.
Cuando comparo los IDEs actuales de Java, como Eclipse, con lo que teníamos antes, me quedo asombrado. Con esos IDEs puedes trabajar en el flujo de eventos como puse antes con Android, casi sin escribir una línea de código, simplemente soltando y mezclando módulos como si fuera un mecano. Cuando te pones a modificar algo de su código te sueltan advertencias y errores por todos lados porque claro, estás retocando las secciones que la propia herramienta va escribiendo, y puedes acabar armando un lío monumental. Terminas con la sensación de que ya no sabes programar en Java, más aún: de que ya no sabes programar.
Es verdad que puedes forzar al editor a que "te deje en paz", pero entonces todas las bondades y virtudes de ese IDE desaparecen, y acaba siendo más engorroso hacer cualquier aplicación en ellas, que en el notepad.
Java, al tener su propio sistema de gestión y dibujo de interfaz (Java AWT), te permite ser sumamente flexible, pero si el estudiante que cursa estudios de informática se ve obligado a amoldarse a lo que diga y ponga la RAD o el IDE, esa flexibilidad se diluye por completo.
Cuando me puse delante de los últimos Delphi (y eso que Delphi no es una de las RADs más avanzadas) o VisualBasic, salí corriendo a por mis antiguos IDEs. Los nuevos te lo ensucian todo, te lo corrompen todo, lo quieren tener todo tan controlado que no te dejan hacer nada. Me asusté cuando quise hacer alguna utilidad portable con ellos y me salían dependencias por todas las esquinas. Claro, ahora nadie (o casi nadie) accede a los elementos y estructuras básicas del sistema, para qué, son muy flexibles y admiten datos de todo tipo sin conversión, y enormes y complejos métodos encapsulados, pero eso tiene la contrapartida de que si los quieres exprimir en su rendimiento, no puedes. Cosas como que para conectar con un socket o abrir un puerto, necesitas introducirle manejador de datos, protocolos, servicios dinámicos y un enorme etcétera que a lo mejor -y muy probablemente- no necesitas. Claro, quien ve tu código de cuatro líneas, muy eficiente, y lo compara con otro de un desarrollador moderno, piensan que no sabes programar. Por decirlo sencillo, es mejor que introduzcas un editor con objetos encapsulados, a que lo hagas "a mano" llamando simplemente a la estructura de strings y a procedimientos de entrada y salida (o apertura y cierre) de archivos, aunque en el primer caso no vayas a hacer uso nunca de negritas, itálicas, y capacidades accesorias parecidas.
Es cierto que buena parte de culpa no está en el programador, sino en la industria, que le obliga a trabajar así. Testear una aplicación de bajo nivel, cuanto más bajo nivel sea es más complicado, y lleva mucho más tiempo, así que cuidado. Aunque el resultado final sea mejor. Es más cómodo -y rápido- soltar un objeto encapsulado, una "pieza de puzzle" que ya estamos seguros de cómo funcionará, y andando. Aunque a la larga estemos para el resto de los días anclados a esa pieza encapsulada o a esa librería, y en caso necesario luego sea muy tedioso portarlo. Pero da lo mismo: si funciona hoy, con eso basta. Mañana que se arregle con ello el que venga detrás. Si hay un mañana.
| Redacción: Bianamaran.blogspot.com
No hay comentarios:
Publicar un comentario