Functional Programming in F# für .NET – Kursinhalte

Die Kurs Inhalte können variieren, je nach Wissensstand, Zeitrahmen und Trainingsschwerpunkten.
Es wird Wert gelegt auf die Grundlagen und dass man das Gelernte sofort anwenden kann.

Sofort Produktiv

  • einfache und mächtige F# Syntax, wenig Code, einfaches Refactoring
  • Code ausführen während man ihn schreibt
  • effiziente und gut verständliche Datenmodellierung (Domain Driven Design (DDD)) mit Algebraischen Daten Typen die automatisch Strukturellen Vergleich und Hashing bieten.
  • Masseinheiten werden vom Compiler bei Übergabe und Berechnungen auf Korrektheit geprüft (Meter, Kilogramm, Sekunde, Pixel, Dollar, SelbstDefiniert, etc.)
  • mit F# Type Providern Ihre Daten automatisch typisiert im Code mit IntelliSense anwenden. Type Provider sind ein einzigartiges Feature von F# (seit 2010, ich konnte es kaum glauben als ich es das erste mal 2010 gesehen habe, It’s magic!), das keine andere Programmiersprache bisher ermöglicht (mit Ausnahme von IDRIS seit März 2015).
  • Erstellen von eigenen Domain Specific Languages (DSL)
  • F# ist in Visual Studio (seit 2010) schon enthalten
  • Kompatibilität, .dll’s können von C#, VB.NET und umgekehrt verwendet werden.

Wichtige Grundlagen der Funktionalen Programmierung (FP)

  • Immutability: verstehen warum Immutability gut ist und hilft Probleme einfacher zu lösen und Code besser zu verstehen. Immutable Daten Strukturen
  • Type Inference : verstehen und Nutzen erkennen
  • Partial Application und Curring
  • Rekursion: rekursive Funktionen und rekursive Datentypen
  • Higher Order Functions : map, reduce, filter, etc.
  • Pattern Matching
  • Referential Transparency
  • Lazyness: Seq, lazy
  • Memoziation
  • Algebraischen Daten Typen (ADT) (sind keine POCOs (Plain-Old CLR Objects))

Wesentliche Unterschiede von F# zu C#

  • null als ungültiger Wert (nicht als gültiger default Wert von Referenz Typen in C#)
  • unit als leerer Wert (nicht void als kein Wert wie in C#, denn void und async vertragen sich nicht gut in C#)
  • async als Library (nicht als async und await Sprachkonstrukte wie in C#)
  • lock als Funktion (nicht als Statement wie in C#)
  • choice für Exception Handling (Exception free programming)

Automatisiertes Testen

  • interaktives Testen im REPL
  • automatisches Erzeugen von Testdaten und Ermittlung des kleinsten Datensatzes, der die Fehler-Analyse vereinfacht mit FsCheck
  • Testen von Webseiten mit Canopy (Automatisiertes Surfen)

Parallel Programming und Asynchronous Programming (Concurrent Programming)

  • Parallelen Code schreiben, dem man trauen kann (immer richtiges Ergebnis)
  • Async Code composition
  • Actors (F# MailboxProcessor)

Web Programmierung (wird im Grundkurs nur gestreift)

  • F# Code zu JavaScript compilieren (mit FunScript oder WebSharper)
  • Client- und Server-Code in F# schreiben (Code Reuse) und automatisch zu .NET für Server und JavaScript für Client compilieren (mit WebSharper)
  • IntelliSense in F# für JavaScript Library Funktionen dank automatischer TypeScript Definitions File Auswertung.


Zu F# Inhouse Schulungskurse

Zuverlässige Software durch weniger bewegliche Teile

Jedes mechanische System wird einfacher und wartungsfreundlicher, je weniger bewegliche Teile es hat. Die Einfachheit macht es auch langlebiger und weniger Störungsanfällig.

In der Softwareentwicklung findet man auch “bewegliche Teile”, so werden Variablen definiert in C#, C++

1: 
int myVariable = 0; 

in F# mit mutable

1: 
let mutable myVariable = 0

Jetzt könnte man denken, das ist ja furchtbar, immer noch dieses mutable hinzuschreiben. Und genauso ist es, denn der Standart (default) ist ohne mutable

1: 
let myValue = 0

Das hat seine Bedeutung, es ist sicher aufgefallen dass im Beispiel die Benennung von Variable auf Value gewechselt hat. Der Grund ist, in F# gibt es Standart mässig nur Values. Will man Veränderliche, so ist man gezwungen mutable hinzuschreiben. Also die beweglichen Teile zu markieren, so wird mutable auch als Code-Smell, als nicht so fein duftender Code bezeichnet.

Unveränderlich (Immutable)

Was hat es nun mit den Values auf sich?

Values sind einmal zugewiesen nicht wieder veränderbar. In C++ und C# ist es genau umgekehrt, man kann variablen mit const markieren. Das wird kaum angewandt, weil zu aufwendig oder nur dann wenn z.B. Mathematische oder Physikalische Konstanten definiert werden.

Ein F# Value ist konstant.

Ja aber bitte, wie soll man nur mit Konstanten programmieren können? Die Frage ist gut, die Antwort wird sie überraschen.

Angenommen sie wollen in eine string (.Net) myString = “aBc” das B durch ein kleines b ersetzen, wie machen sie das?

Nein, nicht so

1: 
myString[1] = 'b'

Sie könnten

1: 
myString.ToLower()

verwenden, was erhält man?

Ist nun myString = "abc" ?

Nein, man erhält einen neuen string “abc” als Rückgabewert von der Funktion ToLower().

Ah ja klar.

Es fällt auf, dass die string Instanz eigentlich eher ein Value ist, als eine Variable, also der string immutable ist, das Gegenteil von mutable.

Values sind immer zugewiesen, es gibt keine nicht initialisierten Values in F#.

Initialisierte Values (keine null Referenzen)

Es mag in C#/C++ nicht initialisierte Variablen oder Objekte geben.

1: 
2: 
object myObject;        // war früher in C/C++ nicht unbedingt null
object myObject = null; 

Bedeutet null nun, nicht initialisiert oder nicht zugewiesen oder nicht vorhanden oder kein Ergebnis oder Fehler ?

1: 
return null;

Da müssten jetzt die Alarmglocken losgehen, oder wie ist das denn genau in den von Ihnen angewandten Codierrichtlinien definiert?

Wie oft kommt dies im Code vor?

null

1: 
2: 
3: 
if x == null    // C++/C#
if x != null    // C++/C#
if x <> null    // VB

Nothing

1: 
2: 
If x Is Nothing Then // VB.NET
If IsNothing(x) Then // VB.NET

Nullable

Die Möglichkeit einen nicht-Referenz Type wie z.B. int auch null setzen zu können.

1: 
2: 
3: 
4: 
System.Nullable<int> x = 4;
int? x = 4;

int? a = null;

Der F# Option type ersetzt die null und das Nullable auf einsichtigere Weise mit static typing.

Die Bedeutungen von null und deren negative Konsequenzen

Meint null nun, nicht initialisiert oder nicht gültig?

Die Frage an C# Entwickler, Antwort oft: Beides!

In F# ist alles IMMER initialisiert, eine Option.None (ähnlich null) sagt, dass es keinen (gültigen) Wert hat.

Der Option Type als Rückgabe Parameter einer Funktion besagt, dass die Funktion auch None liefern kann. Somit bei static typing immer geprüft wird UND in Interfaces ist klar was optional ist!

Ob eine C# Methode null liefert oder nicht weiss man nicht explizit.

Also sollte man bei Verdacht immer prüfen? Um sogenanntes FailSafe Verhalten zu erzeugen?

Schön dass String in .Net ein immutable Type ist, aber leider leider kann er auch null sein. Dazu gibt es dann so nette Funktions Klassiker wie String.IsNullOrEmpty()

1: 
result = s == null || s == String.Empty; // String.IsNullOrEmpty()

All dies ist in F# nur dann ein Problem, bei Interop mit C# oder VB. Sonst ist die Welt in Ordnung.

Wie oft geht dies vergessen und führt so zu Fehlverhalten in der Software (Null-Refernece Exception)?

Was dazu führen kann (Fail-Save Programming), dass auch zuviele und unnötige null Tests gemacht werden und der Code fast ausschliesslich daraus besteht und ein Reviewer die Logik des Codes über weite Flächen erkunden muss.

In F# kann man darauf verzichten. Der Code ist Spezifikation und enthält nur das Wesentliche.

Das Problem ist ja, dass man nicht wissen kann, ob an dieser und jener Stelle eine null Prüfung gemacht werden muss oder nicht. Da kann man Code Annotations machen und externe Tools bemühen, die Code Dokumentation aufblähen, nur weil es keine Konvention oder Interface hat.

Der Option Type in F# stellt so ein Interface zu Verfügung. Das Interface kann der Compiler überprüfen. Man erkennt ob eine Funktion eine Option als Parameter verwendet und ob eine Option zurückgegeben wird. Es ist alles klar definiert. Keine Annahmen, die je nach Projekt oder Software Team in einer Konvention definiert wurde, z.B. in den Codierrichtlinien.

Dies ist nichts weiter als die Behandlung von Symtomen, anstatt die Ursache, die Null-Referenz zu bekämpfen. In F# ist keine null nötig und der F# Compiler kennt die “Codierrichtlinien” und prüft ob die Option korrekt ausgewertet wird.

So jetzt vergessen wir all diese Bauchschmerzen.

In F# gibt es nur initialisierte Values.

Somit braucht man die null nicht.

Und dies erübrigt auch die null Abfragen*.

So einfach und so praktisch!

*) Dies wohlbemerkt innerhalb der F# Welt. Bei Anwendung und Interfacing von nicht F# Modulen, muss man leider aus Sicherheitsgründen alles was rein kommt überprüfen.

Also dies ist nur ein Teil der wegfallenden beweglichen-Null-Teile, die nicht nur das Denken des Entwicklers vereinfacht auch der Code und somit die Software selbst.

Man kann es als Evolution der Programmiersprachen sehen

1: 
2: 
3: 
4: 
5: 
6: 
1965    Algol   null Referenz                                           Tony Hoare gilt als Erfinder der null Referenz
1972    C       Pointer (null)                                          Speicher Verwaltung mit malloc
1985    C++     nicht Initialisierte Objekte (null), Pointer (null)     Speicher Verwaltung mit malloc
2001    C#      nicht Initialisierte Objekte (null)                     Garbage-Collector verwaltet den Speicher
2002  VB.Net    nicht Initialisierte Objekte (null)                     Garbage-Collector verwaltet den Speicher
2002    F#      initialisierte Values, Static Typing                    Garbage-Collector verwaltet den Speicher

Ja F# gibt es seit 2002. Warum F# gut ein Jahrzehnt später populär wird liegt wohl daran, dass Microsoft F# erstmals in Visual Studio 2010 mit auslieferte, zuvor musste man es separat installieren, um es im Visual-Studio zu nutzen.

Static Typing

1: 
2: 
3: 
4: 
5: 
Dim Text As String  = "Hello world"     // VB
CString Text        = "Hello world";    // C++
String Text         = "Hello world";    // C#
var Text            = "Hello world";    // C#3 - Inferred type: String
let Text            = "Hello world"     // F#  - Inferred type: String  

Dass Text ein String sein muss, erkennt das F# Type-System automatisch ohne zu kompilieren! Der Tooltip unterm Mauszeiger zeigt den type. Dies verkürzt den Code, vorallem bei Funktions Deklerationen. Da werden von allen Parametern die Typen automatisch erkannt. Es ist also viel mächtiger als das C# var Konstrukt.

Dies vereinfacht das Code Refactoring, man muss die Type Spezifikation nicht “rumschleppen” und benötigt folge dessen kein extra Tool dazu (das auch noch auf die Compiler Version abgestimmt sein muss), weil es der Compiler selbst ist. Und es ist, dem Anschein zu Trotz, weil da ja keine Typen mehr stehen, strikt Type-Safe.

Die Vorteile von immutable sind

  • thread safety guarantee
  • besser testbar
Multiple items
val int : value:'T -> int (requires member op_Explicit)

Full name: Microsoft.FSharp.Core.Operators.int

——————–
type int = int32

Full name: Microsoft.FSharp.Core.int

——————–
type int<'Measure> = int

Full name: Microsoft.FSharp.Core.int<_>
val mutable myVariable : int

Full name: ZuverlässigeSoftwaredurchwenigerbeweglicheTeile.myVariable
val myValue : int

Full name: ZuverlässigeSoftwaredurchwenigerbeweglicheTeile.myValue
namespace System
Multiple items
type Nullable =
  static member Compare<'T> : n1:Nullable<'T> * n2:Nullable<'T> -> int
  static member Equals<'T> : n1:Nullable<'T> * n2:Nullable<'T> -> bool
  static member GetUnderlyingType : nullableType:Type -> Type

Full name: System.Nullable

——————–
type Nullable<'T (requires default constructor and value type and 'T :> ValueType)> =
  struct
    new : value:'T -> Nullable<'T>
    member Equals : other:obj -> bool
    member GetHashCode : unit -> int
    member GetValueOrDefault : unit -> 'T + 1 overload
    member HasValue : bool
    member ToString : unit -> string
    member Value : 'T
  end

Full name: System.Nullable<_>

——————–
System.Nullable()
System.Nullable(value: 'T) : unit
module String

from Microsoft.FSharp.Core
val Text : string

Full name: ZuverlässigeSoftwaredurchwenigerbeweglicheTeile.Text