¿Es práctica la programación orientada al lenguaje?

Leí este artículo sobre programación orientada al lenguaje. Señala algunas debilidades en los enfoques modernos de procedimiento / OOP para la programación, y sugiere un nuevo paradigma de programación que los resolverá

Estoy a favor de las partes pequeñas y poco acopladas del programa: es mucho mejor aprender muchas cosas pequeñas, todas las cuales usará, que un par de cosas grandes, de las que solo usa partes y piezas.

Al leer el artículo, tuve la impresión de que el autor estaba promoviendo una de dos cosas:

• Una multitud de lenguajes de scripting fáciles de crear
• Un lenguaje único y fácilmente extensible que puede reescribirse para satisfacer las necesidades del programador.

Si él está sugiriendo el segundo, yo respondería con "¡Ya está hecho!" y da a Lisp como ejemplo. Como sugiere Paul Graham, los idiomas parecen moverse continuamente hacia esto de todos modos .

En cuanto al primero, creo que es una buena idea, si hay un lenguaje subyacente que los una a todos. Ese me parece ser el punto débil: la comunicación entre los idiomas. ¿Usaría llamadas, que es un concepto de procedimiento o transmisión de mensajes, que me recuerda la comunicación entre procesos? Me gustaría tener la oportunidad de trabajar con lenguajes específicos de dominios pequeños, si es fácil usarlos todos al mismo tiempo. ¿Sería práctico este enfoque (LOP)?

He estado abogando por las DSL durante mucho tiempo, pero me preocupa lo que les sucede a las Buenas Ideas cuando se convierten en carretas. Se crean productos que anuncian The Good Idea, prometiendo que todo lo que tiene que hacer es obtener uno , y estará en el grupo, sin tener que pensar con mucho cuidado sobre lo que significa.

¿Qué es un idioma? Es un vocabulario y una sintaxis en la que los significados se pueden comunicar, ¿verdad? Cada vez que declara una variable, escribe una función, define una clase, está construyendo un nuevo idioma, agregando sustantivos y verbos a un idioma existente. Ahora puedes decir cosas que antes no podías.

Creo que lo que hace que un lenguaje sea específico del dominio es la medida en que expresa naturalmente los conceptos mentales que se están comunicando, y creo que hay una medida simple de eso. Básicamente, si existe un requisito X independiente simple e independiente, que podría incluirse en el programa o no, su implementación correcta requiere algún conjunto de inserciones, eliminaciones y reemplazos de código Y. Se puede mostrar un simple diferencial de antes y después Y. El número N de tales cambios es una medida de cuán específico es el dominio del idioma. El N más pequeño es, para los requisitos típicos, el mejor.

No depende necesariamente de la sintaxis elegante, las estructuras de control, el paso de mensajes o lo que tenga. De lo que depende es de qué manera concisa implemente el requisito. Muchas herramientas afirman hacer esto, pero las afirmaciones no son actuales. Tiene que ser real .

A veces es necesaria una tecnología inusual . Aquí está mi ejemplo favorito. Cuando es así, ilustra el punto de que puede requerir un esfuerzo por parte de los programadores para comprenderlo. Entonces, la especificidad del dominio (y la facilidad de mantenimiento) no es lo mismo que la legibilidad .

Por lo tanto, estoy de acuerdo con el segundo enfoque, que un buen lenguaje es uno que fácilmente permite construir los idiomas necesarios sobre él. (Eso es lo que me gustó de Lisp.) Pero aún más importante es que los programadores necesitan saber cómo construir idiomas para que coincidan con los dominios en los que están trabajando, y estar dispuestos a escalar las curvas de aprendizaje de dichos idiomas.

Realmente no veo que eso suceda. En cambio, están atrapados en los "programas = algoritmos + estructura de datos", o "los sustantivos se convierten en clases y los verbos en métodos". No están trabajando en términos de cómo tomar dominios de pensamiento y linguificarlos para obtener la máxima concisión.

Ese es el enfoque de Ruby.

• Mantenga el lenguaje central simple y extiéndalo a través de gemas
• Crea dialectos de Ruby para dominios específicos a través de parches de mono. ig Ruby on Rails.

No sé si esto es mejor, pero supongo que es muy pragmático.

El enfoque LOP es extremadamente práctico. Tenga en cuenta que no necesariamente tiene que implementar "lenguajes de secuencias de comandos": la metodología también es aplicable a los eDSL y, por lo general, se compilan de manera eficiente. Estoy usando este enfoque en literalmente todo mi trabajo de desarrollo.

Veremos mucho más sobre los lenguajes específicos de dominio en el futuro, a juzgar por las personas que están hablando de ellos ahora. He notado que Martin Fowler también habla mucho de ellos y algunos artículos interesantes a través de Lambda The Ultimate sobre el tema, entre otros.

Eso me sugiere que esta es definitivamente una dirección en la que sopla el viento con respecto al diseño del lenguaje de programación y las plataformas de programación. De alguna manera ya lo ha sido durante un tiempo, una de las ventajas de Ruby (como alguien ya observó) es que facilita la creación de DSL, pero en realidad hay un montón de ellas en aplicaciones y bibliotecas de programación que ya utilizamos.

Estoy usando LOP cada vez que programo solo. Descubrí que en algunos proyectos, no hay otra forma de cumplir con el cronograma. En una alegoría simple, uno puede equiparar el uso de LOP con herramientas eléctricas. Si está trabajando solo en el taller, no puede hacer las cosas manualmente y cumplir con la fecha límite. Si hay otras personas con usted, coordinar el uso de esas herramientas eléctricas es esencial para la eficiencia y la seguridad.
En modo equipo, LOP requiere preparación organizativa para evitar un desastre de la Torre de Babel.