Buch zum Thema Programmiersprachendesign/Compilerbau

[Xin]

Moin

Heute schrieb mich ein Verlag an, ob ich nicht ein Buch zu diesem Thema schreiben möchte.
Nun ist das ja mein Thema und so sind die dann auch auf mich gekommen, also überlege ich das auch zu tun.

Und aus dem Grund stelle ich mal ganz einfach ein paar allgemeine Fragen:

• Was würdet ihr euch von einem Buch in dem Bereich versprechen,
• was würdet ihr gerne lesen wollen,
• was würdet ihr gerne behandelt wissen?

Ganz allgemein, was würdet ihr gerne zu dem Thema alles wissen, zu welchen Fähigkeiten würdet ihr gerne kommen, wenn ihr solch ein Buch in die Hand bekommt? Quasi freies Brainstorming hier, was gewünscht wird. Ob ich das umsetzen kann, sieht man vielleicht später.

[Dirty Oerti]

Tag!

Nicht schlecht
Wichtig zu erwähnen wird wohl sein, warum man verschiedene Programmiersprachen benötigt
Vorteile und Nachteile einiger Programmiersprachen aufzuzeigen und eine eventuelle Möglichkeit zu bieten, wie so etwas besser gelöst hätte sein können fände ich auch recht interessant. Wobei man da nicht zu ausschweifend werden sollte.


Zu welchen Fähigkeiten möchte ich durch so ein Buch kommen..?
Nunja, ich möchte entscheiden können, was an einer Programmiersprache gut ist. Was dagegen schlecht ist.
Nach so einem Buch würde ich gerne in der Lage sein zu entscheiden, ob eine Programmiersprache geglückt ist oder nicht.

Eventuell kannst du in so ein Buch ja auch "Praxis" einbeziehen...

[Xin]

Danke für die Anregungen.
Da war schonmal einiges dabei, was ich mir gut vorstellen könnte einfließen zu lassen.

[fat-lobyte]

Moin

Heute schrieb mich ein Verlag an, ob ich nicht ein Buch zu diesem Thema schreiben möchte.
Nun ist das ja mein Thema und so sind die dann auch auf mich gekommen, also überlege ich das auch zu tun.

Und aus dem Grund stelle ich mal ganz einfach ein paar allgemeine Fragen:

• Was würdet ihr euch von einem Buch in dem Bereich versprechen,
• was würdet ihr gerne lesen wollen,
• was würdet ihr gerne behandelt wissen?

Ganz allgemein, was würdet ihr gerne zu dem Thema alles wissen, zu welchen Fähigkeiten würdet ihr gerne kommen, wenn ihr solch ein Buch in die Hand bekommt? Quasi freies Brainstorming hier, was gewünscht wird. Ob ich das umsetzen kann, sieht man vielleicht später.

Ich kann natürlich keine Qualifizerte Antwort geben, aber hier mal meine "Meinung":
Von dem Buch würde ich mir versprechen, dass ich nach dem Lesen weiß, wie ein Compiler aufgebaut ist, wie eine Programmiersprache "Funktioniert", und wie man selbst einen schreiben Könnte.

Lesen würde ich gerne etwas von Grammatik, (E)BNF, und Parsern und Lexern. (Frontend?) Außerdem noch von "Ausdrucksbäumen" und Codegenierung (Backend?).
Vielleicht ein kleiner Ausflug in (x86-) Assembly, gerade soviel wie zum Verständnis notwendig ist. Evtl. noch ein kleines Kapitel über Optimierungen.

Wie Dirti Oerty schon gemeint hat, sollte man (ich finde in der Einführung) ein oder zwei Kapiteln darüber schreiben, was Programmiersprachen so ausmacht, was es für Vorteile gibt, welche Nachteile sie nach sich ziehen usw.

Vielleicht solltest du als "Begleitprojekt" entweder deinen Compiler als Beispiel weiterentwickeln, oder im Laufe des Buches selbst eine kleine und einfache Interpretersprache (der auch kompilierte?) mitsamt Compiler Entwickeln. Alternativ könntest du im Buch auch einen Blick unter die Haube vom GCC werfen. GCC ist immerhin _DER_ Comppiler der Open Source Community, und mittlerweile ist er auch ziemlich gut geworden (was die Sprache(n), aber auch die Optimierung betrifft)

Ich hoffe da war was dabei für dich...

Ansonsten Gratuliere ich dir zu deiner Chance! Ich denke mir so ein Buch zu schreiben würde dir persönlich viel Bringen, und auch Finanziell wäre das sicher nicht so unvorteilhaft.

mfg, fat-lobyte

[Xin]

Ich kann natürlich keine Qualifizerte Antwort geben, aber hier mal meine "Meinung":

Mehr möchte ich auch nicht, es geht mir nur darum herauszufinden, was Leute bewegen würde, ein solches Buch haben zu wollen. Es bringt ja nicht viel, wenn man sich die Mühe macht etwas zu schreiben, was niemand lesen möchte.

Vielleicht ein kleiner Ausflug in (x86-) Assembly, gerade soviel wie zum Verständnis notwendig ist. Evtl. noch ein kleines Kapitel über Optimierungen.

Optimierung des Expressiontrees sicher, Optimierung des Backends, das würde Bücherbände füllen.
Der Ausflug in x86 ASM wäre natürlich schon happig.

Wie Dirti Oerty schon gemeint hat, sollte man (ich finde in der Einführung) ein oder zwei Kapiteln darüber schreiben, was Programmiersprachen so ausmacht, was es für Vorteile gibt, welche Nachteile sie nach sich ziehen usw.

Programmiersprachen unterscheiden sich in vielen Dingen.
Ein solches Kapitel habe ich praktischerweise bereits, daher frage ich mal ganz offen, welche Unterschiede wären für euch denn interessant?

Vielleicht solltest du als "Begleitprojekt" entweder deinen Compiler als Beispiel weiterentwickeln, oder im Laufe des Buches selbst eine kleine und einfache Interpretersprache (der auch kompilierte?) mitsamt Compiler Entwickeln.

Eine Weiterentwicklung ist ausgeschlossen - was ich an Dokumentation zum halbentwickelten Compiler habe, sprengt bereits den Rahmen eines Buches.
Eine kleine kompilierende Interpretersprache wäre sicherlich möglich.

Alternativ könntest du im Buch auch einen Blick unter die Haube vom GCC werfen. GCC ist immerhin _DER_ Comppiler der Open Source Community, und mittlerweile ist er auch ziemlich gut geworden (was die Sprache(n), aber auch die Optimierung betrifft)

Hmm... von der Idee auch nicht verkehrt, doch da stellt sich mir die Frage, wie aktuell so ein Buch bleiben kann.

Ich hoffe da war was dabei für dich...

Eine ganze Reihe - jede Meinung zählt.

Ansonsten Gratuliere ich dir zu deiner Chance! Ich denke mir so ein Buch zu schreiben würde dir persönlich viel Bringen, und auch Finanziell wäre das sicher nicht so unvorteilhaft.

Finanziell bezweifle ich, dass das interessant wird. Das ist kein Thema, dass die Masse anspricht, deswegen gibt es ja so wenig Fachbücher und soviele Einsteigerbücher. ^^

Vielleicht sollte ich ein "Compiler Construction für Dummies" schreiben

[fat-lobyte]

Vielleicht ein kleiner Ausflug in (x86-) Assembly, gerade soviel wie zum Verständnis notwendig ist. Evtl. noch ein kleines Kapitel über Optimierungen.

Optimierung des Expressiontrees sicher, Optimierung des Backends, das würde Bücherbände füllen.

Das dachte ich mir schon. Deswegen meinte ich auch, dass es ein _kleines_ Kapitel wäre, mit einer kleinen Einführung. Dass es Tausende von Artikeln, Benchmarks und Optimierte Assemblycodes darüber gibt, weil das Thema so komplex ist, ist mir schon klar.

Ausflug in x86 ASM wäre natürlich schon happig.

Inwiefern? Es wäre ziemlich sicher Notwendig, wenn du demonstrieren willst, wie ein "Compiler" (nicht Interpreter) funktioniert. Denn es ist nunmal so dass x86 ein der weitverbreitetsten Prozessoren der Welt ist. Nicht für ungut, aber ich glaube kaum, dass die Leute das Buch von den Regalen reißen würden, wenn du einen Compiler für AmigaOS schreibst

Wie Dirti Oerty schon gemeint hat, sollte man (ich finde in der Einführung) ein oder zwei Kapiteln darüber schreiben, was Programmiersprachen so ausmacht, was es für Vorteile gibt, welche Nachteile sie nach sich ziehen usw.

Programmiersprachen unterscheiden sich in vielen Dingen.
Ein solches Kapitel habe ich praktischerweise bereits, daher frage ich mal ganz offen, welche Unterschiede wären für euch denn interessant?

Wie gesagt, viel qualifiziertes kann ich nicht von mir geben. Aber ich dachte mir erstmal die Unterschiede zwischen Kompiliert, Interpretiert, und Halb-Interpetiert, und noch die 17 anderen Facetten, die du im Wiki genannt hast. (Ok, das thema hat schon nen Bart...) Was du aber behandeln könntest wären die Vorteile, und wie diese Vorteile automatisch Nachteile mit sich bringen. Beispielsweise: (Binäre) Plattformunabhängigkeit -> Geschwindigkeit, Einfache Syntax -> Eingeschränkte Möglichkeiten. Hardwarenähe -> Gravierende Auswirkung bei Fehlern...
Sicherlich wird das meiste von dem was ich gerade geschrieben habe Blödsinn sein - Aber anstatt (oder besser neben dem) dass du mir erklärst wieso, könntest du darüber schreiben.

Alternativ könntest du im Buch auch einen Blick unter die Haube vom GCC werfen. GCC ist immerhin _DER_ Comppiler der Open Source Community, und mittlerweile ist er auch ziemlich gut geworden (was die Sprache(n), aber auch die Optimierung betrifft)

Hmm... von der Idee auch nicht verkehrt, doch da stellt sich mir die Frage, wie aktuell so ein Buch bleiben kann.

Die Frage ist schon richtig - was ich allerdings meinte waren nicht wirklich die "Implementierungsdetails", sonder eher den Aufbau des Compilers (Was Frontend ist, was Backend, wie die Komponten der verschiedenen Sprachen miteinander agieren), des Projekts, vielleicht auch ein bisschen der Sozialen Strukturen innerhalb von dem Projekt. Klar hat das nicht "direkt" mit Compilerbau zu tun. Aber ich denke, es kann nicht schaden wenn jemand der sich für Compiler interessiert sich eventuell irgendwann mal im "größten" Open Source Compiler einklinken kann, dort mal schaut wie es läuft und vielleicht mal den einen oder anderen Patch beitragen kann.

Ansonsten Gratuliere ich dir zu deiner Chance! Ich denke mir so ein Buch zu schreiben würde dir persönlich viel Bringen, und auch Finanziell wäre das sicher nicht so unvorteilhaft.

Finanziell bezweifle ich, dass das interessant wird. Das ist kein Thema, dass die Masse anspricht, deswegen gibt es ja so wenig Fachbücher und soviele Einsteigerbücher. ^^

Vielleicht sollte ich ein "Compiler Construction für Dummies" schreiben

*lol* "Interstellare Astrophysik für Dummies"

[Xin]

Ausflug in x86 ASM wäre natürlich schon happig.

Inwiefern? Es wäre ziemlich sicher Notwendig, wenn du demonstrieren willst, wie ein "Compiler" (nicht Interpreter) funktioniert. Denn es ist nunmal so dass x86 ein der weitverbreitetsten Prozessoren der Welt ist. Nicht für ungut, aber ich glaube kaum, dass die Leute das Buch von den Regalen reißen würden, wenn du einen Compiler für AmigaOS schreibst

Das meine ich nicht.
Um einen "Ausflug" in die x86er Programme zu machen, müsste man a) ein Verständnis für Assembler voraussetzen b) ein Verständnis für ELF und/oder COFF-Files (Linux/Windows-Executables) und wie man diese aufbaut. Also mal eben 'anreißen' sind da schon ein ganzer Batzen Seiten.

>Programmiersprachenunterschiede
Ein solches Kapitel habe ich praktischerweise bereits, daher frage ich mal ganz offen, welche Unterschiede wären für euch denn interessant?

Wie gesagt, viel qualifiziertes kann ich nicht von mir geben. Aber ich dachte mir erstmal die Unterschiede zwischen Kompiliert, Interpretiert, und Halb-Interpetiert, und noch die 17 anderen Facetten, die du im Wiki genannt hast. (Ok, das thema hat schon nen Bart...) Was du aber behandeln könntest wären die Vorteile, und wie diese Vorteile automatisch Nachteile mit sich bringen. Beispielsweise: (Binäre) Plattformunabhängigkeit -> Geschwindigkeit, Einfache Syntax -> Eingeschränkte Möglichkeiten. Hardwarenähe -> Gravierende Auswirkung bei Fehlern...
Sicherlich wird das meiste von dem was ich gerade geschrieben habe Blödsinn sein - Aber anstatt (oder besser neben dem) dass du mir erklärst wieso, könntest du darüber schreiben.

Och, so blödsinnig ist das nicht, das war Teil meiner Diplomarbeit.

Die Frage ist schon richtig - was ich allerdings meinte waren nicht wirklich die "Implementierungsdetails", sonder eher den Aufbau des Compilers (Was Frontend ist, was Backend, wie die Komponten der verschiedenen Sprachen miteinander agieren), des Projekts, vielleicht auch ein bisschen der Sozialen Strukturen innerhalb von dem Projekt. Klar hat das nicht "direkt" mit Compilerbau zu tun. Aber ich denke, es kann nicht schaden wenn jemand der sich für Compiler interessiert sich eventuell irgendwann mal im "größten" Open Source Compiler einklinken kann, dort mal schaut wie es läuft und vielleicht mal den einen oder anderen Patch beitragen kann.

Sicher, nur muss man sich da auch überlegen, wie groß der Aufwand in Seiten wird, wen das dann am Schluss noch interessiert, wenn er 100 Seiten lesen muss, um ein paar Beispiele nachzuvollziehen. Die grundsätzlichen Dinge, wie halt ein Backend von beliebigen Frontends bedient wird, dafür braucht man den GCC nicht unbedingt zu obduzieren.

[fat-lobyte]

Das meine ich nicht.
Um einen "Ausflug" in die x86er Programme zu machen, müsste man a) ein Verständnis für Assembler voraussetzen b) ein Verständnis für ELF und/oder COFF-Files (Linux/Windows-Executables) und wie man diese aufbaut. Also mal eben 'anreißen' sind da schon ein ganzer Batzen Seiten.

Achso... das ist auch wieder Richtig. Nur: Ist das nicht die Hauptaufgabe eines Compilers? Executables erzeugen? Vielleicht muss es ja nicht unbedingt ELF,COFF oder PE sein... Aber irgend ein Format, das von Betriebssystemen Lesbar ist solltest du schon einbauen.

Ich weiß, dass es schwierig für dich ist bei irgend einem Teilgebiet zu beschränken. Aber schau:
Compilerbau IST NUNMAL ein ziemlich komplexes Gebiet! Das war auch der Grund wieso ich "Compilerbau für Dummies" so amüsant fand: Einen Compiler zu schreiben ist nicht das gleiche wie mal eben eine Webseite einzurichten. Du brauchst Grundlegende Kenntnisse von ganz Unten bis ganz Oben: über das betriebssystem, vielleicht sogar die Hardware, über das was eine "Sprache" (nicht nur Computer, sondern allgemein) ist, was man mit der Sprache erreichen soll, wie man den Programmierer dazu zwingt sauber zu denken.
All das sind Themen, die an sich schon Bücher füllen - die du aber einbauen musst. Also ich sehe nicht viele Möglickeiten das Buch kurz zu halten .

Och, so blödsinnig ist das nicht, das war Teil meiner Diplomarbeit.

Umso besser, so hast du ja schon mal Material und Know- How, das du verwenden Könntest.

Die Frage ist schon richtig - was ich allerdings meinte waren nicht wirklich die "Implementierungsdetails", sonder eher den Aufbau des Compilers (Was Frontend ist, was Backend, wie die Komponten der verschiedenen Sprachen miteinander agieren), des Projekts, vielleicht auch ein bisschen der Sozialen Strukturen innerhalb von dem Projekt. Klar hat das nicht "direkt" mit Compilerbau zu tun. Aber ich denke, es kann nicht schaden wenn jemand der sich für Compiler interessiert sich eventuell irgendwann mal im "größten" Open Source Compiler einklinken kann, dort mal schaut wie es läuft und vielleicht mal den einen oder anderen Patch beitragen kann.

Sicher, nur muss man sich da auch überlegen, wie groß der Aufwand in Seiten wird, wen das dann am Schluss noch interessiert, wenn er 100 Seiten lesen muss, um ein paar Beispiele nachzuvollziehen. Die grundsätzlichen Dinge, wie halt ein Backend von beliebigen Frontends bedient wird, dafür braucht man den GCC nicht unbedingt zu obduzieren.

Dast stimmt, da hast du recht. War eigentlich auch nur eine Idee.

[Xin]

Um einen "Ausflug" in die x86er Programme zu machen, müsste man a) ein Verständnis für Assembler voraussetzen b) ein Verständnis für ELF und/oder COFF-Files (Linux/Windows-Executables) und wie man diese aufbaut. Also mal eben 'anreißen' sind da schon ein ganzer Batzen Seiten.

Achso... das ist auch wieder Richtig. Nur: Ist das nicht die Hauptaufgabe eines Compilers? Executables erzeugen? Vielleicht muss es ja nicht unbedingt ELF,COFF oder PE sein... Aber irgend ein Format, das von Betriebssystemen Lesbar ist solltest du schon einbauen.

Naja, mehr als ein OS wird dabei kaum rauskommen.

Compilerbau IST NUNMAL ein ziemlich komplexes Gebiet! Du brauchst Grundlegende Kenntnisse von ganz Unten bis ganz Oben: über das betriebssystem, vielleicht sogar die Hardware, über das was eine "Sprache" (nicht nur Computer, sondern allgemein) ist, was man mit der Sprache erreichen soll, wie man den Programmierer dazu zwingt sauber zu denken.
All das sind Themen, die an sich schon Bücher füllen - die du aber einbauen musst. Also ich sehe nicht viele Möglickeiten das Buch kurz zu halten .

Lange Bücher liest niemand freiwillig.

Och, so blödsinnig ist das nicht, das war Teil meiner Diplomarbeit.

Umso besser, so hast du ja schon mal Material und Know- How, das du verwenden Könntest.

Darum wurde ich ja auch zu dem Thema angeschrieben.

Sicher, nur muss man sich da auch überlegen, wie groß der Aufwand in Seiten wird, wen das dann am Schluss noch interessiert, wenn er 100 Seiten lesen muss, um ein paar Beispiele nachzuvollziehen. Die grundsätzlichen Dinge, wie halt ein Backend von beliebigen Frontends bedient wird, dafür braucht man den GCC nicht unbedingt zu obduzieren.

Dast stimmt, da hast du recht. War eigentlich auch nur eine Idee.

Ich schätze jede Idee, ihr sollt mich hier ja auch ein wenig inspirieren, die Sachen richtig aufzubauen und eine brauchbare und interessante Gewichtung zu finden, was theroretische und praktische Anteile angeht.
Also verstehe nichts, was ich hier schreibe, als Ablehnung, sondern mehr als Auseinandersetzung mit der Idee. Die Idee einen Überblick über den GCC einzubauen, ist nicht vergessen. Es muss wenn denn aber so stattfinden, dass es für einen Leser einen Wert hat, oder es muss weggelassen werden, weil der Text sonst Zeitverschwendung ist und die Mehrseiten nur das Buch unnötig verteuern.

[fat-lobyte]

Compilerbau IST NUNMAL ein ziemlich komplexes Gebiet! Du brauchst Grundlegende Kenntnisse von ganz Unten bis ganz Oben: über das betriebssystem, vielleicht sogar die Hardware, über das was eine "Sprache" (nicht nur Computer, sondern allgemein) ist, was man mit der Sprache erreichen soll, wie man den Programmierer dazu zwingt sauber zu denken.
All das sind Themen, die an sich schon Bücher füllen - die du aber einbauen musst. Also ich sehe nicht viele Möglickeiten das Buch kurz zu halten .

Lange Bücher liest niemand freiwillig.

Wie willst du es dann Handhaben? Wenn es zu kurz wird, steht keine Info drinnen. Wenn es zu lang ist, liest es keiner. Du verlierst scheinbar so oder so. Die Frage ist jetzt aber welches Clientele du bedienen willst: Sind es erfahrene Programmierer die von ihrer Firma beauftragt worden sind, eine Programmiersprache zu Schaffen? Oder sind es Hobbyprogrammierer, die wissen wollen, wie ein Compiler eigentlich so Funktioniert? Oder sind es Kids wie Schwani, die nach einem frustrierenden Erlebnis mit Basic davon Träumen die beste Programmiersprache der Welt zu schreiben?
Ich finde wenn du dir darüber im klaren bist, wirst du auch wissen, wie du Detailliertheit/Kürze balancierst. Ich kenne mich nicht aus in diesem Gebiet und habe deswegen nicht viel zu sagen, aber von meiner Perspektive ist das ein gigantisches Themengebiet, dass man nicht einfach mal so behandeln kann. Oder siehst du das anders?