Lasst C einfach C sein und hört auf, an der Sprache etwas verbessern wollen.
Dem kann ich nur zustimmen. Man muss sich als Negativbeispiel nur das Frankenstein-Konstrukt namens C++11 anschauen.
Jeder meint er könne es besser und schreibt eine eigene Sprache und wenn etwas Zeit vergeht, schreibt man vllt. auch noch eine zweite weil man es "noch besser" kann. Und im Endeffekt findet man dann trotzdem nur eine C/C++ Abart wieder.
There are only two kinds of programming languages: those people always bitch about and those nobody uses.
Und der Großteil nimmt eh C/C++ wegen der "besseren Performance"...
Ein herrlicher Satz - immer wieder gern geäußert von Menschen, die
Just-in-time-Kompilierung verschlafen haben.
Trotzdem nutzt sie kaum einer, weil eben funktional und nicht "C-like" ist und somit fehlt auch sämtliche Toolchain-Unterstützung.
Leider lassen sich viele Probleme in der realen Welt nicht in schöne und saubere Formeln verpacken, sondern benötigen hässliche Sachen wie Zustände, womit man wieder bei imperativen Konstrukten landet.
Die kann man zwar z.B. mit Monaden unter den Teppich kehren und so tun, als wäre die Welt hübsch, aber gewonnen hat man nichts.
Trotzdem würden/werden natürlich viele Mainstream-Sprachen von funktionalen Konstrukten wie Closures profitieren.
Leider macht die mangelhafte Toolchain-Unterstützung Scheme für komplexe Projekte leider unproduktiver als Mainstream-Sprachen.
Ich finde, bevor man eine neue Sprache baut, sollte man sich vllt. erst mal alte Sprachen noch mal genau anschauen.
Das haben doch die Designer der heute verbreitesten Sprachen doch gemacht und erkannt, dass manche Features (z.B. Bequemlichkeit (Garbage Collection), eine vernünftige Standardbibliothek oder Ähnlichkeit mit bereits verbreiteten Sprachen) wichtiger sind als andere, die ihren Vorteil in der Praxis kaum ausspielen können.
Rückblickend sind natürlich viele Entscheidungen der Sprachdesigner unsinnig; teils weil es schlicht Fehlentscheidungen sind, teils weil sich die Voraussetzungen geändert haben.
Will damit jetzt nicht sagen, dass ich überall Scheme haben will, aber ich gucke mir die gerade für die Uni an und bin erstaunt wie mächtig diese Sprache ist, obwohl sie verdammt alt ist.
Wie ich selbst erfahren musste, sind die Unterschiede zwischen Uni und der realen Welt enorm. Je komplexer die Probleme werden, desto weniger bestimmt die Sprache allein as Ergebnis. Mit einer mäßigen Sprache mit guter Toolchain erreicht man ein besseres Ergebnis (Produktivität, Performance, Wartbarkeit, etc.) als mit einer guten Sprache mit schlechter Toolchain.
Egal was geschrieben, angeblich modern, neu erfunden oder gar verschlimmbessert wird. Hochleistungssoftware wird noch immer in C oder C++ geschrieben.
Definiere Hochleistungssoftware. Heutzutage werden selbst High-Frequency-Trading-Systeme, bei denen es auf Mikrosekunden ankommt, in Sprachen wie
Java oder
C# geschrieben.
Der Trend meines Eindrucks eher in die andere Richtung. Ich habe in diesem Jahrtausend
persönlich kein einziges Greenfield-Projekt erlebt, das noch in C oder C++ gestartet wurde (abgesehen von Hardware-nahen Sachen).
In den meisten komplexen Projekten erreichen die JIT-Compiler von Haus aus eine bessere Performance, als man unter C oder C++ mit vertretbarem Aufwand - wenn überhaupt - je hinbekommt.
Kompetenz in C oder C++ zu haben, ist und bleibt auch weiterhin eine Investition in die Zukunft und veraltet nie!
Allein aufgrund der schieren Verbreitung (und dem Verständnis für Low-Level-Programmierung, das man beim Erlernen gewinnt) ist zumindest C grundsätzlich empfehlenswert.
Bei C++ wird es schon fraglicher - je nachdem, in welche Richtung man sich professionell entwickeln möchte. Es gibt Bereiche, in denen C und C++ praktisch nicht-existent sind.
