Ist C++ am Aussterben?



  • Wird es von moderneren Sprachen wie Haskell und Rust überholt?



  • Nö.



  • Kannst du das begründen?



  • Was meinst du, wie viele Programmierer es mit jahre- und jahrzehntelanger Erfahrung in C++ es gibt, und daraus resultierend wie viele Programme, die in C++ geschrieben wurden und erweitert und gewartet werden müssen?

    Also bei Java gab es auch mal eine Zeit, in der man meinte, dass es C und C++ ablösen würde, aber dem war nicht so.



  • Also nur weil es sehr viele Menschen gibt, die C++ können und die noch an C++-Programmen arbeiten, heißt das nicht, das die Sprache "lebt". Man muss ja schon eine Definition für "tot" erstellen.

    Ist Cobol tot? Ich würde sagen: Ja! Obwohl wir hier noch Millionen Zeilen Cobol-Code haben, der gepflegt und erweitert wird, und sogar immer wieder Cobol-Programmierer gesucht werden, würde ich die Sprache als tot bezeichnen. Warum? Weil keiner ein neues ernsthaftes Projekt damit anfängt. Cobol macht Bestandswahrung, mehr nicht.

    Nun, wie sieht es mit C++ aus? C++ hat noch ein paar Nischen wo auch noch neue Projekte angefangen werden. Dann wird das Eis aber auch schon dünn. C++ ist nicht tot, aber es hat viele Gebiete an die Konkurrenz verloren. Es gibt viele Felder wo heute einfach andere Sprachen eher eingesetzt werden.

    Dazu muss man nur mal die Stellenbörsen verfolgen. C++ macht in vielen Gebieten Bestandswahrung... kommt mir bekannt vor.

    Ach ja, und dieses Forum zeigt auch den Trend. Vor 10 oder 15 Jahren war hier die Hölle los... heute ist schon verhältnismäßig tote Hose.

    Ob aber gerade Rust der C++-Nachfolger wird, bezweifel ich! Ich sehe den Trend eher das C++ nur noch für die Implementierung von Engines und VMs benutzt wird. Die Anwendungen (egal ob Business, Games usw.) dann in einer Interpreter/Managed-Sprache entwickelt werden... also Java (Android und Enterprise-Edition), C#, JavaScript, Lua, Python usw.



  • Python ist doch viel zu langsam für Spiele.



  • Es geht doch nur ums Prinzip. Nämlich das heute nunmal viel gescriptet wird. Da kann man sich dann natürlich für das jeweilige Szenario für Javascript, Python, Lua (für Spiele) oder sogar AngelScript (für das C++-Feeling) entscheiden. Und wenn nicht gescriptet wird, dann eine Managed-Sprache wie C# oder Java. C++ ist heute jedenfalls nicht mehr in allen Gebieten vertreten wie damals.



  • naja das liegt irgendwo auch an einem selbst. wer möchte kann ja weiterhin c++ oder gar c verwenden.

    also ich habe mal in irgendeinem buch (über visual basic glaube ich) gelesen, dass da irgendeine büroanwendung entwickelt wurde und der kunde total erstaunt über die geschwindigkeit dieser anwendung war und die antwort auf die frage, wieso das so schnell läuft, war eben, dass man komplett auf objektorientierte programmierung und sonstigen overhead verzichtet hat.

    und wenn man sich diesen geschwindigkeitsvorteil klar macht, dann hat man auch einen grund, um c++ eben nicht aussterben zu lassen.
    kunden stehen nämlich eigentlich überhaupt nicht darauf, lange warten zu müssen, weil der interpreter erst einmal den anderen interpreter aufrufen muss, damit dieser dann wieder einen interpreter aufruft usw. 🙄



  • war eben, dass man komplett auf objektorientierte programmierung und sonstigen overhead verzichtet hat.

    ganz ganz schlechtes Beispiel

    wer mit OOP einen Projekt-relevanten Overhead produziert schafft das auch spielend mit prozeduraler Programmierung - oder jedem anderen Paradigma 🙂



  • keine Ahnung, vielleicht war das mal anders, ist ja auch schon etwas her.



  • Wade1234 schrieb:

    keine Ahnung, vielleicht war das mal anders, ist ja auch schon etwas her.

    Nee, war schon immer Blödsinn.



  • Artchi schrieb:

    Ob aber gerade Rust der C++-Nachfolger wird, bezweifel ich!

    Wobei, wenn es jemand schafft irgendwann mal als C++-Nachfolger durchzugehen, dann wohl Rust.

    Und ich finde schon, dass man C++ mal durch was modernes (z.B. mit import statt include) ersetzen sollte.

    Ich hatte noch nicht das Vergnügen mit C++ > 2003(?) richtig zu arbeiten aber wenn ich mir mit 15 Jahren alter C++-Erfahrung so Sachen wie die "neuen" move-Operatoren angucke, kriege ich eher Schüttelfrost. Habe so schon oft genug das Problem "Uberladungshölle" zu meistern.

    Ich will die neuen Features natürlich unbedingt haben und denke mal, dass die auch alle gut und sinnvoll sind, aber es wird halt immer komplizierter.
    Rust scheint gut zu sein, wirkt von außen aber jetzt schon sehr kompliziert. Liegt wohl auch daran, dass sich da noch ständig was ändert.



  • Rostig schrieb:

    Rust scheint gut zu sein, wirkt von außen aber jetzt schon sehr kompliziert. Liegt wohl auch daran, dass sich da noch ständig was ändert.

    Und natürlich daran, dass es so gut wie C++ sein will. Das ist ja auch nicht ohne Grund so kompliziert.



  • Wade1234 schrieb:

    keine Ahnung, vielleicht war das mal anders, ist ja auch schon etwas her.

    OO-Code war nie langsamer als proceduraler Code. Denn du musst ja beim Vergleich die gleichen Fähigkeiten implementieren, weil du ja ein bestimmtes Ziel/Vorteil erreichen willst. Im OO-Fall meistens die dynamische Polymorphie. Und in proceduralen Sprachen baust du dir halt Work-Arounds für Polymorphie, für das was ein OO-Compiler für dich autom. im Hintergrund generiert. In z.B. C programmierst du das per Hand nach (kommt technisch das selbe raus, hast aber mehr Arbeit und Komplexität rein gesteckt, als wenn du einfach eine OO-Sprache nimmst).

    Der Mythos, das OOP langsamer sein soll, kommt vielleicht von Smalltalk. Bei Smalltalk war aber nicht die OO das Langsame, sondern das Message-System (der Smalltalk-Erfinder Alan Kay bezeichnet es deshalb auch als Message-Oriented-Programminglanguage). Und Messaging ist, wie wir wissen, in jedem System langsam. Weil das Ziel/Vorteil der Entkopplung (Late-Binding) nunmal diesen Nachteil mit sich bringt.

    Alles was einen Vorteil hat, hat auch einen Nachteil. Wenn du procedural und statisch programmierst, dann hast du zwar einen Performance-Vorteil... aber den Nachteil der Unflexibilität, starken Kopplung und nicht-Erweiterbarkeit.

    Wenn statischer proceduraler Code so geil wäre und keine Nachteile hätte, dann würde niemand einen Grund haben andere Paradigmen (Messaging, Polymorhie, Funktional usw.) einzusetzen. Oder? Am Ende ist ja alles Fallabhängig, welches Paradigma man einsetzt.



  • In unserer internationalen Firma setzen wir erfolgreich auf Haskell.

    Denkt mal drüber nach!

    Grüße aus Oslo/Norwegen



  • In unserer internationalen Firma setzen wir erfolgreich auf C++.

    Denkt mal drüber nach!

    Grüße aus Witten/Deutschland



  • Ich fange an bei meiner Firma alles mit C++ zu "durchseuchen" 😛
    Keine Lust alles in Delphi zu machen *würg*. Die interessiert das eh alles nicht.
    Sollte sie meiner Ansicht nach aber. Wenn ich weg bin, haben die ein Problem, weil die jemand bräuchten, den sie doppelt so gut bezahlen müssten, nicht weil schlecht dokumentiert, sondern weil ich unterbezahlt bin -.-
    Aber wenns die nicht interessiert was ich nutze, dann C++. (Für Embedded, Beagle Bones und Desktopanwendungen). Wenn schon scheiße bezahlt, dann will ich auch mit Freude zur Arbeit gehen.

    Ich bin aber so frei zu behaupten, dass sie mit mir und meiner Sprachenwahl sehr sauber strukturierte, performante, wartbare und fehlerfreie Software kriegen.
    Aktuell brauchen die in manchen Projekten 3 Tage mindestens um einen Bug zu beheben, weil deren Software plain Scheiße ist. Ich kann den Mist auch nicht mehr lesen, wenn er 20 Einrückungen stellenweise hat, weil der Quelltext toxisch ist wie nichts. Dann doch lieber ein kleinen TMP Trick hier und da und alles wird wieder lesbar, weil es auf eine Zeile runterkocht, die für sich selbst spricht.

    EDIT: Ich weiß dass es für das große Ganze irrelevant ist, was ich denke, aber ich bringe ein bisschen mehr C++ in die Wirtschaftswelt ^^.

    EDIT 2:

    Was wird bei uns eingesetzt?:

    • Delphi
    • C
    • Assembly
    • C++ (NEU)

    Da ist IMHO C++ noch das beste aus der Liste. (Ich habe meine JavaScript, Python, Bash und Batch Scripte mal nicht mitgezählt)



  • Artchi schrieb:

    Ach ja, und dieses Forum zeigt auch den Trend. Vor 10 oder 15 Jahren war hier die Hölle los... heute ist schon verhältnismäßig tote Hose.

    Das kann aber auch am Forum liegen, da es
    a) deutschsprachig ist und mittlerweile doch die meisten ohne Probleme Englisch schreiben und verstehen und das eben auch die wichtigste Sprache im IT-Bereich ist.
    b) Das Forum ist schwer zu finden, ich kam gerade nur per Zufall und durch einen obskuren Suchbegriff her.
    c) Stackoverflow und Co. sind die Orte, an denen mittlerweile am meisten diskutiert wird, egal über welche Sprache wir sprechen.

    Artchi schrieb:

    Ob aber gerade Rust der C++-Nachfolger wird, bezweifel ich! Ich sehe den Trend eher das C++ nur noch für die Implementierung von Engines und VMs benutzt wird. Die Anwendungen (egal ob Business, Games usw.) dann in einer Interpreter/Managed-Sprache entwickelt werden... also Java (Android und Enterprise-Edition), C#, JavaScript, Lua, Python usw.

    Das sehe ich genauso, wir (internationaler Konzern) setzen z.B. sehr stark auf C# für die meisten Anwendungen und hardwarenahes wird meistens in C oder C++ gemacht.
    Die Produktivität mit C# und Co. ist einfach enorm hoch und gewisse Fehler sind von vornherein ausgeschlossen.

    Rust krankt IMO an zwei Dingen: zu komplex und zu wenig produktiv für klassische Desktopanwendungen und umgekehrt im Hardwarebereich (noch)kaum vertreten, obwohl ich gerade da große Vorteile durch die erzwungenen statischen Checks sehen würde.
    Tooling ist gerade im professionellen Bereich oftmals einfach alles und was nicht offiziell vom Zulieferer unterstützt wird, wird auch nicht eingesetzt.
    Wir sehen das häufig bei C++: da wären wir schon um C++11 support froh.
    Wo es ggfls. jetzt schon sehr gut einsetzbar ist, wäre bei der Systemprogrammierung aber vermutlich werden weder die Linuxentwickler noch Microsoft Lust haben, ihre Kernels nach Rust zu portieren.

    Zukünftige Betriebssysteme könnten es natürlich ohne Probleme einsetzen, da man dann von Anfang an damit plant.

    Das muss natürlich nicht heißen, dass Rust niemals eine sehr wichtige Sprache werden wird aber ich könnte mir vorstellen, dass wir Rust in 10-15 Jahren rückblickend eher als wichtigen Zwischenschritt sehen werden.



  • Artchi schrieb:

    Alles was einen Vorteil hat, hat auch einen Nachteil. Wenn du procedural und statisch programmierst, dann hast du zwar einen Performance-Vorteil... aber den Nachteil der Unflexibilität, starken Kopplung und nicht-Erweiterbarkeit.

    also ist oo doch langsamer?

    dass kunden meistens gar nicht wissen, was sie eigentlich haben wollen und es bei prozeduralen konzepten besser ist, alles noch einmal von vorne zu machen, wenn da plötzlich größere änderungen stattfinden sollen, ist ja eine ganz andere geschichte. 😃


  • Mod

    Wade1234 schrieb:

    Artchi schrieb:

    Alles was einen Vorteil hat, hat auch einen Nachteil. Wenn du procedural und statisch programmierst, dann hast du zwar einen Performance-Vorteil... aber den Nachteil der Unflexibilität, starken Kopplung und nicht-Erweiterbarkeit.

    also ist oo doch langsamer?

    mit derselben argumentativen Tiefe könnte man auch sagen, Pseudocode ist am schnellsten (hat auch selten Probleme mit z.B. Skalierung o.ä.).

    Erfahrungsgemäß ist der Code bzw. das Programm gut wenn der/die Programmierer/in gut ist/sind.

    Problem mit guten Programmierern:
    https://www.youtube.com/watch?v=LWTe0aW1OFs (10:48)


Log in to reply