Eigentlich durch Zufall ist mir ein guter Beitrag wieder unter die Augen gekommen, er stammt aus dem Jahr 2016:
https://www.heise.de/hintergrund/Schlanke-Embeded-Entwicklung-mit-Small-C-3576516.html
Nun haben wir das Jahr 2024. In dieser Zeit gab es regelrechte Revolutionen bei der Programmiersprache C++, vor allem im Bereich der generischen Programmierung. Und sehr viele dieser Features erzeugen KEINEN Overhead im Maschinencode, keine zusätzlichen Stackrahmen etc., bringen aber die Verlagerung von Algorithmen in die Compile-Zeit, Typsicherheit, die Möglichkeit von zusätzlichen Tests wieder in der Compile-Zeit, bessere Debug-Möglichkeiten etc. etc. etc. Daneben wird aus meiner Sicht immer mehr auf ein neues Pferd gesetzt, Rust.
Es geht hier nicht darum, eine Programmiersprache gegen die andere auszuspielen. Ein guter Handwerker hat zu Recht einen ganzen Werkzeugkoffer, sein Können besteht auch darin, je nach Problem die richtigen Werkzeuge auszusuchen und mit diesen in der Anwendung vertraut zu sein. Wer käme schon auf die Idee, eine Diskussion vom Zaun zu brechen, ob ein Schraubendreher besser wäre als eine Kneifzange. Aber ohne Zweifel gibt es eben Schritte, wo der Schraubendreher dran ist und nicht die Kneifzange, oder umgekehrt.
Was mich hier erstaunt, ist der noch immer sehr hohe Anteil an embedded Projekten, die REIN in C abgewickelt werden. Damit meine ich keine sehr HAL-nahen Routinen oder die Implementation von ABIs. Ich meine die Umsetzungen der höheren Layer. Damit mögen Programmierer mit nur prozeduralen Programmierwissen ohne Schulung besser zurechtkommen. Aber auf der anderen Seite bezahlt man aus meiner Sicht die Zeche in der Sicherheit des Codes und vor allem seiner Wartbarkeit. Es ist für mich wieder ein Beispiel von vielen für Sparen am falschen Platz: was ich hier am Anfang des Projektes einspare, muss ich später teuer mit Zinseszins obendrauf zahlen … angefangen schon in der Programmierung selbst, wenn die Architektur langsam etwas komplexer wird, dann im Bug Fixing, wo viele Fehler im Falle von C++ schon gar nicht aufgekommen oder vom Compiler entdeckt wären, und nicht zuletzt bei Anpassungen des Codes und vor allem seiner Übersichtlichkeit.