Hallo an alle Programmierer. Vielleicht gibts jetzt nach diesem Thread wieder eine Diskusion C++ vs Java vs C# usw. Hab heute mal etwas nach der Programmiersprache D recherchiert und muss sagen, das hört sich ja nicht so schlecht an. Da diese noch eher jung ist sind die Bibliotheken noch am entstehen (aber FLTK4D gibts auch schon :) ) und somit ist der Einstieg noch nicht so ganz einfach. Als positiv finde ich, dass ne fertige EXE raus kommt (kein Framework oder so), .h-Files nicht mehr benötigt werden und ein GC ist auch vorhanden soweit ich das mitbekommen habe. Ich selbst hab noch Probleme ein Hello-World zu kompilieren (mit dem GDC). Wo seht Ihr D in so ca. 10 Jahren? Hat vielleicht schon jemand mehr Erfahrungen damit? mfg Weinga-Unity
Kurze Antwort zum Gesamtkonzept: Hat sehr viele Probleme von C/C++ nicht, lässt sich auch für hardwarenahe Sachen benutzen u.v.a.m., ist dafür aber genauso undynamisch, kennt weder Reflection/Introspection oder dynamische Codegenerierung etc. In zehn Jahren: Wird es, wie schon viele andere, in der Versenkung verschwunden sein. Wie viel wird denn z.B. noch in der IMO besten dynamischen OO-Sprache aka Smalltalk entwickelt, wieviele benutzen (noch) Pascal, Haskell (ausserhalb der Unis) etc. Die einzigen Sprachen, die momentan die Aussicht haben noch in ein paar Jahren verwendet zu werden (und nicht nur zur Pflege irgendwelcher Uraltsachen), dürften Java/C++/C# und vielleicht Ruby sein (wenn die Entwicklung von C++ eine etwas andere Richtung nimmt).
Ich denke das die Zukunft eher den Plattformunabhängigen "Interpreter"sprachen gehören wird da mit der stetig steigenden Rechenleistung der Prozessoren und des immer größer werdenden Speichers der geringe Unterschied nicht mehr in's Gewicht fallen wird. Es gibt ja schon Mikrocontroller die Java in Hardware gegossen haben. C, C++ und vielleicht D werden ihren Platz als systemnahe Sprachen behalten, weil ohne die keine Hardwarezugriffe möglich sind, aber zb Microsoft wird den Großteil der höheren Applikationen wohl frühere oder später auf C# umstellen
> Die einzigen Sprachen, die momentan die Aussicht haben noch in ein paar > Jahren verwendet zu werden (und nicht nur zur Pflege irgendwelcher > Uraltsachen), dürften Java/C++/C# und vielleicht Ruby sein Nana, so schnell verschwinden Sprachen nicht von der Bildfläche. Da gibt es noch diverse andere, welche sich noch eine ganze Weile halten werden, ob man das nun will/mag oder nicht (schon mal was von COBOL gehört?). Und wenn sich z.B. deiner Meinung nach Ruby halten wird, dürften sich Perl und Python erst recht halten. Die haben beide eine grössere Userbase, und Python ist eigentlich auch ganz nett (was ich persönlich von Perl nicht behaupten kann).
> Ich denke das die Zukunft eher den Plattformunabhängigen > "Interpreter"sprachen gehören wird da mit der stetig steigenden > Rechenleistung der Prozessoren und des immer größer werdenden Speichers > der geringe Unterschied nicht mehr in's Gewicht fallen wird. Man muss hier ganz klar nach Anwendung differenzieren. Mindestens 4 grundsätzlich unterschiedliche Gebiete mit völlig verschiedenen Anforderungen und Programmiersprachen fallen mir ein: - Anwendungsentwicklung für Personalcomputer - Embedded- und Betriebssystementwicklung - Webapplikationen (client- und serverseitig) ( - Plattformspezifisches Scripting (Batch, Shellscript, VBA, ...) Alle Bereiche haben ihre etablierten Sprachen, und ich sehe in keinem Bereich allzugrosse Dynamik. Allgemein geht es natürlich hin zu höherer Abstraktion, aber die heutigen Sprachen werden weiterhin den Löwenanteil ausmachen: Die heutigen Programmiersprachen sind eigentlich völlig ausreichen, einzig eine teilweise höhere Abstraktion von typischen Aufgaben wäre nützlich - doch sobald man dies tut, wird die Sprache automatisch weniger allgemein.
>- Anwendungsentwicklung für Personalcomputer
Ich würde das sogar noch aufsplitten in "große Anwendungen" wie zb einen
Email Client und in "kleine Tools" wie zb einen Taschenrechner. Für den
Taschenrechner würde ich nie eine Eclipse RCP verwenden sondern eher
Python und Qt4 oder GTK oder sogar gleich Tkinter
> Ich würde das sogar noch aufsplitten in "große Anwendungen" wie zb einen > Email Client und in "kleine Tools" wie zb einen Taschenrechner. Für den > Taschenrechner würde ich nie eine Eclipse RCP verwenden sondern eher > Python und Qt4 oder GTK oder sogar gleich Tkinter ...auch Computergames müsste man noch irgendwo unterbringen. Gerade neuere Spiele mit mächtigen Online- und Modding-Fähigkeiten entwickeln sich ja teilweise zu riesigen Systemen.
Weinga-Unity wrote: > Wo seht Ihr D in so ca. 10 Jahren? Hat vielleicht schon jemand mehr > Erfahrungen damit? Die Datentypen sind genaus besch... wie in C und obwohl in der Designphase offensichtlich sein musste, dass die Migration 32bit zu 64bit ansteht, wurde rein garnichts dafür getan, dies zu erleichtern.
Wozu braucht man schon 64 Bit... 4 Milliarden ist groß genug für die meisten Variablen.
*.* wrote: > Wozu braucht man schon 64 Bit... 4 Milliarden ist groß genug für die > meisten Variablen. Wenn man keine Ahnung hat? ...
Ja dann erkäre mal was Du besser weißt (will nicht dumm sterben). Mit der Pointer-Breite kommste in C eh kaum in Berührung. Was braucht es da für Innovationen?
Ich glaube, dass die Add-Ons von D gegenüber C++ zu wenig sind und das Gewicht von Walter Bright bzw. seiner Firma viel zu gering ist, um D einen nennenswerten "Marktanteil" zu verschaffen. Fortran hat sich damals durchgesetzt, weil es von IBM gepusht wurde, Algol, obwohl fortschrittlicher, nicht. C hat sich durchgesesetzt, weil es mit Unix zusammen vertrieben wurde. Nachdem Unix das Standardbetriebssystem für Workstations wurde, war es naheliegend, dass jeder darauf in C programmierte, was dazu führte, dass es sich langsam auch auf Nicht-Unix-Rechnern ausbreitete. C++, obwohl von einer Einzelperson entwickelt, wurde trotzdem akzeptiert, weil es auf C mit OO verbindet. C konnte damals schon jeder, und OO wurde gerade so megahipp, so dass sich wahrscheinlich alles, was irgendwie mit C und OO zu tun hat, regelrecht aufgesaugt worden wäre. Bei Java war's dann der Internet-Hype und die Möglichkeit, damit Applikationen portabel im Web-Browser auszuführen. C# bietet gegenüber C++ und Java eigentlich keine grundlegend neue Features, geschweige denn neue Programmierparadigmen. Es versucht vielmehr, die Vorteile der beiden in einer einzigen Sprache zu vereinen. Käme C# nicht von Microsoft, wäre die Sprache wahrscheinlich kaum publik geworden, weil sie für Freaks (die so etwas normalerweise als erste aufgreifen) zu wenig Pepp hat. D ähnelt in dieser Hinsicht C#, aber es gibt eben keine Firma Microsoft oder IBM, die dahinter steht. Es gibt einfach viel zu viele Programmiersprachen, und der Aufwand, der zu treiben ist, um mit einer neue Programmiersprache produktiv arbeiten zu können, ist nicht von Pappe.
> Da gibt es noch diverse andere, welche sich noch eine ganze Weile halten > werden, ob man das nun will/mag oder nicht (schon mal was von COBOL > gehört?). Nicht nur gehört... deswegen auch der Nachsatz "und nicht nur zur Pflege irgendwelcher Uraltsachen" > C# bietet gegenüber C++ und Java eigentlich keine grundlegend neue > Features, geschweige denn neue Programmierparadigmen. Features gegenüber C++/Java eine ganze Reihe (je nach Sprache mehr oder weniger): Saubere Delegaten/Events, Properties, Reflection/Introspection, dynamische Codegenerierung, DLR (Dynamic Language Runtime), Nullable Types und div. "Syntactic Sugar", gegenüber Java z.B. bessere Schnittstelle zu nativen Functionen/Strukturen, Linq, Lambda-Ausdrücke, konsistente(re) Klassenbibliothek(en) und einige interessante Sprachen die darauf aufbauen bzw. das restliche Framework benutzen (Spec#, F# etc.), u.e.a.m. Grundlegend neu: DLR (wird z.B. für IronRuby verwendet) und Linq. DLR: http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx
>> C# bietet gegenüber C++ und Java eigentlich keine grundlegend neue >> Features, geschweige denn neue Programmierparadigmen. > > Features gegenüber C++/Java eine ganze Reihe (je nach Sprache mehr > oder weniger): Das ist schon klar. Ich wollte mit meiner obigen Aussage ausdrücken, dass C# nicht viel zu bieten hat, was weder in C++ noch in Java schon zuvor vorhanden war. C# ist eben ein Versuch, C++ und Java unter einen Hut zu bringen, dazu kommen noch ein paar Elemente aus anderen Bereichen, bspw. der funktionalen und der Datenbankprogrammierung. Das Ganze wirkt auf mich deswegen etwas aufgedunsen und zusammengewürfelt (wobei dies zugegebenermaßen auch für C++ in seiner aktuellen Form gilt). Vor einigen Jahrzehnten wurde PL/1 ebenfalls mit dem Ziel entwickelt, die Features möglichst vieler Sprachen in einer neuen Sprache zu vereinen. Weil aber alle dieser Features selten gleichzeitig benötigt wurden, konnte sich PL/1 gegen spezialisiertere und damit schlankere Sprachen nicht durchsetzen. Die einzige Programmiersprache, die in meinen Augen wirklich fast alles an Programmierkonzepten und -paradigmen bietet (und dies sogar schon vor Jahrzehnten), und trotzdem eine klare, durchgängige und offene Struktur hat, ist Lisp. Dass sie sich nicht durchgesetzt hat, liegt natürlich an der eigenwilligen Syntax (die aber mit zum Konzept dazugehört), die mit ihren vielen Klammern die meisten schon beim ersten Kontakt davon abhalten, sich weiter mit der Sprache zu beschäftigen. Schade eigentlich.
*.* wrote:
> Mit der Pointer-Breite kommste in C eh kaum in Berührung.
Doch, sehr oft sogar. Nämlich in Gestalt von Adressrechnung aka
Array-Indizierung und Pointer-Arithmetik. Nur wenn man das konsequent in
64 Bit Breite macht, ist man aller Probleme ledig.
Dummerweise macht man das aber nicht. Sowohl in Windows als auch in
Linux ist "int" weiterhin 32 Bit breit. Das hindert zwar weder Anwender
noch Compiler daran, dafür 64 Bit Datentypen zu akzeptieren (siehe
ptrdiff_t, offset_t, ...) und entsprechend breit zu rechnen, aber so ist
es ausschliesslich Sache des Programmierers, den richtigen Typ zu
erwischen. Schrott rein Schrott raus und dementsprechend fehlerträchtig.
Was hier fehlt ist:
- Die Möglichkeit, Arrays entsprechend zu deklarieren. Beispielsweise
mit
int a[long];
um zu signalisieren, dass für die Indexrechnung 64-Bit Arithmetik
erforderlich ist. Leider ist das nicht wirklich konsequent möglich,
aufgrund der C/D-typischen Identität von Array- und Pointer-Rechnung,
aber es würde dem Compiler doch immerhin die Chance geben, freundlich
darauf hinzuweisen, dass
int k;
... a[k] ...
wahrscheinlich Unfug ist. Für Pointer liesse sich eine entsprechende
qualiifizierung auch vorstellen (hässlich, aber diesen Geburtsfehler
kriegt man aus C/D nicht raus ohne es ganz auf den Kopf zu stellen).
- Basierend darauf die Möglichkeit, aus einem Pointer/Array-Objekt den
für die Indizierung/Arithmetik nötigen Typ abzuleiten. Damit liessen
sich for-loops formulieren, ohne a priori wissen zu müssen, welcher
Indextyp dafür nötig ist. Eine Technik die beispielsweise in C++
collection classes rege verwendet wird.
yalu wrote: > Fortran hat sich damals durchgesetzt, weil es von IBM gepusht wurde, > Algol, obwohl fortschrittlicher, nicht. Tja, das waren noch Zeiten als die Welt wusste was gut war ;-). In späteren Jahren konnte man drauf wetten, dass alles was von IBM gepusht wurde schon allein deswegen garantiert absäuft (z.B. PS/2, OS/2, SNA, Token-Ring, ATM).
yalu wrote: > Weil aber alle dieser Features selten gleichzeitig benötigt > wurden, konnte sich PL/1 gegen spezialisiertere und damit schlankere > Sprachen nicht durchsetzen. Das auch. Aber vor allem ist PL/1 ein einziger grosser Konstruktionsfehler.
D, C# und Java kann man nicht mit C oder C++ vergleichen. D, C# und Java sind Projekte, die von irgendwelchen Firmen ins Leben gerufen wurden, während hinter C und C++ richtige ISO Standards stehen. Daher wird sich nur C und C++ langfristig halten.
Auszug aus Wikipedia-Artikel: 2003 wurde C# von der ISO genormt (ISO/IEC 23270). Java hält sich auch schon ziemlich lange, obwohl kein ISO-Standard. Pascal ist so gut wie gestorben, obwohl ISO.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.