Warum ist C immer noch so erfolgreich?
-
Warum ist C immer noch so erfolgreich. Ich meine die Sprache ist uralt und mit den Zeigern kann man sich schnell ins Bein schießen.
-
Gründe dafür:
Hohe Verbreitung:
- vorhandener Code, an dem man mitwirken möchte
- Bibliotheksunterstützung
- Anzahl der Lehrer/Bücher/KurseGeschwindigkeit:
- Manchmal braucht man eben die höchste Geschwindigkeit
- C ist mit eine der schnellsten Sprachen und von diesen die wohl am einfachsten erlernbarePlattformunabhängigkeit:
- Manchmal braucht man eben beste Portabilität
- C ist mit eine der portabelsten Sprachen und von diesen die wohl am einfachsten erlernbare
- Vermutlich ist C sogar die am weitesten portierte SpracheSchwierigkeit:
- Die Sprache hat zwar nur begrenztes Ausdrucksvermögen, aber das macht sie vergleichsweise einfach zu lernen. Es gibt die technischen Fallstricke, weil man nahe an der Maschine ist, die nichts verzeiht. Aber hat man die gelernt, dann weiß man alles, um gut mit C umgehen zu können. Von nicht speziell zum Lernen entwickelten Sprachen, dürfte C mit am einfachsten sein.
- Nicht jeder hat Angst vor der Maschine. Pointer sind cool und lehren viel über das was wirklich im Computer passiert.Gründe darfst du dir selber ausdenken, wenn du nicht nur trollen willst. Es genügt zu sagen, dass es sie natürlich gibt, auch reichlich. Aber die Gründe dafür haben bei denen, die C noch benutzen, wohl überwogen. Und bei denen, die es nicht tun, wohl nicht.
-
Ich sehe im Fall von C drei Hauptgründe:
1. Legacy
Es ist viel Code in C geschrieben worden, und der muss gepflegt werden. Das ist allerdings nichts C-spezifisches; was einmal weit verbreitet war, wird man nicht wieder los -- grad letztens gab es eine Schlagzeile, dass für amerikanische Atomkraftwerke Leute gesucht werden, die PDP-11-Assembler schreiben können (sichere Stellen bis 2050), COBOL hat ne Cloud-Anbindung spendiert gekriegt und dergleichen mehr. Dieser Faktor greift für alle Sprachen, aber für C halt in besonders großem Maße, weil praktisch alles irgendwie mit C-Code zu tun hat. Das bringt mich zu
2. C ist der kleinste gemeinsame Nenner.
Nahezu alle anderen Sprachen bieten die Möglichkeit, C-Code einzubinden. Wenn du in eine Skriptsprache geschwindigkeitskritischen Code einbinden willst -- egal, ob du den Rest in Lua, Ruby, PHP, Python oder Visual Basic schreibst -- ist es am einfachsten, wenn der eine C-Schnittstelle bereitstellt, denn damit können alle umgehen. Java hat JNI. C++ und Objective-C haben C-Kompatibilität eingebaut. .net hat P/Invoke und C++/CLI, und auch wenn letzteres den Umweg über C++ geht, kann man C damit einfach einbinden. Matlab, Mathematica, alle sprechen C. Du kannst jedem eine C-Bibliothek in die Hand drücken und erwarten, dass der damit nach Dokumentationslektüre schon irgendwie klarkommt.
Wenn du jetzt eine Bibliothek schreiben willst, die überall benutzbar sein soll, welche Art Schnittstelle wirst du ihr geben?
3. Kontrolle.
C ist furchtbar unbequem, denn man muss in C alles selber machen. Gleichzeitig ist C damit furchtbar mächtig, denn man kann alles selber machen. Dabei geht es inzwischen oft weniger um Geschwindigkeit -- für einen in beiden Sprachen versierten Programmierer ist es dank Compilertechnik in C++ einfacher, zeitperformanten Code zu schreiben (wobei man nicht vergessen sollte, dass es einfacher ist, in C versiert zu werden als in C++) -- als um Binarygröße oder Speicherbelegung. Wenn du für ein Embedded-System schreibst, zählt jedes Byte, sowohl RAM als auch Programmspeicher, und wenn du einen Kerneltreiber schreibst und genau wissen musst, was die Maschine macht, ist C auch eine sinnvolle Wahl.
Für Userspace-Programme, die auf einem PC laufen, packe ich heute nur noch selten einen C-Compiler aus (bevorzuge C++), und um Bibliotheken baue ich eher am Ende einen C-Wrapper, als den Kern in C zu schreiben, aber es gibt durchaus Bereiche, in denen sich kaum sinnvolle Alternativen zu C anbieten.
Oh, und
4. es gibt einen Haufen Leute, die C können.
Und die schreiben halt C. Das gehört irgendwie mit zu Punkt 1, denke ich.
P.S.: Wenn ich mit meiner Einschätzung daneben liege, ignorier den Absatz. Dein Verweis auf Zeiger als Stolperfalle lässt mich vermuten, dass du mit C erst am Anfang stehst. Da es Zeiger auch in anderen Sprachen gibt (in Java zum Beispiel wird fast alles durch Zeiger angesprochen, auch wenn sie ihre Zeiger "Referenzen" nennen) streiche ich den Bezug gedanklich mal zusammen auf "man kann uninitialisierte Zeiger bauen und Zeigerarithmetik ist verwirrend."
Ich sehe häufig, dass diese beiden Dinge Anfängern Probleme bereiten, weil Zeiger oft nicht allzu gut erklärt werden -- sie sind eines dieser Dinge, die so schwer zu erklären sind, weil sie, nachdem man sie einmal verstanden hat, so selbsterklärend erscheinen, dass man kaum noch erklären kann, was man vorher daran so verwirrend gefunden hat. Aber vorher wurden einem zur "Erklärung" Zeiger auf Zeiger auf Zeiger um die Ohren geworfen, um den Unterschied zwischen dem Zeiger, dem Zeiger auf den er zeigt, dem Zeiger auf den der Zeiger auf den der Zeiger zeigt zeigt und dem Wert, auf den der Zeiger zeigt, auf den der Zeiger zeigt, auf den der Zeiger zeigt zu "verdeutlichen." Dass einem solche Datenstrukturen nur in Ausnahmefällen über den Weg laufen und meistens ein Zeichen dafür sind, dass man schreiend weglaufen sollte, wird dabei üblicherweise nicht thematisiert, und dass die Handhabung eines Zeigers sich nicht dadurch ändert, dass er statt auf einen int auf einen Zeiger zeigt, geht mitunter unter. Für den Fall, dass du in dieser Falle steckst, lass ich mal einen Link auf Binky Pointer Fun da.
Trotz dieser Erklärungsschwierigkeiten sind Zeiger aber eigentlich nicht sehr schwierig zu verwenden. Uninitialisierte Zeiger sind leicht zu vermeiden (Zeiger halt initialisieren), und Zeigerarithmetik ist in der Praxis durchaus beherrschbar. Die Regelung, dass p + 1 nicht auf das nächste Byte, sondern auf das nächste Element zeigt, stellt sich ziemlich schnell als ganz natürlich heraus, weil Zeigerarithmetik (nahezu) ausschließlich im Umgang mit Arrays auftaucht, und alles weitere läuft allein darauf hinaus, in den Arraygrenzen bleiben zu müssen.
-
Ja, ich stehe erst am Anfang von C und diese Frage kam mir halt. Ich stand halt vor der Frage C oder C++ und bin beide mal so überflogen. Zusätzlich habe ich mir Fragen und Antworten zu beiden Sprachen hier angeschaut.
C++ war mit dann doch eine Nummer zu umfangreich und ich habe da das Gefühl dass man ewig braucht um es zu beherrschen. Ich komme aus der C# Ecke und selbst dort brauchte ich noch nie wirklich OOP, ganz einfach weil ich allein keine riesigen Programme schreibe und bis jetzt auch ohne OOP wunderbar klar gekommen bin. Letzten Endes bin ich jetzt bei C gelandet und fragte mich halt warum es noch so populär ist.
-
seldon schrieb:
2. C ist der kleinste gemeinsame Nenner.
Ich denke, das ist ein sehr wichtiger Punkt. Nicht alles ist C++, es gibt auch sehr viel andere Sprachen und es ist viel einfacher, ein Binding für eine C Lib zu schreiben, als für eine C++ Lib.
@SuccessOfC: ich würde mir C ehrlich gesagt nicht mehr antun. OOP magst du vielleicht noch nicht verstehen oder mögen, aber allein die manuelle Speicherverwaltung in C ist sehr umständlich. Und es ist ziemlich schwierig, elegant in C zu programmieren, ohne einen Haufen Spaghetticode zu produzieren. Auch wenn du von C# kommst, wird dir vieles unnötig kompliziert oder fehleranfällig vorkommen.
Wenn du einfach nur die Sprache lernen willst, ok. Aber wirklich irgendwelche neuen Projekte würde ich damit nicht anfangen. Wenn du das nicht professionell machst und es nicht brauchst, warum bleibst du nicht bei C#?
Man kann auch allein ziemlich umfangreiche Projekte schreibenEins meiner Projekte hatte über 100 000 Zeilen C# und ich hab vier Jahre dran gearbeitet.
-
Tja, warum bleibe ich nicht bei C#? Nun, ich möchte mal weg von den ganzen Libs, Frameworks und IDEs. Ich möchte Dinge wirklich selbst programmieren und nicht nur Legobausteine zusammenstecken wie ein Fünfjähriger.
Nein, professionell möchte ich keine Programme in C entwickeln. Ob das nur Spagetticode bei raus kommt oder nicht ist, ist völlig egal. Das Programm muss funktionieren, nur das zählt. Man kann sich das vielleicht vorstellen wie ein Schreiner, der mal die Schnauze voll von Fabrikarbeit hat und ein Stück wirklich selber bauen möchte.
-
SuccessOfC schrieb:
Nun, ich möchte mal weg von den ganzen Libs, Frameworks und IDEs. Ich möchte Dinge wirklich selbst programmieren und nicht nur Legobausteine zusammenstecken wie ein Fünfjähriger.
Ja, das ist ein durchaus legitimer Wunsch und da macht C denk ich auch mehr Sinn als C++. Später kannst du dann vielleicht auch Assembler lernen (wobei ich erst Assembler und dann C gelernt habe).
-
Die wesentlichen Gründe, warum C noch so erfolgreich ist, sind schon genannt worden. Trotzdem glaube ich, daß C langfristig von C++ abgelöst werden wird.
Wenn man Programmiersprachen eine Lebensspanne, was die Verbreitung und Benutzung anbetrifft, zugesteht, dürfte C sich wahrscheinlich schon in der zweiten Hälfte befinden, C++ hingegen hat die Mitte noch nicht erreicht.
-
SuccessOfC schrieb:
Ich möchte Dinge wirklich selbst programmieren und nicht nur Legobausteine zusammenstecken wie ein Fünfjähriger.
Dann musst Du Assembler programmieren, denn selbst C ist nichts anderes als Legobausteine zusammenzustecken.
-
SuccessOfC schrieb:
Tja, warum bleibe ich nicht bei C#? Nun, ich möchte mal weg von den ganzen Libs, Frameworks und IDEs. Ich möchte Dinge wirklich selbst programmieren und nicht nur Legobausteine zusammenstecken wie ein Fünfjähriger.
Nein, professionell möchte ich keine Programme in C entwickeln. Ob das nur Spagetticode bei raus kommt oder nicht ist, ist völlig egal. Das Programm muss funktionieren, nur das zählt. Man kann sich das vielleicht vorstellen wie ein Schreiner, der mal die Schnauze voll von Fabrikarbeit hat und ein Stück wirklich selber bauen möchte.
das ist auf jeden Fall eine gute Idee.
Ein Background in C und Assembler schadet niemals, da man dadurch viele Dinge klarer sieht.
Bei "nur Java/C#" Programmierern habe ich schon öfter gemerkt, dass sie eigentlich gar nicht wirklich wissen wie die Dinge im Hintergrund ablaufen, was ein Stack ist, was ein Heap ist, sind erstaunt dass es am Computer keine "natürlichen" Stringdatentyp gibt, usw....
Nicht, dass man die Dinge unbedingt wissen muss, um in der SW Entwicklung sein Geld zu verdienen. Aber schaden tut es auf keinen Fall.Wenn ich Stellenanzeugen lese, bei denen man 5000 Frameworks können muss, aber sonst keine Fähigkeiten brauche, ist das der beste Hinweis auf eine Stelle, wo man Legosteine zusammenstecken darf.
Bei Stellen für C oder C++ Programmierer liest man dagegen nur selten von irgendwelchen Frameworks (vllt. mal Qt oder OpenCV oder sowas...).Wenn du wirklich sehen willst, was in einem Programm so abläuft, starte mal einen Debugger.
Erstelle ein einfaches Hello World Programm in C.
Du denkst, da werden nur 2 oder 3 Befehle ausgeführt?
Starte dein Hello World Programm in OllyDbg und lass dich überraschen
OllyDbg: http://thelegendofrandom.com/blog/archives/31Zur Ausgangsfrage: Mir sind Java Programme schon öfter mit einer Null Pointer Exception abgeflogen als C Programme mit einer Access Violation. Also auch mit Java kann man sich ins Bein schießen.
-
C vs C++ schrieb:
Die wesentlichen Gründe, warum C noch so erfolgreich ist, sind schon genannt worden. Trotzdem glaube ich, daß C langfristig von C++ abgelöst werden wird.
Falscher Blickwinkel.
C als höchstportabler Hochassembler mit einheitlicher API wird sich noch Jahrhunderte halten. Schon rein aus Legacy-Gründen werden C-Schnittstellen erhalten bleiben (WinAPI, Posix) und es werden neue entstehen, denn C ist das Mass aller Dinge, dem andere Programmiersprachen ihre Bindings aufsetzen (Python, C++, Haskell). Niemand kann da C den Rang streitig machen.C++ hingegen als hochperformante Sprache mit viel Abstraktionsmöglichkeiten für Linux/Windows/Mac kann recht schnell ersetzt werden. Google migriert auf Go, andere ziehen nach -> Adé C++. Aber im Moment sehe ich noch keine grosse Bedrohung.
-
Ich denke auch, dass in Zukunft in C wesentlich mehr programmiert wird als in C++. Warum? Nun, wenn man Abstraktion und OOP braucht, dann gibt es weit aus komfortablere Sprachen(Java, C#, Python, Ruby, etc.) und die, die da noch kommen werden.
Sollte man doch das letzte bisschen Geschwindigkeit brauchen(was sehr sehr selten der Fall ist), dann kann man immer noch die paar kritischen Stellen auslagern.
Ein Projekt vollständig in C++ zu schreiben macht doch heute kein Software-Entwickler mehr freiwillig. Erstens nehmen sich die meisten nicht mehr Zeit über viele Jahre das sehr komplexe C++ zu lernen und zweitens will man auch dass seine Software auch noch dann wartbar ist wenn die ganzen alten Hasen, die noch C++ gut können, das Schicksal der Dinos teilen. C hingegen kann im in relativ kurzer Zeit wirklich komplett beherrschen.
Es gibt keinen logischen Grund, warum C++ sich länger wie C halten würde. Allein mit C, Assembler und den anderen höher abstrahierten Sprachen ala Java, C#, etc. kann man die komplette Informatik perfekt abdecken.
C++ wird wie dieses Forum ganz langsam ausbluten, da helfen auch neue Standards nix. Die Sprache wird man nicht freiwillig für neue Projekte verwenden. Wenn man C++ meiden kann, so tut man dies.
-
Da braucht man gar nicht agurmentieren, es reichen die Fakten. Geht in einen großen Zeitschriftenhandel und schaut euch an, in wievielen Zeitungen C++ ein Thema ist und vergleicht dies mit den Sprachen die thematisiert sind. Das ist immeer, neben Stellenanzeigen, ein guter Indikator. So habe ich das schon zu C64-Zeiten gemacht.
-
SuccessOfC schrieb:
Warum ist C immer noch so erfolgreich. Ich meine die Sprache ist uralt und mit den Zeigern kann man sich schnell ins Bein schießen.
Alter ist kein Grung. Und wo du hinschiesst, ist dein Problem und nicht das der Sprache.
C ist das Mass aller Dinge
Quatsch. C ist der kleinste gemeinsame Nenner, auf den man sich einigt zwecks Interoperabilitaet.