Gebt doch endlich mal richtige Gründe gegen die Sprache D an!

Zeus schrieb:

Vor einem Jahr wurde beschlossen, dass Sie in eine Koexisten gehen wollen. ^^

@D-Profi
Du redet von Änderung des Programmierparadigmas. Was zur Hölle willst du Objective C?

Diese Frage kann ich dir nicht beantworten, zuerst will ich, dass du mir die Frage erneut stellst, diese mal jedoch auf Deutsch, bitte!
Dann kann ich versuchen dir die Frage zu beantworten.

DEvent

D-Profi schrieb:

Ruby hat sich auch nur so schnell so stark durchsetzen können durch RubyOnRails, ohne ROR hätte es keinen (so) großen Anreiz gegeben auf Ruby zu wechslen.

Stimmt leider, Features der Sprache sind nicht das wichtigste. Wie gesagt denke ich das Ruby weitaus bessere Features hat als Java, aber mit Java habe ich IDEs, Build-Tools, eine sehr ausfuehrliche Standard-Bibliothek, uvm. Das sind die Dinge die einem am Ende wirklich wichtig sind.

Btw, haette man die Sprachfaetures in D nicht einfach in C++/C umsetzen koennen? Also man schreibt das Programm in D und dann wird der Code erst in C umgeschrieben und dann mit einem C-Compiler kompiliert? Ganz am Anfang von C++ wurde es ja auch erst in C transformiert.

Das haette die Vorteile gehabt dass man a) schon sehr gute Compiler haette, b) der Code waehre zu 100% kompatibel zu C, c) man haette die Build-Werkzeuge von C verwenden koennen, usw.

D-Profi schrieb:

Zeus schrieb:

Vor einem Jahr wurde beschlossen, dass Sie in eine Koexisten gehen wollen. ^^

@D-Profi
Du redet von Änderung des Programmierparadigmas. Was zur Hölle willst du Objective C?

Diese Frage kann ich dir nicht beantworten, zuerst will ich, dass du mir die Frage erneut stellst, diese mal jedoch auf Deutsch, bitte!
Dann kann ich versuchen dir die Frage zu beantworten.

Oh man, jedem DAU fällt auf, das in der Frage nur das Wort "mit" fehlt.

Wenn du zwischen den Zeilen lesen könntest, dann wäre dir das auch von selbst aufgefallen.

Die Frage dürftest du mit diesem Hinweis jetzt also beantworten können,
falls nicht, dann hätte ich eh meine bezweifel ob du so eine Frage kompetent beantworten könntest.

[quote="DEvent"]

D-Profi schrieb:

Btw, haette man die Sprachfaetures in D nicht einfach in C++/C umsetzen koennen?

Dann hätte man C++ neu definieren und die Compiler entsprechend alle umschreiben müssen.

D grenzt die Entstehung von Bufferoverflow by Design z.B. weitgehend ab, das hätte man dann auch mit C++ machen müssen.
D ist keineswegs nur eine Erweiterung der STD.

Also man schreibt das Programm in D und dann wird der Code erst in C umgeschrieben und dann mit einem C-Compiler kompiliert? Ganz am Anfang von C++ wurde es ja auch erst in C transformiert.

Den C Code kann dann aber am Ende eh kein Mensch lesen, wenn der Computer das zusammenpfuscht.

Außerdem gibt es ja den GNU GDC, der macht dir daraus Assemblercode im AT&T Style. Und den kannst du genauso gut wieder in C Code zurückverwandeln, nur besonders lesbar wird der nicht sein.

Shade Of Mine

Siehe schrieb:

D grenzt die Entstehung von Bufferoverflow by Design z.B. weitgehend ab, das hätte man dann auch mit C++ machen müssen.

Gute Programmierer koennen das auch in C++.

In der heutigen Welt gibt es keine Entschuldigung fuer Buffer Overflows oder SQL Injections und derartiges. Dass sie dennoch auftreten liegt an der Dummheit einiger Programmierer. Natuerlich versucht man jetzt alles Foolproof zu machen, aber im Endeffekt muss jeder Programmierer dennoch achtgeben. Denn eine OutOfBounds Exception ist genauso doof wie ein Buffer Overflow nur das Ergebnis ist nicht ganz so fatal.

Natürlich liegt es am Programmierer, ist vollkommen richtig. Aber es ist eine realitätsfremde Einstellung, zu meinen, die Programmierer sollen aufpassen oder kompetent sein und damit is es erledigt. Das es so nicht funktioniert kann man seit Jahren sehen.

Trotzdem bin ich nicht der Meinung dass man eine neue Sprache braucht, um mit diesem Problem umzugehen. Eine neue Sprache braucht man, um ein paar Altlasten loszuwerden. Alles was bei C++ neu hinzukommt ist gut, aber was bleibt, nicht.

Shade Of Mine

Optimizer schrieb:

Das es so nicht funktioniert kann man seit Jahren sehen.

Nur hilft da auch leider ein Java nicht. Man hat zwar dann keine Sicherheitsluecke aber die Anwendung schmiert trotzdem ab (oder ist in einem inkonsistenten Zustand)...

Ich sehe halt einfach nur keine Loesung ausser automatische Hilfen anzubieten. Aber eben auch diese automatischen hilfen muessen sinnvoll benutzt werden. In Managed Code geht man eben soweit und sagt: wir verhindern automatisch sicherheitsluecken - das ist toll, aber es loest das Problem nicht.

Wenn jemand weiss wie man solche Probleme verhindern kann, dann nur her damit. PHP hat zB probiert alle Usereingaben automatisch zu escapen um SQL Injections zu verhindern - aber alle Leute haben es immer deaktiviert. Und jetzt schaut man sich mal den Ruf von PHP an

Ne ne ne, ich habe leider noch kein foolproof System gesehen - deshalb finde ich foolproof argumente immer schwach - zumal ich nicht glaube dass D garantieren kann dass es keine overflows gibt.

Shade Of Mine schrieb:

Gute Programmierer koennen das auch in C++.

Kein Mensch ist fehlerfrei, du kannst 30 Jahre lang unfrallfrei Auto fahren und dann nach dieser zeit dann dennoch einen bauen und dabei auch noch der Verursacher sein, also tue mal nicht so, daß Bufferoverflows bei C++ kein Problem seihen.

Wenn Programmierer so gut wären, dann hätte heutige Computer Software überhaupt keine Bugs, da Programmierer wie man deiner Aussage entnehmen kann, ja keine Fehler machen würden.

In der heutigen Welt gibt es keine Entschuldigung fuer Buffer Overflows oder SQL Injections und derartiges.

Und für Bugs in Software auch nicht!?
Immer so ein dummes Geblubber.

Dass sie dennoch auftreten liegt an der Dummheit einiger Programmierer.

Stimmt, Programmierer haben ja unendlich viel Zeit, so daß sie gefälligst Fehlerfrei zu Programmieren haben.

Natuerlich versucht man jetzt alles Foolproof zu machen, aber im Endeffekt muss jeder Programmierer dennoch achtgeben..

Und warum willst du das fehlerfreie Programmieren dem Menschen überlassen, wenn es die Maschine + Mensch so viel besser kann?

Ich nehme jedes Hilfmittel welche mir die Maschine geben kann, dankbar an und dazu gehört auch eine Programmiersprache die das Auftreten Bufferoverruns deutlich reduziert.

Optimizer schrieb:

Natürlich liegt es am Programmierer, ist vollkommen richtig. Aber es ist eine realitätsfremde Einstellung, zu meinen, die Programmierer sollen aufpassen oder kompetent sein und damit is es erledigt. Das es so nicht funktioniert kann man seit Jahren sehen.

Trotzdem bin ich nicht der Meinung dass man eine neue Sprache braucht, um mit diesem Problem umzugehen. Eine neue Sprache braucht man, um ein paar Altlasten loszuwerden. Alles was bei C++ neu hinzukommt ist gut, aber was bleibt, nicht.

Dann wäre es Zeit mal C++ zu entschlacken und den alten Müll rauszuschmeißen.

Nur will das dann niemand, weil ja dann jeder seinen Code umbauen müßte.
Also ist es besser wenn man eine neue Sprache einführt.

Wenn man so will ist D ein Branch von C welcher es versucht die Fehler im Branch C++ zu vermeiden.

Shade Of Mine schrieb:

[
Ne ne ne, ich habe leider noch kein foolproof System gesehen - deshalb finde ich foolproof argumente immer schwach - zumal ich nicht glaube dass D garantieren kann dass es keine overflows gibt.

Wie schon gesagt, es reduziert sie deutlich im Vergleich zu C++.
Und das ist auch etwas, wenn die Rate von potentiellen Bugs um 70 % abnimmt. (Die Zahl ist aus der Luft gegriffen)

Shade Of Mine

D vs. C++ schrieb:

Wie schon gesagt, es reduziert sie deutlich im Vergleich zu C++.
Und das ist auch etwas, wenn die Rate von potentiellen Bugs um 70 % abnimmt. (Die Zahl ist aus der Luft gegriffen)

nur dass die bugs nicht weniger werden sondern sich nur einfach nicht so vernichtend auswirken. weniger werden tun sie kein bisschen...

Erhard Henkes

Irgendwie dreht sich die Diskussion im Kreis. Welche Art von Programmen sollte man z.B. bevorzugt in D programmieren und aus welchem Grund?

Erhard Henkes schrieb:

Irgendwie dreht sich die Diskussion im Kreis. Welche Art von Programmen sollte man z.B. bevorzugt in D programmieren und aus welchem Grund?

Ganz klar "Systemprogrammierung". Diesen Platzhalter hört man im Zusammenhang mit D immer wieder. Aber bei der Verfügbarkeit an Compilern ist wenigstens eindeutig welches System gemeint ist

Shade Of Mine schrieb:

Optimizer schrieb:

Das es so nicht funktioniert kann man seit Jahren sehen.

Nur hilft da auch leider ein Java nicht. Man hat zwar dann keine Sicherheitsluecke aber die Anwendung schmiert trotzdem ab (oder ist in einem inkonsistenten Zustand)...

Das ist doch vergleichsweise harmlos. Du musst schon zugeben, wenn mir jemand mein Java-Programm zum Absturz bringt, bei etwas was normal ein buffer overflow gewesen wäre, dann ist das ein wesentlich besseres Ergebnis. Dann sehe ich sogar noch den stack trace und kann den Fehler relativ einfach beheben. Bei einem Server, der mir gehackt wurde und Amok läuft, wie soll ich da im Nachhinein herausfinden, wo das Problem war?

Das ist einfach ein Punkt, wo solche "sicheren" Sprachen überlegen sind - nur noch der Chief Lead of irgendwas muss Ahnung von der Sache haben damit keine konzeptionellen Sicherheitslücken enstehen. Wenn ich eine Sprache wie C oder C++ verwende, reicht es aus das ein Programmierer von meinen hundert keine Ahnung hat und ich habe eine Sicherheitslücke drin - und garantiere mir mal, dass jeder in deinem Team nie solche Fehler machen würde...

Ich sehe halt einfach nur keine Loesung ausser automatische Hilfen anzubieten. Aber eben auch diese automatischen hilfen muessen sinnvoll benutzt werden. In Managed Code geht man eben soweit und sagt: wir verhindern automatisch sicherheitsluecken - das ist toll, aber es loest das Problem nicht.

Wieso löst es das Problem nicht? Buffer overflows, uninitialisierte Variablen und ähnliche Kleinigkeiten sind hiermit ein gelöstes Problem. Viele Sachen finde ich schlechter gelöst, man muss natürlich seine Prioritäten kennen. Sicherheitsmäßig halte ich solche Sprachen jedenfalls für überlegen.

Wer Java und SWT liebt, der kann jetzt mit D und DWT GUI Anwendungen entwickeln.

DWT ist nämlich ein Gui Widget für D und vom Programmieren her stark an SWT angelehnt.
Das ist doch also mal etwas positives für D.

http://www.dsource.org/projects/dwt

Screenshots:
http://www.dsource.org/projects/dwt/wiki/Screenshots

Erhard Henkes

Wenn ich mir das so ansehe, habe ich das Gefühl, dass D ein typisches "me-too" Produkt ist. Damit kann man im professionellen Umfeld nicht punkten. Für den privaten Anwender zählt die Kompaktheit der Toolchain, die Flexibilität von der Konsole bis zum Spieledesign und ausreichend Unterstützung bei Problemfällen.

Was ich bisher gesehen habe, ist für mich wenig attraktiv. Macht aber nichts, weil C/C++, Java oder C# bereits ausreichend Möglichkeiten und Unterstützung bieten.

Oh Mann! schrieb:

D-Profi schrieb:

Zeus schrieb:

Vor einem Jahr wurde beschlossen, dass Sie in eine Koexisten gehen wollen. ^^

@D-Profi
Du redet von Änderung des Programmierparadigmas. Was zur Hölle willst du Objective C?

Diese Frage kann ich dir nicht beantworten, zuerst will ich, dass du mir die Frage erneut stellst, diese mal jedoch auf Deutsch, bitte!
Dann kann ich versuchen dir die Frage zu beantworten.

Oh man, jedem DAU fällt auf, das in der Frage nur das Wort "mit" fehlt.

Wenn du zwischen den Zeilen lesen könntest, dann wäre dir das auch von selbst aufgefallen.

Die Frage dürftest du mit diesem Hinweis jetzt also beantworten können,
falls nicht, dann hätte ich eh meine bezweifel ob du so eine Frage kompetent beantworten könntest.

Geht doch

So dann will ich euch den Grund verrate warum ich mir eher Objective C anschauen würde als Objective C wird in der Praxis eingesetzt und zwar jetzt und nicht irgendwann

Zeus

Requirements for DWT

Compiler:
DMD – http://www.digitalmars.com/d/1.0/changelog.html
DMD 1.028 OK

Runtime library:
Tango - http://www.dsource.org/projects/tango
release 0.99.6

Damit hat die Hälfte, die D ansehen, probleme.

D-Profi schrieb:

So dann will ich euch den Grund verrate warum ich mir eher Objective C anschauen würde als Objective C wird in der Praxis eingesetzt und zwar jetzt und nicht irgendwann

Fairerweise muss man hier aber auch erwähnen, dass es für objC ausserhalb von MacOS auch ziemlich dünn wird. Aber zumindest Compiler sind kein wirkliches Problem (afaik).

Erhard Henkes schrieb:

Wenn ich mir das so ansehe, habe ich das Gefühl, dass D ein typisches "me-too" Produkt ist. Damit kann man im professionellen Umfeld nicht punkten.

Was verstehst du unter "me-too" Produkt?

Für den privaten Anwender zählt die Kompaktheit der Toolchain, die Flexibilität von der Konsole bis zum Spieledesign und ausreichend Unterstützung bei Problemfällen.

Meinst du damit, daß es ein komplettes Betriebssystem basierend auf D geben sollte und das es eine eigene OpenGL Implementierung geben sollte, aber auf Basis der Sprache D, damit das was du willst, also die größte Kompaktheit & Flexibilität erfüllt werden kann?

Wenn ja, dann frage ich mich, wieso du so etwas von D verlangst?

Auch C++ nutzt nur die Funktionen der gängigen Betriebssysteme die in C geschrieben wurden und hat selbst kein eigenes Betriebssystem. (zuminest kenen ich kein bekanntes. Linux, Darwin & Windows sind beide in C geschrieben)

Auch kenen ich keine Implementierung von OpenGL, die in C++ realisiert wurde.
Lediglich unter Windows gibt es etwas ähnliches namnes Direct3d.

Und bei den GUI Toolkits sieht es auch nicht viel besser aus.
Auch QT abstrahiert nur die Funktionalität des X-Window System, es gibt keine freie X-Window Implementierung die in C++ geschrieben wurde.

Von daher verstehe ich dich nicht.

Warum soll D nicht die C Implementierungen von OpenGL nutzen können dürfen?
Warum soll D nicht auf die C Implementierungen der GUI Toolkits wie z.B. GTK+ aufbauen dürfen? Man beachte, GTK+ wurde dafür geschrieben, daß man auch andere Programmiersprachen Bindings nutzen kann. Man denke nur an GTKmm -> C++.