¿Cuándo es razonable crear mi propio lenguaje de programación?

¿Existen tipos de aplicaciones asesinas, clases de problemas algorítmicos, etc., donde es mejor, a la larga, crear mi propio lenguaje?

PD: Solo para estar seguro, me refiero a un nuevo lenguaje de programación y un compilador, no un nuevo compilador para un lenguaje existente.

EDITAR : Gracias por las respuestas. ¿Puede proporcionar algunos ejemplos, donde es absolutamente innecesario crear un DSL o casos en los que un DSL podría ser una buena idea?

Ciertamente, es relevante que una persona escriba su propio idioma con fines educativos. Para aprender sobre el diseño del lenguaje de programación y sobre el diseño del compilador. Pero los usos del mundo real son pocos y distantes entre sí.

Al escribir su propio idioma usted es:

• Agregar una enorme cantidad de complejidad a su problema
• Agregar una cantidad significativa de trabajo por escrito y mantener el nuevo lenguaje y compilador

Entonces, si planea escribir su propio idioma para su proyecto, entonces las características que proporciona que otros idiomas no tienen que compensar los costos anteriores.

Tome el desarrollo de juegos, por ejemplo. A menudo necesitan mini-idiomas dentro de sus juegos o lenguajes de secuencias de comandos. Usan estos lenguajes para escribir una gran cantidad de eventos en el juego que suceden. Sin embargo, incluso en este caso, casi siempre eligen los lenguajes de secuencias de comandos existentes y los adaptan a sus necesidades.

Permítanme citar a Paul Vick, ex desarrollador principal del compilador de VB y ahora trabajando en el Proyecto Oslo y el lenguaje M:

Es alucinante, increíblemente difícil construir un nuevo lenguaje, incluso uno que se base en gran medida en uno existente. Sin embargo, muchos programadores piensan: "oye, yo uso idiomas, ¿qué tan difícil puede ser esto?" Y lo intentan. ... probablemente más del 98% de ellos no logran ganar tracción alguna, pero Dios bendiga a los optimistas porque sin ellos nunca obtendríamos el 2% de los idiomas que tienen éxito. Estoy personalmente dispuesto a sacrificar los millones de dólares y las horas desperdiciadas en lenguajes que nunca lo hacen solo para que podamos obtener lenguajes como C # y Java y Ruby y Python, etc.

Por lo tanto, el hecho de que crear un nuevo idioma sea una mala idea no debería disuadir a las personas de desarrollar nuevas DSL, solo debería darles una pausa y, con suerte, un poco de humildad. La clave, creo, es comenzar de a poco y mantenerse pequeño.

DSL: definitivamente una mala idea.

¿Cuándo es razonable?

Cuando te apetece!

No escuches a estas personas que tienen comentarios sarcásticos que básicamente dicen:

"No lo hagas porque es demasiado difícil y el lenguaje X es mejor que cualquier idioma que se te ocurra".

La cuestión es que crear un DSL ocurre todo el tiempo. Un marco es un DSL. Una macro es un DSL. Cada vez que escribe una función para su programa, eso es parte de un DSL. Claro, está dentro de los límites de la gramática, pero el vocabulario es parte de un lenguaje. Es por eso que las industrias a menudo crean su propia lengua vernácula: ¡es más eficiente!

Si "no hacerlo" fuera la respuesta correcta, todos estaríamos escribiendo COBOL y Fortran.

Es posible que desee leer partes del próximo libro DSL de Martin Fowler , si está pensando en escribir su propio idioma.

Realmente no puedo pensar en un caso de negocios para crear un lenguaje desde cero que no sea una experiencia de aprendizaje tremenda.

Editar: para DSL hay muchos casos de negocios, pero la clave aquí es no dejarse llevar y mantenerlo simple.

Sugiero que las preguntas clave son: "¿Qué problema estoy tratando de resolver?" y "¿Quién obtiene el ROI?"

Si está tratando de desarrollar sus propias habilidades y experiencia, avance a toda velocidad, pero no en un sistema de producción que supuestamente resuelva el problema de otra persona.

Parece que la razón principal por la que desea un nuevo idioma es que comienza a descubrir patrones en su código que los idiomas existentes no manejan bien. Pero hay muchos problemas para crear tu propio idioma. Te perderás todas las bibliotecas y frameworks creados para los idiomas existentes. Pasará mucho tiempo diseñando e implementando el nuevo lenguaje, que es todo el tiempo que no tiene que gastar en la tarea de programación real. Pasarás un gran esfuerzo para convencer a otros desarrolladores de que deberían usar tu lenguaje. Y tendrá dificultades para reclutar y capacitar a nuevos desarrolladores.

¿Por qué no escribir en un idioma como Lisp que le permite extender el idioma a medida que descubre nuevos patrones? Luego, obtienes todo el poder de un nuevo idioma con todos los beneficios de un idioma establecido.

Una razón podría ser crearlo como un experimento para aprender sobre el diseño del lenguaje y la construcción del compilador.

Otra razón podría ser crear un lenguaje de script en una aplicación cuando no tiene la opción de agregar una API de terceros.

No creo que pueda programar sin crear un nuevo idioma, por lo que es bueno darse cuenta de que es lo que está haciendo y comprender los problemas.

• ¿Qué es un idioma?
  Vocabulario, sintaxis y semántica.

Un lenguaje estándar como VB, Java, C #, etc. es solo un lenguaje base . Tan pronto como le agregue clases, métodos, etc., habrá agregado vocabulario y semántica. Hay muchas formas de implementar idiomas: análisis y traducción, análisis e interpretación, macros sobre un idioma existente, agregando clases y métodos a un idioma existente.

• ¿Qué quieres que haga un idioma?
  Sea bueno para expresar problemas de manera concisa.

¿Cómo sabes si has hecho esto? La medida que uso es editar recuento . Si aparece el requisito A de una oración, procedo a implementar el requisito en código. Cuando termino y elimino todos los errores, reviso el código, y el repositorio de códigos me da una lista de los cambios que hice, B. Cuanto más pequeño es B, mejor es el idioma. Promediada en el espacio de requisitos reales y posibles, esa medida me dice cuán "específico de dominio" es el lenguaje.

• ¿Por qué es buena la concisión?
  Porque minimiza los errores.

Si se necesitan N cambios en el código para implementar 1 requisito, y a veces comete errores, entonces el número de errores que introduce es aproximadamente proporcional a N. En el límite donde N = 1, es casi imposible introducir un error sin intentarlo.

Tenga en cuenta que este es un desafío directo a la "acumulación de código" que vemos hoy en día.

AGREGADO: en respuesta a su solicitud de un ejemplo, vea la ejecución diferencial . No diré que se puede entender rápidamente, pero reduce significativamente el código de la interfaz de usuario.

Siempre es "factible" usar la palabra en su pregunta (original), pero no suele ser útil y rara vez es óptima dada la abundancia de marcos y lenguajes maduros y bien respaldados que existen.

Sin embargo, es un desafío intelectual interesante.

Solo si el negocio principal de su equipo es lenguajes de programación.

He trabajado en un lenguaje de programación creado en una empresa financiera.

Claramente, para el arquitecto mismo, este fue un gran desafío y mejoró sus propias habilidades.

Inevitablemente, el lenguaje no pudo crecer ni mejorar en ninguna parte cerca de la velocidad que algo como C # o Java podrían: tienen equipos dedicados a hacer eso.

El lenguaje pronto se estancó ya que nadie nuevo quería asumir la tarea de mejorar el proyecto favorito de otra persona.

El arquitecto original se fue. El lenguaje se marchitó y murió después de 10 años.

Esos 10 años fueron un infierno para cualquiera que tuvo la desgracia de trabajar en un idioma sin salida.

Así que adelante, cree su propio idioma, pero no le pida a nadie más que lo use. No esperes que nadie más te lo agradezca.

Diseñar idiomas puede ser divertido. Pero no tiene que restringirse a los lenguajes de programación.

Si construyo una aplicación moderadamente compleja, me gusta agregar un tipo de lenguaje de macro / scripting para facilitar la ejecución de tareas repetitivas complejas. La mayoría de los usuarios no usarán esta funcionalidad, pero los pocos que la usan están muy agradecidos. Además, me aseguro de que sea valioso para las personas de soporte ayudarles a solucionar los problemas de los clientes.

Es completamente razonable si se hace para ampliar sus habilidades y aprender.

Aparte de eso, si tiene que hacer la pregunta, entonces no lo es. Si está tratando de determinar si puede manejar una determinada clase de algoritmo o un determinado dominio de problemas mejor que los idiomas existentes, primero debe ser un experto en el área que está abordando. Sabrás que es apropiado cuando tus habilidades y experiencia te lo indiquen.

Y también podría estar equivocado al respecto, pero necesitaría otro experto para convencerlo de eso (o para mostrarle que no es el experto que cree que es). Sería una discusión animada, no una simple pregunta y respuesta como encontrarás aquí.

Excepto para fines de autoeducación, me gustaría afirmar que hoy no existe la necesidad de crear su propio idioma. En cualquier circunstancia Siempre. Independientemente de lo que desee hacer, hay muchos cargamentos de idiomas existentes que puede tomar / adaptar a sus necesidades.

Definitivamente depende de la situación. Como dijo nosklo: si tiene una buena idea, un concepto nuevo o algo así, le recomendaría encarecidamente que lo haga.

En general, sugeriría confiar en la tecnología establecida.

Pero si está interesado en crear su propio "idioma", debería consultar: YACC y Lex

Puedes, simplemente no te atrapes en el antipatrón "Recreando la rueda cuadrada".

Lo que significa que está recreando lo que ya se ha hecho, solo que es más pobre que el original.

Wouter era conocido por crear un nuevo lenguaje para cualquier idea nueva. Puedes inspirarte en su trabajo: la página del lenguaje de programación de Wouter .

¿Cuándo crear tu propio idioma?

Cuando quieras, como un gran proyecto de hobby.

Para un lenguaje específico de dominio. Estos pueden ser bastante elaborados; mira lo que sucede en la comunidad de Ficción interactiva (o aventura de texto) revisando el archivo .

Cuando sus objetivos son muy ambiciosos y cree que puede hacer un avance real, como el proyecto Arc de Paul Graham .

Además, en cualquier lenguaje suficientemente adaptable (tal vez C ++, definitivamente Common Lisp) en el proceso de desarrollo de construcciones de bajo nivel.

¿Cuándo evitarlo como lo harías, espero, evitar un cliché como evitarlo como la peste?

Cuándo será la base del desarrollo continuo para proyectos reales. Siempre terminará quedando muy rezagado con respecto a lo que está disponible comercialmente a bajo precio, y paralizará un mayor desarrollo. Trabajé para una compañía con su propia versión de COBOL, y nunca quiero trabajar en otra compañía que mantenga su propio idioma. Vimos otras versiones de COBOL obtener mejores capacidades y mejores herramientas, mientras estábamos atrapados con los mismos problemas. (No quiero volver a trabajar con COBOL nunca más, pero esa es otra historia).

Las situaciones en las que podrías crear tu propio idioma no entran en esto. Los proyectos de pasatiempo no se utilizan para el desarrollo real. Algo como Arc tendrá éxito (y obtendrá múltiples implementaciones y más evolución y desarrollo) o fracasará (y nadie más lo usará). Un pequeño lenguaje específico de dominio es solo una parte de un proyecto, y dado que es pequeño, se puede mejorar con el tiempo. Se usa un lenguaje de aventura de texto para escribir juegos individuales, y esos juegos, además de ser proyectos de pasatiempo, casi nunca se usan para un desarrollo continuo.

Mi perspectiva es que las DSL son generalmente una "idea débil", y es más productivo a largo plazo usar un lenguaje estándar y construir sus necesidades específicas de dominio como una biblioteca de "no DSL".

Sin embargo, puede resultar que sus necesidades sean lo suficientemente personalizadas como para que sea preferible tener un DSL (no solo una implementación de gcc o lisp ligeramente modificada) para su empresa. Muchas compañías usan drop-ins de idiomas actuales que apuntan a lo que están haciendo, sin escribir / mantener su propio idioma. Por ejemplo, he oído que PHP tiene un buen acceso directo; Lua está diseñado para ser un drop-in, ModelView usa Python y AutoCAD tiene AutoLISP como scripter.

No hay nada de malo en escribir su propio lenguaje de programación si puede aprovechar las herramientas existentes. En el mundo de hoy, esto significaría que usted lo define en una sintaxis utilizable para un lenguaje existente (como Java o C #) o escribe un pequeño sistema de transformación (expansor de macro) que genera código en un lenguaje existente.

Ir hasta el código de máquina es reinventar MUCHAS ruedas ...

Una muy buena razón para un DSL es representar los datos del dominio de una manera sucinta. Esto permite a los expertos en dominios trabajar con los datos directamente en lugar de tener que pasar por otros. El truco consiste en tener los programas resultantes en un formulario fácil de procesar.

En general, la respuesta sería un gran NO. De los cientos de idiomas que existen, generalmente hay uno que se adaptará a su problema.

Sin embargo, hay circunstancias en las que es una opción racional desarrollar un nuevo lenguaje:

• Cuando uno de sus competidores ahora posee una de sus principales plataformas de desarrollo. Estoy pensando en la dependencia actual de Googles en Java y su desarrollo de "go", (¡ayuda si tienes un autor del lenguaje más exitoso en la nómina!).
• Cuando tiene que escribir una tonelada de código para una nueva plataforma y los idiomas existentes son verbosos y propensos a errores, por ejemplo, php para desarrollo web.
• Cuando se encuentra con problemas de escala y paralelismo que nunca antes se habían encontrado porque nadie había tenido tanto hardware para procesar tantos datos antes, por ejemplo, Scala y (hasta cierto punto, IR).

Para qué es bueno el lenguaje es la composicionalidad o unir los mismos componentes de diferentes maneras.

Si su problema de dominio solo necesita que configure un grupo de interruptores ortogonales, un idioma probablemente no agregue mucho sobre los formularios, una interfaz gráfica de usuario o una configuración de texto directo. archivo. (Asumo aquí que un archivo lleno de claves, pares de valores no es lo que quiere decir con un "idioma").

OTOH, si su configuración es como un lenguaje real, por ejemplo. los verbos y los sustantivos se pueden juntar en muchas combinaciones diferentes (y novedosas) a cualquier grado de complejidad, entonces un lenguaje se volverá casi inevitable, porque la explosión combinatoria de tratar de especificar lo que quieres por cualquier otro método abruma.

Dejando de lado los ejercicios de aprendizaje, es razonable crear su propio lenguaje de programación solo cuando comprende otros idiomas, su dominio del problema específico y la forma en que los idiomas existentes abordan ese dominio del problema y esta comprensión es lo suficientemente exhaustiva como para que sepa que un nuevo idioma es razonable solución sin necesidad de hacer la pregunta.

La última vez que me propuse hacer eso en un proyecto de pasatiempo, comencé a especificar cómo quería que se viera la sintaxis y me di cuenta a mitad de camino que estaba reinventando el prólogo. Otros idiomas que pueden ser adecuados cuando cree que necesita inventar un idioma son lisp, lua o algo así como Haskell. Básicamente, todos esos idiomas que ignoraste en la universidad porque pensaste que nunca serían útiles.

Una razón es para fines educativos, como ya se dijo. Pero hay más. Por ejemplo, hay muchos idiomas de investigación como Sing#el sistema operativo Singularity y BitCel Coyotos que se han diseñado porque los idiomas existentes no ofrecen las características requeridas (por ejemplo, verificación a nivel de idioma).

Tom Van Cutsem escribió recientemente una respuesta de ensayo a esta misma pregunta:

http://soft.vub.ac.be/~tvcutsem/whypls.html

Resumen de viñetas (de esa página):

• El lenguaje como mecanismo de abstracción sintáctico: para reducir el código repetitivo "repetitivo" que no se puede abstraer del uso de los mecanismos de abstracción incorporados en otro idioma.
• El lenguaje como formador de pensamiento: para inducir un cambio de paradigma en cómo se debe estructurar el software (cambiando el "camino de menor resistencia").
• El lenguaje como simplificador: reducir un paradigma existente a sus partes esenciales, a menudo para aumentar la comprensión y la comprensión.
• El lenguaje como ejecutor de la ley: para imponer propiedades importantes o invariantes, posiblemente para facilitar la inferencia de propiedades más útiles de los programas.

Probablemente nunca.

Lua es la mejor opción que puede obtener si desea incrustar el idioma en prácticamente cualquier otro idioma.

Actualmente se encuentran en idiomas específicos de dominio pequeño, y tiene sentido en algunas aplicaciones.

Aparte de eso, las razones son principalmente académicas.

Crear un lenguaje cuando no es necesario, es realmente algo malo debido a la complejidad que implica desarrollarlo y mantenerlo. He visto muchos proyectos que introducen algún tipo de lenguaje de secuencias de comandos específico solo para ese programa, y ​​fue lo que desaceleró el desarrollo de lo básico en gran medida. Buenos ejemplos son, por ejemplo, lenguajes de automatización como Phantom, AutoHotKey, AutoIt. Esas herramientas serían IMO mucho mejores si usaran algún lenguaje de emsing conocido como Lua.

Su 'edición' parece ser una pregunta sustancialmente diferente ("¿cuándo debo construir un DSL?" En lugar de la pregunta original que la gente entendió como "cuándo debería construir un nuevo lenguaje de programación de propósito general"). Parece que la gente ha respondido a fondo la pregunta "original", pero hay pocas respuestas que dan criterios específicos sobre cuándo usar un DSL. Entonces propongo una lista de verificación:

1. Su base de usuarios es mayor que unas pocas personas, generalmente no técnica y / o con acceso restringido al sistema (por lo tanto, no es razonable esperar que aprendan / usen un lenguaje de propósito general existente). Si está dentro de su equipo de desarrollo u organización de software, podría decir "simplemente escriba un script".
2. Sus usuarios deben usarlo con la frecuencia suficiente, con comportamientos lo suficientemente variados y cambiantes necesarios (es decir, no puede simplemente proporcionar una biblioteca fija de funciones mantenida por usted)
3. El comportamiento que los usuarios pueden especificar es demasiado complicado para especificarlo como datos (por ejemplo, no se puede lograr usando una tabla de base de datos, o una matriz de entrada de usuario, o una lista de tareas, o una colección de valores clave ... piense detenidamente porque puedes lograr mucha complejidad con estos). Si puede lograr el comportamiento utilizando la entrada de datos o la configuración en lugar de DSL, entonces probablemente debería hacerlo porque será mucho menos trabajo. Algún tipo de condicionalidad, o compilabilidad / encadenamiento juntos, o modelar algunas abstracciones diferentes pueden ser signos de que el comportamiento que necesita es demasiado complejo para datos / configuración simples
4. Pero el comportamiento todavía está lo suficientemente restringido como para poder especificarlo en un DSL conciso. Un gran peligro es la 'hinchazón de la plataforma', por ejemplo, si los usuarios comienzan a solicitar "¿puede agregar ...?". Si necesitan conectarse a Internet, o leer y escribir desde el sistema de archivos, o abrir y cerrar procesos, entonces esto ya no es un DSL. (He visto que esto sucede de verdad ... los usuarios pueden incrustar pequeñas llamadas de Python, creciendo gradualmente a scripts de Python y eventualmente destruyendo cualquier límite / modularidad / rendimiento)

Si todo esto es cierto, entonces un DSL puede ser apropiado.

¿Existen tipos de aplicaciones asesinas, clases de problemas algorítmicos, etc., donde es mejor, a la larga, crear mi propio lenguaje?

Depende.

Tomemos nuestro cerebro. Parece ser un desastre tan complejo que encontramos fronteras con CUALQUIER lenguaje de programación (al menos ahora). Entonces, para virtualizar realmente nuestro cerebro, necesitamos otros enfoques y, por lo tanto, otras semánticas y sintaxis.

En términos generales, todavía hay temas tan complejos que podrían conducir a otras estrategias que también incluirían un "mejor" lenguaje para un escenario dado.