boo - una - ¿Cuándo es un nuevo idioma la herramienta adecuada para el trabajo?
que idiomas aprender para el futuro (10)
Durante mucho tiempo he estado probando diferentes idiomas para encontrar el conjunto de características que quiero y no he podido encontrarlo. Tengo idiomas que se adaptan decentemente a varios proyectos míos, pero he llegado a una intersección de estos idiomas que me permitirá hacer el 99.9% de mis proyectos en un solo idioma. Quiero lo siguiente:
- Construido sobre .NET o tiene una implementación de .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% de código .NET sin dependencias no administradas
- Admite anidamiento de expresiones arbitrarias (ver a continuación)
- Admite definiciones de operador personalizadas
- Admite la inferencia de tipo
- Optimiza las llamadas de cola
- Tiene definiciones explícitas inmutables / mutables (sutileza: me ha encantado, pero puedo vivir sin ella)
- Admite macros reales para metaprogramación fuerte (imprescindible)
Los dos idiomas principales con los que he estado trabajando son Boo y Nemerle, pero también jugué con F #.
Principales quejas contra Nemerle: el compilador tiene horribles informes de errores, la implementación tiene errores (compilador y bibliotecas), las macros solo se pueden aplicar dentro de una función o como atributos, y es bastante dependiente de la dependencia (aunque no es suficiente que sea un dealbreaker).
Principales quejas contra Boo: No hay anidamiento de expresiones arbitrarias (dealbreaker), las macros son difíciles de escribir, no hay una definición de operador personalizado (potencial dealbreaker).
Principales quejas contra F #: sintaxis fea, metaprogramación difícil de entender, licencia no libre (rompedor épico).
Así que cuanto más lo pienso, más pienso en desarrollar mi propio idioma.
Pros:
- Obtenga 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 la funcionalidad personalizada al compilador para jugar bien con mi tiempo de ejecución
- Obtengo algo que está diseñado y funciona exactamente de la manera que quiero, aunque suene como NIH, esto hará mi vida más fácil
Contras:
- A menos que pueda obtener popularidad, me quedaré con la carga del mantenimiento. Sé que al menos puedo acabar con la gente de Nemerle, ya que creo que todos quieren algo más profesional, pero se necesita un pueblo.
- Debido a la primera estafa, soy cauteloso de usarlo en un entorno profesional. Dicho esto, ya estoy usando Nemerle y estoy usando mi propio compilador modificado ya que no lo están manteniendo del todo bien.
- Si no gana popularidad, encontrar desarrolladores será mucho más difícil, hasta tal punto que Paul Graham ni siquiera lo tolerará.
Entonces, en base a todo esto, ¿cuál es el consenso general? ¿Es esta una buena idea o una mala idea? Y tal vez de manera más útil, ¿me he perdido algún gran pros o contra?
Editar: Olvidé agregar el ejemplo de anidación. Aquí hay un caso en Nemerle:
def foo =
if(bar == 5)
match(baz) { | "foo" => 1 | _ => 0 }
else bar;
Editar # 2: Me imaginé 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 asustarme 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í .
Si eres tan inteligente como pareces (una posible posibilidad), mi consejo es seguir adelante y hacer primero el diseño del lenguaje, repetirlo un par de veces, preguntar a algunos tipos inteligentes en quienes confías en el lenguaje de programación inteligente relacionado. comunidades sobre el diseño concreto que se le ocurrió y luego tomar la decisión.
Puede que te des cuenta en el proceso de crear el diseño que solo un truco rápido en Nemerle te daría todo lo que necesitas, por ejemplo. Muchas cosas pueden suceder solo cuando se reflexiona sobre un problema, y la solución final podría no ser lo que realmente se tenía en mente al comenzar el proyecto.
En el peor de los casos, está obligado a implementar realmente el diseño, pero para entonces tendrá una lectura de prueba y madurez, y sabrá con un alto grado de certeza que era un buen camino a seguir.
Un consejo relacionado, comience de a poco, solo defina las características que necesita y luego edifíquelas para obtener el resto.
Creo que la mayoría de los idiomas nunca se ajustarán a la totalidad de la factura.
Es posible que desee combinar sus 2 idiomas favoritos (en mi caso C # y Scheme ) y usarlos juntos.
Desde un punto de vista profesional, esta probablemente no sea una buena idea.
Cuando comencé mi carrera a principios de los 90, parecía haber esta locura de que todos desarrollaran sus propios lenguajes internos. Mis primeros 3 trabajos fueron con compañías que habían hecho esto. ¡Una compañía incluso había desarrollado su propio sistema operativo!
Por experiencia, diría que esta es una mala idea por las siguientes razones:
1) Pasarás un tiempo depurando el idioma en sí mismo además del código base en la parte superior
2) Cualquier desarrollador que contrates tendrá que 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 no muchas compañías siguen esta ruta :).
Un argumento adicional que haré 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 trabajando solo en el idioma a tiempo parcial.
Escribir su propio idioma no es un proyecto fácil. Especialmente uno para ser utilizado en cualquier tipo de "entorno profesional"
Es una gran cantidad de trabajo, y dudo que pueda escribir su propio idioma, y todavía escribir cualquier proyecto grande que lo use; pasará tanto tiempo agregando las características que necesita, corrigiendo errores y cosas de diseño de lenguaje en general.
Recomiendo encarecidamente que elija un idioma que esté más cerca de lo que desea y lo amplíe para que haga lo que necesita. Nunca será exactamente lo que quieres, pero comparado con el tiempo que pasarás escribiendo tu propio idioma, diría que es un pequeño compromiso.
Lamentablemente, no hay métricas o historias en torno a los idiomas fallidos. Solo idiomas exitosos. Claramente, los fracasos superan en número a los éxitos.
¿En qué baso esto? Dos experiencias comunes
Una o dos veces al año, tengo que soportar un lanzamiento para un producto / idioma / herramienta / marco que cambiará absolutamente todo. Mi respuesta ha sido constante durante los últimos 20 o más años. Muéstrame a alguien que necesita ayuda y mi compañía los apoyará. Y eso es eso. Nunca más noticias de ellos. Digamos que he escuchado 25 de estos.
Una o dos veces al año, tengo que trabajar con un cliente que tiene tecnología huérfana. En algún momento del pasado, algunos programas inteligentes crearon una herramienta / framework / library / package que se utilizó internamente para varios proyectos. Entonces ese programador se fue. Nadie más puede resolver esa maldita cosa, y quieren que la reemplacemos / reescribamos. Lamentablemente, tampoco podemos resolverlo, y nuestra propuesta es volver a escribir desde cero. Y se quejan de que su genio creó el conjunto de aplicaciones en un período de semanas, no nos llevaría meses reescribirlas 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 la de una compañía cuyo portafolio completo de software de TI fue escrito por un tipo inteligente con un lenguaje y herramientas privados. No se había ido, pero se había dado cuenta de que su lenguaje y su conjunto de herramientas se habían quedado atrás en el tiempo: el estado del arte había avanzado, y no lo había hecho.
Y el movimiento fue, por supuesto, en una dirección inesperada. Su lenguaje y sus herramientas estaban bien, pero el mundo había comenzado a adoptar bases de datos relacionales, y no tenía absolutamente ninguna forma 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, ¿quieres?]
Entonces, hablamos. Reescribió muchas de las aplicaciones en Plain-Old VAX Fortran (sí, esto fue hace mucho tiempo). Y lo reescribió para usar cosas antiguas de SQL relacional (Ingres, en ese momento).
Después de un año de codificación, tenían problemas de rendimiento. Me llamaron para revisar todas las cosas geniales que habían hecho al reemplazar el lenguaje de fabricación casera. Lamentablemente, habían hecho el peor diseño de base de datos relacional posible. Lo peor posible Habían tomado sus copias de archivos, fusiones, géneros 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, a la derecha y al centro.
Estaba tan sumido en su visión privada del lenguaje perfecto, que no podía adaptarse a una nueva tecnología relativamente común y omnipresente.
NUNCA JAMÁS desarrolles tu propio idioma.
Desarrollar su propio idioma es una trampa tonta, y lo que es peor, lo limitará a lo que su imaginación puede proporcionarle, además de exigirle que trabaje tanto en su entorno de desarrollo como en 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 considerable 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 de que tengas como objetivo un nicho en el que no exista un lenguaje de programación adecuado para la tarea Y las características de las personas que realizan la tarea.
Scala tiene un compilador .NET. No sé el estado de esto sin embargo. Es una especie de ciudadano de segunda clase en el mundo de Scala (que está más centrado en la JVM). Pero podría ser una buena idea adoptar el compilador .NET en lugar de crear un nuevo lenguaje desde cero.
Scala es un poco débil en el cajero automático del departamento de metaprogramación. Es posible que la necesidad de metaprogramación se vea reducida por otras características del lenguaje. En cualquier caso, no creo que nadie esté triste si implementas funciones de metaprogramación. También hay una infraestructura de plug-ins de compilador en el camino.
Sería interesante escuchar algunas de las cosas que cree que no puede hacer en los idiomas existentes. ¿En qué tipo de proyectos estás trabajando que no se puede hacer en C #?
¡Solo soy curios!
Yo digo que lo haga.
- Sería una experiencia increíble, independientemente del clima, llega a la producción o no.
- Si lo haces compilar hasta IL, entonces no tienes que preocuparte por no poder volver a utilizar tus ensamblajes compilados con C #
- Si cree que tiene quejas válidas sobre los idiomas que enumeró anteriormente, es probable que muchos piensen igual que usted. Por supuesto, por cada 1000 personas interesadas podría haber 1 dispuesto a ayudarlo a mantenerlo, pero ese es siempre el riesgo
Pero aquí hay algunas cosas de las que se debe advertir:
- Obtenga su especificación de idioma IN STONE antes del desarrollo. Asegúrese de que todas las características del lenguaje estén resueltas de antemano, incluso las cosas que tal vez solo desee en el futuro. En mi opinión, C # está cayendo lentamente en la trampa de "oh-solo-uno-más-extensión-de-lenguaje" que conducirá a su destino final.
- Asegúrese de optimizarlo. No sé lo que ya sabes; pero si no lo sabe, aprenda;) Nadie querrá un lenguaje que tenga una sintaxis agradable, pero que funcione tan lento como la implementación de JavaScript de IE.
Buena suerte: D
Principales quejas contra Nemerle: el compilador tiene horribles informes de errores, la implementación tiene errores (compilador y bibliotecas), las macros solo se pueden aplicar dentro de una función o como atributos, y es bastante dependiente de la dependencia (aunque no es suficiente que sea un dealbreaker).
Veo que tu publicación se escribió hace más de dos años. Te aconsejo que pruebes el idioma de Nemerle hoy. El compilador es estable. No hay errores de bloqueo para hoy. La integración VS tiene muchas mejoras, también existe la integración SharpDevelop.
Si le das una oportunidad, no te decepcionará.