Open Source im professionellen Einsatz
Linux-Magazin 06/2014
© Denis Aglichev, 123RF

© Denis Aglichev, 123RF

Reactive Programming

Reaktionsfreudig

Im Juli 2013 veröffentlichte der Software-Unternehmer Jonas Bonér zusammen mit einigen Mitstreitern das Reactive Manifesto. Nur wenige Monate später war der Begriff schon in aller Programmierer Munde. Dabei ist das scheinbar neue Konzept schon weitaus älter.

1333

Den Begriff Reactive Programming sollen David Harel und Amir Pnueli bereits 1985 geprägt haben [1]. In ihrer wissenschaftlichen Arbeit ging es um den Entwurf von Systemen, die ständig auf Eingaben oder Änderungen reagieren müssen. Im Laufe der folgenden Jahre änderte sich die Bedeutung leicht. Heute gilt eine Anwendung allgemein als reactive, wenn sie möglichst schnell auf eingegebene oder geänderte Daten reagiert.

Besonders wünschenswert ist das bei interaktiven Programmen oder Webanwendungen, bei der Analyse von großen Datenmengen oder in der Robotik – also immer dann, wenn ein Programm in wenigen Millisekunden eine Antwort liefern muss, unter hohen (Netzwerk-)Lasten leidet oder große Datenmengen verarbeiten soll.

Da diese Anforderungen immer mehr Anwendungen betreffen, verwundert es wenig, dass sich immer mehr Projekte und wissenschaftliche Arbeiten mit Reactive Programming befassen. Besonders weit verbreitet ist eine ebenso simple wie interessante Grundidee: Man stellt kurzerhand die Daten in den Mittelpunkt.

Immer im Fluss

Wenn ein Entwickler etwas berechnen möchte, muss er in den meisten Programmiersprachen das Ergebnis in einer neuen Variablen auffangen. Ein einfaches Beispiel wäre:

a = b + 2

Das Ergebnis der Berechnung ist in diesem Fall eine Zahl. Sie bleibt in der Regel auch dann in »a« gespeichert, wenn sich der Inhalt von »b« im späteren Programmverlauf ändert.

Reactive Programming fordert hingegen, dass die Variablen »a« und »b« voneinander abhängen: Sobald sich »b« ändert, aktualisiert sich auch »a« automatisch. In der Variablen »a« liegt damit stets der Wert von »b + 2« , egal welchen Wert »b« gerade besitzt. Ein Programmierer braucht nicht mehr zu überlegen, an welchen Stellen im Programm er die Berechnung erneut durchführen muss oder wo sich zuvor »b« geändert haben könnte. Dies reduziert nicht nur Fehlerquellen, im Idealfall reagiert die Anwendung auch flotter. Der Begriff Reactive lässt sich daher sowohl mit reaktionsfreudig als auch mit rückwirkend übersetzen.

Während sich Entwickler bei der herkömmlichen Programmierung auf den Kontrollfluss (also die Befehlsabfolge) konzentrieren, steht beim Reactive Programming meist der Datenfluss im Vordergrund.

Davon unabhängig bietet sich noch die parallele Verarbeitung an: Je mehr Prozessoren eine Anwendung einspannt, desto schneller kann sie ihre Berechnungen durchführen – so zumindest das Kalkül. Arbeiten die Komponenten einer Anwendung nebenläufig, lässt sie sich auch wesentlich einfacher in verteilten Systemen beziehungsweise in einer Cloud einsetzen.

Ebenfalls en vogue ist eine asynchrone Verarbeitung der Daten: Nachdem die Benutzeroberfläche die geänderten Daten an die Datenbank geschickt hat, wartet sie nicht erst auf eine Antwort, sondern steht sofort wieder für weitere Eingaben zur Verfügung.

Schnellsprecher

Auch wenn es beim Blick auf den Datenfluss nicht so aussieht: Reactive Programming funktioniert auch in bestehenden Sprachen. In der objektorientierten Programmierung kann man zum Beispiel mit dem Entwurfsmuster Observer Datenänderungen weiterreichen [2]. Diesen Weg geht etwa Microsoft mit seiner Bibliothek Rx, die Reactive Programming in der Dotnet-Welt nachrüsten soll (Abbildung 1, [3]). Eine Portierung auf Java trägt den Namen Rx Java und stammt von der Online-Videothek Netflix [4].

Abbildung 1: Das von Microsoft verwendete Kürzel Rx greifen auch andere Projekte auf.

Auch für die meisten anderen Sprachen existieren entsprechende Bibliotheken oder Erweiterungen. Für Ruby gibt es beispielsweise Frappuccino [5], während Sodium das Umsetzen von Reactive Programming unter Java, Haskell und C++ ermöglicht [6]. Sofern – wie bei Rx – ein objektorientiertes Paradigma zugrunde liegt, spricht man auch von Object Oriented Reactive Programming (OORP). Besonders verbreitet ist Reactive Programming aber bei funktionalen Sprachen, wo es Functional Reactive Programming (FRP) heißt.

Mittlerweile sind daneben Programmiersprachen entstanden, die ihre Erfinder von Anfang an auf Reactive Programming zugeschnitten haben. Hierzu zählt die recht junge funktionale Programmiersprache Elm, die das bewährte Javascript ersetzen möchte (siehe Abbildung 2 und den Kasten "Vernetzte Ulme"). Wer sich mit diesen bereits existierenden Lösungen beschäftigt, trifft auf einen Mix aus unterschiedlichen Begriffen, Konzepten und Umsetzungen.

Abbildung 2: Die ganz dem Reactive Programming verschriebene Programmiersprache Elm eignet sich vor allem für interaktive Webanwendungen.

Vernetzte Ulme

Die funktionale Programmiersprache Elm (Ulme) gehört zu den wenigen Sprachen, die ihre Erfinder von vornherein für Reactive Programming ausgelegt haben. Elm ist auf die Programmierung von Webanwendungen ausgerichtet, der zugehörige Compiler erzeugt HTML, CSS und Javascript [11]. Erfunden hat sie Evan Czaplicki im Rahmen seiner Abschlussarbeit an der Universität Harvard im Jahre 2011.

Elm bietet keine Variablen im herkömmlichen Sinn. Neben Konstanten wie

a = 2 + 4

gibt es noch so genannte Signale. Diese verhalten sich wie Variablen, die jedoch plötzlich ihren Wert ändern können. Ein Paradebeispiel dafür ist das Signal »Mouse.position« , das immer die aktuellen Koordinaten des Mauszeigers enthält. Bindet der Programmierer »Maus.position« in eine Berechnung ein, dann aktualisiert Elm nach einer Mausbewegung automatisch das Ergebnis.

Dieses Verhalten lässt sich gut veranschaulichen, indem man die Mausposition auf dem Bildschirm ausgibt. Der dazu notwendige Quellcode umfasst gerade mal zwei Zeilen:

import Mouse
main = lift asText Mouse.position

»import« holt die Bibliothek mit Maus-Funktionen und Signalen hinzu. Anschließend steckt die Funktion »lift« die aktuellen Mauskoordinaten aus »Mouse.position« in die Funktion »asText« . Diese wiederum übersetzt den Zahlenwert in einen Text. Dieser Text wandert in die spezielle Konstante »main« , deren Inhalt später auf dem Bildschirm erscheint. Die Funktion »lift« ist notwendig, um eine normale Funktion auf das Signal anzuwenden. Elm bezeichnet diesen Vorgang als Lifting.

Das Ergebnis ist wieder ein Signal. »lift« selbst geht dabei davon aus, dass die Funktion (hier »asText« ) nur einen Parameter erwartet. Sollte die Funktion zwei Parameter benötigen, greift der Programmierer zu »lift2« , bei drei Parametern zu »lift3« und so weiter.

Ausprobieren kann man den Code direkt im Browser: Der Entwickler von Elm stellt auf seiner Homepage eine kleine Entwicklungsumgebung bereit [12]. Auf der linken Seite tippt man den Code ein, rechts erscheint nach einem Klick auf »Compile« (am unteren linken Fensterrand) umgehend das Ergebnis – oder eine Fehlermeldung.

Abgesehen vom Lifting erinnert Elm ein klein wenig an Haskell oder Coffeescript. Dank der mitgelieferten Bibliotheken lassen sich schnell Clientanwendungen im Browser umsetzen, die Signale prädestinieren Elm geradezu für den Bau interaktiver Benutzeroberflächen.

Im Gegensatz zu vielen anderen funktionalen Programmiersprachen ist der Wechsel von imperativen Sprachen recht einfach. Einen schnellen und leicht verständlichen Einstieg bietet die Onlinedokumentation [13]. Was mit Elm alles möglich ist, zeigt die Beispielsammlung [14]. Das Diagramm aus Abbildung 3 etwa lässt sich mit der Maus in Echtzeit verändern, ein komplettes Pong-Spiel benötigt gerade mal 100 Zeilen Code [15]. Allerdings gibt es derzeit noch keine ernsthafte Praxisanwendung, die in Elm implementiert wäre.

Abbildung 3: Elm im Browser: Bewegt bei diesem Beispiel der Anwender die Maus, verändern sich die Verhältnisse der Teilstücke in Echtzeit.

Genau das möchten Jonas Bonér und seine Co-Autoren mit ihrem "Reactive Manifesto" ändern ([7], [8]). Es definiert einheitliche Begriffe, die nicht nur die Zusammenarbeit unter den Entwickler-Communities verbessern, sondern es auch den Anwendern und Herstellern erleichtern sollen, miteinander zu reden und einander besser zu verstehen.

Dabei handelt Jonas Bonér nicht ganz ohne Eigennutz: Wie viele seiner Mitstreiter arbeitet er für die von ihm mitgegründete Firma Typesafe, die an einer Plattform für reaktive Programme bastelt (Abbildung 4, [9]). Dazu gehören die Programmiersprache Scala, die Laufzeitumgebung Akka, ein Framework namens Play und mit Activator ein Reactive Development Environment.

Abbildung 4: Die Firma Typesafe setzt vollständig auf die Software-Erstellung mit Reactive Programming und bietet dazu unter anderem Schulungen an.

Gemäß Manifest gilt eine Anwendung als reaktiv, wenn sie umgehend auf einen Stimulus reagieren kann. Dazu muss sie wiederum ereignisgesteuert (Event-driven), skalierbar (scalable), robust (resilient) und jederzeit ansprechbar (responsive) sein. Diese vier Eigenschaften gelten zwingend für alle Bestandteile des Softwaresystems. So müssen etwa bei einer Webanwendung neben dem Client im Browser auch die Serverkomponenten schnell reagieren, andernfalls geriete das komplette System ins Stocken.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 5 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Polish Perl Workshop 2014

    Am Wochenende des 17. und 18. Mai findet in Posen der Polish Perl Workshop 2014 bei freiem Eintritt statt.

  • KDE beschreibt sich selbst und veröffentlicht sein Manifest

    Das KDE-Manifest soll nicht die Arbeitsweise der KDE-Entwickler und des e.V. verändern, schreibt das Projekt in einer Pressemitteilung. Vielmehr wollen die Initiatoren in wenigen Worten definieren, was das freie Desktop-Projekt ausmacht, "wie sich die KDE-Community selbst sieht".

  • Oettinger begrüßt Telco-Manifest gegen Netzneutralität

    Der deutsche EU-Kommissar für Digitale Wirtschaft und Gesellschaft Günther Oettinger hat das  “5G Manifesto for timely deployment of 5G in Europe" der europäischen Telekomindustrie begrüßt, das sich unter anderem gegen Netzneutralität wendet.

  • Meteor

    Javascript sowohl im Browser als auch auf dem Server: Das Webframework Meteor verspricht Anwendungen aus einem Guss, die sich dank vieler fertiger Pakete rasch programmieren lassen.

  • Bewerbungen für Mozilla Open Source Support Program starten

    Mit dem Open Source Support Program hat Mozilla sich vorgenommen, Projekte und Technologien finanziell zu unterstützen. Nun beginnt die zweite Bewerbungsphase.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.