Für die SkeptikerInnen gibt es keinen Grund, eine neue Programmiersprache zu entdecken. Die meisten Sprachen sind heutzutage Turing-vollständig, d.h. sie können alles programmieren, was programmierbar ist. Wieso sollte man da etwas Neues lernen? Für bekennende Fans von Programmiersprachen, zu denen ich auch gehöre, ist das allerdings kein Argument. Eine neue Sprache zu finden, mit der ich mich noch klarer ausdrücken kann, ist immer wieder interessant.
Sprachen sind ein wesentlicher Bestandteil der Technologielandschaft. Deshalb haben sie im Thoughtworks Technology Radar, in dem wir unsere Ansichten zu Entwicklungen in der Technologiebranche teilen, auch ihren eigenen Quadranten. Die kürzlich erschienene 20. Ausgabe des Radars ist ein willkommener Anlass für mich, auf Veränderungen und Entwicklungen im Bereich Programmiersprachen zurück zu blicken.
Als wir die erste Ausgabe des Radars veröffentlichten, hatten EntwicklerInnen im Wesentlichen die Wahl zwischen Java, C# und C++. Diese Sprachen deckten die allermeisten Unternehmensanwendungen ab. Uns wurde aber schnell klar, dass das Ökosystem einer Programmiersprache genauso wichtig sein kann wie die Sprache selbst. Dies zeigte sich zuerst bei C++, später auch bei Java und C#, heute sieht man es bei Kotlin.
Heute könnten man sagen, diese Einschätzung sei falsch gewesen, Java ist schließlich nicht ausgestorben. Zum damaligen Zeitpunkt waren die Bedenken aber berechtigt. Sun Microsystems war gerade von Oracle übernommen worden, und Java hatte schon ewig kein neues Release herausgebracht.
Eine Einschätzung, bei der wir aber definitiv recht hatten, war die Einordnung von JavaScript als Sprache “erster Klasse”.
Sprachen erster Klasse verfügen über Werkzeuge und Ansätze wie Unit-Tests und Refactoring, die man beim Programmieren für produktive Umgebungen erwarten würde. JavaScript wurde vermehrt in wichtigen Unternehmensprojekten eingesetzt, allerdings damals ungerechtfertigt zur reinen Skriptsprache degradiert und unterschätzt. Auch wenn es eine Weile gedauert hat: Heute gilt JavaScript als ernstzunehmende Programmiersprache.
Ungefähr zur selben Zeit riefen wir dazu auf, sich generell mehr ernsthafte Gedanken um Programmiersprachen zu machen. Wir sahen damals die ersten Innovationen rund um neue Programmiersprachen auf der Java Virtual Machine (JVM). Als EntwicklerIn stellte man sich mehr und mehr die Frage: Welche Sprache ist angemessen, um etwas zu programmieren? Nur weil man in einem “Java-Shop” arbeitet, musste man vielleicht nicht mehr automatisch nur Code in Java schreiben. Wann ist vielleicht Clojure eher geeignet, wann JavaScript?
Damals gab es bei uns zwei Lager: Team Clojure und Team Scala. Wer als Sieger hervorgehen würde, war nicht abzusehen. Und vielleicht ist das auch heute noch nicht klar. Beide bringen die Stärke funktionaler Sprachen ins Unternehmen – jede auf ihre eigene Art. Während Clojure eher am funktionalen Paradigma festhielt, waren die Grenzen bei Scala fließender, und die Syntax war Java-ProgrammiererInnen vertrauter. Scala hatte anfangs ein fortschrittlicheres Ökosystem, z. B. das Play Framework - doch das änderte sich bald.
Die andere erwähnenswerte funktionale Sprache zu dieser Zeit war F#, die als Microsofts Beitrag im Bereich funktionaler Sprachen kaum ignoriert werden konnte. So zumindest die Theorie. In der Realität aber konnte sich F# nie richtig durchsetzen, obwohl viele Unternehmen sich stark an das Microsoft-Ökosystem gebunden haben.
Inzwischen haben wir bei Scala einige Aspekte gesehen, die potenziell zu Problemen führen können. Da die Sprache wie Java aufgemacht ist, kann Scala in derselben Anwendung mit ganz unterschiedlichen idiomatischen Stilen verwendet werden.
Diese Herausforderung haben wir auch im Radar zum Thema gemacht, in einem Eintrag mit dem Titel “Scala, the good parts”. Dies wirft generell die Frage auf: Wie trifft man denn nun eine gute Wahl bei der Entscheidung für Programmiersprachen? Diese Frage lässt sich vielleicht gar nicht eindeutig beantworten; denn Egal, wie die Entscheidung aussieht, das Team muss sich darauf einigen, wie es die Sprache nutzt und wie es ähnliche Probleme mit der Sprache angehen will. Bei der Problemlösung sollte nicht jede Entwicklerin ihren eigenen Ansatz wählen.
Eine Person, mit der ich sprach, fand die Sprache grauenvoll. Sie war der Meinung, dass ihre EntwicklerInnen jahrzehntealte Fehler wiederholt hatten. Jemand anders wiederum sagte mir er fände Go ganz toll, weil es so einfach zu benutzen sei. Dies verdeutlicht, dass zwei Menschen eine Programmiersprache völlig unterschiedlich erleben können, weil jeder von uns Probleme auf eine eigene Art angeht.
Wir glauben, dass das ein Fehler ist. Manchmal lässt sich in einer Sprache etwas klar ausdrücken, was in einer anderen schwerfallen würde. Und eine der wichtigsten Aufgaben der EntwicklerInnen ist es, klaren und damit leicht verständlichen Code zu schreiben.
Andererseits ist uns auch klar: Wenn alle EntwicklerInnen selbst entscheiden dürfen, welche Sprache sie verwenden, treten sehr wahrscheinlich ebenfalls Probleme auf. Was ist also die richtige Anzahl Sprachen für ein Unternehmen? Wir verwenden den Begriff polyglotte Programmierung, um zu verdeutlichen, dass die Auswahl an Programmiersprache(n) je nach Problemstellung umsichtig erweitert werden sollte.
Es empfiehlt sich für Unternehmen, mehrere Sprachen zu fördern, die unterschiedliche Ökosysteme oder Sprachfunktionen unterstützen, damit Unternehmen ihre Prozesse beschleunigen und schneller Software in Produktion zu bringen. EntwicklerInnen profitieren ihrerseits, weil sie die richtigen Werkzeuge für die jeweilige Problemstellung bekommen.
Sprachen sind ein wesentlicher Bestandteil der Technologielandschaft. Deshalb haben sie im Thoughtworks Technology Radar, in dem wir unsere Ansichten zu Entwicklungen in der Technologiebranche teilen, auch ihren eigenen Quadranten. Die kürzlich erschienene 20. Ausgabe des Radars ist ein willkommener Anlass für mich, auf Veränderungen und Entwicklungen im Bereich Programmiersprachen zurück zu blicken.
Als wir die erste Ausgabe des Radars veröffentlichten, hatten EntwicklerInnen im Wesentlichen die Wahl zwischen Java, C# und C++. Diese Sprachen deckten die allermeisten Unternehmensanwendungen ab. Uns wurde aber schnell klar, dass das Ökosystem einer Programmiersprache genauso wichtig sein kann wie die Sprache selbst. Dies zeigte sich zuerst bei C++, später auch bei Java und C#, heute sieht man es bei Kotlin.
Das Ende von Java?
In den ersten Ausgaben des Radars haben wir uns viel mit dem Schicksal von Java beschäftigt. Im November 2010 hielten wir das Ende von Java für möglich. Die schleppende Innovation bei Java machte uns Sorgen, und wir wollten unsere Bedenken mit anderen EntwicklerInnen teilen.Heute könnten man sagen, diese Einschätzung sei falsch gewesen, Java ist schließlich nicht ausgestorben. Zum damaligen Zeitpunkt waren die Bedenken aber berechtigt. Sun Microsystems war gerade von Oracle übernommen worden, und Java hatte schon ewig kein neues Release herausgebracht.
Eine Einschätzung, bei der wir aber definitiv recht hatten, war die Einordnung von JavaScript als Sprache “erster Klasse”.
Sprachen erster Klasse verfügen über Werkzeuge und Ansätze wie Unit-Tests und Refactoring, die man beim Programmieren für produktive Umgebungen erwarten würde. JavaScript wurde vermehrt in wichtigen Unternehmensprojekten eingesetzt, allerdings damals ungerechtfertigt zur reinen Skriptsprache degradiert und unterschätzt. Auch wenn es eine Weile gedauert hat: Heute gilt JavaScript als ernstzunehmende Programmiersprache.
Ungefähr zur selben Zeit riefen wir dazu auf, sich generell mehr ernsthafte Gedanken um Programmiersprachen zu machen. Wir sahen damals die ersten Innovationen rund um neue Programmiersprachen auf der Java Virtual Machine (JVM). Als EntwicklerIn stellte man sich mehr und mehr die Frage: Welche Sprache ist angemessen, um etwas zu programmieren? Nur weil man in einem “Java-Shop” arbeitet, musste man vielleicht nicht mehr automatisch nur Code in Java schreiben. Wann ist vielleicht Clojure eher geeignet, wann JavaScript?
Scala oder Clojure?
Über die Radar-Ausgaben hinweg haben wir auch den Aufstieg der funktionalen Programmiersprachen beobachtet. Sprachen wie Lisp und Haskell begleiten uns zwar schon seit Jahrzehnten, aber wir sahen auf einmal, wie Unternehmen begannen sich für funktionale Sprachen zu interessieren.
Damals gab es bei uns zwei Lager: Team Clojure und Team Scala. Wer als Sieger hervorgehen würde, war nicht abzusehen. Und vielleicht ist das auch heute noch nicht klar. Beide bringen die Stärke funktionaler Sprachen ins Unternehmen – jede auf ihre eigene Art. Während Clojure eher am funktionalen Paradigma festhielt, waren die Grenzen bei Scala fließender, und die Syntax war Java-ProgrammiererInnen vertrauter. Scala hatte anfangs ein fortschrittlicheres Ökosystem, z. B. das Play Framework - doch das änderte sich bald.
Die andere erwähnenswerte funktionale Sprache zu dieser Zeit war F#, die als Microsofts Beitrag im Bereich funktionaler Sprachen kaum ignoriert werden konnte. So zumindest die Theorie. In der Realität aber konnte sich F# nie richtig durchsetzen, obwohl viele Unternehmen sich stark an das Microsoft-Ökosystem gebunden haben.
Inzwischen haben wir bei Scala einige Aspekte gesehen, die potenziell zu Problemen führen können. Da die Sprache wie Java aufgemacht ist, kann Scala in derselben Anwendung mit ganz unterschiedlichen idiomatischen Stilen verwendet werden.
Diese Herausforderung haben wir auch im Radar zum Thema gemacht, in einem Eintrag mit dem Titel “Scala, the good parts”. Dies wirft generell die Frage auf: Wie trifft man denn nun eine gute Wahl bei der Entscheidung für Programmiersprachen? Diese Frage lässt sich vielleicht gar nicht eindeutig beantworten; denn Egal, wie die Entscheidung aussieht, das Team muss sich darauf einigen, wie es die Sprache nutzt und wie es ähnliche Probleme mit der Sprache angehen will. Bei der Problemlösung sollte nicht jede Entwicklerin ihren eigenen Ansatz wählen.
Im Auge des Betrachters
Weshalb diese Einigung im Team so wichtig ist, lässt sich am Beispiel Golang verdeutlichen. Wir haben die Aufregung – und die Konflikte – um Go zuerst 2014 mitbekommen.Eine Person, mit der ich sprach, fand die Sprache grauenvoll. Sie war der Meinung, dass ihre EntwicklerInnen jahrzehntealte Fehler wiederholt hatten. Jemand anders wiederum sagte mir er fände Go ganz toll, weil es so einfach zu benutzen sei. Dies verdeutlicht, dass zwei Menschen eine Programmiersprache völlig unterschiedlich erleben können, weil jeder von uns Probleme auf eine eigene Art angeht.
Eine Sprache für alle?
Ich erwähnte bereits am Anfang, dass manche Menschen keinen Wert in der Entwicklung neuer Sprachen sehen. Diese Einstellung ist nah verwandt mit der Idee, immer genau eine Sprache für alle Entwicklungsbereiche zu wählen.Wir glauben, dass das ein Fehler ist. Manchmal lässt sich in einer Sprache etwas klar ausdrücken, was in einer anderen schwerfallen würde. Und eine der wichtigsten Aufgaben der EntwicklerInnen ist es, klaren und damit leicht verständlichen Code zu schreiben.
Andererseits ist uns auch klar: Wenn alle EntwicklerInnen selbst entscheiden dürfen, welche Sprache sie verwenden, treten sehr wahrscheinlich ebenfalls Probleme auf. Was ist also die richtige Anzahl Sprachen für ein Unternehmen? Wir verwenden den Begriff polyglotte Programmierung, um zu verdeutlichen, dass die Auswahl an Programmiersprache(n) je nach Problemstellung umsichtig erweitert werden sollte.
Es empfiehlt sich für Unternehmen, mehrere Sprachen zu fördern, die unterschiedliche Ökosysteme oder Sprachfunktionen unterstützen, damit Unternehmen ihre Prozesse beschleunigen und schneller Software in Produktion zu bringen. EntwicklerInnen profitieren ihrerseits, weil sie die richtigen Werkzeuge für die jeweilige Problemstellung bekommen.
Was bringt die Zukunft?
Wir sind optimistisch, dass sich die Innovationswelle bei Programmiersprachen und Frameworks fortsetzt, und werden die weitere Entwicklung in den nächsten 20 Ausgaben des Technology Radars abbilden.Hinweis: Die in diesem Artikel geäußerten Aussagen und Meinungen sind die der Autor:innen und spiegeln nicht zwingend die Position von Thoughtworks wider.