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