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

12

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

Michael K
fuente
Seguro que tiene un enorme potencial alucinante.
2
No me queda claro qué problema resuelve este paradigma. Por cierto, LISP no es un ejemplo de lenguaje exitoso.
mouviciel
77
@mouviciel depende mucho de lo que quieres decir exactamente con "exitoso". ¿Es utilizado por la mayoría de los programadores? No. ¿Ha estado presente, en uso, mucho tiempo? Sí, 50 años y contando. ¿Le han robado la mayoría de los idiomas modernos una gran cantidad de características útiles? Si. (¿Pueden los idiomas robar aún más de los idiomas Lisp? ¡Sí!)
Frank Shearar
2
Hay una diferencia entre un lenguaje ampliamente utilizado y uno útil. Un lenguaje que explora nuevas áreas generalmente no se usa, pero puede contribuir a todos a largo plazo. Por otro lado, Java es inútil, ya que no aporta nada nuevo a la mesa (aunque definitivamente es un lenguaje exitoso para todas las cuentas).
Matthieu M.
1
Me resultaría más útil dominar Lisp que dominar Cobol.
glenatron

Respuestas:

8

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.

Mike Dunlavey
fuente
Definitivamente estoy de acuerdo con usted en la parte del carro: "el jefe de pelo puntiagudo sabe en qué idioma debe estar escrito. Java". Otro problema es lo que Joel llama el "astronauta de la arquitectura". También pude ver las DSL apiladas entre sí ad infitium (sp?). Supongo que todo se reduce a programador -> ingeniero de software -> informático.
Michael K
Y si no requiere esfuerzo para entender, lo más probable es que realmente no valga la pena :)
Michael K
4

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.

Nerian
fuente
77
RoR no es un dialecto de Ruby.
back2dos
44
@ back2dos: Estaba pensando en la metaprogramación. Por supuesto, RoR no es un lenguaje de programación diferente. Lo que quiero decir con dialecto es que incluso si todo debajo de Rails es Ruby, desde el punto de vista del desarrollador, está usando Ruby en un nivel más alto de abstracción. Un dominio. Un dialecto Él usa vistas, modelos, controladores y los está programando usando una sintaxis que se asemeja a un idioma diferente, un dialecto, por así decirlo. Esa es la belleza de un lenguaje de secuencias de comandos tan poderoso como Ruby.
Nerian
Creo que es importante ver realmente la diferencia. AspectJ es un dialecto de Java, mientras que AspectR es solo una biblioteca Ruby. La diferencia es realmente el idioma. Ruby fue diseñado para proporcionar esa flexibilidad y expresividad y Java no. Ambos se pueden considerar lenguajes de uso general, la diferencia es que Ruby es generalmente lo suficientemente expresivo como para eliminar la necesidad de un DSL real para cualquier propósito general, mientras que Java no lo es, aunque por ejemplo usas habitualmente vistas, modelos y controladores.
back2dos
1

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.

SK-logic
fuente
Disculpe mi ignorancia: un eDSL podría ser un preprocesador para otro lenguaje, ¿verdad?
Michael K
@ Michael, sí, es posible implementar eDSL de esta manera, vea CamlP4 por ejemplo. Pero más a menudo eDSL se basa en las características propias del lenguaje (por ejemplo, macros Lisp, plantillas C ++, etc.).
SK-logic
1

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.

glenatron
fuente
Puede agregar FoF con se está utilizando para desarrollar controladores para el núcleo múltiple Barrelfish. Un lenguaje para desarrollar DSL en :)
Matthieu M.
0

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.

Kakungulu
fuente