In einem vorherigen Posting haben wir uns mit einer Monade für Wahrscheinlichkeitsverteilungen beschäftigt. Diese erlaubt uns, ein probabilistisches Szenarium als Programm aufzuschreiben, deren Ausführungen die Wahrscheinlichkeitsverteilung möglicher Resultate des Szenarios liefert. Allerdings ist die explizite monadische Programmierung etwas umständlich. Eigentlich hatten wir uns gewünscht, die Szenarien als „normales“ Racket-Programm unter Verwendung der gewohnten Operatoren wie and, if und let zu schreiben. Stattdessen mussten wir bisher monadische Versionen con, if_ und let_ benutzen. In diesem Post zeigen wir, wie wir genau das erreichen, und zwar unter Verwendung einer geradezu bewusstseinserweiternden Technik namens Kontrollabstraktion, die es in der Mächtigkeit nur in funktionalen Sprachen gibt. Dieses Posting ist technisch etwas anspruchsvoll.

Weiterlesen...

Vor kurzem war Nebenläufigkeit mit Software Transactional Memory das Thema hier im Blog. Da Nebenläufigkeit auch in modernen Softwaresystemen immer noch häufig ein schwieriges Problem und eine Quelle vieler Fehler ist, schauen wir uns heute Software Transactional Memory (kurz: STM) nochmal genauer an. Funktionale Sprache wie z.B. Haskell, Scala oder clojure bieten gute Unterstützung für STM, denn der deklarative Programmierstil und der weitgehende Verzicht auf Seiteneffekte passen gut zum STM-Paradigma.

Wir haben in dem ersten Artikel gesehen, dass STM eine Alternative zu Locks darstellt, die einfacher zu benutzen ist und bei der Probleme wie Deadlocks oder Race Conditions typischerweise nicht oder nur sehr selten auftreten. Meine tägliche Erfahrung mit STM in unserem Softwareprodukt CheckpadMED bestätigt mich immer wieder darin, dass Nebenläufigkeit mit STM eigentlich (relativ) einfach ist: man muss lediglich spezifizieren, welche Codeblöcke atomar laufen sollen, und das Laufzeitsystem stellt dann diese Atomizitätseigentschaft sicher.

Im heutigen Artikel untersuchen wir STM etwas genauer. Wir gehen dabei der Behauptung nach, die wir im ersten Artikel aufgestellt haben, nämlich dass auch Gründe der Softwarearchitektur für STM sprechen: während zwei mit Locks implementierte Programmkomponenten oftmals nicht ohne Änderung des Locking-Protokolls zu einer neuen Komponenten zusammengebaut werden können, klappt ein solcher Zusammenbau mit STM meist problemlos, ohne dass man sich über Implementierungsdetails der Komponenten Gedanken machen muss.

Weiterlesen...

Uns erreichte neulich die Frage „Wozu sind Monaden eigentlich in dynamisch getypten Sprachen“ gut? In Haskell zum Beispiel sind ja Monaden fast allgegenwärtig und haben dort insbesondere die Aufgabe, anhand der Typen deutlich zu machen, mit welchen Effekte ein Entwickler bei der Auswertung eines Ausdrucks rechnen muss. Da Typen in dynamisch getypten Sprachen im Programmtext nicht direkt sichtbar sind, ist die Frage legitim, da viele Monaden nur jeweils einen Wert als Resultat einer Berechnung mit Seiteneffekten produzieren. Es gibt allerdings auch Monaden, die mehr leisten - wie zum Beispiel die Monade der Wahrscheinlichkeitsverteilungen. Um die geht es in diesem Beitrag - und zwar in einer dynamisch getypten Sprache, nämlich in Racket. Racket bietet für diese Anwendung relevante Abstraktionsmöglichkeiten, die noch über die Fähigkeiten von Haskell hinausgehen. Es wird nur rudimentäres Racket vorausgesetzt, wie zum Beispiel in unserem früheren Posting erläutert.

Weiterlesen...

Die Active Group entwickelt die Software EQUALS für das gleichnamige Gemeinschaftsprojekt von INTEGRAS und der KJPK Basel. EQUALS (eine Kurzform für „Ergebnisorientierte Qualitätssicherung in sozialpädagogischen Einrichtungen“) hilft zur Abklärung der psychischen Gesundheit von jungen Menschen, sowie zur pädagogischen Dokumentation der (Heim)-Erziehungshilfen.

In diesem Projekt haben wir 2012 begonnen, die Java-Codebasis Schritt für Schritt nach Scala zu migrieren. Dieser Blogpost zeigt dazu die prinzipellen Schritte, die notwendig sind, um Scala und Java zusammen in einer Software zu verwenden.

Weiterlesen...

Nebenläufigkeit ist aus modernen Softwaresystemen nicht mehr wegzudenken. Sei es, um Performancesteigerungen durch paralleles Ausführen auf mehreren Prozessorkernen zu erzielen, oder weil das zugrundeliegende Problem inherent nebenläufig ist. In einem anderen Blogartikel haben wir uns bereits mit der Parallelisierung von Programmen bzw. Algorithmen beschäftig.

Heute soll es nun um echte Nebenläufigkeit gehen. Mit „echter Nebenläufigkeit“ meine ich, dass die Nebenläufigkeit nicht Mittel zum Zweck ist, sondern im zu lösenden Problem schon drinsteckt. Ein gutes Beispiel ist z.B. ein Webserver, der quasi gleichzeitig Anfragen von verschiedenen Clients beantwortet. Um einen solchen Webserver zu programmieren, ist Nebenläufigkeit ein gutes Modell: jeder Client wird als separater Thread programmiert und kann damit isoliert betrachtet werden.

Jeder der schon einmal ein nebenläufiges Programm geschrieben hat, weiß allerdings wie schwer es sein kann, Daten zwischen verschiedenen Threads auszutauschen: Race Conditions und Deadlocks sind oft die Folge. In diesem Artikel geht es um „Software Transactional Memory“, kurz STM, einer alternativen Technik zur Kommunikation zwischen Threads. Wir setzen in der Serverkomponente unseres Produkts CheckpadMED ausschließlich auf STM zur Kommunikation zwischen Threads und sind damit sehr zufrieden. STM ist sprachunabhängig und steht für eine Vielzahl von funktionalen Sprachen (z.B. Clojure, Haskell, OCaml, Scala) und anderen Sprache (z.B. C/C++, C#, Java) zur Verfügung. Funktionale Sprachen scheinen aber für den Einsatz von STM deutlich besser gerüstet zu sein, da dort unveränderbare Datenstrukturen und der Verzicht auf global-veränderbare Variablen Standard sind. In diesem Artikel zeigen wir, wie STM in Haskell funktioniert, die Konzepte sind aber in den anderen Sprachen sehr ähnlich und übertragbar.

Weiterlesen...