Die Vorteile funktionaler Programmierung (im speziellen F#)

TL;DR: Weniger Code mit FP und F#.

Was ist es denn genau, was in der Funktionalen Programmierung mit F# den Code, also die Problemlösung, so vereinfacht und verkürzt?

Zu meinem Blog-Post "Less Code and Less Bugs : with Functional Programming languages"
http://functionalsoftware.net/less-code-and-less-bugs-with-functional-programming-languages-589/
bei dem es darum geht, das "weniger Code auch weniger Fehler" hat,
möchte ich hier aufzeigen mit welchen speziellen Sprachkonstrukten F#
  • das Code Verständnis erhöht und

  • dabei prägnanten Code ermöglicht

    (prägnant = knapp, treffend, gehaltvoll.)

    (concise = giving a lot of information clearly and in a few words; brief but comprehensive.)


Es folgt eine Auflistung von ausgewählten F# Features, die in etwa in dieser Reihenfolge aufeinander aufbauen für eine Problemlösungs-Formulierung, und massgeblich für das Code Verständnis und Code Korrektheit dienlich sind.

Was das Code Verständnis und Code Korrektheit am meisten fördert, sind:
  • Funktionen

    Input -> Output : den Output an einem klar definierten Ort im Code und die exakte Type Information des Output.

  • Die Pipe |>

    und Arrow >> Syntax ermöglicht den Daten/Program-Fluss in eine Richtung (ähnlich einem visuellen Flow-Diagram), die der natürlichen Leserichtung von links nach rechts (in unserer Kultur) folgt. Dies erleichtert auch das Naming, weil nicht für jedes Zwischenergebnis das nur einmal weiter gegeben wird ein Name/Bezeichner gefunden werden muss. Je nach verwendeter Namenskonventionen kann dies sehr mühsam zu lesen sein (Wortlängeneffekt, Erinnerungsleistung, Speed-Reading). Statt benannte Zwischenergebnisse Schritt für Schritt anzuwenden x = f() ; y = g(x) ; z = y das definieren was es ist z = f() |> g

  • Higher Order Functions (HOF) https://en.wikipedia.org/wiki/Higher-order_function

    sind Funktionen die Funktionen transformieren und mit minimalem syntaktischen Aufwand codiert werden. Man braucht nur den Funktionsnamen zu übergeben und die Interface-Typen werden von der Type-Inference automatisch ermittelt. Man braucht so nichts zu deklarieren (keine Func, Action, delegate, Interface), einfach nur zusammenbauen.

  • Expressions

    statt Statements (Referential Transparency, Pure Functions) - kurz : das WAS statt das WIE

  • Immutability

    als default und Mutation als Ausnahme.

  • Type Inference https://de.wikipedia.org/wiki/Typinferenz

    nicht weil man weniger Typen Signaturen schreiben muss, sondern weil es "fast" nebensächlich ist und es einfach passen muss, was die Type Inference im Editor während des Code schreibens prüft und signalisiert.

  • Algebraic Data Types (ADT) https://en.wikipedia.org/wiki/Algebraic_data_type

    Prägnanter exakter Daten Design mit Summen- und Produkt-Typen, die auch rekursiv zusammen gestellt (Composition) werden können.

  • Pattern Matching https://msdn.microsoft.com/en-us/library/dd547125.aspx

    ein vom Compiler überwachter Verzweigungs-Control-Flow damit kein (Spezial)-Fall vergessen wird. Man stelle sich das als super intelligentes switch-case Konstrukt vor, das mit den Algebraic Data Types perfekt harmoniert.

  • Computation Expression (CE) https://msdn.microsoft.com/en-us/library/dd233182.aspx

    ermöglicht Code-Plumbing hinter den Kulissen zu erledigen. So ist nur die Essenz in der Computation Expression ersichtlich. Die Logik dahinter, der Computation Builder, kann wiederverwendet werden. Mittels dieser Computation Expression lassen sich elegant z.B. Monaden usw. implementieren.

  • Units of Measure https://msdn.microsoft.com/en-us/library/dd233243.aspx

    vom Compiler geprüfte und berechnete Masseinheiten.

  • Domain Specific Language (DSL), Domänenspezifische Sprache https://de.wikipedia.org/wiki/Dom%C3%A4nenspezifische_Sprache

    F# eignet sich hervorragend um embedded-DSL's zu implementieren, denn man braucht dazu keine Lexer/Parser zu schreiben und kann die DSL in der Entwicklungsumgebung anwenden. Dies ist einfach möglich, da F# nebst kompliliertem Code auch als Scripting verwendet werden kann, das dann wiederum Kompiliert werden kann. Somit hat man für die eigene Domain Specific Language die Spracheigenschaften von F#, wie strict-static-typing und die Entwicklungsumgebung mit samt dem Debugger (wenn nötig). Ein bekanntes und viel angewandtes Beispiel einer embedded-DSL ist FAKE, ein F# Open Source Build Automatisierungs Scripting Tool ("make").


Hier einige Referenzen mit Beispielen die zeigen wie prägnant F# Code sein kann, im Vergleich mit C# Code.

"An F# rewrite of a fully refactored C# Clean Code example"
http://functionalsoftware.net/fsharp-rewrite-of-a-fully-refactored-csharp-clean-code-example-612/

"Analyzing Government Data"
in C# #csharp http://blogs.msdn.com/b/dave_crooks_dev_blog/archive/2015/04/20/intro-to-c-and-analyzing-government-data.aspx
und F# #fsharp http://fssnip.net/qE

"Does the Language You Use Make a Difference (revisited)?"
http://simontylercousins.net/does-the-language-you-use-make-a-difference-revisited/

"F# means less code"
http://fpbridge.co.uk/why-fsharp.html#conciseness

F# Videos 2015

Eine sehr gute Staffel von Videos zu F#, kurz und auf dem Punkt. 
Von Tomas Petricek und Seth Juarez von Channel9. Erschienen am 6.6.2015.

1. F# für Manager und CTOs
Time-to-Market (TTM),  Korrektheit, komplexe Probleme lösen, effiziente skalierbare Software

2. F# für Architekten und Domain Experten
Domain Driven Development (DDD)

3. F# für Web Entwickler und Data Scientists
Eleganter Zugriff auf Web-Services mit minimalem Code und ohne Tools.

4. F# für Web Entwickler
Eine WebApp in unter 50 Zeilen Code mit Azure Deployment.


Wer mit .NET entwickelt sieht sich am besten die ganze F# Video Staffel (1-4) an, es ist empfehlenswert!

1. Für Manager
“Making the Case for using F#”


2. Für Architekten und Domain Experts
“Domain Modeling in F#”


3. Für Web Entwickler und Data Scientists
“Type Providers in F#”


4. Für Web Entwickler
“Deploying an F# Web Application with Suave”


Weiterführende Information zu Suave gibt es hier :
– Eine komplette Beschreibung zu einer “Music Store” Suave WebApp https://www.gitbook.com/book/theimowski/suave-music-store/details
– Suave Web Development F# Library https://github.com/SuaveIO/suave
– Suave Homepage : Suave is a lightweight, non-blocking web server http://suave.io/

Warum Unternehmen noch zögern mit F#

Ich denke die wesentlichen 3 Gründe (“als grob zitierte Aussagen”) warum sich ein Unternehmen noch nicht getraut F# einzusetzen, nebst all den bekannten Vorteilen, sind:
  • 1. “Eine andere Sprache bringt nichts” “Das Problem das wir haben ist nicht das Programmieren, wozu dann eine andere Programmiersprache?” Das “Funktionale” an einer Funktionalen Programmiersprache ist weit mehr als Lambda-Funktionen und LINQ-Expressions. Es ist nicht nur die Sprache die bei F# anders ist, es ist die Funktionale DENKWEISE! Lernen anders zu Denken, um Probleme einfacher zu lösen, hat noch niemandem geschadet, im Gegenteil! Die Funktionale Denkweise birgt jede Menge neuer Konzepte, Techniken und Tricks, die Objekt-Orientierten-Praktikern meist unbekannt sind. Und die Denkweise wirkt sich auf die Software Entwicklung aus und das auch in anderen Programmiersprachen.
“Without exception, everybody I know who learned F# would say that it made them a better C# programmer. That’s the kind of thing that actually will make a difference during the week.” — Eric Sink (@eric_sink)  [1]   “becoming a better programmer” Warum das so ist? Es ist die Denkweise die sich erweitert hat und die Möglichkeiten diese Umzusetzen.
  • 2. “Es gibt zur Zeit zu wenig F# Entwickler” “Diese einfach vom Markt einzukaufen ist ja z.Z. nicht so einfach möglich.” Dann bildet doch einige aus, am besten ein Team! Ihr werdet sicher Freiwillige finden. Es sind diejenigen Entwickler die schon ein Auge auf Funktionale Programmierung (FP) oder F# geworfen haben und sich privat damit auseinandersetzen. Es sind meist die Talentiertesten der Entwickler die das tun und diese sehen sich auch um am Markt. Lasst sie nicht zu einer anderen Firma abwandern, weil man dort FP oder F# einsetzt und bei euch nicht!
“Startups are beginning to realize the potential for leveraging F# as a way to attract talented developers away from their otherwise satisfactory jobs to try something different just so they can finally turn their F# hobby into a full-time job.” [1]   “F# made me a far better C# developer. I’m delighted I can write F# a lot in my day job now, and I left an otherwise great position to do so.” — Ryan Riley (@panesofglass) [1]
  • 3. “Schulungskosten” “C# 6 hat auch ganz viel Neues, da haben wir erst mal zu tun.” Was auch Schulungsaufwand bedeutet! Und diejenigen die Neues Lernen möchten, sollte man im Unternehmen halten. Ja man muss investieren in die eigenen Entwickler! Und in andere Denkansätze zu Investieren, die Probleme einfacher lösen können, ist ein grundsätzlicher Wettbewerbsvorteil. Und weil noch nicht alle dies erkannt haben, packen Sie die Chance vor den anderen!
 

Wir bieten Hilfe für einen fundierten Einstieg in FP mit F#

Unser F# Kurs vermittelt die Denkweise des Funktionalen Programmierens (FP) von Grund auf, ohne zu sehr akademisch oder mathematisch zu werden. Die F# Programmiersprache wird praxisorientiert gelernt, immer aufbauend auf den Funktionalen Prinzipien, Schritt für Schritt. So lernt man von Kleinen der Funktionen bis ins Grosse der Module wie man per Komposition die Software Lösung entwickelt. Ich habe die Erfahrung in meinen F# Kursen gemacht, dass Senior Software Architekten und CTOs, bei einigen FP-Prinzipien die Köpfe geraucht haben (das ist stark positiv, denn das ist die Reaktion des Gehirns auf die neuen Denkweisen!) und dann gestaunt haben wie elegant man komplexe Dinge lösen kann, und nicht mehr warten konnten es gleich auszuprobieren. Zum Kurs Angebot      [1] “Why are C# programmers afraid of F# or functional languages in general?” 150115 https://dotnetkicks.com/stories/105569

Videos zum Thema Funktionale Programmierung (FP)

Hier sind einige neue interessante und zum anders Denken anregende Videos zum Thema Funktionale Programmierung (FP). Warum sich jeder Software Entwickler mit FP befassen muss!

Weckruf – rüttelt an dem wie man bisher Software entwickelt(e).

Titel: Functional Programming: What? Why? When? Aussage: The Failure of State Autor: Robert C. Martin Titel: Programming in Interesting Times Aussage: YOUR PROGRAMMING LANGUAGE IS GOING TO DIE Autor: Russ Olsen Titel: One Hacker Way, a Rational Alternative to Agile Aussage: With Scrum we talk too much about code, instead of writing code. Uses the F***-word Autor: Erik Meijer Titel: Type Systems – The Good, Bad and Ugly Aussage: Not relying on type safety is unethical (if you have an SLA) Autor: Paul Snively and Amanda Laucher

   

Zeigt die Möglichkeiten von F#

Titel: FSLAB: DOING DATA SCIENCE WITH F# Aussage: How to get knowledge from data? Autor: Tomas Petricek Title: MBrace: large-scale programming in F# Aussage: Cloud Computing is easy with F# Autor: Eirik Tsarpalis

Apple Swift ein F# Klon?

Am 2. Juni hat Apple an der WWDC14 ihre neue Funktionale Programmiersprache präsentiert. Apple’s neue Programmiersprache Swift scheint auf den ersten Blick nahezu ein F# Klon zu sein. Die Syntax von Swift sieht abgesehen von den { } zu verwechseln ähnlich aus wie F#. Wie kommt das? Aus sicherer Quelle ist zu erfahren, dass bei Apple ein ehemaliger Microsoft Mitarbeiter aus dem F# Team für Swift verantwortlich ist. Nun haben jetzt alle dieser drei verbreiteten Plattformen den Schritt in die Funktionale Zukunft gemacht.
  • Microsoft, .Net, Mono :   C#  ->  F#
  • Oracle, JEE / JVM :         Java  ->  Scala
  • Apple, Cocoa, iOS /OSX :   Objective-C  ->  Swift
Interessant ist auch das Erscheinungsdatum der Version 1.0 von wegen Ausgereiftheit und Bekanntheit. Ideal ist es, wenn die Programmiersprache mit sich selber implementiert ist (Bootstrapping, Rekursiver Kompiler, Selbst-Compiler) und der Quellcode offen verfügbar ist (Open Source), denn so hat man die Möglichkeit beim Erlernen der Sprache eine grosse Codebasis zu entdecken und zu studieren. Und man kann sicher sein, dass die Programmiersprache funktioniert, d.h. korrekt ist, denn der Compiler selbst ist ein nicht trivialer Test der kompletten Sprache. Bei F# ist beides gegeben, im Gegensatz zu Scala, das in Java implementiert ist und* Swift das wie bei Apple üblich wohl Closed Source bleiben wird. Mit Roslyn hat Microsoft genau dies für C# und VB.Net vor ein paar Monaten nachgeholt.
  • F# (2005) implementiert in F# (Open Source)
  • Scala (2003) implementiert in Java* Scala (Open Source) 1      2     3       
  • Swift (2014) implementiert in ? (Objective-C or Swift?) (Closed Source)
Den Schritt in die Funktionale Zukunft schon geplant? *) Korrektur: Dank an Soc88 (er hat Wikipedia Scala Eintrag korrigiert)