Kann ich eh nicht ändern. Ist seine Entscheidung. Und wenn jemand der Prüffunktion was übergeben möchte, was nicht von "Spielobjekt" abgeleitet wurde, gibt's halt nen Fehler.

Ja, nur kosten diese Art der Fehler ziemlich viel Geld - je größer, komplexer und integrierter Software wird, desto mehr Fehler dieser Art treten auf. Statische Typisierung ist nicht umsonst entwickelt worden. (und wird es immernoch)

Wie vorher schon gesagt: Es sei Dir unbenommen, dass "Parser", "Compiler" oder wie-auch-immer zu nennen. Sinnvoll ist das _meiner_ Meinung nach nicht.

Deine Meinung in allen Ehren - die Entwicklung der neueren Programmiersprachen und z.B. auch die Änderungen in Java 8 zeigen, dass es sehr wohl sinnvoll ist. Alles geht in diese Richtung.

Spätestens jetzt habe ich wirklich etwas den Faden verloren, was Du mir sagen möchtest (ich komme jetzt zu dem, auf was ich voher schon verwiesen hatte).
Eindeutig widersprechen kann ich Dir, dass "diese Sprache nicht mächtig genug ist, um deine Gedanken in ihr auszudrücken". Wie man - so hoffe ich jedenfalls - erkennen kann, ist diese Sprache mächtig genug, dass ich meine Intention mit ihrer Hilfe widerspiegeln konnte.

Ja, indem du einen Mini-Interpreter geschrieben hast. ;)
Wie gesagt, nach deiner Definition kann man auch jede Intention mit Assembler ausdrücken oder nicht?

Zumindest Matthias und Du scheinen ja meine Idee nachvollzogen und verstanden zu haben. Sozusagen q.e.d.

Ich möchte aber, dass auch du es tust. Du musst ja nicht mit mir übereinstimmen, aber meine Ansichten nachvollziehen zu können - das wäre doch schön.

Dass ich die "Sprache so erweitert [habe], dass sie ausdrucksstärker wird", bezweifle ich nicht. Das ist aber die Voraussetzung für Programmierung.

Nein, das ist nicht richtig. Natürlich muss man mit der Sprache arbeiten, aber man muss sie nicht zwangsläufig ausdrücksstärker machen.

Außerdem (auch darauf kommst Du gleich noch zu sprechen): Wie ist das bei Multiple Dispatch (habe gerade extra nochmal bei Wikipedia reingeschaut)? Ist es intuitiv und entspricht es weitgehend Deinen Gedanken, dass Du eine abstrakte Klassendefinition, eine abstrakte Methodendefinition und eine "kryptische" Methodenimplmentierung angeben kannst, um "blaues Auto" zu sagen?

Intuitiv nicht, nein. Aber ich kann damit meinem Gedanken ohne drumherum ausdrücken. Alles was halbwegs komplex ist, ist nicht mehr intuitiv - solange bis es intuitiv wird. ;)

Ein gutes Beispiel sind auch Arrays oder Listen. [Beispiel entfernt]

Aber sind das wirklich die Gedanken, die man hat? Denkt man wirklich "mach eine Variable i und gib ihr den Wert 0, dann guck dir die Liste der Dateien an und hol dir die Anzahl deren Elemente, zieh davon 1 ab und solange Variable i kleiner als diese Anzahl ist tue... usw.
Nicht wirklich oder?

Nein, natürlich nicht. Da gebe ich Dir recht. Aber wo ist das Problem? So funktioniert _jede_ Sprache nun einmal, sonst wäre es keine Sprache.

Das war ja nur ein Beispiel. Und das ist durchaus ein Problem, denn je einfacher verständlich der geschriebene Quellcode, desto besser. Übrigens ist auch eine Schleife mit Variablen inhaltlich etwas anderes als die foreach Lösung. Ja wirklich: beide Varianten KÖNNEN sich gleich verhalten, müssen es aber nicht. Erkennst du, warum?

Eine Sprache ist einfach eine Konvention, um anderen "Objekten" (im Normalfall: anderen Menschen) seine Gedanken verständlich zu machen. Ich muss auch bei der "natürlichen Sprache" Umwege in Kauf nehmen und mit der Sprache arbeiten. Alles andere würde nicht funktionieren, keiner würde mich verstehen oder neue Gedanken könnten nicht gedacht werden.

Gruß,
der T-Rex hat noch nix zu meiner zweiten Grußzeile gesagt,
Dennis

Ps: Wo ich meinen Text gerade nochmal in der Vorschau gelesen habe: Manches ist nicht ganz so toll formuliert, Whouzuo, es ist aber nichts auch nur im Entferntesten böse gemeint!

Kein Problem, besonders Freitags nach der Arbeit. ;)