Sprache entwickeln

[Gast]

Hallo,

ich will mir eine eigene Programmiersprache entwickeln. Dragon Book habe ich. Aber wie setze ich am besten am Design an? Muss man da so genial sein wie Börni Stroustrup?

[tokugawa]

Am besten liest du dich erst mal in Theoretischer Informatik (speziell Formale Sprachen) ein, dann in Compilerbau, und danach kannst du mal anfangen eine einfache Sprache in EBNF zu formulieren.

[Trap]

Das was in theoretischer Informatik drankommt ist langweiliges Handwerkszeug. Wichtig ist es schon, man muss wissen wie man es richtig anwendet, aber das kann man bei allen modernen Sprachen als gegeben voraussetzen.

"structure and interpretation of computer programs" oder "growing a language" sprechen Sachen an bei denen man sich als Sprachentwickler einbringen muss und bei denen nicht bekannt ist wie man es richtig löst, oft gibt es nichtmal eine informelle Übereinkunft was sinnvoll wäre.

[tokugawa]

Das was in theoretischer Informatik drankommt ist langweiliges Handwerkszeug. Wichtig ist es schon, man muss wissen wie man es richtig anwendet, aber das kann man bei allen modernen Sprachen als gegeben voraussetzen.


Wenn man selbst eine Sprache entwickeln kann (dazu gehört auch das Spezifizieren der Sprache), sollte man schon wissen,
a) dass Programmiersprachen formale Sprachen sind
b) wie man formale Sprachen eindeutig und konfliktfrei spezifizieren kann
c) in welcher Stufe der Komplexität diese Sprache dann ist (in der Chomsky-Hierarchie)

Wenn eine dieser Kriterien nicht zutrifft, ist die Sprache nicht brauchbar (was umgekehrt nicht heißt dass die Sprache brauchbar ist, selbst wenn diese Kriterien zutreffen).

Also würde ich an deiner Stelle diese Theorie nicht herunterspielen. Klar, theoretische Informatik hab ich auch fad gefunden, aber wie so oft wurden bestimmte Aspekte davon dann interessant, wenn man sich mit der praktischen Anwendung befaßt - nämlich mit dem Compilerbau/Übersetzerbau.

[Trap]

Das betrifft alles nur die Syntaxebene und die ist langweilig wie sonst was. Nicht umsonst gibt es dafür automatische Generatoren dutzendweise.

Ein Compiler ist heute üblicherweise 3-schrittig Text->AST->AST->Ausgabe, der Text->AST Schritt ist in jeder Hinsicht unwichtig, man kann ihn sogar weglassen und direkt den AST in den Compiler füttern (siehe Lisp). Die beiden Schritte AST->AST->Ausgabe sind das, was Semantik und Performance des Ergebnis ausmacht und damit im Endeffekt den Wert der Programmiersprache.

Wenn man Holzhausbau so lehren würde wie Compilerbau würde man extrem ausführlich über Hämmer und Sägen reden, aber über nichts anderes ;)

[tokugawa]

Das betrifft alles nur die Syntaxebene und die ist langweilig wie sonst was. Nicht umsonst gibt es dafür automatische Generatoren dutzendweise.


Für die man geeignetes Wissen mitbringen muß, sonst füttert man denen Blödsinn.

Das betrifft eben nicht nur die Syntaxebene, sondern die lexikalische, die semantische, sowie die Optimierungs-/Performanceebene.


Ein Compiler ist heute üblicherweise 3-schrittig Text->AST->AST->Ausgabe, der Text->AST Schritt ist in jeder Hinsicht unwichtig, man kann ihn sogar weglassen und direkt den AST in den Compiler füttern (siehe Lisp). Die beiden Schritte AST->AST->Ausgabe sind das, was Semantik und Performance des Ergebnis ausmacht und damit im Endeffekt den Wert der Programmiersprache.

Wenn man Holzhausbau so lehren würde wie Compilerbau würde man extrem ausführlich über Hämmer und Sägen reden, aber über nichts anderes ;)

Die Metapher stimmt nur begrenzt - im Compilerbau geht es auch um Sprachendesign, natürlich auf einer gewissen niedrigen Ebene (widerspruchsfreie, konfliktfreie Sprachen; gute, menschenlesbare Sprachenspezifikationen in EBNF). Das ist schon wichtig. Auch die semantische Analyse gehört natürlich dazu. Performance und Optimierung sowieso.


Um eine ähnliche Metapher wie du zu beanspruchen: bevor man das Fundament eines Hauses nicht fertig gebaut hat, sollte man noch nicht am Dach basteln. Die Theorie und Praxis hinter Übersetzerbau ist genau dieses Fundament.

[Monger]

Trap hat schon recht. Das Problem an einer Sprache ist nicht die Grammatik (wenn man nicht gerade etwas extrem exotisches machen will, hat man da ausreichend Vorlagen), sondern was man mit dieser Sprache anfangen will. Und über die Probleme stößt man meistens erst, wenn man die Sprache mal anfängt zu sprechen...

[del_4901]

Um einen Compiler zu schreiben braucht man kein TI, das hab ich selbst schon hinter mir. Aber ein bischen Verständniss dafür, hätte mir etwas an Zeit erspaart.

Un das ist eine Korifee im Compilerbau.

[tokugawa]

Trap hat schon recht. Das Problem an einer Sprache ist nicht die Grammatik (wenn man nicht gerade etwas extrem exotisches machen will, hat man da ausreichend Vorlagen), sondern was man mit dieser Sprache anfangen will. Und über die Probleme stößt man meistens erst, wenn man die Sprache mal anfängt zu sprechen...

Wie gesagt - das stimmt ja alles schon, dass Sprachendesign auf semantischer Ebene wichtig ist.

Aber trotzdem wirst du sehr dankbar sein wenn du das Handwerk darunter (das Fundament) auch beherrscht.

Probleme an einer Sprache kannst du auf jeder Ebene haben. Auf der Semantik-Ebene, oder eben auf der Syntax-Ebene (fehlerhaft definierte Grammatik). Klarerweise sind jene Probleme auf den niedrigen Ebenen "einfacher" in gewisser Weise, weil sie einfach nur eben das Handwerkswissen um TI und Compilerbau erfordern. Aber das macht es nicht unwichtig.


Das erinnert mich irgendwie an Allüren-besetzte Layouter/Grafikdesigner, die großartige Textlayout-Designs entwerfen wollen ohne vorher das Handwerk "Textsatz" zu beherrschen... Klar ist das artistische Design selbst das aufregende, spannende, gar glorreiche (wie das Design der Semantik einer Sprache), aber man sollte trotzdem das Handwerk darunter (wie die Theorie über Compilerbau und Formale Sprachen) beherrschen. Erst mit beiden zusammen klappt es nahtlos.


Sh. was AlphaTier gepostet hat.

[Trap]

Man kann sich um den TI-teil rumdrücken, indem man den AST direkt eingeben lässt, z.B. als supereinfach parsebaren Text wie in Lisp.

Man kann auch die Textdarstellung ganz weg lassen und liefert einen Editor mit, mit dem man direkt den AST manipulieren kann. Den AST speichert man per Serialisierung.

[tokugawa]

Man kann sich um den TI-teil rumdrücken, indem man den AST direkt eingeben lässt, z.B. als supereinfach parsebaren Text wie in Lisp.

Man kann auch die Textdarstellung ganz weg lassen und liefert einen Editor mit, mit dem man direkt den AST manipulieren kann. Den AST speichert man per Serialisierung.

Klar geht das.

Aber damit killt man den Zweck einer "schönen Sprache" mit "schöner Semantik", die eben oft nicht direkt oder einfach (zumindest bei sehr hochleveligen Sprachen) einem AST entsprechen.


Und selbst dann gibt es noch immer die Compilerbau-Algorithmen der Codeerzeugung und Optimierung, die auch Teil der Theorie sind :)

Und gerade die Optimierung selbst arbeitet dann wieder mit Regel-Grammatiken.

Ich bin wahrlich kein Fan der TI, aber selbst ich hab eingesehen dass die Grundlagen halt auch in der Praxis brauchbar und nötig sind.

[Xmas]

Ti und Compilerbau != Parserentwicklung.

Allerdings würde ich beim Entwurf einer Sprache auch nicht mit der Grammatik anfangen.

[tokugawa]

Ti und Compilerbau != Parserentwicklung.


Hm? Nähere Erklärung bitte. Compilerbau umfasst (nicht nur, aber auch) schon die Parserentwicklung auch. Oder meintest du eh genau das, dass TI/Compilerbau sich nicht auf die Parserentwicklung beschränkt?


Allerdings würde ich beim Entwurf einer Sprache auch nicht mit der Grammatik anfangen.

Ja, ich auch nicht. Ich würd erst eher "natürlich" auf Menschenebene anfangen, was ich überhaupt machen will, und wie das aussehen soll (also quasi fast künstlerisch herantasten).

Aber irgendwann tät ich die Sprache auch - auch deswegen damit die Grammatik der Sprache danach wirklich eindeutig ist und es keine unschönen Nebeneffekte gibt - die Sprache dann versuchen in einer formalen Grammatik zu formulieren.

Selbst wenn man wie Trap vorschlägt, Compilergeneratoren verwendet, muß man ja trotzdem sich mit Grammatiken auskennenm, weil dies ja die Eingabe von Compilergeneratoren ist. Und wenn man weiß was die Compilergeneratoren machen (Recursive Descent, LLR-Parsing, usw.) dann kann man schon beim Transfer von "natürlicher Sprachdefinition" in "formale Sprachdefinition" (= Grammatik) darauf achten, dass man einen robusten Compiler kriegt.

[Xmas]

Hm? Nähere Erklärung bitte. Compilerbau umfasst (nicht nur, aber auch) schon die Parserentwicklung auch. Oder meintest du eh genau das, dass TI/Compilerbau sich nicht auf die Parserentwicklung beschränkt?
Letzteres, das war als Antwort auf Traps Beitrag gedacht.

Ja, ich auch nicht. Ich würd erst eher "natürlich" auf Menschenebene anfangen, was ich überhaupt machen will, und wie das aussehen soll (also quasi fast künstlerisch herantasten).

Aber irgendwann tät ich die Sprache auch - auch deswegen damit die Grammatik der Sprache danach wirklich eindeutig ist und es keine unschönen Nebeneffekte gibt - die Sprache dann versuchen in einer formalen Grammatik zu formulieren.
Klar, wenn du eine String-Eingabe willst wirst du irgendwann auch eine formale Grammatik benötigen, das wäre für mich aber der letzte Schritt (vor dem Verbessern durch Anwendung). Ich konnte mich lediglich nicht mit dem "anfangen eine einfache Sprache in EBNF zu formulieren" in deinem ersten Beitrag anfreunden.

[tokugawa]

Klar, wenn du eine String-Eingabe willst wirst du irgendwann auch eine formale Grammatik benötigen, das wäre für mich aber der letzte Schritt (vor dem Verbessern durch Anwendung). Ich konnte mich lediglich nicht mit dem "anfangen eine einfache Sprache in EBNF zu formulieren" in deinem ersten Beitrag anfreunden.

Da war auch mehr gemeint, dass man sich die Grundlagen, wie man eine konfliktfreie Grammatik definiert zuerst durch "einfache Sprachen in EBNF" durchdenken kann, quasi zur Übung, nicht für die Sprache die man dann tatsächlich kreieren will.