Estrategias de evaluación para intérpretes de software

Depth First, o Primero en Profundidad.

Existen dos estrategias para recorrer una estructura de árbol:
Depth First o Primero en anchura:
Se recorren primero las hojas hermanas, luego las hojas hijas, nivel por nivel.

Breath First o Primero en profundidad:
Se recorren primero las hojas hijas, rama por rama, hasta la más lejana a la raíz primero.

Ambas estrategias tienen sus ventajas y desventajas, pero para este evaluador, la mejor es ir primero en profundidad.

¿Porqué?
Porque así respetamos el órden correcto de los operadores.
En este caso, las hojas “6” y “7” se multiplican primero. Y luego el resultado es asignado a “x”.

En mi caso me gustaría hablar del motor V8 de JavaScript, y esto es algo que ya he hablado en otras clases, pero ahora que entiendo más todo este proceso me gustaría profundizar más en ello:
.
Este es un esquema que tomé del Curso Profesional de JavaScript
.

.
Este es otro que tomé del Curso de JavaScript Engine (V8) y el Navegador
.

.
Son los mismos, pero pongo ambos para que tengan dos visiones diferentes.
.
Todo inicia en el Source Code, justamente ese archivo de texto plano que termina en extensión .js, en nuestro caso, nuestro source code del Lenguaje de Programación Platzi es todo el programa que pasamos, es decir, lo que escribimos en sintaxis de LPP.
.
Podemos ver que JavaScript lo pasa por un parser, para generar su propio AST. El LPP también usa un parser para generar nuestro LPP. Muy seguramente el parser de JavaScript usa un Lexer interno que también genera tokens (de ahí el error Unexpected token... de JavaScript)
.
Recordemos que las computadoras solo entienden machine code, no entienden nada de lo que escribimos dentro de ese archivo que terminan en .js:
.

.
Entonces, para que nuestra computadora pueda entenderlo, hacemos uso del JavaScript Engine, existen demasiados pero el más conocido es V8 que es justamente el que te mostré en las primeras imagenes, básicamente V8 es el intérprete de JavaScript, es su evaluador, es ese motor que traduce todo el código a algo que la computadora puede entender:
.

.
Como se mencionó en la clase, JavaScript usa Just In Time Compiler, es decir, genera código máquina y bytecode al mismo tiempo, y los genera dependiendo de cómo se comporte el código que le pasemos:
.

.
Esto se puede apreciar mejor en este diagrama (la segunda imagen que te puse al inicio):
.

.
El interpreter traduce todo esto a bytecode (este es un código de bajo nivel que es leído por una máquina virtual que lo ejecuta), también podemos ver como el profiler se mantiene vigilando al interpreter en busca de cosas que optimizar para luego tomar la decisión de pasarlo directamente por un compilador y generar código máquina que puede leer la computadora, que por lo general es código mejor optimiazado.
.
La forma en la que el profiler decide esto es, si hay un pedazo de código que se ejecuta mucho (por ejemplom las llamadas a una función), entonces mejor lo optimiza y lo manda directamente a machine code.
.
Sin embargo, cuando una llamada a una función que estaba optimizada cambia y produce un resultado diferente al que solía producri, JavaScript dice: “Uy, esto ya cambio, mejor vamos a deoptimizar esto y mandemoslo a la máquina virtual”, es ahí donde se produce el proceso de deoptimización (primera imagen):
.

.
Es por eso que debemos cuidar nuestra programación en JavaScript para que el lenguaje tenga la posibilidad de echarnos una manita optimizando nuestro código. 😄