Die Programmiersprache D
-
So, ich grabe den Thread mal aus.
Habe ne Weile D programmiert und es scheint eine eierlegende Wollmilchsau zu sein. Für jedes Problem gibt es eine verdammt elegante Lösung.
D lässt in meinen Augen C++ komplett im Regen stehen.Warum interessiert sich kein Schwein für D?
-
Vorweg: Ich habe in D noch nie programmiert.
D sieht mir in vieler Hinsicht sehr schön aus. Im Grunde finde ich, dass D so ist, wie C++ sein sollte, mit nur einem großen Nachteil: Der Garbage-Collector.
-
Marthog schrieb:
Vorweg: Ich habe in D noch nie programmiert.
D sieht mir in vieler Hinsicht sehr schön aus. Im Grunde finde ich, dass D so ist, wie C++ sein sollte, mit nur einem großen Nachteil: Der Garbage-Collector.
Für viele Einsatzfälle halte ich den GC für einen großen Vorteil.
In b4 Kernel/Embedded.
-
Ich hab mich schon lange nicht mehr mit D beschäftigt.. aber zumindest zum Zeitpunkt, als ich dieses Arbeit geschrieben hab, war es halt so:
- Es macht vieles besser als C++, aber nur etwas und nicht bahnbrechend
- Die Unterstützung durch bedeutende Hersteller (z.B. Microsoft) hat gefehlt und es gab kaum wirklich gute Tools, Libraries etc. Die komplette Infrastruktur hat gefehlt.
-
Ethon schrieb:
Für viele Einsatzfälle halte ich den GC für einen großen Vorteil.
Ich finde die Argumente ja ganz vernünftig, aber will den gc nur als Alternative, also z.B. so dass der gc nur mit einer Extension genutzt wird oder man ihn nur mit bestimmten pointern nutzen kann, also quasi Unterschied zwischen new und gcnew.
-
Marthog schrieb:
Ethon schrieb:
Für viele Einsatzfälle halte ich den GC für einen großen Vorteil.
Ich finde die Argumente ja ganz vernünftig, aber will den gc nur als Alternative, also z.B. so dass der gc nur mit einer Extension genutzt wird oder man ihn nur mit bestimmten pointern nutzen kann, also quasi Unterschied zwischen new und gcnew.
Konkretes Beispiel aus dem echten Leben in dem du keinen GC möchtest?
-
Ethon schrieb:
Marthog schrieb:
Ethon schrieb:
Für viele Einsatzfälle halte ich den GC für einen großen Vorteil.
Ich finde die Argumente ja ganz vernünftig, aber will den gc nur als Alternative, also z.B. so dass der gc nur mit einer Extension genutzt wird oder man ihn nur mit bestimmten pointern nutzen kann, also quasi Unterschied zwischen new und gcnew.
Konkretes Beispiel aus dem echten Leben in dem du keinen GC möchtest?
Immer, wenn ich keinen brauche. Ich mag jetzt nicht 99.999% aller Programmieraufgaben auflisten.
-
Immer, wenn ich keinen brauche. Ich mag jetzt nicht 99.999% aller Programmieraufgaben auflisten.
Und der Grund dafür ? Wenn du was wirklich performancekritisches machst kannst du ihn ja immernoch abschalten...
Aber wozu freiwillig mehr Arbeit machen als nötig ?
-
DarkShadow44 schrieb:
Immer, wenn ich keinen brauche. Ich mag jetzt nicht 99.999% aller Programmieraufgaben auflisten.
Und der Grund dafür ? Wenn du was wirklich performancekritisches machst kannst du ihn ja immernoch abschalten...
Aber wozu freiwillig mehr Arbeit machen als nötig ?Mehr Arbeit?
Ich habe mit javaeskem GC und verspäteten Destruktoren *deutlich* mehr Arbeit als mit sofort zuschlagenden Destruktoren wie in C++/Perl.
Wenn der GC hingegen nur für den Speicher zuständig ist und hinter sofort zuschlagenden Destruktoren herräumt, ist es kein Unterschied.
Ich sehe nirgends mehr Arbeit beim Verzicht auf GC (außer vielleicht diesem Fall mit den lock-free queues).
-
Und selbst da ist es fraglich ob malloc/free Speicherverwaltung schneller ist.
-
Ethon schrieb:
Und selbst da ist es fraglich ob malloc/free Speicherverwaltung schneller ist.
Dann läßt man den Code wie gehabt, macht free wirkungslos und tut einen GC nur für den Speicher drunter, siehe "Wenn der GC hingegen nur für den Speicher zuständig ist und hinter sofort zuschlagenden Destruktoren herräumt"
Also MS schreibt auf manchen Seiten, der GC viel schneller ist und (oh, wie toll ist .net!), auf anderen, daß man den Quatsch aufgibt (wegen Handys erstmal) weil viel zu lahm (oh, wie untoll ist .net!). Wem glaubst Du mehr, MS oder MS?
-
Deinen eigenen Allokator kannst du doch trotzdem schreiben? Verbietet dir ein GC ja nicht, dem ist ja egal was mit dem Speicher passiert den er dir gibt.
Das Argument mit den Destruktoren finde ich auch komisch.
Viele Destruktoraufrufe fallen sowieso weg nachdem Destruktoren nicht mehr für die Speicherfreigabe verwendet werden.
Bei vielen anderen ist es egal wann die Destruktoren aufgerufen werden.
Und sollte das mal nicht egal sein (was wohl sehr selten sein sollte) kann man immer noch mit scope(exit) dafür sorgen dass am Ende des Scopes zerstört wird.