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.
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.
