Gebt doch endlich mal richtige Gründe gegen die Sprache D an!
-
Hmm, D bietet dir die Möglichkeit RAII und GC-basierend zu arbeiten. In dem Sinn brauchst du beides. Ist jetzt diese Freiheit schlecht, welches in C++ so gelobt wird?
-
und ich dachte immer, D sei eine Esoteriksprache, die C++ auf die Schippe nehmen wollte
-
Zeus schrieb:
Hmm, D bietet dir die Möglichkeit RAII und GC-basierend zu arbeiten. In dem Sinn brauchst du beides.
Nein, man braucht nur dann finally, wenn die Sprache keine deterministisch aufgerufene Destruktoren kennt, das schließt übrigens einen GC nicht aus.
-
Man hat genügend Alternativen, d.h. der Ausleseprozess ist härter geworden. Die mangelnde Unterstützung in der Praxis spricht z.Z. einfach noch gegen die Verwendung von D in professionellen Projekten.
Dennoch bin ich der Meinung , dass man hier im Forum eine Sektion D eröffnen sollte, da diese Sprache nun über ein Jahr "offiziell existiert" und eine wohl nicht zu leugnende Nähe zu C/C++ besitzt.
-
Erhard Henkes schrieb:
Dennoch bin ich der Meinung , dass man hier im Forum eine Sektion D eröffnen sollte, da diese Sprache nun über ein Jahr "offiziell existiert" und eine wohl nicht zu leugnende Nähe zu C/C++ besitzt.
Plus dass die Nachteile der Sprache für kleinere Hobby-Projekte kaum Gewicht haben. Mit Compiler und Editor mit Syntax-Coloring kann man sofort loslegen
-
~john schrieb:
Zeus schrieb:
Hmm, D bietet dir die Möglichkeit RAII und GC-basierend zu arbeiten. In dem Sinn brauchst du beides.
Nein, man braucht nur dann finally, wenn die Sprache keine deterministisch aufgerufene Destruktoren kennt, das schließt übrigens einen GC nicht aus.
Stimmt und den hat D o.O
-
Erhard Henkes schrieb:
Man hat genügend Alternativen, d.h. der Ausleseprozess ist härter geworden. Die mangelnde Unterstützung in der Praxis spricht z.Z. einfach noch gegen die Verwendung von D in professionellen Projekten.
Dennoch bin ich der Meinung , dass man hier im Forum eine Sektion D eröffnen sollte, da diese Sprache nun über ein Jahr "offiziell existiert" und eine wohl nicht zu leugnende Nähe zu C/C++ besitzt.
Wieso dann könnte jeder Compilerbauer mit seine Sprache kommen und verlangen ne Sektion zu haben?
-
Ruby_profi schrieb:
Du bist echt arm, VS ist eine Plattform, wie Eclipse oder NetBeans um darin Entwicklertools laufen zu lassen. RubyInStell ist so vollwertig wie jede andere IDE. Es ist kein Plugin wie VAssist für Visual C++. Du kannst es dir eher wie ein Visual Ruby vorstellen.
Bin halt arm, kann sich halt nicht jeder VS kaufen. Eclipse und Netbeans sind kostenlos und laufen auf Windows/Linux/Mac/BSD/Solaris/usw. Klar wer nur Windows benutzt und bereits eine VS-Lizenz hat, freuet sich ueber RubyInStell.
Btw, existieren eigentlich build-tools fuer D? Gibt es eine autotools/automake Integration?
-
Wieso dann könnte jeder Compilerbauer mit seine Sprache kommen und verlangen ne Sektion zu haben?
Nein, die Nähe zu C/C++ sollte entscheidend sein. D ist doch vermutlich der Versuch, ein modernes und narrensicheres "C/C++" aus einem Guss zu schaffen. Im Prinzip die gleiche Idee wie bei Java und C#.
Gibt es zumindest eine Anweisung für Anfänger, wie man den Digital Mars Compiler in Code::Blocks integriert?
-
~john schrieb:
Unfug schrieb:
Das ist doch Bullshit.
Es ist einfach Unfug, wenn man sich die Realität so zurecht biegt, wie es einem gerade in den Kram paßt. D ist schon deutlich länger da draußen als ein Jahr.
Ich unterscheide hier aber zwischen:
Draußen für den Praxiseinsatz -> hier gilt erst die 1.0 Version
und
Draußen für das Design und die Entwicklung der Sprache -> hier mag die erste Zeile Code von vor 10 Jahren zählen.
Das Problem das du und der Mod machen, ist daß ihr nach dem Praxiseinsatzzeitpunkt fragt, aber dann die Zeiten der Entstehung als Zeitpunkt hernimmt und das ist einfach falsch.
Entwickelt ihr z.b. auch schon Software für den Nachfolger von Windows Vista?
Denn der Code existiert ja schon!Nein, natürlich nicht, denn das macht ihr frühstens mit dem erscheinen des ersten Release Candidaten.
Alles was davor war und ist zählt nicht und so ist es auch mit D.Wenn ihr also die 1.0 Version nicht akzeptieren wollt, dann könntet ihr gerade mal den Release Kandidaten, also 1.0RC nehmen, sofern es einen gibt.
-
Die Historie ist nicht das Problem, aber auch nicht gerade überzeugend. Es ist die mangelnde Praxisunterstützung. Solche Dinge müssen professionell gepusht werden. Dafür benötigt man ein geeignetes Marketingkonzept.
-
Hallo
Erhard Henkes schrieb:
Wieso dann könnte jeder Compilerbauer mit seine Sprache kommen und verlangen ne Sektion zu haben?
Nein, die Nähe zu C/C++ sollte entscheidend sein.
Entscheident sollte und ist wohl eher, wie viele Fragen es dazu gibt. Da fast niemand damit programmiert, wird es auch kaum Fragen geben -> kein Subforum.
chrische
-
@DEvent
Buildsysteme gibst es BUD und DSSS. Intregration nie gesehen, allerdings auch nicht danach geguckt.@Erhard Henkes
CodeBlocks würde ich nicht für D nehmen.
Vielversprechend ist DScite als Editor, welches mitgeliefert BUD hat. Descent hat zur Zeit als IDE stillstand. Die Entwickler haben wenig Zeit. Allerdings hat Descent nen Parser und Auto Completion, dafür kein Builder.
-
Shade Of Mine schrieb:
es gibt nur 2 schwache Compiler.
....
Mit Ruby konnte man schon von fast beginn an verwenden um zu programmieren
Der Vergleich hinkt gewaltig.
Ruby ist eine Scriptsprache, also solche ist Performance nachrangig.
Wenn bei Ruby Performance wichtig wäre, dann wäre es eine Sprache die compiliert wird, also Maschinencode erstellt wird,aber das ist nicht der Fall, denn Ruby wird interpretiert.
Es ist eine Scriptsprache.Daher ist der Vergleich nicht fair, den der Interpreter von Ruby war im 1.0 Status bestimmt nicht performant, also kannst du nicht sagen,
das Ruby vom ersten Tag einsetzbar ist wen du Ruby mit den gleichen
Maßstäben bewertest wie D, denn bei D ist dir die Performance des Compilers ja offensichtlich wichtig.Außerdem.
Die Compiler sind nur Implementierungen.
Sie sind nicht die Sprache selbst.Daher darf man eigentlich nicht die Compiler bei der Bewertung der Sprache D ansich in die Bewertung mit einbeziehen.
Das D mangels schneller Compiler momentan in der Praxis noch wenig einsatzfähig ist, ist ein Thema, aber es ist kein Thema um damit zu sagen, daß deswegen die Sprache schlecht ist.
-
Erhard Henkes schrieb:
Dennoch bin ich der Meinung , dass man hier im Forum eine Sektion D eröffnen sollte, da diese Sprache nun über ein Jahr "offiziell existiert" und eine wohl nicht zu leugnende Nähe zu C/C++ besitzt.
Bin dafür!
-
hhhh schrieb:
Der Vergleich hinkt gewaltig.
[...]
Das D mangels schneller Compiler momentan in der Praxis noch wenig einsatzfähig ist, ist ein Thema, aber es ist kein Thema um damit zu sagen, daß deswegen die Sprache schlecht ist.Komplette Themenverfehlung.
Geschwindigkeit ist mir jetzt egal. Die ist relevant wenn ich die Anwendung shippe. Vorher nicht.
Aber die Compiler sollen ordentlich funktionieren - aktuell ist es so, dass die beiden Compiler ziemlicher Schrott sind.
Und ich glaube ihr versteht das nicht: für Hobbyprojekte wo man mal was probieren will mag D nett sein, aber wenn ich eine Anwendung schreiben will die etwas produktives macht und ich in 2 Jahren den Code nicht wegschmeissen mag, dann ist D einfach die falsche wahl.
Es ist total egal welchen Zeitpunkt man als Stichtag hernimmt: D war unverwendbar, ist unverwendbar und bleibt es ein paar Jahre mindestens noch.
Erst wenn die D Compiler die Sprache gut unterstützen und es _eine_ standard library gibt die interface stabil ist - dann kann man sich überlegen ob man damit arbeiten kann. Dann brauche ich debugger, ich nehme an gdb wird laufen - also am besten gleich eine eclipse/netbeans integration machen. Intellisense ist noch nicht so wichtig, aber Projektverwaltung.
Dann etwas CPAN ähnliches wo es D libraries gibt und wrapper um c++ libraries. Und dann hat man massig code mit dem man arbeiten kann. Dann kann man anfangen programme zu entwicklen. Und das ist der Zeitpunkt wo man mit D arbeiten kann.
Das alles hat nichts mit der Sprache zu tun. Dass die Sprache selber auch einige fragwürdigen Ziele verfolgt ist dabei komplett aussen vorgelassen. D ist rein vom technischen standpunkt her heute nicht verwendbar.
wenn man es nur aus hobby sicht sieht, dann ist einem das egal - aber es gibt eben auch andere leute die Toolchains nach effektivität beurteilen und nicht nach hype oder nicht hype.
ich bin übrigens stark dafür dass ihr anfangt in D zu programmieren, weil dann sind die tools in 5 jahren vielleicht verwendbar und ich kann dann mit D3 endlich anwendungen erstellen. stören würde mich das nicht.
-
Ich habe nun mal folgendes gemacht:
auf http://www.digitalmars.com/d/download.html folgende Dateien gezogen:
dmd 2.014.zip und dmc.zip
extrahiert
und in Code::Blocks integriert (Compiler ... settings, toolchain exe, ...)... hat nicht funktioniert.
Also bitte: wo ist die Vorschrift, wie das geht?
-
Erhard Henkes schrieb:
Ich habe nun mal folgendes gemacht:
auf http://www.digitalmars.com/d/download.html folgende Dateien gezogen:
dmd 2.014.zip und dmc.zip
extrahiert
und in Code::Blocks integriert (Compiler ... settings, toolchain exe, ...)... hat nicht funktioniert.
Also bitte: wo ist die Vorschrift, wie das geht?
Ich wurde schon bei der ersten Google Suche fündig:
http://d.whosme.de/index.php?language=&site=tutorials
Der Trick ist im Google Suchfeld anstatt nur D, einfach "D Programming Language"
in gesetzten Gänsefüschen einzugeben und schon findet man alles zu D.
-
Seltsam
Erhard Henkes schrieb:
Ich habe nun mal folgendes gemacht:
auf http://www.digitalmars.com/d/download.html folgende Dateien gezogen:
dmd 2.014.zip und dmc.zip
extrahiert
und in Code::Blocks integriert (Compiler ... settings, toolchain exe, ...)... hat nicht funktioniert.
Also bitte: wo ist die Vorschrift, wie das geht?
Seltsam genau dies hat bei mir funktioniert o.O
-
Eclipse kann man übrigens auch als IDE für D schon verwenden, sihe obiger Link.
Und für OpenAL, OpenGL und die SDL gibt es Bindings um damit mit D zu programmieren.
Der Spieleprogrammierer hat also schonmal alles, was er zum proggen mit D braucht.