Was stört/fehlt euch bei aktuellen Programmiersprachen?

[Kellerautomat@work]

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

[cxxbash]

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.

[Gast]

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.

[Kellerautomat]

Xin schrieb:

Kellerautomat schrieb:

Du willst einer Klasse kontextabhaengige Interfaces verpassen koennen?

Yepp.

Lustig, ich hatte die selbe Idee schon lange Zeit in meinem Kopf herumschwirren, aber ich konnte sie nie in Worte fassen.

Xin schrieb:

Kellerautomat schrieb:

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.

Naja, wenn es die Konfigurationsdatei oder Datenbankdatei ist, dann ist das schon ein Grund imo. Gerade in solchen Faellen finde ich Exceptions auch extrem praktisch.

Xin schrieb:

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.

Hehe
Ich programmiere noch nicht mal 10 Jahre. Damals hatte ich auch noch keinen Computer :p

Xin schrieb:

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

Ich hatte bis 1 Minute vor dem Absenden auch emit da stehen, aber ich war mir nicht sicher, ob das Wort die richtige Bedeutung hat.

Xin schrieb:

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

Das sowieso. Wenn der Programmier meint, er braucht Pointer, dann soll er sie haben. Per default gibts trotzdem Refcounting.

Xin schrieb:

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

Weil die Klasse int final ist :p

Uebrigens trenne ich strikt zwischen Speicherallokation und Speicherverwaltung. Man kann das Refcounting mit einem eigenen Allokator verwenden, das ist unabhaengig voneinander.

[gary1195]

Vier Sachen die ich gerne hätte:
1. wenn es in größe beschränkt integer Typen gibt, dann zusätzlich diese Typen mit overflow-check
2. Referenzen dürfen nicht null sein, außer es wird explizit erlaubt (wie zB bei Vala)
3. automatisch generierbare getter und setter optional mit constraints, die auch wie der Zugriff auf ein public attribut aussehen können (statt .getA() nur .a, statt .setA(5) nur .a = 5)
4. wenn es generische blabla mit <type> gibt, dann irgendwas damit man nicht alles doppelt schreiben muss (ich gehe mal von java,c#,... ähnlicher Syntax aus)

HashMap<string,string> hm = new HashMap<string,string>() //unschön
var hm = new HashMap<string,string>() //vll so
HashMap<string,string> hm = New() //oder so
hm: HashMap<string,string> = New() //oder so
hm = HashMap()   //oder so mit mehr typinferenz
hm.add("a","B")

[Kellerautomat]

gary1195 schrieb:

Vier Sachen die ich gerne hätte:
1. wenn es in größe beschränkt integer Typen gibt, dann zusätzlich diese Typen mit overflow-check

Das ist ein reines Library-Feature, kann man sich dann selbst bauen. Ich glaube nicht, dass ich sowas in die stdlib stecke, ist mir dazu noch nicht wichtig genug.

gary1195 schrieb:

2. Referenzen dürfen nicht null sein, außer es wird explizit erlaubt (wie zB bei Vala)

Das ist bereits der Fall:

void f(Foo? foo) // Nullable
{
    ...
}

gary1195 schrieb:

3. automatisch generierbare getter und setter optional mit constraints, die auch wie der Zugriff auf ein public attribut aussehen können (statt .getA() nur .a, statt .setA(5) nur .a = 5)

Sowas wie Properties in C#?

gary1195 schrieb:

4. wenn es generische blabla mit <type> gibt, dann irgendwas damit man nicht alles doppelt schreiben muss (ich gehe mal von java,c#,... ähnlicher Syntax aus)

HashMap<string,string> hm = new HashMap<string,string>() //unschön
var hm = new HashMap<string,string>() //vll so
HashMap<string,string> hm = New() //oder so
hm: HashMap<string,string> = New() //oder so
hm = HashMap()   //oder so mit mehr typinferenz
hm.add("a","B")

Ebenfalls bereits geplant:

let m1 := new HashMap!<string, int> // Leere Map
let m2 := hashMap([{"foo", 1}, {"bar", 2}]) // Direkt füllen
let m3 := ["foo" -> 1, "bar" -> 2] // Vielleicht auch so, mit Operatoren (noch nicht sicher)

[Xin]

Kellerautomat schrieb:

Naja, wenn es die Konfigurationsdatei oder Datenbankdatei ist, dann ist das schon ein Grund imo. Gerade in solchen Faellen finde ich Exceptions auch extrem praktisch.

Ich halte die Nutzung von Exceptions für eine Katastrophe.

Ein Softwareentwickler muss ein kritischer Mensch sein. Das bedeutet in meinem Selbstverständnis, dass er vorhersehen muss, wo das Programm scheitert, um Algorithmen zu formulieren die nicht scheitern.

Dein Beispiel habe ich bereits implementiert. Findet eins meiner Programme die Konfiguration nicht, legt es eine Standardkonfiguration an. Das ist für mich der Regelfall. if( !Config.Load() ) WriteConfig().

Es käme mir nie in den Sinn eine Exception zu werfen. Wenn ich beim Start des Programms das Programm konfiguriere und kann das nicht durch das Laden der Konfiguration, wie soll dann irgendeine Funktion im Stacktrace das können?

Wenn es meine Verantwortung ist, das Programm zu konfigurieren, dann ist meine Funktion auch dafür verantwortlich auf ein "File Not Found" angemessen zu reagieren und das Programm irgendwie startfähig zu machen. Wenn meine Funktion so geschrieben ist, dass sie nicht scheitern kann, dann startet das Programm. Und wenn ich die Funktion irgendwie so schreiben kann, dass sie nicht scheitern kann, dann tue ich das. Aber auf gar keinen Fall, werfe ich eine Exception für etwas belangloses, denn wer immer mich ruft oder denjenigen ruft, der mich gerufen hat, wird darauf spezialisiert sein, das Programm zu konfigurieren.

Viele Programmierer programmieren aber so, dass wenn der einfachste und erwartete Weg nicht funktioniert, dann bekomme ich eine Exception und die leite ich dann einfach weiter. Man gibt die Verantwortung immer weiter ab. Und irgendwann landet bei main() eine FileNotFound-Exception und main() weiß da auch nix anzufangen, das Programm endet und der User hat die Arschkarte. Für den Entwickler sind Exceptions aber extrem praktisch. Er hat ja eine Exception geworfen und musste sich um nix kümmern.
Und die Sprache suggeriert, dass das vorbildliches Verhalten ist.

In meinen Augen sind Exceptions der mit Abstand größte Fail, den Java besitzt bzw. in die gängige Programmierung eingeführt hat.

Kellerautomat schrieb:

Ich programmiere noch nicht mal 10 Jahre. Damals hatte ich auch noch keinen Computer :p

Warum möchtest Du dann eine Programmiersprache schreiben?

Kellerautomat schrieb:

Xin schrieb:

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

Weil die Klasse int final ist :p

Das sehe ich deutlich entspannter.

Allgemein halte ich nicht viel von 'final'.

Kellerautomat schrieb:

gary1195 schrieb:

2. Referenzen dürfen nicht null sein, außer es wird explizit erlaubt (wie zB bei Vala)

Das ist bereits der Fall:

void f(Foo? foo) // Nullable

Bei Klassen geht das auch sehr schön mit

void f( Foo * foo )

Das ist eine Referenz, die Null sein darf.

Im Gegensatz zu (Foo?) muss man aber nicht die Information mitführen, ob wie bei (int?) 0 0 oder Null bedeutet. Das ganze macht also nur Sinn, wenn Null ein valider Wert wäre, der sich von Null unterscheidet. Und wenn man über den vorherigen Satz nachdenken muss, um ihn zu verstehen, sollte man sowas im Quelltext vielleicht expliziter ausdrücken.

Kellerautomat schrieb:

let m1 := new HashMap!<string, int> // Leere Map

Wofür steht das '!'?

Gratulation für die Abkehr von '=' für die Zuweisung.

Wie lange programmierst Du und was hast Du so programmiert?

[knivil]

Eigene Programmiersprache? Im Moment sehe ich nur zusammengeklaute Dinge, die sich in den bekannten Sprachen auf die ein oder andere realisieren lassen.

Gratulation für die Abkehr von '=' für die Zuweisung.

Ja sehr fortschrittlich anders und ueberhaupt ...

Jeder computerspielende Depp will sein MMORPG programmieren, wird hier im Forum aber im optimalen Fall nur muede belaechelt, bestenfalls mit dem Verweis erstmal programmieren zu lernen.

Hier aktuell eine Programmiersprache, die C++, C#, .... alle vereint und super toll ist. Mein Rat: Etwas naeher an der Realitaet bleiben und Grundlagen aufbauen. Viele Probleme sind in der Vergangenheit bereits geloest worden.

Der Rest hat nichts mehr mit Programmiersprachen an sich zu tun:

Standardkonfiguration

Die gibt es nicht immer. Auch kann die Konfiguration von einem ... aeh ... externen Konfigurationsprogramm kommen.

Programm irgendwie startfähig zu machen

Ich moechte kein Steuerungprogramm fuer einen Laser startfaehig machen, wenn die Konfigurations fehlt.

[Kellerautomat]

knivil schrieb:

Eigene Programmiersprache? Im Moment sehe ich nur zusammengeklaute Dinge, die sich in den bekannten Sprachen auf die ein oder andere realisieren lassen.

Leute, die nichts anderes zu tun haben, außer kontraproduktiven Mist von sich zu geben, gehören auch nicht zu meiner Zielgruppe.

knivil schrieb:

Gratulation für die Abkehr von '=' für die Zuweisung.

Ja sehr fortschrittlich anders und ueberhaupt ...

Schön, dass du ohne zu wissen, wovon du sprichst, deine Meinung kundtust.
:= heißt übrigens Initialisierung, = ist eine Zuweisung.

Den Rest ignorier ich mal.

[knivil]

Bevor du weiter mit Beleidigungen um dich wirfst ... komm wieder wenn du was vorzuweisen hast. Viel Glueck bei deinem MMORPG.

Schön, dass du ohne zu wissen, wovon du sprichst, deine Meinung kundtust.

Du weisst es doch selbst nicht.

[Kellerautomat]

Xin schrieb:

Ich halte die Nutzung von Exceptions für eine Katastrophe.

Ein Softwareentwickler muss ein kritischer Mensch sein. Das bedeutet in meinem Selbstverständnis, dass er vorhersehen muss, wo das Programm scheitert, um Algorithmen zu formulieren die nicht scheitern.

Dein Beispiel habe ich bereits implementiert. Findet eins meiner Programme die Konfiguration nicht, legt es eine Standardkonfiguration an. Das ist für mich der Regelfall. if( !Config.Load() ) WriteConfig().

Es käme mir nie in den Sinn eine Exception zu werfen. Wenn ich beim Start des Programms das Programm konfiguriere und kann das nicht durch das Laden der Konfiguration, wie soll dann irgendeine Funktion im Stacktrace das können?

Wenn es meine Verantwortung ist, das Programm zu konfigurieren, dann ist meine Funktion auch dafür verantwortlich auf ein "File Not Found" angemessen zu reagieren und das Programm irgendwie startfähig zu machen. Wenn meine Funktion so geschrieben ist, dass sie nicht scheitern kann, dann startet das Programm. Und wenn ich die Funktion irgendwie so schreiben kann, dass sie nicht scheitern kann, dann tue ich das. Aber auf gar keinen Fall, werfe ich eine Exception für etwas belangloses, denn wer immer mich ruft oder denjenigen ruft, der mich gerufen hat, wird darauf spezialisiert sein, das Programm zu konfigurieren.

Viele Programmierer programmieren aber so, dass wenn der einfachste und erwartete Weg nicht funktioniert, dann bekomme ich eine Exception und die leite ich dann einfach weiter. Man gibt die Verantwortung immer weiter ab. Und irgendwann landet bei main() eine FileNotFound-Exception und main() weiß da auch nix anzufangen, das Programm endet und der User hat die Arschkarte. Für den Entwickler sind Exceptions aber extrem praktisch. Er hat ja eine Exception geworfen und musste sich um nix kümmern.
Und die Sprache suggeriert, dass das vorbildliches Verhalten ist.

In meinen Augen sind Exceptions der mit Abstand größte Fail, den Java besitzt bzw. in die gängige Programmierung eingeführt hat.

Gut, mein Beispiel war zugegebenermaßen blöd gewählt.
Nach deiner Argumentation ist das Problem also, dass Exceptions einfach weiergegeben werden? Wären dann nicht checked Exceptions von Java die Lösung?!

Xin schrieb:

Kellerautomat schrieb:

Ich programmiere noch nicht mal 10 Jahre. Damals hatte ich auch noch keinen Computer :p

Warum möchtest Du dann eine Programmiersprache schreiben?

Weil ich denke, dass ich ein paar gute Ideen habe und aktuelle Sprachen alle irgendwelche Problme haben.

Xin schrieb:

Kellerautomat schrieb:

]

Xin schrieb:

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

Weil die Klasse int final ist :p

Das sehe ich deutlich entspannter.

Allgemein halte ich nicht viel von 'final'.

final ist gut als Optimierungsmöglichkeit, daher sind bei mir alle Klassen und Methoden per default final.

Xin schrieb:

Das ist eine Referenz, die Null sein darf.

Im Gegensatz zu (Foo?) muss man aber nicht die Information mitführen, ob wie bei (int?) 0 0 oder Null bedeutet. Das ganze macht also nur Sinn, wenn Null ein valider Wert wäre, der sich von Null unterscheidet. Und wenn man über den vorherigen Satz nachdenken muss, um ihn zu verstehen, sollte man sowas im Quelltext vielleicht expliziter ausdrücken.

T? nimmt alle Möglichen Werte von T sowie den Wert null auf. Was ist daran schwer?

Xin schrieb:

Kellerautomat schrieb:

let m1 := new HashMap!<string, int> // Leere Map

Wofür steht das '!'?

Dient dazu, um Mehrdeutigkeiten in der Grammatik aufzulösen.

Xin schrieb:

Gratulation für die Abkehr von '=' für die Zuweisung.

Wie schon mal gesagt: ":=" heißt Initialisierung, "=" ist eine Zuweisung.
Das hat insbesondere Voteile in Konstruktoren: Man kann die Initialisierung im Funktionskörper durchführen und braucht keine Initialisierungsliste mehr. Außerdem ist die Initialisierungsreihenfolge egal.

Xin schrieb:

Wie lange programmierst Du und was hast Du so programmiert?

Ich hab im Alter von 11 Jahren angefangen, C++ zu lernen.
Was hab ich gemacht? Eine VM geschrieben in C++, ein paar IRC-Bots in C++ und Java, diverse Minecraft-Server Plugins. Microsoft Sharepoint Plugins in C#. Websites in PHP, Greasemonkey Scripte in JS.

Nichts großes also, aber dafür viele kleinere Sachen.

[Xin]

knivil schrieb:

Eigene Programmiersprache? Im Moment sehe ich nur zusammengeklaute Dinge, die sich in den bekannten Sprachen auf die ein oder andere realisieren lassen.

Ich habe vor knapp 10 Jahren eine ähnliche Umfrage gemacht, aber nicht in einem Forum, sondern ich schrieb eine eigene Website dafür, ähnlich surveymonkey. Aber neben fragen ähnlich 'Auf einer Skala von 1 bis 10..." hatte ich auch reichlich Textfelder, wo ich die Leute einfach mal schreiben ließ. Das machen kaum Umfragen, weil man die Ergebnisse nicht automatisiert in ein Excel-Diagramm packen kann. Wissenschaftlich also zu aufwendig, ergo wertlos. Ich sehe mich eher als Praktiker: Für mich sind das interessanten Felder.
Ich erhielt rund 400 von einander unabhängige Antworten. Die würde kellerautomat vermutlich genauso interessieren, wie mein Aktenordner. ^^

Die wichtigste Erkenntnis daraus, möchte ich aber durchaus teilen: Während Programmieranfänger, Ingenieure, Mathematiker, Projektleiter, Wirtschaftler, die eben nicht als Informatiker programmierten sich über fast alles beschwerten, fielen ITler nicht nur mit einer Ideenarmut auf ("Da habe ich mir noch nie Gedanken drüber gemacht."), sondern vorrangig damit, dass jeder Versuch etwas zu verändern nicht gewünscht ist: "Zeitverschwendung", "Man kann mit den existieren den Sprachen schon alles machen".
Ich fand es sehr erstaunlich, wie sehr professionelle Entwickler Wert darauf legen, dass sich ihr Werkzeug nicht verändert. Es ist ja nicht so, dass eine neue Sprache ihnen ihre derzeitige Sprache verbieten würde, es wäre ja nur ein zusätzliches Angebot.

Jede Programmiersprache "klaut", denn am Schluss kommen doch nur Assembler-Befehle heraus. Man macht nur einige Details anders. Es gibt nur wenige Baustellen, wo man Dinge "neu" machen kann - oder eher - bekannte Dinge fortführen, weiterentwickeln, übertragen kann.

Es wird keine "neue" Programmiersprache geben. Ich behaute auch nie, dass ich eine "neue" Sprache entwickle, ich behaupte nur, eine "eigene" Sprache entwickle und mich dabei auf andere Dinge konzentriere als andere Sprachen. Eigene Erfahrungen verwerte, auf die in diesem Forum in der Regel ablehnend reagiert wird. Aber aus der Erfahrung heraus, würde ich auch keinen Informatiker ernsthaft mehr fragen, wie er sich sein Haupt-Werkzeug vorstellt, wenn er sich darüber keine Gedanken macht.

knivil schrieb:

Gratulation für die Abkehr von '=' für die Zuweisung.

Ja sehr fortschrittlich anders und ueberhaupt ...

Im Gegenteil, es ist rückschrittlich. Jede moderne Programmiersprache benutzt für die Zuweisung den '=' Operator. Die Zuweisung per ':=' findet sich eher im Bereich Algol 60, bzw. davon abgeleitet in Pascal und Delphi. Alles mehr oder weniger tote Sprachen.

Aber die Richtung stimmt. Wer die Zukunft sucht, muss dahin gehen, wo der Java-Hype begann und jedes kreative Denken eliminierte. '=' als Zuweisung ist man gewohnt, darum rüttelt an sowas niemand. Wenn man aber fortschreiten möchte, muss man das gewohnte Umfeld verlassen. Was ich aus dem ':=' herauslese ist nicht, dass er den Doppelpunkt (wieder) dazu setzt, sondern dass er sich nicht durch das Umfeld einengen lässt und sich von ablehnenden Reaktionen, wie der deinigen, die auch eher die Regel als die Ausnahme sein wird, beeinflussen lässt und dazu ist ihm nur zu gratulieren. Indem er sich der Forderung seines Umfeldes widersetzt, alles beim Alten zu lassen, ermöglicht er sich und seinen Ideen Fortschritt.

Wenn er anfängt, etwas zu implementieren, wird man ihm sagen, dass er das alleine nie schaffen kann. Das habe ich auch schon oft genug gehört, den Spruch in der Signatur kommt daher.

knivil schrieb:

Hier aktuell eine Programmiersprache, die C++, C#, .... alle vereint und super toll ist. Mein Rat: Etwas naeher an der Realitaet bleiben und Grundlagen aufbauen. Viele Probleme sind in der Vergangenheit bereits geloest worden.

Warum programmierst Du denn? Viele Programme sind in der Vergangenheit schon geschrieben worden. Wer braucht da das, was Du schreibst?

Wenn kellerautomat soweit ist, eine Sprache wie C zu übersetzen, wird sehr, sehr viel mehr Grundlagen über Datenverarbeitung mehr gelernt haben, als die meisten Informatiker. Und er wird viel genauer verstehen, was eine Sprache eigentlich tut, wenn man sie programmiert - weil er nicht nur die Grundlagen gelernt hat, sondern sie wörtwörtlich begriffen hat.

Ich habe auch keine Ahnung, ob meine Sprache jemals fertig wird. Aber es macht Spaß. Genauso wie es anderen Spaß macht, das 100. Tetris zu programmieren. Ich habe immernoch Spaß am Programmieren, obwohl ich 40 Stunden pro Woche als Software-Entwickler arbeite. Auch etwas, was die meisten Software-Entwickler verlieren: Den Spaß an der Sache.
Ich programmiere seit 1989. Der Reiz wäre sicherlich längst weg, wenn ich nur Fließbandarbeiten und nur die Lösungen der Vergangenheit abschreiben würde.
Also glaube ich nicht, dass ich was falsch mache. ^^

[Xin]

Kellerautomat schrieb:

Xin schrieb:

Ich halte die Nutzung von Exceptions für eine Katastrophe.

Ein Softwareentwickler muss ein kritischer Mensch sein. Das bedeutet in meinem Selbstverständnis, dass er vorhersehen muss, wo das Programm scheitert, um Algorithmen zu formulieren die nicht scheitern.

Dein Beispiel habe ich bereits implementiert. Findet eins meiner Programme die Konfiguration nicht, legt es eine Standardkonfiguration an. Das ist für mich der Regelfall. if( !Config.Load() ) WriteConfig().

Es käme mir nie in den Sinn eine Exception zu werfen. Wenn ich beim Start des Programms das Programm konfiguriere und kann das nicht durch das Laden der Konfiguration, wie soll dann irgendeine Funktion im Stacktrace das können?

Gut, mein Beispiel war zugegebenermaßen blöd gewählt.
Nach deiner Argumentation ist das Problem also, dass Exceptions einfach weiergegeben werden? Wären dann nicht checked Exceptions von Java die Lösung?!

Nein, das wäre eine Symptombehandlung.

Für 4 Zeilen C++ Code, die nicht fehlschlagen konnten, brauchte ich 2 Seiten Java-Quelltext, weil ich diszipliniert jede Exception abarbeiten musste, die per 'throws' vorgegeben waren.

Alleine die Trennung von Fehlerauftritt und Fehlerbehandlung halte ich für falsch - das muss zusammenbleiben.
Das Springen über die Funktionshierarchie hinaus, ist eine Katastrophe.

Vielliecht hast Du mal was von INTERCAL gehört. Das ist eine Programmiersprache aus den 70ern. Bekannt wurde sie für das "COME FROM"-Statement, ein inverses Goto. Erreicht das Programm das Label, das bei COME FROM angegeben ist, verzweigt es an die Stelle, wo das COME FROM im Quelltext steht.

Etwa so:

printf( "1\n" );
Label:

  printf( "2\n" );

  come from Label;

  printf( "3\n" );

Ausgabe:
1
3

INTERCAL hatte nur einen Zweck: Die Programmierung so umständlich und schlecht wie möglich zu machen. Eine reine Demonstration, wie man es nicht machen soll.

Und jetzt ersetze mal "COME FROM" mit "catch" und vor das Label schreibst Du "throw"...

Kellerautomat schrieb:

Xin schrieb:

Kellerautomat schrieb:

Ich programmiere noch nicht mal 10 Jahre. Damals hatte ich auch noch keinen Computer :p

Warum möchtest Du dann eine Programmiersprache schreiben?

Weil ich denke, dass ich ein paar gute Ideen habe und aktuelle Sprachen alle irgendwelche Problme haben.

Und reichen die Ideen, um den Aufwand zu rechtfertigen?

Kellerautomat schrieb:

final ist gut als Optimierungsmöglichkeit, daher sind bei mir alle Klassen und Methoden per default final.

Spricht ja nicht gegen Optimierung, solange man das final zurücknehmen kann. ^^

Kellerautomat schrieb:

Xin schrieb:

Das ist eine Referenz, die Null sein darf.

Im Gegensatz zu (Foo?) muss man aber nicht die Information mitführen, ob wie bei (int?) 0 0 oder Null bedeutet. Das ganze macht also nur Sinn, wenn Null ein valider Wert wäre, der sich von Null unterscheidet. Und wenn man über den vorherigen Satz nachdenken muss, um ihn zu verstehen, sollte man sowas im Quelltext vielleicht expliziter ausdrücken.

T? nimmt alle Möglichen Werte von T sowie den Wert null auf. Was ist daran schwer?

Nichts. Aber wo braucht man es, außer bei Primitiven?

Ist das ein Konstrukt wert?
Ist das ein ? wert?
Wenn Du viele Ideen hast, wird Dir auffallen, dass Kurzzeichen-Operatoren eher Mangelware sind.

Kellerautomat schrieb:

Xin schrieb:

let m1 := new HashMap!<string, int> // Leere Map

Wofür steht das '!'?

Dient dazu, um Mehrdeutigkeiten in der Grammatik aufzulösen.[/quote]
Mehrdeutigkeiten? Welche könnte das sein?
Es ist doch Deine Grammatik und da sollte die Sache doch möglichst eindeutig sein?

Kellerautomat schrieb:

Xin schrieb:

Gratulation für die Abkehr von '=' für die Zuweisung.

Wie schon mal gesagt: ":=" heißt Initialisierung, "=" ist eine Zuweisung.

Oh... schade. ^^

Kellerautomat schrieb:

Das hat insbesondere Voteile in Konstruktoren: Man kann die Initialisierung im Funktionskörper durchführen und braucht keine Initialisierungsliste mehr. Außerdem ist die Initialisierungsreihenfolge egal.

let f1 := Foo(1);
let f2 := Foo(2);

f1 := f2;

Was bedeutet das?

Kellerautomat schrieb:

Xin schrieb:

Wie lange programmierst Du und was hast Du so programmiert?

Ich hab im Alter von 11 Jahren angefangen, C++ zu lernen.

Interessanter Zeitpunkt, dann verstehst Du Programmiersprachen vermutlich anders als die meisten hier.

Fang mal an und halt mich auf dem Laufenden. Interessiert mich. Wenn Du Fragen hast, auf unten genanntem Forum lese ich alle Boards und bin unter UsernameHier at proggen.org zu erreichen, hier lese eigentlich nur "Beruf und Ausbildung" und ansonsten nur wenn ich Zeit habe und/oder zufällig was Interessantes mitbekomme.

[otze]

Xin schrieb:

Alleine die Trennung von Fehlerauftritt und Fehlerbehandlung halte ich für falsch - das muss zusammenbleiben.

Damit stehst du aber beei vielen Fehlern alleine da. Die meisten Fehler sind nicht vor ort korrigierbar.

[knivil]

PS: @Xin, du erzaehlst gern von dir ... aber das Thema bist nicht du und ich will auch nicht ueber dich reden. Deswegen schweige ich zu deinem Beitrag.

[Xin]

otze schrieb:

Xin schrieb:

Alleine die Trennung von Fehlerauftritt und Fehlerbehandlung halte ich für falsch - das muss zusammenbleiben.

Damit stehst du aber beei vielen Fehlern alleine da. Die meisten Fehler sind nicht vor ort korrigierbar.

Das ist vielleicht eine Frage der Perspektive, bzw. nach der Antwort auf die Frage "Was ist ein Fehler"? Was ist Wunsch, was ist Erwartung?

Möchte ich die Konfiguration laden, so ist mein Wunsch, dass ich die Datei finde und einlesen kann. Meine Erwartung ist aber, dass mein Wunsch in er Erfüllung gehen kann - aber eben nicht muss. Wenn ich die Datei nicht finde, ist jetzt der optimale Zeitpunkt, darauf zu reagieren, denn ich weiß an dieser Stelle ohne weitere Nachfrage, welches Detail hier eigentlich nicht wunschgemäß verlaufen ist. Entsprechend kann ich das Detail häufig schon korrigieren und den eigentlichen Algorithmus weiterlaufen lassen.

Zu einem Fehler, also dass der Algorithmus nicht weiter weiß, sollte es also gar nicht kommen.

Kommt es trotzdem zu einem besonderen Fehler, zum Beispiel, dass die bereits geöffnete Datei nicht mehr gelesen werden kann, weil jemand den USB-Stick gezogen hat, akzeptiere ich ausnahmsweise eine Ausnahme.

knivil schrieb:

PS: @Xin, du erzaehlst gern von dir ... aber das Thema bist nicht du und ich will auch nicht ueber dich reden. Deswegen schweige ich zu deinem Beitrag.

Ein PS kommt nach dem Beitrag, ein PS ohne einen Beitrag ist sinnfrei.

Schweigen ist nicht mit "Ich poste, dass ich schweige" zu realisieren, zumal Du auch hier nur Destruktives beizutragen hast. Du möchtest nochmal in meine Richtung treten, das wird auch nicht zu "schweigen", wenn Du schreibst, dass Du schweigen würdest.

Sollte der Threadstarter an meinen "Erzählungen" nicht interessiert sein, so darf er mir das gerne sagen.

Wenn Du daran nicht interessiert bist, das Thema ist nicht für Dich.
Sofern Du nichts Konstruktives beizutragen hast, schweige bitte aktiv.