Kennt jemand von euch D ??? neue Prog. sprache?!?

[newkid]

eben nicht
muss ja nur einen findet bei dem es nicht zutrifft

ausserdem

wollte ich eigenlich ne kleine diskusion voranbringen wie z.b.

der typ spricht unwahrheiten
oder
ja ist echt mega überlegen
oder
heiße luft
oder
ja D wird bald von jeder firma gefragt sein
oder
denkt dir was aus

[Korbinian]

such mal danach. das thema ist alt und schon mehrfach durchgekaut

[??????]

Korbinian schrieb:

such mal danach. das thema ist alt und schon mehrfach durchgekaut

nach "D" kann man ja auch so toll suchen.

[Korbinian]

jo ist mir jetzt auch aufgefallen dann halt manuell durchklicken jedenfalls wurde das vor über nem halben jahr glaub schon mal ordentlich (5 seiten) durchgekaut

[Shade Of Mine]

?????? schrieb:

nach "D" kann man ja auch so toll suchen.

Aber nach digitalmars oder c++ nachfolger oder dem namen vom D erfinder oder oder oder

[newkid]

kann mir jemand diesen tollen 5 seiten post hier posten?
merci
danke
thx

[newkid]

[quote]Korbinian kennst du NBS????

[__me]

Hab spontan beim ersten Suchversuch direkt diesen Thread gefunden.

[Talla]

Also neu ist die auf keinen Fall, hab schon vor Jahren was dazu gelesen, aber irgendwie spricht die mich überhaupt nicht an. Wenn ich mir den Überblick so angucke sieht das echt nur aus wie nen Versuch das schlimmste aus allen Sprachen zusammenzumischen.

[__me]

Das schlimmste heißt?

Ich seh eigentlich größtenteils nur gutes (von der extrem bescheidenen Bibliothek mal abgesehen).

Ein GC und trotzdem RAII möglich ist schonmal sau geil.

Lambda-Ausdrücke, verschachtelte Funktionen, etc. ist auch cool.

Echte Templates sind auch nicht übel.

Ein foreach ist nie schlecht.

[K.a]

Seid mal realistisch.
Solch eine sprache wird sich nie durchsetzen. Ihr fehlt jede anbindung. Es wird sich nie jemand die mühe machen eine XLib für "D" zu programmieren. Zudem finde ich es unverschämt, eine sprache "D" zu nennen.
Ich denke dass niemand das recht hat, sich als nachfolger von C zu bezeichnen - zumindest nicht mit soetwas.
Auch sind verschachtelte funktionen sinnlos und verleiten zu schlampigem programmieren. Und was will ein programmierer mit foreach und assotiativen arrays? Warum schlüsselwörter für soetwas verwenden?
Das ist doch keine prozessornahe programmierung mehr. Habt ihr euch nie gefragt, warum man Basic nicht für grosse Projekte einsetzt? Ein durchschnittlicher programmierer sollte sich ein assoziatives array selber schreiben können.
Ein schlechter sollte ein fertiges aus einer libary verwenden (siehe C++ libary). Aber doch bitte keine schlüsselwörter.

[Ein Gast]

K.a schrieb:

Solch eine sprache wird sich nie durchsetzen. Ihr fehlt jede anbindung. Es wird sich nie jemand die mühe machen eine XLib für "D" zu programmieren.

Warum sollte jemand eine XLib für D programmieren, wenn er einfach die XLib, GTK oder was weiß ich verwenden kann?
D fehlt keine Anbindung, D kann einfach gegen C-Code gelinkt werden. Du mußt nur die passenden Import-Dateien aus den Headern erstellen. Dies ist einfacher als z.B. für Ada oder andere nicht C-Syntax-Sprachen.

Zudem finde ich es unverschämt, eine sprache "D" zu nennen.
Ich denke dass niemand das recht hat, sich als nachfolger von C zu bezeichnen - zumindest nicht mit soetwas.

Ich finde es unverschämt eine Sprache C++ oder C# zu nennen...

Auch sind verschachtelte funktionen sinnlos und verleiten zu schlampigem programmieren. Und was will ein programmierer mit foreach und assotiativen arrays? Warum schlüsselwörter für soetwas verwenden?
Das ist doch keine prozessornahe programmierung mehr.

Jipp, warum programmieren wir alle nicht einfach in Assembler, oder besser, warum nicht mit einem Hexeditor? Das ist Prozessornah!!!
Verschachtelte Funktionen sind mit ein Ersatz für Makros; hoffe Du erkennst, daß Makros zu fehlerhaftem Programmieren führen, da sie nicht type-safe sind.
Außerdem kannst Du in Ada verschachtelte Funktionen programmieren, und Du willst doch nicht behaupten, daß Ada zu schlampigem Programmieren verleitet, oder?
Assoziative Arrays haben kein Schlüsselwort, wo ist also das Problem? Foreach ist ein Schlüsselwort, ja und? Ist doch schön

Container!(Typ) a;
...
foreach ( Typ i; a )
  doSomething(i);

zu schreiben, anstelle irgendwelcher wilder Iterator-Sachen, man muß für einen Container lediglich einen Operator überladen. Und wenn Du auf den C++-Weg stehst, kannst Du immer noch eine eigene Template Library für D schreiben, bzw. warten bis die DTL fertig ist (die rein zufällig vom STLSoft-Programmierer erstellt wird).

Wenn Du an Deine Lieblingssprache so sehr gewöhnt bist, daß Dich eine Sprache wie D so aufregt, dann brauchst Du erst gar nicht eine andere Sprache anschauen. Ich jedenfalls halte D für eine gute Sprache mit einigen sehr schönen Sprach-Elementen, die einige Schwächen von C und C++ beseitigt, und einige Konzepte aus Sprachen wie Java, C# und Ada mitbringt.

[K.A]

Ein Gast schrieb:

K.a schrieb:

Solch eine sprache wird sich nie durchsetzen. Ihr fehlt jede anbindung. Es wird sich nie jemand die mühe machen eine XLib für "D" zu programmieren.

Warum sollte jemand eine XLib für D programmieren, wenn er einfach die XLib, GTK oder was weiß ich verwenden kann?
D fehlt keine Anbindung, D kann einfach gegen C-Code gelinkt werden. Du mußt nur die passenden Import-Dateien aus den Headern erstellen. Dies ist einfacher als z.B. für Ada oder andere nicht C-Syntax-Sprachen.

Ok das stimmt auch wieder. Aber trotzdem bin ich nicht überzeugt, dass die erweiterungen verbesserungen mit sich bringen. Teilweise vielleicht schon aber grössten teils nicht.

Zudem finde ich es unverschämt, eine sprache "D" zu nennen.
Ich denke dass niemand das recht hat, sich als nachfolger von C zu bezeichnen - zumindest nicht mit soetwas.

Ich finde es unverschämt eine Sprache C++ oder C# zu nennen...
[/quote]

C++ oder C# finde ich nicht unverschämt. Was gibt es daran auszusetzen sich als erweiterung zu betrachten? Ich finde es aber nciht gut sich als NACHFOLGER zu betrachten. Und ich sage das obwohl ich C# auch nicht mag.

Auch sind verschachtelte funktionen sinnlos und verleiten zu schlampigem programmieren. Und was will ein programmierer mit foreach und assotiativen arrays? Warum schlüsselwörter für soetwas verwenden?
Das ist doch keine prozessornahe programmierung mehr.

Jipp, warum programmieren wir alle nicht einfach in Assembler, oder besser, warum nicht mit einem Hexeditor? Das ist Prozessornah!!!
Verschachtelte Funktionen sind mit ein Ersatz für Makros; hoffe Du erkennst, daß Makros zu fehlerhaftem Programmieren führen, da sie nicht type-safe sind.
Außerdem kannst Du in Ada verschachtelte Funktionen programmieren, und Du willst doch nicht behaupten, daß Ada zu schlampigem Programmieren verleitet, oder?
Assoziative Arrays haben kein Schlüsselwort, wo ist also das Problem? Foreach ist ein Schlüsselwort, ja und? Ist doch schön

Container!(Typ) a;
...
foreach ( Typ i; a )
  doSomething(i);

zu schreiben, anstelle irgendwelcher wilder Iterator-Sachen, man muß für einen Container lediglich einen Operator überladen. Und wenn Du auf den C++-Weg stehst, kannst Du immer noch eine eigene Template Library für D schreiben, bzw. warten bis die DTL fertig ist (die rein zufällig vom STLSoft-Programmierer erstellt wird).
[/quote]

ok aber warum macht man dann nicht einfach eine normale for? Warum fügt man ein schlüsselwort hinzu, was nur geringe abkürzungen mit sich bringt!
Ehrlich gesagt mag ich auch an C++ die standard libary nicht. Die fertigen klassen finde ich nicht sehr gut gebrauchbar und schön. Auch ist der name der (template)klasse vektor unpassend.
Ich habe nichts gegen klassen aber gegen von der libary angebotene classen mit überladenen operatoren wie cout.
Ich glaube dass ein anfänger nur richtig begraift wie ein kompiler und C wirklcih funktioniert, wenn er mit printf und ähnlichen anfängt. Wenn es ihm dann gefällt, kann er ja dann immernoch cout verwenden.
Und zum prozessornah programmieren: Ich hoffe du weisst, dass um so weiter sich eine compiler-sprache davon entfernen versucht, umso langsamer das compilat ist? Ich bin kein Assembler-freak der sagt man müsse alles in assembler machen, aber ich denke C++ ist schon weit genug entfernt um gut damit zu programmieren - ja an manchen stellen vielleicht schon ein bisschen zu weit.

Wenn Du an Deine Lieblingssprache so sehr gewöhnt bist, daß Dich eine Sprache wie D so aufregt, dann brauchst Du erst gar nicht eine andere Sprache anschauen. Ich jedenfalls halte D für eine gute Sprache mit einigen sehr schönen Sprach-Elementen, die einige Schwächen von C und C++ beseitigt, und einige Konzepte aus Sprachen wie Java, C# und Ada mitbringt.

Ich rege mich nicht auf weil D eine andere sprache ist. Der einzige grund warum ich mich aufrege ist der name. Sonst finde ich, dass sprachelemente wie foreach überflüssig sind und das fehlen eines preprozessors(oder habe ich das flasch verstanden?) nicht akzeptabel ist für ein grosses projekt. Weitere elemente wie assotative arrays sind überflüssig finde ich.
Ich selber würde an C++ noch einiges verbessern, an ANSI C jedoch nichts.

[Shade Of Mine]

K.A schrieb:

ok aber warum macht man dann nicht einfach eine normale for?

Weil foreach einfach passt.
foreach geht ueber jedes element, klar ist for dass ueber alle elemente iteriert auch nicht so schwer zu schreiben, aber beachte mal:

for(list<string>::iterator i=l.begin(); i<l.end(); i++)

Wieviele Fehler stecken darin?
ein

foreach(string s in l)

ist kuerzer, schoener und fehlerfreier.

Ich glaube dass ein anfänger nur richtig begraift wie ein kompiler und C wirklcih funktioniert, wenn er mit printf und ähnlichen anfängt. Wenn es ihm dann gefällt, kann er ja dann immernoch cout verwenden.

Dir ist schon klar, dass dank printf() der einstieg in c verdammt schwer ist? weil man dauernd den falschen format specifier erwischt (passiert sogar mir ab und zu) also gerade anfaenger sollten printf meiden, weil es zu komplex ist (und nichts zu dem verstaendnis der sprache beitraegt)

und selbst wenn jemand printf verstanden hat, dann bringt es einem doch in bezug auf sprache/compiler etc. ueberhaupt nicht weiter...

Und zum prozessornah programmieren: Ich hoffe du weisst, dass um so weiter sich eine compiler-sprache davon entfernen versucht, umso langsamer das compilat ist? Ich bin kein Assembler-freak der sagt man müsse alles in assembler machen, aber ich denke C++ ist schon weit genug entfernt um gut damit zu programmieren - ja an manchen stellen vielleicht schon ein bisschen zu weit.

aber der faktor ist laecherlich gering. die einfuehrung einer VM als abstraktionsebene ist ja ein riesen schritt weg von asm, oder? und um welchen faktor ist java langsamer als c++? verschwindend gering. weil durch die abstraktion wieder neue arten der optimierung moeglich sind.

Ich rege mich nicht auf weil D eine andere sprache ist. Der einzige grund warum ich mich aufrege ist der name.

Und C# (Cis, C um 1 erhoeht) stoert dich nicht?
Oder C++, welches ja der Nachfolger von C ist.
Oder C, welches der nachfolger von B ist?

und das fehlen eines preprozessors(oder habe ich das flasch verstanden?) nicht akzeptabel ist für ein grosses projekt.

Verdammt. Und ich war immer der Meinung mit Java, PHP, Python, C# etc. koennte man auch grosse Projekte machen

Ich selber würde an C++ noch einiges verbessern, an ANSI C jedoch nichts.

na das ist interessant. klaer uns mal auf.

[K.a]

Shade Of Mine schrieb:

K.A schrieb:

ok aber warum macht man dann nicht einfach eine normale for?

Weil foreach einfach passt.
foreach geht ueber jedes element, klar ist for dass ueber alle elemente iteriert auch nicht so schwer zu schreiben, aber beachte mal:

for(list<string>::iterator i=l.begin(); i<l.end(); i++)

Wieviele Fehler stecken darin?
ein

foreach(string s in l)

ist kuerzer, schoener und fehlerfreier.

schöner - ja. Aber nur weil list<string>::iterator unschön ist. Das kann man viel schöner programmieren, indem man den iterator oben in der funktion lokal definiert. Dann ist es übersichtlich und man ist sich immer im klaren, welche lokalen variablen erzeugt sind.

Shade Of Mine schrieb:

Ich glaube dass ein anfänger nur richtig begraift wie ein kompiler und C wirklcih funktioniert, wenn er mit printf und ähnlichen anfängt. Wenn es ihm dann gefällt, kann er ja dann immernoch cout verwenden.

Dir ist schon klar, dass dank printf() der einstieg in c verdammt schwer ist? weil man dauernd den falschen format specifier erwischt (passiert sogar mir ab und zu) also gerade anfaenger sollten printf meiden, weil es zu komplex ist (und nichts zu dem verstaendnis der sprache beitraegt)

und selbst wenn jemand printf verstanden hat, dann bringt es einem doch in bezug auf sprache/compiler etc. ueberhaupt nicht weiter...

ich denke dass es einen anfänger sehr verwirrt, wenn er nicht begreift, dass der << operator von cout nur eine funktion ist und nichts "was der prozessor macht". Normalerweise ist << ja ein bitshifting opetator, wie du sicher weisst.
Wenn er printf allerdings wie jede funktion verwendet, die er selber auch schreiben kann, begreift er dass dahinter programmcode steckt, der aufgerufen wird. Und er hat vom programm ein ganz anderes verständnis nicht wie anfänger und sogenannten "profis" sagen :"Das der computer das halt ausführt".
Er versteht das programm aus einer sammlung von aneinandergehängten funktionen - so wie es auch wirklich ist und nicht aus "befehlen die der cumputer kann".

Shade Of Mine schrieb:

Und zum prozessornah programmieren: Ich hoffe du weisst, dass um so weiter sich eine compiler-sprache davon entfernen versucht, umso langsamer das compilat ist? Ich bin kein Assembler-freak der sagt man müsse alles in assembler machen, aber ich denke C++ ist schon weit genug entfernt um gut damit zu programmieren - ja an manchen stellen vielleicht schon ein bisschen zu weit.

aber der faktor ist laecherlich gering. die einfuehrung einer VM als abstraktionsebene ist ja ein riesen schritt weg von asm, oder? und um welchen faktor ist java langsamer als c++? verschwindend gering. weil durch die abstraktion wieder neue arten der optimierung moeglich sind.

Was höre ich da? Java soll verschwindend gering langsamer sein als C++? Und PHP ist so schnell wie assembler oder wie?
Java ist ein 100tstel so schnell wie C++.
Probier's aus!

Shade Of Mine schrieb:

Ich rege mich nicht auf weil D eine andere sprache ist. Der einzige grund warum ich mich aufrege ist der name.

Und C# (Cis, C um 1 erhoeht) stoert dich nicht?
Oder C++, welches ja der Nachfolger von C ist.
Oder C, welches der nachfolger von B ist?

D ist einfach zu allgemein. C++ und C# beinhalten immer noch C und bezeichnen sich somit nicht als nachfolger!

Shade Of Mine schrieb:

und das fehlen eines preprozessors(oder habe ich das flasch verstanden?) nicht akzeptabel ist für ein grosses projekt.

Verdammt. Und ich war immer der Meinung mit Java, PHP, Python, C# etc. koennte man auch grosse Projekte machen

Ich wiederhole mich: ungeeignet.
Wie willst du mit D cross-compilieren ohne pre-prozessor?
Wie willst du mit -D_DEBUG compilieren ohne pre-prozessor?
Pre-prozessor hat sehr viele vorteile.

Shade Of Mine schrieb:

Ich selber würde an C++ noch einiges verbessern, an ANSI C jedoch nichts.

na das ist interessant. klaer uns mal auf.

[!quote]

Das habe ich bereits gesagt.
zitat von mir selbst:

K.A schrieb:

Ehrlich gesagt mag ich auch an C++ die standard libary nicht. Die fertigen klassen finde ich nicht sehr gut gebrauchbar und schön. Auch ist der name der (template)klasse vektor unpassend.
Ich habe nichts gegen klassen aber gegen von der libary angebotene classen mit überladenen operatoren wie cout.
Ich glaube dass ein anfänger nur richtig begraift wie ein kompiler und C wirklcih funktioniert, wenn er mit printf und ähnlichen anfängt. Wenn es ihm dann gefällt, kann er ja dann immernoch cout verwenden.

[SideWinder]

Lustig zu lesen hier

MfG SideWinder

[operator void]

__me schrieb:

Ein foreach ist nie schlecht.

Es zeigt aber IMHO das Problem hinter der D-Philosophie. foreach ersetzt jetzt std::for_each durch etwas "Schöneres". Und wo bleibt ein sort, das std::sort ersetzt? usw. - Hätte man die Mittel bereit gestellt, damit man sich ein benutzbares foreach selbst schreiben kann (so wie Enumerable#each in Ruby z.B.), hätte man mit einer allgemeineren Lösung nicht nur die Spitze des Eisbergs kaschiert.
Oder um ein anderes Beispiel zu bringen, D stellt für Strings einen eingebauten Typ bereit (verschiebt die Arbeit also in den Compiler), der dann nicht mehr die Probleme von C++-Strings hat. Wieder wäre es mir lieber, die Sprache wüsste nichts über Strings (oder dynamische Arrays im allgemeinen, denn solche sind Strings ja in D) und würde es ermöglichen, eine schönere Stringklasse in der Sprache selbst zu schreiben.
D = Flickenlösung

[Shade Of Mine]

K.a schrieb:

schöner - ja. Aber nur weil list<string>::iterator unschön ist. Das kann man viel schöner programmieren, indem man den iterator oben in der funktion lokal definiert. Dann ist es übersichtlich und man ist sich immer im klaren, welche lokalen variablen erzeugt sind.

Von dem iterator rede ich ja garnicht. aber hast du alle fehler gefunden?
kleiner tipp, es sind 3.
und das in dieser unschuldigen zeile...

ich denke dass es einen anfänger sehr verwirrt, wenn er nicht begreift, dass der << operator von cout nur eine funktion ist und nichts "was der prozessor macht". Normalerweise ist << ja ein bitshifting opetator, wie du sicher weisst.

bitshifting ist fuer den anfaenger aber noch uninteressanter.
und wozu wissen dass << eine funktion ist?
cout<<was_auch_immer;
gibt was_auch_immer aus, ohne dass ich den typen kennen muss.

das ist ja ein kleiner teil der oo philosphie. der typ ist egal, nur das objekt zaehlt.

natuerlich versteht das der anfaenger jetzt noch nicht, aber der mechanismus wird ihm praktisch erscheinen und irgendwann wird er es kapiert haben.

Wenn er printf allerdings wie jede funktion verwendet, die er selber auch schreiben kann, begreift er dass dahinter programmcode steckt, der aufgerufen wird.

Klar, printf() ist ja trivial, gell?
variadic functions sind etwas, dass ein anfaenger nicht braucht und selbst profis nur sehr selten. also wozu gleich am anfang lernen?
und wieso sich ab muehen und die format specifier lernen, die man dann sowas irgendwann verwechselt und so viele bugs einbaut?

Er versteht das programm aus einer sammlung von aneinandergehängten funktionen - so wie es auch wirklich ist und nicht aus "befehlen die der cumputer kann".

Aber ein programm ist ja eben _mehr_ als das.
ein programm ist nicht ein "fuehere befehl nach befehl aus".
auf der untersten ebene ist es natuerlich schon, aber wozu fuehren wir dann die abstraktionsschichten ein?

Was höre ich da? Java soll verschwindend gering langsamer sein als C++? Und PHP ist so schnell wie assembler oder wie?
Java ist ein 100tstel so schnell wie C++.
Probier's aus!

Probier du es doch aus. schau dich hier um, hier gab es schon benchmarks.
idr musste man in beiden sprachen etwas tweaken um die maximale leistung herauszuholen und c++ hat zwar immer gewonnen, aber 1) oft mit mehr aufwand und 2) nur mit geringem unterschied. faktor 2-5 etwa.

was na java so lahm ist, ist swing.

D ist einfach zu allgemein. C++ und C# beinhalten immer noch C und bezeichnen sich somit nicht als nachfolger!

doch, tun sie. sie beinhalten zwar C, sehen sich aber dennoch als nachfolger an. zumindest c++ wird auch offiziell als nachfolger angesehen.

Ich wiederhole mich: ungeeignet.
Wie willst du mit D cross-compilieren ohne pre-prozessor?
Wie willst du mit -D_DEBUG compilieren ohne pre-prozessor?
Pre-prozessor hat sehr viele vorteile.

Schau dir D an, dann wirst du sehen, dass du einen PP braucht.

Ehrlich gesagt mag ich auch an C++ die standard libary nicht. Die fertigen klassen finde ich nicht sehr gut gebrauchbar und schön. Auch ist der name der (template)klasse vektor unpassend.

vector ist aber ein aktzeptierter begriff dafuer.

Ich habe nichts gegen klassen aber gegen von der libary angebotene classen mit überladenen operatoren wie cout.

cout ist kein operator
und es haben kaum klassen den op<< ueberladen, nur die, bei denen es sinn macht, wie zB string.

dein problem ist, dass du keine argumente dafuer bringst.

[MasterCounter]

Ich hab mir jetzt nicht die ganze Übersicht durchgelesen, aber ganz unten ist ein beispiel D Programm (man sieht "D" sch... aus )

Sample D Program (sieve.d)

/* Sieve of Eratosthenes prime numbers */

bit[8191] flags;

int main()
{ int i, count, prime, k, iter;

printf("10 iterations\n");
for (iter = 1; iter <= 10; iter++)
{ count = 0;
flags[] = 1;
for (i = 0; i < flags.length; i++)
{ if (flags[i])
{ prime = i + i + 3;
k = i + prime;
while (k < flags.length)
{
flags[k] = 0;
k += prime;
}
count += 1;
}
}
}
printf ("\n%d primes", count);
return 0;
}

Das sieht doch irgendwie wie c aus ,
oder hab ich da was falch verstanden?

[Shade Of Mine]

MasterCounter schrieb:

Das sieht doch irgendwie wie c aus ,

Schau dir das Programm in Java an.
statt printf nimmt man println aber sonst ist es doch essentiell das selbe.

oder hab ich da was falch verstanden?

keine ahnung was du erwartet hast, aber D hat sich C++ als grundlage ausgesucht. da sind die aehnlichkeiten durchaus erwuenscht.