Was stört/fehlt euch bei aktuellen Programmiersprachen?

knivil

C++11 hat immernoch kein Makrosystem wie in Scheme.

Mal auf C++ bezogen (ohne Library):
- Pointer Aliasing verhindert Optimierungen (strict aliasing ist nicht ganz zufriedenstellend)
- AST Macros, jetztige Macros entfernen (für Modul-System)
- Module
- inout (wie in D)
- Mit Syntax aufräumen (Templates, Lambdas)
- Variablen schon vor Scopeende deleten können (automatisch bei move)
- Mehr standardisierte Hardwareintrinsics (prefetch, overflow)

cooky451

Jo, ist eig interessant dass man die Template-Syntax mit Modulen, constexpr und Concepts komplett umkrempeln und implizit machen könnte. Und Hardwareintrinsics fehlen mir auch dauernd.

Youka

Soweit kommt's, dass wir dir die Design-Arbeit abnehmen :p

Ich seh es so wie SeppJ. Es kann keine (nichtmal nahezu) perfekte Sprache geben, denn was du für eine Aufgabe vereinfachst, erschwert den Nutzen für eine andere. Möchtest du etwas simpler gestalten, lässt du etwa die Funktionen niedrigeren Levels aus, auf denen deine aufbaut, oder du lässt sie und überlädst damit die Sprache (Fall entsteht: "viele Lösungen für ein Problem").

knivil

Es kann keine (nichtmal nahezu) perfekte Sprache geben

Das hat schon Lisp erkannt. Deswegen hat es das Werkzeug fuer Sprachen gleich mitgeliefert, um eigenen problembezogen Sprachen fuer die Domain basteln zu koennen. Und da nichts perfekt ist: Das machte Codewartung schwierig, da vielleicht jeder Programmierer seine eigene DSL fuer das Problem entwirft.

knivil schrieb:

Das machte Codewartung schwierig, da vielleicht jeder Programmierer seine eigene DSL fuer das Problem entwirft.

Deshalb ist Java so beliebt, weil jeder Doof (die Mehrheit der Programmierer) anderen Code versteht und sich in Bibliotheken schnell einarbeitet.

DSLs sind zwar schön, aber schädlich.

Die Aufgabe einer Sprache ist es, DSLs zu verbieten und ein möglichst einheitliches Sprachkonzept, was möglichst einfach ist für möglichst viele Domains möglichst ohne viel Syntaxoverhead über eine DSL einsetzbar zu machen. Und besonders wichtig: Die Sprache soll möglichst einfach zu lernen sein.

Deshalb ist Java top und Scala flop, obwohl Scala vom Ausdruck her mächtiger ist.

Xin

Kellerautomat@work schrieb:

Rein aus Interesse (Und weil ich immer noch an meiner Sprache bastle :p ):

Was ist denn das Ziel Deiner Sprache?

Kellerautomat@work schrieb:

[*]Was stört euch bei gängigen Sprachen?

Prosa.
Die Compiler nutzen die Möglichkeiten der semantischen Analyse nicht voll aus, wobei C++ hier noch sehr positiv hervorsticht, aber eben vieles auch unbeachtet lässt.
Baue ich ein Objekt auf, befinde ich mich in einem anderen Zustand als wenn ich das Objekt nutze. Ich würde das zum Beispiel gerne unterscheiden.

Kellerautomat@work schrieb:

[*]Welche Sprachfeatures vermisst ihr?

Eine sinnvolle Fehlerbehandlung und -vermeidung.
Exceptions halte ich für so ungefähr das letzte - außer im Ausnahmefall. In gängigen Sprachen werden Exceptions aber im Regelfall benutzt: Taugt also nix.

Kellerautomat@work schrieb:

[*]Auf welche Probleme seid ihr gestoßen, die in aktuellen Sprachen unzureichend/nicht gelöst werden?

Früher hatte ich dafür mal einen Aktenordner. ^^

Was ist Dein Ziel?

Ethon

Ich will ein C++# - die ganzen coolen C# Features in C++ einbauen (+ der dicken Bibliothek), aber ohne dass Microsoft da die Finger drin hat.

Xin schrieb:

Was ist denn das Ziel Deiner Sprache?

Eine Sprache, die:

Ausdrucksstark und prägnant ist, ohne dabei unleserlich zu werden (z.B. Pattern Matching, damit verbunden auch Tuple in der Sprache eingebaut, oder auch std::optional aka Nullable in die Sprache)
Den Programmierer nicht einschränkt (MI, nutzerdefinierte Operatoren, ...)
Codegenerierung unterstützt (Meta-Programme, die Code erzeugen - mit schöner Sytax. Ich will mir meinen Serialisierungscode mittels Compiletime-Reflection automatisch generieren lassen können.)
Schwer falsch zu verwenden ist
Gut optimierbar ist (Sprachkonstrukte für Parallelisierung und Vektorisierung)
Keinen GC hat, dafür RAII/Refcounting unterstützt (GCs sind ja mal sowas von Vorgestern)

Liste nicht nach Priorität oder Wichtigkeit sortiert.

Xin schrieb:

Prosa.
Die Compiler nutzen die Möglichkeiten der semantischen Analyse nicht voll aus, wobei C++ hier noch sehr positiv hervorsticht, aber eben vieles auch unbeachtet lässt.
Baue ich ein Objekt auf, befinde ich mich in einem anderen Zustand als wenn ich das Objekt nutze. Ich würde das zum Beispiel gerne unterscheiden.

Was du damit meinst, ist mir nicht klar. Könntest du mir das genauer erklären?

Xin schrieb:

Eine sinnvolle Fehlerbehandlung und -vermeidung.
Exceptions halte ich für so ungefähr das letzte - außer im Ausnahmefall. In gängigen Sprachen werden Exceptions aber im Regelfall benutzt: Taugt also nix.

Warum sind Exceptions schlecht, nur weil sie oft falsch verwendet werden?

Xin schrieb:

Früher hatte ich dafür mal einen Aktenordner. ^^

Dann kram mir den mal hervor, würde mich interessieren.

SeppJ

Was mir bei der Beschreibung deiner Sprache noch fehlen würde, wäre eine umfangreiche Standardbibliothek. Das stört mich schon bei C++ ein wenig, dass man doch wirklich nur das absolute Minimum zur Verfügung hat. Gerade da Portabilität nicht auf deiner Liste steht (was mir auch fehlen würde, aber das ist dann eben ein Grund für mich, die Sprache nicht zu nutzen, für andere Leute hingegen ein Argument dafür, da unportable Sprachen andere Vorteile haben können), kannst du da richtig reinhauen.
Ja, eine Standardbibliothek ist Teil einer Sprache, auch wenn es der Teil ist, der dem Sprachdesigner am wenigsten Spaß macht. Aber es ist der Teil, mit dem der Programmierer oftmals den meisten Kontakt hat.

Erstmal muss ich die Sprache hinbekommen, dann kann man über eine stdlib reden.
Aber du hast schon Recht, eine große stdlib ist auf jeden Fall ein Muss.

Betriebssystemunabhängig auf jeden Fall, aber ich werde mir keine Mühe machen, damit meine Implementierung mit MSVC kompiliert. :p

Zeus

Kellerautomat@work schrieb:

Betriebssystemunabhängig auf jeden Fall, aber ich werde mir keine Mühe machen, damit meine Implementierung mit MSVC kompiliert. :p

Welche Implementierungsstategien hast du schon festgelegt?
IMO hast du dort mehr potenzielle Entwickler, besonders im native Bereich.

Zeus schrieb:

Kellerautomat@work schrieb:

Betriebssystemunabhängig auf jeden Fall, aber ich werde mir keine Mühe machen, damit meine Implementierung mit MSVC kompiliert. :p

Welche Implementierungsstategien hast du schon festgelegt?
IMO hast du dort mehr potenzielle Entwickler, besonders im native Bereich.

Oh, mein letzter Test ist wohl irgendwie verschwunden. Post bitte einfach löschen.

Ich habe noch nichts implementiert, was man sinnvoll verwenden könnte. Bin auch mit dem aktuellen Design noch nicht zufrieden.

Xin

Kellerautomat@work schrieb:

Xin schrieb:

Was ist denn das Ziel Deiner Sprache?

Eine Sprache, die:

Ausdrucksstark und prägnant ist, ohne dabei unleserlich zu werden (z.B. Pattern Matching, damit verbunden auch Tuple in der Sprache eingebaut, oder auch std::optional aka Nullable in die Sprache)

Den Programmierer nicht einschränkt (MI, nutzerdefinierte Operatoren, ...)

Codegenerierung unterstützt (Meta-Programme, die Code erzeugen - mit schöner Sytax. Ich will mir meinen Serialisierungscode mittels Compiletime-Reflection automatisch generieren lassen können.)

Schwer falsch zu verwenden ist

Gut optimierbar ist (Sprachkonstrukte für Parallelisierung und Vektorisierung)

Keinen GC hat, dafür RAII/Refcounting unterstützt (GCs sind ja mal sowas von Vorgestern)

Liste nicht nach Priorität oder Wichtigkeit sortiert.

Mir scheint, wir haben sehr ähnliche Ziele.

Kellerautomat@work schrieb:

Xin schrieb:

Prosa.
Die Compiler nutzen die Möglichkeiten der semantischen Analyse nicht voll aus, wobei C++ hier noch sehr positiv hervorsticht, aber eben vieles auch unbeachtet lässt.
Baue ich ein Objekt auf, befinde ich mich in einem anderen Zustand als wenn ich das Objekt nutze. Ich würde das zum Beispiel gerne unterscheiden.

Was du damit meinst, ist mir nicht klar. Könntest du mir das genauer erklären?

Beispiel: Ich schreibe einen Compiler... während des Parsens baue ich ein Objekt auf. Während der Codegenerierung nehme ich das gleiche Objekt, um es auszulesen.
Während des Parsens stehen mir Funktionen zur Verfügung, die ich in dem Moment nicht rufen können möchte, während der Codegenerierung stehen mir Funktionen zum Parsen zur Verfügung.

Da könnte man auch ein paar Wrapper drumrum bauen. Aber warum soll ICH das tun?

Kellerautomat@work schrieb:

Xin schrieb:

Eine sinnvolle Fehlerbehandlung und -vermeidung.
Exceptions halte ich für so ungefähr das letzte - außer im Ausnahmefall. In gängigen Sprachen werden Exceptions aber im Regelfall benutzt: Taugt also nix.

Warum sind Exceptions schlecht, nur weil sie oft falsch verwendet werden?

Keiner sagt, dass Exceptions im Ausnahmefall schlecht sind.

Aber das Konzept lädt zum Exception-Ping-Pong ein. Das Konzept ist also dazu gedacht, Fehler zu fangen, bei einem Fehler in der Fehlerbehandlung verliere ich aber die Information, wer den Fehler ausgelöst hat, weil nun eine vollkommen andere Exception durch mein Programm fliegt, die ich auch nicht erklären kann, weil sie im eigentlichen Programmteil ja gar nicht geworfen werden sollte. Wo kommt die her und was muss ich falsch machen, damit ein Fehler erzeugt wird, bei dem dann die Fehlerkorrektur fehlschlägt?

Debug das. Das ist teuer... ^^
(Ich war mal Java Entwickler, aber selbst gutes zureden half nicht, Exceptions sinnvoll einzusetzen, mit dem Ergebnis, dass ich sowas in einer noch verzwickteren Situation debuggen musste, weil sich Exception, die eigentlich nicht existieren konnte, natürlich in meinem catch hängenblieb...).

Kellerautomat@work schrieb:

Xin schrieb:

Früher hatte ich dafür mal einen Aktenordner. ^^

Dann kram mir den mal hervor, würde mich interessieren.

Das kann ich sehr gut nachvollziehen. ^^
Ich bin selbst immer auf der Suche nach interessanten Ideen, von daher weiß ich auch, wie aufwändig und teuer es ist, an gute Ideen zu kommen. Ich verbringe damit jetzt 14 Jahre, sie zu sammeln, zu ordnen und in Syntax zu gießen, die Syntax zu verwerfen und neu anzufangen. Ursprünglich war ich mal C++ kompatibel - lange her ;-).
Anfangs suchte ich offen nach Mitstreitern und das habe ich inzwischen aufgegeben, habe da auch erfolglos Zeit und Geld investiert, also mache die Geschichte jetzt alleine: Das hat sich als schneller und billiger erwiesen.

Inzwischen bin ich auf dem Stand, dass ich in etwa weiß, was ich wie umsetzen möchte und habe ein paar Dinge auch bereits lauffähig implementiert, was rund 150kLOC darstellt.
Ich hoffe, Du bist mir nicht böse, wenn ich das nicht einfach so verschenken mag.

Es spricht aber nichts dagegen, sich auszutauschen. Ich bin ja durchaus auch neugierig. ^^

Kellerautomat@work schrieb:

Pattern Matching

Wo ist der Vorzug zu SFINAE?

Tuple in der Sprache eingebaut

Wäre für die Definition von Variablen ganz praktisch.

std::optional aka Nullable

Nö. Nullable ist entweder intrusive oder Bibliothekssache (Punkt-Operator).

nutzerdefinierte Operatoren

Sehe den Sinn nicht ganz. Lieber Infix-Funktionsaufrufe.

Codegenerierung unterstützt (Meta-Programme, die Code erzeugen - mit schöner Sytax. Ich will mir meinen Serialisierungscode mittels Compiletime-Reflection automatisch generieren lassen können.)

Konkret? String Mixins?

Gut optimierbar ist (Sprachkonstrukte für Parallelisierung und Vektorisierung)

Das ist zu spezifisch. Vektorisierung ist bald out, dann kommt was neues. Parallelisierung wandelt auch stark im Ansatz. syncronized in Java und D ist schon fast verpönt.

Die Lösung sind hardwareintrinsics und eine Bibliothek, die ein hohes Abstraktionsniveau zeigt. Es ist die Aufgabe von std::accumulate zu Vektorisieren und zu parallelisieren.

[*]Keinen GC hat, dafür RAII/Refcounting unterstützt (GCs sind ja mal sowas von Vorgestern)

Speicherverwaltung ist mMn Sache der Bibliothek und nicht der Sprache.
Ein GC ist manchmal schneller als Refcounting, anderswo ist Refcounting besser.

Ich fände eine in die Bibliothek fest eingebaute Allocator-Policy perfekt.

Ergänzung was mir in C++ fehlt:
- Compile-Time-Reflection
- Punkt-Operator überladen (geht mit Compile-Time-Reflection)
- Meta-Informationen zu Funktionen angeben können (Kommutativität, etc.)

otze

meine optimale Sprache wäre eine Code-Generator-Sprache.

Ganz unten liegen Code-Macros, und da drüber liegt eine DSL die in diese Makros übersetzt. Und natürlich sollte das in mehreren Schichten funktionieren, sodass die untere Makroschicht nur in dem Sinne etwas besonderes ist, das es keine darunter liegende Schicht gibt.

Vielleicht sollte ich mir wirklich einmal lisp anschauen.

Aus dem anderen Thread:

volkard schrieb:

Und die Möglichkeit, Sprachmittel zu definieren, echte Sprachmittel, die den Parser bestimmen, was vielleicht zu einem rekursiven Abstiegscompiler führt, der nicht hardcoded ist, sondern sich an unserem Syntax-Semantik-Baum entlanghangelt, oder einem Compiler, der immer, wenn was neues kommt, das lernt und von vorne beginnt. Keine Bange, das Von-Vorne-Beginnen betrifft nur die ersten Versionen und die Sprachdefinition, die unter Umständen dadurch duetlich vereinfacht wird, später werden schlaue Leute auch den Compiler optimieren und nur von vorne beginnen, wenn es wirklich nötig ist, praktisch nie.

Zum Beispiel:
syntax::define
  while(cond)
    cmd
syntax::as
  nochmal:
  if(cond)
    cmd
    goto nochmal

Ich mag die Idee und denke ein wenig darüber nach, wie man sowas realisieren könnte.
Wie könnte man hier geschickt mit Whitespaces umgehen? Also "while (cond)" soll sicherlich erlaubt sein, "wh ile(cond)" dagegen nicht.

Kellerautomat

Xin schrieb:

Beispiel: Ich schreibe einen Compiler... während des Parsens baue ich ein Objekt auf. Während der Codegenerierung nehme ich das gleiche Objekt, um es auszulesen.
Während des Parsens stehen mir Funktionen zur Verfügung, die ich in dem Moment nicht rufen können möchte, während der Codegenerierung stehen mir Funktionen zum Parsen zur Verfügung.

Da könnte man auch ein paar Wrapper drumrum bauen. Aber warum soll ICH das tun?

Du willst einer Klasse kontextabhaengige Interfaces verpassen koennen?

Xin schrieb:

Keiner sagt, dass Exceptions im Ausnahmefall schlecht sind.

Aber das Konzept lädt zum Exception-Ping-Pong ein. Das Konzept ist also dazu gedacht, Fehler zu fangen, bei einem Fehler in der Fehlerbehandlung verliere ich aber die Information, wer den Fehler ausgelöst hat, weil nun eine vollkommen andere Exception durch mein Programm fliegt, die ich auch nicht erklären kann, weil sie im eigentlichen Programmteil ja gar nicht geworfen werden sollte. Wo kommt die her und was muss ich falsch machen, damit ein Fehler erzeugt wird, bei dem dann die Fehlerkorrektur fehlschlägt?

Debug das. Das ist teuer... ^^
(Ich war mal Java Entwickler, aber selbst gutes zureden half nicht, Exceptions sinnvoll einzusetzen, mit dem Ergebnis, dass ich sowas in einer noch verzwickteren Situation debuggen musste, weil sich Exception, die eigentlich nicht existieren konnte, natürlich in meinem catch hängenblieb...).

Wo ziehst du denn eine Linie? Ist "file not found" eine Ausnahme? Wie stehts mit EOF?
Meiner Meinung nach haengt das immer vom Use Case ab.

Xin schrieb:

Das kann ich sehr gut nachvollziehen. ^^
Ich bin selbst immer auf der Suche nach interessanten Ideen, von daher weiß ich auch, wie aufwändig und teuer es ist, an gute Ideen zu kommen. Ich verbringe damit jetzt 14 Jahre, sie zu sammeln, zu ordnen und in Syntax zu gießen, die Syntax zu verwerfen und neu anzufangen. Ursprünglich war ich mal C++ kompatibel - lange her ;-).
Anfangs suchte ich offen nach Mitstreitern und das habe ich inzwischen aufgegeben, habe da auch erfolglos Zeit und Geld investiert, also mache die Geschichte jetzt alleine: Das hat sich als schneller und billiger erwiesen.

Inzwischen bin ich auf dem Stand, dass ich in etwa weiß, was ich wie umsetzen möchte und habe ein paar Dinge auch bereits lauffähig implementiert, was rund 150kLOC darstellt.
Ich hoffe, Du bist mir nicht böse, wenn ich das nicht einfach so verschenken mag.

Es spricht aber nichts dagegen, sich auszutauschen. Ich bin ja durchaus auch neugierig. ^^

Klar, austauschen kann man sich gerne. Ich werde die Sprache eh bestimmt noch 10-mal umkrempeln

cxxbash schrieb:

Wo ist der Vorzug zu SFINAE?

Was hat denn Pattern Matching mit SFINAE zu tun?

cxxbash schrieb:

Nö. Nullable ist entweder intrusive oder Bibliothekssache (Punkt-Operator).

Wenn ich Nullable in die Sprache baue, kann ich dem auch einen passenden Deklarator verpassen, selbst wenns nur ein Alias fuer eine Standard-Klasse mit Sonderbehandlung ist.
Zumal Pattern Matching auf Nullables moeglich sein soll und diese auch ihre eigenen Operatoren haben, die nicht ueberladbar sind.

cxxbash schrieb:

Sehe den Sinn nicht ganz. Lieber Infix-Funktionsaufrufe.

DSELs. Wenn man sich seine eigenen Operatoren bauen kann, koennte man z.B. Regex beinahe 1:1 in Code hinschreiben.

cxxbash schrieb:

Konkret? String Mixins?

Ich weiss noch nicht so genau. Syntax mal aus der Luft gegriffen:

generator times(uint n)
{
    echo "for(uint i = 0; i != " ~ n ~ "; ++i)"
}

void f()
{
    $times(10)
        println("Hello, World!")
}

Man koennte in einem Generator auch andere Generatoren generieren. Erst wenn der Code keine Generator-Aufrufe mehr enthaelt, ist das Generieren fertig.

cxxbash schrieb:

Das ist zu spezifisch. Vektorisierung ist bald out, dann kommt was neues. Parallelisierung wandelt auch stark im Ansatz. syncronized in Java und D ist schon fast verpönt.

Ich meine damit eher, dass ich versuche Sprachkonstrukte zu erfinden, die dem Compiler helfen, besseren Code zu generieren. Ein Beispiel:

let a := [1, 2, 3, 4], b := [5, 6, 7, 8]; // 2 Arrays
println(a[] + b[]) // aha!

Das [] hinter dem Array macht aus dem Array eine "component-wise expression", die Operationen auf alle Elemente anwendet. Das funktioniert auch mit Slicing:

a[0:2] -= b[1:3];

cxxbash schrieb:

Speicherverwaltung ist mMn Sache der Bibliothek und nicht der Sprache.
Ein GC ist manchmal schneller als Refcounting, anderswo ist Refcounting besser.

Ich fände eine in die Bibliothek fest eingebaute Allocator-Policy perfekt.

Das sehe ich anders. Die Wahl der Speicherverwaltung beeinflusst das Design der Sprache. Ich habe einen GC von vornherein ausgeschlossen, da GCs keinen deterministisches Aufraeumen erlauben.
Wenn man jetzt einfach alles refcounted macht, dann mag ein GC schneller sein.

Uebrigens hat Apple ebenfalls den GC aus Objective-C rausgeschmissen und verwendet jetzt Refcounting.

cxxbash schrieb:

- Compile-Time-Reflection

Ist, wie schon gesagt, in meiner Sprache geplant.

cxxbash schrieb:

- Punkt-Operator überladen (geht mit Compile-Time-Reflection)

Wozu denn das?

cxxbash schrieb:

- Meta-Informationen zu Funktionen angeben können (Kommutativität, etc.)

Wuesste auch hier nich, wozu das gut sein sollte. Die wenigsten Funktionen sind kommutativ, und selbst wenn, was mache ich mit dieser Information?

Xin

Kellerautomat schrieb:

Du willst einer Klasse kontextabhaengige Interfaces verpassen koennen?

Yepp.

Kellerautomat schrieb:

Xin schrieb:

Keiner sagt, dass Exceptions im Ausnahmefall schlecht sind.

Aber das Konzept lädt zum Exception-Ping-Pong ein. Das Konzept ist also dazu gedacht, Fehler zu fangen, bei einem Fehler in der Fehlerbehandlung verliere ich aber die Information, wer den Fehler ausgelöst hat, weil nun eine vollkommen andere Exception durch mein Programm fliegt, die ich auch nicht erklären kann, weil sie im eigentlichen Programmteil ja gar nicht geworfen werden sollte. Wo kommt die her und was muss ich falsch machen, damit ein Fehler erzeugt wird, bei dem dann die Fehlerkorrektur fehlschlägt?

Debug das. Das ist teuer... ^^
(Ich war mal Java Entwickler, aber selbst gutes zureden half nicht, Exceptions sinnvoll einzusetzen, mit dem Ergebnis, dass ich sowas in einer noch verzwickteren Situation debuggen musste, weil sich Exception, die eigentlich nicht existieren konnte, natürlich in meinem catch hängenblieb...).

Wo ziehst du denn eine Linie? Ist "file not found" eine Ausnahme? Wie stehts mit EOF?

Eine Ausnahme passiert dann, wenn der Regelfall so stark verletzt würde, dass das Programm in sehr große Schwierigkeiten kommt.

Wenn Du eine Datei öffnest und die Datei gibt es nicht? Ist das ein Grund, das Programm explodieren zu lassen? Ich denke nicht. Ist das Ende einer Datei so ungewöhnlich, dass man eine Ausnahme werfen sollte? In meinen Augen ist es eher der Regelfall, dass eine Datei irgendwann endet.

Der Unterschied zu C++ und Java ist, dass bei C++ Windows meldet "Das Programm funktioniert nicht mehr und beendet wurde". In Java meldet Java, dass eine unbehandelte Exception aufgetreten ist und das Programm jetzt beendet wird."

Bei Java darf ich mein Programm also noch selbst beenden und den Moment selbst entscheiden, wann meine Daten komplett geschreddert werden. Also haben uns Exceptions nicht wirklich weiter gebracht in meinen Augen - eher im Gegenteil.

Kellerautomat schrieb:

Meiner Meinung nach haengt das immer vom Use Case ab.

Meiner Meinung auch. Aber der Use-Case ist so selten - eben eine Ausnahme - dass ich eigentlich vollkommen ohne Exceptions arbeite.

Für Rückgabecodes braucht man aber Disziplin.

Geh davon aus, dass Entwickler nicht diszipliniert arbeiten. Du findest in Java-Code von professionellen Entwicklern häufig catch( Exception x ) {}.

Wenn Du eine gute Sprache schreiben willst, setz Dich mit dem auseinander, was die Entwickler Dir nicht erzählen. Beobachte Dich selbst und wenn Du Mist gebaut hast, schreib Dir das auf. Im Umkehrschluss wirst Du diese Fehler in Zukunft vermeiden, was Dich wiederum zu einem besseren Entwickler macht.

Kellerautomat schrieb:

Man koennte in einem Generator auch andere Generatoren generieren. Erst wenn der Code keine Generator-Aufrufe mehr enthaelt, ist das Generieren fertig.

Ein Ringcompiler, im Gegensatz zu den üblichen Phasencompilern 4 bis 10-Phasen-Compilern.

Das Konzept habe ich vor 10 Jahren mal beschrieben, aber der Prof hat es nicht verstanden und meinte nur, ich sollte den Unterschied zwischen Interpreter und Compiler beschreiben.

Das entsprechende Kommando heißt bei mir "emit", allerdings emitiere ich derzeit nur auf den Bildschirm.

cxxbash schrieb:

Speicherverwaltung ist mMn Sache der Bibliothek und nicht der Sprache.
Ein GC ist manchmal schneller als Refcounting, anderswo ist Refcounting besser.

Ich fände eine in die Bibliothek fest eingebaute Allocator-Policy perfekt.

Das sehe ich anders. Die Wahl der Speicherverwaltung beeinflusst das Design der Sprache. Ich habe einen GC von vornherein ausgeschlossen, da GCs keinen deterministisches Aufraeumen erlauben.[/quote]

Ref-Counting kostet Zeit. Was Zeit kostet, sollte vermieden werden oder wenigstens von Entwickler bestellt werden. Notfalls abgelehnt werden können.

Kellerautomat schrieb:

Wenn man jetzt einfach alles refcounted macht, dann mag ein GC schneller sein.

Ein GC ist nur dann schneller, solange er Speicher hat.
Mit der Strategie kann man auch einfach delete verbieten, new überladen und hoffen, dass der RAM reicht.

Kellerautomat schrieb:

cxxbash schrieb:

- Punkt-Operator überladen (geht mit Compile-Time-Reflection)

Wozu denn das?

Warum kann man eigentlich nicht von (int ableiten? ^^

Kellerautomat schrieb:

cxxbash schrieb:

- Meta-Informationen zu Funktionen angeben können (Kommutativität, etc.)

Wuesste auch hier nich, wozu das gut sein sollte. Die wenigsten Funktionen sind kommutativ, und selbst wenn, was mache ich mit dieser Information?

Zum Debuggen sind sie schön.