¿Cuándo es un nuevo idioma la herramienta adecuada para el trabajo?

Question

Durante mucho tiempo he estado intentando diferentes idiomas para encontrar el conjunto de características que quiero y no he podido encontrarlo. Tengo idiomas que se adaptan decentemente para varios proyectos míos, pero he encontrado una intersección de estos idiomas que me permitirá realizar el 99.9% de mis proyectos en un solo idioma. Quiero lo siguiente:

• Construido sobre .NET o tiene una implementación .NET
• Tiene pocas dependencias en el tiempo de ejecución de .NET tanto en tiempo de compilación como en tiempo de ejecución (esto es importante ya que uno de los principales casos de uso está en el desarrollo integrado donde el tiempo de ejecución de .NET es completamente personalizado)
• Tiene un compilador que es 100% código .NET sin dependencias no administradas
• Admite el anidamiento de expresiones arbitrarias (ver más abajo)
• Admite definiciones de operador personalizadas
• Admite inferencia de tipos
• Optimiza las llamadas de cola
• Tiene definiciones explícitas inmutables / mutables (amabilidad, he llegado a amar esto, pero puedo vivir sin él)
• Admite macros reales para una metaprogramación sólida (absolutamente imprescindible)

Los dos idiomas principales con los que he estado trabajando son Boo y Nemerle, pero también he jugado con F #.

Principales quejas contra Nemerle: el compilador tiene horribles informes de errores, la implementación es defectuosa (compilador y bibliotecas), las macros solo se pueden aplicar dentro de una función o como atributos, y es bastante pesado en cuanto a dependencia (aunque no suficiente como para romper el trato).
Principales quejas contra Boo: No hay anidamiento de expresiones arbitrarias (breakbreaker), las macros son difíciles de escribir, no hay una definición de operador personalizada (breakbreaker potencial).
Principales quejas contra F #: sintaxis fea, metaprogramación difícil de entender, licencia no libre (ruptura épica).

Entonces, cuanto más lo pienso, más pienso en desarrollar mi propio lenguaje.

Pros:

• Obtener la sintaxis exacta que quiero
• Obtenga un tiempo de respuesta que será mucho más rápido; difícil de cuantificar, pero no me sorprendería ver una productividad del desarrollador 1.5x, especialmente debido a las infraestructuras de prueba que esto puede permitir para ciertos proyectos
• Puedo agregar fácilmente funcionalidades personalizadas al compilador para jugar bien con mi tiempo de ejecución
• Obtengo algo que está diseñado y funciona exactamente como quiero, por mucho que esto parezca NIH, esto me facilitará la vida

Contras:

• A menos que pueda ganar popularidad, estaré atrapado con la carga del mantenimiento. Sé que al menos puedo superar a la gente de Nemerle, ya que creo que todos quieren algo más profesional, pero se necesita un pueblo.
• Debido a la primera estafa, desconfío de usarlo en un entorno profesional. Dicho esto, ya estoy usando Nemerle y mi propio compilador modificado personalizado, ya que no lo mantienen en absoluto.
• Si no gana popularidad, encontrar desarrolladores será mucho más difícil, hasta un punto que Paul Graham podría ni siquiera aprobar.

Entonces, con base en todo esto, ¿cuál es el consenso general? ¿Es una buena idea o una mala idea? Y quizás más útil, ¿me he perdido algunos grandes pros o contras?

Editar: Olvidé agregar el ejemplo de anidamiento; aquí hay un caso en Nemerle:

def foo = 
    if(bar == 5)
        match(baz) { | "foo" => 1 | _ => 0 }
    else bar;

Edición n.º 2: pensé que no estaría de más dar un ejemplo del tipo de código que se convertirá a este idioma si es que existe (la respuesta de S. Lott por sí sola puede ser suficiente para alejarme de hacerlo) . El código hace un uso intensivo de la sintaxis personalizada (opcode,: =, quoteblock, etc.), anidamiento de expresiones, etc. Puede consultar un buen ejemplo aquí: aquí .

Answer 1

Lamentablemente, no hay métricas o historias sobre idiomas fallidos. Solo idiomas exitosos. Claramente, las fallas superan en número a los éxitos.

¿En qué baso esto? Dos experiencias comunes.

1. Una o dos veces al año, tengo que soportar un lanzamiento para un producto / idioma / herramienta / marco que absolutamente lo cambiará todo. Mi respuesta ha sido constante durante los últimos 20 años más o menos. Muéstrame a alguien que necesite apoyo y mi empresa lo apoyará. Y eso es eso. Nunca vuelva a saber de ellos. Digamos que escuché 25 de estos.

2. Una o dos veces al año, tengo que trabajar con un cliente que tiene tecnología huérfana. En algún momento en el pasado, una programación inteligente creó una herramienta / marco / biblioteca / paquete que se utilizó internamente para varios proyectos. Entonces ese programador se fue. Nadie más puede darse cuenta de eso, y quieren que lo reemplacemos / reescribamos. Lamentablemente, tampoco podemos resolverlo, y nuestra propuesta es reescribir desde cero. Y se quejan de que su genio creó el conjunto de aplicaciones en un período de semanas, no nos puede llevar meses volver a escribirlas en Java / Python / VB / C #. Digamos que he escrito más o menos 25 de este tipo de propuestas.

Solo soy yo, un consultor.

De hecho, una situación particularmente triste fue una empresa cuya cartera completa de software de TI fue escrita por un tipo inteligente con un lenguaje y herramientas privadas. No se había ido, pero se había dado cuenta de que su lenguaje y su conjunto de herramientas habían quedado muy atrás: el estado del arte había avanzado y él no.

Y el movimiento fue, por supuesto, en una dirección inesperada. Su lenguaje y herramientas estaban bien, pero el mundo había comenzado a adoptar bases de datos relacionales, y no tenía absolutamente ninguna manera de actualizar su basura para alejarse de los archivos planos. Era algo que no había previsto. De hecho, era algo que no podía prever. [No caerás en esta trampa, ¿verdad?]

Entonces, hablamos. Reescribió muchas de las aplicaciones en Plain-Old VAX Fortran (sí, esto fue hace mucho tiempo). Y lo reescribió para usar material SQL relacional antiguo (Ingres, en ese momento).

Después de un año de codificación, tenían problemas de rendimiento. Me volvieron a llamar para revisar todas las excelentes cosas que habían hecho al reemplazar el lenguaje casero. Lamentablemente, habían hecho el peor diseño de base de datos relacional posible. Lo peor posible Tomaron sus copias de archivos, fusiones, clases y demás, e implementaron cada operación de sistema de archivos de bajo nivel utilizando SQL, duplicando las filas de la base de datos a la izquierda, derecha y centro.

Estaba tan inmerso en su visión privada del lenguaje perfecto, que no pudo adaptarse a una nueva tecnología relativamente común y dominante.

Answer 2

Yo digo ve por ello.

• Sería una experiencia increíble, independientemente del clima que llegue a producción o no.
• Si lo hace compilar a IL, entonces no tiene que preocuparse por no poder reutilizar sus ensamblados compilados con C #
• Si cree que tiene quejas válidas sobre los idiomas que mencionó anteriormente, es probable que muchos piensen como usted. Por supuesto, por cada 1000 personas interesadas puede haber 1 dispuesto a ayudarlo a mantenerlo, pero ese es siempre el riesgo

Pero aquí hay algunas cosas sobre las que se debe tener cuidado:

• Obtenga su especificación de idioma IN STONE antes del desarrollo. Asegúrese de que todas y cada una de las características del idioma se hayan resuelto de antemano, incluso las cosas que quizás solo desee en el futuro. En mi opinión, C # está cayendo lentamente en la extensión "oh-just-one-more-language-extension". trampa que conducirá a su eventual perdición.
• Asegúrese de optimizarlo. No sé lo que ya sabes; pero si no sabe, aprenda;) Nadie querrá un lenguaje que tenga una buena sintaxis pero que funcione tan lento como la implementación de JavaScript de IE.

Buena suerte: D

Answer 3

Cuando comencé mi carrera a principios de los años 90, parecía haber esta locura de que todos desarrollaran sus propios idiomas internos. Mis primeros trabajos 3 fueron con compañías que habían hecho esto. ¡Una empresa incluso había desarrollado su propio sistema operativo!

Por experiencia, diría que es una mala idea por las siguientes razones:

1) Pasará tiempo depurando el lenguaje en sí, además de la base de código encima de él
2) Cualquier desarrollador que contrates deberá pasar por la curva de aprendizaje del idioma
3) Será difícil atraer y mantener a los desarrolladores, ya que trabajar en un lenguaje propietario es un callejón sin salida para la carrera de alguien

La razón principal por la que dejé esos tres trabajos fue porque tenían lenguajes propietarios y notarás que ya no hay muchas empresas que tomen esta ruta :).

Un argumento adicional que haría es que la mayoría de los idiomas tienen equipos completos cuyo trabajo a tiempo completo es desarrollar el lenguaje. Tal vez sería una excepción, pero me sorprendería mucho si pudiera igualar ese nivel de desarrollo solo trabajando en el lenguaje a tiempo parcial.

Answer 4

  

Principales quejas contra Nemerle: el   el compilador tiene informes de errores horribles,   la implementación tiene errores como el infierno   (compilador y bibliotecas), las macros   solo se puede aplicar dentro de una función   o como atributos, y es bastante   fuerte dependencia sabia (aunque no   suficiente para que sea un factor decisivo).

Veo que tu publicación se escribió hace más de dos años. Te aconsejo que pruebes el idioma Nemerle hoy. El compilador es estable. No hay errores de bloqueo por hoy. La integración VS tiene muchas mejoras, también hay integración SharpDevelop.

Si le das una oportunidad, no te decepcionará.

Answer 5

NUNCA desarrolle su propio lenguaje.

Desarrollar su propio lenguaje es una trampa para tontos, y lo que es peor, lo limitará a lo que su imaginación puede proporcionar, además de exigirle que desarrolle tanto su entorno de desarrollo como el programa real que está escribiendo.

Los casos en los que esto no se aplica son más o menos si eres Larry Wall, los chicos de AWK o parte de un grupo sustancial de personas dedicadas a probar los límites de la programación. Si estás en alguna de esas categorías, no necesitas mi consejo, pero dudo mucho que estés apuntando a un nicho donde no hay un lenguaje de programación adecuado para la tarea Y las características de las personas que realizan la tarea.

Answer 6

Si eres tan inteligente como pareces ser (una posibilidad probable), mi consejo es que sigas adelante y hagas el diseño del lenguaje primero, repetirlo un par de veces, preguntar a algunos tipos inteligentes en los que confías. lenguaje de programación relacionado con las comunidades sobre el diseño concreto que se le ocurrió y luego tome la decisión.

En el proceso de creación del diseño, es posible que se dé cuenta de que un simple truco en Nemerle le daría todo lo que necesita, por ejemplo. Pueden ocurrir muchas cosas solo cuando se piensa mucho en un problema, y ??la solución final podría no ser lo que realmente tenía en mente al comenzar el proyecto.

En el peor de los casos, está atascado con la implementación real del diseño, pero para entonces tendrá una prueba de lectura y madurez, y sabrá con un alto grado de certeza que fue un buen camino a seguir.

Un consejo relacionado, comience con algo pequeño, solo defina las características que necesita absolutamente y luego amplíelas para obtener el resto.

Answer 7

Escribir su propio idioma no es un proyecto fácil ... Especialmente para ser utilizado en cualquier tipo de "entorno profesional"

Es una cantidad de trabajo enorme , y dudaría que pudieras escribir tu propio idioma, y ??aún escribir cualquier proyecto grande que lo use; pasarás tanto tiempo agregando las funciones que necesitas, corrigiendo errores y cosas generales de diseño de lenguaje.

Recomendaría fuertemente recomendar elegir un idioma que esté más cerca de lo que desea y extenderlo para hacer lo que necesita. Nunca será exactamente lo que quieres, pero en comparación con el tiempo que pasarás escribiendo tu propio idioma, diría que es un pequeño compromiso ...

Answer 8

Scala tiene un compilador .NET. Sin embargo, no sé el estado de esto. Es una especie de ciudadano de segunda clase en el mundo Scala (que está más centrado en la JVM). Pero podría ser una buena opción adoptar el compilador .NET en lugar de crear un nuevo lenguaje desde cero.

Scala es algo débil en el departamento de metaprogramación ATM. Es posible que la necesidad de metaprogramación se vea algo reducida por otras características del lenguaje. En cualquier caso, no creo que nadie se entristezca si implementaras funciones de metaprogramación. También hay una infraestructura de complementos de compilador en camino.

Answer 9

Creo que la mayoría de los idiomas nunca se ajustarán a todos los requisitos.

Es posible que desee combinar sus 2 idiomas favoritos (en mi caso C # y Esquema ) y usarlos juntos .

Desde un punto de vista profesional, probablemente esta no sea una buena idea.

Answer 10

Sería interesante escuchar algunas de las cosas que siente que no puede hacer en los idiomas existentes. ¿En qué tipo de proyectos está trabajando que no se puede hacer en C #?

¡Solo soy curiosidad!