Programmieren in D

[michast]

Hi,

bin erst durch die c't auf die Programmiersprache D aufmerksam geworden. Gibt es hier schon experimentierfreudige Entwickler, die erste Erfahrungen gesammelt haben? Wie ist Eure Meinung? Schafft es D gegen C/C++ und Java oder ist es nur eine zusätzliche Sprache, die parallel zu den anderen Sprachen läuft, bzw. wieder untergeht.

Klingt wie ein Anfängerposting, ich weiss. Aber bis vor zwei Wochen wusste ich nicht einmal, das D existiert. Nun wollte ich mal Meinungen einfangen, meine Frau macht er Web, die interessierts nicht

 

[schlingel]

Ich persönlich finde D zwar sehr interessant und es bringt etliche Verbesserungen gegenüber C++. Allerdings glaube ich nicht, dass D C++ in absehbarer Zeit ablösen wird, da es zu viele alteingesessene C++ Programmierer gibt.
Sollten die Unis anfangen ihren Informatikern D ans Herz zu legen könnte ich mir das schon eher vorstellen. Aber ich glaube nicht, dass die alten Herren in den Lehrstühlen sowas "neues" machen werden.
Gegen Java wird D sicher nicht ankommen, da die Plattformunabhängigkeit nicht so gegeben ist. Es wird nebenher existieren und irgendwann werden viele hoffentlich schnallen, dass hier einiges umgesetzt wurde, was absolut super ist, aber das wird dauern.
Und solange es kein Ojective-D gibt interessierts mich nur peripher

 

[MatzeLoCal]

Dass sich eine neue Sprache sehr schnell durchsetzt ist doch eh unwahrscheinlich.

Java, das den Marketinghype von SUN im Rücken hatte, hat auch Jahre gebraucht um überhaupt erstmal eine "Heimat" zu finden.

Mit C# ist es ähnlich wobei das sich ja schon in ein gemachtes Nest setzen konnte.

D hat aber nicht so eine Macht im Rücken, darum muss es sich beweisen. Wenn es gut ist, dann wird es sich neben C/C++ behaupten... ersetzen wird es keines von beiden.

 

[michast]

Wenn ich mir vorstelle wie lange es gedauert hat, bis mal Java an der FH angeboten wurde. Die Zeiten von Pascal sind noch gar nicht so lange her, und damit konnte man nicht wirklich etwas anfangen (ging zumindest mir so).

Vielleicht kommt Microsoft ja auf den Trichter, verkompliziert die ganze Sache und nennt die Sprache dann D#

 

[Walli]

Ich habe das erste Mal vor einigen Jahren in einem C++ Forum von D gehört. Ich finde die Sprache bringt einige nette Ansätze, aber es wird nicht reichen um C++ zu verdrängen. Das haben Java und C# nicht geschafft und D wird es auch nicht schaffen. Hinter C++ stehen mittlerweile auch einige namhafte Firmen (z.B. Microsoft, Intel, Hewlett Packard usw.), die an der Weiterentwicklung interessiert sind. Mir ist auch nicht bekannt, dass irgendwelche ernstzunehmende Software bisher in D geschrieben wurde und die Community ist noch recht klein. D war für mich immer eine nette Sprache, die aber ohne Bedarf geschaffen wurde.

 

[schlingel]

Ich habe das erste Mal vor einigen Jahren in einem C++ Forum von D gehört. Ich finde die Sprache bringt einige nette Ansätze, aber es wird nicht reichen um C++ zu verdrängen. Das haben Java und C# nicht geschafft und D wird es auch nicht schaffen. Hinter C++ stehen mittlerweile auch einige namhafte Firmen (z.B. Microsoft, Intel, Hewlett Packard usw.), die an der Weiterentwicklung interessiert sind. Mir ist auch nicht bekannt, dass irgendwelche ernstzunehmende Software bisher in D geschrieben wurde und die Community ist noch recht klein. D war für mich immer eine nette Sprache, die aber ohne Bedarf geschaffen wurde.

Dann hast Du den Sinn von D nicht verstanden...

P.S. D wurde erst vor kurzem als fertige Sprache inkl. Standard veröffentlicht, daher wurde auch bisher noch keine "ermstzunehmende" Software darin Programmiert.

 

[michast]

Übrigens spricht mein Lieblingseditor "Textmate" mittlerweile D.

Im D Programmierer Forum hab ich mal dafür gesorgt, dass die Mac-Fraktion vertreten ist. Und siehe da, ich bin nicht alleine. Es gibt Ansätze, XCode mit D bekannt zu machen. Ich hab es noch nicht richtig geschafft, aber wie gesagt, Textmate hab ich hinbekommen

Dann hast Du den Sinn von D nicht verstanden...

P.S. D wurde erst vor kurzem als fertige Sprache inkl. Standard veröffentlicht, daher wurde auch bisher noch keine "ermstzunehmende" Software darin Programmiert.

Beide Male meine Meinung

 

[Walli]

Dann hast Du den Sinn von D nicht verstanden...

Der da wäre? Sorry, aber ich finde es irgendwie blöd wenn man sowas nach einem Fullquote mit ein paar Pünktchen dahinter schreibt aber keine Begründung folgen lässt.

P.S. D wurde erst vor kurzem als fertige Sprache inkl. Standard veröffentlicht, daher wurde auch bisher noch keine "ermstzunehmende" Software darin Programmiert.

Also in C++ wurde schon Jahre vor dem Standard ernsthaft programmiert. Was mich wieder zu der Vermutung bringt, dass D ohne Bedarf geschaffen wurde.

 

[schlingel]

Der da wäre? Sorry, aber ich finde es irgendwie blöd wenn man sowas nach einem Fullquote mit ein paar Pünktchen dahinter schreibt aber keine Begründung folgen lässt.


Also in C++ wurde schon Jahre vor dem Standard ernsthaft programmiert. Was mich wieder zu der Vermutung bringt, dass D ohne Bedarf geschaffen wurde.

Entschuldige Meister.

Also C++ hat besonders in der Pointerei "Schwächen" welche sich böse ausnutzen lassen. Hier übernimmt D die Speicherverwaltung selbst (kann man auch ausschalten).
Ich bin nicht "nur" an den objektorientierten Programmierstil gebunden, sondern könnte auch prozedural programmieren. Ich kann es sogar mischen oder direkt in den Code Assembler Code einfügen.
Wenn ich Spass dran hab, kann ich C Bibliotheken einbinden (dank der C-ABI) und ansprechen, dass zeigst Du mir mal in C++.

Und für das schreiben von "Ernsthaften Programmen": Intergriertes Unit-Testing, Junge DAS ist für grosse Projekte ein Killerfeature!

D war vor dem finalen Release noch etwas buggy und c++ ist bisher sehr gut etabliert war schrieb keiner bisher darin.
Der Sprung vom funktionalen C zum objektorientierten C++ war damals ein wahnsinns Sprung, den D im selben Aussmass natürlich nicht bieten kann.

Ich persönliche finde alle Neuerungen sehr sehr gut und begrüsse das sehr. Wenn Du nicht mit D programmieren willst dann lass es eben. Wie schonmal gesagt (glaub ich) auf dem Mac ist es eh erstmal uninterssant, da ich nicht weiss wie D mit Cocoa zusammenspielt.

 

[michast]

Wie schonmal gesagt (glaub ich) auf dem Mac ist es eh erstmal uninterssant, da ich nicht weiss wie D mit Cocoa zusammenspielt.

Und genau da bin ich sehr gespannt, da Apple eigentlich gerne innovativ ist

 

[Walli]

Entschuldige Meister.

Eigentlich schade, dass man mit dir scheinbar nicht ernsthaft diskutieren kann. Letzter Versuch.

Also C++ hat besonders in der Pointerei "Schwächen" welche sich böse ausnutzen lassen. Hier übernimmt D die Speicherverwaltung selbst (kann man auch ausschalten).

D hat einen GC. Ob das ein Vorteil oder ein Nachteil ist, darüber kann man sich streiten. Solange er abschaltbar ist kann ja jeder selber entscheiden. Nur, wer C++ programmieren KANN (ich verweise auf RAII und so Scherze), der ist nur ganz selten auf wilde Pointerei angewiesen und das kann man oft auch noch wunderbar kapseln. Für alltägliches gibt es diverse Container, Smart-Pointer usw. Wer C++ nur als ein C mit Klassen sieht und wild auf blanken Arrays rumpointert oder Sachen wie printf und Co verwendet, der baut natürlich anfälligen Code. Solche Sachen sind in der C++ Community mehr als verpönt. Ich sehe einen GC jedenfalls nicht als Allheilmittel um unerfahrene Anwender davor zu bewahren Memory Leaks zu bauen.
BTW: Auch für C++ gibt es GCs, die allerdings kaum ein Schwein einsetzt. Mag daran liegen, dass es kein direktes Sprachfeature ist und man sich für so etwas, was nicht unbedingt nötig ist, ungerne eine weitere Library ins Boot holt.

Ich bin nicht "nur" an den objektorientierten Programmierstil gebunden, sondern könnte auch prozedural programmieren. Ich kann es sogar mischen oder direkt in den Code Assembler Code einfügen.

Wo ist jetzt der Vorteil ggü. C++? Eben diese Sachen kann ich dort alle auch machen. Ich kann sogar in Java prozedural programmieren oder in C objektorientiert. Bloß weil eine Sprache gewisse Paradigmen von Haus aus unterstützt ist man ja nicht daran gebunden.

Wenn ich Spass dran hab, kann ich C Bibliotheken einbinden (dank der C-ABI) und ansprechen, dass zeigst Du mir mal in C++.

Da laust mich doch der Affe! Nee, DAS ist GANZ sicher nicht möglich mit C++ </ironie> Und dass C einen Schulabschluss hat war mir auch neu .

Und für das schreiben von "Ernsthaften Programmen": Intergriertes Unit-Testing, Junge DAS ist für grosse Projekte ein Killerfeature!

Es gibt für die Mainstream-Sprachen Unit-Testing-Frameworks. Ich sehe also nicht warum eine Firma von bereits etablierten Lösungen dringend auf D umsatteln muss. "Junge" (um in deiner Sprache zu bleiben), weißt du eigentlich was es kostet mit einem Großprojekt mal eben mir nichts, dir nichts die Programmiersprache zu wechseln? Die meisten Programme übertreffen nunmal den Codeaufwand einer DVD-Verwaltungssoftware. Natürlich ist es nett, dass D z.B. Design by Contract integriert hat usw., sage ja nichts negatives darüber. Aber es ist sicher kein Killerfeature für den Umstieg, weil man das in anderen Sprachen auch bereits haben kann. Und für neue Projekte bleibt das Risiko, dass D in 10 Jahren von der Bildfläche verschwunden sein könnte. Neee, also wenn sich keine namhaften Firmen finden, die D pushen dann sehe ich schwarz.

Ich persönliche finde alle Neuerungen sehr sehr gut und begrüsse das sehr.

Ich auch!?!

Wenn Du nicht mit D programmieren willst dann lass es eben.

Wie gesagt. Die Frage in diesem Thread war, ob wir uns vorstellen können, dass D es gegen C/C++/Java schafft oder wieder untergehen wird. Es gibt eine Menge interessanter Sprachen (Ada 95, Ruby, Ocaml usw.), die aber für die meisten Leute höchstens zu Studienzwecken interessant sind, eben weil sie kaum ernsthaft verwendet werden. Ich denke, dass es mit D ähnlich sein wird, nicht mehr und nicht weniger. Und so wie ich dein erstes Posting interpretiere sind wir uns doch da einig.

 

[MatzeLoCal]

D wird es sehr sehr schwer haben. Ob Apple D offiziell unterstützen wird bezweifel ich mal, zumindest in den nächsten 5 Jahren.
Obj-C ist für Apple im Moment die Sprache der Wahl. Und so wie es aussieht konzentireren sich die Leute aus Cupertino immer mehr darauf. Java wird nur noch als "Beiwerk" betrachtet (was soweit auch ok ist.. zumindest für mich).

Was in OS X noch stärker zum Tragen kommen wird sind Skriptsprachen wie, JS, Python und Ruby. Aber die haben ein anderes Einsatzgebiet.

 

[tjp]

Entschuldige Meister.

Also C++ hat besonders in der Pointerei "Schwächen" welche sich böse ausnutzen lassen. Hier übernimmt D die Speicherverwaltung selbst (kann man auch ausschalten).

In C++ hat man die Wahlfreiheit wie man Objekte anlegen lassen will. Dies ist oftmals unumgänglich, weil man in vielen Bereichen eine direkte Kontrolle der Speicherallokation benötigt. Trivialerweise kann man Zeiger via Referenzcounting (siehe Boost Library) oder GC in C++ verwalten lassen. Boost wird zum großen Teil in die nächste ISO-Norm integriert werden.

Wenn man in D die Zeiger selbst verwaltet, dann kämpft man auch dort mit den exakt gleichen Problemen wie in C und C++. Im Gegensatz zur Brightschen Propaganda schenken sich hier C++ und D gar nichts. Einzig den GC muß man bei C++ extra hinzulinken, aber viele brauchen keinen GC. Zyklische Graphen braucht man nur unter bestimmten Bedingungen.

Ich bin nicht "nur" an den objektorientierten Programmierstil gebunden, sondern könnte auch prozedural programmieren.

Äh ja, wo ist das Problem? Kennst Du überhaupt C++?

Ich kann es sogar mischen oder direkt in den Code Assembler Code einfügen.

Tolles Feature braucht man auch so häufig. Das geht aber auch mit einigen C++ Compilern. Dafür gibt es aber auch C++ Compiler von denen Walter Bright auch noch nie etwas gehört hat.

Wenn ich Spass dran hab, kann ich C Bibliotheken einbinden (dank der C-ABI) und ansprechen, dass zeigst Du mir mal in C++.

Ja, das sagt uns jetzt nur, daß Du C++ nicht kennst. (Das geht da natürlich auch.)

Und für das schreiben von "Ernsthaften Programmen": Intergriertes Unit-Testing, Junge DAS ist für grosse Projekte ein Killerfeature!

Unittesting kann man so in ziemlich jeder Programmiersprache realisieren und ich bin kein Fan davon Unittesting aus dem Produktionscode zu schmeißen. (Kaputte Datenbanken kommen nicht gut an.) Womit man die meisten Unittesting Libraries oder Sprachfeature nicht nutzen kann, weil diese meist auf Assertions aufbauen und nicht auf Exceptions.

 

[schlingel]

Ich will nicht behaupten, dass ich mehr Ahnung von C++ habe, als ihr, aber die Sache mit den C-ABI's geht mir jetzt nicht mehr aus dem Kopf.

Also es geht nicht darum einfach C-Code in den Quelltext einzubauen, den der C++ Compiler ja auch kann, sondern darum das C-Application-Binary-Interface anzusprechen. Wenn mir jetzt jemand erklärt, wie das geht dann halt ich die Klappe! Dann hab ich wieder was neues gelernt.

 

[tjp]

Hi,

bin erst durch die c't auf die Programmiersprache D aufmerksam geworden.

Die Sprache ist eher ein Rückschritt, da Walter Bright leider einen fundamentalen Designfehler gemacht hat: Er führt für jedes neue Feature immer wieder neue Bezeichner ein. Wie so etwas endet sich man zum Beispiel an PHP.

Zur Sprache selbst:
D bietet keine substantielle Verbesserung gegenüber C++ und ist dafür inkompatibel. D hat an einigen wenigen Stellen echte Neuerungen gegenüber C++. Mir fallen da so Sachen ein wie:
Properties
DbC (SubrangeTypes wie in Ada wären sehr viel sinnvoller gewesen)
In, InOut, Out Parameter (Ada sag ich nur)
Dynamic Closures (wobei das eigentlich auch nur Syntax ist)

Die eingebauten Strings in D sehe ich persönlich eher als Nachteil, da man sie auf eigenene Bedürfnisse nicht so anpassen kann, da man keinen eigenen Allokator verwenden kann und auch andere private Anpassungen nicht durchführen kann.

C++ mag mehr als Baukasten für den vorgeschrittenen Programmierer erscheinen, hat dafür aber sehr viel mehr Möglichkeiten.
std::string ist ja nur ein typedef für std::basic_string<class charT, class traits=char_traits<charT>, class Allocator = allocator<charT> >

Sehr erhellend war auch der Streit von Walter Bright zum Thema "wahrer" Operator für das Zusammenfügen von Strings. ("+" ist für ihn bäh, obwohl das Zusammenfügen von Strings sogar eine additive Halbgruppe ist. Läßt er sich nicht davon abbringen.)

Die häßliche und gefährliche "printf" Syntax ist bei D leider wieder zum Maß der Dinge erhoben worden. Das lädt leider zu Formatstring Exploits ein. Da der Mist leider nicht typsicher ist.

Einige Neuerungen wird es ja für die nächste ISO-Norm von C++ geben. Wenn man einen modernen C++-Programmierstil pflegt erscheint D nicht sonderlich attraktiv, da es nicht sonderlich viel mehr bringt, dafür aber komplett inkompatibel ist.

 

[tjp]

Wenn mir jetzt jemand erklärt, wie das geht dann halt ich die Klappe! Dann hab ich wieder was neues gelernt.

Du mußt dazu nur C-Header Files als "extern C" inkludieren und anschließend die C-Library an das C++ Kompilat binden. Das war's.

Es gibt drei, vier Punkte in der Verwendung zu beachten.
Erstens wenn man C++ Funktionen als C-Callbacks verwendet dürfen diese keine Exceptions werfen und müssen mit "extern C" deklariert sein. (Da das C ABI das Stack Unwinding des C++ Compilers nicht unterstützen muß. Es gibt C++-Compiler, C-ABIs Kombinationen bei denen das funktioniert. C++ läuft auf sehr viel mehr Plattformen als D, daher gibt es für so etwas keinerlei Garantie, und die allgemeine Regel lautet: Mach's nicht.)
Die C-Header müssen so geschrieben sein, daß der C++ Compiler sie wie der C-Compiler interpretiert. Es gibt da ein, zwei Kleinigkeiten, die Ärger machen (im Stroustrup steht's drin. Bei Interesse schau ich nach). Die üblichen C-Header für Libraries sind zu 99% für die Verwendung in C++ Projekten vorgesehen. Im C-Programmcode bestehen diese Einschränkungen übrigens nicht, die werden auch von einem C-Compiler übersetzt.

 

[schlingel]

Hmm ok besonders die Printf Problematik ist schon überzeugend.

Also Du führtst hier tatsächlich viele Argumente an, welche ich nicht bedacht habe.. ArgH!

Naja für die wirklich grossen Projekte scheint es definitiv Minuspunkte zu geben... Also ich persönliche finde den Garbage-Colletor sehr angenehm... Naja ansichtssache.

 

[schlingel]

Du mußt dazu nur C-Header Files als "extern C" inkludieren und anschließend die C-Library an das C++ Kompilat binden. Das war's.

Es gibt drei, vier Punkte in der Verwendung zu beachten.
Erstens wenn man C++ Funktionen als C-Callbacks verwendet dürfen diese keine Exceptions werfen und müssen mit "extern C" deklariert sein. (Da das C ABI das Stack Unwinding des C++ Compilers nicht unterstützen muß. Es gibt C++-Compiler, C-ABIs Kombinationen bei denen das funktioniert. C++ läuft auf sehr viel mehr Plattformen als D, daher gibt es für so etwas keinerlei Garantie, und die allgemeine Regel lautet: Mach's nicht.)
Die C-Header müssen so geschrieben sein, daß der C++ Compiler sie wie der C-Compiler interpretiert. Es gibt da ein, zwei Kleinigkeiten, die Ärger machen (im Stroustrup steht's drin. Bei Interesse schau ich nach). Die üblichen C-Header für Libraries sind zu 99% für die Verwendung in C++ Projekten vorgesehen. Im C-Programmcode bestehen diese Einschränkungen übrigens nicht, die werden auch von einem C-Compiler übersetzt.

OK. D ist blöd und wird es nie schaffen