Freizeit in D investieren?

Freizeit in Damen investieren ist besser ;-)

Superfast — Sun, 20 May 2007 10:24:16 GMT

Re(2): Freizeit in D investieren?

Xmolch — Sat, 19 May 2007 21:58:18 GMT

Die großen Firmen haben keine unwesentliche Rolle darin gespielt ihre Sprachen zu etablieren, da geb ich dir Recht. Obwohl, bei Microsoft ist es nicht sehr verwunderlich, dass sich C# weit verbreitet hat.

Durch wunderbare Features allein wird sich eine Sprache zwar nicht durchsetzen, aber ohne diese wird sie von vornherein keine Chance haben. Meiner Meinung nach hat D großes Potential und dafür dass es ein Ein-Mann-Projekt ist hat es sich bisher tapfer geschlagen. Wir reden hier von Walter Bright, der Mann der den ersten nativen Compiler für C++ geschrieben hat, der direkt zu Maschinencode übersetzte und nicht zuerst zu C. Ich finde nicht, dass man sein Projekt als hoffnungslos abtun sollte, nur weil es schon genug Programmiersprachen gibt oder weil nichts C/C++/Java ablösen kann. Wenn jemand die Unzulänglichkeiten von C++ am besten kennt, dann ist das mit Sicherheit Walter Bright (und Bjarne Stroustrup wahrscheinlich auch ). Er hat sich damit nicht zufrieden gegeben und eine hervorragende Alternative erschaffen. C++ ist hoffnungsloch überaltet, und ich werde mit Sicherheit nicht darauf warten, dass das C++-Kommitee irgendwann im Jahre 2009 minimale Verbesserungen bringen wird. Bis dahin ist D 2.0 schon fertig und um Welten besser sein als es so schon ist (zugegeben, ein paar Kinderkrankheiten hat D noch aber die halten mich nicht ab die Sprache zu verwenden und zu lieben.)

Re: Freizeit in D investieren?

komplexler — Sat, 19 May 2007 21:29:23 GMT

Meiner Meinung nach sind die Features der Sprache selbst an sich nicht so wichtig, es geht viel mehr um die Unterstützung durch die Industrie (solange nicht gerade ein neues Paradigma erfunden wird).
Und da haben die etablierten Sprachen wie C++, C# und Java nun mal einen gewaltigen Vorteil... Wenn es also um "Verwertbarkeit" gehen soll, ist D wohl nicht so sinnvoll, sonst kann es durchaus interessant sein.

Re(2): Freizeit in D investieren?

Xmolch — Sat, 19 May 2007 21:22:48 GMT

Ich möchte mal ein paar Dinge klar stellen: dein Freund verwechselt "scope" mit dem Schlüsselwort "auto". "scope" ist dafür zuständig, dass eine Klasse automatisch destruiert wird wenn eine Variable den Gültigkeitsbereich verlässt (scope wird außerdem für scope guards verwendet.) "auto" ist dazu da den Typ einer Variable aus der Initialisierung anzunehmen (sehr nützlich bei langen Klassennahmen oder Templates.)

Ich demonstriere mal diese Features:


import std.stdio;

scope class Foo // Klasse Foo als scope markieren
{
  int a;
  this(int a)
  {
    this.a = a;
  }
  ~this()
  {
    writefln("~Foo.a=", a);
  }
}

class Foo2
{
  ~this() // Wird durch GC aufgerufen
  {
    writefln("~Foo2");
  }
}

void main(char[][] args)
{
  auto variable = new Foo2(); // auto nimmt den Typ vom Ausdruck zur rechten Seite an.
  // delete variable; // Objekt sofort löschen, andernfalls dem GC überlassen.
  variable = null; // Nicht wirklich nötig.

  scope Foo foo2 = new Foo(2);
  //Foo foo2 = new Foo(2); // Error: variable foo2 reference to scope class must be scope

  { // Neuen Bereich erschaffen
    scope Foo foo1 = new Foo(1);
  } // foo1 wird hier zerstört

} // foo2 wird hier zerstört

// Ausgegeben wird:
~Foo.a=1
~Foo.a=2
~Foo2

Re(2): Freizeit in D investieren?

Xmolch — Sat, 19 May 2007 20:41:27 GMT

Hier noch eine Linksammlung für Interessierte:

Webseiten:
dsource: Ähnlich wie sourceforge.net. Beherbergt die meisten und wichtigsten D-Projekte.
Programming in D for C Programmers: Einführung in D für C-Programmierer.
Programming in D for C++ Programmers: Einführung in D für C++-Programmierer.
Computer Language Shootout Benchmarks: Geschwindigkeitsvergleich zwischen verschiedenen Sprachen in verschiedenen Gebieten.

Werkzeuge:
GDC: D-Compiler für GCC.
DSSS: DSSS, the D Shared Software System, builds upon rebuild and intends to create a standardized system for building, installing, configuring, acquiring and using D software.
descent: Ein Eclipse-Plugin, das noch nicht sehr brauchbar ist. Es ist eine Portierung des DMD-Frontends zu Java-Code, was eine ausgezeichnete *TRÖT*setzung für Intellisense und Refactoring-Tools ist.
bcd: Ein automatischer Generator für Bindungen zwischen C/C++ und D.

Bibliotheken:
DDL: Unterstützt das dynamische Laden von Bibliotheken, weit über das hinaus, was DLLs und SOs anbieten.
wxD: wxWidgets-Bindungen für D.
bcd: Beinhaltet FLTK2-Bindungen für D.

Spiele:
ShortHike: 3D-Simulation von Raumstationen. Früher kommerziell, jetzt quelloffen und von C++ nach D portiert.
Bosskoneun: Quelloffenes Asteroids (bescheuerte Steuerung aber der Code sollte interessanter sein).

IRC:
Einen Kanal gibt es auf irc.freenode.net:6667 unter #D.

Re: Freizeit in D investieren?

Xmolch — Sat, 19 May 2007 20:36:43 GMT

Hallo Arrris,

Kommt drauf an wo du derzeit mit deinen Erfahrungen in Sachen Programmierung stehst. Ansich ist D ein ausgereiftes Produkt eines Compilerexperten, der bei der 7-jährigen Entwicklung die Wünsche der Community oft zu Herzen genommen hat, aber es gibt leider noch wenige D-eigene Bibliotheken. In diesem Punkt sieht es etwas blass aus im Vergleich zu Java, C# und C++. Die Sprache selbst ist schon geeignet richtig große Programme zu schreiben, und das viel besser als C/C++ (wenn man nicht unbedingt masochistisch ist.) Erst vor kurzem hab ich in den D-Newsgroups gelesen, dass ein Studententeam in einem universitären Programmierwettbewerb den 2. Platz errungen hat; sie hatten ein Spiel "Deadlock" in D programmiert, das mehr als 70000 Zeilen hatte. Das ist nur ein Beispiel von vielen. D ist schon lange kein unbedeutsames Ein-Mann-Projekt mehr. Es wird sogar von Andrei Alexandrescu unterstützt, ein Mitglied des C++-Kommitees soweit ich weiß.

Ich hab schon viele Skeptiker erlebt, die sich Nase rümpfend negativ über D geäußert haben, ohne mal wirklich sich die Zeit genommen zu haben die Sprache für ein paar Stunden genau zu studieren. Das sind für gewöhnlich jene Leute, die in ihrer Meinung schon festgefahren sind oder sie haben einfach schon zu viel Zeit und Geld in das Studium einer Sprache wie Java od. C++ gesetzt, dass es sie zu viel Überwindung kostet was neues anzufangen. Für die fährt der Zug nur noch in eine Richtung, und es gibt kein zurück... Es gibt aber auch die Ausnahmen, das sind meintens jene, denen die Unzulänglichkeiten von C++ od. Java schon zum Hals raushängen, und deswegen nach einer besseren Alternative Ausschau halten.

Meiner Meinung nach macht D einige Dinge besser als die derzeit etablierten Sprachen. Ich streiche mal heraus welche Eigenschaften von D mir zusprechen:

D hat eine kontext-unabhängige Grammatik. Das macht das Parsen von Sourcecode unheimlich schnell und die Implementierung eines D-Parsers ungemein einfach.

D hat volle Unicodeunterstützung. Niemand will sich mehr mit Codepages herumschlagen und es ist eine gute Sache für internationalisierte Applikationen.

D ist zwar nicht sourcekompatibel mit anderen Sprachen, aber man kann direkt zu C-Code linken (man muss nur die C-Headerdateien nach D konvertieren.) Direkte C++-Unterstützung wird es nie geben, da das einen kompletten C++-Compiler erfordern würde (Walter Bright sagte mal, dass er ca. 10 Jahre benötigte um einen C++-Compiler zu schreiben, der dem Standard entsprach). Man muss sich also einem C-Layer bedienen oder das COM-Feature von D verwenden.

Code wird nativ zu Objektdateien kompiliert und er ist mindestens genauso schnell wie C/C++. Man ist nicht abhängig von einer virtuellen Maschine.

Es gibt einen integrierten Garbagecollector. Den kann man sich in C++ zwar mühselig selbst installieren, aber wenn man über die Grenzen des eigenen Programmes Speicher weitergeben will, wird es knifflig (zugegeben: ich hab keine Erfahrung mit GC & C++, hab ich nur so gehört.) Wer denkt ein GC hat in einer systemnahen Sprache nichts zu suchen, der irrt. In zeitkritischem Code (wie Spiele oder Steuerung von Geräten) alloziert man den ganzen Speicher den man benötigt ohnehin schon von vornherein, malloc() & Co sind da genauso undeterministisch wie ein GC. In D kann man den GC selbst steuern, also für eine Zeit lang deaktivieren od. eine Aufräumung erzwingen (z.B. wenn ein Spieler mal Pause gedrückt hat.) Man kann natürlich auch weiterhin seinen Speicher explizit selbst verwalten mit malloc(), und mit dem Schlüsselwort scope kann man auch Klassen auf dem Stack allozieren und automatisch bei Scopeende zerstören lassen (RAII.) D lässt einem also völlig freie Hand was Speichermanagement angeht.

Statt der Trennung zwischen Headerdateien und Quelltexten gibt es Module, wie in Java. Wenn man seine Bibliotheken nicht mit ganzem Sourcecode ausliefern kann, dann kann man D-Interfacedateien generieren (*.di), die nur Deklarationen und inline-Funktionen enthält. Manche halten Headerdateien für eine gute Übersicht, aber das denke ich nicht. Es ist völlig unnötig zwei Dateien verwalten zu müssen, wenn es eine einzige mit Dokumentationskommentaren auch tut (die mit Ddoc oder doxygen extrahiert werden können.)

Templates sind um Welten besser als bei C++.

Design by Contract, Unittests, scope guards...

Manche würden jetzt bestimmt einwenden, dass sie all diese Sachen schon in ihrer eigenen Lieblingssprache haben, oder dass sie manche Features nicht benötigen. Schön für euch.Für mich vereint D einfach alle Dinge, die das Programmieren äußerst bequem und zu einem Genuss machen. Es sind die vielen kleinen Dinge in einer Sprache, die entscheiden ob es Freude macht mit ihr zu programmieren, oder nicht. Java mag ich nicht, wegen der VM. C# mag ich nicht wegen Microsoft. Als Scriptsprache verwende ich Python, aber damit kann man keinen performanten Code schreiben. D ist einfach genau das, was C++ eigentlich hätte werden sollen.

Re: Freizeit in D investieren?

nergal — Sat, 19 May 2007 18:59:43 GMT

Die Meinung von einem Freund von mir zum Thema D - ich habe die E-Mail mal ausgegraben:

Mein Freund schrieb:
Ich habe ja voriges Jahr einige Zeit lang mit "D" gearbeitet.

Allerdings habe ich es dann wieder aufgegeben, weil ich einen
gravierenden Mangel entdeckt hatte: Zwar *gibt* es Destruktoren wie in C++, d. h. welche die nicht von der Garbage Collection aufgerufen werden, sondern wenn der jeweilige Scope verlassen wird.

Das macht es auch in D grundsätzlich möglich, "intelligente" Objekte wie "Filehandle" zu definieren, welche die zugrunde liegende Datei
automatisch mit "Close" schließen, sobald der Gültigkeitsbereich
verlassen wird in dem das Objekt definiert ist.

Dieses Destruktoren-Feature ist insbesondere, aber nicht nur in
Verbindung mit Exception-Handling sinnvoll, um dafür zu sorgen dass alle Ressourcen zur rechten Zeit wieder aufgeräumt werden.

In JAVA muss man in solchen Fällen ja manuell einen "close"-Aufruf in den "finally"-Handler schreiben, sonst bleibt die Datei offen bis die GC irgendwann (spätestens bei Programmende) geruht, den Destruktor aufzurufen welcher die Datei (hoffentlich) ebenso schließen wird.

Jedoch ärgert es mich, sinnlos ständig irgendwelche Dinge in
"finally"-Handler hinschreiben zu müssen, die ein Destruktor unter C++ automatisch tut.

Ich sehe das Fehlen von zu definierten Zeitpunkten aufgerufenen
Destruktoren jedenfalls als die größte Schwäche von JAVA an, die ich
bisher kenne.

Perl hat hier einen Zwischenweg gewählt: Es ruft die Destruktoren genau wie C++ auf sobald der Scope verlassen wird - jedoch nur wenn keine weiteren Referenzen auf ein Objekt mehr bestehen. In diesem Fall wird der Destruktor dann aufgerufen, sobald die letzte Referenz aufgelöst wurde.

Und nur wenn das Programmende erreicht wird und immer noch Referenzen bestehen, wird eine Art Garbage Collection ausgelöst welche alle Objekte zwangsweise freigibt.

D hingegen unterstützt beide Ansätze: Defaultmäßig arbeitet es wie JAVA, also GC und verzögerter Destruktorenaufruf.

Wenn man jedoch eine Objekt-Variable explitit als "auto" deklariert,
dann wird auf das Objekt auf welches diese Variable verweist die C++ Methode angewendet.

D. h. sobald der Gültigkeitsbereich der Variable verlassen wird, wird
der Destruktor aufgerufen und das Objekt zerstört. OHNE warten auf die GC.

Das beste beider Welten...

...so dachte ich.

Bis ich drauf kam: Das funktioniert zwar - aber nur, wenn man das "auto" JEDESMAL zu JEDER Deklaration einer Variable dazuschreibt!

Sprich, man kann das "auto" nicht etwa zur Klassendefinition dazu
schreiben - damit jedes Objekt dieser Klasse sich immer nach der C++ Semantik verhält.

Statt dessen kann man, wann immer man eine Referenzvariable für ein Objekt einer Klasse irgendwo anlegt, "auto" dazu schreiben, oder nicht.

Und es gibt auch keinerlei Compiler-Warnung, wenn man etwa an einer Stelle für eine Objektvariable "auto" dazuschreibt, und ein paar Zeilen später für eine zweite Objektvariable DERSELBEN Klasse *nicht*.

Statt dessen bekommt man einfach 2 Objektvariablen für Objekte derselben Klasse, die ein völlig unterschiedliches Destruktoren-Verhalten aufweisen!

Sprich, wenn man irrtümlich irgendwo "auto" hinzuschreiben vergisst, wird man nicht gewarnt sondern das Programm verhält sich einfach anders als man es erwarten würde.

Ich fand das einen himmelschreienden Wahnsinn!

Denn wie leicht kann man einmal "auto" hinzuschreiben vergessen. Und es wird keinen Fehler geben, und das Programm wird immer noch oft genug funktionieren, da die GC doch rechtzeitig genug daher kam bevor es Probleme gab.

Nur ist so etwas eben total unsicher - man schreibt Programme, wo
tickende kleine Zeitbomben schlummern, und ohne es zu merken; nur weil man irgendwo "auto" hinzuschreiben vergessen hat.

Besonders teuflisch ist dabei der Umstand, dass man das "auto" ja nicht für alle, sondern nur für bestimmte Klassen verwenden will.

Man kann sich daher nicht "von Haus aus" daran gewöhnen, immer ein "auto" hinzuschreiben, weil man das eben nicht immer haben will.

Na jedenfalls - solange D diesen Blödsinn nicht abschafft, ist es
unbrauchbar.

Weil dann kann ich gleich JAVA nehmen, da schreibe ich statt "auto" halt einen "finally"-block. Und habe dafür den Vorteil einer in langjährigem Praxiseinsatz erprobten Sprache mit umfangreichen Bibliotheken und Benutzerbasis.

Nein, wenn D gegen JAVA oder C++ anstinken will, dann muss es schon *besser* sein als beide, und nicht nur deren Nachteile kombinieren...

Re: Freizeit in D investieren?

Somnatic — Sat, 19 May 2007 13:22:08 GMT

Uninteressant

Freizeit in D investieren?

Arrris — Sat, 19 May 2007 08:57:06 GMT

Würdet ihr es für "sinnvoll" halten, wenn man seine Freizeit derzeit in die "neue" Programmiersprache D investiert? Oder wäre eine andere besser/einfacher zu erlernen?

Welche würdet ihr bevorzugen / empfehlen?