228 – (Domänenspezifische) Programmiersprachen
| Rate/Vote |   (average: 4.26) Loading... |
Gast: Markus Völter Host: Nora Ludewig Shownoter: Kolja Dummann
Nachdem uns viele darum gebeten haben: in dieser Episode spreche ich mit Markus über das, was Markus beruflich macht, nämlich den Bau von meist domänenspezifischen Programmiersprachen (DSLs). Wir beginnen mit einigen Grundlagen zur Programmierung und Programmiersprachen an sich, und erklären dann, warum es Sinn macht, an spezifische Fachgebiete angepasste Programmiersprachen zu entwickeln. Im Hauptteil des Gesprächs geht es darum, was gute DSLs ausmacht, wie man sie entwickelt und welche Werkzeugunterstützung man dafür bekommen kann.
Am Anfang der Episode gibt’s auch einen kleinen Rückblick auf unser Podcastjahr 2016. Schöne Weihnachten und Guten Rutsch euch allen :-)
Vorstellung Markus
00:16:18
Was ist ein Program?
00:20:03Bubblesort | Prozessor | Befehlssatz | Hexadezimalsystem | Compiler | Alan Turing | Halteproblem | C (Programmiersprache) | Bootstrapping | Landau-Symbole / Big 0 Notation | Hashtabelle
Warum gibt es mehr als eine Programmiersprache?
00:47:38BASIC | Pascal | Simulink | Eskimo-Wörter für Schnee | Seiteneffekt | Charles Simonyi | Batchverarbeitung
This website uses cookies to improve your experience. We'll assume you're ok with this.
Diese Webseite verwendet Cookies. Wir gehen davon aus, dass das für Sie/Dich in Ordnung ist.
Sehr schön, endlich wieder mal eine Episode zum Thema Software / Computing / usw. :-)
Frohe Weihnachten und danke für die tollen Podcasts (nicht nur wenn es darin um Software geht)! ;-)
Vielen Dank für den interessanten Einblick! Vielleicht wäre auch eine Folge mit umgekehrter Besetzung spannend?
Wenn die Leute sowohl mehr als auch weniger Details wollen, gebt ihnen doch beides – mit mehr Details aufnehmen, und zusätzlich eine detailreduzierte Version schneiden (lassen?)
Durchaus ne Idee, die wir schon öfters diskutiert hatten … wird vielleicht passieren :-)
Kontext?
“Versicherungsfuzzi” ist keine Beleidigung!
Es ist die mit Abstand wohlwollendste Bezeichnung für einen Buchmacher.
:-)
Schönes Thema und sehr guter Podcast. Ich hätte allerdings den Stil eines geradlinigen Interviews vorgezogen, da ich es als anstrengend empfand immer wieder den Gedankengängen der Interviewenden folgen zu müssen.
Ja, stimmt, wir sind schon etwas hin- und hergesprungen.
Eine sehr schoene Episode mit sehr viel (Hintergrund-)Informationen. Die Unterhaltung ist in der Tat ein wenig hin und hergesprungen – ein etwas deutlicher erkennbarer “roter Faden” waere da sicherlich von Vorteil gewesen. Die recht lange “Einleitung” in Sachen Programmiersprachen als solche (verschiedene Paradigms, etc.) war noch einmal eine gute Auffrischung fuer die anschliessende DSL Diskussion. Wer daruber hinaus mehr wissen moechte kann sich in der Tat durch die existierenden Berge an Literatur arbeiten.
Den Vorschlag in Sachen Rollentausch finde ich sehr gut (dann koennt ich ja ja auch die Zustaendigkeit in Sachen Beitrag schneiden umdrehen).
Nö, das war kein Bubblesort… :-)
Embedded muss ich schon manchmal Assembler programmieren (also IBM 360 auch, aber das war mehr Frotzelei der Lehrer). Stolpert man da heute nicht mehr drüber?
Doch, kommt schon vor. Aber auch in der Embedded-Welt werden Entwicklungskosten, Feature-Reichtum und Wartbar- und Erweiterbarkeit heute höher bewertet als früher, was dann eben ggfs. zu mehr Rechenpower und weniger Ressourcenknappheit führt.
Sehr schöne Folge, die ich mit viel Neugier und Erkenntnisgewinn gehört habe. Danke dafür!
Ein Aspekt, den ich nicht ganz verstanden habe: was genau müssen Versicherungsmathematiker programmieren, wenn neue Versicherungsgesetze in Kraft treten? Aus der Folge habe ich verstanden, dass die Vertragsbedingungen programmiert (?) vorliegen?
Genau. Die Verträge müssen ja ausführbar sein, dass man Dinge durchrechnen kann und für die Kunden interaktive Web Apps bauen kann. Dazu müssen die ganzen Regeln im Vertrag formal beschrieben (d.h., programmiert) werden.
Das finde ich sehr spannend. Vom Recht wird ja häufig behauptet, dass es sich nicht algorithmisieren lasse. Trotzdem wird genau das ja zumindest bei Versicherungsverträgen seit mindestens 40 Jahren gemacht (wenn ich mich richtig an die Zahl im Podcast erinnere). Gibt es zu dieser Praxis irgendwo eine ausführliche Beschreibung?
Wenn Du mir ne Email schreibst kann ich Dir ein paar Dinge schicken.
Super, danke! E-Mail ist eben raus an feedback@omegataupodcast.net.
Um das obige zu präzisieren: Das war nicht nur kein Bubble Sort, das war eine etwas ineffiziente (in der Zahl der Vertauschungen) Implementierung von einem Selection Sort. Trotzdem O(x^2) ;-). Beim Bubble Sort vergleicht und vertauscht man nur benachbarte Elemente.
Excel ist einer der Gründe, warum ich wieder an der Hochschule bin (nach der letzten Beförderung in der Privatwirtschaft erwartete man, dass ich damit lügen lerne). Aber auch wenn bei Excel der erste Eindruck datenorientiert ist, so kann man die Logik auch erst mal ganz ohne Daten (oder nur mit Testdaten) programmieren – und das passiert auch. Solche Teile werden dann mit VBA oder anderen Krücken be- und entfüllt, und laufen tatsächlich zum Teil (oft undokumentiert) auf Servern, wo sie wichtige Geschäftsabläufe abbilden. Ich habe mal jemanden getroffen, der als Excel-Sanierer arbeitete – seine Firma war darauf spezialisiert, solche Dinger zu finden, den Algorithmus zu reverse-zu-engineeren, und dann das Tabellenblatt durch was robusteres (meist in Java) zu ersetzen.
Man kann mit Excel – wie mit jeder Sprache – auch gute Software bauen. Die Frage ist, wie leicht einem die Sprache das macht, und wie gut es skaliert wenn das Problem komplexer wird. Excel ist in dieser beiden Hinsichten nicht besonders toll. Ich denke, da sind wir uns einig.
Ein Tabellenblatt besteht für mich entweder überwiegend aus Daten – dann brauche ich den Kalkulationsteil nicht. Oder es enthält erhebliche Mengen von Formeln und Querbezügen – dann habe ich ein sehr sehr unübersichtliches und schwer zu debuggendes Spaghetti-Programm, bei dem ich immer nur ganz kleine Teile auf einmal sehen kann.
Ich bin alter Unixer – ich mag Text. Wenn es was zu rechnen gibt, dann schreibe ich mir ein kleines AWK- oder (wenn es etwas komplexer wird) Python-Programm zur Datenanalyse.
Hat lange gedauert, bis ich dazu gekommen bin, diese “Weihnachtsepisode” zu hören. Trotz langjähriger IT/Programmier-Erfahrung habe ich vieles mal aus einem anderen Blickwinkel präsentiert bekommen. War sehr informativ und unterhaltsam. Markus kam manchmal etwas oberlehrerhaft rüber, aber da Nora ihm das nicht übelgenommen hat, tue ich das auch nicht.
Es ist immer schön zu hören, wenn Nora lacht; in den “normalen” Episoden ist sie leider immer so ernst…