Finde ich nicht überzeugend. Es gibt sehr systemnahe Sprachen, die die unsäglichen WTFs von C vermeiden und trotzdem einen guten Einblick in die Low-Level-Arbeitsweise eines Computers geben (mir fielen D, Go und Rust ein, gibt sicher mehr).
Ich denke, Lehrkräfte wie diese verklären ihre “tollen” Erfahrungen mit C und vergessen, wie frustrierend und unintuitiv ihre erste Begegnung mit C tatsächlich gewesen ist. Auch systemnahe Sprachen haben sich weiterentwickelt, und den Studenten diese moderne, aufgeräumte Sicht (*) bewusst und ohne einen stichhaltigeren Grund als Nostalgie vorzuenthalten, grenzt für mich an Körperverletzung.
(*) die dann auch ganz natürlich und folgerichtig zu den abstrakteren Sprachen führt, ohne die ganzen Sackgassen und Irrwege, die seit C ausprobiert worden sind, mitnehmen zu müssen
Naja, damit sagst du eigentlich nichts groß anderes als der Autor des Beitrages. Nämlich, dass die Punkte 1-3 unter bestimmten Umständen vernachlässigbar sind. Aber Punkt 4 kann man nicht verneinen.
Es ist und bleibt ein Fakt, dass die meisten “Tools um Software zu schreiben” in C oder C++ entwickelt sind.
Ob man deshalb C lernen muss, liegt einzig und allein daran, in welche Richtung man später Software entwickelt.
Das Argument ist aber auch auf der gleichen Ebene, wie als Handwerker Metallguss zu lernen, weil die meisten Werkzeuge aus Metall sind.
Wenn ich mal naiverweise von meinem Toolset ausgehe, ist das meiste eben nicht in C geschrieben.
IDE ist Java
Build-Tools sind Java
Build-Server ist Java
Docker ist Go
Clang dürft größtenteils C++ sein (was ich mal als explizite Entscheidung gegen C sehen würde)
Node-Stack ist Javascript
Rest dürften Python- und Shell-Skripte sein
Die Runtimes sind natürlich zum größten Teil noch C, aber auch da gehts mittlerweile weg davon und man kommt als “normaler” Entwickler niemals mit dem C/C+±Teil davon in Berührung.
Ich finde es nicht schlecht, wenigstens grob zu lernen, wie sowas funktioniert. Oder dass Garbage Collection nicht einfach so vom Himmel gefallen ist. Aber ich denke, dass man es nicht anhand von C erklären muss. Ich finde es auch gut, wenn die Kinder in der Schule ein bisschen im Gilgamesh-Epos lesen (einfach als Teil der Allgemeinbildung), aber doch bitte nicht in sumerisch.
Ich finde C nicht verkehrt, um viele „Grundlagen“ zu lernen. Man kann C seeehr low-level programmieren, und C-Programme scheiben, bei denen man von vornherein jede Zeile im Kopf schon in den passenden Assembler-Code übersetzen kann. (Man kann, wenn man will, auch funktional und objektorientiert programmieren, aber da bieten sich dann doch eher andere Sprachen an…).
Ich denke, zumindest eine grobe Vorstellung davon zu haben, was eine Addresse oder ein Pointer sind, kann sehr dabei helfen, zu verstehen, wie andere Sprachen etwas unter der Haube funktionieren (und warum das Ding denn NullPointerException heißt…). Und wenn man sich erstmal den Krampf mit malloc und free angetan hat, sich gefragt hat, warum man seine Funktionen denn immer „doppelt“ schreiben muss, und ob ein int nun so groß ist wie 1, 2, 3 (?) oder 4 chars, und ob ein char denn nun 8, 9 (?!) oder 16 bit hat, und man gesehen hat, was für’n kranken Shice man machen kann, wenn die Sprache „zu wenig streng“ ist (wenn array[index] = 42; geht, geht auch index[array] = 42;!), lernt man sowas wie die JLS vielleicht erst richtig zu schätzen
Ob man Leute zwingen sollte, „komplexere“ Anwendungen in C zu schreiben, ist eine andere Frage.
