Nach C kommt D ...

Seite 1 von 2 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/nach_c_kommt_d_174254/page_1 - zur Vollversion wechseln!

JC schrieb am 03.01.2007 um 16:25

Nach Jahren der Entwicklung hat nun Walter Bright die objektorientierte Programmiersprache D fertiggestellt. Die Version 1.0 ist sowohl von C++, C# und Java beeinflusst und soll dabei sämtliche Stärken in sich vereinen - ohne überflüssigen Ballast! Die fertige Version steht auf den Seiten von Digital Mars zum Download bereit; die ZIP-Datei hat Binaries für Windows und Linux inkludiert.

moidaschl schrieb am 03.01.2007 um 16:32

klingt sehr ansprechend , aber die Seite ist anscheinend hoffnungslos überfordert oder einfach nur so down.

Joe_the_tulip schrieb am 03.01.2007 um 17:01

klingt gut. Vielleicht lern ich doch mal ne Programmiersprache

Frys_Assassin schrieb am 03.01.2007 um 17:25

Hm, ich hab jetzt nur einen Blick auf die Comparison Table geworfen und bin mir nicht sicher was ich davon halten soll.
Ich bin froh dass es einen potentiellen Ablöser für das in die Jahre gekommene C++ gibt.
Imho steigt und fällt die mögliche Marktdurchdringung auch mit der Qualität des GUI Designers. Da ist .Net um einiges voraus.
Für D gibts einen Port der SWT. Naja, ich weiss nicht. Ich mag die Java GUIs nicht so wirklich.
Performance ist natürlich ein absolutes plus, nähere Benchmarks wären gut. Daher wirds auch für die Spieleentwicklung vermutlich interessant, wo die Anzeige sowieso primär über OpenGL/DirectX stattfindet.

ica schrieb am 03.01.2007 um 18:02

irgendwie bezweifle ich, dass sich das durchsetzen wird. heutzutage muss da imho schon eine große firma wie ms bei .net oder sun bei java im hintergrund sein.

fresserettich schrieb am 03.01.2007 um 19:40

Zitat von iCA-
irgendwie bezweifle ich, dass sich das durchsetzen wird. heutzutage muss da imho schon eine große firma wie ms bei .net oder sun bei java im hintergrund sein.

hab ich mir auch gedacht, allerdings liegt es nicht nur allein an den firmen, sondern man kann ja auch als informatiker was machen und wenn es wirklich so wie es im artikel bei heise beschrieben ist ziemlich gut sein soll wird es wohl über kurz oder lang eine alternative zu java, c# und c++ darstellen

gue schrieb am 03.01.2007 um 20:09

Habe mir die Sprache jetzt ein bisschen angesehen. Fazit: Mir gefällt sie nicht und ich wüsste nicht, warum ich damit etwas schreiben wollte.
Einige Kritikpunkte:
- Der Präprozessor fällt zwar weg, dafür bleibt aber noch das gottverdammte typedef. Auch "type inference" und alias trägt nicht zur Lesbarkeit bei.
- Zu viele Schlüsselwörter, statt modernerer Techniken wie Annotationen. Beispiel: unittest Schlüsselwort statt z.B. [Test]-Annotation in C#.
- Kein OO-Ansatz: "Freie Funktionen", Standardrepräsentation von Strings ist ein char[] (C lässt grüßen).
- Außerdem frage ich mich, ob der GC hier besser funktioniert als in bisherigen Native-Umgebungen. Wurzelelemente (Register+Stacks) müssen laut der Webseite "gescannt" werden, ich nehme an, dass da wieder Zeiger erraten werden :rolleyes:

So viel erstmal nach den ersten 15 Minuten.
Vielleicht hab ich auch einfach nur Angst, wieder was neues lernen zu müssen und seh deshalb so viele Kritikpunkte

Frys_Assassin schrieb am 03.01.2007 um 22:06

Was ich auch vermisse ist die Möglichkeit Reflections einzusetzen. Gehört find ich zu einer modernen OOPSprache. Man kanns zwar auch ziemlich hässlich einsetzen, aber wenn man sich bemüht ist der Umgang damit doch ziemlich elegant.

that schrieb am 04.01.2007 um 01:08

Zitat von gue
- Der Präprozessor fällt zwar weg, dafür bleibt aber noch das gottverdammte typedef. Auch "type inference" und alias trägt nicht zur Lesbarkeit bei.
- Kein OO-Ansatz: "Freie Funktionen",

Was ist an typedef oder type inference schlecht?
Oder anders: was ist an "MeineSuperTolleJavaKlasse x = new MeineSuperTolleJavaKlasse(123);" oder an "for (map<string,list<int> >::const_iterator i = bla.begin(); ... )" so gut?

Und was ist deine bevorzugte Alternative zu "freien Funktionen"?

mat schrieb am 04.01.2007 um 05:31

den präprozessor wegfallen lassen und wie in java static variablen definieren? nicht einmal wenn das 100% gleich vom compiler interpretiert werden würde, wäre das wünschenswert.

und was ist nochmal an header files so schlecht? in java sind meine klassen im komplett zugemüllt. einzig und allein die template header dll-grenzensache (wer das kennt weiss was ich mein) nervt, aber dafür kann c/c++ herzlich wenig.

gue schrieb am 04.01.2007 um 10:25

Zitat von that
Was ist an typedef oder type inference schlecht?

Ganz einfach: Es ist nicht lesbar. Wenn irgendwo steht MeineSuperTolleJavaKlasse x = new MeineSuperTolleJavaKlasse(123); dann weiß ich genau, was da passiert. Wenn ich zuerst 5 typedefs in irgendwelchen Header-Files oder Dokus nachlesen muss, dann ist das nicht besonders praktisch, oder?
Noch schlimmer wird das mit type inference: Viele Programmierer werden selbst nicht mehr wissen, welchen Typ sie da verwenden. "Ähm was liefert die Funktion noch mal zurück? Wurscht - auto x = func(); writeline(x);"

Zitat
Und was ist deine bevorzugte Alternative zu "freien Funktionen"?

Ähm... KEINE freien Funktionen?

Buschmann schrieb am 07.01.2007 um 21:22

Zitat von gue
Zitat von r4pt0R^-
Inwieweit kann man die dpi bei der Habu umstellen?

In diesem Fall hat der Programmierer versagt. Wie so oft kommt es darauf an wie es eingesetzt wird. typedef std::map < std::string, std:

air < A, B > > ::iterator ABPairIterator wird aus gutem Grund oft verwendet, und verständlich ists wohl, oder? Wenn ein Programmierer eine Instanz einer Rendererklasse nicht "renderer" sondern "apfelbaum" nennt, sind jetzt Objekte schlecht?

Zitat
Noch schlimmer wird das mit type inference: Viele Programmierer werden selbst nicht mehr wissen, welchen Typ sie da verwenden. "Ähm was liefert die Funktion noch mal zurück? Wurscht - auto x = func(); writeline(x);"

Hier dasselbe. Type inference kann leicht missbraucht werden, würde aber die umständlichen Iteratorinstanzen ohne dem von dir so verhassten typedef lösen (und einige andere nette Dinge erlauben). Btw. kommt Type Deduction in C++0x rein, das ist ein Äquivalent zu Type Inference.

Zitat
- Kein OO-Ansatz: "Freie Funktionen", Standardrepräsentation von Strings ist ein char[] (C lässt grüßen).

"Freie Funktionen" gibt es in C++ und in D ohnehin nicht wirklich. Die Funktionen, die du meinst, sind halt Teil des globalen Namespace. Und nein, nicht alles macht in Klassen Sinn.

Offenbar hast du auch von C keine Ahnung, denn dort ist die Standardrepräsentation ein char* Pointer zu einem Array, nicht das Array selbst. D kann Arrays direkt managen, C kennt Arrays nicht als eigenen Datentyp (der [] operator ist nur ein Index in einen Speicherbereich), daher sind Buffer overflows so leicht und diese einzudämmen so schwer (D weiss über Arraygrößen Bescheid, C logischerweise nicht). Ich hätte mir zwar auch eine echte Stringklasse als Standardrepräsentation gewünscht, aber char[] ist nicht schlecht.

Zitat
- Zu viele Schlüsselwörter, statt modernerer Techniken wie Annotationen. Beispiel: unittest Schlüsselwort statt z.B. [Test]-Annotation in C#.

Das ist reine Geschmackssache. Was ist an [Test] moderner als an unittest Test ?

Zitat von mat
Zitat von gue
Zitat von r4pt0R^-
Inwieweit kann man die dpi bei der Habu umstellen?

Headerfiles sind ein Hack, mehr nicht. Schon allein die Existenz von Include Guards beweist das (Fälle, die diese Guards nicht benötigen, sind eher selten und großteils nur bei C-Programmen zuhause). Headerfiles werden immer vom Präprozessor inkludiert, der Compiler hat dann eine Riesenwurscht vor sich, darum ist es guter Stil viele Forward declarations zu verwenden, um Compilezeiten zu verbessern. Systemspezifische Header wie windows.h sind AUCH drin, was v.a. bei plattformunabhängigen Code sehr problematisch sein kann. Last but not least fügt der Präprozessor auch private Klassenmembers ein - eine absolut sinnlose Aktion.

Die Templatesache ist teils auch ein C++-Problem. Ein System wie in Pascal mit Units und Interfaces wäre für C++ wohl das praktischste. Komplette Umstellung in das 1-File-System wäre wohl zu schwer (v.a. bei Templates).

Und, wenn deine Javafiles zugemüllt sind, solltest du an deinem Stil arbeiten, denn das ist die Zukunft. Künstliche Trennungen gibt es eher selten, und bei C war das kein Feature, sondern eine Konsequenz aus damaligen Compilern...

that schrieb am 07.01.2007 um 23:33

Zitat von gue
Ganz einfach: Es ist nicht lesbar. Wenn irgendwo steht MeineSuperTolleJavaKlasse x = new MeineSuperTolleJavaKlasse(123); dann weiß ich genau, was da passiert. Wenn ich zuerst 5 typedefs in irgendwelchen Header-Files oder Dokus nachlesen muss, dann ist das nicht besonders praktisch, oder?

Was ist an

var x = new MeinSuperTollesJavaScriptObjekt(123);

oder

auto x = "Hallo";

nicht lesbar?

Zitat von gue
Noch schlimmer wird das mit type inference: Viele Programmierer werden selbst nicht mehr wissen, welchen Typ sie da verwenden. "Ähm was liefert die Funktion noch mal zurück? Wurscht - auto x = func(); writeline(x);"

Wenns das Richtige tut, wo ist dann genau das Problem? Dein Code gibt offensichtlich das Ergebnis von "func()" aus. Da die Funktion in der Praxis irgendeinen vernünftigen Namen statt "func" hat, ist auch ersichtlich, was hier ausgegeben wird. Stünde statt "auto" irgendein Klassenname dort, muss man auch erst in allen möglichen Headerfiles nachschauen, ob diese Klasse von irgendwas abgeleitet ist, das ausgebbar ist oder einen Konvertierungsoperator auf irgendwas implementiert, das writeline ausgeben kann.

Zitat von gue
Ähm... KEINE freien Funktionen?

Und wo tut man dann Funktionen hin, die z.B. nur mit Library-Klassen etwas tun? Die Libraryklasse erweitern geht ja nicht, und extra dafür eine Klasse mit einer static-Methode zu schreiben ist nur ein aufwändiger Workaround für "OO"-Programmiersprachen, die es nicht besser können.

Bowser schrieb am 07.01.2007 um 23:45

Schaut zumindest interessant aus. Obs wirklich besser is wird sich noch herausstellen und selbst dann wirds noch Jahre dauern bis es sich durchsetzt. Ich werd das auf jeden Fall genauer im Auge behalten.

mat schrieb am 08.01.2007 um 06:08

Zitat von Buschmann
Headerfiles sind ein Hack, mehr nicht. Schon allein die Existenz von Include Guards beweist das (Fälle, die diese Guards nicht benötigen, sind eher selten und großteils nur bei C-Programmen zuhause). Headerfiles werden immer vom Präprozessor inkludiert, der Compiler hat dann eine Riesenwurscht vor sich, darum ist es guter Stil viele Forward declarations zu verwenden, um Compilezeiten zu verbessern. Systemspezifische Header wie windows.h sind AUCH drin, was v.a. bei plattformunabhängigen Code sehr problematisch sein kann. Last but not least fügt der Präprozessor auch private Klassenmembers ein - eine absolut sinnlose Aktion.

Die Templatesache ist teils auch ein C++-Problem. Ein System wie in Pascal mit Units und Interfaces wäre für C++ wohl das praktischste. Komplette Umstellung in das 1-File-System wäre wohl zu schwer (v.a. bei Templates).

Und, wenn deine Javafiles zugemüllt sind, solltest du an deinem Stil arbeiten, denn das ist die Zukunft. Künstliche Trennungen gibt es eher selten, und bei C war das kein Feature, sondern eine Konsequenz aus damaligen Compilern...

ich habe einige zeit über deinen post nachgedacht und mir fällt nicht wirklich ein grund ein warum header files unbedingt nötig wären. die saubere trennung zwischen definition und deklaration ist dabei genausowenig ein argument wie die von dir genannten include guards (die problemlos mit einer weiteren präprozessoranweisung rationalisiert werden könnten). vl ist es einfach nur aus dem grund, weil man es seit so vielen jahren macht, dass man nicht mehr darüber nachdenkt. allerdings sind nicht alle deine argumente wirklich stichhaltig. plattformunabhängiger code wird keinesfalls durch headers erschwert. mit der richtigen abstraktion kann man problemlos ohne schwindligen präprozessoranweisungen auskommen. heutige computer erlauben das in den meisten anwendungsgebieten und gekonntes oop ist auf alle fälle performanter als zB irgendwelche dynamischen bindings oder VMs.

btw: die diskussion läuft in die falsche richtung. features by design, wie zB der nicht vorhandene garbagecollector oder allgemeiner zugriff per pointer _sind_ c++. wer für seine projekte zB eine sicherere, übersichtlichere und und und .. sprache braucht und dafür performance, komplette benutzerdefinierbarkeit und und .. hergeben möchte, der ist mit einer sprache wie d, java oder c# vl besser unterwegs. "c/c++ ist nur das werkzeug, auswahl/benutzung bestimmt der handwerker"

ps: mein stil in java ist ausgereift. ich bin nur einfach kein fan von final static variablen.