Ist man mit der Programmiersprache D 2.0 anstatt C++ (C++11) schneller am Ziel?

Mal angenommen ihr würdet für beide Programmiersprachen gleich gute Compiler bekommen und die Bibliotheken & Werkzeuge, die ihr für euer Projekt benötigt, würden für beide Sprachen beidermaßen zur Verfügung stehen und das Wissen über die jeweilige Programmiersprache wäre beidermaßen gleich gut.

Hätte es dann Vorteile, D anstatt C++ für ein Projekt zu verwenden?
Die Frage zielt insbesondere auf die Frage ab, ob man mit D schneller am Ziel ist.

Aus Erfahrung kann ich jedenfalls sagen, dass ich zum Vergleich sowohl mit Java als auch mit Python schneller mit einem gegebenen Projekt fertig bin, als wenn ich das Projekt in C++ realisieren würde.
Wenn nun aber für die Aufgabe eine Programmiersprache erforderlich ist, die für die Systemprogrammierung geeignet ist, dann fallen sowohl Java als auch Python aus dem Rennen.
Typische Kandidaten wären dann C oder C++.

Aber wie wäre es mit D?
Mal angenommen das Projekt muss in einer kurzen Zeit fertig werden, weil auch das Budget eine lange Entwicklung nicht zulässt, dann würde es ja Sinn machen, eine Programmiersprache zu wählen, die die Aufgabe ebenso bewerkstelligen kann, aber die Entwicklung darin schneller ist.

Wer hat hier diesbezüglich schon einmal Erfahrungen gesammelt und kann sagen, ob man in D schneller zum Ziel kommt als mit C++?

volkard

In D bin ich jedes mal fast doppelt so schnell am Ziel, aber immer dauert es viel länger, bis ich ankomme.

Wozu die Frage, Du weißt doch bereits, was für ein Ergebnis Du als einziges zulassen willst. Behaupte doch einfach.

Gibt es für D schon so umfangreiche Bibliotheken wie Qt?

Gibt es für D richtige gute Entwicklungsumgebungen, mit autocomplete dass nicht dauernd falsche Sachen vorschlägt und besser refactored wie VAX?

Wie schnell ist der Compiler/Linker im Vergleich zu C++?

asc

Schnell ankommen schrieb:

Mal angenommen ihr würdet für beide Programmiersprachen gleich gute Compiler bekommen und die Bibliotheken & Werkzeuge, die ihr für euer Projekt benötigt, würden für beide Sprachen beidermaßen zur Verfügung stehen und das Wissen über die jeweilige Programmiersprache wäre beidermaßen gleich gut.

Hätten, wenn und aber...

D habe ich mir nur kurz angeschaut, fand die Syntax persönlich als unangenehmer als die von C++, Java und C#. Ernsthaft mit D befassen würde ich mich aber auch nur, wenn die Grundvoraussetzungen erfüllt werden - in sofern ist eine solche Annahmensituation völlig unsinnig.

Ohne das die Werkzeuge zumindest auf ähnlichen Niveau existieren, braucht man sich nicht über irgendwelche Vergleiche zu unterhalten.

asc schrieb:

Ohne das die Werkzeuge zumindest auf ähnlichen Niveau existieren, braucht man sich nicht über irgendwelche Vergleiche zu unterhalten.

Es ist natürlich eine zumindest momentan noch hypotetische Frage um allein die Sprache ansich zu bewerten.
Das ganze drumherum würde das nur verfälschen.

In Java bin ich z.B. schneller am Ziel als mit C++, nicht deswegen, weil die Tools besser sind, sondern weil die Sprache einfacher zu handhaben ist und weniger Aufwand benötigt um am Ziel anzukommen.

In Java bin ich nicht schneller am Ziel, weil die Sprache einfacher zu handhaben ist (Java ist sogar ziemmlich hässlich und inkonsequent), sondern weil es in Java ein gigantisches Angebot an Bibliothekten gibt.

Mechanics

Es kommt auch stark drauf an, was für ein Projekt man macht und inwiefern die Arbeitsumgebung vorbereitet ist. Ich bin mit C# ziemlich produktiv. Einfach, weil man sofort loslegen kann und sehr viele fertige Komponenten gibt. Bei den meisten kleinen Projekten kommt man so schnell ans Ziel. Bei C++ muss man erstmal irgendwas vorbereiten... Man braucht wahrscheinlich irgendein UI Framework (mit dem man sich auskennen muss) und evtl. irgendein Build System. Dann muss man evtl. auch Bibliotheken zusammensuchen, evaluieren und Glue Code schreiben, weil so ziemlich alle Bibliotheken im C++ Umfeld zumindest eigene String und Container Klassen verwenden.
Das kostet erstmal alles Zeit. Wenn man das nicht zum ersten Mal macht, sondern schon weiß, dass man sagen wir mal Qt verwenden will und auch weiß, wie das geht, und keine besonderen sonstigen Libs braucht, gehts schon mal schneller. Ganz so schnell wie mit .NET wirds bei kleineren mittleren Projekten aber wahrscheinlich trotzdem nicht gehen. Mit der Sprache an sich hats aber denk ich weniger zu tun... Eher vielleicht mit solchen Features, wie Reflection. Bei einem kleinen Projekt kann ein über Reflection automatischer arbeitendes ORM System + GUI Binding schon die Hälfte des Projekts ausmachen, wo man das in C++ programmieren müsste.

Ethon

asc schrieb:

D habe ich mir nur kurz angeschaut, fand die Syntax persönlich als unangenehmer als die von C++, Java und C#.

Häh? Wo sind die syntaktischen Unterschiede?

Schnell ankommen schrieb:

Mal angenommen ihr würdet für beide Programmiersprachen gleich gute Compiler bekommen und die Bibliotheken & Werkzeuge, die ihr für euer Projekt benötigt, würden für beide Sprachen beidermaßen zur Verfügung stehen und das Wissen über die jeweilige Programmiersprache wäre beidermaßen gleich gut.

Ok, ich versuche, das mal alles so anzunehmen.

Schnell ankommen schrieb:

Hätte es dann Vorteile, D anstatt C++ für ein Projekt zu verwenden?
Die Frage zielt insbesondere auf die Frage ab, ob man mit D schneller am Ziel ist.

Ich weiß nicht. Mir fällt jedenfalls under diesen Voraussetzungen auf Anbieb kein Grund ein, warum man in der einen Sprache schneller als in der anderen Sprache zum Ziel kommen sollte. Aber das muss nichts heißen. Ich bin da wahrscheinlich etwas befangen. Ich habe mich zwar mit D ein bisschen beschäftigt, aber nur soweit, um für mich die Frage zu beantworten, ob es sich denn lohnen würde, es auszuprobieren -- was ich dann im Endeffekt für mich mit einem "Nein" beantwortet habe.

Und wenn man unter diesen Voraussetzungen mit D wirklich nicht schneller ans Ziel kommen würde, würde ich mich gegen D aussprechen, weil es wahrscheinlich leichter ist, Leute zu finden, die das Projekt noch pflegen können, wenn es nicht in D gesdchrieben ist.

Ich find' die Frage aber trotzdem interessant. Eine Sprache an sich ist ja nicht schlecht, wenn der Tool-Support mager ist oder wenn sie noch nicht von genug Leuten beherrscht wird. Sie kann ja trotzdem ein gewisses Potential haben. Vielleicht schafft es ja hier noch einer, mir D schmackhafter zu machen. Ich zweifle aber dran.

Schnell ankommen schrieb:

Aus Erfahrung kann ich jedenfalls sagen, dass ich zum Vergleich sowohl mit Java als auch mit Python schneller mit einem gegebenen Projekt fertig bin, als wenn ich das Projekt in C++ realisieren würde.

Was meinst Du, woran das liegt?

Schnell ankommen schrieb:

Wenn nun aber für die Aufgabe eine Programmiersprache erforderlich ist, die für die Systemprogrammierung geeignet ist, dann fallen sowohl Java als auch Python aus dem Rennen.
Typische Kandidaten wären dann C oder C++.

Aber wie wäre es mit D?

Kommt echt auf die Anforderungen an. Habe am Wochenende erst einen Vortrag von jemandem gesehen, der sich in so einer Situation für Rust als C/C++ Alternative stark gemacht hat. D hätte mit dem nicht-determinischischen Stop-the-World-Garbage-Collector nicht zu seinen Anforderungen gepasst und C/C++ war ihm zu "unsicher".

Schnell ankommen schrieb:

Mal angenommen das Projekt muss in einer kurzen Zeit fertig werden, weil auch das Budget eine lange Entwicklung nicht zulässt, dann würde es ja Sinn machen, eine Programmiersprache zu wählen, die die Aufgabe ebenso bewerkstelligen kann, aber die Entwicklung darin schneller ist.

Wer hat hier diesbezüglich schon einmal Erfahrungen gesammelt und kann sagen, ob man in D schneller zum Ziel kommt als mit C++?

Das ist jetzt aber eine ganz andere Fragestellung. Wenn Du Dich wirklich dafür interessierst, ob D reell einsatzbar ist, dann sind eben die Dinge, die Du anfangs absichtlich ausgeschlossen oder vergessen hast (Tool-Support, wie viele Leute beherrschen die Sprache, Bibliothekenvielfalt, etc) doch sehr wichtig. Nicht?

Ich gebe mir ja Mühe, über die Java/Python/C++/Octave-Tellerränder zu gucken. Habe am Wochenende z.B. mit Rust "gespielt". Aber das, was ich über D zu wissen glaube, haut mich einfach nicht so vom Hocker, dass mir weiteres Experimentieren nicht als Zeitverschwendung vorkommen würde.

volkard

kkaw schrieb:

Kommt echt auf die Anforderungen an. Habe am Wochenende erst einen Vortrag von jemandem gesehen, der sich in so einer Situation für Rust als C/C++ Alternative stark gemacht hat. D hätte mit dem nicht-determinischischen Stop-the-World-Garbage-Collector nicht zu seinen Anforderungen gepasst und C/C++ war ihm zu "unsicher".

lölchen

"C/C++" ist ja auch unsicher, also wenn man im C++-Compiler keine C++-Idiome benutzt. Da haben wir im Forum doch schon seit vielen Jahren Konsens, daß praktisch alle C++-Kritik daraus besteht, daß man ein für C++ schon seit Jahren gelöstes Problem von C dem C++ vorwirft.

Einfach nicht drauf hören, wenn jemand was mit C/C++ beweist, auf keinen Fall ein C/C++-Buch kaufen und Stellenangebote für C/C++ müssen aufs doppelte Gehalt hinauslaufen.

Ethon

Und in D muss man keinen GC verwenden.

volkard schrieb:

kkaw schrieb:

Kommt echt auf die Anforderungen an. Habe am Wochenende erst einen Vortrag von jemandem gesehen, der sich in so einer Situation für Rust als C/C++ Alternative stark gemacht hat. D hätte mit dem nicht-determinischischen Stop-the-World-Garbage-Collector nicht zu seinen Anforderungen gepasst und C/C++ war ihm zu "unsicher".

lölchen

"C/C++" ist ja auch unsicher, also wenn man im C++-Compiler keine C++-Idiome benutzt. Da haben wir im Forum doch schon seit vielen Jahren Konsens, daß praktisch alle C++-Kritik daraus besteht, daß man ein für C++ schon seit Jahren gelöstes Problem von C dem C++ vorwirft.

Wow! Modern C++. So Safe. Much appreciated <insert doge meme image>. Jaja, weiß ich doch. Finde auch, dass C++ von noch zu vielen C Programmierern missbraucht wird, die erst noch lernen müssen, was so cool an Destruktoren ist u.s.w.. Wenigstens können wir Ressource-Lecks ausschließen, wenn jede Ressource einen Besitzer hat und der Besitz-Graph nur Wurzeln im statischen oder automatischen Speicher hat. Tolle Sache.

Aber ein strengeres Typsystem, was die in der Regel unbeabsichtigten Versuche, baumelnde Referenzen, Nullzeiger-Dereferenzierungen oder Datenrennen zu erzeugen, mit einem Compilezeit-Fehler tadelt, ist mal ein löbliches Ziel. Das muss man jetzt gar nicht runterspielen und ist auch im Vergleich zu modernem, guten C++ ein ganz anderes Level an Sicherheit. Das Ausschließen von baumelnden Referenzen ist natürlich einfach, wenn man alles auf'm Heap anlegt und dem Garbage Collector die Arbeit überlässt. Aber das ist nicht der Ansatz von Rust. In Rust hast Du typischerweise das meiste auf'nem Stack oder in einer "owned box". Und ein "owned box handle" fühlt sich so ähnlich wie ein unique_ptr an. Auch cool fand ich, dass es einer Funktion, die etwas zurück geben soll, egal ist, wo der Kram landet. Der Aufrufer entscheidet dann, ob das Objekt direkt in einer "owned box" landen soll oder direkt beim Aufrufer auf'm Stack. ... Aber ich schweife ab. Ich wollte gar nicht so viel zu Rust schreiben. Ich kenne die Sprache noch nicht gut genug, dass ich sie für etwas empfehlen könnte. Aber interessanter als D finde ich sie und das habe ich jetzt auch mal erwähnt.

volkard schrieb:

Einfach nicht drauf hören, wenn jemand was mit C/C++ beweist, auf keinen Fall ein C/C++-Buch kaufen und Stellenangebote für C/C++ müssen aufs doppelte Gehalt hinauslaufen.

Ethon schrieb:

Und in D muss man keinen GC verwenden.

Eigentlich nicht. Praktisch brauchst Du den doch. Für einen GC-losen Betrieb sei die Standardbibliothek nicht ausgelegt.

volkard schrieb:

Einfach nicht drauf hören, wenn jemand was mit C/C++ beweist, auf keinen Fall ein C/C++-Buch kaufen und Stellenangebote für C/C++ müssen aufs doppelte Gehalt hinauslaufen.

Möglicherweise hatte der Vortragende C gar nicht erwähnt, sondern nur von C++ gesprochen. "C/C++" versuche ich bewusst nur in den Kontexten zu verwenden, wo es Sinn macht, C und C++ bzgl eines bestimmten Aspekts über einen Kamm zu scheren. Lass Dich davon nicht abschrecken.

volkard

kkaw schrieb:

volkard schrieb:

Einfach nicht drauf hören, wenn jemand was mit C/C++ beweist, auf keinen Fall ein C/C++-Buch kaufen und Stellenangebote für C/C++ müssen aufs doppelte Gehalt hinauslaufen.

Möglicherweise hatte der Vortragende C gar nicht erwähnt, sondern nur von C++ gesprochen. "C/C++" versuche ich bewusst nur in den Kontexten zu verwenden, wo es Sinn macht, C und C++ bzgl eines bestimmten Aspekts über einen Kamm zu scheren. Lass Dich davon nicht abschrecken.

Ja, er hat von C++ gesprochen. Ab Minute 4:11 hat er "begründet", warum er eine Alternative braucht:

Witzbold schrieb:

NULL pointer exceptions
buffer-overruns
dangling-pointers
double-frees
memory leaks
implicit casts
nicht-initialisierte Variablen (besonders bei Klassen)

Außer den implicit casts betreffen alle Punkte nur C außer dem letzten, und der ist einfach nur Unfug.

kkaw schrieb:

Ethon schrieb:

Und in D muss man keinen GC verwenden.

Eigentlich nicht. Praktisch brauchst Du den doch. Für einen GC-losen Betrieb sei die Standardbibliothek nicht ausgelegt.

Och, darf man halt nicht die ganze Standardbibliothek nutzen. Pech gehabt.

Nee, ist klar ... ich sehe auch überhaupt keinen Mehrwert in einer Sprachen-Compiler-Kombi, die zur Compilezeit das Dereferenzieren von Nullzeigern, Buffer Overflows, Datenrennen, Speicherlecks und baumelnde Referenzen ausschließen und dabei ähnlich effizient sein will wie das, was man mit C++ hinbekommen kann. Braucht kein Schwein sowas. Ist ja nichts für "richtige Programmierer".

volkard

kkaw schrieb:

Nee, ist klar ... ich sehe auch überhaupt keinen Mehrwert in einer Sprachen-Compiler-Kombi, die zur Compilezeit das Dereferenzieren von Nullzeigern, Buffer Overflows, Datenrennen, Speicherlecks und baumelnde Referenzen ausschließen und dabei ähnlich effizient sein will wie das, was man mit C++ hinbekommen kann. Braucht kein Schwein sowas. Ist ja nichts für "richtige Programmierer".

Ich derefenziere keine Nullzeiger, habe keine buffer overflows, Datenrennen oder baumelnde Referenzen, und das sollte eigentlich normal sein, oder?

Seit dem Java- und .net-Desaster sollten wir doch wissen, was passiert, wenn man Nicht-Probleme repariert.

volkard schrieb:

kkaw schrieb:

Nee, ist klar ... ich sehe auch überhaupt keinen Mehrwert in einer Sprachen-Compiler-Kombi, die zur Compilezeit das Dereferenzieren von Nullzeigern, Buffer Overflows, Datenrennen, Speicherlecks und baumelnde Referenzen ausschließen und dabei ähnlich effizient sein will wie das, was man mit C++ hinbekommen kann. Braucht kein Schwein sowas. Ist ja nichts für "richtige Programmierer".

Ich derefenziere keine Nullzeiger, habe keine buffer overflows, Datenrennen oder baumelnde Referenzen

Du, das kommt bei mir wahrscheinlich genauso selten vor, wie bei Dir. Und trotzdem kann ich der Compilezeit-Garantie etwas abgewinnen. Ich muss aber nicht nachvollziehen können, warum Dich das anscheinend (oder scheinbar ;)) kalt lässt.

Kellerautomat

Es gibt keine brauchbaren nativen Sprachen. D hat nen GC, C ist aus der Steinzeit und C++ ist nur das geringste Uebel. Rust sieht interessant aus, steht auf meiner TODO-Liste.
Und wenn unfaehige Leute eine Sprache designen, dann kommt sowas wie Java/C#/JS/PHP/... raus.

just my €0.02

cooky451

^ What he said.