Pregunta

En mis lecturas sobre escritura dinámica y estática, sigo tropezando con la suposición de que los lenguajes escritos estáticamente se compilan, mientras que los lenguajes escritos dinámicamente se interpretan.Sé que en general esto es cierto, pero me interesan las excepciones.

Realmente me gustaría que alguien no sólo dé algunos ejemplos de estas excepciones, sino que intente explicar por qué se decidió que estos lenguajes deberían funcionar de esta manera.

¿Fue útil?

Solución

Aquí hay una lista de algunos sistemas interesantes.Es no ¡exhaustivo!

Escrito y compilado dinámicamente

  1. El compilador del esquema Gambit, Chez esquema, compilador de Will Clinger Larceny Scheme, el Bigloo Compilador de esquemas y probablemente muchos otros.

    ¿Por qué?

    A mucha gente le gusta mucho Scheme.Programas como datos, buen sistema macro, 35 años de desarrollo, gran comunidad.Pero quieren rendimiento.Por lo tanto, existen varios buenos compiladores de código nativo; Chez Scheme es incluso un producto comercial exitoso (los códigos de bytes interpretados son gratuitos;códigos nativos por los que pagas).

  2. El compilador justo a tiempo LuaJIT para lua.

    ¿Por qué?

    Para demostrar que se puede hacer.Y entonces la gente empezó a como obteniendo una aceleración 3 veces mayor en sus programas Lua.Lua está en muchos juegos, donde el rendimiento importa, y también se está introduciendo en otros productos.El 70% del código de Adobe Lightroom es Lua.

  3. El iconc IconoCompilador -a-C.

    ¿Por qué?

    Las cincuenta personas que lo usaron. amado Icono.Modelo de evaluación totalmente inusual, el sistema de procesamiento de cadenas más innovador (y en mi opinión, el mejor) jamás diseñado.Pero ese modelo de evaluación era realmente caro, especialmente en las computadoras de finales de los 80.Al compilar Icon en C, Icon Project hizo posible que los grandes programas Icon se ejecutaran en menos horas.

Conclusión:las personas primero desarrollan un apego a un lenguaje tipado dinámicamente y probablemente a una base de código importante.Con el tiempo, la comunidad lanza un compilador de código nativo para que pueda obtener un mejor rendimiento y resolver problemas mayores.

Tipeado e interpretado estáticamente

Esta categoría es menos común, pero...

  1. cámara objetiva.Dialecto de ML, vehículo para lotes de experimentos innovadores en diseño de lenguaje.

    ¿Por qué?

    Sistema muy portátil y tiempos de compilación muy rápidos.A la gente le gustan ambas propiedades, por lo que las nuevas ideas de diseño del lenguaje se difunden ampliamente.

  2. Moscú ML.ML estándar con algunas características adicionales del sistema de módulos.

    ¿Por qué?

    Portátil, tiempos de compilación rápidos, fácil de crear un bucle interactivo de lectura/evaluación/impresión.Se convirtió en un compilador de enseñanza popular.

  3. C-Terp.Un producto antiguo, creo que tal vez de Gimpel Software.Sabre C: un producto que no creo que puedas comprar más.

    ¿Por qué?

    Depuración.Especialmente, la depuración en hardware de los años 80 en MS-DOS.Con muy pocos recursos, podría obtener muy buena ayuda para depurar código C en hardware muy limitado (piense:Procesador de 4,77MHz con bus de 8 bits, 640K de RAM completamente cargado).Es casi imposible conseguir un buen depurador visual para código compilado nativo, pero con el intérprete es bastante fácil.

  4. UCSD Pascal: el sistema que hizo del "código P" una palabra familiar.

    ¿Por qué?

    A los profesores les gustó el diseño del lenguaje de Niklaus Wirth y el compilador podía ejecutarse en muy máquinas pequeñas.El diseño limpio de Wirth y el sistema P de UCSD formaron una combinación inmejorable, y Pascal fue el lengua de enseñanza estándar de los años 1970.A los más jóvenes les puede resultar difícil apreciar que en los años 1970 había No Debate sobre qué lengua enseñar en el primer curso.Hoy conozco programas que utilizan C, C++, Haskell, Java, ML y Scheme.En la década de 1970 siempre fue Pascal, y el sistema P de la UCSD fue una de las principales razones.

    En caso de que se lo pregunte, P significa portátil.

Resumen:Interpretar un lenguaje escrito estáticamente es una excelente manera de poner una implementación en manos de todos rápidamente.(También tenía ventajas para la depuración en hardware de la Edad del Bronce).

Otros consejos

Objetivo-C se compila y soportes tipado dinámico (ciertamente cuando se llama a los métodos a través de la sintaxis [target doSomething]). Es decir, puede enviar ningún mensaje a un objetivo (utilizando la sintaxis del lenguaje ordinario, sin necesidad de programar contra una API de reflexión), sólo recibirá un aviso en tiempo de compilación que no puede ser manejado, y recibir una excepción sólo en tiempo de ejecución si el doesn objetivo 'T responden a que el selector (que es como una firma de método); y se puede pedir a cualquier objeto (que todos pueden ser de tipo estático id si su código no conoce bien o no le importa) si respondsToSelector: para sondear sus capacidades.

Java (un lenguaje de tipos estáticos) se compila a bytecode JVM, lo que fue interpretado en versiones anteriores de la JVM, mientras que ahora utiliza Just In Time (JIT) compilación, es decir, se genera el código máquina en tiempo de ejecución. También creo ML y sus dialectos puede ser interpretada, y ML es definitivamente tipos estáticos.

Actionscript tiene tipado dinámico y compila a código de bytes.

Y aun compila abajo a la derecha en código máquina nativo si desea liberar una aplicación Flash en el iPhone.

Python es un lenguaje dinámico que tiene compiladores.

esta cuestión de forma -. Python - why compile?, por ejemplo

En general, la compilación hace que el programa funcionará mucho más rápido.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top