Programmiersprachen-Ranking: TIOBE kürt C zur Sprache des Jahres 2017


#1

#2

Ähhhh… Steinzeit? Das sind hoffentlich Fakenews :smiley:

Mist… nee, leider nicht :frowning:


#3

Ich kann zumindest verstehen, warum C weiterhin verwendet wird::

  • ist eine Lehrsprache an den Unis
  • bietet stabiles Toolchain und gutes Debugging Werkzeug
  • ebenso viele verschiedene Libraries

Den ganzen Legacy-Code darf man auch nicht vergessen, denn der will nämlich auch noch weiter gepflegt werden.


#4

Also wenn du mich fragst, ist dieses Argument genauso Steinzeit. Was man nicht vergessen darf, ist die Tatsache, dass inzwischen so ziemlich jede Sprache eine Compiler-Sprache ist, die grundsätzlich Maschinencode erzeugt - Bytecode läuft, wenn auch nicht zwangsläufig, auf virtuellen Maschinen. Daraus folgt, dass man (theoretisch) für jeden Ziel-Code den passenden Sprachcompiler inkl. RSE-Tools entwickeln kann. Das bedeutet, dass man an spezielle Sprachen gar nicht mehr gebunden ist.

Und wenn unter diesen Gesichtspunkten C immernoch die beliebteste Sprache bleibt, ist irgend was faul beim Fortschritt.


#5

Gib dir nicht so viel auf das TIOBE Ranking :sweat_smile:

*EDIT: Wobei ich gerne deine JVM für CNC Maschinen entgegen nehmen :smiley:


#6

Was genau dort gemessen wird, ist schwer zu sagen. Zumindest ist es nicht notwendigerweise die “(“emotionale”) Popularität”: Nur weil es viel verwendet wird, heißt das ja nicht, dass die Leute es “gerne” verwenden.

Gerade bei C gibt es technische Gründe. Etwas oberflächlich gesagt sind das eben die Hardwarenähe und die Toolchains (Compiler) die es da gibt. Manche Sprachen werden auch üblicherweise eben gerade nicht direkt in Maschinencode übersetzt (und die Java Virtual Machine ist in C (C++) geschrieben…).

Nebenbei: Ich denke, dass sowas wie die LLVM da ein ziemlicher Game Changer ist, und ziemlich massive Veränderungen nach sich zieht (auch wenn man die vielleicht erstmal nicht direkt darauf zurückführt).

Und wenn C mit “Steinzeit” assoziiert wird, dann muss ich im Hinblick auf die “moderne” Massenpsychose namens “JavaScript” sagen: Es war nicht alles schlecht, damals … :smirk:


#7

Theoretisch bringt sich jede ach so tolle Programmiersprache nichts, wenn sie sich nicht eignet für den jeweiligen Zweck. Auch eine ach so tolle Programmiersprache bringt sich nichts, wenn dieser niemand mächtig ist. Ich verstehe nicht, warum du C mit Steinzeit verbindest, wenn alles, was auf deiner Hardware läuft, in C(++) programmiert ist. Wobei eigentlich im Umkehrschluss auch dein Rechner Steinzeit sein muss [1]. Natürlich hängt man nicht mehr so von C ab wie früher™, aber das alleine macht sie nicht zu einer rückschrittlichen Programmiersprache… Es sind vermutlich eher die undefined Behaviours, die sie zu einer eher unpraktischen Sprache machen. Wirklich rückschrittlich würde ich eigentlich nur Assembler bezeichnen. Es gibt vielleicht noch wirklich gute Gründe ihn zu verwenden, aber in den meisten Fällen lohnt es sich nicht. Um dir das zu veranschaulichen, dass C weniger mit Steinzeit zu tun hat, rate ich dir folgendes: Probier’ einfach mal einen Brainfuck-Interpreter mit einem Assembler oder vllt. noch besser mit Lochkarten zu programmieren. Egal was du sagst, die in C geschriebene Lösungen gefallen mir jedenfalls besser :stuck_out_tongue:.

[1]: Es sei denn du besitzt ganz heimlich einen Quantencomputer.


#8

C++ ist das Entscheidende. Objektorientiert halt. Was Ein Compiler macht, hast du hoffentlich verstanden - Er kompiliert Hochsprachen (C, C++, Java usw.) In Maschinen- bzw. Bytecode, wobei letzterer Maschinencode für Virtuelle Maschinen ist und Maschinencode annähernd das, was man direkt in Assembler programmiert. Also gegenüber Assembler ist C schon sehr fortschrittlich, aber gegen das, was seitdem sonst noch so erdacht wurde (z.B. C++) ist C hoffnungslos durch. Meine Rechner können jedenfalls nur Maschinencode ausführen und nichts anderes und aus diesem Grunde sind Compiler nötig, wenn man nicht Maschinencode programmieren will. Welcher Compiler nun aus welcher Sprache passenden Maschinencode produziert, ist vollkommen egal. Man könnte mit einem C-Compiler auch Java-Bytecode produzieren, nur würde dies kaum etwas bringen. Dalvik-Java z.B. produziert (u.A.) Maschinencode für ARM-Prozessoren und war bis Android 5.0 fester Bestandteil dieses Betriebssystems. Das zeigt mir, dass man auf keinem System mehr auf Sprachen, wie C angewiesen ist.


#9

Dabei geht ein (sehr) wichtiger Punkt vielleicht etwas unter. Er “übersetzt” nicht einfach nur. Er optimiert auch, und das ist das eigentlich aufwändige. Sehr viele Mannjahre (ja, Mannjahre) sind in die Optimierungsfunktionen von GCC, MSVC & Co geflossen. Dummerweise in einer Form, die das Parsen, Optimieren und Übersetzen nicht sauber getrennt hat (dafür gibt’s jetzt die LLVM). Das kann man nicht “mal kurz” für eine andere Sprache machen. Nicht umsonst werden “frühe” “Very High Level Languages” wie https://de.wikipedia.org/wiki/Eiffel_(Programmiersprache) erst in C übersetzt, und das Ergebnis dann durch einen C-Compiler gejagt. (“Frühe” heißt hier: Die, die es gab, bevor die JVM verbreitet genug war, um dutzende Sprachen darauf aufsetzen zu lassen).


#10

Ich gebe zu, dass C theoretisch nicht mehr notwendig ist. Nichtsdestotrotz gibt noch ein Aspekt, den berücksichtigen sollte, welcher vor allem höhere Programmiersprachen betrifft: Abstraktion kriegt man nicht umsonst, deswegen sollte man als denkender Programmierer nicht alles abstrahieren, nur weil man es kann. Wenn es z.B. um eine einfache Spülmaschine geht, warum soll objektorientierter Code und eine komplexe Speicherverwaltung vom Vorteil sein? Im Endeffekt braucht man ja nichts weiter als die Initialisierung der gesamten Hardware (Timer, Interrupts und etc. aufsetzen), Handling von Interrupts und die Möglichkeit relevante Variablen für das aktuelle Spülprogramm auszulesen und zu schreiben. Was braucht so ein Ding mehr, als es können muss? So ein Design ist einfach, stromsparend (augrund der Verwendung von Interrupts) und spart damit Kosten bei der Wahl der elektronischen Komponenten, weil nicht mehr notwendig ist.


#11

Yo, ich denke auch das dieser Rat auf jeden Fall ersteinmal angebracht ist. Wer sich mal die Mühe gemacht hat nachzulesen wie die Rankings bei Tiobe zustande kommen, der weiss doch eigentlich auch das diese Rankings genau gar nichts über Qualität oder Sinn einer Sprache aussagen. Warum sollten sie auch, dafür sind sie ja nicht konzipiert. Die Rankings basieren darauf ganz andere Aussagen zu treffen. (welche Aussagen das sein mögen muss nun jeder selber bei Tiobe nachlesen :slight_smile: )

Sehe ich auch so. Wenn es um hardwarenähe und eingebettete Systemem geht, da gibt’s neben C nicht gerade viele erwähnenswerte Sprachen. C++ und Assembler kann man noch nennen. Aber ansonsten…?
Und das ist ja auch nicht verwunderlich, denn für die Firmware von Spülmaschinen, Garagentoröffnern, Fieberthermometern, Eieruhren, Tastaturen, Fernbedienungen, Mikrowellen, Scheibenwischern, Akkuladern etc. pp. braucht man halt definitiv keine highlevel Sprache mitsamt ihrem Overhead. Da kommt es eher darauf an resourcensparend zu programmieren, damit bei der MCU noch 'n Groschen eingespart werden kann. Da gibt es schlicht und einfach keinen Grund etwas anderes als C zu verwenden.

PS: Die Sprache C ist derzeit sicherlich ein bedeutender Standard für die Programmierung von ES, aber das heisst ja nicht das man dort heutzutage nicht noch Verbesserungen einbringen könnte. Hat zufälligerweise jemand der Mitlesenden Interesse an einem Brainstorming über eine “bessere” Sprache für ES als C? :slight_smile:

edit:
PPS:

Uhh, erinnere mich nicht daran. Ich musste während meine Studiums noch die Sprache “Beta” lernen (der Name war Programm…), und das war mal so richtig abturnend. Informatik-Pädagogen fanden die Sprache immer ganz toll, aber jeden anderen Menschen brachte sie zum spontanen erbrechen.
Beta-Sources wurdern afair, und deswegen komme ich gerade darauf, auch ersteinmal in C-Sources übersetzt (mit etwas Glück jedenfalls). Aber ehrlich gesagt war das gesamte Beta-Universum total für den Ar… die Katz.
Daher rührt wohl mein persönliches Trauma* wenn es um Sprachen geht die erst in C übersetzt werden müssen bevor sie irgendwie verarbeitet werden könnnen. xD

* Herzlichen Dank nochmal, Prof. D.! Ich weiss ja, wir haben sie auch durch die Debatte auf der Treppe vor dem Physik-Gebäude nicht davon überzeugen können Beta in die Tonne zu kloppen - aber seither sind etliche Jahre vergangen, ich/wir sind schlauer geworden, und ich/wir finden Beta, höflich ausgedrückt, nach wie vor einfach nur für zum weglaufen! Vielleicht bereiten sie für das nächste Alumnitreffen doch mal eine Entschuldigungsrede vor? :stuck_out_tongue:


#12

Go??? D???


#13

Go würde ich mal abrupt nein sagen. Ist soweit ich gehört habe, nicht zur Hardwareprogrammierung ausgelegt worden. Bei D muss man anscheinend ohne die Runtime Library von D auskommen, dürfte daher an sich möglich sein. Rust dürfte ideal sein, weil man bei der Hardwarenähe auf nichts verzichten muss.


#14

Go hat seine Runtime mit GC die im Binary drinsteckt. Von daher fällt das wohl für kleinere Sachen direkt weg, sofern sie nicht gross genug dafür sind.

Rust ist in der Tat ein potentieller Kandidat. Eines der Probleme bei Rust ist die Lernkurve. Bis man also mit Rust soweit ist, um damit produktiv zu sein, hat man mit C vielleicht schon das ganze Programm fertig. Gerade wenn man die Features, die gut und wichtig sind, die Rust mitbringt nicht in dem Ausmass benötigt.


#15

Also ich weiß nicht… Wenn es um Hardware geht, programmiert man ja eh nicht in Sprachen, die bei Tiobe ganz oben auftauchen, es sei denn, bei dieser Hardware handelt es sich um Microcontroller (AtMega z.B.). Das Fließband einer Produktionsstraße wird man kaum anders als per SPS programmieren, Haustechnik mit einem Derivat davon, genannt KNC und was in Küchen- bzw. Haushaltsgeräten so abgeht, wissen auch nur die Ingenieure. Bei Geräten, die nicht bzw. nur spärlich auf Speicher-Prozessor-Grundlage basieren, sind andere Dinge vorherrschend. Kein Mensch würde ein Spiel in Haidenhain Klartext oder ein Werkstück in C programmieren (außer TMII vllt. Hydraulik-Ventil-Blöcke in Java :smiley: )


#16

Seh’ ich eigentlich auch so, nur, weil beliebt/“populär”, und oft genutzt, heißt noch nicht, für den und den “Zweck” geeignet! :slight_smile:

(Parallelen zur Polikig und dem “Geschwurbel” würd ich aber nicht nehmen.)

#17

Uhmmm - ja gut, es mag möglich sein sein Go, D oder auch Java für eingebettete Systeme zu verwenden. Doch ehrlich gesagt bin ich in der Realität noch keiner Firma begegnet die das praktiziert hat. Da ist halt immer C gefragt, bisweilen auch C++ oder Assembler, aber ansonsten nicht viel. Java & Co wird eigentlich nur für Weboberflächen verwendet, gerne auch mal bei Smartphones. Aber Apps auf Smartphones sind schon viel zu “weit weg” von eingebetteten Systemen (so wie ich sie kenne und wertschätze). Mit Kenntnissen in Go und D* hat man in dem Bereich glaube ich wenig Chancen auf einen Job. :confused:

PS: Ganz allgemein und für alle: Für den Tiobe-Index wird gezählt wie oft der Ausdruck “<language> + programming” in an der Auswertung beteiligte Suchmaschinen eingetippt wird. Die ausgewerteten Suchmaschinen sind (u.a.): Google, Youtube, Baidu, Wikipedia, Bing und Ebay**. Was dies am Ende vom Tag über eine Sprache aussagt muss sich explizit jeder selber auswürfeln.

* Ich muss gestehen das ich mich bislang noch mit keiner der beiden genannten Sprachen großartig auseinandergesetzt habe. Kann man da ad hoc irgendwelche Vorteile (z.B. ggü. C/C++ nennen, welche ihre Verwendung für ES vorteilhaft erscheinen lassen?

** https://www.tiobe.com/tiobe-index/programming-languages-definition/


#18

BMW verwendet ua Android und Java für das Entertainmentsystem der Autos. Und auch andere Hersteller überlegen sich, ob sie auf ebenfalls darauf setzen.


#19

Das Infotainment-System im Auto ist kein embedded System. Das ist das, was man bei IoT als “Gateway” bezeichnen würde, also quasi die Zentrale im Auto. Das ist von der Leistungsfähigkeit locker so schnell wie ein Smartphone (> 1 Ghz, mehrer Kerne), hat allerlei Hardwarebescheunigung (Grafik, Video).

Das Infotainment-System im Auto ist dann über Netzwerk/Bus mit verschiedenen MCUs verbunden (die dann wiederum mit Sensoren etc. verbunden sind). DIE haben vlt. so 16Mhz, ein paar KB Speicher, und ein RealTimeOS oder gar kein OS, die DInger nennt man auch “Constrained Device”. Und da läuft dann auch garantiert kein Java drauf.

Das sind 2 völlig unterschiedliche Leistungsklassen, die man nicht in einen Topf werfen kann. Und da IoT-Krams boomt, macht es Sinn, dass auch C boomt.


#20

Zumindest ein Argument, was bisher unerwähnt blieb: