Eigene Programmiersprache - Lexer, Parser, usw

[BeRsErKeR]

Ich plane eine eigene Programmiersprache zu basteln. Ich sitze bislang noch am Konzept. Nun hab ich mich mal umgesehen, was es so für vorhandene Bibliotheken, Tools usw. gibt um geeignete Lexer, Parser, etc. zu erstellen und wollte mal nachfragen ob ihr etwas empfehlen könnt oder bereits gute oder schlechte Erfahrungen mit diversen Compilerbaukästen gemacht habt. Ich habe schon mit lex, yacc, bison usw. gearbeitet und hab mir nun auch schon boost::spirit angeschaut. Ich weiß aber noch nicht so recht, ob das alles das Wahre ist. Würdet ihr vielleicht sogar dazu raten selbst die Tools (oder Teile davon) zu schreiben?

Da meine Sprache sehr strikt und ähnlich wie Python, Tabulatoren als Strukturierungselement nutzen soll, habe ich doch ein paar Probleme insbesondere mit boost::spirit gehabt. Aber auch mit einer EBNF tue ich mich bei einigen Sachen noch etwas schwer. Man muss ja z.B. die Einrückungen mitzählen und bei vielen Verschachtelungen kann das schon komplexer werden, als mir lieb ist.

Da das ganze auch einen Lerneffekt haben soll und ich auch mal über den Tellerrand von lex/bison schauen will, würde ich schon gern eine etwas moderne Library (am liebsten C oder C++) nutzen. Hat denn jemand Erfahrung mit boost::spirit oder vergleichbaren Libs? Ist vielleicht sogar eine Mischung sinnvoll? Es kommen ja noch Dinge hinzu wie Optimierung, ggf. Zwischencodeerzeugung usw. Wobei mein Fokus zunächst auf Parser und falls nötig Lexer liegt.

Ich bin für alle Empfehlungen, Hinweise, Erfahrungsberichte aber auch Links auf Artikel usw. dankbar. ;)

[Florian Keßeler]

Also ich würde prinzipiell eher Generatoren benutzen. Lexer und Parser manuell zu schreiben kann man zwar machen, aber es ist eine eher langweilige, langwierige und fehleranfällige Aufgabe. Wenn du auf den Lerneffekt aus bist, könntest du das tun, ansonsten würde ich die Arbeit eher jemand anderem überlassen, vor allem weil du dann (bei entsprechend entworfener Syntax) sofort einen relativ schnellen Parser bekommst, was bei selbstgeschriebenem Code durchaus erstmal nicht der Fall sein könnte ;-)

flex und bison finde ich inzwischen etwas altbacken, du bist immer wieder gezwungen, dich auf alte C-Probleme einzulassen, obwohl der rest deines Compilers in noch so schönem C++ geschrieben ist. Da gefällt mir persönlich spirit erstmal besser, auf wenn ich damit bisher nur wenig gearbeitet habe. Da kriegst du jedenfalls alles schön sauber gekapselt und ohne den ganzen Low-Level-Kram selbst machen zu müssen.

Mit spirit::lex sollte es auch relativ einfach sein, deine Einrückungen zu tracken (oder gleich zeilenweise lexen).

[RustySpoon]

Irgendwie konnte ich jetzt hier 2-3x nicht posten, sehr seltsam. oO

Jedenfalls: Schau dir unbedingt mal das LLVM-Projekt an!

[BeRsErKeR]

Danke erstmal für die Antworten. LLVM hab ich mir auch schon angeschaut aber noch nichts mit gemacht. Da werd ich nochmal gucken.

@Florian: Ja flex und bison sind altbacken und genau aus diesem Grund würde ich ja gern etwas Moderneres wie halt boost::spirit nutzen. Beim Lerneffekt ziele ich mehr auf das Design der Sprache (auch die Regeln für den Parser usw.) ab als auf das händische Programmieren des Lexers/Parsers. Von daher möchte ich schon auf Generatoren oder Libs zurückgreifen, die mir die grundlegenden Dinge abnehmen. Man kann aber auch viele Fehler bei den Regeln für den Parser machen, sei es nun als EBNF oder als Parser-Objekte von boost::spirit. Was mir auch wichtig wäre, ist eine gute Schnittstelle von Parser zu folgenden/parallelen Verarbeitungsschritten, wie Opcode-Generierung, semantische Aktionen, Zwischencodegenerierung und Optimierung. Wenigstens für den zweiten Punkt bietet boost::spirit soweit ich weiß schon was an. Beim Rest müsste ich entweder selbst tätig werden oder hinten dran noch eine andere Lib zuschalten. Auch hier die Frage was ihr dahingehend empfehlen würdet.

[Florian Keßeler]

Die semantischen Aktionen, die spirit anbietet sind eigentlich das gleiche wie das, was Bison anbietet: Für jedes Stück korrekt geparste Eingabe ein Stück Code aufrufen. Üblicherweise würdest du daraus erstmal einen kompletten Syntaxbaum erstellen und später dann auf diesem an der semantischen Analyse arbeiten. Nicht alles, was dann in deinem Baum ist, wird auch wirklich als Opcode in deinem Kompilat auftauchen. Vieles davon sind dann immer noch Typ-/Variablendeklarationen, Syntaxnotwendigkeiten usw. oder werden direkt an dieser Stelle schon wegoptimiert. Vergiss nicht die semantische Analyse, nur weil etwas eine korrekte Eingabe für den Parser ist, ist es noch kein gültiges Programm.

Du musst ja auch nicht zwischen EBNF und spirit wählen. Spirit bietet dir nur eine relativ elegante Möglichkeit, deine EBNF-Grammatik direkt als C++-Code hinzuschreiben, du solltest dich also trotz allem mit Chomsky-Grammatiken und speziell ihrer Darstellung als EBNF auskennen...

[Virus]

Wird zwar weder mit C++ geschrieben, noch glaube ich das es einfach sein wird, damit Sprachen zu erstellen, bei denen Tabulatoren Einfluss auf die Semantik haben, trotzdem solltest du es dir unbedingt mal ansehen: Xtext. Darin definierst du eine Grammatik, der Rest wird daraus generiert (z. B. der Parser und ein Editor). Das kann dann bei Bedarf erweitert/angepasst werden (in Java). Vorteil: Du hast am Ende einen Editor (mit Syntax Highlighting, Proposals, Outline usw) und musst dafür wenig machen. Die tollste Sprache nützt nichts, wenn es dafür keine guten Tools gibt.

[Florian Keßeler]

1. Kann man auch ohne tolle IDE hervorragend programmieren
2. Die besten Tools sind vollständig wertlos, wenn es keine passende Sprache gibt

[Virus]

1. Kann man auch ohne tolle IDE hervorragend programmieren

Meiner Erfahrung nach nicht annähernd so Effektiv wie mit. Das sehe ich auch bei Leuten, die meinen ihren C++-Code mit vi schreiben zu müssen.

2. Die besten Tools sind vollständig wertlos, wenn es keine passende Sprache gibt

Klar, aber das Gegenteil ist ebenfalls der Fall.

[Florian Keßeler]

1. Kann man auch ohne tolle IDE hervorragend programmieren

Meiner Erfahrung nach nicht annähernd so Effektiv wie mit. Das sehe ich auch bei Leuten, die meinen ihren C++-Code mit vi schreiben zu müssen.

Meine ich auch. Gut, nicht mit vi sondern mit vim, aber da wollen wir mal nicht pingelig sein. Mag sein, dass man mit IntelliSense und ähnlichem etwas schneller sein Zeug niederschreiben kann, aber es verleitet leider auch dazu, die Dokumentation seiner Bibliotheken gar nicht mehr richtig zu lesen. Das hab ich gemerkt, als ich mich mal 3 Wochen mit Java und Eclipse rumgeschlagen habe.

2. Die besten Tools sind vollständig wertlos, wenn es keine passende Sprache gibt

Klar, aber das Gegenteil ist ebenfalls der Fall.

Nö. Solange du den Compiler hast, kannst du mit der Sprache was anfangen. Wenn du Tools für eine nicht existente Sprache hast, bringen sie exakt gar nix.

[Virus]

Jedes Tool kann man falsch benutzen. Wer die Doku nicht ließt, nur weil der ContentAssist viel versprechende Dinge zeigt, ist halt selber schuld. Ich muss die Doku aber genausowenig (richtig) lesen, wenn ich alles mit einem einfachen Texteditor mache. Und: auch der Compiler ist ein Tool. Man kann überrings auch mit Sprachen etwas anfangen, ganz ohne Compiler oder irgendwelche Tools (... dabei meine ich nicht natürliche Sprachen). Bestimmt gibt es auch interessante Anwendungsbeispiele für Tools, für die es keine Sprache (oder was auch immer der Kontext ist) gibt (spätestens im Prototyping).

Worauf ich nur hinaus wollte ist, dass man sich wohl überlegen wollte, wie man geeignete Tools für seine neue Sprache erstellt (insbesondere den Editor). Ohne solche kann man eben nicht viel ("sinnvolles") anfangen mit der Sprache. Und mit Xtext bekommt man einen Editor eben geschenkt (naja, in den meisten Fällen wird wohl einige Anpassung nötig sein, aber man startet schon auf hohem Niveau). Und um Xtext herum existieren wieder andere Tools, die man dann auch noch braucht, etwa zur Transformation seiner Sprache in eine andere (etwa mit Acceleo), usw.

In diesem ganzen Ecipse-Umfeld gibt es einfach enorm viel, mit der man modellgetrieben seine Sprache entwickeln kann. Mit etwas Erfahrung kann man so verdammt schnell eine Sprache erstellen inkl. Editoren. Besonders interessant für Prototypen. Ich kenne nichts vergleichbares in der C++-Welt (würde aber dahingehnede Hinweise gern verfolgen).

Aber ja, es geht auch anders. Und es gibt bestimmt auch in gewissen Fällen gute Gründe dafür.

[Chromanoid]

Kann da Virus nur zustimmen. Vielleicht kann man die Tools ja auch nur benutzen, um erst mal einen Prototyp der gewünschten Sprache zu entwerfen... Insgesamt gibt's viele gute Tools für Sprachentwicklung, die in Java entwickelt wurden (z.B. JavaCC, XMLVM oder ANTLR*).
*ANTLR würde ich mir auf jeden Fall mal anschauen.

[Florian Keßeler]

Die meisten erfolgreichen Sprachen kommen trotzdem zunächst mal ohne eigenen Editor oder sonstige Dekoration aus. Wenn die Sprache für irgendwen interessant ist, folgen diese Tools sowieso früher oder später und sie sollten nicht schon im Vorfeld den Entwurf oder die Implementierung beeinflussen. Die Tools sollten auf die Anforderungen der Sprache abgestimmt werden, nicht umgekehrt.

[Virus]

Die meisten erfolgreichen Sprachen kommen trotzdem zunächst mal ohne eigenen Editor oder sonstige Dekoration aus.

Das ist eine These, bei der du dich nicht mal um eine Begründung bemühst. Also gehe ich mal nicht weiter darauf ein.

Wenn die Sprache für irgendwen interessant ist, folgen diese Tools sowieso früher oder später und sie sollten nicht schon im Vorfeld den Entwurf oder die Implementierung beeinflussen. Die Tools sollten auf die Anforderungen der Sprache abgestimmt werden, nicht umgekehrt.

Nein, das Komplettpaket muss stimmen. Nehmen wir an, ich schreibe ein Paper und beschreibe darin eine Sprache, von der du sagst: Wow, tolle Sache. Ich habe aber nichts getan, damit die Sprache wirklich benutzt werden kann. Dann wirst du sie nicht benutzen, einfach weil man es nicht kann. Und der Aufwand, dahin zu gelangen, einfach sehr hoch ist. Den würdest du doch nur in absoluten Ausnahmen betreiben, und zwar dann, wenn du meinst das der Aufwand hinten raus sich rechnet. Das wirst du zumindest für kleinere ein- bis wenig-Mann-Projekte eher nicht erreichen.

Sprache und Tools müssen in beide Richtungen aufeinander abgestimmt werden. Die tollste Sprache nützt nichts, wenn es dafür nicht möglich ist, gute Tools zu entwickeln. Weil man ohne die Sprache nicht nutzen kann. Also sollte man auch schon bei Entwurf der Sprache ans Tooling denken.

Denke überrings auch daran, dass ein Compiler ein Tool ist. So ist ein Grund, warum etwa die Sprache UML ist, wo sie ist, der, dass ihre Semantik nicht eindeutig ist. Es kann also keinen Compiler geben (der dem Standard folgt). D. h., wäre das ausschließliche Ziel gewesen, mit UML ausführbare Programme beschreiben zu können, wäre sie sinnlos. Und da kann man sich Mühe geben wie man möchte, Tools zu schreiben, denn die Sprache verbietet hier so einiges. Das Sprach-Design muss also den Tools folgen: Und das tut es auch in UML.

Ich rede hier überrings von Sprachen, die für eine wie-auch-immer-geartete Programmierung einer was-auch-immer-für-eine Maschine genutzt werden soll, und zwar in der Praxis. Es gibt natürlich viele andere äußerst relevante Felder, wo meine Aussagen nicht stimmen - etwa in der theoretischen Informatik kommt man natürlich auch sehr gut ohne Editor für seine Sprache aus.

[BeRsErKeR]

Danke für die Hinweise. ANTLR hatte ich mir auch schon angeschaut. Ich habe leider eine starke Abneigung gegen Java und würde darauf nur im äußersten Notfall zurückgreifen wollen.

Die Generierung eines Editors bzw. einer kompletten IDE sehe ich derzeit auch nicht als Ziel an. Mein Ziel ist ein halbwegs vernünftiger Kommandozeilen-Compiler, in der Art von gcc. Ich möchte zunächst einfach nur erreichen, dass man was Ausführbares und vorallem Testbares produzieren kann. Aber selbst bis zur Fertigstellung des kompletten Compilers werden einige Monate ins Land streichen.

Es ist ohnehin mehr als unwahrscheinlich, dass die Sprache, die ich bastel, jemals von einer breiten Masse genutzt wird, ganz zu schweigen von professionellem Einsatz. Dafür fehlen mir schlicht die Erfahrung, das Know-How in speziellen Dingen und die Mithelfer. ;)


Was mir aber auch mal so durch den Kopf schoss:

In diesem Forum sind meiner Meinung nach sehr viele hochqualifizierte Know-How-Träger, Leute mit Spezialwissen und viel Erfahrung. Und wenn ich an so Leute wie Krishty, CodingCat, dot usw. denke, bin ich mir ziemlich sicher, dass man hier sehr gut eine "ZFX-Programmiersprache" entwickeln könnte, bei der alle zusammenarbeiten, Ideen sammeln / brainstormen, über Sprachkonzepte und Optimierungen diskutieren usw. DABEI könnte etwas rauskommen, was wirklich mal eine ernstzunehmende Alternative zu heutigen Sprachen werden könnte. Wäre vielleicht mal eine Idee.

[Chromanoid]

Nur falls du es nicht gesehen hast. ANTLR und Co. können Compiler-Code o.Ä. auch in anderen Sprachen erzeugen. Es wäre also nur das Tool in Java...

@ZFX Programmiersprache: Ich persönlich sehe wenig Sinn in noch einer neuen Sprache. Ich habe jetzt schon mindestens 5 Sprachen auf der Ausprobierliste und es werden nicht weniger. Um nur mal ein paar zu nennen: Clojure, Scala, Groovy, Ada, Erlang.
Da sich hier ja ziemlich viele C++-Fans rumtreiben, wäre ich persönlich ja eher für die gemeinsame Entwicklung eines automatischen sehr strengen Style-Checkers/Bug-Finders für C++ inkl. automatisiertem Verbesserungsmechanismus und Compile-Sperre bei verschiedenen allzu großen Patzern. Das Tool würde dann einen in der Community für gut befundenen Style erzwingen und Neulingen helfen den richtigen Weg zu finden... Für Java gibts da ziemlich viel, ich glaube bei C++ ist es in dem Bereich noch nicht so weit her, oder?

[BeRsErKeR]

Ja habe ich gesehen. Aber wie du schon sagst: Das Tool selbst ist halt Java. Ich werd es mir dennoch mal genauer ansehen.

@ZFX-Programmiersprache: MMn gibt es zwar viele neue Sprachen, aber sie gehen irgendwie alle Wege, die nicht unbedingt mit meine Vorstellungen übereinstimmen. Java ist damals auch einen bestimmten Weg gegangen, der für meinen Geschmack alles andere als befriedigend ist. Auch ich bin ein "C++ Fan", aber auch C++ hat vieles, was mich stört. Aber auch deine Idee wäre ein guter Schritt. ;)

[Florian Keßeler]

Die meisten erfolgreichen Sprachen kommen trotzdem zunächst mal ohne eigenen Editor oder sonstige Dekoration aus.

Das ist eine These, bei der du dich nicht mal um eine Begründung bemühst. Also gehe ich mal nicht weiter darauf ein.

Ich dachte, die Fülle an Positiv-Beispielen für diese Behauptung wäre offensichtlich. C hatte seit seiner Entstehung nie eine einheitliche Entwicklungsumgebung, die von den C-Entwicklern vorgegeben wurde (d.h. vermutlich haben die tatsächlich vi benutzt). Das selbe gilt für C++. Java hatte lange Zeit keine vom Hersteller mitgelieferte IDE, bis sie irgendwann NetBeans übernommen haben. Haskell hat keine feste IDE, Perl nicht, Ruby nicht, ... Gut, Python hat seit jeher IDLE, was ich aber bisher noch nie in irgendjemandes Benutzung gesehen habe. Haskell und C sind übrigens sehr gute Beispiele für Sprachen, die unabhängig von der zukünftig zu verwendenten Toolchain entwickelt wurden und entsprechend von verschiedenen Anbietern in verschiedene Compiler und Standardbibliotheken gegossen wurden und damit sehr erfolgreich wurden.

Als Gegenbeispiele fallen mir spontan VisualBASIC und Konsorten ein. Und das ist zufällig gleich ein Beispiel für eine ganz gruselige Sprache.

Ich sage nicht, dass Entwicklungsumgebungen unnötig sind. Aber ich halte es für absolut falsch, wenn der Designer einer Sprache sich von vornherein um diese sorgt anstatt sich auf die Bedürfnisse der Sprache selbst zu beschränken.

Wenn die Sprache für irgendwen interessant ist, folgen diese Tools sowieso früher oder später und sie sollten nicht schon im Vorfeld den Entwurf oder die Implementierung beeinflussen. Die Tools sollten auf die Anforderungen der Sprache abgestimmt werden, nicht umgekehrt.

Nein, das Komplettpaket muss stimmen. Nehmen wir an, ich schreibe ein Paper und beschreibe darin eine Sprache, von der du sagst: Wow, tolle Sache. Ich habe aber nichts getan, damit die Sprache wirklich benutzt werden kann. Dann wirst du sie nicht benutzen, einfach weil man es nicht kann. Und der Aufwand, dahin zu gelangen, einfach sehr hoch ist. Den würdest du doch nur in absoluten Ausnahmen betreiben, und zwar dann, wenn du meinst das der Aufwand hinten raus sich rechnet. Das wirst du zumindest für kleinere ein- bis wenig-Mann-Projekte eher nicht erreichen.

Sobald ein Compiler, eine Möglichkeit für eine Anbindung an C-Libraries und notfalls ein Linker (oder halt statt dessen ein ordentlicher Interpreter) vorhanden sind, kann man damit arbeiten. Wenn die Sprache selbst Vorteile gegenüber anderen Sprachen hat, für die es sich lohnt, die Sprache überhaupt erst zu lernen, dann kommt es auch nicht drauf an, ob noch eine tolle IDE dabei ist. Für kleine Projekte wird man ohnehin eher bei einer Sprache bleiben, die man bereits beherrscht. Alles andere ist nicht sehr ökonomisch.

Sprache und Tools müssen in beide Richtungen aufeinander abgestimmt werden. Die tollste Sprache nützt nichts, wenn es dafür nicht möglich ist, gute Tools zu entwickeln. Weil man ohne die Sprache nicht nutzen kann. Also sollte man auch schon bei Entwurf der Sprache ans Tooling denken.

Aber man sollte wie gesagt nicht die Wahl seiner Arbeitsmittel davon abhängig machen, dass man später die Tools bequem und umsonst dazu bekommt.

Denke überrings auch daran, dass ein Compiler ein Tool ist. So ist ein Grund, warum etwa die Sprache UML ist, wo sie ist, der, dass ihre Semantik nicht eindeutig ist. Es kann also keinen Compiler geben (der dem Standard folgt). D. h., wäre das ausschließliche Ziel gewesen, mit UML ausführbare Programme beschreiben zu können, wäre sie sinnlos. Und da kann man sich Mühe geben wie man möchte, Tools zu schreiben, denn die Sprache verbietet hier so einiges. Das Sprach-Design muss also den Tools folgen: Und das tut es auch in UML.

Ja, Compiler sind auch Tools und sollten austauschbar sein. Das muss man nicht durch Abhängigkeiten der Sprache von Tools die zum Schreiben des ersten Compiler benutzt werden verkomplizieren.

Ich rede hier überrings von Sprachen, die für eine wie-auch-immer-geartete Programmierung einer was-auch-immer-für-eine Maschine genutzt werden soll, und zwar in der Praxis. Es gibt natürlich viele andere äußerst relevante Felder, wo meine Aussagen nicht stimmen - etwa in der theoretischen Informatik kommt man natürlich auch sehr gut ohne Editor für seine Sprache aus.

Ich wüsste nicht, warum ein Texteditor (die ohnehin meistens einfache Möglichkeiten anbieten, z.B. eigenes Syntaxhighlighting zu machen) nicht ausreichen sollte. Es gibt grade bei Texteditoren viele Glaubenskriege im Bedienkonzept und manche Leute fühlen sich genervt, wenn ein Editor sich auf eine Weise verhält, die ihnen nicht gefällt und die sie nicht beeinflussen können. Will man eine weite Verbreitung der Sprache erreichen, muss man sie anbieten, ohne dem Benutzer einen bestimmten Editor aufzuzwingen. Das heißt ja nicht, dass man keinen mitliefern darf. Aber die Sprache sollte auf die Bedürfnisse des Nutzers angepasst sein, nicht auf die Bedürfnisse der IDE.

[Chromanoid]

Es sagt doch niemand, dass man nicht auch einen Command-Line-Compiler bereitstellen sollte. Es ist doch einfach eine nette Dreingabe, wenn neben den Kommandozeilen-Tools auch gleich noch ne nutzbare IDE rausspringt. So eine IDE ist doch das, was man als erstes vermisst, wenn man erst mal alle Tools hat, um Quelltext der Sprache in eine ausführbare Variante zu bringen... Wenn YACC auch gleich noch ein Syntax Layout für VIM auspucken würde und man das als einen Vorteil für YACC anführen würde, würdest du dich doch auch nicht beschweren oder?

[Florian Keßeler]

Es sagt doch niemand, dass man nicht auch einen Command-Line-Compiler bereitstellen sollte. Es ist doch einfach eine nette Dreingabe, wenn neben den Kommandozeilen-Tools auch gleich noch ne nutzbare IDE rausspringt. So eine IDE ist doch das, was man als erstes vermisst, wenn man erst mal alle Tools hat, um Quelltext der Sprache in eine ausführbare Variante zu bringen...

Das ist zwar eine ziemliche Verallgemeinerung (gib mir vim, nen Compiler, Linker, ne Shell, make und cmake und ich bin glücklich ;-)), aber dagegen hab ich ja auch nichts. Ich sag ja nur, man soll die Sprache nicht nach den Bedürfnissen der späteren Tools schreiben, sondern umgekehrt. Eine IDE dazugeben, klar, wenn man meint, dass es was bringt. Aber sich bei der Implementierung der Sprache schon auf bestimmte Technologien festlegen, die nur dazu dienen, später die Tools einfacher zu machen?

[Artificial Mind]

Ich sage nicht, dass Entwicklungsumgebungen unnötig sind. Aber ich halte es für absolut falsch, wenn der Designer einer Sprache sich von vornherein um diese sorgt anstatt sich auf die Bedürfnisse der Sprache selbst zu beschränken.

Sprache und Tools müssen in beide Richtungen aufeinander abgestimmt werden. Die tollste Sprache nützt nichts, wenn es dafür nicht möglich ist, gute Tools zu entwickeln. Weil man ohne die Sprache nicht nutzen kann. Also sollte man auch schon bei Entwurf der Sprache ans Tooling denken.

Aber man sollte wie gesagt nicht die Wahl seiner Arbeitsmittel davon abhängig machen, dass man später die Tools bequem und umsonst dazu bekommt.

Ich halte es für absolut richtig, eine Sprache zu designen, für die man auch gute Tools schreiben kann. C++ existiert ne ganze Weile länger als Java und wurde bereits viel mehr genutzt und trotzdem gibt es sehr viel weniger und schlechtere Tools. Warum? Weil der Preprocessor, die Uneindeutigkeiten und z.B. die Tatsache, dass man C++ schon semantisch analysieren muss, bevor man vernünftige Auto-Completion nutzen kann, dafür sorgen, dass man nur sehr schwer Tools schreiben kann. Java und z. B. auch D wurden bereits dafür designed, dass man sie einfach analysieren kann (d. h. klar Trennung von Semantik und Syntax, Syntax basierend auf einfacher Grammatik usw.)
Quellcode wird wesentlich häufiger gelesen und analysiert, als dass er geschrieben wird. Außerdem werden Techniken wie automatische Verifikation von Software immer wichtiger. Wenn eine Sprache sich von Anfang an Quer stellt und schwer zu analysieren ist, wird sie eine schwere Zeit haben.

Sobald ein Compiler, eine Möglichkeit für eine Anbindung an C-Libraries und notfalls ein Linker (oder halt statt dessen ein ordentlicher Interpreter) vorhanden sind, kann man damit arbeiten. Wenn die Sprache selbst Vorteile gegenüber anderen Sprachen hat, für die es sich lohnt, die Sprache überhaupt erst zu lernen, dann kommt es auch nicht drauf an, ob noch eine tolle IDE dabei ist. Für kleine Projekte wird man ohnehin eher bei einer Sprache bleiben, die man bereits beherrscht. Alles andere ist nicht sehr ökonomisch.

Also ich persönlich will nicht ohne IDE programmieren. Ich komme mir dann immer unendlich unproduktiv vor. Wenn ich daran denke, wie schnell und effizient ich im Visual Studio C# programmieren kann, dann kann ich mir nicht vorstellen warum man ohne IDE programmieren möchte.

Ich wüsste nicht, warum ein Texteditor (die ohnehin meistens einfache Möglichkeiten anbieten, z.B. eigenes Syntaxhighlighting zu machen) nicht ausreichen sollte. Es gibt grade bei Texteditoren viele Glaubenskriege im Bedienkonzept und manche Leute fühlen sich genervt, wenn ein Editor sich auf eine Weise verhält, die ihnen nicht gefällt und die sie nicht beeinflussen können. Will man eine weite Verbreitung der Sprache erreichen, muss man sie anbieten, ohne dem Benutzer einen bestimmten Editor aufzuzwingen. Das heißt ja nicht, dass man keinen mitliefern darf. Aber die Sprache sollte auf die Bedürfnisse des Nutzers angepasst sein, nicht auf die Bedürfnisse der IDE.

Meistens sind die Bedürfnisse von Benutzer und die von IDEs im Endeffekt die gleichen. Bzw. genauer genommen nicht die Bedürfnisse, sondern sind vernünftige Lösungen gleich, um die Bedürfnisse zu erfüllen. Ich habe zum Beispiel noch keine Autovervollständigung für C++ gesehen, die mit Templates richtig umgehen kann (und nicht nur mit einfachen Container-Templates). Und das Templatesystem ist nicht nur bei der Analyse schwierig, sondern auch für den Benutzer.

gib mir vim, nen Compiler, Linker, ne Shell, make und cmake und ich bin glücklich ;)

Aber produktiv bist du damit noch lange nicht :P Und mit produktiv meine ich auch bei Projekten mit hunderten von Dateien.

[Chromanoid]

Aber sich bei der Implementierung der Sprache schon auf bestimmte Technologien festlegen, die nur dazu dienen, später die Tools einfacher zu machen?

Klar sollte man erst mal ein Konzept für die Sprache entwickeln. Dann schaut man sich an mit welchem System man die Tools für die Sprache implementiert. Und da kann man dann ruhig die automatische "IDE-Erzeugung" als Vorteil anführen. In der Praxis von DSLs ist es allerdings oft so, dass eine IDE mit zum Konzept der Sprache gehört, da sich Nicht-Programmierer mit der Sprache auseinander setzen sollen. Die Sprache soll sich dann als DSL in einem abgesteckten Bereich durchsetzen. In diesem Fall finde ich es bei begrenzten Ressourcen sogar sehr sinnvoll bereits während der Konzeption der Sprache auf mögliche Erleichterungen bei der IDE Implementierung zu achten. Evt. sollte man dann auf ein nicht unbedingt benötigtes Sprachfeature, das sich schlecht mit dem ausgewählten Toolset realisieren lässt, zu Gunsten der erleichterten Implementierung anderer wichtiger Features (wie eine IDE) verzichten.

[Florian Keßeler]

Ja, Ansichtssache. Ich habe an der Arbeit mit einem ~2Mio. Zeilen-Projekt zu tun, das ich maintainen "darf". Das ganze lässt sich leider aus verschiedensten (organisatorischen) Gründen nicht von VC++6 auf eine neue IDE portieren. Wenn ich da irgendwas suche, nehme ich meine Kommandozeile mit cgvg und ctags und finde in Sekunden das, was ich mit dieser Top-IDE innerhalb von Stunden vergeblich suchen würde.

Aber ich stimme zu, dass man sich um Sachen wie einfache Analysierbarkeit kümmern muss. Das sollte aber ohnehin Bestandteil der Sprache und ordentlich geplant sein und nicht nur zufällig als Nebenprodukt abfallen, weil man von seinem Framework dazu gezwungen wird.

Ich "will" auch gar nicht ohne IDE programmieren, aber es gibt leider keine IDE, die mir die übrigen Features von vim liefert und eine enge Zusammenarbeit mit der Shell ermöglicht. Und wenn ich vor der Wahl stehe, auf Codevervollständigung (die es für vim allerdings auch gibt) und Refactoring-Tools oder auf grundlegenden Bedienkomfort zu verzichten, verzichte ich lieber auf Codevervollständigung. Gäbe es für Eclipse z.B. ein Plugin, das mir die vielen Textbearbeitungsmöglichkeiten und das Bedienkonzept von vim anbietet, würde ich vielleicht sogar noch mal zu Eclipse wechseln. Alles was ich da gefunden habe ist aber eher zweit- bis drittklassig.

Außerdem haben wir öfter mehrere Sprachen (und verschiedene Codegeneratoren), die zusammen zu einem fertigen Produkt beitragen. Die mit einer einzelnen IDE unter einen Hut zu bringen ist fast unmöglich. Mit cmake aber kein Problem.

[Florian Keßeler]

Aber sich bei der Implementierung der Sprache schon auf bestimmte Technologien festlegen, die nur dazu dienen, später die Tools einfacher zu machen?

Klar sollte man erst mal ein Konzept für die Sprache entwickeln. Dann schaut man sich an mit welchem System man die Tools für die Sprache implementiert. Und da kann man dann ruhig die automatische "IDE-Erzeugung" als Vorteil anführen. In der Praxis von DSLs ist es allerdings oft so, dass eine IDE mit zum Konzept der Sprache gehört, da sich Nicht-Programmierer mit der Sprache auseinander setzen sollen. Die Sprache soll sich dann als DSL in einem abgesteckten Bereich durchsetzen. In diesem Fall finde ich es bei begrenzten Ressourcen sogar sehr sinnvoll bereits während der Konzeption der Sprache auf mögliche Erleichterungen bei der IDE Implementierung zu achten. Evt. sollte man dann auf ein nicht unbedingt benötigtes Sprachfeature, das sich schlecht mit dem ausgewählten Toolset realisieren lässt, zu Gunsten der erleichterten Implementierung anderer wichtiger Features (wie eine IDE) verzichten.

Okay, ich bin von einer "echten" Programmiersprache ausgegangen. Wenn es darum geht für deine Kunden eine speziell zugeschnittene Sprache zu machen, sieht das anders aus. Da ist aber ohnehin ein Großteil des Drumherum meistens schon gegeben und man passt sich an. Aber bei General-Purpose-Sprachen finde ich eine saubere Sprachdefinition wesentlich wichtiger. Wenn die Sprache definiert ist, kann man (muss man) natürlich gucken, wie man sie umsetzt und was einem da die Arbeit erleichtert.

[CodingCat]

Um Mal auf den Ausgangspunkt der Diskussion zurückzukommen: Das Interessanteste an neuen Sprachen ist natürlich immer das, was diese besser als bisherige Sprachen machen sollen. Das müssen keine weltneuen Features sein. Die Motivation ist meist ohnehin eher, das Beste aus verschiedenen Sprachen konsequent in einer zu vereinen, und dabei möglicherweise zu vereinfachen oder zu verbessern. Genau diese Auswahl ist ein interessanter Ausgangspunkt für Diskussionen und Überlegungen, in denen verschiedene Blickwinkel allen Beteiligten Erkenntnisgewinn bringen können, ganz unabhängig davon, ob die diskutierte Sprache schlussendlich je umgesetzt/fertiggestellt wird. Deshalb wäre mein Vorschlag, dass du (BeRsErKeR) einfach mal die Dinge vorstellst, die du gerne diskutieren möchtest (am besten separater Thread? ;)).

Zu Erfahrungsberichten: Ich habe vor einem halben Jahr zusammen mit jokester aus sppro.de mal zum Spaß eine neue Sprache in ihren Grundzügen skizziert, und einen Parser(prototyp) (Quelltext bis zum AST) in C++ geschrieben. Ich habe keine fremden Tools für den Parser eingesetzt, weil ich mich nicht mit Grammatiken rumschlagen wollte. Die Sprache haben wir einfach so entworfen, dass an jeder Stelle von vorneherein klar ist, welches Token folgen muss. Damit ließ sich der (rekursive) Parser sehr knapp und elegant in wenigen Funktionen implementieren, die jeweils grob einem Sprachkonstrukt entsprechen. (Einfache Übersetzbarkeit erleichtert auch Analysetools!). Bei Interesse kann ich die Sprache hier auch gerne Mal in Grundzügen skizzieren (Parser Source Code gibts btw. auch).

Zur Kollaboration: Feedback/Anregungen gerne, wann immer Zeit da ist. Für mehr reicht die Zeit leider nicht.

[BeRsErKeR]

Ich werd mir mal ein paar Sachen überlegen. Leider ist auch meine Zeit gerade etwas begrenzt. An der Sprache wär ich schon interessiert. Vielleicht kannst du ja mal ein bischen was zeigen. ;)

[Alexander Kornrumpf]

Was war eigentlich nochmal das Problem mit Python?

[dot]

Was war eigentlich nochmal das Problem mit Python?

Wie jede Sprache hat auch Python Stärken und Schwächen. Ich persönlich bin z.B. rein prinzipiell schonmal überhaupt kein Fan von dynamic Typing, wobei es in Skriptsprachen zugegebenermaßen doch sinnvoll sein kann. Abgesehen davon, gefällt mir an Python nicht, dass Whitespace ein wesentlicher Teil der Syntax ist. Nichts desto trotz ist Python imo eine nette Skriptsprache, aber ganz sicher nicht die Lösung aller Probleme und auch kein potentieller Ersatz für C++...nichtmal ansatzweise... ;)

Ich denk wenn ich hier eine Sprache in den Raum werfen wollte, dann wäre das D...

[Alexander Kornrumpf]

Ist das nicht das Problem an dem Ansatz per se? Dass alles was hier entworfen werden könnte ebenfalls Schwächen haben wird. Ein xkcd zur Illustration:

http://xkcd.com/927/

Ich hab Python deshalb angeführt weil es meines Wissens ziemlich stark die Vision eines Einzelnen umsetzt anstelle einer Gruppe (zuviele Köche) und daher in sich halbwegs Schlüssig sein sollte (sofern das eben Möglich ist) was ich im übrigen als einen der Vorteile von C++ (z.B. ggü. Java) empfinde, die finer points an denen C++ sich "unlogisch" verhält erreichen hier wohl nur eher die "Cracks".

Was ich aus der RAII Diskussion mitgenommen habe ist die Idee eine Sprache zu haben, die einerseits das Risiko von Ressoucenlecks per Design minimiert (as in: es ist im idealfall einfach nicht möglich eine Ressource zu leaken oder nur in seltene Spezialfällen) und andererseits dafür keinen GC o.ä. bemüht (sondern eben scopes). Das scheint mir denn auch eine Marktlücke zu sein, ich kenne keine Sprache die dies erfüllt. Es ist argumentierbar relativ einfach in C++ Speicher zu leaken. Minimalbeispiel:

Code: Alles auswählen

while(true)
{
    new int;
}

[dot]

http://xkcd.com/927/

Ja, dass dieser Thread hier ultimativ auf das hinauslauft, denk ich auch ;)

Ich hab Python deshalb angeführt weil es meines Wissens ziemlich stark die Vision eines Einzelnen umsetzt anstelle einer Gruppe (zuviele Köche) und daher in sich halbwegs Schlüssig sein sollte (sofern das eben Möglich ist) was ich im übrigen als einen der Vorteile von C++ (z.B. ggü. Java) empfinde, die finer points an denen C++ sich "unlogisch" verhält erreichen hier wohl nur eher die "Cracks".

Da wär ich nicht so sicher. Wenn man sich z.B. mal eingehender mit C++ beschäftigt, findet man ständig irgendwelche Dinge, an die einer allein niemals hätte denken können. Zumindest ich bin immer wieder erstaunt, an was beim Entwurf von C++ alles gedacht wurde. Wenn es darum geht, potentielle Probleme zu identifizieren und elegante Lösungen zu finden, wirst du allein niemals so gut sein wie ein ganzes Expertenkommittee mit den unterschiedlichsten Hintergründen verstärkt von einer riesigen Community...

Was ich aus der RAII Diskussion mitgenommen habe ist die Idee eine Sprache zu haben, die einerseits das Risiko von Ressoucenlecks per Design minimiert (as in: es ist im idealfall einfach nicht möglich eine Ressource zu leaken oder nur in seltene Spezialfällen) und andererseits dafür keinen GC o.ä. bemüht (sondern eben scopes). Das scheint mir denn auch eine Marktlücke zu sein, ich kenne keine Sprache die dies erfüllt. Es ist argumentierbar relativ einfach in C++ Speicher zu leaken. Minimalbeispiel:

Code: Alles auswählen

while(true)
{
    new int;
}

Ich muss sagen: Ich fände es in der Tat eine interessante Idee, new keinen rohen Zeiger zurückliefern zu lassen, sondern sowas wie einen unique_ptr...

[CodingCat]

Was war eigentlich nochmal das Problem mit Python?

Wie jede Sprache hat auch Python Stärken und Schwächen. Ich persönlich bin z.B. rein prinzipiell schonmal überhaupt kein Fan von dynamic Typing, wobei es in Skriptsprachen zugegebenermaßen doch sinnvoll sein kann. Abgesehen davon, gefällt mir an Python nicht, dass Whitespace ein wesentlicher Teil der Syntax ist.

Die dynamische Typisierung verhindert insbesondere eine effiziente Umsetzung von Attributzugriffen und Methodenaufrufen. Auch sonst fehlt eine statische Namensauflösung, die verhindert, dass undefinierte (oder falsch geschriebene) Variablen frühzeitig erkannt werden. Ansonsten: Kein ordentliches RAII und damit keine lückenlos automatisierte Fehlerbehandlung (es gibt __del__, jedoch ähnlich problematisch wie Javas Dispose). Reine Objektbasierung ohne const-Korrektheit und damit Anfälligkeit für Fehler durch versehentliche Referenzierung (Abhilfe nur durch unveränderliche Typen; defensives Kopieren ist hoffentlich nur ein Witz von Unidozenten). Garbage Collection und damit standardmäßig geteilte Besitzverhältnisse (immerhin gibt es schwache Referenzen, in irgendeinem Zusatzmodul).

Was ich aus der RAII Diskussion mitgenommen habe ist die Idee eine Sprache zu haben, die einerseits das Risiko von Ressoucenlecks per Design minimiert (as in: es ist im idealfall einfach nicht möglich eine Ressource zu leaken oder nur in seltene Spezialfällen) und andererseits dafür keinen GC o.ä. bemüht (sondern eben scopes). Das scheint mir denn auch eine Marktlücke zu sein, ich kenne keine Sprache die dies erfüllt.

Ja, leider ist es eine Marktlücke. Der große Unterschied von C++ gegenüber den meisten anderen Sprache ist jedoch immer noch, dass in C++ in dieser Hinsicht tatsächlich sichere Programmierung möglich ist. Übrigens habe ich D selbst nie ausprobiert, aber es sieht so aus, als hätte D ebenfalls alle wichtigen sprachlichen Mittel.

Es ist argumentierbar relativ einfach in C++ Speicher zu leaken. Minimalbeispiel:

Code: Alles auswählen

while(true)
{
    new int;
}

Ich muss sagen: Ich fände es in der Tat eine interessante Idee, new keinen rohen Zeiger zurückliefern zu lassen, sondern sowas wie einen unique_ptr...

Ich würde sogar so weit gehen, das aktuelle new und delete gänzlich aus der Sprache zu verbannen. Davon abgesehen ist das Beispiel relativ witzlos, bewusst Ressourcen Leaken geht immer. Unbewusst keine Ressourcen Leaken, das ist die einzigartige Stärke von RAII. ;)