¿Hay tipos de aplicaciones asesinas, clases de problemas algorítmicos, etc., donde es mejor, a largo plazo, crear mi propio idioma?
PD: Solo para estar seguro, me refiero a un nuevo lenguaje de programación y un compilador, no a un nuevo compilador para un lenguaje existente.
EDIT : Gracias por las respuestas. ¿Puede proporcionar algunos ejemplos en los que sea absolutamente innecesario crear un DSL o casos en los que un DSL podría ser una buena idea?
Sin duda, es relevante para una persona escribir su propio idioma con fines educativos. 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:
Por lo tanto, si planea escribir su propio idioma para su proyecto, entonces las características que proporciona no necesitan otros idiomas para compensar los costos anteriores.
Tomemos como ejemplo el desarrollo de juegos. A menudo necesitan mini-idiomas dentro de sus juegos o lenguajes de script. Usan estos idiomas para escribir una gran cantidad de los eventos que ocurren dentro del juego. Sin embargo, incluso en este caso, casi siempre eligen los lenguajes de script existentes y los adaptan a sus necesidades.
Permítanme citar a Paul Vick, ex desarrollador jefe del compilador VB y que ahora trabaja en el Proyecto Oslo y el lenguaje M:
Es asombroso, increíblemente difícil construir un nuevo lenguaje, incluso uno que se base en gran medida en uno existente. Sin embargo, muchos programadores piensan: "hey, yo uso lenguajes, ¿qué tan difícil puede ser esto?" ... probablemente más del 98% de ellos nunca 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. Personalmente, estoy dispuesto a sacrificar los millones de dólares y horas perdidos 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 nuevos DSL, solo debería darles una pausa y, con suerte, un poco de humildad. La clave, creo, es comenzar poco a poco y seguir siendo pequeño.
¿Cuándo es razonable?
¡Cuando te apetezca!
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 puedas encontrar".
La cosa es que crear un DSL sucede 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 propio lenguaje vernáculo: ¡es más eficiente!
Si "no lo hagas" fue la respuesta correcta, todos estaríamos escribiendo COBOL y Fortran.
Es posible que desee leer partes del el próximo libro de 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 sean: "¿Qué problema estoy tratando de resolver?" y "¿Quién obtiene el ROI?"
Si está intentando desarrollar sus propias habilidades y experiencia, entonces 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 querrías un nuevo idioma es que comienzas a descubrir patrones en tu código que los idiomas existentes no manejan bien. Pero hay un montón de problemas con la creación de su propio idioma. Te estarás perdiendo todas las bibliotecas y marcos que están construidos 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. Harás un gran esfuerzo para convencer a otros desarrolladores de que deben usar tu idioma. Y, tendrá dificultades para reclutar y capacitar a nuevos desarrolladores.
¿Por qué no escribe en un lenguaje como Lisp que le permite extender el idioma a medida que descubre nuevos patrones? Entonces, obtiene 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 creación de compiladores.
Otra razón podría ser crear un lenguaje de scripting en una aplicación cuando no tienes la opción de agregar una API de terceros.
No creo que puedas programar sin crear un nuevo idioma, así que es bueno saber que estás haciendo eso y entender los problemas.
Un lenguaje estándar como VB, Java, C #, etc. es solo un lenguaje base . Tan pronto como le agrega clases, métodos, etc., ha agregado vocabulario y semántica. Hay muchas formas de implementar idiomas: análisis y amp; traducción, análisis y amp; interpretación, macros sobre un idioma existente, agregando clases y métodos a un idioma existente.
¿Cómo sabes si has hecho esto? La medida que uso es editar recuento . Si aparece el requisito de una frase A, procedo a implementar el requisito en el código. Cuando termine & eliminé todos los errores, verifico el código y el repositorio de códigos me da una lista de los cambios que hice, B. Cuanto más pequeña es B, mejor es el idioma. Promediado en el espacio de real & posibles requisitos, esa medida me dice cómo "específico del dominio" es el idioma.
Si se requieren cambios en el código N para implementar el requisito 1, y a veces se cometen errores, entonces el número de errores que introduce es aproximadamente proporcional a N. En el límite donde N = 1, es casi imposible de introducir un error sin intentarlo.
Tenga en cuenta que este es un desafío directo al "código inflado" que vemos hoy en día.
AGREGADO: En respuesta a su solicitud de un ejemplo, consulte Ejecución diferencial . No diré que se puede entender rápidamente, pero reduce significativamente el código de UI.
Siempre es "factible" usar la palabra en su pregunta (original), pero a menudo no es útil y rara vez es óptimo debido a la abundancia de lenguajes y marcos bien soportados y maduros que existen.
Sin embargo, es un desafío intelectual interesante.
Solo si la actividad principal de su equipo son los lenguajes de programación.
He trabajado en un lenguaje de programación que se creó en una compañía financiera.
Claramente, para el propio arquitecto, este fue un gran desafío y mejoró sus propias habilidades.
Inevitablemente, el lenguaje no podría crecer ni mejorar a una tasa similar a la que C # o Java podrían: tienen equipos dedicados a hacerlo.
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 lenguaje sin salida.
Así que adelante, crea tu propio idioma, pero no le pidas a nadie más que realmente lo use. Por favor, no esperes que nadie más te lo agradezca.
Diseñar idiomas puede ser divertido. Pero no tiene que limitarse a los lenguajes de programación.
Si compilo una aplicación moderadamente compleja, me gusta agregar un tipo de lenguaje de macros / scripts para que sea más fácil ejecutar 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 que les ayuden a solucionar los problemas de los clientes.
Es completamente razonable si se hace para ampliar tus habilidades y aprender.
Aparte de eso, si tiene que hacer la pregunta, entonces no lo es. Si está tratando de averiguar si puede manejar una cierta 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á que es apropiado cuando sus habilidades y experiencia lo indiquen.
Y también podrías estar equivocado al respecto, pero necesitarías otro experto para convencerte de eso (o mostrarte que no eres el experto que crees que eres). Una discusión animada que sería, no un simple Q-and-A como encontrará aquí.
Excepto con fines de autoeducación, me gustaría afirmar que hoy en día no hay necesidad alguna para crear su propio idioma. En cualquier circunstancia. Siempre. Independientemente de lo que desee hacer, hay muchos otros idiomas existentes que puede adaptar / adaptar a sus necesidades.
Definitivamente depende de la situación. Como dijo Nosklo: Si tienes una buena idea, un concepto completamente nuevo o algo así, te recomendaría encarecidamente que lo hagas.
En general, sugeriría confiar en la tecnología establecida.
Pero si está interesado en crear su propio "idioma", debe consultar: YACC & Lex
Puedes, simplemente no te atrapes en el anti-patrón "Recreando la rueda cuadrada".
Significa que estás recreando lo que ya se ha hecho, solo que peor que el (los) original (es).
Wouter era conocido por crear un nuevo lenguaje para cualquier idea nueva. Puede inspirarse en su trabajo: página del lenguaje de programación de Wouter .
¿Cuándo crear tu propio idioma?
Cuando quieras, como un gran proyecto de pasatiempo.
Para un idioma específico del dominio. Estos pueden ser muy elaborados; mire lo que sucede en la comunidad de ficción interactiva (o aventura de texto) visitando el archivo .
Cuando tus objetivos son muy ambiciosos, y crees que puedes hacer un verdadero avance, como el Arc Project de Paul Graham.
También, en cualquier lenguaje suficientemente adaptable (quizás 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 plaga?
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 costo y paralizará aún más el desarrollo. Trabajé para una empresa con su propia versión de COBOL y nunca quiero trabajar en otra empresa que mantenga su propio idioma. Observamos que otras versiones de COBOL obtuvieron mejores capacidades y mejores herramientas, mientras estábamos atrapados con los mismos problemas. (No quiero trabajar con COBOL nunca más, pero esa es otra historia).
Las situaciones en las que puedes crear tu propio idioma no caen en esto. Los proyectos de hobby no se utilizan para el desarrollo real. Algo así como Arc tendrá éxito (y obtendrá múltiples implementaciones y una mayor evolución y desarrollo) o fallará (y nadie más lo usará). Un pequeño lenguaje específico de dominio es solo una parte de un proyecto, y como es pequeño, se puede mejorar con el tiempo. Un lenguaje de aventura de texto se usa para escribir juegos individuales, y esos juegos, además de ser proyectos de hobby, casi nunca se usan para el desarrollo continuo.
Mi perspectiva es que los DSL son generalmente una "idea débil", y es más productivo a largo plazo usar un lenguaje estándar y crear sus necesidades específicas de dominio como una biblioteca de "no DSL".
Sin embargo, puede resultar que sus necesidades sean lo suficientemente personalizadas para que sea preferible tener un DSL (no solo una implementación de gcc o lisp ligeramente modificada) para su empresa. Muchas empresas utilizan el uso de idiomas actuales que apuntan a lo que están haciendo, sin escribir / mantener su propio idioma. Por ejemplo, he escuchado que PHP tiene una buena presentación; Lua está diseñado para ser un drop-in, ModelView usa Python y AutoCAD tiene AutoLISP como su script.
No hay nada de malo en escribir su propio lenguaje de programación si puede aprovechar las herramientas existentes. En el mundo actual, esto significaría que lo definirá en una sintaxis que se pueda usar con un idioma existente (como Java o C #) o que escriba un pequeño sistema de transformación (expansor de macro) que genere código en un idioma existente.
Ir hacia el código de la máquina es reinventar MUCHAS ruedas ...
Una muy buena razón para que una DSL sea representar los datos del dominio de manera sucinta. Esto permite que los expertos en dominios trabajen con los datos directamente en lugar de tener que pasar por otros. El truco es tener los programas resultantes en una forma fácil de procesar.
En términos generales, la respuesta sería un gran NO. De los cientos de idiomas que hay por lo general, hay uno que se adapta a su problema.
Sin embargo, hay circunstancias en las que es una opción racional desarrollar un nuevo lenguaje: -
En qué idioma es bueno es composicionalidad o poner los mismos componentes juntos de diferentes maneras.
Si el problema de su dominio solo necesita que establezca un grupo de interruptores ortogonales, es probable que un idioma no agregue mucho sobre las formas, una IU gráfica o una configuración de texto simple. expediente. (Supongo que aquí un archivo lleno de clave, 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) para cualquier grado de complejidad, luego un lenguaje se volverá casi inevitable, porque la explosión combinatoria de tratar de especificar lo que quiere con cualquier otro método abruma. p>
Dejando de lado los ejercicios de aprendizaje, es razonable crear su propio lenguaje de programación solo cuando comprende otros lenguajes, su dominio de problemas específico y la forma en que los lenguajes existentes abordan ese dominio de problemas y esta comprensión es lo suficientemente completa como para que sepa un nuevo idioma es una solución razonable sin necesidad de hacer la pregunta.
La última vez que me propuse hacer eso en un proyecto de hobby comencé a especificar cómo quería que se viera la sintaxis y me di cuenta de que estaba reinventando el prólogo. Otros idiomas que pueden ser adecuados cuando crees que necesitas inventar un idioma son lisp, lua, o algo como Haskell. Básicamente, todos esos idiomas que ignoraste en la universidad porque pensaste que nunca serían útiles.
Una de las razones es con fines educativos, como ya se ha indicado. Pero hay más. Por ejemplo, hay muchos lenguajes de investigación como Sing# en el sistema operativo Singularity y BitC en Coyotos que se han diseñado porque los idiomas existentes no ofrecen las funciones requeridas ( por ejemplo, verificación en un nivel de idioma).
Tom Van Cutsem escribió recientemente una respuesta de ensayo a esta pregunta:
Resumen de viñetas (de esa página):
Probablemente nunca.
Lua es la mejor opción que puede obtener si desea incrustar el idioma básicamente en cualquier otro idioma.
Los lenguajes específicos del pequeño dominio están actualmente en, 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 de hacer debido a la complejidad que implica desarrollarlo y mantenerlo. He visto muchos proyectos que introducen algún tipo de lenguaje de scripting específico solo para ese programa, y fue lo que ralentizó el desarrollo de la base 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 emeder conocido como Lua.
Su 'edición' parece ser una pregunta sustancialmente diferente ("¿cuándo debo crear un DSL?" en lugar de la pregunta original que la gente entendió como "cuándo debo 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 para cuándo usar un DSL. Así que propongo una lista de verificación:
Si todos estos son verdaderos, entonces un DSL puede ser apropiado.
¿Existen tipos de aplicaciones asesinas, clases de algoritmos? problemas, etc., donde es mejor, a largo plazo, crear mi propia idioma?
Depende.
Tomemos nuestro cerebro. Parece ser un desastre tan complejo que encontramos fronteras con CUALQUIER lenguaje de programación (al menos ahora). Entonces, tal vez para virtualizar nuestro cerebro realmente 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 llevar a otras estrategias que también incluirían un lenguaje "mejor" para un escenario determinado.
Lea otras preguntas en las etiquetas programming-languages dsl