Blick in die Kristallkugel
-
Wie sieht wohl die Zukunft von C,C++,C#,Java aus?
Ist es empfehlenswert, heute noch neue Projekte (betrifft nur Projekte, die in
jeder der drei Sprachen gut durchzuführen wären !) in C zu beginnen
oder wird C als "Altlast" eines Tages von den C++-oder-seinen-Nachfolgern)-Compilern nicht mehr unterstützt werden ?Wie sieht's mit C# aus - Ersatz für C++ oder Proprietarität, die C++ nie
ablösen wird ?Wird der Nachfolger von C++ seinerseits C++-kompatibel sein (so wie
C++ die Untermenge C enthält) oder wird C++ als "Altlast" entsorgt werden,
wenn sich der Nachfolger von C++ etabliert ?Wird es in ferner Zukunft überhaupt noch Sprachen geben, die nicht an C++ angelehnt sind oder ist C++ die Basis für alle weiteren Sprachen so wie
der Intel 4004 vor 30 Jahren die Basis für alle heutigen PCs gelegt hat ?Java - zukunftssicher (in Windows...) oder die besten Zeiten schon wieder
hinter sich ?Ich will Code schreiben, der auch in 10 Jahren, besser in 20, noch compilierbar und portabel ist.
Ist wide-character-Unterstützung dazu nötig oder kann man davon ausgehen,
daß man auch in 10 Jahren noch Textdateien mit 1 Byte/Zeichen aus-/einlesen kann? Ist STL-Verwendung unter diesen Gesichtspunkten zu empfehlen ?Überhaupt: Sollte man zur Maximierung der Portabilität möglichst wenig
Features von C++ benutzen (also lieber printf statt cout<< und char s[80]
statt class string oder gar Tiny C) ?Ich wäre für Hinweise und fundierte Meinungen dankbar, da ich
grundlegende Entscheidungen hinsichtlich meines Programmierstils für die
nächsten 10 Jahre treffen will und nicht vor jedem neuen Projekt neu
darüber nachdenken müssen will.
-
Schau dir doch mal die Geschichte der Programmiersprachen an. Programmiersprachen hören nicht auf zu existieren und haben keine Nachfolger.
Deswegen muss man nicht davon reden, ob C# ein C++ Nachfolger wird. C# ist einfach eine neue Programmiersprache.
Wenn das alles so leicht wär, hätten wir heute keine Fortran und COBOL Programme mehr
-
Hmm, ist der Text wirklich von dir?
Irgendwo hab ich den schon mal gelesen.Leute, die heute portabel programmieren, werden auch in 10 Jahren noch nix anständiges auf die Reihe gebracht haben.
-
@kingruedi:
Programmiersprachen verschwinden nicht einfach, aber es wird schwerer,
nach vielen Jahren noch Code zu compilieren - versuch' mal heute, eine
CP/M-8"-Disk von 1983 mit einem darauf befindlichen USCD-Pascal-Programm (war damals sehr verbreitet) zu compilieren...und UCSD-Pascal ist von der
Komplexität her nicht mal annähernd mit C++ zu vergleichen.Leute, die heute portabel programmieren, werden auch in 10 Jahren noch nix anständiges auf die Reihe gebracht haben.<<
Eines der Musterbeispiele für Portabilität ist Mathematica - das soll so
portabel sein, daß es innerhalb von zwei Stunden (oder einer?) von 32 bit
auf 64 bit portiert wurde. Du willst nicht wirklich behaupten, daß Mathematica
oder auch Linux (läuft ja wohl auf x86, Power PC und Alpha)
nichts Anständiges ist, oder ?Ich rede in meinem Posting ja nicht von irgendwelchen ASM-Hacks und
Grafikkartenregister-Übertakt-Pfriemeleien, sondern von portabler und
langzeit-kompilierbarer Software.
-
Hi cacheline,
war vielleicht etwas undiplomatisch ausgedrueckt.
Aber mir faellt immer haufiger auf, dass Programmierneulinge meiner Meinung nach zu grosses Gewicht auf Portibarkeit legen. Anstatt sie erstmal ein paar Programme auf einem Rechner zum laufen bringen.
Ich weiss nicht, wie deine Programmiererfahrung aussieht, aber du sagst, dass deine Programme in 20 Jahren! immer noch kompilierbar sein sollen.Wenn ich da von mir ausgehe: Meine Programme von > 10 Jahren sind immer noch ausfuehrbar: Auf dem C64 und Amiga. Dass diese syntaktischen Stilblueten den Sprung auf den Windows PC nicht geschafft haben, ist fuer die Nachwelt ein ueberwindbarer Verlust.
Ich meine: 20 Jahre, weisst du, wie lang das ist in Computerjahren?
Ist das wirklich so ein wichtiges Kriterium fuer deine naechsten Programme?
Sind sie auch in 20 Jahren so unverzichtbar?Die Fragen musst du dir selber beantworten.
-
Gibt es da nicht genug Threads zu finden ( die viel im Flame enden )?
-
Meine Programme von vor 10 Jahren sind auch noch ausführbar, da in C
geschrieben. Wenn der Nachfolger von C++ den C-Kompatibilitätsmodus nicht mehr
haben sollte, habe ich also in 10 Jahren ein Problem.Ob meine Programme für mich in 10 Jahren unverzichtbar sind, weiß ich nicht;
aber ärgern würde ich mich schon über den Zeitaufwand, alles in C++ oder Java umschreiben zu müssen, wenn C von den Compilern nicht mehr unterstützt wird.Worum es mir geht, ist das folgende: ich habe es einfach satt, mir bei
jedem string s überlegen zu müssen, ob ich doch lieber
konservativ ein char[80] s nehme oder riskiere, von STL anhängig zu sein und
mir damit Kompatibilitätsprobleme einzuhandeln (in einem bekannten
Buch über STL wird gar davon abgeraten, class string oder auch reverse(..)
zu verwenden, da es Kompatibilitätsprobleme gäbe; man solle lieber vector<char>
und reverse iterator nehmen...).In einem anderen bekannten Buch wird öfter mal geraten, von gewissen
C-Features im Rahmen der C++-Programmierung Abstand zu nehmen; das wären
Altlasten, die irgendwann nicht mehr unterstützt zu werden brauchen - man
soll also cout<< statt printf nehmen usw.Welche der beiden Vorgehensweisen ist aber nun die richtige, um zukunftssicheren
Code zu schreiben - auf fortgeschrittene Dinge wie STL-strings zu verzichten
um heute Kompatibilitätsrisiken zu vermeiden oder auf althergebrachte, aber heute hochgradig protable Features wie printf zu verzichten, um nicht
"Altlasten" im C++-Code unterzubringen, mit denen in 10 Jahren kein Compiler
mehr was anfangen kann ??Überspitzt ausgedrückt:
Programmiert man lieber in Tiny-C, um den kleinsten gemeinsamen Nenner zu
treffen, der hoffentlich noch in den Sprachen der Zukunft vorhanden ist oder
nutzt man lieber fortgeschrittene Features wie STL in der Hoffnung, daß diese
nicht so schnell zur "Altlast" werden wie heute schon C in C++-Programmen?-- ?
-
*lol* die antwort ist doch wohl ganz klar.
stl benutzen.
-
dies ist definitiv ein trollthread.
thread closed.
-
Ja, bitte schliessen!!!
Selbst COBOL wird noch wie wild eingesetzt, sogar für neue Projekte! Vor einem Jahr wurde ich von unserem Kunden gefragt ob ich nicht mal aushelfen kann um ein paar neue COBOL-Funktionen auf dem Mainframe zu schreiben, weil gerade Not am Mann ist. Hi hi, ich kann aber gar kein COBOL! Soviel dazu, ob eine Sprache aus den 60er Jahren noch gefragt ist.
Warum sollte da C++ in 10 Jahren (da lacht COBOL drüber) nicht mehr gefragt sein?
-
dies ist definitiv ein trollthread. <<
Aber erst nach Deinem "Beitrag"...
Warum sollte da C++ in 10 Jahren (da lacht COBOL drüber) nicht mehr gefragt sein?<<
Ganz einfach: COBOL und FORTRAN waren und sind spezialisiert auf einen
Zweck, da ist die Konkurrenz klein. C,C++,Java,C# dagegen sind universell
und für fast alle Zwecke zu gebrauchen - da ist die Konkurrenz größer.(Wo sind eigentlich ALGOL,PASCAL,ADA und PL/M heute ?)
Ich hoffe, daß Du recht hast und C/C++ langlebig wie FORTRAN wird.Damit ist meine Frage aber noch nicht beantwortet - welcher Programmierstil
heute verspricht maximale Portabilität und Langzeit-Kompilierbarkeit ?
-
cachline schrieb:
Damit ist meine Frage aber noch nicht beantwortet - welcher Programmierstil heute verspricht maximale Portabilität und Langzeit-Kompilierbarkeit ?
Einer bei dem man seine Programme möglichst nie neu kompilieren muss um sie auf einer anderen Plattform an´s Laufen zu kriegen
-
wenn du die stl nicht benutzen willst, ist das genauso wie wenn du das schlüsselwort "class" meidest. Ansonsten: C++ ist wohl die sprache deiner wahl, da das kommitee nie irgendetwas rauswerfen wird.
-
Ganz einfach: COBOL und FORTRAN waren und sind spezialisiert auf einen
Zweck, da ist die Konkurrenz klein. C,C++,Java,C# dagegen sind universell
und für fast alle Zwecke zu gebrauchen - da ist die Konkurrenz größer.(Wo sind eigentlich ALGOL,PASCAL,ADA und PL/M heute ?)
Ich hoffe, daß Du recht hast und C/C++ langlebig wie FORTRAN wird.Also ich sehe zu C++ keine direkte Konkurrenz! C#? Java? Sorry, aber diese Sprachen benötigen eine VM, eine Runtime-Lib um vernünftig zu funktionieren (ich will jetzt keinen Roman schreiben, ihr wisst was ich meine?).
Bei C++ sieht die Welt ganz anders aus. C++ gibt es für JEDE Platform. Kann ich Java, C#, Perl, Phyton für meine SEGA Dreamcast (SuperHitachi4-CPU), für meinen Acorn Archimedes/RiscPC (ARM-CPU), für den AmigaOne (PowerPC-CPU) benutzen??? Nein! Aber einen C++ Compiler habe ich für jede der genannten Platformen. Java, C# usw. gibt es für diese nicht. Ja, jetzt kann jeder ankommen und sagen: "Da muß doch nur jemand die VM implementieren". Ja, eben! Und das macht keiner!
Selbst für meinen Acorn hab ich den aktuellen GCC-Compiler sammt Standard-Lib und Firefox wurde sogar auf RiscOS portiert, in dem man einfach den GCC genommen hat und die Libs portiert hat. Auf dem Amiga wird gerade OpenOffice portiert (ist komplett C++ und nicht Java, wie von vielen Java-Fans behauptet!).
Ich habe auf meiner Dreamcast folgendes gemacht: http://www.kharchi.de/dcscode/index.html
Auf der Dreamcast gibt es massig Hobby-Software die mit C und C++ programmiert wurden.
Egal ob zeta (BeOS), PalmOS... ich kann garnicht alle Platformen aufzählen, für die es C++ Compiler gibt. Also, wo ist bitte die Konkurrenz die C++ wirklich ersetzen kann???
Gibt es nicht!
Wieviele C++ Compiler gibt es eigentlich? GCC von GNU, Codewarrior, MS C++, Digital Mars, Intel C++, Acorn C/C++, Storm C (Amiga) uvm. Das sind nur die die mir spontan einfallen. Soll diese Vielfalt aussagen, das C++ in Zukunft keine Bedeutung haben wird? Das beweist eher, trotz Hyper-Duper-Giga-Marketing für Java und C#, das C++ _ohne_ Marketing sehr verbreitet ist. Ich finde das sehr beachtlich und ohne SUNs Marketing wäre Java ein Fliegenschiss.
-
Ja, jetzt kann jeder ankommen und sagen: "Da muß doch nur jemand die VM implementieren". Ja, eben! Und das macht keiner!
Den GCC musste aber genauso irgendjemand mal für diese oder jene Plattform portieren.
Ein Compiler allein ist halt nicht so komplex wie ein Compiler mit beiliegendem Framework.Btw. warum sollte man sich so ein Rießenprojekt auch antun, wenn keine wirkliche Nachfrage danach besteht.
Wenns das Projekt verlangt muss man halt eben eine andere Sprache einsetzen ..Das beweist eher, trotz Hyper-Duper-Giga-Marketing für Java und C#, das C++ _ohne_ Marketing sehr verbreitet ist. Ich finde das sehr beachtlich und ohne SUNs Marketing wäre Java ein Fliegenschiss.
Das ist mir persönlich scheiß egal, solang ich professioneller wirke,
wenn ich mit dem Strom fließe. Ist natürich nur ne persönliche Meinung ..Also ich sehe zu C++ keine direkte Konkurrenz! C#? Java? Sorry, aber diese Sprachen benötigen eine VM, eine Runtime-Lib um vernünftig zu funktionieren (ich will jetzt keinen Roman schreiben, ihr wisst was ich meine?).
Und aus genau dem selben Grund hat sich DirectX letztendlich nie durchsetzen können ..
-
außenstehender schrieb:
Das ist mir persönlich scheiß egal, solang ich professioneller wirke,
wenn ich mit dem Strom fließe. Ist natürich nur ne persönliche Meinung ..ROFL
-
außenstehender schrieb:
Und aus genau dem selben Grund hat sich DirectX letztendlich nie durchsetzen können ..
WTF
-
Artchi: blablabla! Bist du immer noch sauer, dass du im Beruf mit Java programmieren mußt und nicht mit C++? Oder hast du inzwischen die Firma gewechselt? Hört sich ja schrecklich an, dein Text.
OpenOffice ist übrigens genausowenig komplett C++, wie es komplett Java ist. Es beinhaltet Teile von Java. Hast du die entsprechende Diskussion vor einiger Zeit nicht mitgekriegt? War auf allen IT-News-Seiten präsent.
Deine C++-Compiler-Liste ist ja wirklich sehr beeindruckend (wobei ich auch JVMs von 10 verschiedenen Herstellern aufzählen kann). Sind die C++ Compiler eigentlich inzwischen alle Standardkonform? Vermute ich einfach mal. Aber wie lange soll es nach dem nächsten Standard dauern, bis die Compiler nachziehen? Wer garantiert in dem Fall eigentlich Standardkonformität? Gibt es ein Tool, mit dem man das Testen kann oder muss man ausprobieren und hoffen? Ich würde auch nicht behaupten, dass die Kompatibilität in der Zukunft garantiert ist: Heutzutage wird einem das "void main" um die Ohren gehauen, während es vor ein paar Jahren keine Probleme gemacht hat. Abgesehen davon darfst du nicht vergessen, dass auch die Bibliotheken, die du nutzt, auf alle Plattformen portiert sein müssen, sonst kannst du die Portabilität mit C++ vergessen und du landest wieder da, wo du auch mit Java oder C# bist. Die "Hauptplattformen" werden unterstützt und es gibt ein paar mehr oder weniger nutzbare Implementierungen für die Nebenplattformen.
-
Klar ist nur die generelle Marschroute des "Mainstream": Weg von "technischen" Sprachen und hin zu problemorientierten Sprachen (siehe Entwicklung von Assembler zu C#). In 10-20 Jahren wird der Standardprogrammierer mit Sicherheit nicht mehr mit Pointern rumfummeln (hoffe ich zumindest
)
-
Plattformunabhängigkeit ist erst erreicht, wenn es nur noch eine Plattform gibt.
@Artchi: Java und C# sind nicht wirklich mit C++ vergleichbar, die Sprachen verfolgen in ihrer Entwicklung komplett unterschiedliche Ziele. Außerdem bin ich der Meinung, dass sie auf verschiedenen Ebenen liegen. Java und C# sind highleveliger (Gibts dafür ein anderes Wort
) als C++. Je nach Einsatzzweck wird man wählen. Genauso wie Assembler für RAD ungeeignet ist, ist Java ungeeignet um auf einem Toaster Programme auszuführen, weil eben niemand daran interessiert ist JVMs für Toaster zu schreiben. Außer der Syntax und dem leichten Hang zur OOP haben die beiden Sprachen doch ziemlich wenig miteinander zu tun. Diese ewigen Diskussionen sind doch komplett sinnlos
Einzig und allein im Bereich der Anwendungsprogrammierung überschneiden sich die Sprachen. Hier wird man nach detaillierteren Kriterien vorgehen und die für den jeweiligen Zweck geeignetere Sprache suhcen. Doch das entscheiden meistens Projektleiter und Direktoren, der Programmierer sieht bloß zu.
MfG SideWinder