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



  • 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.



  • 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.



  • 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.



  • 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". 🙄



  • 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.



  • 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



  • ^ What he said.



  • Es gibt überhaupt keine brauchbaren Programmiersprachen. Es gibt nämlich keine brauchbaren Computer. Denn wenn ich jemanden erst noch sagen muss wie er etwas tun soll, dann ist er unbrauchbar 🙂



  • Ich glaube du verstehst nicht ganz, das ist schon ziemlich ernst gemeint.



  • Ich glaube du verstehst nicht ganz, das war überhaupt nicht ernst gemeint. (Darum der Smiley)



  • Kellerautomat schrieb:

    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

    Sarkasmus?



  • Ethon schrieb:

    Kellerautomat schrieb:

    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

    Sarkasmus?

    Noe.



  • Dann versteh ich nichtmal im Ansatz wie man sich über den GC von D beschweren kann. Man muss ihn absolut nicht benutzen aber wenn man will dann ist er ein Geschenk des Himmels.
    Dem Argument fehlt in meinen Augen jeder Boden.

    Lehnst du ein geschenktes Auto ab wenn es ein Navi hat aber du kein Navi brauchst weil du den Weg auch so findest?



  • Ethon schrieb:

    Dann versteh ich nichtmal im Ansatz wie man sich über den GC von D beschweren kann. Man muss ihn absolut nicht benutzen aber wenn man will dann ist er ein Geschenk des Himmels.
    Dem Argument fehlt in meinen Augen jeder Boden.

    Lehnst du ein geschenktes Auto ab wenn es ein Navi hat aber du kein Navi brauchst weil du den Weg auch so findest?

    Erstens wurde schon das Argument genannt, dass die D stdlib ohne GC nur beschraenkt benutzbar ist, zweites habe ich noch nie das Verlangen nach einem GC gespuert.

    Ums mal auf deine Analogie zu uebertragen: Das Navi kann ich einschalten wenn ichs brauche. Ein Navi, das sich nicht ausschalten laesst und dauernd irgendwas ansagt wuerde ich definitiv wegwerfen. Und wenn das Navi ins Auto eingebaut ist, dann auch das Auto!



  • Kellerautomat schrieb:

    zweites habe ich noch nie das Verlangen nach einem GC gespuert.

    Ich habe auch noch nie das Verlangen nach Templates gespürt, bis ich C++ kennen gelernt habe.


Anmelden zum Antworten