the next big thing: Programmiersprachen: Gleich und doch nicht dasselbe

Gerfried Steube on January 18, 2017 - 9:05 am in Software-Entwicklung

[ad_1]

Für den einen heißt die Programmiersprache des Jahres 2016 Java, für andere ist sie Go. Das wirft die Frage auf, was unter dem Begriff Programmiersprache des Jahres überhaupt zu verstehen ist. Reife? Aktualität? Verbreitung? Alles zusammen? Nichts davon? Ein Erklärungsversuch.

Dass die Frage nach der Programmiersprache des Jahres schwierig zu beantworten sei, haben die beiden verlinkten Artikel bereits festgestellt. Sie betrachten die Antwort ihrerseits als eine Frage der jeweiligen Metrik beziehungsweise der Betrachtungsweise. Bestätigt wird das auch in den Artikelforen, wo die Kommentare entsprechend vielfältig ausfallen.

Desto erstaunlicher ist deshalb die Beharrlichkeit, mit der regelmäßig versucht wird, eine Sprache als Sprache des Jahres oder etwas Ähnliches zu küren. Der vermutlich bekannteste Ansatz ist der Tiobe-Index, der paradoxerweise zwar Go als Programmiersprache des Jahres bezeichnet, auf dessen erstem Platz sich aber Java befindet.

Rankings sind fragwürdig

Wie fragwürdig solche Rankings sind, zeigt sich, wenn man den Index einmal näher anschaut: Visual Basic .NET habe eine höhere Relevanz als JavaScript, und Assembler eine höhere als T-SQL (was erst auf Platz 33 liegt). Ob nun die Relevanz von JavaScript wiederum tatsächlich höher ist als jene von Assembler, mag auf den ersten Blick naheliegend sein, hängt aber faktisch vom Einsatzgebiet ab.

Während Assembler in sehr hardwarenahen Bereichen in Verbindung mit C vermutlich das Maß der Dinge sein dürfte, verhält es sich im Web umgekehrt. Das Mindeste, was man daher machen müsste, um eine Programmiersprache des Jahres zu benennen, wäre die Definition des Kontexts.

Doch selbst dann stellt sich die Frage, nach welchen Kriterien eine Sprache zu bewerten ist. Die Anzahl der Suchanfragen bei Google oder die der Fragen auf Stack Overflow eignet sich wohl kaum. Schließlich könnte das auch lediglich darauf hindeuten, dass eine Sprache besonders fehleranfällig oder schwierig in der Handhabung ist.

Nicht alle Sprachen sind gleich

Besonders auffällig ist, dass in nahezu jeder Diskussion zu dem Thema über kurz oder lang angemerkt wird, solche Vergleiche seien per se sinnlos, da man ohnehin jede Aufgabe in jeder Sprache umsetzen könne. Das ist allerdings falsch, denn selbst wenn man den Begriff der Turing-Vollständigkeit zugrunde legt, gibt es Sprachen, für die die Aussage nicht gilt.

Abgesehen davon dürfte allein das Argument der Turing-Vollständigkeit zeigen, dass nicht alle Sprachen gleich mächtig sind. Das Ausdrucksvermögen einer Sprache spielt nämlich für die praktische Tauglichkeit ebenfalls eine große Rolle. Wenn dem nicht so wäre, gäbe es keinen Bedarf an verschiedenen Sprachen, und es würde generell genügen, Programme für Turing-Maschinen zu schreiben.

Das Ausdrucksvermögen messen

Um das Ausdrucksvermögen einer Sprache zu messen, könnte man auf die Idee kommen, die Anzahl ihrer Schlüsselwörter zu zählen und jene Sprachen als besonders ausdrucksstark anzusehen, die viele Schlüsselwörter enthalten. Tatsächlich ist jedoch genau das Gegenteil der Fall: Je weniger Konstrukte eine Sprache enthält, desto flexibler lässt sie sich einsetzen, da sie weniger Einschränkungen vorgibt.

Eine sehr interessante These hat Paul Graham in seinem Essay “What Made Lisp Different” vorgestellt. Er beschreibt neun Ideen, die von verschiedenen Sprachen zu unterschiedlichen Graden umgesetzt werden. Je mehr dieser Ideen eine Sprache unterstützt, als desto ausdrucksstärker kann sie ansehen werden.

Während die meisten dieser Ideen inzwischen ihren Weg in den Mainstream gefunden haben, beispielsweise Bedingungen und Rekursion, gilt das für einige nicht. So existieren zwar Sprachen, die auf Anweisungen verzichten und es ermöglichen, Code ausschließlich auf der Basis von Ausdrücken aufzubauen, sie sind aber (noch) nicht die Regel. Unter anderem JavaScript und C# werden jedoch in dieser Richtung weiterentwickelt.

Konzepte statt Sprachen

Am Ende der Liste steht die Idee, Code als einen Baum von Symbolen auszudrücken und die Sprache jederzeit zur Verfügung zu haben, also während der Lade-, der Compile- und der Ausführungszeit. Das ermöglicht in Lisp die Redefinition und Erweiterbarkeit der Sprachsyntax, was Lisp zu einer programmierbaren Programmiersprache macht.

Nimmt man all das zusammen, könnte man auf die Idee kommen zu sagen, dass Lisp die Sprache des Jahres sei – und zwar jedes Jahr seit ihrem Erscheinen im Jahr 1958. Doch selbst das wäre subjektiv, denn ob das Ausdrucksvermögen einer Sprache als die Metrik schlechthin geeignet ist und ob die neun von Paul Graham genannten Ideen als Kriterien dafür dienen können, sei dahingestellt.

Vielleicht wäre es daher am besten, gar nicht nach einer Sprache des Jahres zu suchen, sondern sich auf die allen Sprachen zugrunde liegenden Konzepte zu besinnen. Je mehr dieser Konzepte man kennt, und je besser es einer Sprache gelingt, diese dem gewünschten Kontext entsprechend zu verpacken, desto besser ist die Sprache geeignet, die Herausforderungen des jeweiligen Jahres zu meistern.

tl;dr: Eine Programmiersprache des Jahres kann es bestenfalls in einem gegebenen Kontext geben. Sinnvoller wäre vermutlich, sich auf Konzepte statt Sprachen zu besinnen.

[ad_2]