© iStockphoto.com/P2007, © S&S Media
Windows Developer
JavaScript im Land der Fantasie

Olis bunte Welt der IT

Im April 2013 fand eine interessante Diskussion im GitHub Repository für die Planung der Spezifikation Promises/A+ statt [1]. Es wurde vorgeschlagen, dass die für JavaScript zu spezifizierenden Promises als Monaden erkannt und Promises/A+ entsprechend geändert bzw. ergänzt werden sollte. Im Detail waren die Vorschläge für die Änderungen sehr einfach, wurden jedoch von Domenic Denicola kurzerhand für unbrauchbar erklärt.

Oliver Sturm


„Yeah, this is really not happening“, schrieb Herr Denicola, „It totally ignores reality in favor of typed-language fantasy land ...“. Zu Deutsch: Das wird ganz sicher nicht passieren, der Vorschlag ignoriert die Realität vollständig zugunsten eines Fantasielandes von typisierten Sprachen. Die lange Diskussion, die auf diesen kurzen Austausch folgte, ist als unterhaltsame Lektüre für regnerische Nachmittage durchaus empfehlenswert. Es lassen sich daraus mehrere Dinge lernen: Promises sind Monaden, oder können zumindest als solche betrachtet werden. Es gibt zu viele Liebhaber funktionaler Programmierung, die nicht in der Lage sind, einen Zusammenhang ohne Erwähnung komplexer mathematischer Zusammenhänge zu erklären. Auf der anderen Seite gibt es zu viele Menschen, die Argumente anderer nicht im Detail bedenken, wenn sie mit der grundsätzlichen Aussage nicht einverstanden sind. Schockierenderweise waren einige der zuletzt erwähnten Menschen mit der Erstellung von Promises/A+ beschäftigt.Das Fantasy LandUm zu erklären, was der Sinn einer solchen Bestrebung ist, gehe ich noch einmal einen Schritt zurück zu den Vorschlägen für Promises/A+. Wie bereits erwähnt stand dort im Mittelpunkt, dass Promises als Monaden anerkannt werden sollten. Dieser kurze Satz ist nicht so einfach zu verstehen, wie man es gern hätte – vielleicht wissen Sie insgeheim auch nicht ganz genau, was das bedeutet. Was ist denn nochmal eine Monade? In der Sprache Haskell, die maßgeblich zur Definition der Monade beigetragen hat, ist eine Monade eine bestimmte Typklasse. Eine Typklasse wiederum ist einem Interface in einer objektorientierten Sprache ähnlich. Mit anderen Worten: Eine Typklasse definiert, welche Eigenschaften und welches Verhalten andere Typen gemeinsam haben. Im Gegensatz zum Interface kann allerdings eine Typklasse auch gleich eine Implementation des besagten Verhaltens mitbringen. Noch wichtiger ist, dass beliebige Typen im Nachhinein und „von außen“ mit einer Typklasse assoziiert werden können. Zum Beispiel gibt es in Haskell eine Typklasse Eq, zu der alle Typen gehören, deren Instanzen auf Gleichheit geprüft werden können. Die Typklasse Ord fasst typische numerische Vergleiche zusammen, also „größer“ und „kleiner“ sowie darauf aufbauende Varianten. Wenn Sie selbst einen Typ programmiert haben, können Sie für diesen eine Instanz dieser Typklassen erzeugen, so dass Ihr Typ offiziell vergleichbar ist. Für einen Typ aus einer Library, die jemand anderes geschrieben hat, könn...

Windows Developer
JavaScript im Land der Fantasie

Olis bunte Welt der IT

Im April 2013 fand eine interessante Diskussion im GitHub Repository für die Planung der Spezifikation Promises/A+ statt [1]. Es wurde vorgeschlagen, dass die für JavaScript zu spezifizierenden Promises als Monaden erkannt und Promises/A+ entsprechend geändert bzw. ergänzt werden sollte. Im Detail waren die Vorschläge für die Änderungen sehr einfach, wurden jedoch von Domenic Denicola kurzerhand für unbrauchbar erklärt.

Oliver Sturm


„Yeah, this is really not happening“, schrieb Herr Denicola, „It totally ignores reality in favor of typed-language fantasy land ...“. Zu Deutsch: Das wird ganz sicher nicht passieren, der Vorschlag ignoriert die Realität vollständig zugunsten eines Fantasielandes von typisierten Sprachen. Die lange Diskussion, die auf diesen kurzen Austausch folgte, ist als unterhaltsame Lektüre für regnerische Nachmittage durchaus empfehlenswert. Es lassen sich daraus mehrere Dinge lernen: Promises sind Monaden, oder können zumindest als solche betrachtet werden. Es gibt zu viele Liebhaber funktionaler Programmierung, die nicht in der Lage sind, einen Zusammenhang ohne Erwähnung komplexer mathematischer Zusammenhänge zu erklären. Auf der anderen Seite gibt es zu viele Menschen, die Argumente anderer nicht im Detail bedenken, wenn sie mit der grundsätzlichen Aussage nicht einverstanden sind. Schockierenderweise waren einige der zuletzt erwähnten Menschen mit der Erstellung von Promises/A+ beschäftigt.Das Fantasy LandUm zu erklären, was der Sinn einer solchen Bestrebung ist, gehe ich noch einmal einen Schritt zurück zu den Vorschlägen für Promises/A+. Wie bereits erwähnt stand dort im Mittelpunkt, dass Promises als Monaden anerkannt werden sollten. Dieser kurze Satz ist nicht so einfach zu verstehen, wie man es gern hätte – vielleicht wissen Sie insgeheim auch nicht ganz genau, was das bedeutet. Was ist denn nochmal eine Monade? In der Sprache Haskell, die maßgeblich zur Definition der Monade beigetragen hat, ist eine Monade eine bestimmte Typklasse. Eine Typklasse wiederum ist einem Interface in einer objektorientierten Sprache ähnlich. Mit anderen Worten: Eine Typklasse definiert, welche Eigenschaften und welches Verhalten andere Typen gemeinsam haben. Im Gegensatz zum Interface kann allerdings eine Typklasse auch gleich eine Implementation des besagten Verhaltens mitbringen. Noch wichtiger ist, dass beliebige Typen im Nachhinein und „von außen“ mit einer Typklasse assoziiert werden können. Zum Beispiel gibt es in Haskell eine Typklasse Eq, zu der alle Typen gehören, deren Instanzen auf Gleichheit geprüft werden können. Die Typklasse Ord fasst typische numerische Vergleiche zusammen, also „größer“ und „kleiner“ sowie darauf aufbauende Varianten. Wenn Sie selbst einen Typ programmiert haben, können Sie für diesen eine Instanz dieser Typklassen erzeugen, so dass Ihr Typ offiziell vergleichbar ist. Für einen Typ aus einer Library, die jemand anderes geschrieben hat, könn...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang