¿Qué tan rápido debe ser un lenguaje interpretado hoy?

Question

• ¿Es la velocidad de la implementación (principal/solo viable) de un lenguaje de programación interpretado un criterio en la actualidad?

• ¿Cuál sería el equilibrio óptimo entre velocidad y abstracción?

• ¿Deberían los lenguajes de scripting ignorar por completo todos los pensamientos sobre el rendimiento y simplemente seguir los conceptos de desarrollo rápido, legibilidad, etc.?

Lo pregunto porque estoy actualmente el diseño de algunos idiomas e intérpretes

Answer 1

experimentales Tan rápido como el desarrollador necesita que sea.

No hay reglas, solo necesita ser alimentado.

Answer 2

La velocidad es importante, sí, pero generalmente los lenguajes de scripting se usan en los casos en que la velocidad de ejecución es superada por los costos de E/S, por lo que no es el final, todo. De mucha más importancia es la estructura y las características del lenguaje. Trabaja primero con aquellos y luego con la velocidad de ejecución.

Dicho esto, en última instancia, si usted está buscando construir un nuevo lenguaje de propósito general, va a seguir la ruta que la mayoría va, que es la compilación previa en un bytecode y compilación JIT durante ejecución.

Answer 3

No hay respuesta única a una pregunta como esta. Ninguna respuesta puede aplicarse a todos los posibles propósitos y audiencias.

Probablemente, el factor más importante a tener en cuenta es si pretendes que el idioma sea en su mayoría independiente o utilizado junto con otra cosa. Si escribes algo como Lua que está destinado principalmente (o exclusivamente) para su uso junto con otra cosa (C en el caso de Lua), entonces la velocidad se vuelve mucho menos relevante e interesante. Si escribe algo que se usa principalmente por sí mismo, la velocidad comienza a importar mucho más.

Answer 4

1. Sí
2. depende de cómo está destinado a ser utilizado su idioma.
3. No. No hay razón para que uno no pueda diseñar un lenguaje legible que sea rápido, por lo que difícilmente parecería una excusa para ignorar el rendimiento.

Realmente tiene que responder estas preguntas para usted en función de los objetivos de sus experimentos.

Answer 5

La velocidad siempre es relevante a menos que su lenguaje sea inútil. Si es útil, la gente intentará usarlo para levantar objetos pesados, y si no se cae de bruces cuando lo intentan, siempre es mejor. Esto no significa que es que vale la pena para optimizar la velocidad (que depende de sus objetivos), ni le dice cómo (por ejemplo, compilación rápida a bytecode vs volver a trabajar cómo acceder a una biblioteca de alto nivel escrita en C para que el intérprete tenga aún menos que hacer antes de llamarlo).

El equilibrio óptimo entre velocidad y abstracción depende de los tipos de problemas que se resuelven. El tiempo de computadora generalmente es menos valioso que el tiempo de las personas, pero ambos valen algo.Descuidando por completo el tiempo de la computadora, aún es útil considerar cuánto tiempo se tomará total por personas que trabajan y esperan resultados; los usuarios de la lengua deben estar contentos al máximo cuando se minimiza el tiempo total de codificación + ejecución. (Ponderación de los salarios de los programadores frente a los usuarios si desea crear un caso comercial extremadamente sólido.)

Debido a los dos puntos anteriores, creo que es una mala idea que los idiomas interpretados ignoren por completo el rendimiento. Por supuesto, si el lenguaje es experimental en sí mismo, debe preguntarse cuánto tiempo desea dedicar al rendimiento en lugar de agregar características. Puede ser aceptable que una implementación inicial sea terriblemente lenta si se optimiza gradualmente, ya que se usa con más frecuencia y para tareas más exigentes. JavaScript es un excelente ejemplo de esto.

Answer 6

No entiendo por qué alguien escribiría un intérprete estos días. Hay dos máquinas virtuales excelentes, la CLR (+ DLR) y la JVM. Es trivial escribir un compilador para el tiempo de ejecución, y luego se obtiene la ventaja de la interoperabilidad con las enormes cantidades de código existente, además de bibliotecas estándar fantásticas, además de compiladores JIT que harán que la velocidad de su lenguaje no sea un problema en muchos casos (sin duda más rápido que cualquier intérprete).

Si desea hacer un lenguaje que será más que una curiosidad para los desarrolladores, este es definitivamente el camino a seguir en estos días.

Answer 7

Busco un lenguaje con una API excelente, personalmente. Si miras a Lua, el 90% del código de Lua C que la gente escribe es solo un texto repetitivo. Si aparece un lenguaje más lento, con una API de C++ mucho mejor, cambiaría a eso en un instante.

En última instancia, "la optimización prematura es la raíz de todos los males", y es decir, su lenguaje necesita algunas características excelentes, Y debe ser rápido. No sirve de nada ser rápido si es tan útil como ensamblador, y el usuario tiene que implementar el sistema operativo.