Seite 3: Fazit

Inhaltsverzeichnis

Stärken und Schwächen

Die größte Stärke von F# ist zugleich die größte Schwäche: die Flexibilität. Auf der einen Seite ist es ausgesprochen begrüßenswert, dass eine Sprache mehrere Paradigmen unterstützt und diese
nahtlos kombinieren kann, auf der anderen Seite geht dadurch der Fokus verloren.

Die größten Stärken zeigt F# in den anfangs genannten Bereichen aus: Parallelisierung, korrekterer Code und deklarative Entwicklung. Außerdem beweist F# Stärken im mathematisch-algorithmischen Bereich, da eine kompaktere, übersichtlichere und komfortablere Entwicklung realisierbar ist. Die native Unterstützung der Sprache für Konzepte wie Rekursion oder Listen erweist sich hierbei als positiv.

Letztlich folgt F# damit dem von Perl bekannten TIMTOWTDI-Konzept ("There is more than one way to do it"): Als Entwickler hat man die Wahl zwischen unterschiedlichen Wegen, vom funktionalen über den imperativen bis hin zum objektorientierten, und kann beziehungsweise muss stets individuell entscheiden, welcher Weg sich am besten zur Lösung eines gegebenen Problems eignet. Angenehm ist vor allem, dass man mit der Wahl eines dieser Wege nicht auf ebendiesen festlegt ist, sondern dass man für jede einzelne Zeile Code erneut die Wahl hat und dadurch viel Flexibilität gewinnt. Als Entwickler steht man demnach nicht nur vor einer Vielzahl von sprachlichen Mitteln, sondern muss sich zudem noch mit der Frage beschäftigen, welche von mehreren – scheinbar gleichartigen – Vorgehensweisen am ehesten das gewünschte Ergebnis erbringt.

Stan Lees Diktum "With great power comes great responsibility" trifft auch auf F# zu. Während C# den Entwickler weitgehend an die Hand nimmt, um typische Fallstricke zu vermeiden, und ihm Mittel gibt, sich auf die eigentliche Aufgabe statt auf die Sprache zu konzentrieren, geht F# anders an. Allein die Frage, ob Typen in F# als Records oder als Klassen zu implementieren sind – wobei übrige Arten von Typen wie Enumerationen oder Strukturen noch gar nicht berücksichtigt sind –, kann weitreichende Auswirkungen auf die Architektur und das Design der Anwendung haben.

Es besteht durchaus Bedarf an Best Practices oder zumindest Hinweisen, wie man sich als Entwickler in gewissen Situationen verhalten und worauf man achten sollte. Bei C# findet sich das viel einfacher, sodass man sich eher auf die eigentliche Aufgabe konzentrieren kann. Das Argument, dass F# noch eine vergleichsweise junge Sprache ist, überzeugt an der Stelle nicht – zu groß ist die Verwandtschaft zu anderen funktionalen Sprachen wie OCaml oder ML, weshalb deren Best Practices auch für F# gelten. Das Problem ist nur: Die sind in der .NET-Welt eher unbekannt.

Funktionale Programmierung kann die Entwicklung durchaus vereinfachen und erleichtern. F# erfordert als Sprache deutlich mehr Nachdenken und bewusste Entscheidungen für den einen oder anderen Programmierstil seitens des Entwicklers, als das etwa bei C# der Fall wäre.

Fazit

Um die eingangs gestellte Frage, ob F# eine "General Purpose Language" ist, noch einmal aufzugreifen: Sie lässt sich pauschal zwar mit einem "Ja" beantworten, denn theoretisch ist mit F# all das möglich, was C# kann. Schließlich is t man als Entwickler nicht auf das funktionale Vorgehen beschränkt. Die Antwort lässt jedoch einen wichtigen Aspekt außer Acht: Sie impliziert nämlich, dass F# ebenso leicht wie C# als "General Purpose Language" anzuwenden ist. Genau das ist eben nicht der Fall. Daher sollte man F# nicht leichtfertig einsetzen, sondern sich zuvor einige Fragen stellen, um den Einsatz zu rechtfertigen oder zu verwerfen:

• Wie hoch ist der zu erwartende Anteil der funktionalen Programmierung an der Gesamtanwendung? Rechtfertigt dieser – gegebenenfalls kleine – Anteil den Einsatz einer weiteren Sprache? Würde man für den Anteil in einem ähnlichen Szenario auch eine andere "exotische" Sprache wie Erlang oder Lua einsetzen?
• Wie erfahren sind die Entwickler mit funktionalen Konzepten? Sind sie in der Lage, die angebotenen Möglichkeiten verantwortungsvoll, gezielt, effektiv und auch effizient einzusetzen?
• Wie aufwendig wäre es, die funktionalen Bereiche der Anwendung in einer klassischen Sprache wie C# zu implementieren? Anders formuliert: Wie hoch sind die Gewinne, die daraus entstehen, auf F# und die damit verbundenen funktionalen Konzepte zu setzen?
  

Golo Roden
ist freiberuflicher Wissensvermittler und Berater für .NET, Codequalität und agile Methoden. Er betreibt die Website guidetocsharp.de und ist in der myCSharp.de-Community aktiv.

Literatur

• Michael Stal; F wie funktional; Visual Studio 2010 mit der Programmiersprache F#; iX 8/2010, S. 115
• Oliver Müller; Ein neuer Halbton; F#: Funktional programmieren in .NET; iX 4/2005, S. 113
• Tomas Petricek; Real World Functional Programming Examples; Manning Publications, 2009