Wie funktionale Programmierung die .NET Welt erobert
Das .NET Universum besteht aus 3 Programmiersprachen, die – zumindest in der Theorie – komplett austauschbar sind: C#, VB und F#. In den aktuell besten Schätzungen, welche Programmiersprachen weltweit am meisten eingesetzt werden, finden sich C# und VB beide in den Top 10. F# dagegen reicht es abseits des Scheinwerferlichts knapp in die Top 100. Doch warum fristet F# dieses Schattendasein, während die Geschwister auf der grossen Bühne auftreten? Um dies zu beantworten, bedarf es eines kurzen Exkurses in die Paradigmen der Programmiersprachen.
- Autor:in
- Mark Mancktelow
- Veröffentlicht
Exkurs: funktional vs. objektorientiert
C# und VB sind vorwiegend objektorientierte Programmiersprachen (OOP). Der Focus liegt auf Objekten, die in einer Art Stammbaum aufeinander aufbauen und dabei Eigenschaften aller Vorfahren vererbt bekommen. Diese Objekte – meist in Form von Klassen – enthalten neben den Daten auch Funktionen, welche die Daten verändern können. Es wird also versucht, die Realität durch Objekte und deren Verhältnisse zueinander abzubilden.
Bei der funktionalen Programmierung (FP) liegt der Fokus dagegen auf den Funktionen (obviously). Jede Funktion gibt ein Resultat zurück, das allein von der Eingabe abhängig ist. Diese Operationen können dann verkettet werden, um komplexere Vorgänge abzubilden.
C# und VB sind beide grundsätzlich objektorientierte Sprachen, die aber einen funktionalen Ansatz erlauben, wenn man dies will. F# dagegen ist konzeptuell funktional ausgerichtet. Erlaubt aber auch OOP, wenn dies gewünscht wird.
Einflüsse aus F# in C#
Interessant bei diesen Überschneidungen der Paradigmen ist, dass C# immer funktionaler wird. Dies sowohl in der Entwicklung der Sprachfeatures als auch in den Erwartungen an die Entwickler, was guten Code darstellt.
LINQ (Language Integrated Query) wurde mit .NET 3.5 im Jahr 2007 eingeführt und kennt ein Fluent Interface, bei dem Methodenaufrufe aneinandergekettet werden. Dies ist noch stark OOP, da die geketteten Aufrufe immer auf einem Objekt erfolgen, das auch durch diese Methoden verändert werden kann. Es ist aber von der Charakteristik und der Art, wie Vorgänge beschrieben werden, ein erster Schritt in Richtung FP.
Mit C# 8 wurde ab September 2019 die Möglichkeit geboten, in einem Projekt bestimmen zu können, dass Referenztypen explizit gekennzeichnet werden müssen, wenn diese Null sein können. Dieses Feature, das den Entwicklern schon früh Unterstützung bei der Erkennung möglicher Programmierfehler bietet, war in F# schon von Anfang an (2005) im Einsatz. Ebenfalls wurde die switch Expression eingeführt, die in der Syntax stark an das switch von F# erinnert und alle Vorteile des F#-switches mitbringt.
Mit C# 9 von November 2020 kamen auch Records dazu: Eine Datenhaltung, bei der alle Daten unveränderbar sind, wenn das Objekt erst erstellt ist, und bei der die Gleichheit zweier Records über die Gleichheit aller Eigenschaften und nicht über identische Referenzen bestimmt wird. Damit ist nun in C# eine eingebaute Möglichkeit vorhanden, die Datenhaltung aus der FP und im speziellen aus F# zu übernehmen.
Mit C# 10 (November 2021) wurden die Möglichkeiten von Lambda-Funktionen in C# ausgebaut. Lambdas ermöglichen in C# den funktionalen Ansatz, dass Methoden als Parameter übergeben werden und somit vollwertige Mitglieder der Sprache sind.
Warum dann nicht gleich F#?
Es ist also klar, dass mit jeder der letzten neuen C#-Versionen die Möglichkeiten, in C# einen funktionalen Ansatz bei der Entwicklung zu wählen, entweder erweitert oder vereinfacht wurden. Sowohl in den Möglichkeiten der Sprache als auch in den Erwartungen an die Entwickler, wird der funktionale Ansatz immer präsenter. Wenn aber in C# - einer grundsätzlich OO Sprache – immer funktionaler gearbeitet wird, stellt sich die Frage, warum dann nicht gleich auf F# gewechselt werden sollte. Diese Sprache würde den gewünschten Stil besser unterstützen.
Hier gibt es derzeit zwei Hauptursachen, warum trotz stetig funktionalerer Denkweise noch immer auf eine OO-Sprache gesetzt wird: Altlasten und die Rekrutierung. Sehr viele bestehende Komponenten und Software-Bibliotheken sind OO und lassen sich daher nur mit etwas Umstand und Stilbruch in der FP-Welt einsetzen. Diese Brüche sind zwar nicht schlimm, erschweren jedoch das komplette Eintauchen in die F#-Welt.
Der womöglich entscheidende Faktor aber, warum statt auf F# zu setzen einfach FP-Style C# wächst, ist der Arbeitsmarkt. Es ist derzeit schwer genug, qualifiziertes Personal für C# – einer Top 10 Sprache – zu finden. Wenn man bedenkt, dass derzeit mindestens 100-mal mehr C# als F# entwickelt wird, sind diese Erfahrungen unverzichtbar. F# wird also in absehbarer Zukunft weiter für viele Probleme die schönere, aber unrealistische Antwort bleiben.
Verwandte Themen
Weiterführende Projekte und Inhalte zum Thema