Programmiersprachen: Spitzenreiter fallen auf Rekord-Tief

Hinsichtlich der Beliebtheit und der Verbreitung sind die Programmiersprachen-Klassiker Java und C noch immer Spitze - allerdings sind sie längst nicht mehr so dominant wie noch vor einigen Jahren. Inzwischen fielen sie sogar auf den schwächsten ... mehr... Code, Programmierung, Quellcode, Programmiersprache Code, Quellcode, Programmiersprache, Php, Source Code Code, Quellcode, Programmiersprache, Php, Source Code Free for Commercial Use / Flickr

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Ein Link zu der Statistik oder wenigstens eine Tabelle der Top10 wäre noch hilfreich gewesen.
 
@aecro: https://www.tiobe.com/tiobe-index/
 
@Cykes: Danke!
 
Hab ich das übersehen oder steht gar nichts über Rust? Oder ist Rust keine neue Sprache?
 
@MancusNemo: Rust ist im Ranking irgendwo zwischen 51 und 100. Ein genaues Ranking wird wegen zu kleiner Unterschiede nicht mehr genau angegeben. Quelle: https://www.tiobe.com/tiobe-index/
 
@Danielku15: Achso zu niedrigese "Interesse". Na dann Passt ja alles. Dachte schon nur wegen der Hitze...
 
Wieso finden sich Skriptsprachen unter den Programmiersprachen?
 
@erso: Weil es am Ende eigentlich ziemlich egal ist, ob Code kompiliert oder interpretiert wird...
 
@erso: Weil es auch Sprachen sind, in denen man programmiert?!!!?!!!11!!
 
@erso: Damit Klugscheißer was zum Kommentieren haben.
 
@Niccolo Machiavelli: Und was ist mit html :-)
 
@Skylab: Html ist eine Auszeichnungssprache, keine Programmiersprache.
 
@erso: Kannst du mal bitte erklären was dich zu dieser Frage bringt?
 
@erso: Und wo trennt man das? Ist doch Jacke wie Hose heutzutage. Das Resultat und die Performance sind entscheidened.

Java gilt doch zB auch offiziell als Programmiersprache, obwohl nur Java-Bytecode als Zwischenschritt vorhanden ist, den die Java-VM dann auf dem Zielsystem interpretiert. Nur deshalb ist Java ja prozessorunabhängig. Eine Dekompilierung zum Source ist aus dem Bytecode ja auch nahezu problemlos möglich, was bei sogenannten "echten" Programmiersprachen, die direkt Maschinencode erzeugen, nicht mehr möglich ist.

Wenn man das mit einer klassischen Scriptsprache wie Javascript vergleicht, wird dessen ByteCode eben erst beim Parsing generiert und bereits beim ersten Start zu nativen (unoptimierten) Maschinencode kompiliert. Während der Laufzeit des Scripts wird dieser Maschinencode aber weiter analysiert und (zB für häufig genutzte Funktionen) teilweise optimiert und neu kompiliert um einen deutlichen Performancegewinn zu erreichen. Dadurch läufts auch auf jedem System individuell angepasst so gut es geht.

Und die neu hinzugekommenen WebAssemblys im Browser sind zB Assembly Bytecode, der technisch gesehen nach der Ausführung aber genau das gleiche Programm durchläuft wie Javascript - nur dass die Source->Bytecode Kompilierung übersprungen wird und die meisten Optimierungen im Voraus gemacht werden. WebAssembly-Code ist aber bereits statisch typisiert, so dass viele Prüfungen wegfallen, was im Normalfall die Laufzeit-Performance etwas erhöht.

In der Theorie könnte man diese Optimierungen sogar in Javascript direkt coden, und primär vordefinierte ArrayBuffer-Heaps zur Speicherverwaltung nutzen (ähnlich wie das Resultat in ASM & WebAssembly), aber das macht natürlich keiner von Hand so und überlässt diese Optimierungen dann dem JIT-Compiler. ^^

Die durch C/C++ erzeugten WebAssemblys sind das Resultat einer "echten" Programmiersprache, obwohl sie eigentlich unter der Haube nur wie Javascript interpretiert werden. Am Ende hat man aber immer Maschinencode - mal mehr oder weniger gut optimiert. Aber da jeder Browserhersteller bei Javascript sein eigenes Süppchen kocht, was Kompilierung und Optimierung anbelangt, macht es die Sache eben kompliziert. Auch die WebAssemblys bieten nur eine begrenzte Basis. Was der Browser dann daraus macht, steht auf nem anderen Blatt.

Fürs Web wärs daher eigentlich von Vorteil, wenn alle Browserhersteller die gleiche Javascript-Engine nutzen würden, um eine identische Feature&Performance-Basis zu haben, aber das werden wir wohl nie erleben. Die Zeiten, wo sich Browserhersteller auf ihren Lorbeeren ausruhen und dadurch den Fortschritt ausbremesen, sind ja eigentlich längst vorbei. Alle sind stats daran interessiert, höchste Performance herauszuholen - da wäre eine gemeinsame Zusammenarbeit eigentlich sinnvoller als gegenseitiger Konkurrenzkampf.
 
@Trashy: Du kennst aber den Unterschied zwischen Client- und Server-basierenden
Scripts ?
Und rechenintensivere/aufwändigere Anwendungen laufen sowieso nicht im
lokalen Browser, sondern auf den Servern des Hosters (z.B. Cloud-Plattformen)
Bsp
Ich will eine Web-App mit einem Cloud-Script bei Google machen.Und es soll
irgendetwas kompliziertes und rechenintensives sein..egal was(sagen wir mal
eine SuperDuper-KI-Anwendung)

Da muss man in der HTML-Seite der Web-App nur folgendende Zeile einfügen

<script> google.script.run.myfunction() </script>

Der Rest (der Script mit dem Namen: myFunction()) läuft auf den Servern von Google.
Die lokale Ressourcen(lokale Festplatte, lokales RAM, lokale CPU, welcher Browser
etc) spielen überhaupt keine Rolle mehr.
 
Mich würde in neben dem TIOBE Index auch das grobe Einsatzgebiet der Sprachen interessieren. Auch wenn sich die Top 20 wahrscheinlich nicht grob ändern würden, ist das Ranking sicherlich um einiges anders.
 
Wo sind denn die ganzen Prozentpunkte alle hin? Aus dem Index will mir das nicht so recht hervorgehen. Sind die einfach alle nur bei JAVA und C weg und verteilen sich nun auf die Randnotizen?

Politisch inkorrekt wie ich nunmal bin verorte ich die jetzt erstmal alle bei "Programmierumgebungen zum Zusammenklicken", weil der Horizont immer weiter absinkt und weil es für JAVA-Klassen und #include-Dateien nicht mehr ausreicht.

Aber gegenintuitiv wirkt es trotzdem. Der Sinn sollte doch Interopabilität sein und wenn jeder was anderes macht, wie will man dann zusammenarbeiten? JAVA-Klassen mögen oft keine PERL-Scripts einbinden und andersherum genausowenig; "einfach wechseln" ist da also nicht ganz so einfach.
 
@RalphS:
public class Main {
public static void main(String... argv){
Process p = Runtime.getRuntime.exec("script.pl");
BufferedReader output=new BufferedReader(new InputStreamReader(p.getInputStream()));
}}

perl -c 'exec java -jar Klasse.jar'
perl -c 'exec java pfad/domain/paket/Klasse'
 
@dev null: Das starten eines externen Prozesses hat jetzt genau wie viel mit zusammenarbeiten zu tun?
 
Yeah...das größte Wachstum hat Scratch...wird wohl bald die Weltherrschaft unter
den Programmiersprachen übernehmen.
Denn Scratch das die "ultimative Programmiersprache der Zukunft"

Ist Scratch überhaupt eine Programmiersprache...und kann man TIOBE überhaupt
ernst nehmen, wenn Scratch und Assembler in einem Atemzug genannt werden ?

:-)

https://scratch.mit.edu/
 
@Selawi:
Scratch ist eine Entwicklungsumgebung.
Die Sprache ist Smalltalk.
 
Ich muss lachen, "VisualBasic .NET konnte sich nach oben kämpfen....", da sind laut Ranking +0.05%, kämpfen?
Kommentar abgeben Netiquette beachten!
Einloggen

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.