© iStockphoto.com/P2007 © S&S Media
Kolumne: Olis bunte Welt der IT

Rückblick: Immutable Data damals und heute


Im Februar 2009 war es soweit: Bei der BASTA! Spring vor 12 Jahren hielt ich zum ersten Mal einen Vortrag zum Thema unveränderbare Daten in C#. Damals hatte ich bereits seit mehreren Jahren immer wieder zu Themen der funktionalen Programmierung in C# vorgetragen, und ich war dabei, an meinem Buch „Funktionale Programmierung in C#“ zu arbeiten. In diesem Buch ging es allgemein darum, eine möglichst einfache Syntax für die Verwendung funktionaler Ideen in C# zu finden. Auch damals arbeitete ich bereits mit F#, wo viele funktionale Ideen sehr einfach umzusetzen waren. Allerdings waren viele Teams leider nicht gern bereit, F# in echten Projekten einzusetzen. Wenn also dennoch „ein bisschen“ funktional gearbeitet werden sollte, musste das in C# möglich sein.

Unveränderbare Daten – englisch: Immutable Data – waren ein Thema, zu dem ich detaillierte Recherche betrieb. Mittlerweile hat sich die Idee auch im Mainstream der Programmierung etwas mehr durchgesetzt, sodass heute sicher viele C#-Programmierer mit der Grundidee vertraut sind. Prinzipiell ist die ganz einfach: Wer vermeidet, Werte während der Programmausführung „in place“ zu modifizieren, spart sich viel Ärger. Das ist eigentlich gar keine verblüffende Erkenntnis, denn wir haben doch schon lange aus demselben Grund möglichst auf globale Variablen verzichtet! Wenn Werte global abgelegt werden, sind sie von unterschiedlichen Codeteilen aus änderbar, und wenn sich nach einiger Zeit der Programmausführung ein eventuell fehlerhafter Wert in einer solchen Variablen wiederfindet, weiß man oft nicht, wie es dazu gekommen ist. Daher führte man das Paradigma „bitte keine globalen Variablen verwenden“ ein, vergaß aber gleichzeitig das wichtige Addendum „übrigens kann man dasselbe Problem auch bei Instanzvariablen in Klassen beobachten, sofern diese von mehr als einer Methode aus geändert werden“.

Funktionale Ideen für einfache Parallelisierbarkeit

Ein wichtiger Aufhänger im Jahre 2009 war die Parallelisierung, die sich in der Alltagsprogrammierung – hauptsächlich wegen der steigenden Anzahl von Kernen in Desktopprozessoren – immer weiter durchsetzte. Zum Zwecke der Parallelisierung wollten plötzlich viel mehr Programmierer Code schreiben, der möglichst funktionalen Ideen gehorchte. Manche dieser Programmierer wussten es natürlich damals nicht, aber das Konzept der „puren Funktion“, die ohne Schreibzugriff außerhalb ihres eigenen Bereichs ihre Arbeit erledigt, stammt aus der funktionalen Programmierung und eignet sich gerade wegen dieser Vermeidung der sogenannten Nebeneffekte hervorragend dazu, parallel in vielen unabhängigen Instanzen zu laufen. Eigentlich hätte man das auch im Microsoft-Umfeld schon viel eher merken können, wenn man sich das Web zum Vorbild genommen hätte; dort arbeitet HTTP als zustandsloses Protokoll schon immer auf dieser Basis. Aber Microsoft verfolgte in den Anfangstagen von .NET mit ASP.NET Web Forms noch den Plan, HTTP ad absurdum zu führen, und entschied sich erst nach der Einführung der Windows Communication Foundation (WCF) und dem Hype der Service-Orientierten-Architekturkonzepte (SOA) langsam für andere Wege. So arbeiteten viele .NET-Programmierer noch recht lange mit zustandsbasierten imperativen Ansätzen.

Unveränderbare Daten hängen ebenfalls mit der funktionalen Programmierung zusammen. Tatsächlich gibt es nicht wenige funktionale Sprachen, in denen Variablen im eigentlichen Sinne gar nicht existieren. Dort gibt es benannte Werte, oft Values genannt, die beim Lesen des Codes leicht mit Variablen verwechselt werden können. Allerdings sind sie nicht variabel, ändern also niemals ihren Wert, nachdem sie einmal initialisier...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang