Basierend auf diesem Artikel meine Frage:
Was haltet ihr von D?

Hier gints auch noch ein Buch dazu

Marco D. hat folgendes geschrieben:

Was haltet ihr von D?

Hat ein paar nette Erweiterungen zu C++, zum Beispiel Design by Contract, was in C++ nur zu Fuß zu erledigen ist, oder Delegates mit Function Literals (erstere kann man sich auch in C++ mit Templates zusammenschustern, letztere nicht). Die Typinformation für Variadic Functions ist ein echter Vorteil gegenüber C, bei dem man ohne weiteres auch printf("%s", 6.5); übergeben kann, ohne daß printf() etwas davon mitkriegt. Genauso finde ich es sehr gut, daß Fließkommazahlen zu NaN initialisiert werden und nicht zu 0.0, etwas konsequenter wäre mir lieber gewesen, mit sinnvollen Initialisierungen für jeden Datentyp, der Initialisierungsfehler sofort sichtbar macht.

D bringt aber auch (mMn gefährlichen) Unsinn mit. D macht es beispielsweise möglich, Scopes durch mixins zu vermischen (ähnlich wie with..do in Delphi, nur noch weitergehender und somit noch gefährlicher) oder Inner Classes zu deklarieren, zu denen mit einfach kein Use-Case einfällt, zu dem man kein besseres Design findet. Daß Klassen nicht mehr automatisch freigegeben werden ist auch ein Rückschritt gegenüber C++ und macht es notwendig, ein try..finally einzuführen, das wäre nicht nötig gewesen, wenn man vorher nachgedacht hätte. Außerdem gefallen mit D-Strings nicht wirklich. + als Operator hätte es auch getan, und die Begründung, die im DM-Artikel darüber steht, ist auch etwas fadenscheinig und passt zum Rest meiner Bemängelungen, denn der einzige Grund, warum soetwas notwendig ist, ist, um nicht-sprechende Variablennamen zu unterstützen ("Wir können schlechten Code schreiben und sind stolz darauf!").

Fazit: Ein paar nette Dinge, die durchaus sinnvoll sind, aber zuviel Unsinn, der nur dazu führt, daß Leute undurchsichtigen und schlecht wartbaren Code schreiben. Die groben Designschwächen lassen mich hoffen, daß niemand auf die Idee kommt, D wirklich weit verbreitet und ausgiebig einzusetzen.

Also, ich weiß ja nicht, was ich davon denken soll...
Ich habe einmal ein wenig in dem verlinkten "D-Buch" geblättert, und finde dann da so sachen wie:

Zitat:

"Zur Zeit ist es so, das vor dem Array das Schl¨usselwort static geschrieben werden muss, wenn es initialisiert wird, dies ist aber ein Bug und wird hoffentlich irgendwann beseitigt." (S. 42)

Sowas kann man doch wirklich nicht gebrauchen!

Dann noch so sachen wie

Zitat:

import std.c.s tdarg;

oder

Zitat:

import std.stdio;

Da dreht sich mir doch der Magen um!

Und der Stringoperator ... Naja gut, das mag ja gewöhnungssache sein.

Insgesamt wirkt die Sprache auf mich ziemlich unausgereift und ein wenig im Entwurf "geschlampt" ...

Naja, meine Güte. Als hätten andere Sprachen keine Bugs...
Die Sprache wird ja weiterentwickelt. Ich selbst habe sie mir erst jetzt kurz angesehen, ich kannte die noch nicht. Aber das sieht zumindest mal interessant aus.

Ich werds mir mal eingehender ansehen. Zumindest aus Interesse, auch wenn ich mir derzeit nicht vorstellen kann, dass ich die Sprache ernsthaft benutzen werde. Aber man weiß ja nie...

Reyx hat folgendes geschrieben:

Zitat: "Zur Zeit ist es so, das vor dem Array das Schl¨usselwort static geschrieben werden muss, wenn es initialisiert wird, dies ist aber ein Bug und wird hoffentlich irgendwann beseitigt." (S. 42) Sowas kann man doch wirklich nicht gebrauchen!

Dieser Bug ist wahrscheinlich mittlerweile schon behoben.

Reyx hat folgendes geschrieben:

Dann noch so sachen wie Zitat: import std.c.s tdarg; oder Zitat: import std.stdio; Da dreht sich mir doch der Magen um!

Warum? Wäre es dir lieber, wenn es uses statt import heißen würde?

Reyx hat folgendes geschrieben:

Und der Stringoperator ... Naja gut, das mag ja gewöhnungssache sein.

Sehe ich nicht so, ist eine Prinzipsache. Eine Addition von Strings macht keinen Sinn, aber es scheint natürlich, den Additionsoperator für Stringkonkatenation zu verwenden. Das Argument, daß man die Konkatenation nicht mehr von Addition unterscheiden könne, zieht nur bei jenen, die so schlechten Code schreiben, daß sie Aufgrund der Variablennamen nicht mehr wissen, was das für ein Typ ist. Wenn ich count, i oder size als Variablenname habe, dann gehe ich nicht davon aus, daß sich dahinter ein String verbirgt, im Gegensatz zu Namen wie name, address oder caption. Schlechter Stil halt, den man versucht, mit Syntax wieder zu retten. Klappt nicht.

jaenicke hat folgendes geschrieben:

Ich selbst habe sie mir erst jetzt kurz angesehen, ich kannte die noch nicht. Aber das sieht zumindest mal interessant aus.

Das Ding ist ja schon länger in Entwicklung Ich fand es am Anfang auch interessant, aber je länger ich mir Dokumentation und Beispiele anschaue, desto abschreckender finde ich es für den täglichen Gebrauch.

tommie-lie hat folgendes geschrieben:

Reyx hat folgendes geschrieben: Ich selbst habe sie mir erst jetzt kurz angesehen, ich kannte die noch nicht. Aber das sieht zumindest mal interessant aus. Das Ding ist ja schon länger in Entwicklung Ich fand es am Anfang auch interessant, aber je länger ich mir Dokumentation und Beispiele anschaue, desto abschreckender finde ich es für den täglichen Gebrauch.

Das habe ich geschrieben, nicht Reyx

Naja, inwiefern es sich für den täglichen Gebrauch eignet, mal sehen. Aber eigentlich will ich es eben auch wirklich nur interessehalber ansehen.

tommie-lie hat folgendes geschrieben:

Daß Klassen nicht mehr automatisch freigegeben werden ist auch ein Rückschritt gegenüber C++

Das geht doch mit auto, oder nicht? Seite 108 im Buch. Ich glaube auto entspricht der Instanzierung wo die Daten auf dem Stack landen (static allocation) und ohne auf dem Heap (dynamic allocation mit der ganzen Pointergeschichte in C++); ist aber nur Spekulation.
Ich finde es irgendwie positiv, dass im ganzen Buch nie die Rede von Pointer ist Pointer nightmares à la C++ ade!

tommie-lie hat folgendes geschrieben:

Reyx hat folgendes geschrieben: Dann noch so sachen wie Zitat: import std.c.s tdarg; oder Zitat: import std.stdio; Da dreht sich mir doch der Magen um! Warum? Wäre es dir lieber, wenn es uses statt import heißen würde?

Nein, nicht das Schlüsselwort bemängel ich hier, sondern die Benennung.
Wir suchen im Standard-Namespace, dort dann die "Standard-Ein- und Ausgabe". Doppelt und Dreifach std. Das mag jetzt spitzfindig klingen, aber mich stören solche Kleinigkeiten doch, da sie mir einfach das Gefühl geben, beim Entwurf der Sprache hätte man nicht lange über Benennungen nachgedacht.

Was das mit dem static betrifft: Wie kann eine "Sprache" einen Bug haben? Wohl eher eine Implementation eines Compilers! Ich darf also davon ausgehen, dass es nur einen D-Compiler gibt? -> Schlecht!

@jaenicke: Sorry, ist gefixt

Reyx hat folgendes geschrieben:

Nein, nicht das Schlüsselwort bemängel ich hier, sondern die Benennung. Wir suchen im Standard-Namespace, dort dann die "Standard-Ein- und Ausgabe". Doppelt und Dreifach std. Das mag jetzt spitzfindig klingen, aber mich stören solche Kleinigkeiten doch, da sie mir einfach das Gefühl geben, beim Entwurf der Sprache hätte man nicht lange über Benennungen nachgedacht.

Hm, stimmt schon, std.io wäre sinnvoller gewesen, aber hier scheinen sie sich etwas dabei gedacht zu haben:

Phobos-Doku zum std.stdio-Namespace:

Standard I/O functions that extend std.c.stdio. std.c.stdio is automatically imported when importing std.stdio.

Es gibt also wenigstens eine Begründung dafür, nämlich die Erweiterung der C-Bibliothek. Und neben std.stdio und std.stdint findest du auch keinen anderen Namespace, der std.std* heißt, die anderen Namespaces tragen sinnvolle Namen. Bei stdint wollte man, laut Doku, kompatible zu stdint.h aus der C-Bibliothek sein, daher wohl auch hier wieder der Name.
Und die Benennung in std.c.* rührt von der C-Standardbibliothek her, dort ist nunmal stdio.h der Header, der für den Standard-I/O zuständig ist, genauso wie string.h, time.h, stdarg.h und die ganzen anderen Namespaces in std.c.

Reyx hat folgendes geschrieben:

Ich darf also davon ausgehen, dass es nur einen D-Compiler gibt? -> Schlecht!

Zwei, es existiert ein GCC-Frontend. Inwiefern das den gleichen Lexer und Parser wie DMD benutzt, weiß ich nicht.

delfiphan hat folgendes geschrieben:

tommie-lie hat folgendes geschrieben: Daß Klassen nicht mehr automatisch freigegeben werden ist auch ein Rückschritt gegenüber C++ Das geht doch mit auto, oder nicht? Seite 108 im Buch. Ich glaube auto entspricht der Instanzierung wo die Daten auf dem Stack landen (static allocation) und ohne auf dem Heap (dynamic allocation mit der ganzen Pointergeschichte in C++); ist aber nur Spekulation.

Schönes Beispiel, die File-Klasse von Phobos ist *mist*e. Ressourcen haben niemals vom Client-Code freigegeben zu werden, sondern immer durch denjenigen, der die Ressource repräsentiert. Der Destruktor von File hat dafür zu sorgen, daß die Datei geschlossen wird.
Aber das Schlüsselwort, um ein Objekt auf dem Stack anzulegen, lautet scope. Eine Variable mit dem Modifier scope verhält sich wie ein C++-Objekt.
auto hat laut DM-Dokumentation nichts damit zu tun. auto ist lediglich für Type Inference interessant. Fragt sich nur, was aktueller ist, das Buch oder die DM-Doku.

Nachtrag: In einer Mail vom 17.11.2006 meint Bill Baxter, daß auto nun scope heißt. Vorher hatte auto zwei Bedeutungen. Bei auto var = 5 bedeutete es, daß für var type inference benutzt werden soll. Bei auto Type var = new Type() bedeutete es, daß die Klasse automatisch beim Verlassen des Scopes deinitialisiert wird. Diese Mehrdeutigkeit scheint also irgendwann Anfang November aus dem Weg geräumt worden zu sein, scope ist jetzt der Modifier für RAII und auto der für type inference.
Fragt sich nur noch, warum sie dann meinten, daß finally eine tolle Idee sei...

delfiphan hat folgendes geschrieben:

Ich finde es irgendwie positiv, dass im ganzen Buch nie die Rede von Pointer ist Pointer nightmares à la C++ ade!

C++ und Pointer? Wo?
Und es gibt auch in D Pointer, die scheinen nur in diesem Buch nicht erwähnt zu werden.

tommie-lie hat folgendes geschrieben:

C++ und Pointer? Wo?

Die Frage ist nicht ernst gemeint, oder?
Oder du hast nie mit C++ gearbeitet ...

Reyx hat folgendes geschrieben:

tommie-lie hat folgendes geschrieben: C++ und Pointer? Wo? Die Frage ist nicht ernst gemeint, oder? Oder du hast nie mit C++ gearbeitet ...

Doch, deswegen ja. Wenn man class * als Objektreferenzen ansieht, kommst du in C++ komplett ohne Pointer aus, die wirklich als Pointer benutzt werden. In Delphi gilt das gleiche.

Ja wenn man Pointer als Referenz sieht, dann gibt es statt Pointer nur noch Referenzen * is Pointer und & ist Referenz.

[rant]Spass beiseite. Was ich einfach nicht leidern kann sind Sachen wie (*((char*)data))++ (<- das geht ja noch). Ich mag die Sternchen und Pfeilchen nicht mehr sehen... C++ ich einfach extrem unelegant... Eine Sprache fuer Bastler ... Jede Library macht aus allen primitiven Datentypen seine eigenen Typedefs. Die Makros und die manuellen Abfragen, ob eine Header-Datei bereits included worden ist muss ich ja nicht mehr erwaehnen... Beinahe vergessen: &&, dass die meisten Compiler "a<b<int>> x" ! verstehen, weil >> der Right-Shift Operator ist, finde ich noch amuesant. [/rant]

delfiphan hat folgendes geschrieben:

Ja wenn man Pointer als Referenz sieht, dann gibt es statt Pointer nur noch Referenzen * is Pointer und & ist Referenz.

Nein, man braucht in der Regel keine Pointer auf etwas anderes als Klassen. Uns selbst diese braucht man nicht unbedingt in C++. Die Stnadardcontainer decken nahezu alles ab, sind getestet, haben wohldefiniertes Verhalten und nötigen dich nicht dazu, im Client-Code noch Pointer zu benutzen.

delfiphan hat folgendes geschrieben:

Spass beiseite. Was ich einfach nicht leidern kann sind Sachen wie (*((char*)data))++.

Geschmackssache, immerhin ist es wohldefiniert und jeder weiß, was da steht. Aber typsicher ist das ohnehin nicht, und somit auch nicht wirklich schöner C++-Code.

delfiphan hat folgendes geschrieben:

C++ ich einfach extrem unelegant... Eine Sprache fuer Bastler ...

Da gibt es nichts zu basteln, wenn man weiß, was man tut.

delfiphan hat folgendes geschrieben:

Jede Library macht aus allen primitiven Datentypen seine eigenen Typedefs.

Und das ist auch gut so. Wer an size_t und Genossen etwas auszusetzen hat, hat nicht wirklich verstanden, wie man portablen Code schreibt.

delifphan hat folgendes geschrieben:

Die Makros und die manuellen Abfragen, ob eine Header-Datei bereits included worden ist muss ich ja nicht mehr erwaehnen...

Doch, denn diese Abfragen sind freiwillig und nur dazu da, Compile-Zeit zu sparen. Man verfängt sich nur in Endlosschleifen, wenn man zirkuläre Includes drin hat, aber die machen in Delphi ebenfalls Probleme.

[OT in OT]Ja, es ist wohldefiniert; wenn man portablen Code schreiben will geht's halt nicht anders; ifdefs freiwillig um Compile-Zeit zu sparen; um Endlosschleifen beim Compilieren aus dem Weg zu gehen; die ganzen Makros. Man macht es halt so... Ich sag nur, dass es unelegant ist. Für mich ist das ein Gebastel. Geschmackssache