Una de las dificultades más comunes en lo que se refiere a esto de dedicarse a la programación de computadoras es ¿qué lenguaje de desarrollo elegir? Por ejemplo, yo hace muchos años empecé con Turbo Pascal. Las razones fundamentales para mi elección fueron que era un archivo de unos 50K y contenía compilador y editor. Era además el más rápido en el mercado y su costo era menor a 50 dólares. Realmente una ganga. Otros amigos, por ejemplo, habían decidido aprender C y entonces requerían de varios diskettes, instalaciones incómodas en su momento, etcétera. Más aún, Turbo Pascal empezaba a convertirse en un líder en cuanto a desarrollo de aplicaciones y entonces la misma empresa que lo hacía, Borland, ya empezaba a sacar una serie de bibliotecas de desarrollo, para juegos, para bases de datos, etcétera.
Pero el mundo es muy cambiante y ahora domina Java, Python, C, C++ y C#. Los dos primeros son intérpretes y la intención de que así sean es que se pueden crear máquinas virtuales (como la de Java), que genera algo que llaman ByteCode y que si existe dicha máquina en la plataforma que usamos, entonces podemos tener todas las prestaciones del lenguaje. Lo interesante de la máquina virtual es que es una computadora hecha por software, con una serie de registros e instrucciones que los creadores de la misma se inventaron. Así, podemos escribir este programa, la máquina virtual, y entonces Java correrá en nuestro entorno.
Así pues, Java y Python son por ejemplo, intérpretes y por ende, son más lentos que los lenguajes compilados, los que generan código ejecutable, código de máquina. Sin embargo, con las velocidades de los procesadores actuales, podemos pensar que ya no son tan lentos estos intérpretes aunque pienso que todavía, para software de producción, no son francamente utilizables. Un mal ejemplo al respecto es el desarrollo del SAT para la creación de facturas electrónicas. La gente del gobierno le está pidiendo además a los usuarios que sepan cómo instalar Java en sus navegadores, así como Silverlight, que no entiendo a cuenta de qué lo incorporaron. Vamos, esto es un mal ejemplo de un desarrollo de producción que además, lo va a usar mucha gente.
Pero regresando al problema de qué lenguaje a elegir, cuando uno ya ha hecho su selección, se encuentra cómodo con ella. Ve que hay muchos foros de discusión, muchas bibliotecas de desarrollo para un enorme número de tareas y todo va bien. Pero pasan los años y de pronto algo pasa. El lenguaje empieza a decaer. Llámenle moda, modernidad, obsolescencia programada, lo que quieran, pero el caso es que los miles de foros de discusión empiezan a palidecer. Las páginas con código fuente, herramientas, componentes, etcétera, se hacen cada vez menos en número y al mismo tiempo, florecen otros lenguajes e incluso se mantienen con los años. Probablemente este es el caso de Java.
Pensaba yo en esta situación cuando hallé la página Pascal Programming for Schools, la cual contiene una idea interesante: un intérprete de Pascal que genera ByteCode de Java. Y sí, Pascal es en general un lenguaje que compila a código nativo de la plataforma en la que corra, como en el caso de Delphi o Lazarus, pero esta opción de generar ByteCode parece novedosa y podría hacer que los programadores de Pascal no tengan necesidad de migrar e irse a aprender otro lenguaje de desarrollo.
Hay intérpretes de Pascal escritos incluso en Pascal. Una serie de componentes llamados Pascal Script, de RemObjects permiten instalarse en Delphi 7 para poder hacer la traducción del código escrito en Pascal a ByteCode. Este código se interpreta si no se encuentran errores al “compilar” a la máquina virtual. RemObjects explica el propósito del software así: “Este es un motor de scripts que permite a los usuarios finales cambiar una aplicación a sus necesidades sin tener que recompilarla. El software no está diseñado para principiantes, pero hay apoyo en ejemplos e incluso un tutorial.
Ya probaré esta idea y reportaré lo que encontré. Como sea, es un paso interesante porque incluso se puede programar en Pascal y correr en el navegador, o al menos en principio esto podría hacerse si efectivamente compila ByteCode. Seguiremos informando.
Referencias: