Eigene Programmiersprache - Lexer, Parser, usw

[dot]

Garbage Collection und damit standardmäßig geteilte Besitzverhältnisse (immerhin gibt es schwache Referenzen, in irgendeinem Zusatzmodul).

Python verwendet afaik Reference Counting, GC ist nur über eine Zusatzbibliothek verfügbar. Das war mir bis vor kurzem auch nicht bewusst, aber ich verwend python auch praktisch nie...

Übrigens habe ich D selbst nie ausprobiert, aber es sieht so aus, als hätte D ebenfalls alle wichtigen sprachlichen Mittel.

Ich hab D auch nie selbst ausprobiert. Aber ich habs mir ein bisschen angeschaut und bin nicht wirklich davon überzeugt. Und nach allem was ich davon gesehen hab, hab ich das Gefühl, dass D kaum mehr als ein Experiment ist und wohl auch bleiben wird...

Ich würde sogar so weit gehen, das aktuelle new und delete gänzlich aus der Sprache zu verbannen.

Jap, wär interessant, was für Alternativen man so finden kann...

[BeRsErKeR]

http://xkcd.com/927/

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

Mal nicht so miesepeterisch hier. Es geht hier nicht drum, die tollste Sprache der Welt zu entwickeln. Ich finde Schwächen auch gar nicht so schlimm, sofern diese Schwächen einen nicht betreffen/beeinflussen. Was ich anstrebe ist eine Sprache, die die Probleme, die ich beim Arbeiten mit anderen Sprachen habe, eliminieren. Das diese Sprache schwächenfrei sein wird behauptet keiner. ;)

[CodingCat]

Python verwendet afaik Reference Counting, GC ist nur über eine Zusatzbibliothek verfügbar. Das war mir bis vor kurzem auch nicht bewusst, aber ich verwend python auch praktisch nie...

Ja, habe ich vorhin auch gelesen. Ausschalten des GC ist auf jeden Fall möglich, dann läuft nur noch das Reference Counting, mit all den Schwierigkeiten von geteilten Besitzverhältnissen (-> zyklische Abhängigkeiten).

http://xkcd.com/927/

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

Mal nicht so miesepeterisch hier. Es geht hier nicht drum, die tollste Sprache der Welt zu entwickeln. Ich finde Schwächen auch gar nicht so schlimm, sofern diese Schwächen einen nicht betreffen/beeinflussen. Was ich anstrebe ist eine Sprache, die die Probleme, die ich beim Arbeiten mit anderen Sprachen habe, eliminieren. Das diese Sprache schwächenfrei sein wird behauptet keiner. ;)

Lass dir von den resignierten Miesmachern nicht die Laune verderben. ;) Und ja, Sprachentwicklung (eigentlich allgemein Softwareentwicklung) verhält sich in frustrierendem Maße wie Politik.

[Alexander Kornrumpf]

Mal nicht so miesepeterisch hier.

Lass dir von den resignierten Miesmachern nicht die Laune verderben. ;) Und ja, Sprachentwicklung (eigentlich allgemein Softwareentwicklung) verhält sich in frustrierendem Maße wie Politik.

Resignierten Miesmachern? I beg your pardon. Ich bin nicht derjenige, der den Jammer Thread hier mit 100erten von Seiten gefüllt hat. Ich programmiere selbst (leider) kaum noch und kann nur den Hut ziehen vor der Weise auf die "ihr" C++ gemeistert habt. Das ist ein Kenntnisstand der hier vor 10 Jahren o.ä. einfach nicht im Forum vorhanden war.

Was ich anstrebe ist eine Sprache, die die Probleme, die ich beim Arbeiten mit anderen Sprachen habe, eliminieren.

Meiner Meinung nach das größte Problem der Softwareentwicklung überhaupt. Es gibt keinen general case. Eine Sprache die deinen Arbeitsstil in optimaler Weise unterstützt ist für den Rest der Weltbevölkerung wahrscheinlich maximal 80% geeignet. Und das ist C++, die eierlegende Wollmilchsau halt auch.

Beispiel was mir kürzlich untergekommen ist: Ich hab mir halt Python angeschaut. Ich hätte gerne Datums (also Plural von Date, nicht von Data) in eine Datenbank gespeichert. Mit SQLAlchemy. Aber die Standard-Date Klasse in Python kann keine Daten vor dem Jahr 0 (das wollte ich aber). Insbesondere wollte ich auch Zeiträume angeben können. Und ich hätte gerne Strings in verschiedenen Varianten zu Datums geparst. Bibliothek die all das kann gibt es nicht. Nur verschierdene Lösungen die jeweils etwa 80% davon können. Aber wechselseitig inkompatibel sind. Und keine davon ist kompatibel zu SQLAlchemy was aber natürlich nicht verwundert.

Und so ist mein ganzes Leben als Entwickler. Man kann den Krishty-Weg gehen und sagen "fickt euch, ich mach jetzt alles selbst", aber dazu fehlt mir Zeit, Geduld und letztlich auch Können. Dasselbe gilt für die Alternative, die z.B. Thomas gewählt hat, als er OIS bis zum Nichtmehrwiedererkennen umgeschrieben hat. Für Anforderungen die mir persönlich nun soo exotisch auch nicht erschienen.

Das sind einfach Dinge von denen ich keine Ahnung haben will. Ich glaube dass ich fachlich ein paar ganz gute Ideen habe. Das o.g. Pythonprojekt hätte eine sehr schöne Web-Anwendung werden können, und Python/Pylons (auf Empfehlung des PHP-Rants von vor ein paar Wochen) war schon um Längen schmerzfreier als PHP, Rails oder Gott behüte JSP. Aber dann kommt einem eben so ein Scheiß dazwischen, der die Umsetzung zum Graus macht.

Ich bin kein Stück resigniert. Ich hätte sehr gerne Tools die dieses Problem mal lösen. Aber was ich gar nicht gebrauchen kann ist das 27. Tool dass das gleiche Problem hat wie alle anderen nur anders.

[dot]

http://xkcd.com/927/

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

Mal nicht so miesepeterisch hier. Es geht hier nicht drum, die tollste Sprache der Welt zu entwickeln. Ich finde Schwächen auch gar nicht so schlimm, sofern diese Schwächen einen nicht betreffen/beeinflussen. Was ich anstrebe ist eine Sprache, die die Probleme, die ich beim Arbeiten mit anderen Sprachen habe, eliminieren. Das diese Sprache schwächenfrei sein wird behauptet keiner. ;)

Ich glaub du hast mich falsch verstanden. Ich wollte damit nicht ausdrücken, dass es sinnlos ist, eine neue Sprache zu entwerfen. Was ich damit sagen wollte (und was der Comic imo auch auszudrücken versucht) ist, dass deine neue Sprache am Ende auch wieder nur ein weiterer Trade-off unter vielen ist. Aber ich denk das ist dir eh bewusst... ;)

[ftb]

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...

Ist doch kein Problem, wenn man sowas haben will gibt ja genug Möglichkeiten dazu (sei es Überladung von new oder eine eigene Funktion/Factory, wobei überladen wohl der faulere Weg wäre :p.

[dot]

Durch Überladen von new bekommst du das nicht hin, da du den new operator nicht überladen kannst ;)
(operator new() ist eine sog. allocation function nicht der new operator selbst und muss immer void* returnen)

[CodingCat]

Resignierten Miesmachern? I beg your pardon. Ich bin nicht derjenige, der den Jammer Thread hier mit 100erten von Seiten gefüllt hat.

Der Jammer-Thread ist doch im Großen und Ganzen das glatte Gegenteil von Resignation. Die Dokumentation und Systematisierung von Missständen ist schlussendlich Grundvoraussetzung für jegliche Verbesserung. ;)

Ich bin kein Stück resigniert. Ich hätte sehr gerne Tools die dieses Problem mal lösen. Aber was ich gar nicht gebrauchen kann ist das 27. Tool dass das gleiche Problem hat wie alle anderen nur anders.

Naja, ohne Experimente auch kein Fortschritt. Es zwingt dich niemand, auch das 27. Tool zu nutzen. Es geht hier (hoffentlich) in erster Linie um Erkenntnisgewinn, was dabei entsteht, ist erstmal nebensächlich. Erkenntnisgewinn wiederum erfordert oftmals Replikation von Bestehendem, um überhaupt eine Vorstellung für dessen Funktionsweise und im Optimalfall ein überschaubareres Modell für weitergehende Forschung zu erlangen.

Der verlinkte Comic passt nur bedingt hierher, weil Sprachentwicklung erstmal nichts mit Standards, sondern mit Konzepten zu tun hat. Ein Stück weit, insbesondere ergänzt durch die Erläuterungen zum 27. Tool, ist er aber durchaus Ausdruck von Resignation. Neues kann nunmal oftmals nur schwerlich im Kontext komplexer bestehender (und obendrein strikt abwärtskompatibler!) Strukturen erarbeitet werden. Wer sich in der Vorstellung, alles Machbare sei erreicht, um der Einheitlichkeit Willen an Bestehendes klammert, schränkt sich zwangsläufig stark ein.

[Alexander Kornrumpf]

Wer sich in der Vorstellung, alles Machbare sei erreicht, um der Einheitlichkeit Willen an Bestehendes klammert, schränkt sich zwangsläufig stark ein.

Ja, aber warum unterstellst du mir das? Weder finde ich das alles machbare erreicht ist, noch klammere ich mich an bestehendes. Ein Bruch mit der C Kompatibilität halte ich z.B. für unbedingt erforderlich um irgendwas zu reißen.

Die Frage ist halt woran man eine Sprache evaluieren will. Und da halte ich praktische Anwendbarkeit für sehr weit vorne.

[CodingCat]

Ja, aber warum unterstellst du mir das?

Nicht dir, sondern dem Comic im Kontext dieses Threads. ;) Warum, habe ich gerade eben erläutert.

[ftb]

Durch Überladen von new bekommst du das nicht hin, da du den new operator nicht überladen kannst ;)
(operator new() ist eine sog. allocation function nicht der new operator selbst und muss immer void* returnen)

Hmm okey, wusste ich nicht ;p. Wieder was gelernt! Über Funktionen kann man das ganze wohl auch nur lösen solange man einen Default Konstruktor hat andernfalls muss man die ganze Parameterliste wrappen :(. Und ich dachte schon das wäre easy möglich :/

[CodingCat]

Über Funktionen kann man das ganze wohl auch nur lösen solange man einen Default Konstruktor hat andernfalls muss man die ganze Parameterliste wrappen :(. Und ich dachte schon das wäre easy möglich :/

Nein, seit C++11 ist das absolut kein Problem mehr. Die C++-Standardbibliothek könnte und sollte seit C++11 eine Funktion make_unique anbieten, die wohl mal wieder in krampfhaftem Minimalismus vergessen wurde; und laut Herb Sutter mit dem nächsten Standard (in 5-10 Jahren? :evil:) nachgeliefert wird. Bis dahin ...

Code: Alles auswählen

template <typename T, typename ...Args>
std::unique_ptr<T> make_unique(Args&& ...args)
{
    return std::unique_ptr<T>( new T( std::forward<Args>(args)... ) );
}

... sobald MSVC++ Variadic Templates unterstützt. (In 2-5 Jahren? :evil:) Tatsächlich könnte und sollte make_unique bereits in C++11 fast alle Aufrufe von new ersetzen.

Randnotiz: Ich bin mal wieder begeistert, wie konsequent das Konzept umgesetzt wurde: std::forward<Args>(args)... funktioniert nicht nur mit hochspezialisiertem std::forward, sondern mit jedem Ausdruck.
foo(args)... wird zu foo(arg1), foo(arg2), ....
(args * 2)... zu arg1 * 2, arg2 * 2, ....
(args + blargs)... zu arg1 + blarg1, arg2 + blarg2, ... (Lockstep Expansion).

[EyDu]

Die dynamische Typisierung verhindert insbesondere eine effiziente Umsetzung von Attributzugriffen und Methodenaufrufen.

Im allgemeinen Fall ist dem natürlich so, allerdings hängt die Umsetzung stark vom Interpreter ab. IIRC werden in PyPy solche Zugriffe optimiert, so das kein Overhead mehr anfällt.

Auch sonst fehlt eine statische Namensauflösung, die verhindert, dass undefinierte (oder falsch geschriebene) Variablen frühzeitig erkannt werden.

Ehrlich gesagt ist das für mich noch nie ein Problem gewesen und ich arbeite bereits seit sieben Jahren mit Python. Falsche Typen oder nicht vorhandene Namen werden immer durch Unittests abgefangen.

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)

Dieses Verhalten ist beim Sprachdesign schon so gewünscht gewesen. Es gibt genau eine Art wie Parameter übergeben werden oder wie man auf Objekte zugreift: Referenzen; ohne const und mit allen Vor- und Nachteilen.

Die Unveränderlichen Typen sind auch keine Abhilfe gegen dieses Problem, sondern addressieren einen ganz anderen Bereich. Da in Python alle Namensauflösungen über Dictionaries laufen, sind die Zugriffe auf diesem Weg optimiert. Ansonsten kann man sich für Schlüsselvergleiche beliebig lange Laufzeiten einhandeln.

Kopien sind in Python tatsächlich relativ üblich, da sie einfach unglaublich billig sind. Eine Liste von Referenzen ist einfach schnell verdoppelt. Aber natürlich fängt niemand an in allen Funktionen nun wild alles zu kopieren um irgendwie Konstanten zu erhalten. Mit wenigen ausnahmen (wie zum Beispiel im fall von List Comprehensions) wird nur dann kopiert, wenn man in anderen Sprachen auch kopieren würde. In Python erfolgt dies lediglich explizit, wie viele andere Dinge auch (was übrigens auch ein gewünschtes Verhalten ist).

Python verwendet afaik Reference Counting, GC ist nur über eine Zusatzbibliothek verfügbar. Das war mir bis vor kurzem auch nicht bewusst, aber ich verwend python auch praktisch nie...

Richtig, Python verwendet Reference Counting. Falsch ist allerdings, dass man den GC über eine Zusatzbibliothek extra starten müsste. Über dieses Modul hat man lediglich weitere Kontrollmöglichkeiten über den GC. Ansonsten läuft der GC ganz normal im Hintergrund mit.

Entschuldigt diesen kleinen Ausflug, aber die Dinge wollte ich gerne richtigstellen.

[CodingCat]

Die dynamische Typisierung verhindert insbesondere eine effiziente Umsetzung von Attributzugriffen und Methodenaufrufen.

Im allgemeinen Fall ist dem natürlich so, allerdings hängt die Umsetzung stark vom Interpreter ab. IIRC werden in PyPy solche Zugriffe optimiert, so das kein Overhead mehr anfällt.

Kein Overhead ist realtiv. :P

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)

Dieses Verhalten ist beim Sprachdesign schon so gewünscht gewesen. Es gibt genau eine Art wie Parameter übergeben werden oder wie man auf Objekte zugreift: Referenzen; ohne const und mit allen Vor- und Nachteilen.

Aber wozu, wenn sich diese Nachteile so einfach beheben lassen? Nun gut, im Kontext von Python ohne jegliche statische Prüfung ist das ohnehin keine Diskussion wert. ;)

Die Unveränderlichen Typen sind auch keine Abhilfe gegen dieses Problem, sondern addressieren einen ganz anderen Bereich. Da in Python alle Namensauflösungen über Dictionaries laufen, sind die Zugriffe auf diesem Weg optimiert. Ansonsten kann man sich für Schlüsselvergleiche beliebig lange Laufzeiten einhandeln.

Doch, unabhängig von irgendwelchen sprachspezifischen Optimierungen lösen unveränderliche Typen genau dieses Problem, zu dem Preis, dass sie eben grundsätzlich immer unveränderlich sind.

Kopien sind in Python tatsächlich relativ üblich, da sie einfach unglaublich billig sind. Eine Liste von Referenzen ist einfach schnell verdoppelt. Aber natürlich fängt niemand an in allen Funktionen nun wild alles zu kopieren um irgendwie Konstanten zu erhalten. Mit wenigen ausnahmen (wie zum Beispiel im fall von List Comprehensions) wird nur dann kopiert, wenn man in anderen Sprachen auch kopieren würde. In Python erfolgt dies lediglich explizit, wie viele andere Dinge auch (was übrigens auch ein gewünschtes Verhalten ist).

Explizit ist grundsätzlich gut, aber nur dann, wenn vermeintlich implizit nicht automatisch falsch ist.