00:00:08 Domänenspezifische Sprachen (DSLs) und ihre Vielfalt.
00:01:36 Beispiele für DSLs: AMPL für mathematische Programmierung und HTML für Webseiten.
00:03:00 Die Vorteile des Einsatzes von DSLs gegenüber allgemeinen Programmiersprachen für bestimmte Aufgaben.
00:05:22 Lokads Einsatz einer DSL für die supply chain Optimierung in unterschiedlichen Situationen.
00:07:23 Die Vorteile des Einsatzes einer DSL für eine schnellere und zuverlässigere Konfiguration.
00:09:35 Einschränkungen einer DSL und deren Nutzen in der supply chain Optimierung.
00:12:55 Sicherheitsimplikationen beim Einsatz einer DSL im Vergleich zu allgemeinen Programmiersprachen.
00:13:01 Der zeitaufwändige Prozess der Entwicklung einer DSL.
00:14:49 Ratschläge für Startups, die die Entwicklung einer eigenen DSL in Betracht ziehen.
00:16:01 Die Unterausnutzung von DSLs und traditionellen Lösungen, die zu unbefriedigenden Produkten führen.
00:17:26 Das Dilemma der Verwendung von DSLs im Vergleich zu etablierten Programmiersprachen und deren Ergebnissen.
00:18:32 SQL und HTML als erfolgreiche Beispiele für domänenspezifische Sprachen.
00:19:46 Das Potenzial von DSLs in verschiedenen Industriezweigen und ihre transformativen Kräfte.
00:21:19 Fazit und mögliche zukünftige Entwicklungen im Einsatz von DSLs.
Zusammenfassung
In diesem Interview bespricht Kieran Chandler domänenspezifische Sprachen (DSLs) mit Joannes Vermorel, dem Gründer des Unternehmens supply chain optimization Lokad. DSLs sind Programmiersprachen, die für spezifische Aufgaben entwickelt wurden, im Gegensatz zu universellen Sprachen wie Java oder Python. Vermorel erklärt, dass DSLs in Branchen wie der Automobilindustrie eingesetzt werden, wo sie eine fehlerfreie Funktion für kritische Komponenten wie Antiblockiersysteme gewährleisten. Er spricht auch über Lokads Entwicklung einer eigenen DSL, Envision, um die supply chain Optimierung zu rationalisieren. Vermorel hebt die Vorteile von DSLs hervor, wie effiziente Berechnungen und Anpassung an spezifische Domänen, und räumt gleichzeitig die Herausforderungen und den zeitaufwändigen Entwicklungsprozess ein.
Ausführliche Zusammenfassung
In diesem Interview bespricht Kieran Chandler, der Moderator, domänenspezifische Sprachen (DSLs) mit Joannes Vermorel, dem Gründer von Lokad, einem Softwareunternehmen, das sich auf supply chain Optimierung spezialisiert hat.
DSLs sind eine spezielle Klasse von Programmiersprachen, die entwickelt wurden, um sehr spezifische Arten von Problemen zu lösen, im Gegensatz zu allgemeinen Programmiersprachen wie Java oder Python, die darauf ausgelegt sind, ein breiteres Spektrum von Aufgaben zu bewältigen. Allgemeine Programmiersprachen bieten eine bequeme, produktive und effiziente Methode, alles zu tun, was mit Computern möglich ist, während DSLs sich auf die Lösung spezifischer Probleme konzentrieren. Einige der ersten domänenspezifischen Sprachen, wie AMPL, wurden für mathematische Programmierung und andere sehr spezifische Aufgaben entwickelt.
DSLs werden in realen Anwendungen eingesetzt, um kritische Komponenten in verschiedenen Industriezweigen zu implementieren. Zum Beispiel könnte im Automobilsektor eine DSL verwendet werden, um die Software zu entwickeln, die das Antiblockiersystem (ABS) eines Autos steuert. Das Ziel ist es, ein nahezu fehlerfreies System zu schaffen, da ein Ausfall dieser Komponente zu einem Verlust der Bremsfähigkeit führen könnte. Im Gegensatz dazu bieten herkömmliche Programmiersprachen möglicherweise nicht dasselbe Maß an Sicherheit in der fehlerfreien Ausführung.
Ein weiteres Beispiel für eine DSL ist HTML, das für die Erstellung von Webseiten konzipiert ist. HTML ist zugänglicher und einfacher als allgemeine Programmiersprachen und daher für technisch weniger versierte Nutzer oder sogar für Grundschüler geeignet. Diese Einfachheit geht jedoch mit Einschränkungen einher, da HTML in seinen Fähigkeiten begrenzt ist und den Nutzern lediglich die Steuerung des Layouts einer Webseite ermöglicht, anstatt komplexere Aufgaben wie die Steuerung von Robotern oder die Entwicklung von künstlicher Intelligenz zu realisieren.
Auf die Frage, warum DSLs anstelle von ausdrucksstärkeren, herkömmlichen Programmiersprachen verwendet werden, erklärt Vermorel, dass die Nutzung einer allgemeinen Programmiersprache für Aufgaben, die besser für eine DSL geeignet sind, den Prozess unnötig verkomplizieren würde. Zum Beispiel würde die Verwendung einer allgemeinen Programmiersprache für das Webseitendesign bedeuten, jeden einzelnen Pixel auf dem Bildschirm zu steuern, anstatt einfache Elemente der Markup-Sprache zu verwenden, wie das Festlegen von Titel, Schriftgröße oder Textausrichtung, wie es bei HTML der Fall ist.
Vermorel erklärt, dass supply chain Probleme vielfältig sind, da kein Unternehmen dem anderen exakt gleicht. Unternehmen verfügen über unterschiedliche IT-Landschaften, applikative Landschaften und verschiedene Kombinationen von ERPs, WMSs und anderen Systemen. Diese Vielfalt schafft Herausforderungen für Softwarelösungen, die versuchen, die supply chain Optimierung mit einem One-Size-Fits-All-Ansatz anzugehen. Traditionelle Frameworks, die auf Konfiguration basieren, erfordern oft umfangreiche Anpassungen und Konfigurationen für jeden Kunden, was zeitaufwändig und kostspielig ist.
Im Bewusstsein, dass jede Kundensituation unterschiedliche Software erfordert, suchte Lokad nach einem effizienteren und zuverlässigeren Prozess. Sie beschlossen, ihre eigene DSL, Envision, zu entwickeln, um den Konfigurationsprozess zu vereinfachen und schneller sowie produktiver zu gestalten. Vermorel stellt den Einsatz von Envision den herkömmlichen Programmiersprachen wie C#, F# und TypeScript gegenüber. Obwohl diese generischen Programmiersprachen bereits umfangreich genutzt werden, erwies sich die Bearbeitung von Kundenanfragen mit ihnen als träge und kostspielig. Envision wurde so konzipiert, dass es agiler ist und besser zu den einzigartigen Anforderungen der supply chain Optimierung passt.
Vermorel hebt hervor, dass ein Grund, warum viele supply chain software Lösungen aufgebläht werden, darin liegt, dass sie versuchen, jede erdenkliche Funktion und jeden Anwendungsfall zu berücksichtigen. Lokad wählte einen anderen Ansatz, indem sie eine eng fokussierte Kern-DSL entwickelten, wobei das Softwareprodukt selbst Envision und dessen Fähigkeiten darstellt. Dies ermöglicht es ihnen, für jeden Kunden individuelle Implementierungen mit Envision zu erstellen, während der Compiler und die Umgebung für Envision in C#, F# und TypeScript umgesetzt sind.
Vermorel erklärt, dass der Einsatz einer DSL Einschränkungen mit sich bringen kann, was in bestimmten Situationen jedoch von Vorteil sein kann. Zum Beispiel kann es bei der Optimierung einer großen supply chain mit einem umfangreichen Datensatz schwierig sein, sicherzustellen, dass Berechnungen innerhalb eines bestimmten Zeitrahmens abgeschlossen werden, wenn generische Programmiersprachen verwendet werden. Eine DSL mit passenden Einschränkungen kann garantieren, dass die Berechnungen rechtzeitig abgeschlossen werden, und somit Störungen in der supply chain vermeiden.
Die Entwicklung einer DSL kann jedoch ein zeitaufwändiger Prozess sein. Vermorel berichtet, dass es sein Unternehmen fast ein Jahrzehnt gekostet hat, ihre eigene DSL zu entwickeln. Diese lange Entwicklungszeit kann im Widerspruch zur schnelllebigen Natur von Startups stehen. Die zentrale Herausforderung bei der Entwicklung einer DSL besteht darin, die zugrunde liegenden Probleme neu zu überdenken und die logischen Primitive zu definieren, die zur Lösung benötigt werden. Dies beinhaltet die Gestaltung der Syntax und Operatoren der Programmiersprache, sodass sie mit dem zu lösenden Problem im Einklang stehen.
Trotz der Herausforderungen ist Vermorel der Ansicht, dass der Weg der DSLs bisher unterausgeschöpft wurde und für Startups von Vorteil sein könnte. Die Entwicklung einer DSL ersetzt nicht die Notwendigkeit von Softwareingenieuren oder allgemeinen Programmiersprachen; im Gegenteil, es könnte sogar mehr Softwareingenieure erfordern. Durch die Fokussierung auf einen spezifischen Problembereich kann eine DSL jedoch Vorteile in Bezug auf Effizienz, Sicherheit und Optimierung bieten.
Vermorel beginnt damit, die Einschränkungen traditioneller Unternehmenssoftware zu erörtern, die oft aufgebläht und schwer zu handhaben ist. Anschließend führt er das Konzept der DSLs als potenzielle Lösung für dieses Problem ein. DSLs sind Programmiersprachen, die auf bestimmte Domänen oder Industriezweige zugeschnitten sind und spezialisierte Fähigkeiten sowie Optimierungen bieten.
Vermorel weist darauf hin, dass viele der heutigen Softwareprodukte unbefriedigend sind und dazu neigen, wie große Unternehmenssoftware zu werden, was nicht das ideale Ergebnis ist. Er nennt das Beispiel von Multi-Channel Order Management Systemen (MOMS), die sich zu ERP-Systemen mit Hunderten von Bildschirmen und Tausenden von Optionen entwickelt haben. Das ursprüngliche Ziel, sich von ERPs abzuheben, ist verloren gegangen, und das resultierende Produkt ist kaum besser als das ursprüngliche ERP.
Er argumentiert, dass der Einsatz von DSLs im Fall von MOMS zu einem schlankeren und leistungsstärkeren Produkt hätte führen können. Die Einführung einer DSL bringt jedoch eigene Herausforderungen mit sich, wie jahrelange Kopfschmerzen und Einschränkungen. Andererseits könnte die Verwendung einer allgemeineren Programmiersprache ein schnelleres Wachstum ermöglichen, aber zu einem unüberschaubaren Produkt führen.
Ein erfolgreiches Beispiel für eine DSL ist SQL (Structured Query Language), eine Programmiersprache, die zur Verwaltung relationaler Datenbanken verwendet wird. Vermorel merkt an, dass, wenn eine DSL sehr erfolgreich wird, die Menschen oft vergessen, dass es sich überhaupt um eine DSL handelt. Er ist überzeugt, dass DSLs in verschiedenen Industriezweigen, einschließlich der supply chain Optimierung bei Lokad, erhebliches Potenzial haben.
Chandler fragt nach anderen Branchen, in denen DSLs von Nutzen sein könnten. Vermorel schlägt Marketing als eine Möglichkeit vor, wo Unternehmen oft mit komplexen Softwarelösungen zu kämpfen haben, die nicht leistungsfähig genug sind, um ihren Bedürfnissen gerecht zu werden. Personalwesen ist ein weiterer Bereich, in dem DSLs eine maßgeschneiderte Lösung bieten könnten, da es die einzigartige Kultur jedes Unternehmens widerspiegelt, was es schwer macht, Ansätze von der Stange effektiv umzusetzen.
Vollständiges Transkript
Kieran Chandler: Heute wollen wir ein wenig mehr darüber erfahren, wie sie entwickelt werden und auch verstehen, warum sie im Vergleich zu einigen der gängigeren Programmiersprachen vorteilhaft sein können. Joannes, vielleicht könntest du damit beginnen, uns ein wenig mehr darüber zu erzählen, was DSLs eigentlich sind und wie sie funktionieren.
Joannes Vermorel: DSLs sind eine spezielle Klasse von Programmiersprachen, die, im Gegensatz zu allgemeinen Programmiersprachen wie Java, Python und C++, nicht darauf ausgelegt sind, eine Lösung für alles zu bieten, was man an einem Computer programmieren kann. Allgemeine Programmiersprachen sollen dir den bequemsten, produktivsten und effizientesten Weg bieten, alles zu tun, was mit Computern möglich ist – oder mit vielen Computern, wenn du möchtest. Domänenspezifische Programmiersprachen hingegen sind etwas ganz anderes. Es handelt sich um Programmierung, weshalb sie mit Code versehen sind, formal und abstrakt sind, aber dafür entwickelt wurden, sehr spezifische Arten von Problemen zu lösen. Zum Beispiel waren historisch gesehen die ersten domänenspezifischen Programmiersprachen meist für Dinge wie AMPL gedacht, eine mathematische Programmiersprache, die für sehr spezifische Aufgaben konzipiert wurde.
Kieran Chandler: Für welche Art von Problemen würdest du eine domänenspezifische Sprache einsetzen, und wofür wird sie in der realen Welt verwendet?
Joannes Vermorel: In der realen Welt wäre eine historische Anwendung, kritische Komponenten zu implementieren. Zum Beispiel möchtest du ein Stück Software haben, das dein ABS in deinem Auto steuert, also das Antiblockiersystem, und du möchtest den Nachweis haben, dass diese Software niemals abstürzt, denn wenn das passiert, hat dein Auto plötzlich keine Bremskraft mehr. Das ist eine Situation, in der es wirklich ernst wird, und man würde denken, dass wir versuchen sollten, etwas zu vermeiden, das zu fehleranfällig ist. Das ist im eingebetteten Bereich. Dann gibt es Probleme wie HTML für Webseiten, wo es sich um eine Programmiersprache handelt, du aber möchtest, dass sie zugänglicher ist. Es gibt einen guten Grund, warum man HTML in der Grundschule lernen kann; es ist sehr einfach. Die Grundlagen sind buchstäblich selbst für relativ untechnische Menschen sehr zugänglich. Aber der trade-off besteht darin, dass HTML dir erlaubt, das Layout einer Webseite zu steuern; es erlaubt dir nicht, einen Roboter zu kontrollieren oder künstliche Intelligenz zu entwickeln.
Kieran Chandler: Also, sie sind sehr einfach und stärker eingeschränkt. Ich meine, warum benutzt du nicht allgemeinere Programmiersprachen, die für diese Aufgaben mehr Ausdruckskraft haben, weil sie in der Lage sind, dies zu leisten?
Joannes Vermorel: Wenn du darüber nachdenkst, was es für HTML-Webseiten bedeuten würde, anstatt einfach nur eine Markup-Sprache zu haben, in der du “title”, “big font size” und “body of text”, “I want to have the text justified” und so weiter angeben kannst – einfache Steuerungen –, müsstest du daran denken: “Oh, ich werde jeden einzelnen Pixel auf meinem Bildschirm steuern”, und das ist nicht praktikabel.
Kieran Chandler: …würde das bedeuten, was man mit einem super Low-Level-Ansatz erreichen könnte, und wenn du noch tiefer gehen möchtest, sagst du: Nun, ich werde meine Grafikkarten direkt steuern, um eine super hohe Leistung zu erzielen, und das ist vielleicht das, was du tun würdest, wenn du tatsächlich eine 3D-Engine für Videospiele entwickeln würdest. Aber wenn du nur etwas Einfaches machen willst, wie zum Beispiel eine Webseite, würde das auf diese Weise eine unendliche Zeit in Anspruch nehmen. Bei 3D-Videospielen ist es so viel einfacher und direkter, einfach IDs und dergleichen wie HTML zu verwenden. Okay, und es ist ein Thema, mit dem wir bei Lokad sehr vertraut sind, da wir sozusagen unsere eigene DSL entwickelt haben. Warum war es also etwas, das für uns als supply chain Unternehmen so interessant war?
Joannes Vermorel: Das, was an der supply chain so frustrierend ist, liegt darin, dass die Probleme so vielfältig sind. Es gibt buchstäblich kein Unternehmen, das dem anderen exakt gleicht. Sie besitzen nicht dieselbe anwendungsspezifische Landschaft. Einige Unternehmen haben ein ERP; viele haben aus ungünstigen Gründen zwei ERPs. Sie verfügen über ein WMS; sie haben mehrere WMS. Manche besitzen 10 verschiedene ERPs, weil sie in zehn verschiedenen Ländern mit unterschiedlichen IT-Landschaften operieren. Sie haben die E-Commerce-Plattform, die später hinzukam – eine separate Sache. Sie haben zusätzliche Beschleuniger. Also war das Problem, dass wir eine supply chain Optimierung durchführen wollten, und ich erkannte in den frühen Jahren, dass der klassische Ansatz, ein Framework zu haben, das man konfigurieren konnte, schlichtweg nicht funktionieren würde. Die Situationen waren so vielfältig, dass wir am Ende bei jedem einzelnen Kunden mit einer enormen Menge an Anpassungen und Konfigurationen landeten. Und buchstäblich, wenn man an Software denkt, die komplett einsatzbereit ist, aber sechs Monate benötigt, um irgendwie konfiguriert zu werden – ist das wirklich Konfiguration? Oder ist es nicht buchstäblich, ein neues Softwarestück neu zu erfinden? Die Realität ist: Ja, das tut man. Und so haben wir beschlossen, diesen Ansatz auf den nächsten logischen Schritt zu heben: Wenn jede Situation ein anderes Softwareprodukt erfordert, was wäre dann, wenn es etwas gäbe, das diesen Prozess unterstützt und ihn sehr produktiv, sehr schnell und äußerst zuverlässig macht? Genau an dieser Stelle entstand die Idee, eine DSL, also eine domänenspezifische Sprache, einzusetzen.
Kieran Chandler: Wenn du eine gängigere Programmiersprache benutzt, würde die Konfiguration viel mehr Zeit in Anspruch nehmen, während eine so eingeschränkte Umgebung bedeutet, dass man die Dinge deutlich schneller erledigen kann.
Joannes Vermorel: Das ist interessant. Bei Lokad nutzen wir generische Programmiersprachen. Von Anfang an haben wir C-sharp, C-sharp.NET verwendet – praktisch den Programmierstack von Microsoft – und später kamen F-sharp und TypeScript für verschiedene Aufgaben dazu. Wir verwenden also bereits umfassend generische Programmiersprachen, und ich kenne mich sehr gut damit aus, was man mit ihnen anstellen kann. Doch schon in den ersten Jahren bei Lokad stellten wir fest, dass die Bearbeitung von Kundenanfragen mit diesen Sprachen unglaublich schleppend und kostspielig war. Wir brauchten etwas Besseres, und es lag nicht daran, dass wir diese Sprachen nicht beherrschten. Es war schlichtweg ein Alptraum, sie für jede einzelne Kundensituation durchzuspielen. Übrigens ist das auch ein Grund, warum all diese supply chain Softwarelösungen am Ende zu gigantischen Softwaremonstern werden. Sie versuchen, in ihr Produkt alles hineinzupressen, und am Ende entsteht ein Softwaremonster. Also sagten wir: Was wäre, wenn das Softwareprodukt…
Kieran Chandler: Was wäre, wenn das Softwareprodukt lediglich eine DSL und ihre Fähigkeiten wäre – so etwas wie ein superstraaffer Kern –, und wenn wir zu einem Kunden gehen, erstellen wir eine kundenspezifische Implementierung, allerdings nicht in C-sharp, sondern in Envision, unserer eigenen DSL? Der Compiler und die Umgebung für Envision sind jedoch nicht in Envision implementiert, sondern in C-sharp, F-sharp und TypeScript. Joannes Vermorel: Okay. Kieran Chandler: Du hast erwähnt, dass supply chains offensichtlich unglaublich vielfältig sind und jeder Kunde unglaublich unterschiedlich ist. Führt die Verwendung einer DSL zu Einschränkungen? Hält sie dich davon ab, gewisse Dinge tatsächlich zu implementieren? Joannes Vermorel: Absolut, und genau darum geht es – so überraschend es auch klingen mag. Schau, beispielsweise eines der grundlegendsten Probleme ist: Wenn du eine große supply chain hast, die du optimieren möchtest, landest du mit einem ziemlich umfangreichen Datensatz. Sagen wir, du hast ein Terabyte an Daten. Das ist nicht riesig; du kannst in einen Supermarkt gehen und eine 1-Terabyte-Festplatte für etwa 100 Euro kaufen, was recht billig ist. Es ist also eine große Datenmenge, aber nicht gigantisch. Das Problem ist nun, dass dein Datensatz täglich aktualisiert wird und du etwa einen Durchlauf brauchst, um intelligente supply chain Entscheidungen zu treffen – wie Nachfüll- und Preisentscheidungen. Jetzt stellt sich das Problem: Wenn du eine generische Programmiersprache hast, wie kannst du sicherstellen, dass die Berechnungen in weniger als, sagen wir, 60 Minuten abgeschlossen sind? Es ist sehr schwierig. Sobald du beliebige Schleifen oder Konstrukte einsetzt, wird es quasi unmöglich zu beweisen, dass deine Ausführung in einen bestimmten Zeitrahmen passt – was problematisch werden kann, wenn die Berechnungen für Entscheidungen, wie z. B. Nachfüllentscheidungen, in eine straffe Ausführungssequenz deines ERP-Systems eingebettet werden müssen. Du musst wirklich sicherstellen, dass diese Ausführung in 60 Minuten abgeschlossen wird, sonst störst du deine gesamte supply chain, weil die Berechnung zu lange dauert.
Joannes Vermorel: Absolut, und das ist genau der Punkt, so überraschend es auch sein mag. Schau, eines der grundlegendsten Probleme ist, wenn du eine große supply chain hast, die du optimieren möchtest, und am Ende mit einem ziemlich umfangreichen Datensatz landest. Sagen wir, du hast ein Terabyte an Daten. Das ist nicht riesig; du kannst in einen Supermarkt gehen und eine 1-Terabyte-Festplatte für etwa 100 Euro kaufen, was recht günstig ist. Es ist also zwar eine große Menge an Daten, aber nicht gigantisch. Nun wird dein Datensatz täglich aktualisiert, und du möchtest beispielsweise einen Durchlauf machen, um intelligente supply chain Entscheidungen zu treffen, wie Nachfüll- und Preisentscheidungen.
Nun stellt sich das Problem: Wenn du eine generische Programmiersprache hast, wie kannst du sicherstellen, dass die Berechnung tatsächlich in weniger als, sagen wir, 60 Minuten abgeschlossen wird? Es ist sehr schwer. Sobald du beliebige Schleifen oder Konstrukte einsetzt, wird es äußerst schwierig zu beweisen, dass deine Ausführung in einen bestimmten Zeitrahmen passt – was problematisch sein kann, wenn die Berechnungen für bestimmte Entscheidungen, wie Nachfüllentscheidungen, in eine enge Ausführungssequenz deines ERP-Systems passen müssen. Du musst wirklich gewährleisten, dass diese Ausführung in 60 Minuten abgeschlossen wird, sonst störst du deine gesamte supply chain, weil die Berechnung zu lange dauert.
Das ist typisch für Probleme, bei denen generische Programmiersprachen keine Garantien liefern können, weil man mit ihnen prinzipiell alles machen kann – es ist also extrem schwer, aus diesen Sprachen irgendwelche Garantien abzuleiten. Mit einer DSL, die über gezielte Einschränkungen verfügt, gibt es allerdings einen weiteren Aspekt: das Design. Es ist tatsächlich sehr schwer, mit einer generischen Programmiersprache eine Programmierumgebung zu bieten, die vollkommen sicher ist. Mit generischen Sprachen wie Java, Python oder C-sharp setzt du dich ganzen Klassen von Sicherheitslücken aus. Wenn du mit einem Computer prinzipiell alles machen kannst, kannst du Dinge tun, die aus einer IT-Sicherheit Perspektive relativ gefährlich sind.
Erneut bedeutet der Einsatz einer DSL, dass es ganze Klassen von Dingen gibt, auf die du schlichtweg keinen Zugriff hast – etwa das Herumspielen mit dem Betriebssystem – und somit werden Problemklassen ausgeschlossen, die dich gar nicht betreffen. Alles, was zählt, ist die supply chain Optimierung.
Kieran Chandler: Ja, und genau darüber haben wir in unserer Sicherheitsepisode gesprochen. Schauen wir uns mal die Entwicklung einer DSL an. Wie lange dauert es denn in deiner Position, so eine Sprache zu entwickeln – wie lange hat es gedauert, Envision zu entwickeln?
Joannes Vermorel: Das ist eine gute Frage. Es dauert buchstäblich ein Jahrzehnt, was irgendwie verrückt ist. Wenn du ein Start-up bist, sagst du: “Bewege dich schnell und zerstöre Dinge”, entwickle ein Minimum Viable Product, das du innerhalb von sechs Monaten verkaufen kannst, und beginnst dann damit, deine eigene DSL zu erschaffen – und das ist buchstäblich ein Prozess.
Kieran Chandler: Sicherlich ein mehrjähriger Aufwand, und die zentrale Herausforderung besteht darin, dass man die zugrundeliegenden Probleme von Grund auf neu denken muss. Was sind die fundamentalen Aspekte dieser Probleme, und welche logischen Primitive müssen dir zugänglich sein, um sie mit Computern zu lösen? Es ist sogar schlimmer, als nur neue Wörter zu erfinden – man erfindet logische Primitive, die Konzepte verbinden, sodass du letztlich ganze Lösungsklassen in diese Sprache einbetten kannst, um Lösungen auf eine vollständig automatisierte Weise zu generieren. Dabei denkst du buchstäblich über die Programmiersprache selbst nach – ihre Syntax, die Art der Operatoren – und du möchtest, dass all das vollkommen auf das Problem, das du lösen willst, abgestimmt ist. Würdest du also einem Start-up, das jetzt anfängt, raten, diesen Weg einzuschlagen und diese Sprache zu entwickeln, was unglaublich zeitaufwendig und schwer umsetzbar ist, oder würdest du eher empfehlen, bei gängigen Programmiersprachen zu bleiben?
Joannes Vermorel: Zunächst einmal ist die Entwicklung deiner DSL nichts, womit du gängige Programmiersprachen ersetzen würdest. Wenn du ein Softwareunternehmen bist und diese neue Sprache erschaffen möchtest, um eine bestimmte Problemklasse zu lösen – so wie wir es bei supply chain tun – benötigst du einen Compiler und eine Laufzeitumgebung, um die in dieser Sprache geschriebenen Programme auszuführen. Und dieser Compiler wird in einer herkömmlichen Programmiersprache geschrieben. Es ist also nicht so, dass du, nur weil du den DSL-Weg einschlägst, keine Softwareingenieure mehr brauchst; ganz im Gegenteil – du wirst noch mehr Softwareingenieure benötigen. Betrachtet man die Lage für Start-ups, ist es interessant, weil der DSL-Weg so ambitioniert ist, dass er erheblich unterausgenutzt bleibt. Ich sehe viele Softwareunternehmen und Start-ups, die Probleme klassisch angehen, weil sie in Eile sind, und am Ende mit etwas unbefriedigenden Produkten herauskommen. Wenn ich die Art der Produkte betrachte, die sie auf den Markt bringen, denke ich, dass es zwar interessant ist, aber sie steuern direkt darauf zu, zu einem riesigen Teil der Unternehmenssoftware zu werden – und genau das ist nicht der Weg, den man einschlagen möchte. Ein Beispiel dafür wären, was ich “multi-channel order management systems” nenne. Es gibt eine Welle von Softwareprodukten, die diesen Weg gegangen sind, und die größeren davon beginnen mittlerweile, fast schon wie eigenständige ERPs auszusehen – mit buchstäblich hunderten von Bildschirmen, tausenden von Optionen und monatelanger Einrichtung. Sie landen nicht in einer Situation, in der sie wesentlich besser sind als die ursprünglichen ERPs, die zur Differenzierung dienten – also Produkte, die schlanker, schneller einsetzbar und so weiter sind. Zehn Jahre später endet man mit etwas, das einem ERP unglaublich ähnlich ist – und vielleicht ist das genau das Problem, bei dem der Einsatz einer DSL den Unterschied gemacht hätte.
Kieran Chandler: Wir diskutieren die Unterschiede zwischen der Verwendung einer domänenspezifischen Sprache (DSL) und einer gängigen Programmiersprache in der Softwareentwicklung. Mit einer DSL könntest du jahrelang Kopfzerbrechen haben, landest aber letztendlich mit einer leistungsstarken und schlanken Lösung. Andererseits könnte die Verwendung einer gängigen Programmiersprache zu schnellerem Wachstum führen, jedoch in einem unüberschaubaren System münden.
Joannes Vermorel: Es ist interessant festzustellen, dass eine der ersten erfolgreichen DSLs SQL war, die Abfragesprache für Datenbanken. Heutzutage verkauft im Grunde jeder Datenbankanbieter eine DSL, denn der einzige Weg, mit einer Datenbank zu interagieren, führt über in einer domänenspezifischen Sprache geschriebene Abfragen. Wenn eine DSL unglaublich erfolgreich wird, vergessen die Leute, dass es sich überhaupt um eine DSL handelt. Zum Beispiel ist HTML derart verbreitet, dass man nicht mehr daran denkt, dass es eine DSL ist. Ich glaube, dass DSLs in verschiedenen Branchen ein enormes Potenzial haben – etwa bei der supply chain Optimierung mit Lokad.
Kieran Chandler: Abgesehen von der supply chain Branche, welche anderen Branchen könnten deiner Meinung nach von der Verwendung einer DSL profitieren?
Joannes Vermorel: Marketing ist eine Branche, die mir sofort einfällt. Ich sehe viele Unternehmen, die mit komplexen Softwarelösungen kämpfen, die nicht leistungsfähig genug sind. Am Ende arbeiten sie viel mit Excel, was schwer zu warten und in die Produktion zu überführen ist. Auch im Bereich Human Resources könnten DSLs von Vorteil sein. Das Personalmanagement spiegelt oft die Unternehmenskultur wider, weshalb es schwerfällt, eine Einheitslösung zu finden. Ich bin überzeugt, dass DSLs das Potenzial haben, nahezu jede Branche nachhaltig zu beeinflussen – wenngleich die Art der Implementierung von Problem zu Problem stark variieren kann.
Kieran Chandler: Damit belassen wir es. Danke für deine Zeit heute, Joannes.
Joannes Vermorel: Gern geschehen.
Kieran Chandler: Das war alles für heute. Danke fürs Einschalten, und bis zum nächsten Mal. Tschüss!
Kieran Chandler: Das war alles für heute. Danke fürs Einschalten, und bis zum nächsten Mal. Tschüss!
