D?

[langeweile]

Es wird von mir auch demnächst etwas umfassendes zu D im Magazin geben.

Mal abwarten...

[finix]

groovemaster schrieb:

Kurz zusammengefasst, D bietet im Vergleich zu C++ nichts neues. Teilweise beschnitten, zB fehlende Mehrfachvererbung. Der Rest ist fast ausschliesslich semantischer Zucker. Über die Syntax lässt sich teilweise auch diskutieren.

Nichts neues?

GC, nested functions, function literals, lazy evaluation, nested classes, ... link

[Konrad Rudolph]

Ich finde, der iX-Artikel (6/2007) zum Thema brachte es (im letzten Absatz!) ganz gut auf den Punkt:

Sprachen wie Ada, die ebenso leistungsfähig sind wie D und noch dazu einen sauberen Sprachentwurf aufweisen, dürften hier in einer anderen Liga spielen.

(Hervorhebung von mir.)

=> D ist ein Haufen ganz netter Features, aber unprofessionell zusammengeworfen und damit letztendlich recht belanglos.

[Sovok]

hab mal nen artikel über D gelesen und das fazit war, dass die sprache kaum unterstützung von der industrie hat

solange sich das nich ändert lässt sie sich auch nur schlecht einsetzen

[CStoll]

finix schrieb:

GC, nested functions, function literals, lazy evaluation, nested classes, ... link

Hey, wo sind denn die restlichen Spalten der Tabelle geblieben? So ein Vergleich macht nur Sinn, wenn mindestens ein "Gegner" gelistet wird.

[C++ Forumbot]

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

[Gast]

Was wird eigentlich an der Syntax von D genau kritisiert? Es ist ja auf jeden Fall schon mal nicht schlecht, dass es eine kontextfreie Grammatik hat. Für Sprachen, die leicht zu parsen sind, können leicht sehr mächtige IDEs und andere Entwickler-Tools entwickelt werden und das ist für den Erfolg schon mal sehr wichtig.

Ich habe jetzt aber noch nicht selber in D programmiert, vielleicht kenne ich da ein paar unschöne Sachen noch nicht?

[asdasdasd]

D ist zwar nciht meine Lieblingssprache aber D ist meiner meinung nach gut. Auch wenn ich es nicht mehr einsetze (da es kaum externe libs dafür gibt, udn wenn doch dann in entwicklungsphase).

[sap]

darthdespotism schrieb:

Ich hab mich noch nicht näher damit befasst, aber das was ich gesehen habe wirkt wie die übliche "Sicherheitskorrektur" die ich mit C# & Java bereits bekomme, auch wenn D angeblich wieder eine Systemnahe Sprache sein soll.

Ich muss ehrlich sagen das mir "richtig kompilierte" Sprachen besser gefallen als welche die nur in Bytecode kompiliert wurden und/oder eine Virtual Maschine/Framework brauchen um laufen zu können.
- meistens laufen sie schneller
- wenn man seinen Source geheim halten will kann man das so leichter realisieren
- sie können ohne Installation und out of the box laufen (-> weniger Supportanfragen weil irgendwelche Frameworks nicht installiert sind oder Probleme machen)

Ein Nachfolger von C++ mit einheitlicherer und einfacherer Syntax wäre schon wünschenswert gewesen.

Aber D wird das wohl kaum wenn C++ Features entfernt wurden.

[groovemaster]

GPC schrieb:

Na ja, das ist nicht ganz korrekt. Ich habe in C++ noch keine Invariants, Unit Tests, Contract Programming, Scopes, Mixins und Properties gesehen.

Das läuft, wie ich bereits sagte, unter semantischem Zucker. Vom Ansatz her zwar nett, jedoch keine wirklichen Argumente für D. In Produktivumgebungen wird vieles davon sowieso kaum genutzt. Und wirklich neu ist das auch nicht. Das gibt es ebenfalls in anderen etablierten Sprachen, wenn auch nicht unbedingt immer mit builtin Support, aber zumindest konzeptionell und realisierbar. D ist sicherlich nicht schlecht, ich sehe nur keine Gründe, warum es von der Insdustrie grossartig unterstützt werden soll. Wie Konrad schon sagte, es wirkt wie ein bunter Haufen zusammengewürfelter Features ohne ein überzeugendes Konzept. Sicherlich sollte man so fair sein und der Sprache Zeit zum wachsen geben. C oder C++ haben sich auch nicht von heute auf morgen durchgesetzt. Ich fürchte nur, D hat diese Zeit nicht, und im Endeffekt wird sie der Sprache auch nicht sonderlich weiterhelfen.

[CStoll]

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

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

[Konrad Rudolph]

sap schrieb:

Ich muss ehrlich sagen das mir "richtig kompilierte" Sprachen besser gefallen als welche die nur in Bytecode kompiliert wurden und/oder eine Virtual Maschine/Framework brauchen um laufen zu können.

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. Das soll übrigens *kein* Angriff auf Dich sein, mir passiert das auch häufig, und Du hast ja durchaus auch Argumente geliefert. Trotzdem ist die Formulierung „mir gefällt …“ selten angebracht.

- meistens laufen sie schneller

Das ist so nicht mehr korrekt. Das Optimierungspotential moderner VMs ist enorm. Dass C++ nach wie vor schneller ist, liegt *nicht* an der Umsetzung in nativen Code sondern vornehmlich daran, dass durch die Templates viel Rechenaufwand an den Compiler delegiert wird, wohingegen Java und die .NET-Sprachen den Aufwand eben zur Laufzeit haben. Außerdem hat C++ teilweise einfach besser designete Datenstrukturen und spart eine Menge an Heap-Verwaltungs-Overhead.

- wenn man seinen Source geheim halten will kann man das so leichter realisieren

Auch das ist irgendwie obsolet. Geheimhaltung des Codes erreicht man heutzutage nur, wenn man nichts (auch kein Kompilat) herausgibt – mit anderen Worten, indem man den Dienst „remote“ zur Verfügung stellt, beispielsweise als WebService.

- sie können ohne Installation und out of the box laufen (-> weniger Supportanfragen weil irgendwelche Frameworks nicht installiert sind oder Probleme machen)

Hier hast Du sicherlich einen gültigen Punkt, allerdings finde ich Deployment für eine VM wesentlich einfacher. Das ist aber in der Tat eine persönliche Vorliebe, die einfach auf mangelnder Erfahrung fußt.

Ein Nachfolger von C++ mit einheitlicherer und einfacherer Syntax wäre schon wünschenswert gewesen.

Na los! Husch, husch. Und bitte mal hier schauen: http://madrat.net/caliph/

[GPC]

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.

groovemaster schrieb:

Das gibt es ebenfalls in anderen etablierten Sprachen, wenn auch nicht unbedingt immer mit builtin Support, aber zumindest konzeptionell und realisierbar.

Das ist 'n anderes Feld. "realisierbar" ist zwar vieles, aber der Aufwand dahinter ist dann was anderes

Sicherlich sollte man so fair sein und der Sprache Zeit zum wachsen geben. C oder C++ haben sich auch nicht von heute auf morgen durchgesetzt. Ich fürchte nur, D hat diese Zeit nicht, und im Endeffekt wird sie der Sprache auch nicht sonderlich weiterhelfen.

Du wirst lachen, aber ich teile diese Meinung.

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