compiler construction - lenguajes - ¿Elección de back-end para un nuevo lenguaje de programación dinámico?
frontend y backend platzi (14)
He estado desarrollando una variante de Smalltalk simplemente por el gusto de hacerlo y me pregunto qué sería una opción similar para stackoverflowers cuando se trata de apuntar a un back-end. Estas fueron mis consideraciones actuales:
.NET, JVM: Estas dos máquinas virtuales son principalmente para lenguajes estáticos y supongo que sería bastante difícil dirigirse a un lenguaje tan dinámico como smalltalk.
Python (como código fuente): Parece ser la forma más simple. También sería mejor si pudiera emitir un bytecode de Python, pero no está bien documentado como el AFAIK de otras máquinas virtuales (¡Necesito excavar el código fuente de Python para más detalles!).
Intérprete hecho a sí mismo: fuera de la cuestión, ya que no es divertido :-)
LLVM, NekoVM, Parrot son otras opciones que estoy revisando. ¿Cuál sería tu opinión sobre esto?
.NET como el DLR ahora que se sienta encima del CLR para el lenguaje dinámico.
Es posible que desee echar un vistazo a PyPy : mientras este proyecto existe para implementar el lenguaje Python en (un subconjunto de) Python, el enfoque que están tomando permite múltiples interfaces y múltiples back-ends (incluyendo CLR, JVM, LLVM , C e incluso Smalltalk y JavaScript, creo). Por ejemplo, el trabajo en el JIT se ha hecho usando Prolog como lenguaje de usuario y CLR como back-end. Así que puedes unirte a la fiesta para implementar Smalltalk y luego descubrir que también has ayudado a alguien a implementar Prolog sin saberlo ... :-)
Factor ( http://factorcode.org/ ) puede ofrecer algunas características útiles para esto.
Hazlo en .Net, después de todo lo que quieras hacer por diversión. Así que hazlo un poco desafiante Y cualquier hallazgo puede ser reportado a Microsoft, para mejorar el DLR y los idiomas que soporta.
JVM como primera opción. Permitiría un amplio soporte de biblioteca desde el primer día. Vea cómo eso benefició a Clojure.
Además, LLVM podría ser una opción interesante, pero no estoy seguro de qué tan "probado" sea, ya que no puedo tener una implementación de lenguaje maduro con el backend de LLVM.
Evitaría .NET. Haría más difícil reunir comunidad y apoyo en torno a su nuevo idioma, y lo necesitará pronto. Además, no es multiplataforma.
Lo que sea que elija, aprenderá mucho al hacerlo.
JVM es más estable, está mejor documentado y, en general, es menos probable que sea un objetivo en movimiento que .Net. También es más probable que encuentre personas que puedan ayudarlo si utiliza el código abierto. Con .Net el talento es realmente escaso, y la mayoría trabaja para Microsoft, por lo que probablemente no tengan tiempo para ayudar.
No descuenta .NET o JVM tan rápido. Se están desarrollando lenguajes dinámicos para ambos (por ejemplo, Groovy, JRuby, Jython en la JVM, IronRuby, IronPython en .NET) y .NET está ganando el "DLR" - Dynamic Language Runtime. (Ver el blog de Jim Hugunin para más detalles).
Parrot es realmente genial, incluso si aún no han enviado ningún código "real". Pero dado que el proyecto es solo por diversión, eso no debería detenerlo: D.
Si va a consultar el uso de .Net, eche un vistazo a Beautiful Code: hay un ensayo sobre cómo hacer código gen dinámico en .Net CLR.
Una ventaja del uso de Parrot es que incluye toneladas de ejemplos de idiomas, incluida una variante de Smalltalk llamada ChitChat. Entonces puede usar eso como referencia para ver cómo alguien más ha implementado un lenguaje similar en Parrot.
Definitivamente, .Net usa Dynamic Language Runtime. Sus objetos serán utilizables directamente por los usuarios de C # y V.Net cuando finalice (¿ tiene la intención de enviar algo? :-)
En particular, el objetivo se ejecuta bajo el .Net reducido en SilverLight para que pueda obtener la última compra de interfaz de usuario rica en web.
Si esto es por diversión, ¿por qué no comenzar con la base de código para Squeak, que es de código abierto, y modificarla? Smalltalk debería tener un tiempo de ejecución pequeño, y su variante pequeña y divertida podría comenzar con el entorno bootstrap de chirrido, que es casi microscópico, y acumulado desde allí.
Mi gran cosa contra .NET y la JVM es el enorme tamaño. Mire qué tan pequeño es el tiempo de ejecución "sistema operativo a smalltalk" impedance-matching-layer en Squeak.
¿No deberían ser proyectos divertidos, bueno ...... DIVERSIÓN? Squeak es muchas cosas, businesslike no es uno de ellos, pero divertido ... definitivamente.
Elegiría la JVM, pero principalmente porque estoy familiarizado con ella.
Las razones objetivas para JVM son: se admiten plataformas principales, muchas bibliotecas y un buen rendimiento (dentro de las opciones que usted ha otorgado, puede tener el mejor rendimiento).
.Net funciona mejor en Windows. Si lo elige, debe probar en Mono para ser más neutral en la plataforma.
Python parece una buena opción también. Pero creo que para la JVM hay más bibliotecas disponibles.
Parrot es en mi opinión demasiado fresco, necesita algo de tiempo para madurar. Pero una alternativa interesante para el futuro.
Las otras opciones son nuevas para mí, las echaré un vistazo.