Compiladores e intérpretes

Entre el momento en que escribes código y el momento en que la máquina lo ejecuta ocurre mucho más de lo que parece. El texto que redactaste no es, por si mismo, algo que un procesador entienda: es una secuencia de caracteres que alguien tiene que traducir a instrucciones reales. Esa traducción es el trabajo de los compiladores y los intérpretes, y entenderla cambia la forma en que ves los lenguajes.

La pregunta típica de quien empieza, es Python lento?, está mal planteada. Antes de responderla conviene mirar que caminos distintos existen entre tu código y la máquina.

Las fases de la traducción

Todo compilador moderno recorre etapas parecidas. Primero el análisis léxico parte el texto en tokens: palabras, números, signos, identificadores. Es lo mismo que separar sílabas antes de leer. Luego el análisis sintáctico revisa que esos tokens formen frases válidas según la gramática del lenguaje y construye un árbol de sintaxis, una estructura que representa el código ya descompuesto en su jerarquía. Las gramáticas formales y los autómatas (de pila, sobre todo) son la teoría que sostiene este paso.

Después viene el análisis semántico, que verifica que lo sintácticamente correcto tenga también sentido: que no sumes un número con una función, que los tipos cuadren, que las variables existan. Recién entonces, con el árbol validado, llega la optimización: el compilador reescribe partes del código para que sean más rápidas o usen menos memoria, sin cambiar lo que hacen. Finalmente genera código máquina o un formato intermedio.

Compilado, interpretado y el punto intermedio

Durante mucho tiempo la distinción parecía simple: un lenguaje compilado traduce todo el programa a código máquina antes de ejecutarlo, y el resultado es un archivo ejecutable que corre rápido pero atado a una arquitectura; un lenguaje interpretado lee y ejecuta el código línea por línea, lo que es más flexible pero suele ser más lento.

La realidad moderna es más rica. Muchos lenguajes no compilan a código máquina directo, sino a un formato intermedio llamado bytecode, que luego una máquina virtual ejecuta. Java y su máquina virtual son el ejemplo clásico: compilar una vez, correr en cualquier plataforma que tenga el soporte. Y existe el camino justo a tiempo, conocido como JIT, que durante la ejecución identifica las partes más usadas y las compila a código máquina al vuelo. Por eso un lenguaje puede ser lento al arrancar y veloz una vez caliente.

Tipos y errores: cuanto antes, mejor

Buena parte del trabajo del compilador es atrapar errores antes de que el programa corra. Los sistemas de tipado estático conocen el tipo de cada variable al compilar y rechazan operaciones sin sentido antes de tiempo; los de tipado dinámico lo asocian al valor en ejecución y descubren algunos errores solo cuando el programa corre. La inferencia de tipos busca lo mejor de ambos: la seguridad del tipado estático sin la ceremonia de declarar todo.

Esta es la verdadera respuesta a si un lenguaje es lento. Depende de si compila a máquina, de si tiene un JIT, de que tan buena sea su máquina virtual, de que optimizaciones aplique y, por supuesto, de las bibliotecas que use por debajo. Un Python numérico bien usado puede ser tan veloz como C, porque el trabajo pesado lo hace código compilado. La lentitud no es propiedad del lenguaje, sino del recorrido completo entre tu código y el silicio.

Enlazado y el ejecutable final

Cuando el compilador genera código máquina, el resultado todavía no es un programa completo: le faltan las piezas de las bibliotecas que usaste. El enlazado es el paso que cose tu código con esas piezas externas y produce un ejecutable autónomo, listo para correr. Algunos sistemas enlazan todo al compilar; otros lo hacen al cargar el programa, o dejan que el sistema operativo resuelva las referencias en plena ejecución. Son detalles de implementación, pero explican por qué a veces un programa corre en una máquina y en otra se queja de una biblioteca ausente.

Lo que conviene llevarse

El código que escribes es un texto; lo que corre la máquina es otra cosa, obtenida tras un recorrido de análisis, verificación, optimización y traducción. Ese recorrido define buena parte de la experiencia de usar un lenguaje: que errores te atrapa temprano, que tan veloz es el resultado, en que plataformas corre. Antes de etiquetar un lenguaje como lento o rápido, conviene preguntar que camino recorre tu código hasta la máquina. Casi siempre, la respuesta es más interesante que la etiqueta.