Die Programmiersprache D

[GPC]

1 Einleitung

Vor kurzem ist Version 1.0 der Programmiersprache D erschienen. Sie steht mit ihren Konzepten (OOP, Metaprogrammierung, Contract-Programming, Garbage Collection) in direkter Konkurrenz zu C++, Java und C#. Allerdings gibt es so gut wie keine Literatur zu dem Thema, weshalb eine Evaluation der Sprache schwierig ist.

Im Rahmen meines Studiums habe ich eine Seminararbeit zu D geschrieben, die versucht einen Überblick über D zu geben. Man hätte sicherlich noch mehr schreiben können, allerdings hatte ich ein Seitenlimit zu beachten

Das Ziel der Arbeit war es, einen möglichst umfassenden Blick auf die Sprache zu werfen, um eine Bewertung zu D abgeben zu können. Diese Arbeit darf man nicht als Tutorial für Programmieranfänger verstehen, es wird oft auf Merkmale von C(++) und Java verwiesen, deren Kenntnis vorausgesetzt wird.

Das erste Kapitel der Arbeit gibt es weiter unten unter Punkt 4 direkt zum reinschnuppern. Wer dann Lust auf mehr hat, kann sich das PDF downloaden.

2 Die Arbeit

Das komplette PDF kann man hier downloaden.

3 Weitere Anlaufstellen

Sofern man Fragen zur Sprache D hat, findet man hier Antworten:

3.1 Homepage von D

http://www.digitalmars.com/d/

3.2 IRC

Netzwerk: Freenode
Channel: #D

3.3 Newsgroups

• D.gnu - GDC, the Gnu D Compiler.
• digitalmars.D - General discussion of the D Programming Language.
• digitalmars.D.announce - Announcements of new products, libraries, books, etc. on D.
• digitalmars.D.bugs - Bug reports for the D compiler and library.
• digitalmars.D.dwt - Developing the D Widget Toolkit.
• digitalmars.D.dtl - Developing the D Template Library.
• digitalmars.D.learn - Questions about learning D.

4 Einführung

4.1 Informationen und Geschichte von D

D ist eine Systemprogrammiersprache, die im Dezember 1999 von Walter Bright erfunden und am 3. Januar 2007 in der Version 1.0 freigegeben wurde. D lehnt sich von der Syntax stark an C(++) an und übernimmt auch einige Konzepte der Sprache (z.B. Templates, OOP und strukturierte Programmierung). Anderes hat man hingegen verworfen (z.B. Mehrfachvererbung, umfangreiche implizite Typkonvertierung). Ideen für D hat man auch in den Sprachen Java und C# gefunden, wobei Delegates, Template Mixins und Garbage Collection die auffälligsten Beispiele sind.
Mit D ist sowohl eine sehr moderne Programmierweise mit OOP, Design Patterns oder Metaprogrammierung als auch eine sehr systemnahe mittels Binärkompatibilität zur C-ABI und Inline Assembler möglich.
Da D noch nicht lange auf dem Markt ist, gibt es wenig Informationen zu D. Aus diesem Grund baut diese Seminararbeit auf der offiziellen D Language Specification auf, die im Moment die exaktesten Informationen zu D liefern kann.

4.2 D-Compiler

Es existieren derzeit zwei Compiler für Der offizielle Digital Mars D-Compiler (DMD) und das Frontend GNU D Compiler (GDC) für die GNU Compiler Collection (GCC). Während der DMD-Compiler nur für Windows und GNU/Linux zur Verfügung steht, existiert der freie GDC praktisch für alle Plattformen, auf denen auch eine Portierung des GCC existiert. Das umfasst z.B. *BSD, Solaris und Mac OS X.

Im Unterschied zu der Mehrheit der Compiler für andere Programmiersprachen wirft der DMD-Compiler keine Warnungen aus, sondern zeigt nur Fehler an, d.h. Warnungen werden zu Fehlern gemacht. Der Verzicht auf Warnungen resultiert daher, dass viele C-Compiler zum Beispiel sehr tolerant sind, wenn es darum geht, Pointer zu casten. In vielen Fällen erzeugt so ein Code eine Warnung, die aber vom Programmierer ignoriert wird oder aufgrund einer zu niedrigen Warnstufe einfach nicht ausgegeben wird. Da ein mit Warnungen behafteter Code aber sehr schnell zum Problem werden kann (undefiniertes Verhalten, Probleme bei Portierungen), hat man sich beim DMD-Compiler darauf festgelegt, den Programmierer mit dem Weglassen von Warnungen zur Beseitigung der heiklen Codestelle zu zwingen.

D-Code wird vom Compiler direkt in Maschinencode übersetzt, um eine möglichst hohe Ausführungsgeschwindigkeit zu erzielen.

So, weiter geht's hier

[kartoffelsack]

RAII gibts nicht, oder?

[Aprollo]

Ja, ist aber ein Problem in D.

Setzt du ne (alle zu einem Objekt) Referenz auf Null, was ja in GC-Sprachen gemacht wird, damit der GC den Speicher mal bereinigt kann, dessen Klassen RAII benutzen, kannst du nicht garantieren wie der Speicher bereinigt wird.
Es gibst zwar paar Sachen in D, die das Abfangen sollten, allerdings hat die D Gemeinde ne beliebte Tango-lib, welches nen eigenen GC-API hat und anders arbeitet kann und dewegen wird auf RAII verzichtet, damit der Code portabel bleibt.

[rüdiger]

http://www.digitalmars.com/d/archives/digitalmars/D/challenge_implement_the_max_function_47026.html

[Aprollo]

Dann hoffen wir mal, dass D 2.0 alles richten wird

[Gast]

c) preserve lvalueness when possible such that one can write e.g.

max(arr[0], arr[1]) *= 0.9;

Es ist mir echt unbegreiflich, wie man sich sowas wünschen kann. Findet ihr sowas nicht hässlich?

[Just another Coder]

Optimizer schrieb:

c) preserve lvalueness when possible such that one can write e.g.

max(arr[0], arr[1]) *= 0.9;

Es ist mir echt unbegreiflich, wie man sich sowas wünschen kann. Findet ihr sowas nicht hässlich?

also ich finde das praktisch. so kann man z.b. gleich das max. element verändern. ist doch ausserdem gut lesbar, oder?

[Gast]

Ich finde es nicht gut lesbar wenn ein Funktionsaufruf das Ziel einer Zuweisung sein kann. Es widerspricht auch total dem, was eine Funktion im mathematischen Sinne ursprünglich war.

Und wenn ich jetzt so einen Frickelcode habe und den Multithreaded machen soll, dann kann es hier ganz leicht passieren, dass ich einen üblen Seiteneffekt einfach übersehe und irrtümlich annehme, der Code sei jetzt threadsafe. Bei max() erwarte ich keine Seiteneffekte aber auch bei jeder anderen Funktion, die an sich eigentlich threadsafe wäre, kann hier was passieren, sobald das array nicht mehr exklusiv von diesem Thread benutzt wird.

Angesichts der zukünftigen Herausforderungen, die eher einen effektfreien Code nahelegen, ist so ein Programmierstil meiner Meinung nach nicht wünschenswert. Seiteneffekte sollte man nicht verstecken, sondern ganz besonders hervorheben. Das Ergebnis einer Funktion als lvalue zu behandeln versteckt Seiteneffekte und scheint mir eher eine Gelegenheit für tolle l33t-c0d0r zu sein, die damit zeigen können, wie geil kompakt sie alles ausdrücken können.

[0ptimizer]

ist doch nur gewohnheitssache. funktionen als lvalue kennt man sonst nicht, deswegen die ablehnung, ne? in C kannste z.b. eine 'max' funktion schreiben, die eine adresse zurückgibt: *max(a,b) *= 1.4;. nur ein '*' vorne dran, sonst das selbe.

[Checker*amp*Murckser]

Optimizer schrieb:

Ich finde es nicht gut lesbar wenn ein Funktionsaufruf das Ziel einer Zuweisung sein kann.

na ja,

std::vector<int> v;
// ...
v.at(10) = 10;
//...

ist halt ne Referenz

[rüdiger]

Optimizer schrieb:

Das Ergebnis einer Funktion als lvalue zu behandeln versteckt Seiteneffekte und scheint mir eher eine Gelegenheit für tolle l33t-c0d0r zu sein, die damit zeigen können, wie geil kompakt sie alles ausdrücken können.

Eine Kompakte Ausdrucksweise hat nichts mit "l33t-c0d0r" zu tun, sondern mit Lesbarkeit. Ein Beispiel aus einem Quelltext, den ich für eine Übung schreiben musste:

public void add(X x, int anzahl) {
  Integer i = data.get(x);
  if(i != null)
    anzahl += i;
  data.put(x, anzahl);
}

vs

void add(X x, int anzahl) {
  data[x] += anzahl;
}

Und das ist noch ein simpler Fall. Wenn man Seiteneffekte vermeiden will, nimmt man entweder eine funktionale Sprache oder markiert eben alles als konstant.

[Gast]

rüdiger schrieb:

Optimizer schrieb:

Das Ergebnis einer Funktion als lvalue zu behandeln versteckt Seiteneffekte und scheint mir eher eine Gelegenheit für tolle l33t-c0d0r zu sein, die damit zeigen können, wie geil kompakt sie alles ausdrücken können.

Eine Kompakte Ausdrucksweise hat nichts mit "l33t-c0d0r" zu tun, sondern mit Lesbarkeit.

Wobei diese Aussage auch wieder impliziert, dass kompakter Code lesbar ist. Und das ist so verallgemeinert einfach nur falsch.

[rüdiger]

Tim schrieb:

rüdiger schrieb:

Optimizer schrieb:

Das Ergebnis einer Funktion als lvalue zu behandeln versteckt Seiteneffekte und scheint mir eher eine Gelegenheit für tolle l33t-c0d0r zu sein, die damit zeigen können, wie geil kompakt sie alles ausdrücken können.

Eine Kompakte Ausdrucksweise hat nichts mit "l33t-c0d0r" zu tun, sondern mit Lesbarkeit.

Wobei diese Aussage auch wieder impliziert, dass kompakter Code lesbar ist. Und das ist so verallgemeinert einfach nur falsch.

Lesbar ist es definitiv. Lesbarer nicht unbedingt. Da hast du recht. Richtig formuliert wäre es wohl gewesen "Zu schreiben können, was man meint, hat nichts mit "l33t-c0d0r" zu tun, sondern mit Lesbarkeit."

[Gast]

rüdiger schrieb:

Optimizer schrieb:

Das Ergebnis einer Funktion als lvalue zu behandeln versteckt Seiteneffekte und scheint mir eher eine Gelegenheit für tolle l33t-c0d0r zu sein, die damit zeigen können, wie geil kompakt sie alles ausdrücken können.

Eine Kompakte Ausdrucksweise hat nichts mit "l33t-c0d0r" zu tun, sondern mit Lesbarkeit. Ein Beispiel aus einem Quelltext, den ich für eine Übung schreiben musste:

public void add(X x, int anzahl) {
  Integer i = data.get(x);
  if(i != null)
    anzahl += i;
  data.put(x, anzahl);
}

vs

void add(X x, int anzahl) {
  data[x] += anzahl;
}

Und das ist noch ein simpler Fall. Wenn man Seiteneffekte vermeiden will, nimmt man entweder eine funktionale Sprache oder markiert eben alles als konstant.

Dein eigentliches Problem ist hier aber ein anderes, nämlich dass du mit Integer-Objekten hantieren musst. Wenn man in Java ein int in ne Collection tun könnte sähe es so aus:

public void add(X x, int anzahl) {
  data.put(x, data.get(x) + anzahl);
}

Das ist schön kompakt und man sieht genau wo Seiteneffekte sind. Außerdem hast du in deinem Code-Beispiel beim ersten den Fall behandelt, dass ein Element nicht in der Collection ist, beim zweiten nicht. Ich habe übrigens auch nichts gegen den Index-Operator, aber er sollte nicht unbedingt eine Referenz zurückgeben, sondern einen getter und setter haben.

[rüdiger]

Optimizer schrieb:

Außerdem hast du in deinem Code-Beispiel beim ersten den Fall behandelt, dass ein Element nicht in der Collection ist, beim zweiten nicht.

doch.

[Gast]

Wieder ein toller Seiteneffekt versteckt. Sehr elitär, ich bin begeistert. (Das ist der Grund, warum der []-op einen getter und setter haben sollte)

[rüdiger]

Optimizer schrieb:

Wieder ein toller Seiteneffekt versteckt. Sehr elitär, ich bin begeistert. (Das ist der Grund, warum der []-op einen getter und setter haben sollte)

Das Beispiel drückt doch aus, was passieren soll. Die Anzahl von x wird um eine neue Anzahl "anzahl" erhöht. Falls es eben keine (0) x gibt, dann ist der Wert danach "anzahl".

Das hat nichts mit "Elitär" zu tun, sondern einfach mit Ausdrucksstärke.

[Gast]

Falls es eben keine (0) x gibt, dann ist der Wert danach "anzahl"

Das wird meiner Meinung nach in dieser Zeile überhaupt nicht ausgedrückt. Dass ein Ausdruck map[key] = value unter Umständen einen neuen Key hinzufügt finde ich akzeptabel. Man baut eine Assoziation explizit auf, egal ob es vorher schon so eine gab oder nicht. Aber in deinem Beispiel wird zuerst der Wert gelesen und dieses Lesen fügt einen neuen Wert hinzu. Das drückt dein Code aus meiner Sicht nicht aus.

Es ist auch eher Zufall, dass in diesem Beispiel so ein Verhalten wünschenswert ist. Was soll denn bei einem String ein sinvoller default-Wert für den Key sein? char* auf 0? Die map verhält sich so, weil sie nicht zwischen lesen und schreiben unterscheidet, nicht weil es irgendwie sinnvoll wäre.

[Gast]

Und "ausdrucksstark" macht das eine Programmiersprache natürlich auch nicht. Ich könnte auch die Java-Map beim getten einen neuen Key hinzufügen lassen. Zum Glück haben sie es nicht so gemacht.

[rüdiger]

Optimizer schrieb:

Falls es eben keine (0) x gibt, dann ist der Wert danach "anzahl"

Das wird meiner Meinung nach in dieser Zeile überhaupt nicht ausgedrückt.

Nur weil du viele explizite Angaben erwartest. Aber es ist imho schon sehr logisch, dass man nach Erhöhung der Anzahl um anzahl Elemente eine um anzahl höhere Anzahl von Elementen hat und dass dies auch für den Fall von keinen Elementen vorher gilt.

Aus dem Grund versucht man ja Programme abstrakt und gekapselt zu modellieren. Die Details sind unwichtig, wichtig ist, dass das erreicht wird, was man möglichst verständlich ausdrückt.

Optimizer schrieb:

Was soll denn bei einem String ein sinvoller default-Wert für den Key sein? char* auf 0?

ein leerer String und bei einem Zeiger ein Nullpointer.