Die IT-Beratungsfirma Tiobe hat C# im umstrittenen Tiobe-Index zur Programmiersprache des Jahres 2025 gekürt. Tiobe wertet monatlich die zwanzig im Web beliebtesten Programmiersprachen aus und vergibt die Auszeichnung jeweils im Januar für das Vorjahr. Entscheidend ist die Sprache mit den größten Zugewinnen im Jahresvergleich. Nach 2023 erhält C# den Titel damit bereits zum zweiten Mal innerhalb von drei Jahren.

Laut Tiobe verzeichnete C# 2025 den stärksten Anstieg in den Bewertungen. Die Betreiber führen das auf tiefgreifende Veränderungen der Sprache in den vergangenen Jahren zurück. C# habe früh neue Konzepte aufgegriffen und sich sowohl von der reinen Windows-Bindung gelöst als auch vom proprietären Microsoft-Produkt zu einer plattformübergreifenden Open-Source-Sprache entwickelt.

Java und C# liefern sich Kopf-an-Kopf-Rennen

Im Markt für Unternehmenssoftware liefern sich Java und C# seit Jahren ein enges Rennen. Tiobe sieht bislang keinen klaren Sieger. Java sei weiterhin stark verbreitet, stehe aber wegen seines vergleichsweise umfangreichen Boilerplate-Codes und der Zugehörigkeit zu Oracle unter zunehmendem Druck.

Verschiebungen in den Top 10

Auch innerhalb der Top 10 gab es im Jahr 2025 Bewegung. C und C++ tauschten ihre Plätze. Während sich C++ laut Tiobe in den vergangenen Jahren stark verändert hat, finden einige größere Neuerungen wie das Modulsystem bislang nur begrenzt Eingang in die Praxis. C profitiert dagegen weiterhin von seiner Einfachheit und Geschwindigkeit, insbesondere im wachsenden Markt für kleine eingebettete Systeme. Rust erreichte mit Platz 13 zwar einen neuen Höchststand, konnte sich in diesem Umfeld aber noch nicht dauerhaft etablieren.

Gewinner und Verlierer des Jahres

Zu den überraschenden Gewinnern zählt Perl. Die Sprache verbesserte sich deutlich von Platz 32 auf Platz 11 und kehrte damit in die Top 20 zurück. Ebenfalls wieder in den Top 10 vertreten ist R, getragen vom anhaltenden Wachstum in Data Science und statistischer Datenanalyse.

Auf der Verliererseite nennt Tiobe unter anderem Go, das 2025 dauerhaft aus den Top 10 herausfiel – Programmiersprache des Jahres 2016. Auch Ruby rutschte aus den Top 20 ab und dürfte nach Einschätzung der Index-Betreiber so schnell nicht zurückkehren.

Ausblick auf 2026

Einen vorsichtigen Blick nach vorn wagt Tiobe ebenfalls. TypeScript könnte 2026 erstmals den Sprung in die Top 20 schaffen. Zudem sieht Tiobe Potenzial bei Zig, das sich 2025 von Platz 61 auf 42 vorarbeitete und damit näher an die Top 30 heranrückte.

Bei der Berechnung des Index möchten die Betreiber die Anzahl der Engineers, Kurse und Dienstanbieter bewerten, die eine Programmiersprache verwenden. Das trägt Tiobe über die Anfragen bei verschiedenen Internet-Suchmaschinen zusammen. Die Betreiber weisen selbst darauf hin, dass der Index eher zur Überprüfung der Aktualität von Programmierkenntnissen und zur strategischen Entscheidung bei der Auswahl von Programmiersprachen für neue Projekte zum Einsatz kommen sollte.

Weitere Informationen finden sich im Beitrag auf der offiziellen Tiobe-Website.

(mdo)

In dieser Folge sprechen Anne Görs, Senior User Researcher, Founder und Managing Director bei der leefs CX GmbH, und Dominique Winter darüber, wie sich User Research operationalisieren lässt, sodass sie dauerhaft Teil der Produktarbeit wird. Ausgangspunkt ist die Beobachtung, dass viele Teams User Research grundsätzlich schätzen, sie aber als zu langsam, zu aufwendig oder störend für schnelle Entscheidungen wahrnehmen. Genau hier setzt der Gedanke an, User Research zu operationalisieren und so in den Arbeitsfluss einzubetten, dass sie Entscheidungen unterstützt, statt sie auszubremsen.

Entscheidungen auf Basis nachvollziehbarer Erkenntnisse

User Research zu operationalisieren bedeutet, Forschung nicht als einmaliges Projekt zu denken, sondern als wiederkehrenden, verlässlichen Prozess. Es geht darum, Strukturen zu schaffen, die Wiederholbarkeit ermöglichen, ohne die nötige Flexibilität zu verlieren. Dazu gehören klare Verantwortlichkeiten, abgestimmte Abläufe und ein gemeinsames Verständnis dafür, wofür Erkenntnisse genutzt werden. Forschung wird dadurch planbarer und verliert den Ruf, ein Bremsklotz zu sein. Stattdessen erhöht sie die Wahrscheinlichkeit, mit den getroffenen Entscheidungen tatsächlich Wirkung zu erzielen.

Dazu braucht es auch einen bewussten Umgang mit Unsicherheit. User Research liefert schließlich keine Wahrheiten, sondern reduziert Risiken. Wenn Teams und Stakeholder verstehen, dass Forschung dabei hilft, bessere strategische Wetten einzugehen, verändert sich die Akzeptanz spürbar. Entscheidungen basieren dann nicht mehr ausschließlich auf Erfahrung oder Bauchgefühl, sondern auf nachvollziehbaren Erkenntnissen über Nutzerinnen und Nutzer. Das stärkt Vertrauen in den Prozess und in die Menschen, die ihn verantworten.

Aber damit das Operationalisieren der User Research gelingen kann, braucht es auch Wege, Erkenntnisse so aufzubereiten, dass sie im Alltag genutzt werden. Forschung entfaltet nur dann ihren Wert, wenn sie in konkrete Anforderungen, Prioritäten oder Entscheidungen übersetzt wird. Das erfordert enge Zusammenarbeit mit den Produktteams und ein Verständnis dafür, welche Form von Ergebnissen ihnen wirklich hilft. Einheitliche Templates oder starre Reportstrukturen greifen hier oft zu kurz.

Entscheidend ist also, dass Erkenntnisse anschlussfähig sind und dort ankommen, wo sie gebraucht werden. Teams profitieren davon, selbst beteiligt zu sein, zuzuhören, Fragen zu stellen und Forschung mitzuerleben. Diese Beteiligung erhöht die Akzeptanz der Ergebnisse und sorgt dafür, dass Erkenntnisse nicht infrage gestellt werden, nur weil sie unbequem sind. Gleichzeitig braucht es fachliche Begleitung, um die Qualität zu sichern und Fehlinterpretationen zu vermeiden.

Bestehendes hinterfragen

User Research zu operationalisieren heißt daher am Ende auch, kulturelle Voraussetzungen zu schaffen. Eine Organisation muss bereit sein, mit Feedback umzugehen, das bestehende Annahmen infrage stellt. Forschung deckt Schwächen auf und zeigt, wo Ideen nicht wie erwartet funktionieren. Wer das als Chance zur Verbesserung versteht, schafft Raum für kontinuierliches Lernen und bessere Produkte.

Der Blick richtet sich damit weniger auf einzelne Methoden als auf ein Zusammenspiel aus Haltung, Prozessen und Verantwortung. Wenn User Research dauerhaft Teil der Produktentwicklung wird, unterstützt sie Entscheidungen, reduziert Risiken und hilft Teams, näher an den tatsächlichen Bedürfnissen ihrer Nutzerinnen und Nutzer zu arbeiten. Genau dort entfaltet operationalisierte User Research ihre größte Wirkung.

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „User Research operationalisieren“.

(mai)

In den vergangenen 30 Jahren hat sich eine rege Community im Java-Umfeld gebildet. Ich habe im Laufe des Jahres einige deutschsprachige Vertreter zu ihren Erfahrungen befragt. Die Resonanz war überwältigend. Vielen Dank an alle, die mitgemacht haben. In diesem dritten Teil kommen Jens Schauder (Spring Data Team und ehemaliger Organisator der JUG Ostfalen), Richard Fichtner (Java Champion und Organisator JCON), Cay Horstmann (Java Champion, Buchautor), Ralf D. Müller (Open Source Committer und arc42 Contributor) und Mark Paluch (Spring Data Team und ehemaliger Organisator der majug) zu Wort.

Java prägt viele Entwicklerinnen und Entwickler seit ihren ersten Schritten in der IT – und hat in dieser Zeit Höhen, Tiefen und mehrere Neuerfindungen erlebt. Die folgenden Antworten spiegeln persönliche Anfänge, prägende Erlebnisse, kritische Momente und eine Einordnung von Javas Rolle in der heutigen Softwareentwicklung wider. Abschließend wagen sie einen Blick nach vorn: mit Tipps für die eigene Weiterentwicklung und Erwartungen an Java in den kommenden Jahren.

Wann und mit welcher Version bist du erstmals mit Java in Berührung gekommen?

Jens Schauder: Das war 1997. Ich habe zu der Zeit mit Fortran 90 an meiner Diplomarbeit gearbeitet und ein Bekannter hat mir total begeistert von Java erzählt. Ich habe mir dann das JDK heruntergeladen und ein kleines Applet gebaut, in dem ich Würfel gezeichnet habe. Im Wesentlichen eine Portierung eines der ersten Programme, die ich auf meinem ersten Rechner geschrieben habe, einem Apple. Ich kann mich an die Versionsnummer nicht wirklich erinnern, aber es war vermutlich 1.1.

Richard Fichtner: Meine erste Java-Anwendung habe ich im Jahr 2003 mit der Version J2SE 1.4 geschrieben. Java hat mir nicht gefallen. Ich war damit nicht produktiv. In Visual Basic 6.0 gab es einen GUI-Builder und mit PHP ließen sich schnell Webanwendungen bauen. Zum Glück hat Java hier nachgelegt.

Cay Horstmann: 1995 rief Gary Cornell mich an und teilte mir mit: „Cay, wir schreiben ein Java-Buch.“ Wir waren beide bekannte Buchautoren, ich für C++ und er für Visual Basic. Ich wusste dagegen nichts über Java, außer ein paar Gerüchten. Und er auch nicht. Aber er hatte es fertiggebracht, einen Buchvertrag mit Sun Microsystems Press zu bekommen. Denn Sun Microsystems Press hatte ein Problem. James Gosling und Ken Arnold hatten Sun Microsystems Press umgangen und den Vertrag für „The Java Programming Language“ mit einem angesehenen Verlag geschlossen. Also verbrachten wir den Herbst und Winter 1995, um Java gründlich zu lernen. Es half, dass ich als Professor eine „Research License“ für den Quellcode bekam. Das war lange vor Open Source. Dadurch konnten wir schreiben, was wirklich funktionierte und wo man vorsichtig sein musste. Das machte das „Core Java“-Buch, das zusammen mit Java 1.0 erschien, zum Bestseller.

Ralf D. Müller: Das war ganz früh an der Uni Frankfurt. Am 12. April 1996 haben einige Studenten die Java User Group Frankfurt (Vorgänger der heutigen JUG Frankfurt) gegründet. Damals war Java 1.0 aktuell.

Mark Paluch: Java 1.1, kurz bevor 1.2 im Dezember 1998 released wurde.

Was war rückblickend dein schönstes Erlebnis mit der Sprache oder dem Ökosystem Java?

Jens Schauder: Am meisten Spaß mit der JVM hatte ich in der Zeit, als ich mich mit Scala beschäftigt habe. Ich habe unglaublich viel darüber gelernt, was eine Programmiersprache, ein Compiler, ein Typsystem tun kann. Ich bin ständig mit Knoten im Hirn rumgelaufen und das war sehr, sehr cool.

Richard Fichtner: Das Schönste an Java sind die Menschen in der Community. Java hat sicherlich auch technisch viele tolle Sachen zu bieten, aber die Haltung und Kultur der Java-Community machen es aus. Open Source war für viele vor 20 Jahren unvorstellbar. Bei Java User Groups Wissen teilen – seid ihr wahnsinnig? Heute haben viele Organisationen verstanden, dass man zusammen erfolgreicher ist und offene Standards sowie Austausch uns alle voranbringen.

Cay Horstmann: Ich habe viele schöne und produktive Erfahrungen mit Java gemacht, aber wenn ich mir eine Erfahrung aussuchen muss, wäre das der Violet UML Editor. Ich weiß, heutzutage kräht kein Hahn mehr nach UML, aber wir fanden es damals (2002) wichtig. Ich wollte meinen Studenten Sequence-Diagramme beibringen. Die damals erhältlichen Produkte versagten mit diesem Diagrammtyp und außerdem waren sie sehr teuer. Ich schrieb eine Swing-Anwendung und war begeistert, dass ein Großteil der Routinearbeit durch die Java-Standardbibliothek abgedeckt war. Einige Jahre später hatte ich ein anderes Problem. Meine Studenten hatten Probleme mit Schleifen. Sie brauchten einfach mehr Übung. Ich entwickelte eine Webanwendung. Zum Glück in Java, denn ich bekam seitdem stetig Fragen von Studenten aus der ganzen Welt, ob sie nicht bei meinem Open-Source-Projekt mitmachen können. Dann lade ich sie gerne ein, um ein offenes Problem zu bearbeiten. Weil das Projekt in Java ist, finden sich die Studenten zurecht. Bei Rails (zu unbekannt) oder JavaScript (zu chaotisch) wäre es nicht so einfach, Mitstreiter zu finden. Und Java ist wahnsinnig stabil. Die Webanwendung hat sich über die Jahre von Glassfish zu Play und jetzt zu Quarkus gewandelt, aber der Kerncode besteht weiterin.

Ralf D. Müller: Ich hatte immer viel Spaß mit Groovy und Grails im Java-Ökosystem. Groovy hat es geschafft, eine leichtgewichtige Skriptsprache im Java-Ökosystem zu etablieren, die auch ohne IDE beherrschbar ist.

Mark Paluch: Für mich ist es wichtig, Wissen an andere Entwickler weiterzugeben und dabei auch von ihnen zu lernen, wie sie Java verwenden und in welchem Kontext. Konferenzen sind eine großartige Möglichkeit, mich mit der Java Community auszutauschen, und ein ganz besonderes Highlight.

Aber es ist nicht alles Gold, was glänzt. Was hat dich negativ beeinflusst beziehungsweise was war ein unschöner Moment im Java-Umfeld?

Jens Schauder: Das war Gradle. Ich habe eine Zeit lang Gradle als Build-Tool genutzt und es geliebt, da es mir erlaubte, kleine Skripte direkt im Build-Tool zu schreiben. Ich konnte damit Probleme lösen, die durch kafkaeske Architekturvorgaben eines Kunden verursacht wurden. Sehr cool! Das böse Erwachen kam, als ich ein Projekt, das ein Jahr lang herumlag, versuchte wiederzubeleben. Durch Updates von was auch immer funktionierte nichts mehr und ich habe mein eigenes Build-Skript nicht mal ansatzweise mehr verstanden.

Richard Fichtner: Die große Verunsicherung um die Lizenzierung von Java vor einigen Jahren war unschön und bedurfte viel Erklärung. Das hat sich zum Glück heute alles gelegt und die Auswahl an JDKs ist so groß wie noch nie.

Cay Horstmann: Circa 2009 war ich schon unglücklich mit der langsamen Weiterentwicklung von Java. Ich lernte Scala, benutzte es für einige Projekte und schrieb ein Buch darüber. Scala ist wirklich eine schöne und elegante Sprache, aber einfach ist sie nicht. Und auch nicht sonderlich stabil. Seitdem hat sich Java enorm weiterentwickelt. Scala ist immer noch eleganter, aber Java hat eine bessere Infrastruktur.

Ralf D. Müller: Die Open-Source-Community ist in der Java-Welt recht stark. Demgegenüber stehen im starken Kontrast die Rechtsstreitigkeiten zwischen den großen Firmen, die aus Java Kapital schlagen wollen. Das hat immer wieder die Community verunsichert.

Mark Paluch: Es ist schade, dass ein guter HTTP-Client (Java 11) und so etwas wie Single-File Programs es erst so spät in ein Java Release geschafft haben. Das sind Features, die gerade für den Einstieg in die Sprache eine große Rolle spielen. Es ist auch schön, dass Java nun eine API für Bytecode-Interaktion bereitstellt und ASM vielleicht langsam nicht mehr notwendig sein wird. JPMS ist für das JDK ein großer Schritt nach vorn gewesen. Für Bibliotheken ist es schade, dass Module-Info so sehr viel restriktiver (z. B. ein Modul pro JAR) gehandhabt wird, was zu der Wahrnehmung führt, dass Bibliotheken Bürger zweiter Klasse sind.

Glaubst du, dass Java auch nach 30 Jahren noch relevant ist? Welche Rolle spielt Java deiner Meinung nach in der modernen Softwareentwicklung, insbesondere im Vergleich zu anderen Sprachen und Technologien?

Jens Schauder: Java ist das langweilige Arbeitstier unserer Zeit und wird es noch lange bleiben. Projekte im Enterprise-Umfeld, in dem Java besonders stark ist, laufen lange und werden noch länger gewartet. Ich vermute daher, dass auch in 30 Jahren Java noch relevant sein wird. Ich sehe momentan nur einen Weg, das zu verhindern: Wenn es ein Tool gäbe, das Code in einer Sprache in hochwertigen Code einer anderen Sprache überführen kann. Viele Tools versuchen etwas Derartiges, um Cobol-Programme in Java umzuwandeln. Das Ergebnis ist aber meist noch schlimmer als der ursprüngliche Cobol-Code. Wer weiß, was KI da noch für uns tun wird. Und generell darf man nicht vergessen, wie viel 30 Jahre sind. Vor 30 Jahren hatten Handys das Format einer kleinen Werkzeugkiste. Und ein Rechner mit der Leistung eines aktuellen Mobiltelefons würde vermutlich einen Raum füllen.

Richard Fichtner: Ich hoffe, dass Java noch relevant ist. Mit dem neuen sechsmonatlichen Release-Zyklus und den zweijährlichen LTS-Releases ist viel Bewegung und Erneuerung in die Java-Welt gekommen. Java hat viele moderne Features und ist gleichzeitig noch sehr rückwärtskompatibel zu Code von vor 30 Jahren. Ich bin zuversichtlich.

Cay Horstmann: Die am meisten benutzten Programmiersprachen (C++, Python, Java, JavaScript) sind alle etwa 30 Jahre alt. Neuere Sprachen wie Go, Ruby, Rust und Swift haben ihre Nischen, aber es ist nicht einfach, darüber hinaus zu wachsen. Die Programmiersprache ist nur ein Teil der Infrastruktur. Java hat ausgezeichnete Tools und Bibliotheken sowie ein technisch kompetentes und motiviertes Team, das die Sprache weiterentwickelt. Die JVM gibt Stabilität und Einsicht in das Verhalten laufender Programme. Das ist für viele Anwendungen wichtig. Ich sehe zurzeit keine Sprache oder Technologie, die Java das Wasser abgraben würde. Zumindest abgesehen von KI. Es ist natürlich vorstellbar, dass es bald keine menschlichen Entwickler mehr gibt, sondern dass ein Manager der KI einfach erzählt, was sie programmieren soll. In irgendeiner Sprache. Aber ganz glauben kann ich das nicht. Ich benutze gerne KI für „Autocomplete“-Vorschläge. Aber selbst da geht genug schief, dass ich meine, wir sind nicht so schnell ersetzbar.

Ralf D. Müller: Java ist etabliert. Die Sprache hat zwar ihr ursprüngliches Versprechen „Write once, run anywhere“ nicht so erfüllen können, wie andere Sprachen es gefühlt schaffen, aber Java-Programme laufen auf einer Vielzahl von Systemen, die den Betrieb unserer modernen Welt sicherstellen. Durch Python und JavaScript gibt es zwei Herausforderer, denen Java in verschiedenen Bereichen (ML, Web) das Feld überlassen muss. Hier wird es spannend zu sehen, welchen Einfluss GenAI auf die weitere Entwicklung haben wird. Da die Large Language Models gerade in der Erzeugung von Python-Code sehr stark sind, wird hier ein verstärkter Effekt entstehen. Java ist durch seine Struktur eher nicht optimal für die Generierung durch LLMs aufgestellt.

Mark Paluch: Java ist ein fundamentaler Baustein moderner Softwareentwicklung und gleichzeitig wird Java jedes Jahr neu totgesagt. Jetzt sind wir hier nach 30 Jahren Java. Die Veränderungen in der Sprache und der Standardbibliothek zeigen, wie relevant Java ist. Derzeit ist für mich das Wichtigste, dass die Sprachentwicklung durch eine diverse Community vorangetrieben wird. Valhalla, Babylon und Leyden sind die bedeutendsten Projekte seit Generics und Functional Interfaces.