ESE 2009: Don Syme über F# und Funktionale Programmierung


Hier in Ludwigsburg findet aktuell ja das Eclipse Summit Europe statt. Es sind rund 400 Leute dabei, und es gibt eine Menge zu lernen über Eclipse, einige der wichtigsten Eclipse-Projekte und die neuesten Entwicklungen zu Eclipse4 (kurz e4), dem noch etwas vagen und für manch einen auch sehr esoterischen nächsten großen Meilenstein in Eclipse.

Zwar ist mir noch niemand über den Weg gelaufen, der mir mit meinem DataBinding-Problem weiterhelfen kann, aber dafür gibt es eine Menge an Informationen und Eindrücke zu bewältigen.

Als Business Partner von Instantiations sind wir natürlich auch dam um Dan, Jaime und Nick zu unterstützen und Interessenten über die Neuerungen der Instantiations-Tools zu informieren. Aber das ist eine andere Geschichte…

Die heutige Keynote war bemerkenswert. Nicht nur, weil Don Syme für Microsoft arbeitet, sondern auch, weil er nicht über Java, sondern über F#, eine funktionale Programmiersprache von MS, und dabei für seine Demo nicht Eclipse, sondern VisualStudio benutzt hat. Und trotzdem wurde den ganzen Tag über an den Tischen und in den Kaffeegrüppchen darüber gesprochen, und nicht etwa, um ein Urteil über seinen dreifachen Frevel zu fällen, sondern um über funktionale Programmiersprachen, Type Inferencing und Scala zu diskutieren.

Und in der Tat war seine Keynote ein Highlight. Er zeigte einige sehr eindrucksvolle Beispiele, wieviel kompakter und verständlicher F# Code sein kann, verglichen etwa mit C#. Neben einem kurzen Schweinsgalopp durch die wichtigsten Sprachkonstrukte von F# und die Kernkonzepte funktionaler Programmierung brachte er auch einige gewichtige Argumente für funktionaler Programmierung zur Sprache:

  • Die Lästigkeit des vielen Syntax-Rauschens in Java oder C# verglichen mit FP
  • Die ökonomischen Effekte durch wesentlich niedrigere Fehlerraten (bekannter Weise sind die Codezeilen, die nie geschrieben wurden, die am wenigsten fehleranfälligen)
  • Den Spass am Programmieren, der in C# oder Java leider allzu oft verloren geht

Als Smalltalker fühlte man sich immer wieder an die eigene Umgebung erinnert, nicht zuletzt, als er in F#interactive in der Manier eines Workspaces Code-Schnipsel für Codeschnipsel mit der Maus selektierte und per “Execute”-Menü bzw. Tastenkürzel ausführte.

Die ersten Code-Beispiele waren dann auch noch sehr “normal” und da man in F# (wie übrigens auch in Scala) keine Typeninformationen eintippen muss, fühlt sich das ganze für einen Smalltalker sehr vertraut an.

Aber FP ist noch deutlich mehr: die FP ermöglicht es, Funktionen zu definieren und praktisch als Objekte immer wieder zu verwenden. Ähnlich vielleicht wie Smalltalk-Blocks, aber eben irgendwie auch anders. Durch Definition einer Funktion kann Code extrem kompakt gehalten werden (man ist ab und an im Hinterkopf den Begriff Makro zu bemühen, aber ein Makro ist ja nur ein Precompiler-Trick um Schreibarbeit zu sparen, und ist nicht der richtige Vergleich).

Die Trends, die aktuell in OO-Sprachen zu beobachten sind, so Syme, sind genau die Stärken der FP:

  • Immutable Data
  • Abfragesprachen in der Programmiersprache eingebettet
  • Lambda-Funktionen
  • Pattern Matching als Sprachelement
  • Einfache Syntax
  • Reduktion von Seiteneffekten

Genau diese sieht Syme in F# realisiert. Die Funktionale Programmierung wird aktuell ja als einer der vielversprechendsten Ansätze gesehen, um die Umsetzung von Programmen für Multiprozessor- und Multi-Core-Architekturen zu schreiben. Eine Funktion ist in sich abgeschlossen, operiert auf isolierten, unveränderlichen Daten und erzeugt neue, und kann daher isoliert auf einem Prozessor oder Core parallel ausgeführt werden.

Die Sprache F# hat zwei wesentliche Urpsünge: OCaml als Ideenlieferant für die Syntax und C# wegen des gemeinsamen Objektmodells.

Ein sehr wichtiger Aspekt, den Syme anspricht, ist die Tatsache, dass ein F#-Programm nahtlos in ein .Net-Umfeld eingebettet werden kann. Jede andere .Net-Sprache kann auf F#-Komponenten zugreifen, und umgekehrt natürlich auch. Dasselbe gikt für Scala, das ja nahtlos mit Java interoperieren kann.

So macht es möglicherweise Sinn, den GUI-Code in C# (Im Sinn: Java/Eclipse) zu schreiben, und die Business-Logik in F# (behalte Scala) umzusetzen.

FP hat das Zeug dazu, die Objekttechnologie abzulösen bzw. einen Schritt weiter zu bringen. Java, C# etc. sind Sprachen, in denen sehr viel technisch motivierter Krimskrams programmiert werden muss, den man sich in der FP sparen kann. Die Ansätze in JavaScript, Scala und F# dazu sind vielversprechend. Vielleicht ist Jave wirklich bald mehr eine Plattform als eine Programmiersprache, und vielleicht bewegen wir uns bald wieder auf einem neuen Terrain, der funktionalen Programmierung.

Ich wäre dabei. Die ganze Umgebung und die Denkweise in Scala oder meinetwegen F# ist einem Smalltalk-Entwickler sehr vertraut. Und doch gibt es einige neue Ideen und Konzepte zu entdecken und zu nutzen.

Achja: F# hat auch etwas, das mich doch sehr verwundert hat: Whitespace matters. Das heisst, es ist für Zeilen in einer Funktionsdefinition zwingend erforderlich, dass sie mit einem Tab eingerückt sind. Ich musste unweigerlich an Cobol und PL/1 denken, und habe innerlich den Kopf geschüttelt. Aber vielleicht gibt es ja eine gute Erklärung für diese Design-Entscheidung… Zumindest gibt es so keine Glaubenskriege über Einrückungen oder den richtigen Platz für schliessende Klammern…😉