http://fora.tv/2008/11/19/Erlang_Concurrency_Whats_the_Fuss

Nachdem der ganze Wahnsinn in Sachen immer-schnellere-CPUs-jedes-Jahr an physikalischen Grenzen scheiterte, werden neue (bzw. seit langem bekannte, aber nicht beachtete) Wege beschritten. Joe Armstrong hat in seinem Vortrag bei der Erlang Exchange 2008 über skalierbare Software, Concurrency und Fehlertoleranz gesprochen. Die Slides findet man hier.

Bei der Erlang Exchange 2008 Konferenz wurde das vom Zuse Institut Berlin und onScale Solutions GmbH entwickelte data-store System vorgestellt. Im Vortrag kommen so wichtige Themen wie Distributed Hashtables (DHTs), transaction layer und schnelle application layer für tausendfache Lese-/Schreibzugriffe vor. Weitere Podcasts zum Thema Erlang, fehlertolerante Systeme und Concurrency kann man hier abrufen. Der originale Link zum obigen Podcast ist hier zu finden und die Slides hier.

Slides befinden sich hier, sowie als gezipptes File hier. Da im Video nicht immer alle Slides eingeblendet werden, ist es zu empfehlen, parallel zu diesem die Slides zu halten, sonst ist es recht schwierig, dem (ausgezeichneten!) Vortrag zu folgen.

Als Erstes benötigen wir Emacs, welcher für verschiedene Betriebssysteme bereits vorkompiliert im Netz gefunden werden kann. Ich bevorzuge EmacsW32, wenn ich unter Windows entwickle, aber dies sich ja nur eine Geschmackssache. Auf jeden Fall wird Emacs benötigt.

Danach holen wir uns mit Subversion die Distel-Sourcen:
svn checkout http://distel.googlecode.com/svn/trunk/ distel

Diese Sourcen werden mit “make” kompiliert. Unter Unix/Linux geht dies recht einfach, für Windows muss zuerst die passende POSIX-Umgebung geschaffen werden. Mit Cygwin geht dies am besten und einfachsten. Für alle, die wenig Lust auf Cygwin und die ganzen Compile-Vorgänge haben, gibt es ein Zip-Paket zum Download, welches die ganze Distel-Verzeichnisstruktur beinhaltet (mit bereits kompilierten Dateien). Meine Erlang-Version zum Zeitpunkt der Kompilierung war 5.6.5.

Nachdem Distel-Sourcen übersetzt bzw. heruntergeladen worden sind, sollen diese im Verzeichnis ERLANG_HOME\lib\distel abgelegt werden.

Am Ende solltet ihr eine solche Struktur haben:

Jetzt müssen wir der Erlang-Umgebung einen Pfad mehr verpassen, damit die Distel-Binaries verfügbar sind. Im Verzeichnis ERLANG_HOME\usr wird eine Datei namens .erlang (Punkt nicht vergessen!) angelegt, sofern sie nicht bereits vorhanden ist. Diese erweitert man um folgenden Eintrag

code:add_pathz(“ERLANG_HOME/lib/distel/ebin”).

Jezt passen wir Emacs an und erstellen, sofern nicht vorhanden, eine Datei namens .emacs in eurem Benutzer-Homeverzeichnis. Wenn man sich nicht sicher ist, wie das Homeverzeichnis heißt, einfach auf der Kommandozeile Folgendes eingeben: echo %HOME%

Bei Unix/Linux-Usern schaut das Ganze ein bisserl anders aus.

Dort hilft ein “env” auf der Konsole bzw. echo $HOME.

Im Home-Verzeichnis wird die zuvor erwähnte Datei um folgende Einträge erweitert:

;; Erlang Paths
(setq load-path (cons  “ERLANG_HOME/lib/tools-2.6.2/emacs” load-path))
(setq erlang-root-dir “ERLANG_HOME“)
(setq exec-path (cons “ERLANG_HOME/bin” exec-path))
(require ‘erlang-start)

;; This is needed for Distel setup
(let ((distel-dir “ERLANG_HOME/lib/distel/elisp”))
(unless (member distel-dir load-path)
;; Add distel-dir to the end of load-path
(setq load-path (append load-path (list distel-dir)))))
(require ‘distel)
(distel-setup)

;; Some Erlang customizations
(add-hook ‘erlang-mode-hook
(lambda ()
;; when starting an Erlang shell in Emacs, default in the node name
(setq inferior-erlang-machine-options ‘(“-sname” “emacs”))
;; add Erlang functions to an imenu menu
(imenu-add-to-menubar “imenu”)))

;; A number of the erlang-extended-mode key bindings are useful in the shell too
(defconst distel-shell-keys
‘((“\C-\M-i”   erl-complete)
(“\M-?”      erl-complete)
(“\M-.”      erl-find-source-under-point)
(“\M-,”      erl-find-source-unwind)
(“\M-*”      erl-find-source-unwind))
;; Additional keys to bind when in Erlang shell.”)
(add-hook ‘erlang-shell-mode-hook
(lambda ()
;; add some Distel bindings to the Erlang shell
(dolist (spec distel-shell-keys)
(define-key erlang-shell-mode-map (car spec) (cadr spec)))))

Ein Beispiel für ERLANG_HOME wäre C:/Programme/erl5.6.5

Und auch für diesen Schritt habe ich ein entsprechendes Download vorbereitet, falls man doch wenig Lust hat, sich in die Emacs-Lisp-Syntax einzuarbeiten.

Jedoch sollten die Pfade angepasst werden und auch muss man daraus achten, dass die eventuell vorhandenen Leerzeilen in Windows Pfaden umgangen werden.

Jetzt können wir Emacs starten und sich mit dem neue Erlang-Modus vertraut machen. Um diesen zu aktivieren, muss eine *.erl-Datei geladen werden.

Daneben ist noch ein weiteres Menü namens imenu vorhanden, welches vor allem bei umfangreichen Quellcodes recht nützlich ist, da es sämtliche Funktionen auflistet, die aktuell vorhanden sind. Diese kann man dann direkt ansteuern. Um eine Erlang-Shell zu starten, wählt man den Menüpunkt Shell/Start New Shell aus.

Als Ergebnis erhält man automatisch eine neue Shell innerhalb der Emacs-Umgebung.

In dieser kann man z.B. die über Emacs kompilierten Erlang-Quellcodes starten. Würden wir den angezeigten Code kompilieren wollen, so wäre die Vorgehensweise wie folgt:

Übrigens: das Wechseln zwischen verschiedenen “Buffers”, denn auch eine Erlang-Shell in Emacs ist “nur” ein weiterer Buffer, geschieht über den Menüpunkt “Buffers”. Dort wählt man einfach den gewünschten Buffer aus (hier den Quellcode) und anschließend startet man das Kompilieren desselben über Erlang/Compile/Compile Buffer. Wenn alles ordentlich verlaufen ist, erhält man folgendes Ergebnis:

Es wird also die zuvor geöffnete Shell benutzt, um den Quellcode zu kompilieren. Hätten wir keine Shell zuvor aufgemacht, so würde Emacs automatisch eine entsprechende starten. Jetzt können wir auch direkt in derselben Shell das Kompilat starten:

Dies wäre ein typischer Vorgang beim Entwickeln unter Emacs/Distel. Zuerst den Code im Buffer eingeben (oder Teile davon) und dann schrittweise testen. Ferner bietet Distel auch die Möglichkeit an, bestimmte Code-Skeletons automatisch einzufügen. Hier ein Beispiel mit einem einfachen Server-Skeleton:

Ein weiteres, äußerst nützliches Feature von Distel ist die Debugging-Funktionalität. Um diese zu nützen benötigt man neben einem geladenen Quellcode auch eine laufende Erlang-Shell. Sind diese vorhanden, wird aus dem Quellcode-Buffer (dieser muss über Buffer-Menü gewählt werden!)  eine Connection zur bereits gestarteten Shell aufgebaut. Dazu bedient man sich des folgenden Menüpunktes:

Es ist natürlich auch möglich, all diese Optionen direkt über Tasktenkombinationen auszuwählen.

Direkt nachdem wir die Option aktiviert haben, werden wir nach dem Namen des Erlang-Nodes gefragt, welcher in der unten eingeblendeten Zeile eingegeben werden muss. Der Node-Name setzt sich immer aus Node-Name@Maschinen-Name zusammen. Am einfachsten ist es, sich über das Buffer-Menü zu vergewissern wie der Node heißt. Und falls wir mehrere haben, wählt man einen aus.

Nachdem der Node konnektiert wurde, muss natürlich der Quellcode kompiliert werden, damit das Debugging auch einen Sinn macht. Jedoch werden wir diesmal nicht den Menüpunk Erlang/Compile/Compile Buffer wählen, sondern direkt über die Erlang-Shell kompilieren. Dies hat damit zu tun, dass wir für das Debugging zusätzliche Informationen in unserem Kompilat bereitstellen müssen (sog. Debug-Infos). Deswegen brauchen wird einen leicht erweiterten Kommandoaufruf in der Zeile. Wir wählen also die Erlang-Shell und geben Folgendes ein (“func1″ wird natürlich nicht immer vorkommen müssen, sondern der Name eurer *.erl-Datei):

Danach müss das fertig kompilierte Modul neu geladen werden. Dies erfolgt über folgenden Menüpunkt:

Und auch hier muss der Name des Moduls in unten eingeblendeter Zeile eingegeben werden. Standardmäßig wird das aktuell kompilierte Modul vorgeschlagen, sodass man diesen nur noch bestätigen muss. Ist alles erfolgreich verlaufen, wird in der Zeile folgende Nachricht angezeigt (mit entsprechendem Modulnamen):

Jetzt aktivieren wir das Debugging:

Ist alles gut verlaufen, meldet sich Emacs mit folgender Meldung zurück:

Danach können wir in unserem Quellcode z.B. einen Breakpoint setzen, welcher dann zur Laufzeit die Abarbeitung anhalten wird. Dazu setzen wird den Cursor an die gewünschte Position und wählen diesen Menüpunkt aus:

Automatisch wird die ausgesuchte Zeile rot markiert. Will man den Breakpoint entfernen, muss nur derselbe Menüpunkt gewählt werden (oder, wie immer, die passende Tastenkombination eingegeben werden).

Jetzt rufen wir die markierte Funktion in der Erlang-Shell auf. Direkt nachdem sie gestartet wurde, wird ein neuer Debug-Buffer aktiviert, in welchem die Infos zu unserem Breakpoint und seiner momentanen Ausführung aufgelistet sind.

Man sieht unten, dass noch kein Ergebnis der Funktion double(12) zurückgegeben worden ist. Dies ist ein Zeichen, dass die weitere Ausführung ab jetzt auch schrittweise erfolgen kann. Um den angezeiten Prozess manuell zu debuggen, positioniert man den Cursor auf die gewünschte Zeile (in diesemFalle ist es nur eine, was aber nicht immer sein muss). Dann drück man einmal auf ENTER und automatisch wechselt Emacs zum Quellcode genau an die Stelle wo das Debugging markiert wurde. Man erkennt es auch am grünen Pfeil direkt neben der Quellcode-Zeile. In der unteren Fensterhälfte sieht man den momentanen Status der eingesetzten Variablen (in diesem Falle ist X = 12, was unserer Eingabe beim Funktionsaufruf entspricht).

Jetzt hat man die Wahl zwischen diesen Optionen, welche über die Tastatur eingegeben werden:

• h: Anzeige verfügbarer Kommandos.
• q: Debug-Anzeige beenden (der gedebuggte Prozess wird aber nicht geschlossen)
• SPC: Nächster Schritt.
• n: Über den Ausdruck hinausgehen.
• u: Nach oben zum nächsten Stack-Frame.
• d: Nach unten zum nächsten Stack-Frame.
• c: Fortsetzen bis zum (eventuell) nächsten Breakpoint.
• b: Breakpoint auf der aktuellen Zeile setzen/entfernen.

Man sieht, dass eine schnelle und komfortable Entwicklung auch mit Erlang möglich ist.

Viel Spaß mit Erlang, Emacs & Distel!

Mehr Infos gibt es hier, hier und hier. Eine Google-Group ist ebenfalls vorhanden.

In diesem Interview geht es vor allem um die aktuellen IT-Probleme wie Concurrency/Parallelism und die Vorteile der funktionalen Programmierung beim Lösen derselben.

Da mittlerweile auch die günstigsten Notebooks über einen Dual-Core-Prozessor verfügen, ist es nur eine Frage der Zeit, bis Concurrency denselben Stellenwert einnimmt wie zuvor die GHz-Zahl oder die RAM-Größe.

Da es schon seit geraumer Zeit keine “doppelt-so-schnell-wie-letztes-Jahr” CPUs mehr gibt, geht der Trend in Richtung mehr Kerne pro CPU, was wiederum neue Software auf den Plan ruft, die solche technischen Möglichkeiten ausreizen kann. Bisher hat man wohl zu 99% nur für single CPUs programmiert und auch nur solche Sprachen gelernt. Früher oder später wird man “dazulernen” müssen, wenn man es nicht schon seit LISP, Smalltalk und ADA kennt. Oder zumindest ein bisschen Haskell spricht.

In this interview filmed during QCon London 2008, Joe Armstrong, designer of Erlang, speaks on various aspects of the Erlang language, presenting its roots, how it compares with other languages and why it has become popular these days due to its native ability to scale on multi core systems.

Joe Armstrong is the principle inventor of Erlang and coined the term “Concurrency Oriented Programming”. At Ericsson he developed Erlang and was chief architect of the Erlang/OTP system. In 1998 he formed Bluetail, which developed all its products in Erlang. In 2003 he obtain his PhD from the Royal Institute of Technology, Stockholm. He is author of the book “Software for a concurrent world“.

Gegeben ist folgender Quellcode, welcher ein Programm zum Berechnen des Quadrats einer beliebigen Zahl bildet:

Das Programm besteht aus zwei Teilen, den Modulattributen und Funktionen.
Modulattribute sind in diesem Falle -module(func1) und -export([double/1]).

Modulattributen können sowohl vom Entwickler selbst definiert, wie auch aus einem Satz von Standardvorgaben eingesetzt werden.
Die Attribute -module und -export gehören zum Erlang-Standard, wobei -module zwingend ist, während -export nur dann eingesetzt werden sollte, wenn man bestimmte Funktionen für den Zugriff von Außen freigeben möchte. In diesem Falle ist es die Funktion double, die z.B. von der Erlang-Shell aus aufgerufen werden soll. Jede Erlang-Quelldatei muss eine Angabe über den aktuellen Modulnamen tragen und zwar innerhalb der Klammern des Attributen -module. Somit ist der Name der *.erl-Datei gleichzeitig auch der Name des Moduls. Nachdem dieses beispielsweise über den Aufruf c(MODULNAME). in der Shell kompiliert worden ist, wird eine neue Bytecode-Datei namens MODULNAME.beam angelegt. Und genau diese ist für die eigentliche Ausführung in der Erlang Virtual Machine gedacht. Dies ist mit Java *.class-Dateien vergleichbar, die aus gewöhnlichen *.java-Dateien gebildet werden, um dann in der JVM als Bytecode ausgeführt zu werden. Und wie bei sonstigen Erlang-Anweisungen auch, müssen diese beiden Attribute mit einem Punkt abgeschlossen werden.

Jedoch sollte noch geklärt werden, was die Angabe [double/1] zu bedeuten hat. Nun, da Funktionen mehrere Argumente akzeptieren können und in mehrfacher Ausführung vorhanden sein dürfen (d.h. mit gleichem Funktionsnamen, jedoch unterschiedlicher Anzahl von erwarteten Argumenten), ist die Angabe des Funktionsnames zusammen mit Slash + Zahl für die Anzeige der “Stelligkeit” (engl. “Arity”) einer Funktion notwendig. Mit “Stelligkeit” ist hier die Anzahl der “erwarteten Argumenten-Stellen” gemeint. Da unsere double-Funktion nur ein Argument erwartet, nämlich X, ist ihre Stelligkeit “eins” (1). Hätten wir z.B. weitere double-Funktionen, so müssten sich diese in der Stelligkeit voneinander unterscheiden, um von Erlang akzeptiert zu werden.

Nachdem wir mit Attributen dem Compiler die Umgebung vorgestellt haben, widmen wir uns der Funktion double. Sie besteht, nach Erlang-Terminologie, aus einem Headund einem Body. Zwischen diesen befindet sich ein stilisierter Pfeil, der vom Head auf den Body zeigt. Der Head ist dabei immer mit einem Funktionsnamen gefolgt von einem Klammerpaar und (optional) mit einer Argumentenliste innerhalb dieser versehen. Dabei werden mehrere Argumente durch Kommata voeinander getrennt. Als Argumente können sowohl Variablen wie auch Atome eingesetzt werden. Mit “Atome” sind konstante, nicht-numerische Werte gemeint, welche immer mit einem Kleinbuchstaben beginnen (im Gegensatz zu Variablen, welche immer mit einem Großbuchstaben anfangen). In unserem Falle kann double einen beliebigen Wert annehmen, welcher dann im Body mit sich selbst multipliziert wird. Und auch hier ist am Ende ein Punkt zu setzen.

Die Kompilierung des Programms ist denkbar einfach: Erlang-Shell starten und mit c(func1). die func1.erl-Datei kompilieren. Als Ergebnis erhält man ein sog. Tupel, welches aus dem Namen des Moduls und einem Atom “ok” besteht. Somit hat uns Erlang-Umgebung die Info geliefert, dass die Kompilierung erfolgreich verlaufen ist.

Da ich lokal das Ganze über Emacs laufen lasse, schaut bei mir die Ausgabe vielleicht etwas komplexer aus, als sie vielleicht sein sollte. Dennoch ist die Vorgehensweise dieselbe.

Jetzt können wir die exportierte Funktion double aufrufen. Dabei übergeben wir ihr den erwarteten Zahlenwert.

Als Ergebnis erhalten wir 144, was dem Quadrat von 12 entspricht. Der Aufruf selber ist recht einfach und erinnert entfernt an das Programmieren in C++, wenn es darum geht, die einzelnen Methoden den passenden Klassen/Namespaces zuzuordnen. In C++ wird die Zuordnung über sog. “Bereichsauflösungsoperatoren” erledigt (d.h. mit KLASSE::METHODE). Ähnlich wird auch bei Erlang verfahren, z.B. wenn es darum geht, die passende Funktion eines Moduls aufzurufen. Da es wohl recht viele “double”-Funktionen geben darf, muss sichergestellt werden, dass sowohl die richtige aufgerufen, wie auch die passende “Stelligkeit” befolgt wird. Es sind also zwei Sachen zu beachten: die passende Funktion über (optional viele) Module hinweg und dann noch die Funktion mit der gewünschten Stelligkeit (“Arity”) innerhalb eines Moduls. Hier ein leicht erweitertes Beispiel mit unserem bisherigen Modul.

Jetzt beinhaltet unser Modul eine weitere Version der double-Funktion. Diesmal ohne Argumente, d.h. mit Stelligkeit Null (0). Über diese Änderung muss auch der Compiler informiert werden, sofern wir vor haben, eine weitere Funktion zu exportieren. Daher wird die Liste in -export um einen Eintrag mehr erweitert. Die Listen werden in Erlang übrigens immer mit eckigen Klammern angegeben und ihre Elemente durch Kommata voneinander getrennt. In diesem Falle wäre es [double/0,double/1]. Nachdem wir die neue Modulversion kompiliert haben (in der unteren Fensterhälfte zu sehen), wird die neue double-Funktion aufgerufen (diesmal mit leeren Klammern, aber immer zusammen mit dem Modulnamen). Als Ergebnis erhält man 4, was genau den Vorgaben im Funktions-Body entspricht. So einfach kann Erlang sein.

Das ist aber nicht alles, denn in Erlang können Funktionen mehr als nur Werte zurückgeben und in mehrfacher Ausführung gleichzeitig vorhanden sein. In Erlang können Funktionen auch neue Funktionen als Ergebnis zurückgeben.

Noch einmal, zur Wiederholung: Funktionen können in Erlang neue Funktionen als Ergebnis zurückgeben. Oder Erlang-like ausgedrückt: wir können “higher-order-functions” basteln.

Hier ein kleines Beispiel:

Wir haben eine Variable Multiply, welche keinen direkten Wert zugewiesen bekommt, sondern vielmehr ein zunächst sonderbares Konstrukt:

fun(X,Y) -> 3 * (X + Y) end.

Was meint man damit?

Nun, die Bezeichnung fun habe ich mir, schon mal im Voraus, nicht ausgedacht, denn diese gehört zum Sprachumfang von Erlang. Dabei meinen wir mit dem Einsatz von fun, dass hier eine neue Funktion mit 3 * (X + Y) end. aufgebaut werden sollte. Dies bedeutet, dass wir in fun(X,Y) die Elemente eingesetzt haben wollen, welche später (im Funktions-Body) an die Stellen zum Einsatz kommen werden, wo jetzt 3 * (X + Y) end. steht, um einen neuen Wert zu berechnen. Somit steht Multiply stellvertretend für eine dahinter “eingebettete” Funktion, welche eben zwei Werte erwartet und nach einem bestimmten Algorithmus (hier: 3 * (X + Y)) rechnet. Diese “innere” Funktion wird auch durch das spezielle Schlüsselword end. auch explizit beendet. Ein fun wird immer mit einem end. abgeschlossen, damit Erlang diese richtig zuordnen und bei Bedarf auch “als Rückgabe-Wert” liefern kann.

Deshalb ist die Shell-Info beim ersten, oben abgebildeten Aufruf eben kein berechneter Wert, sondern vielmehr eine Erlang-Info die mit #Fun<erl_eval anfängt. Diese recht kryptische Ausgabe sollte aber niemanden verwirren, denn es handelt sich nur um Erlang-Internals, die für die Entwicklung selbst unerheblich sind. Wichtig ist nur zu wissen, dass damit Erlang zu verstehen gibt, dass es die Vorgaben evaluiert hat und in Zukunft überall dort wo Multiply steht eben diesen Algorithmus aktivieren wird. Ein simples Aufrufen von Multiply(3,3) gibt 18 aus und somit ist die Abarbeitung erfolgreich verlaufen. Für alle Entwickler die schon mal mit anonymen Funktionen zu tun hatten: “ja, dies sind anonyme Funktionen in Erlang“, was an sich kein Wunder ist, da anonyme Funktionen aus der funktionalen Programmierung kommen und Erlang eben “so ziemlich” funktional ist.

Dies ist aber auch nicht alles, denn mit funs kann man noch viel mehr machen, wie in diesem Beispiel hier:

Hier haben wir einen weiteren Level-Of-Indirection eingebaut und eine fun deklariert, die wiederum eine weitere fun beinhaltet. Um die Verwirrung aber schon zu Anfang zu ersticken, fangen wir ganz langsam an und schauen uns die einzelnen Bestandteile genauer an:

MoreMultiply bekommt Folgendes zugewiesen: fun(HowMuch) -> (EINE WEITERE FUN EINGEBETTET)

Wie wir schon im ersten Beispiel erfahren haben, können Variablen eingebettete funs beinhalten. Hier aber befindet sich aber in der ersten fun fun(HowMuch) eine weitere fun, welche wir aus Gründen der Übersichtlichkeit nicht aufgeschrieben haben.

Was hat dies zu bedeuten?

Ganz einfach: die erste fun (nennen wir diese “die äußere”) erwartet ein Argument, welcher dann in der zweiten (der “inneren”) fun eingebettet wird. Die innere fun beinhaltet aber mehr als nur die Variable HowMuch, nämlich Value * HowMuch. Dies bedeutet, dass die innere fun erst gar nicht rechnen könnte, wenn die äußere fun keinen Wert an sie liefern würde. Und genau hier liegt die Bedeutung in dieser scheinbar unnötig komplexen Verzahnung. Die innere fun ist nämlich eine VERALLGEMEINERTE Ausführung eines einfachen Multiplikators, welcher aber eben nicht selber vorgibt, wie eines seiner Elemente multipliziert wird. Die SPEZIALISIERUNG also, in diesem Falle die Angabe HowMuch kommt aus der äußeren fun. Somit ist die Arbeitsteilung klar: die äußere fun sagt, wer der Multiplikator ist und die innere benutzt diesen dann, um kommende Werte (d.h. Value) mit ihm zu multiplizieren. Deshalb ist der Rückgabewert von MoreMultiply eben nicht ein berechnter Wert, sondern vielmehr eine der vielen möglichen Spezialisierungen der inneren fun. Und erst mit dieser zurückgegebenen Spezialisierung können Berechnungen durchgeführt werden. So wie im Beispiel oben. Und auch hier meldet sich zuerst die Erlang-Shell und gibt die Erfolgsmeldung aus, dass die Evaluierung OK sei. Danach weisen wir einer neuen Variable die von uns gewünschte Spezialisierung zu (der Name der Variable sollte sinnvollerweise die Spezialisierung dokumentieren). In diesem Falle haben wir uns entschieden, dass die innere fun alle zukünftigen Werte mal 2 nehmen soll. Daher auch die Angabe MoreMultiply(2). Jetzt können wir die in MakeDouble abgelegte (innere) fun anwenden und geben eine 5 ein. Das Ergebnis ist erst jetzt mathematischer Natur und heißt 10.

Eigentlich einfach, nur es braucht Zeit, bis man sich vom alltäglichen Schema WERTEINGABE -> BERECHNUNG -> AUSGABE befreit hat. Hier wird eben ALGORITHMUSAUFBAU -> WERTEINGABE -> BERECHNUNG -> AUSGABE angewandt. Wir basteln uns zuerst den Algorithmus zusammen und setzen ihn erst später ein. Fast so wie mit Möbeln bei Ikea

So, das war’s für heute. Viel Spaß mit Erlang.

Und wie man dies mit Erlang bewerkstelligen kann, ist in dieser Präsentation (pdf) von Ulf Wiger vorgestellt worden.