Leider habe ich viel zu lange auf den zweiten Teil der Einführung in Erlang warten lassen. Und bevor ich überhaupt mit Ausreden anfange, fange ich lieber mit ganz konkreten Beispielen an.

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.

Da mittlerweile selbst die günstigsten Notebooks über einen sog. “Multicore”-Prozessor verfügen, ist es nur eine Frage der Zeit, bis auch die entsprechende Software verfügbar sein wird, welche diese neue Technologie ausreizt. Um von professionelleren Einsätzen (Telco-Industrie z.B.) erst gar nicht zu reden…

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

These days, the functional languages are all the rage. You see more and more hackers from the traditionally vanilla languages trying out things like Haskell or Scheme or OCaml. Breaking away from an imperative tradition forces us to think in a different way, which is always a good thing.

Recently, I’ve heard a lot about Erlang, especially from curious members of the Ruby community. This article is the result of my quick dive into the language, and will hopefully serve as a starting point for anyone else who’s been hearing the buzz, but hasn’t taken the plunge yet.

ONLAMP TUTORIAL

The programming language Erlang, new if even known at all to most computer programmers, secretly celebrates its 20th birthday year 2007. Erlang was developed with goals such as high-availability, “prototypeability”/maintainability and scalability over an at design time unknown number of CPUs. All goals are still challenges in software development. The scalability property has however reached another dimension due to the past few years development in the field of common and affordable multi core processors. This talk will cover the history of Erlang, demonstrate major design goals with a few programming examples and also touch on the subject of the future of Erlang. The speaker, Mr Lennart Ohman, has been working with Erlang since 1992 in different positions. Amongst many things Mr Ohman was actively involved in the development of the OTP framework, which is an architecture framework for Erlang based software. At present he is managing director of the consultancy company Sjöland & Thyselius Telecom AB.

Erlang ist eine mehrzweck (general-purpose) Programmierspache, welche vor allem das Paradigma der Nebenläufigkeit (Concurrency) implementiert. Ferner ist sie stark von der funktionalen Programmierung beeinflusst worden, wobei man hier aber nicht sagen kann, dass es sich bei Erlang um eine rein funktionale Sprache handelt. Um sich von allgegenwärtigen OO-Sprachen abzugrenzen, wird der Begriff der “Concurrency Oriented Programming Language” gebraucht, um den Fokus auf die Entwicklung von nebenläufigen, oft auf mehrere Prozessoren oder gar Netzwerke verteilten Applikationen zu betonen. Was Objekte für OO-Sprachen wie C++, Java oder C# sind, sind Prozesse für Erlang. Jedoch sind Prozesse in der Erlang-Welt nicht mit OO-Prozessen bzw. “Threads” zu vergleichen. So gibt es in Erlang kein Shared Memory und Locks sind auch nicht vorhanden. In Erlang läuft so ziemlich alles anders ab. So sind auch Variablen auch nicht so sehr “variabel”, wie man es von anderen Sprachen gewohnt ist. Auch was den allgemeinen Aufbau der Sprache angeht, so schaut man beim ersten Male fast wirklich “in die Röhre”, wenn man so eine erl-Datei in den Editor geladen hat.

Um den Schrecken aber nicht allzu sehr zu steigern (denn schließlich sollen ja paar Leute dieses Tutorial lesen), kümmern wir uns erst einmal um die Einrichtung der Erlang-Umgebung. Vergleichbar mit der JVM für Java oder .NET für C#, muss auch für Erlang bestimmte Vorarbeit geleistet werden, um an die Sprache (und den ganzen Rest) ranzukommen. Denn Erlang ist nicht nur eine Sprache, sondern auch eine Laufzeitumgebung (so ähnlich wie JVM oder .NET) wie auch eine Bibliothek. Da diese Dreigliedrigkeit aber eine recht hohe Komplexität in sich birgt, werden wir uns Schritt für Schritt der Programmiersprache Erlang nähern und mittels Erlang-Shell die Laufzeitumgebung Erlang kennenlernen, wie auch die Erlang-Bibliothek.

Die erste Anlaufstelle für Erlang/OTP is www.erlang.org (ja, eigentlich heißt es nicht bloß “Erlang”, sondern immer Erlang/OTP…Erklärung kommt später noch). Dort geht man auf Downloads und lädt sich die entsprechenden Binaries (es gibt sie für verschiedene Systeme, in diesem Tutorial wird Win32-Version eingesetzt). Die Installation wird per Installer durchgeführt und bereitet keinerlei Schwierigkeiten. Wer auf Linux-Version setzt, kann z.B. unter Debian (oder auch Ubuntu) mit einem einfachen apt-get install erlang die ganzen Binaries holen. Wer zuerst das ganze System lokal kompiliert haben möchte, muss mehrere Schritte gehen:

$ tar -xzf otp_src_R12B-4.tar.gz
$ cd otp_src_R12B-4
$ ./configure
$ make
$ sudo make install

Bei der Installation unter Windows wird man folgendes Fenster zu sehen bekommen:

Erlang-Installer erkennt automatisch, ob bestimmte DLLs bereits unter Windows vorhanden sind.

Danach geht es weiter zum Einrichten des Install-Verzeichnisses.

Noch den Menüeintrag setzen und mit der Installation kann begonnen werde.

Die wichtigste Schnittstelle zu Erlang ist sicherlich die Erlang-Shell, welche von der Kommandozeile aus per erl.exe aufgerfuen wird. Es existiert auch eine eigenständige Shell-Applikation, die über Windows-Menüs aufgerufen werden kann (werl.exe). Um ein ordentliches Arbeiten innerhalb der DOS-Konsole zu gewährleisten, sollte die PATH-Variable unter Windows um den Pfad zum Erlang-BIN-Verzeichnis gesetzt werden (z.B. C:/Programme/erl5.6.4/bin).

Wie man unschwer erkennen kann, ist meine Shell etwas “gesprächiger” als erwartet, da hier einige Verzeichnisse zusätzlich ausgegeben wurden. Dies liegt an der Anpassung einer speziellen .erlang Datei aus dem usr-Verzeichnis der Erlang-Installation. Diese Datei benutze ich vor allem, um eigene Quellcode-Verzeichnisse der Erlang-Shell bekannt zu machen. So muss ich dann bei der Kompilierung von der Shell aus keine langen Pfadangaben machen. Zusätzlich habe ich der .erlang-Datei die Pfadangabe einiger Emacs-Module angehängt (diese werden aber jetzt (noch) übersprungen). Erlang ist schon ungewöhnlich genug. Wenn ich jetzt noch mit Emacs anfangen würde, dann würde das Tutorial wirklich niemand mehr lesen wollen

Eine mögliche .erlang-Datei könnte bspw. so ausschauen:

io:format(“Lese .erlang aus ~p~n~n”,
[element(2, file:get_cwd())]).
% Erlang Code Path
io:format(“Wechsle ins “).
c:cd(“K:/desk/eigene/Codes/erlang”).
io:format(“\nQuellcodes sind in ~p~n~n”, [element(2, file:get_cwd())]).

Hier wird eine Ausgabe getätigt (io:format) inklusive der Information zum Verzeichnis, in welchem sich .erlang befindet (file:get_cwd()).  Danach wechselt die Shell mit c:cd() ins Quellcode-Verzeichnis und gibt wieder eine Information per io:format aus. Wie man merkt, sind einige der Sachen schon “bekannt” und erinnern sehr stark an bekannte DOS oder POSIX-Kommandos. Dennoch werden wir nicht von diesen Befehlen aus die Sprache Erlang anfassen und widmen uns lieber der Shell und ihren Besonderheiten. Denn, wer Erlang programmieren will, der macht es zuerst über die Shell. Es bringt bei Erlang wirklich nicht viel, wenn man sich auf irgendwelche Codes stürzt, diese schnell “mal eben” in irgendeinen Editor eingibt und dann versucht zu kompilieren. Erstens, es würde nicht einfach so gehen, denn selbst der Erlang-Compiler will von der Shell aus bedient werden (zumindest für den Anfang) und zweitens ist Erlang an einigen Stellen derart besonders, dass diese abgetippten Programme eh nicht verstanden werden könnten, selbst wenn sie zum Laufen gebracht worden wären. Also, ab zur Shell, ein paar Befehle eingeben:

So, in der ersten Zeile haben wir 10 + 100, dann eine weitere Zeile mit einem Punkt und dann dahinter das Ergebnis 110. Was hat das zu bedeuten? Ganz einfach zwei Dinge: in Erlang kann man direkt rechnen, ohne viele Umwege (also nix da mit int x = 10; int y = 100; int ergebnis = x + y;). Und was die Befehlsfolge angeht, so muss jede Anweisung mit einem Punkt enden, damit sie auch richtig interpretiert werden kann. Daher tat die Maschine nichts, als wir 100 eingegeben haben, denn es gab (noch) keinen Abschlusspunkt! Beim zweiten Versuch mit gleichen Operanden sehen wir, dass es sofort zum Ergebnis kommt. Das ist aber noch nicht die Welt und an sich auch keine Überraschung, denn auch andere Sprachen können “sowas”

Übrigens, vorangegangene Befehle können in der Erlang-Shell einfach mit den Pfeiltasten wieder hervorgeholt werden.  Oder aber mit Emacs-Befehlen (CTRL+P, CTRL+N). Im Allgemeinen ist das Editorsystem Emacs sehr empfehlenswert, wenn man mit Erlang zu tun hat. So existieren einige sehr gute Module für Erlang (mit Debugging-Möglichkeiten, Shell-Integration etc.). Jedoch kann z.Zt. auf Emacs verzichtet werden, da wir noch lernen, mit Erlang zu gehen. Fliegen werden wir (hoffentlich) später. Jetzt geben wir Folgendes in Erlang ein und tauchen so langsam in die seltsame Welt ein:

Wie wir sehen, muss bei Variablendeklaration kein expliziter Datentyp angegeben werden. Denn Erlang ist eine dynamisch getypte Sprache und somit entfällt das Vorgeben der zu erwarteten Datentypen.  Jedoch ist dies nicht die ganze Wahrheit, denn passt jetzt auf, was passiert, wenn man versucht, der angeblichen “Variablen” VariableX einen neuen Wert zuzuweisen.

Da meldet sich die Shell mit der Info, dass Werte nicht übereinstimmen! Aber, wir wollten doch nicht vergleichen, sondern zuweisen. Was ist denn hier passiert? Eigentlich ist die Erklärung ganz einfach zu verstehen, es sei den, man hat ein Leben lang nur mit “gewöhnlichen” Sprachen zu tun gehabt. Also, das Gleichheitszeichen ist kein Zuweisungsoperator, nicht einmal beim ersten Male, als VariableX = 10. stand. Nein, es gibt keine eigentlichen Zuweisungen in Erlang, denn auch die VariableX ist keine Variable, da man ihren Wert nicht wie bei vielen anderen Sprachen beliebig ändern kann. Vielmehr ist Erlang beim Interpretieren von Anweisungen an “Pattern Matching” angelehnt. D.h., dass beim ersten Male die Shell eben den Wert auf der rechten Seite (10) dem Pattern VariableX gleichgesetzt hat (oder in der Erlang-Terminologie “variable was bound“). In Erlang gibt es also nur gebundene und ungebundene Variablen. Alles andere entfällt. Deshalb gab es auch beim zweiten Versuch eine Fehlermeldung, weil eine gebundene Variable vor einen neuen Wert gesetzt wurde und gemäß Pattern Matching dieser Ausdruck als unwahr zu gelten hatte. Und das ist wiederum der Grund für die auf den ersten Blick seltsame Fehlermeldung, die besagt, dass der rechtsseitige Wert keine Entsprechung auf der linken Seite hatte. Dies ist sicherlich eine der wichtigsten (und wohl auch ungewöhnlichsten) Eigenschaften von Erlang. Variablen sind nämlich viel mehr den mathematischen Variablen ähnlich (so wie wir es eben in der Schule gelernt haben) und Operatoren wie das Gleichheitszeichen sind wirklich zum Vergleichen da und nicht für die gewohnte Wertezuweisung. Also, verkürzt: es gibt nur ungebundene und gebundene Variablen und alles wird per Pattern-Matching (Musterüberprüfung) erledigt. Und da Mathematik in ihrer abstraktesten Definition nichts anderes als die “Wissenschaft von Mustern” sei, ist es wohl mehr als logisch, dass mathematisch-orientierte Erlang-Variablen eben nach “Musterüberprüfung” verarbeitet werden und nicht durch stumpfe Wertezuweisung. In der Tat ist jede Erlang-Variable nichts anderes als ein gewöhnliches Pattern (“Muster”) und dementsprechend geht der Erlang-Interpreter so vor, wenn er zum ersten Mal auf einen Ausdruck wie z.B. VariableX = 10. stößt:

MUSTER “VariableX” erkannt, jedoch ist “VariableX” noch UNGEBUNDEN.

Setze MUSTER “VariableX” in VERBINDUNG zu 10, weil ein GLEICHHEITSZEICHEN zwischen diesen beiden steht.

Kommt es später zu einem neuen Pattern wie VariableX = 200., gibt es sofort eine Fehlermeldung, da eben das zuvor erkannte Muster nicht mehr auf diesem neuen abgebildet werden kann. Würdet ihr jetzt aber noch einmal VariableX = 10. eingeben, so gäbe es keine Fehlermeldung, sondern bloß die Ausgabe 10. D.h. das erste Muster ist als wahr erkannt worden.

So, das wär’s dann für’s Erste und ich hoffe, dass ein paar von euch dabei geblieben sind und tatsächlich diese abschließenden Worte lesen. Ganz zu Anfang dieses ersten Tutorials versprach ich zu erklären, was Erlang/OTP bedeutet. Ganz einfach: OTP steht für “The Open Telecommunication Platform” und stammt aus den Laboren der Firma Ericsson, welche auch die Sprache Erlang entwickelt hat. OTP ist eine spezielle Middleware mit dem Fokus auf den Aufbau von verteilten, hochverfügbaren Systemen. Dies bedeutet, dass Erlang zu Anfang für kommerzielle Projekte eingesetzt wurde. Erst später ist die Sprache zum OpenSource erklärt worden. Somit ist Erlang eine der wenigen Sprachen, die in einer kontrollierten Umgebung entwickelt, später dann bei einem internationalen Konzern auf “Herz und Nieren” geprüft (vor allem was Skalierbarkeit, Geschwindigkeit und Concurrency angeht) und erst danach in die OpenSource-Hände übergeben wurde.

Der Name “Erlang” selbst ist zu Ehren des Wissenschaftlers Agner Krarup Erlang als Bezeichner für die Sprache gewählt worden (auch wenn die Ähnlichkeit zu “Ericsson Language” nicht von der Hand zu weisen ist).

Weiterführende Informationen:

http://www.erlang.org/doc/getting_started/part_frame.html