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

49

¿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?

Daniel Rikowski
fuente
8
Creo que uno debería crear un DSL para cada problema.
SK-logic
44
¿No es esto para lo que LISP es genial?
Darknight
1
@Darknight, no necesariamente Lisp: cualquier lenguaje con cabañas de metaprogramación decentes está bien.
SK-logic
2
Cuando desee aprender sobre los componentes internos del compilador.
dan_waterworth
1
Cuando crees que sería divertido o educativo. Diseñar un nuevo lenguaje que necesite su propio compilador nunca sirve para ningún propósito útil, dada la cantidad de esfuerzo involucrado. (Por supuesto, hay personas que son lo suficientemente inteligentes, educadas y con experiencia para saber cuándo ignorar mi consejo.)
David Thornley

Respuestas:

40

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.

Simucal
fuente
13
Debo mencionar que en "El programador pragmático" que escribir lenguajes más pequeños y específicos del dominio para ayudar en una tarea es increíblemente útil y alentador. No recomendaría escribir un lenguaje de propósito general completo, pero un metalenguaje que genera código puede ser útil a veces.
Jordan Parmer
55
Es una mentira. Escribir un idioma no agrega complejidad, normalmente reducirá la complejidad significativamente. Implementar un compilador y mantenerlo es un trabajo muy pequeño de todos modos.
SK-logic
3
@ SK-logic, "Implementar un compilador y mantenerlo es un pequeño trabajo de todos modos". ¿Has probado? ¿Para qué procesador?
2
@ Thorbjørn Ravn Andersen, lo estoy haciendo para vivir. Hoy en día no tiene que apuntar directamente a ninguna CPU dada, ya que hay excelentes máquinas virtuales disponibles, como LLVM, .NET, incluso JVM. Y si no va a hacer muchas de las costosas optimizaciones, incluso apuntar a una CPU "real" no es gran cosa; vea el compilador OCaml para ver un ejemplo de este enfoque primitivista.
SK-logic
8
@ Thorbjørn Ravn Andersen, por definición, el compilador está traduciendo de un idioma a otro. El nivel de ese idioma de destino no importa nada. Y nadie cuerdo implementará un compilador de back-end de optimización completa para un DSL: es mejor reutilizar el existente. En realidad, la mayoría de las DSL modernas se compilan en C. En cuanto al ensamblador y el enlazador, siempre se han considerado separadas de la compilación, desde los primeros días de la programación del sistema.
SK-logic
24

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.

Konrad Rudolph
fuente
8
VB! = VBA. Por cierto, ¿es incluso legal criticar a VBA en este sitio? Después de todo, Joel ayudó a desarrollarlo, ¿verdad?
Konrad Rudolph
1
Aunque el programador pragmático era un libro tan bueno, la recomendación de DSL en ese libro era simplemente estúpida. De la misma manera que recomendaron aprender un nuevo idioma cada año, en mi humilde opinión, eso también es bastante estúpido.
dr. mal
2
Acabo de editar su respuesta para señalar el artículo de Paul Vick nuevamente en lugar del caché de Google. En 2011 "restableció su blog" y eliminó todo el contenido de VB, pero en 2012 lo volvió a colocar aunque con diferentes URL. Parece que personalmente estaba teniendo dificultades cuando eliminó esas cosas.
MarkJ
2
@ Mark J. Muchas gracias. Y, wow, ese artículo no es una lectura agradable. Espero que esté mejor ahora.
Konrad Rudolph el
2
Gracias por los amables comentarios, en realidad ahora estoy trabajando en JavaScript y, sí, las cosas están bastante mejor. :-) No estoy seguro de por qué el enlace original no funcionó, intenté que todos los estilos de enlaces antiguos funcionaran, lo echaré un vistazo.
panopticoncentral
23

¿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.

Desconocido
fuente
3
De Verdad? Consideraría que los marcos, las macros y las funciones son cosas que ayudan a un lenguaje a mantener la independencia del dominio.
CurtainDog
3
@CurtainDog, solo se convierte en parte del lenguaje si es parte de la biblioteca estándar. De lo contrario, es un "dialecto" del idioma.
9

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.

Ruben Steins
fuente
7

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.

joel.neely
fuente
7

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.

Clint Miller
fuente
6

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.

Sebastian Dietz
fuente
6

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.

Mike Dunlavey
fuente
Si existieran requisitos de una oración, todos estaríamos codificando en inglés. Al igual que cualquier lenguaje humano, el código requiere una gran cantidad de repeticiones para tener algún significado.
CurtainDog
@Dog: desde el punto de vista de la IA, eso sería ideal. Echa un vistazo a la ejecución diferencial. Ese es un ejemplo real de cortar el código fuente en un orden de magnitud. Puede que sea necesario un repetitivo, pero no es algo bueno.
Mike Dunlavey
5

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.

Simon
fuente
Uy, lo siento. Hablante no nativo ... :)
Daniel Rikowski
oh, no sabía eso y tu publicación está en excelente inglés, tan difícil de decir. Tampoco intento ser policía gramatical, disculpas.
Simon
5

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.

Joe R
fuente
1
Interesante estudio de caso ... ¿podría evitarse ese estancamiento apuntando a un lenguaje para, por ejemplo, las plataformas Java o .NET? De esa forma, el lenguaje puede 'crecer' a medida que se agrega más a las bibliotecas base.
CurtainDog
2
No estoy seguro de por qué crearías un lenguaje dirigido a otro como Java. ¿Por qué no usar Java o C # para comenzar?
4

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.

Toon Krijthe
fuente
4

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í.

Adam Bellaire
fuente
4

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.

JesperE
fuente
Su reclamo es extremadamente controvertido y me parece una queja.
SK-logic
Hoy en día hay varios marcos para crear sus propios DSL personalizados, que realmente no cubro lo que estaba tratando de decir (esto fue hace 2 años). Probablemente debería reformularlo ya que "implementar un nuevo lenguaje de propósito general desde cero nunca es, en la práctica, el camino correcto". :)
JesperE
ok, esta adición de "propósito general" lo cambia todo. Pero, no creo en los lenguajes de "propósito general", ninguno de ellos es lo suficientemente general, por lo que todavía hay mucho espacio para los nuevos lenguajes "algo generales" (que son, de hecho, DSL de algún tipo).
SK-logic
3

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

Chris
fuente
3

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.

Sintaxis
fuente
Si las ruedas no se recrearon, podríamos haber estado usando ruedas de roca. Rock it baby
Wong Jia Hau
3

¿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.

David Thornley
fuente
3

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.

Paul Nathan
fuente
3

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.

usuario1249
fuente
3

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).
James Anderson
fuente
2

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.

interestar
fuente
1

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.

Dave Sherohman
fuente
1

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.

Karl Bielefeldt
fuente
Yo uso habitualmente más de una docena de idiomas muy diferentes. Incluyendo Prolog, varios Lisps y Haskell. Pero aún así tiendo a resolver casi cualquier problema implementando un DSL. Y que las DSL son lo suficientemente específicas como para estar lejos de cualquiera de los idiomas existentes: se parecen más a una mezcla de pequeñas partes de los diferentes idiomas.
SK-logic
1

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).

sakisk
fuente
1

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.
Aidan Cully
fuente
0

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.

majkinetor
fuente
Lua es lento. Pero, por otro lado, hay un MetaLua con algunas capacidades de metaprogramación decentes.
SK-logic
0

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.

usuario967543
fuente
0

¿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.

Fabian Bigler
fuente