D?

[CStoll]

GPC schrieb:

CStoll schrieb:

(btw, wie kann man in D die Kommunativität eines Operators abschalten? (z.B. für Matrix-Multiplikation))

Kommutativität?
Die binären Operatoren haben zwei Funktionen zum Überladen, z.B. eine die den Fall a+b und eine die b+a behandelt. Eine davon nicht implementieren.

Ich zitiere mal von der D-Webseite

Given a binary overloadable operator op and its corresponding class or struct member function name opfunc and opfunc_r, and the syntax:

a op b

the following sequence of rules is applied, in order, to determine which form is used:

1. The expression is rewritten as both:

a.opfunc(b)
b.opfunc_r(a)

If any a.opfunc or b.opfunc_r functions exist, then overloading is applied across all of them and the best match is used. If either exist, and there is no argument match, then it is an error.

1. If the operator is commutative, then the following forms are tried:

a.opfunc_r(b)
b.opfunc(a)

1. If a or b is a struct or class object reference, it is an error.

Das heißt, wenn der Compiler keine Matrix!(i,j).opMul(Matrix!(k,i)) findet, verwendet er als nächstes Matrix!(k,i).opMul(Matrix!(i,j)) (und vertauscht mir damit meine Fkatoren, um das Produkt irgendwie doch noch darstellen zu können)

[Gast]

CStoll schrieb:

Optimizer schrieb:

Was wird eigentlich an der Syntax von D genau kritisiert?

D hat womöglich Potential, eine ernsthafte Konkurrenz zu Java oder C# zu bilden - und hat auch einige netten Features. Aber was ich beim Überfliegen der Doku so gesehen habe, schwankt zwischen "rein syntaktische Unterschiede" (z.B. sizeof(char) vs. char.sizeof) und "nett anzusehen, aber in C++ mit geringem Aufwand realisierbar" (z.B. Vergleichsoperatoren: Ja, man braucht 8 Funktionen zum Vergleichen - aber sieben davon kann man per Template bereitstellen).

Also an der Syntax selber wird nichts kritisiert oder? Ich war schon verwundert. So fremdartig erscheint sie mir ja nicht.

[Konrad Rudolph]

Optimizer schrieb:

Also an der Syntax selber wird nichts kritisiert oder? Ich war schon verwundert. So fremdartig erscheint sie mir ja nicht.

Ahem. Da die Syntax an die von C angelehnt ist, ist sie ja eigentlich schon per Default Schrott. Was reitet Sprach-Designer nur, diese fehlgeleiteten Konstrukte zu kopieren? (Ich meine, die Motivation hinter der C-Syntax war ja sehr interessant und hätte aufgehen können aber es hat sich doch in der Praxis einfach gezeigt, dass sie falsch war.)

[Sovok]

Konrad Rudolph schrieb:

Was reitet Sprach-Designer nur, diese fehlgeleiteten
Konstrukte zu kopieren? (Ich meine, die Motivation hinter der C-Syntax war ja
sehr interessant und hätte aufgehen können aber es hat sich doch in der Praxis
einfach gezeigt, dass sie falsch war.)

Was war denn die Motivation und warum ist Sie nich aufgegangen?
Würd mich direkt mal interessiern

[CStoll]

Optimizer schrieb:

Also an der Syntax selber wird nichts kritisiert oder? Ich war schon verwundert. So fremdartig erscheint sie mir ja nicht.

Mit der Syntax könnte ich mich im Ernstfall schon anfreunden (ist zwar sicher in Details eine Umstellung, aber machbar). Witzig finde ich nur, daß D fast alle C/C++ Grundkonzepte als schlecht oder unzureichend einstuft - und dann selber teilweise nur syntaktisch andere Ansätze liefert.

Beispiele, die mir spontan auffallen:

• Inwiefern ist "int.sizeof" besser als "sizeof(int)"?
• Beim Vergleich wird hingestellt, daß man 'straightforward' "if(x==y)..." schreiben kann - die Tatsache, daß die dazu nötige opEquals auch oft Unsinn macht, wird dabei unterschlagen (und zumindest ich führe meine Vergleiche normalerweise nicht auf memcmp() zurück).
• Was ist der Unterschied zwischen einer scope-Klasse und einer lokalen Variablen? (Stichwort RAII)
• Die ganzen angeblichen "Probleme" mit Complex-Klassen kann man mit einem einfache 'const complex<double> i(0,1);' umgehen - oder parallel zu den complex-Klassen reine imaginary-Klassen schreiben (ist zwar aufwendig in der Entwicklung, aber auch nicht schwieriger anzuwenden als D's Variante)
• ...

(und daß es eine ellenlange Liste von "Verbesserungen" gegenüber C gibt, kann man nur als Witz einstufen - zumal viele der dortigen Frage schon eine brauchbare C++ Lösung haben)

[Konrad Rudolph]

Sovok schrieb:

Was war denn die Motivation und warum ist Sie nich aufgegangen?
Würd mich direkt mal interessiern

Da gibts verschiedene Sachen, speziell beziehe ich mich aber auf diese Idee, bei der Deklaration einer Variable die Zugriffsweise zu emulieren. Also dass ich halt z.B. schreibe 'int *x', weil ich später per '*x' Zugriff auf das darin gespeicherte int erhalte. Nette Idee, ergibt aber leider ein absolutes Chaos bei verschachtelten Typen, das nicht nur für Anfänger komplex ist.

Außerdem war es von vornherein ein Schuss in den Ofen, auf Schlüsselwörter wie 'var' und 'function' zu verzichten: Klar geht es ohne, aber der Lesbarkeit hift es nicht gerade.

[GPC|off]

CStoll schrieb:

Das heißt, wenn der Compiler keine Matrix!(i,j).opMul(Matrix!(k,i)) findet, verwendet er als nächstes Matrix!(k,i).opMul(Matrix!(i,j)) (und vertauscht mir damit meine Fkatoren, um das Produkt irgendwie doch noch darstellen zu können)

Stimmt, das haben sie IIRC vor einiger Zeit geändert.
Eigentlich ein Widerspruch zu dem Verbot von implizierten Konvertierungen.

[Simon2]

Konrad Rudolph schrieb:

...
Es ist lustig, wie oft man in diese „Falle“ fällt zu denken, Programmieren habe etwas mit Meinungen oder Vorlieben zu tun. Das ist ja nur äußerst selten der Fall: Informatik, und auch Programmieren, ist eine Wissenschaft, die mit Fakten umgeht....

Und es ist lustig, wie oft man in diese "Falle" fällt, zu denken, "Wissenschaft" und "Fakten" hätten nichts mit "Vorlieben" und "Meinungen" zu tun....
Aber das führt zu weit hier ...

Gruß,

Simon2.

[finix]

groovemaster schrieb:

Das läuft, wie ich bereits sagte, unter semantischem Zucker.

Und C++ ist lediglich semantischer Zucker für C

[GPC]

Konrad Rudolph schrieb:

...
Es ist lustig, wie oft man in diese „Falle“ fällt zu denken, Programmieren habe etwas mit Meinungen oder Vorlieben zu tun. Das ist ja nur äußerst selten der Fall: Informatik, und auch Programmieren, ist eine Wissenschaft, die mit Fakten umgeht....

Ich weiß nicht. Man schaue sich doch nur die ganzen Flamewars an, oder Threads die sich über zig Seiten erstrecken und "Welche Einrückung ist besser?" zum Thema haben.

[Krux]

ist es objektiv, dass man mit einer Programmiersprache die man besser kennt mehr anfangen kann, als mit einer in dem einem alles fremd vorkommt. Wenn man nun einmal eine Sprache richtig lernt, und dann kommt plötzlich eine andere, die man lernen muss, dann ist diese spracht und die verwendete Systax erstmal schlecht, und es führt zum flamewar. Ist doch ganz logisch, ich werde mich in zukunft aber nicht an sochen diskussionen beteiligen, denn Systax ist meist wirklich nur subjektiv.

[Konrad Rudolph]

GPC schrieb:

Konrad Rudolph schrieb:

...
Es ist lustig, wie oft man in diese „Falle“ fällt zu denken, Programmieren habe etwas mit Meinungen oder Vorlieben zu tun. Das ist ja nur äußerst selten der Fall: Informatik, und auch Programmieren, ist eine Wissenschaft, die mit Fakten umgeht....

Ich weiß nicht. Man schaue sich doch nur die ganzen Flamewars an, oder Threads die sich über zig Seiten erstrecken und "Welche Einrückung ist besser?" zum Thema haben.

Das sind ja auch meistens sooo substanzielle Diskussionen.

Natürlich gibt es immer und überall Vorlieben (wobei ich mal behaupte, dass die meisten in diesem Bereich durch Gewöhnung erreicht werden). Aber oft werden objektive Kriterien bei Flamewars einfach ignoriert.

[nep]

Konrad Rudolph schrieb:

Aber oft werden objektive Kriterien bei Flamewars einfach ignoriert.

Sonst wärs doch auch kein Flamewar

[groovemaster]

Konrad Rudolph schrieb:

Ahem. Da die Syntax an die von C angelehnt ist, ist sie ja eigentlich schon per Default Schrott.

Naja, das ist wie so oft sehr subjektiv. Es gibt einige Sachen, die ich auch nicht wirklich toll finde, zB die Typ Syntax. Vom Grundprinzip her ist aber die C Syntax nicht schlecht. Sie gefällt mir zumindest besser als so manch anderes. Aber jedem wird man es sowieso nie recht machen können. Common Lisp mit seinen unendlichen Klammerorgien ist sicherlich auch nicht jedermanns Geschmack.

Konrad Rudolph schrieb:

Da gibts verschiedene Sachen, speziell beziehe ich mich aber auf diese Idee, bei der Deklaration einer Variable die Zugriffsweise zu emulieren. Also dass ich halt z.B. schreibe 'int *x', weil ich später per '*x' Zugriff auf das darin gespeicherte int erhalte.

Das hat nichts mit "Zugriffsweise" zu tu, sondern vielmehr mit Indirektion.

Konrad Rudolph schrieb:

Außerdem war es von vornherein ein Schuss in den Ofen, auf Schlüsselwörter wie 'var' und 'function' zu verzichten

Für Leute, die die Sprache nicht kennen, mag das evtl. hilfreich sein. Für Leute, die sie kennen, ist das eher hinderlich. Je weniger Schlüsselwörter eine Sprache für eine gewisse Funktionalität benötigt, desto sauberer ist der Designansatz. Auch wenn es womöglich gar nicht gewollt war.

finix schrieb:

Und C++ ist lediglich semantischer Zucker für C

Kann man so sehen. Wobei OO oder generische Programmierung schon ein Stückchen darüber hinaus gehen.

[Konrad Rudolph]

Konrad Rudolph schrieb:

Außerdem war es von vornherein ein Schuss in den Ofen, auf Schlüsselwörter wie 'var' und 'function' zu verzichten

Für Leute, die die Sprache nicht kennen, mag das evtl. hilfreich sein. Für Leute, die sie kennen, ist das eher hinderlich. Je weniger Schlüsselwörter eine Sprache für eine gewisse Funktionalität benötigt, desto sauberer ist der Designansatz.

Diese Aussage ist so pauschal sicher nicht korrekt. Generell bin ich natürlich auch ein Fan von Minimalismus. Aber gewisse Redundanzen erhöhen die Lesbarkeit schon. Gerade, was Deklarationen angeht, ist C ziemlich defizitär und das bringt dann in C++ Doppeldeutigkeiten zustande, in denen nur durch die Klammerung zwischen Funktionsdeklaration und Konstruktoraufruf unterschieden werden kann. Selbst routinierte C++-Programmierer stolpern über solche Konstrukte. Und nicht nur in C++; ich programmiere beruflich unter anderem C# und selbst hier stolpere ich bisweilen über eine Variablendeklaration.

Es gab zu dem Thema AFAIK sogar eine Studie, die das verdeutlicht haben.

finix schrieb:

Und C++ ist lediglich semantischer Zucker für C

Irgendwie ignoriert diese Aussage das C++-Typensystem komplett.

[Gast]

Konrad Rudolph schrieb:

finix schrieb:

Und C++ ist lediglich semantischer Zucker für C

Irgendwie ignoriert diese Aussage das C++-Typensystem komplett.

Was ja auch nicht berauschend ist und kaum besser als das von C. Das ist mal wirklich ein Punkt, wo D einfach mehr zu bieten hat, zum Beispiel durch die typedefs, eine ganz feine Sache.

[mmmm]

Konrad Rudolph schrieb:

Gerade, was Deklarationen angeht, ist C ziemlich defizitär und das bringt dann in C++ Doppeldeutigkeiten zustande, in denen nur durch die Klammerung zwischen Funktionsdeklaration und Konstruktoraufruf unterschieden werden kann.

liegt aber auch an schlechten Namen. Klassennamen sollten Substantive und Methoden Verben sein. Und wenn manche Leute nicht noch auf die Idee kommen würden die Methoden groß zu schreiben, dann wäre es ganz klar.

[GPC]

Optimizer schrieb:

Konrad Rudolph schrieb:

finix schrieb:

Und C++ ist lediglich semantischer Zucker für C

Irgendwie ignoriert diese Aussage das C++-Typensystem komplett.

Was ja auch nicht berauschend ist und kaum besser als das von C. Das ist mal wirklich ein Punkt, wo D einfach mehr zu bieten hat, zum Beispiel durch die typedefs, eine ganz feine Sache.

Schon, aber man hätte imo nicht unbedingt die Bedeutung von typedef ändern sollen, sondern noch ein neues Schlüsselwort einführen. alias wurde ja auch eingeführt.
Oder typedef wie in C(++) lassen und ein neues Schlüsselwort für das Deklarieren semantisch neuer Typen.

[groovemaster]

Konrad Rudolph schrieb:

Diese Aussage ist so pauschal sicher nicht korrekt. Generell bin ich natürlich auch ein Fan von Minimalismus. Aber gewisse Redundanzen erhöhen die Lesbarkeit schon. Gerade, was Deklarationen angeht, ist C ziemlich defizitär und das bringt dann in C++ Doppeldeutigkeiten zustande, in denen nur durch die Klammerung zwischen Funktionsdeklaration und Konstruktoraufruf unterschieden werden kann.

Das ist aber eben ein C++ Problem und kein generelles.

[Konrad Rudolph]

groovemaster schrieb:

Konrad Rudolph schrieb:

Diese Aussage ist so pauschal sicher nicht korrekt. Generell bin ich natürlich auch ein Fan von Minimalismus. Aber gewisse Redundanzen erhöhen die Lesbarkeit schon. Gerade, was Deklarationen angeht, ist C ziemlich defizitär und das bringt dann in C++ Doppeldeutigkeiten zustande, in denen nur durch die Klammerung zwischen Funktionsdeklaration und Konstruktoraufruf unterschieden werden kann.

Das ist aber eben ein C++ Problem und kein generelles.

Nein, es ist ein Problem, das auf dieser minimalistischen Syntax fußt. Wenn man von vornherein unterschiedliche Typen von Anweisungen durch Schlüsselwörter abgetrennt hätte, dann wäre das Problem nie vorhanden gewesen. Gut, man kann sicher auch zuweit gehen und wie in BASIC für *jede* Anweisung ein Schlüsslwort verlangen. Aber Sprachkonstrukte gehören einfach ausgewiesen.