¿Compilador o intérprete? La historia de una rivalidad que comenzó en los años 40
Hexa, Chip, and Pro trace the 80-year rivalry between compilers and interpreters, from Grace Hopper's A-0 in the 1940s through Fortran and Python. Compiled code runs faster; interpreted code lets you build and test quicker. Which one you pick depends on what you're building.
Chapters
Hexa, ¿no decías que ibas a contar una historia a través del código?
Totalmente, Chip. En este capítulo te voy a contar la historia de una eterna y épica lucha entre dos formas de ejecutar un programa.
¿Te refieres a ejecutar un guión en modo interpretado o ejecutar un programa compilado a código máquina?
Esa es nuestra historia de hoy.
Pero Hexa, no es típico de ti hacer esas simplificaciones. No es lo mismo compilar un código para una máquina virtual, como hace Java, o compilar el código para una arquitectura de hardware.
Sé que hay matices. Entraremos en ellos poco a poco. Lo que nos interesa ver es cómo surgieron los compiladores, cómo han evolucionado y al mismo tiempo compararlo con la creación y la evolución de los intérpretes.
Me parece un tema interesante, sobre todo porque abarca un periodo de la historia remoto, el inicio de los lenguajes de programación de hecho.
Pues parece que ya está todo. Hacemos un inciso y comenzamos.
Novedades. Como todos sabéis, podéis haceros historiadores o cronistas del canal y disfrutar de contenido exclusivo, además de apoyarnos.
Totalmente, aunque eso no es ninguna novedad, pro.
La novedad es que a partir de ahora también tenemos Patreon.
Sí, eso sí que es una novedad. Aunque, ¿qué ventaja tendría ser historiador o cronista en Patreon?
Pues además de apoyarnos, el mismo contenido exclusivo se encuentra en Patreon sin publicidad.
Eso podemos decirlo aquí en YouTube.
Y no olvidéis que a través de la página web podéis seguir realizando vuestras votaciones de forma gratuita.
Y la forma óptima de darnos vuestro apoyo siempre es dar al like, suscribiros y compartir el vídeo con todos.
Sigamos con el vídeo.
Al principio de los tiempos, en una época muy remota, en el siglo XVIII, no, la década de 1940, cuando comenzó la informática y se comenzaron a escribir los primeros programas de ordenador. Los programadores debían escribir en código máquina, Sé que no es lo mismo, pero imaginad que hubiese avanzado y se escribiese a día de hoy así.
¡Da miedo! Me los imagino con multitud de manuales, referencias, hojas de trucos y un sinfín de problemas.
Tampoco era para tanto. Es decir, es verdad que es muy difícil escribir código así, pero los programas se basaban en la resolución de problemas matemáticos y la generación de tablas de resultados para balística, astronomía y otros menesteres.
En nuestro capítulo de Von Neumann ya dijimos que no todos tenían problemas. Von Neumann podía memorizar páginas enteras de código máquina y traducir en su cabeza qué hacía el programa.
Se dice que alguien estaba revisando el código máquina en busca de un error, Von Neumann pasó por detrás y le señaló dos líneas diciéndole que estaban en orden inverso.
¡Qué bárbaro! Pero entonces, supongo que el primer lenguaje fue el ensamblador. Y por tanto surgió el compilador, ¿no?
Shortcode, el primer intérprete. El código máquina siempre ha tenido operaciones, saltos condicionales y capacidades que permiten traducir un lenguaje de programación a estas instrucciones y funcionar sin problema.
Sí, pero carece de expresiones, de una buena estructura y su legibilidad es casi nula.
Por ese motivo, para los programadores se crearon los lenguajes de programación y se considera el primer lenguaje de programación a Shortcode. Una evolución de la idea de John Mauchly con Briefcode.
Totalmente. Briefcode fue un formato para escribir las expresiones que un programa interpretaba para generar el resultado. Y aunque Mauchly pensó en este sistema durante 1949 para ENIAC, no se materializaría hasta que William Smith y otros compañeros escribiesen Shortcode para el UNIVAC.
Entonces, ¿concretamos que tras el código máquina llegó un lenguaje ensamblador interpretado?
No, Chip. Los lenguajes ensambladores tuvieron una evolución aparte. Shortcode parece un lenguaje de expresiones matemáticas de alto nivel.
¿Alto nivel?
Las categorías de lenguajes llegaron décadas después y fueron eliminadas otro par de décadas después.
Eso no tiene sentido, Pro. Se estudian en la universidad.
También la prehistoria, y no por ello está de moda.
Creo que Pro, al igual que Camilo Chacón en un episodio de Codeadores, Se refiere a que las categorías, las generaciones y otras catalogaciones para los lenguajes de programación están algo desfasadas.
¡Exacto! Al principio la programación de los computadores no era obvia que pudiese abstraerse. Mauchly tuvo la idea de facilitar el trabajo de transformar las ecuaciones matemáticas con un paso intermedio y, por casualidad, ideó el primer intérprete. Aunque es verdad que en 1942, unos 7 años antes, surgió el primer ensamblador.
Entonces sí que hubo un lenguaje ensamblador compilado.
No, Chip, el ensamblador ARC no se compilaba, se traducía.
¿Y qué diferencia hay?
Kathleen Booth, en Reino Unido, llegó a la conclusión de que escribir palabras que sugiriesen el código máquina a utilizar facilitaba la comprensión del programa cuando había que leerlo.
Pero tenía que hacer la traducción a mano, por lo que el intérprete sigue siendo anterior al compilador. Y fue en Reino Unido donde la familia de lenguajes Autocode, todos interpretados, tuvo más presencia, aunque no mucha aceptación, todo sea dicho.
Solo me queda preguntar entonces: ¿cuándo llegó el primer compilador?
Pues fue un trabajo conjunto entre Betty Holberton y Grace Hopper. Al parecer Colberton creó un programa para generar programas de ordenación en código máquina cambiando algunos datos necesarios y así ayudarle a acelerar la creación de estos programas.
Hopper vio el potencial de que un programa escribiese directamente el código máquina basado en datos y elaboró un catálogo de subrutinas de modo que cada comando escrito en el lenguaje A-0 se tradujese a estas subrutinas.
De ahí el nombre de compilar. Se toman trozos de código de las subrutinas, se sustituyen los datos pertinentes y se obtiene un código máquina que se ejecuta mucho más rápido que un programa interpretado.
Totalmente. El proceso de compilación se produce una sola vez y después se ejecuta el código máquina todas las veces que se necesite.
Entonces, A-0 se considera el primer compilador y Hopper es su inventora.
Parece que fue un bombazo para la empresa y el UNIVAC tuvo gran repercusión por el uso de este compilador.
Sí, al menos hasta llegar IBM, John Backus y su Fortran.
Lo recuerdo, tenemos vídeos sobre este tema, por lo que no entraremos en detalles aquí. Sigamos.
Lo siguiente a tratar es la edad de oro de los compiladores. Los ciclos de reloj eran caros. Utilizar un computador se medía en ciclos de reloj y, por tanto, la optimización de los programas era una necesidad.
La optimización siempre es una necesidad.
En cierto momento dejó de serlo gracias a la proliferación de los ordenadores personales y sobre todo del PC. El computador personal.
Y por ese motivo, en la década de 1990, los lenguajes interpretados volvieron a la escena.
Todos los lenguajes de los que ya hemos hablado en algún momento, como Python de 1991 o de 1995 Ruby y PHP.
No obstante, hablamos de la década de 1960 y 1970 principalmente, donde se produjeron grandes lenguajes y sus respectivos compiladores como son C, O Pascal.
Fortran dejó el listón tan alto que no pudo superarse hasta muchísimas décadas después. Si querías un lenguaje con un rendimiento cercano a escribir código máquina, debías usar Fortran.
Pero hubo otros lenguajes interpretados también muy usados. Aún recuerdo el capítulo de BASIC.
¡Los capítulos de BASIC, Chip! Pero sí, el capítulo de los orígenes en la década de 1960 dejó claro que era un intérprete para interactuar con los usuarios.
Bueno, que nos andamos por las ramas y aunque la historia ha estado muy bien, vamos con lo práctico. ¿Intérprete o compilador?
De esto hemos hablado muchas veces, Chip. Los compiladores se prefieren cuando tenemos que escribir código eficiente, óptimo.
Mientras que los intérpretes los utilizamos cuando queremos escribir código rápido, prototipos o guiones para nuestro sistema operativo.
¡Ni hablar! Puedes utilizar los intérpretes para código eficiente ejecutándolos en tu computador o en un servidor. Python da muestras de ello.
Discutible. Es verdad que a nivel de servidor y una vez el código está en ejecución muchas veces no se nota la diferencia entre un código hecho en un intérprete o un código compilado.
¿Cómo que no? El intérprete agrega un montón de código a la ejecución que no es requerido. Solo cuando se ejecutan rutinas escritas en Rust, C o cualquier otro lenguaje compilado es cuando Python es óptimo.
Ahí estoy confesa.
Hay matices. La mayoría de intérpretes hoy en día incluyen código JIT. O just-in-time para compilar con un optimizador de tiempo de ejecución, lo que hace los códigos interpretados mucho más rápidos.
¿Ves, Hexa? Un código interpretado puede ser óptimo también.
Habrá que verlo en ejecución.
Pero entonces, Pro, si dices que los lenguajes interpretados tienen mecanismos para hacerlos óptimos, ¿cómo sabemos cuál elegir?
Debemos basarnos en diferentes factores. Por ejemplo, una aplicación de escritorio puede escribirse hoy en día con JavaScript usando Atom, El cual embebe un navegador entero. Esto puede ser fatal para una herramienta pequeña. Ejecutar diez herramientas diferentes podría terminar consumiendo toda la CPU y memoria.
Pero eso no pasa si ejecutamos Python o Ruby con una biblioteca como GTK o WX Window.
También depende del tiempo que se mantendrá en ejecución. Los guiones son una buena opción para ejecuciones acotadas en el tiempo. Si un programa debe mantenerse en ejecución. Entonces es mejor utilizar un compilador.
En desarrollo móvil o en entornos embebidos también se prioriza la ejecución de código compilado y nativo a código interpretado.
Igualmente también depende. Si la aplicación se usará puntualmente y no de forma prolongada, como decía Hexa, da igual e incluso puede ser más rápido utilizar alguna solución multiplataforma o basada en guiones.
Me da la sensación de que estamos siendo algo ambiguos. No ayudamos nada a decidir.
Pues porque no lo vamos a conseguir, Chip. Da igual que te diga que Go es un lenguaje genial para hacer tus aplicaciones web, tú vas a seguir usando Python.
Porque con Python y Django tienes mucho hecho. No hace falta pensar algunas decisiones de diseño de la solución que no vienen dadas con Go.
Tampoco ayudará entonces recomendar rastileptos para hacer las páginas web de forma óptima.
Actualmente podríamos decir que el uso de un intérprete o compilador solo depende de nichos específicos donde el rendimiento extremo sistema obligan a utilizar un compilador.
O la velocidad de desarrollo nos obliga a utilizar un intérprete.
Conclusiones. Pues ya hemos dado un repaso. Supongo que habría que indicar que mientras el compilador procesa todo el código generando un código máquina, el intérprete no suele procesar el código al completo hasta el momento de su ejecución.
Como hemos visto, esto tiene sus ventajas e inconvenientes. Mientras un código compilado con antelación elimina este proceso en las subsiguientes ejecuciones, un código interpretado necesita hacer cada vez este proceso al iniciar una nueva ejecución.
Pero hay mucho más. Los intérpretes tienen mejoras como una compilación anticipada, caché e incluso la compilación JIT para acelerar su proceso, lo que los acerca un poco al rendimiento de los códigos compilados.
No tan rápido. Los compiladores tienen optimizadores que en algunos casos son difíciles de aplicar en cada ejecución y por tanto solo benefician al código compilado y no al interpretado.
Es difícil ponerse de acuerdo.
Pero parece que estáis de acuerdo en el desacuerdo, por lo que pasemos a las preguntas.
A los comentarios, pro. Y tú, sí tú, el que nos está viendo, como siempre digo, ya sabes, escribe algo en la cajita de comentarios. Y si no sabes qué poner, ya te lo digo yo. Empieza: CHIP, eres el mejor.
¿No será mejor que nos dejen un comentario concreto? Quizás vuestro parecer a esta discusión.
Por supuesto, el código compilado es el mejor, así que podéis escribir vuestro compilador de preferencia. El mío es LLVM.
¡Déjanos tu comentario!
Pues no me ha convencido la historia contada con código hexa.
Aún no he tenido tiempo de hacerlo bien, pero ya verás. El siguiente capítulo es sobre Delphi, ahí veremos código.
Pero si Delphi es principalmente un lenguaje con un entorno visual, ¿vas a programar en Windows?
Delphi no está solo en Windows, Chip. ¿Quieres echarle un vistazo?
Continuará, digo yo.
More from Manuel
Historia de los Lenguajes de Programación: años 1960-1969 #basic #apl #simula #lisp #logo
