maciek905 - Fotolia
Wie sich Programmiersprachen bis heute entwickelt haben
Programmiersprachen sind ein wesentlicher Bestandteil der Technologielandschaft. Es empfiehlt sich für Unternehmen, mehrere Sprachen zu fördern, um weiterzukommen.
Für Skeptiker gibt es keinen Grund, eine neue Programmiersprache zu entdecken. Die meisten Sprachen sind heutzutage Turing-vollständig, das heißt sie können alles programmieren, was programmierbar ist. Wieso sollte man also etwas Neues lernen? Für bekennende Fans von Programmiersprachen ist das kein Argument. Eine neue Sprache zu finden, mit der man sich klarer ausdrücken kann, ist immer wieder interessant.
Sprachen sind ein wesentlicher Bestandteil der Technologielandschaft. Deshalb haben sie im ThoughtWorks Technology Radar, in dem der Anbieter seine Ansichten zu Entwicklungen in der Technologiebranche teilt, auch eigene Quadranten. Die kürzlich erschienene 20. Ausgabe des Radars ist ein guter Anlass, auf Veränderungen und Entwicklungen im Bereich der Programmiersprachen zurückzublicken.
Als die erste Ausgabe des Radars veröffentlicht wurde, hatten Entwickler im Wesentlichen die Wahl zwischen Java, C# und C++. Diese Sprachen deckten die allermeisten Anwendungen ab. Doch es wurde 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?
Die erste Ausgabe des Radars hat sich mit dem Schicksal von Java beschäftigt. Im November 2010 wurde dabei das Ende von Java für möglich gehalten. Die schleppende Innovation bei Java machten vielen Sorgen.
Heute kann man festhalten, dass diese Einschätzung falsch war, da Java nicht ausgestorben ist. Zum damaligen Zeitpunkt waren die Bedenken aber berechtigt. Sun Microsystems war gerade von Oracle übernommen worden, und Java hatte schon lange 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 erwartet. 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 Entwickler stellte man sich mehr und mehr die Frage: Welche Sprache ist angemessen, um etwas zu programmieren? Nur weil man in einem Java-zentrierten Unternehmen arbeitet, muss man nicht automatisch nur Code in Java schreiben. Wann ist vielleicht eventuell eine andere Sprache besser geeignet?
Scala oder Clojure?
Darüber hinaus 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 in Unternehmen. Während Clojure eher am funktionalen Paradigma festhält, sind die Grenzen bei Scala fließender, und die Syntax ist Java-Programmierern vertrauter. Scala hatte anfangs ein fortschrittlicheres Ökosystem, zum Beispiel das Play Framework – doch das änderte sich schnell.
Die andere erwähnenswerte funktionale Sprache zu dieser Zeit war F#, die als Microsofts Beitrag im Bereich funktionaler Sprachen kaum ignoriert werden konnte. In der Realität konnte sich F# allerdings nie richtig durchsetzen, obwohl viele Unternehmen sich stark an das Microsoft-Ökosystem gebunden haben.
Inzwischen gibt es bei Scala einige Aspekte, die potenziell zu Problemen führen. Da die Sprache wie Java aufgebaut 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 allerdings generell die Frage auf: Wie trifft man eine gute Wahl bei der Entscheidung für Programmiersprachen? Diese Frage lässt 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 jeder Entwickler einen eigenen Ansatz wählen.
Weshalb diese Einigung im Team so wichtig ist, lässt sich am Beispiel der Programmiersprache Go verdeutlichen. Einige Programmierer finden die Sprache grauenvoll, da für sie jahrzehntealte Fehler darin wiederholt wurden. Andere wiederum sagen, Go ist eine gute Sprache, da sie einfach zu benutzen ist. Dies verdeutlicht, dass Entwickler eine Programmiersprache unterschiedlich erleben, da jeder Probleme auf eine eigene Art angeht.
Eine Sprache für alle?
Bereits am Anfang wurde erwähnt, 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.
„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 bringen können.“
Dr. Rebecca Parsons, ThoughtWorks
Wir glauben, dass das ein Fehler ist. Manchmal lässt sich in einer Sprache etwas klar ausdrücken, was in einer anderen schwerfällt. Und eine der wichtigsten Aufgaben der Entwickler ist es, klaren und damit leicht verständlichen Code zu schreiben.
Andererseits ist auch klar: Wenn alle Entwickler selbst entscheiden dürfen, welche Sprache sie verwenden, treten 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 Programmiersprachen 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 bringen können. Entwickler profitieren ihrerseits, da sie die richtigen Werkzeuge für die jeweilige Problemstellung bekommen.
Wir sind optimistisch, dass sich die Innovationswelle bei Programmiersprachen und Frameworks fortsetzt, und werden die weitere Entwicklung in den nächsten Ausgaben des Technology Radars abbilden.
Über den Autor:
Dr. Rebecca Parsons ist Chief Technology Officer bei ThoughtWorks. Sie ist bereits seit Jahrzehnten an der Entwicklung von Anwendungen für ganz unterschiedliche Branchen und Systeme beteiligt. Im Rahmen ihrer technischen Erfahrungen war sie führend an der Entwicklung großvolumiger Anwendungen für verteilte Objekte und der Integration heterogener Systeme beteiligt. Sie ist Autorin mehrerer Bücher, ihre jüngste Neuerscheinung trägt den Titel „Building Evolutionary Architectures“.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder und entsprechen nicht unbedingt denen von ComputerWeekly.de.
