00:00:08 Lenguajes específicos de dominio (DSLs) y su diversidad.
00:01:36 Ejemplos de DSLs: AMPL para programación matemática y HTML para páginas web.
00:03:00 Las ventajas de usar DSLs sobre lenguajes de programación de propósito general para tareas específicas.
00:05:22 El uso por parte de Lokad de un DSL para la optimización de supply chain en situaciones diversas.
00:07:23 Los beneficios de usar un DSL para una configuración más rápida y confiable.
00:09:35 Limitaciones de un DSL y sus beneficios en la optimización de supply chain.
00:12:55 Implicaciones de seguridad al usar un DSL en comparación con lenguajes de programación generales.
00:13:01 El proceso que consume mucho tiempo para desarrollar un DSL.
00:14:49 Consejos para startups que consideran desarrollar su propio DSL.
00:16:01 La subexplotación de DSLs y las soluciones tradicionales que conducen a productos insatisfactorios.
00:17:26 El dilema de usar DSLs frente a lenguajes de programación convencionales y sus resultados.
00:18:32 SQL y HTML como ejemplos exitosos de lenguajes específicos de dominio.
00:19:46 El potencial de los DSLs en varias industrias y su poder transformador.
00:21:19 Conclusión y potenciales desarrollos futuros en el uso de DSLs.

Resumen

En esta entrevista, Kieran Chandler discute los lenguajes específicos de dominio (DSLs) con Joannes Vermorel, el fundador de la empresa supply chain optimization Lokad. Los DSLs son lenguajes de programación diseñados para tareas específicas, a diferencia de los lenguajes de propósito general como Java o Python. Vermorel explica que los DSLs se utilizan en industrias como la automotriz, donde proporcionan una operación libre de errores para componentes críticos como los sistemas de frenos antibloqueo. También discute el desarrollo por parte de Lokad de su propio DSL, Envision, para agilizar la optimización de supply chain. Vermorel destaca las ventajas de los DSLs, tales como cálculos eficientes y una personalización hecha a la medida para dominios específicos, al mismo tiempo que reconoce los desafíos y la naturaleza laboriosa del desarrollo.

Resumen Ampliado

En esta entrevista, Kieran Chandler, el presentador, discute los lenguajes específicos de dominio (DSLs) con Joannes Vermorel, el fundador de Lokad, una empresa de software especializada en la optimización de supply chain.

Los DSLs son una clase específica de lenguajes de programación diseñados para resolver tipos muy particulares de problemas, a diferencia de los lenguajes de programación generales como Java o Python, que están destinados a abordar una gama más amplia de tareas. Los lenguajes de programación generales están diseñados para proporcionar una forma conveniente, productiva y eficiente de hacer todo lo que se puede hacer con computadoras, mientras que los DSLs se centran en resolver problemas específicos. Algunos de los primeros lenguajes específicos de dominio, como AMPL, fueron creados para la programación matemática y otras tareas muy específicas.

Los DSLs se utilizan en aplicaciones del mundo real para implementar componentes críticos en diversas industrias. Por ejemplo, en el sector automotriz, un DSL podría utilizarse para desarrollar el software que controla el sistema antibloqueo de frenos (ABS) en un automóvil. El objetivo es crear un sistema casi libre de errores, ya que una falla en este componente podría conducir a una pérdida de la capacidad de frenado. En contraste, los lenguajes de programación convencionales podrían no proporcionar el mismo nivel de certeza en una operación libre de errores.

Otro ejemplo de un DSL es HTML, que está diseñado para crear páginas web. HTML es más accesible y sencillo que los lenguajes de programación generales, lo que lo hace adecuado para usuarios no técnicos o incluso para estudiantes de primaria. Sin embargo, esta simplicidad trae limitaciones, ya que HTML está restringido en sus capacidades, permitiendo únicamente a los usuarios controlar el diseño de una página web en lugar de habilitar tareas más complejas como controlar robots o desarrollar inteligencia artificial.

Cuando se le pregunta por qué se utilizan los DSLs en lugar de lenguajes de programación convencionales más expresivos, Vermorel explica que usar un lenguaje de programación general para tareas que se adaptan mejor a un DSL complicaría en exceso el proceso. Por ejemplo, usar un lenguaje de programación general para el diseño de páginas web implicaría controlar cada píxel en la pantalla, en lugar de utilizar elementos simples de un lenguaje de marcado, como especificar el título, el tamaño de fuente o la justificación del texto, como es el caso de HTML.

Vermorel explica que los problemas de supply chain son diversos, ya que no hay dos empresas exactamente iguales. Las empresas tienen diferentes infraestructuras de TI, paisajes aplicativos, y varias combinaciones de ERPs, WMSs y otros sistemas. Esta diversidad crea desafíos para las soluciones de software que intentan abordar la optimización de supply chain con un enfoque único para todos. Los marcos tradicionales que dependen de la configuración a menudo requieren una personalización y configuración extensas para cada cliente, lo que consume mucho tiempo y resulta costoso.

Reconociendo que cada situación de cliente requiere un software diferente, Lokad buscó desarrollar un proceso más eficiente y confiable. Decidieron crear su propio DSL, Envision, para agilizar el proceso de configuración y hacerlo más rápido y productivo. Vermorel contrasta el uso de Envision con lenguajes de programación convencionales como C#, F# y TypeScript. Aunque ya utilizan extensamente estos lenguajes de programación genéricos, abordar las solicitudes de los clientes con ellos resultó ser lento y costoso. Envision fue diseñado para ser más ágil y estar mejor adaptado a las demandas únicas de la optimización de supply chain.

Vermorel destaca que una de las razones por las que muchas soluciones de supply chain software se vuelven infladas es porque intentan acomodar cada característica y caso de uso posible. Lokad eligió un enfoque diferente, desarrollando un DSL central altamente enfocado, siendo el producto de software Envision y sus capacidades. Esto les permite crear implementaciones hechas a la medida para cada cliente utilizando Envision, mientras que el compilador y el entorno para Envision están implementados en C#, F# y TypeScript.

Vermorel explica que usar un DSL puede introducir limitaciones, pero esto puede ser ventajoso en ciertas situaciones. Por ejemplo, al optimizar una gran supply chain con un conjunto de datos considerable, puede ser difícil asegurar que los cálculos se completen en un plazo específico utilizando lenguajes de programación genéricos. Un DSL con las limitaciones adecuadas puede garantizar que los cálculos se completen a tiempo, evitando disrupciones en la supply chain.

Sin embargo, desarrollar un DSL puede ser un proceso que consume mucho tiempo. Vermorel comenta que a su empresa le tomó casi una década desarrollar su propio DSL. Este largo tiempo de desarrollo puede estar en desacuerdo con la naturaleza acelerada de las startups. El desafío clave al desarrollar un DSL es replantear los problemas fundamentales a resolver y definir los primitivos lógicos necesarios para solucionarlos. Esto implica diseñar la sintaxis y los operadores del lenguaje de programación de manera que estén alineados con el problema en cuestión.

A pesar de los desafíos, Vermorel cree que el camino de los DSLs ha sido subexplotado y podría ser beneficioso para las startups. Desarrollar un DSL no reemplaza la necesidad de ingenieros de software ni de lenguajes de programación convencionales; de hecho, puede requerir incluso más ingenieros de software. Sin embargo, al centrarse en un dominio de problemas específico, un DSL puede ofrecer ventajas en términos de eficiencia, seguridad y optimización.

Vermorel comienza discutiendo las limitaciones del software empresarial tradicional, que a menudo se vuelve inflado y difícil de gestionar. Luego introduce el concepto de DSLs como una solución potencial a este problema. Los DSLs son lenguajes de programación hechos a la medida para dominios o industrias específicos, ofreciendo capacidades y optimizaciones especializadas.

Vermorel señala que muchos productos de software en el mercado hoy en día son insatisfactorios y tienden a llegar a parecerse a grandes softwares empresariales, lo cual no es el resultado ideal. Da el ejemplo de los sistemas de gestión de pedidos multicanal (MOMS), que han llegado a parecerse a sistemas de planificación de recursos empresariales (ERP) con cientos de pantallas y miles de opciones. El objetivo inicial de diferenciarse de los ERP se ha perdido, y el producto resultante no es mucho mejor que el ERP original.

Él argumenta que el uso de DSLs podría haber conducido a un producto más ágil y poderoso en el caso de MOMS. Sin embargo, adoptar un DSL conlleva sus propios desafíos, como años de dolores de cabeza y limitaciones. Por otro lado, usar un lenguaje de programación más convencional podría permitir un crecimiento más rápido, pero podría dar lugar a un producto ingobernable.

Un ejemplo exitoso de un DSL es SQL (Structured Query Language), un lenguaje de programación utilizado para gestionar bases de datos relacionales. Vermorel señala que cuando un DSL tiene mucho éxito, la gente a menudo olvida que en primer lugar se trata de un DSL. Él cree que existe un potencial significativo para los DSLs en diversas industrias, incluida la optimización de supply chain con Lokad.

Chandler pregunta acerca de otras industrias donde los DSLs podrían ser beneficiosos. Vermorel sugiere el marketing como una posibilidad, donde las empresas a menudo luchan con soluciones de software complejas que no son lo suficientemente potentes para satisfacer sus necesidades. Los recursos humanos son otra área donde los DSLs podrían ofrecer una solución hecha a la medida, ya que reflejan la cultura única de cada empresa, lo que dificulta que los enfoques genéricos sean efectivos.

Transcripción Completa

Kieran Chandler: Hoy vamos a descubrir un poco más sobre cómo se desarrollan y también a entender por qué pueden ser ventajosos en comparación con algunos de los lenguajes de programación convencionales. Así que Joannes, quizás podrías comenzar contándonos un poco más acerca de lo que realmente son los DSLs y cómo funcionan.

Joannes Vermorel: Los DSLs son una clase específica de lenguajes de programación que, a diferencia de los lenguajes de programación generales como Java, Python y C++, no están diseñados para ser una solución para todo lo que se puede programar en una computadora. Los lenguajes de programación convencionales están orientados a brindarte la manera más conveniente, productiva y eficiente de hacer todo lo que puedes hacer con computadoras o con muchas computadoras si lo deseas. Pero los lenguajes de programación específicos de dominio son algo totalmente diferente. Es programación, por lo que viene con código, y es formal y abstracta, pero está diseñada para resolver tipos muy específicos de problemas. Por ejemplo, históricamente, los primeros lenguajes de programación específicos de dominio eran en su mayoría sobre cosas como AMPL, un lenguaje de programación matemática, diseñado para realizar tareas muy específicas.

Kieran Chandler: Entonces, ¿para qué tipo de problemas se usaría un lenguaje específico de dominio, y para qué se utilizan en el mundo real?

Joannes Vermorel: En el mundo real, una aplicación histórica sería implementar componentes críticos. Por ejemplo, deseas tener un software que controle el ABS de tu automóvil, el sistema antibloqueo de frenos, y quieres tener la certeza de que esto nunca se fallará, porque si falla, tu automóvil de repente no tendrá capacidad de frenado. Entonces, esa es una situación bastante grave, y pensarías, intentemos no tener algo demasiado defectuoso aquí. Eso corresponde al ámbito embebido. Luego tienes problemas como HTML para páginas web, donde se trata de un lenguaje de programación, pero se quiere que sea más accesible. Hay una buena razón por la que se puede aprender HTML en la escuela primaria; es porque es muy simple. Lo básico es literalmente muy accesible incluso para personas que son bastante no técnicas. Pero el trade-off es que HTML te permite controlar el diseño de una página web; no te permite controlar un robot o hacer inteligencia artificial.

Kieran Chandler: Así que, son muy simples y más limitados. Quiero decir, ¿por qué no usas lenguajes de programación convencionales, que tienen más expresividad para estas tareas porque son capaces de hacerlo?

Joannes Vermorel: Si piensas en lo que significaría para las páginas web HTML, por ejemplo, en lugar de tener simplemente un lenguaje de marcado donde puedes decir “título”, “tamaño de fuente grande” y “cuerpo de texto”, “quiero que el texto esté justificado”, y demás – controles simples – tendrías que pensar, “Oh, voy a controlar cada píxel en mi pantalla”, y eso no es práctico.

Kieran Chandler: …sería lo que podrías obtener de un enfoque de muy bajo nivel, y si quieres ser aún más de bajo nivel, dices, bueno, voy a controlar directamente mis tarjetas gráficas para tener un rendimiento superalto, y eso es quizás lo que, si de hecho estás construyendo un motor 3D para videojuegos, terminarías haciendo. Pero si solo quieres hacer algo simple, como una página web, simplemente tomaría una cantidad infinita de tiempo hacerlo de esa manera. En los videojuegos 3D, es mucho más sencillo y directo pasar por IDs y cosas como HTML. Bien, y es un tema con el que estamos muy familiarizados en Lokad, dado que en cierto modo generamos nuestro propio DSL. Entonces, ¿por qué fue algo tan interesante para nosotros como empresa de supply chain?

Joannes Vermorel: Lo que resulta algo irritante del supply chain es que los problemas son tan diversos. Es literalmente que no hay dos empresas iguales, o sea, no exactamente iguales. No tienen el mismo paisaje aplicativo. Algunas empresas tienen un ERP; muchas tienen dos ERPs por malas razones. Tienen un WMS; tienen múltiples WMS. Tienen 10 ERPs diferentes porque operan en diez países distintos con paisajes de TI diferentes. Tienen la plataforma de ecommerce que llegó después, que es algo aparte. Tienen aceleradores extra. Así que el problema era: queríamos hacer optimización de supply chain, y me di cuenta durante los primeros años de que, literalmente, el enfoque clásico de tener un framework que se pudiera configurar simplemente no funcionaría. Quiero decir, las situaciones eran tan diversas que terminábamos con una cantidad masiva de personalización y configuración para cada cliente. Y literalmente, cuando empiezas a pensar en tener un software completamente fuera de la caja pero que simplemente toma seis meses para hacer alguna configuración con el software, ¿realmente es configuración? ¿No es como reinventar literalmente una nueva pieza de software? La realidad es, sí, lo haces. Y así, decidimos llevar este ángulo al siguiente paso lógico, que es: bueno, si cada vez que nos enfrentamos a una situación se requiere una pieza de software diferente, ¿qué tal si tenemos algo que respalde este proceso para hacerlo muy productivo, muy rápido, muy confiable? Y en realidad, de ahí surgió la idea de tener un DSL, un lenguaje específico de dominio.

Kieran Chandler: Entonces, si has usado un lenguaje de programación más convencional, esa configuración tomaría mucho más tiempo, mientras que tener ese tipo de entorno restringido significa que puedes hacer las cosas mucho más rápido.

Joannes Vermorel: Es interesante. O sea, en Lokad usamos lenguajes de programación genéricos. Desde el principio hemos utilizado C-sharp, C-sharp.NET, que es básicamente el stack de programación de Microsoft, y más tarde añadimos F-sharp y TypeScript para diversos propósitos. Así que ya usamos de forma extensa lenguajes de programación genéricos, y estoy muy familiarizado con lo que se puede hacer con esos lenguajes. Pero nos dimos cuenta durante los primeros años de Lokad de que abordar las solicitudes de los clientes con este tipo de lenguajes era increíblemente lento y costoso. Así que necesitábamos algo mejor, y no era el hecho de que no conociéramos esos lenguajes. Nos dimos cuenta de que recurrir a ellos para cada situación del cliente era algo espantoso. Y, por cierto, esa es también una de las razones por las que todas esas soluciones de software de supply chain terminan siendo piezas gigantescas y monstruosas de software. Es porque intentan incluir en su producto de software todo, y luego terminas con un monstruo de software. Entonces, decidimos decir: bueno, ¿y si el producto de software era

Kieran Chandler: ¿Y si el producto de software fuera simplemente un DSL y sus capacidades, es decir, algo que fuera como un núcleo súper compacto, y luego, cuando vayamos a un cliente, crearíamos una implementación hecha a la medida implementada no en C-sharp, sino en Envision, nuestro propio DSL? Pero el compilador y el entorno para Envision, en realidad, no están implementados en Envision, sino en C-sharp, F-sharp y TypeScript.

Joannes Vermorel: Vale.

Kieran Chandler: Mencionaste que, obviamente, los supply chain son increíblemente diversos y cada cliente es increíblemente diferente. ¿Introduce el uso de un DSL algún tipo de limitación? ¿Te impide, en realidad, implementar ciertas cosas?

Joannes Vermorel: Absolutamente, y ese es exactamente el punto, por sorprendente que parezca. Verás, por ejemplo, un problema muy básico al que te enfrentas es cuando tienes un grande supply chain que deseas optimizar y terminas con un conjunto de datos bastante considerable. Digamos que tienes un terabyte de datos. No es absolutamente enorme; puedes ir a un supermercado y comprar un disco duro de 1 terabyte por algo como 100 euros, lo cual es bastante barato. Así que, es una gran cantidad de datos, pero no gigantesca. Ahora, el problema es que tu conjunto de datos se actualizará cada día, y quieres, por ejemplo, hacer un recorrido sobre este conjunto para tomar inteligentes supply chain decisions, como decisiones de reabastecimiento y de precios.

Ahora, el problema es que si tienes un lenguaje de programación genérico, ¿cómo aseguras que el cómputo tomará, digamos, menos de 60 minutos? Es muy difícil. En cuanto tienes bucles o construcciones arbitrarias, se vuelve súper difícil demostrar que tu ejecución se ajustará a un plazo específico, lo cual puede ser un problema si el cálculo que realizas para tomar ciertas decisiones, como decisiones de reabastecimiento, necesita encajar en una secuencia de ejecución estricta dentro de tus sistemas ERP. Realmente necesitas que esta ejecución se complete en 60 minutos; de lo contrario, interrumpes todo tu supply chain porque el cálculo lleva demasiado tiempo.

Así que, típicamente, ese es el tipo de situación en la que los lenguajes de programación genéricos no pueden darte estas garantías, porque precisamente puedes hacer de todo con ellos, por lo que es muy difícil obtener cualquier tipo de garantía con esos lenguajes. Pero con un DSL que tenga las limitaciones adecuadas, hay otro ángulo: el diseño. Es realmente muy difícil ofrecer un entorno de programación que sea completamente seguro usando un lenguaje genérico. Con lenguajes de programación genéricos como Java, Python o C-sharp, te expones a clases enteras de vulnerabilidades en seguridad. Si puedes hacer cualquier cosa con una computadora, puedes hacer cosas que son relativamente peligrosas desde una perspectiva de IT security.

De nuevo, tener un DSL significa que hay clases enteras de cosas que ni siquiera están accesibles para ti, como interactuar con el sistema operativo, y de este modo se eliminan clases completas de problemas que ni siquiera te conciernen. Lo único que te importa es la optimización de supply chain.

Kieran Chandler: Sí, y eso es de lo que hablamos en nuestro episodio de seguridad. Miremos, tal vez, el desarrollo de un DSL. O sea, ¿cuánto tarda realmente en desarrollarse uno de estos lenguajes? En tu caso, ¿cuánto tardó en desarrollarse Envision?

Joannes Vermorel: Es una buena pregunta. Literalmente toma una década, lo cual es algo insano. Así que, cuando eres una start-up, ya sabes, dices “muévete rápido y rompe las cosas”, tengamos un producto mínimo viable que se pueda vender en seis meses, y luego empiezas a crear tu propio DSL, y es como, literalmente, un proceso de

Kieran Chandler: Ciertamente, un esfuerzo de varios años, y el desafío clave es que realmente tienes que replantear en el núcleo los problemas que estás resolviendo. ¿Cuáles son los aspectos fundamentales de esos problemas, y cuáles deberían ser los primitivos lógicos que necesitas tener a tu disposición para resolverlos con computadoras? Es incluso peor que simplemente inventar nuevas palabras; es inventar primitivos lógicos para conectar conceptos, de modo que al final puedas encuadrar clases enteras de soluciones en este lenguaje para obtener soluciones generadas de manera completamente automatizada por las computadoras. Pero literalmente estás pensando en el propio lenguaje de programación, su sintaxis, el tipo de operadores que tienes, lo cual es… y realmente quieres que esas cosas estén completamente alineadas con el problema que intentas resolver. Entonces, si fueras una start-up comenzando ahora, ¿recomendarías emprender ese camino y desarrollar este lenguaje, que puede ser increíblemente laborioso y bastante difícil de hacer, o aconsejarías quedarte y trabajar con un lenguaje de programación más convencional?

Joannes Vermorel: Primero, crear tu DSL no es algo que usarás como sustituto de los lenguajes de programación convencionales. Si eres una empresa de software y quieres crear este nuevo lenguaje como una forma de resolver una clase de problemas, como lo hacemos para supply chain, necesitarás un compilador y un entorno de ejecución para ejecutar estos programas escritos en estos lenguajes. Y este compilador estará escrito con un lenguaje de programación regular. Así que no es que, al optar por el camino del DSL, no necesites ingenieros de software; al contrario, necesitarás incluso más ingenieros de software.

Considerando la pregunta para las start-ups, creo que es interesante porque el camino del DSL es tan ambicioso que ha sido significativamente subexplotado. Veo muchas empresas de software y start-ups tratando de abordar los problemas de la manera clásica porque tienen prisa, y terminan con productos algo insatisfactorios. Cuando miro el tipo de productos que están entregando al mercado, digo que es interesante, pero se están encaminando directamente hacia convertirse en una gran pieza de software empresarial, y eso no es exactamente a donde quieres llegar.

Un ejemplo sería lo que yo llamo “sistemas de gestión de órdenes multicanal”. Hay una ola de productos de software que siguieron ese camino, y los más grandes ahora están empezando a parecerse bastante a ERPs por sí mismos, con literalmente cientos de pantallas, miles de opciones, y se requieren meses para configurarlos adecuadamente. En realidad, no terminan siendo algo tan superior a los ERPs que fueron el punto de partida para diferenciarse, con productos que eran más ágiles, más rápidos de implementar, etc. Diez años después, terminas con algo que es increíblemente similar a un ERP, y tal vez ese sea típicamente el tipo de problema en el que usar un DSL habría marcado la diferencia.

Kieran Chandler: Estamos discutiendo las diferencias entre usar un lenguaje específico de dominio (DSL) y un lenguaje de programación convencional para el desarrollo de software. Con un DSL, podrías enfrentar años de dolores de cabeza, pero eventualmente terminas con una solución poderosa y ajustada. Por otro lado, usar un lenguaje de programación convencional podría llevar a un crecimiento más rápido, pero podría resultar en un sistema inmanejable.

Joannes Vermorel: Es interesante notar que uno de los primeros DSLs exitosos fue SQL, el lenguaje de consultas para bases de datos. Hoy en día, cada proveedor de bases de datos está esencialmente vendiendo un DSL, ya que la única forma de interactuar con una base de datos es a través de consultas escritas en un lenguaje específico de dominio. Cuando un DSL se vuelve increíblemente exitoso, la gente olvida que en realidad es un DSL. Por ejemplo, HTML se ha vuelto tan prevalente que la gente ya no lo considera un DSL. Creo que hay mucho potencial para los DSLs en diversas industrias, como la optimización de supply chain con Lokad.

Kieran Chandler: Aparte de la industria de supply chain, ¿qué otras industrias crees que podrían beneficiarse del uso de un DSL?

Joannes Vermorel: El marketing es una industria que viene a la mente. Veo muchas empresas luchando con soluciones de software complejas que no son lo suficientemente potentes. Terminan haciendo mucho trabajo con Excel, lo cual es difícil de mantener y llevar a producción. Los recursos humanos son otra área donde los DSLs podrían ser beneficiosos. La gestión de recursos humanos a menudo refleja la cultura de una empresa, lo que dificulta tener una solución única para todos. Creo que los DSLs tienen el potencial de tener un impacto significativo en prácticamente todas las industrias, pero la forma en que se implementan puede variar enormemente de un problema a otro.

Kieran Chandler: Vamos a dejarlo así. Gracias por tu tiempo hoy, Joannes.

Joannes Vermorel: De nada.

Kieran Chandler: Eso es todo por hoy. Gracias por sintonizar, y nos vemos de nuevo la próxima vez. Adiós por ahora.