In letzter Zeit sind in der Software-Entwicklung domänenspezifische Sprachen

• kurz als DSL für „domain-specific language“ bezeichnet - populär geworden: Das Versprechen einer DSL ist es, für ein bestimmtes Anwendungsgebiet besonders kompakte und verständliche Programme zu ermöglichen. Diese Programme können außerdem auf technische Details verzichten, die nichts direkt mit dem Anwendungsgebiet zu tun haben.

Das Entwickeln einer konventionellen DSL ist aufwendig, da zur Implementierung DSL alles dazugehört, was bei einer „normalen“ Programmiersprachenimplementierung ebenfalls fällig ist: Lexer, Parser, Compiler oder Interpreter sowie IDE-Support. Aus diesem Grund sind substantielle Frameworks für die schnelle Entwicklung von DSLs entstanden, z.B. Spoofax, das Eclipse Modeling Project oder Xtext.

In funktionalen Sprachen gibt es allerdings häufig einen einfacheren Weg: die Entwicklung einer sogenannten eingebetteten DSL (kurz EDSL für „embedded DSL“). Dabei wird die Host-Sprache so eingesetzt, dass es so aussieht, als ob innerhalb der Host-Sprache eine DSL entsteht. Dies hat eine Reihe von Vorteilen:

Weiterlesen...

Zeitreisen mit persistenten Datenstrukturen

Wir schreiben das Jahr 2025. Längst haben soziale Plattformen im Internet uns vollständig von der Notwendigkeit eines guten Gedächtnisses befreit. Ein Großteil der Kommunikation ist für die Ewigkeit auf Servern gespeichert und kann jederzeit abgerufen werden.

In einem Anflug von Nostalgie erinnern wir uns an die guten alten Zeiten um das Jahr 2013 und fragen uns, warum unsere Lieblingsplattform es uns nicht erlaubt abzufragen, wer denn damals unsere „Freunde“ und Freundesfreunde waren.

Sicherlich nicht, weil das nicht möglich ist. Virtuelle „Zeitreisen“ wie diese sind durchaus möglich und in vielen Fällen sogar effizient realisierbar. Am Beispiel eines Freundschaftsgraphen, wie er in sozialen Plattformen zu finden ist, werden wir mit diesem Artikel versuchen, uns einer bestimmten Klasse von Datenstrukturen zu nähern und eine vergleichsweise einfache Lösung des Problems zu entwickeln.

Weiterlesen...

JasperReports ist eine beliebte Java-Bibliothek zur Erstellung von Reports, in der Regel in PDF oder HTML-Form. Reports sind Auszüge oder Zusammenfassung aus größeren Datenbeständen in Form von Tabellen, Diagrammen und begleitenden Texten.

JasperReports bietet nun unter anderem eine API an, mit der man programmatisch einen Report zusammenbauen kann. Diese API lässt aber einiges zu wünschen übrig, was auch die Macher der Bibliothek DynamicJasper erkannt haben, die aber immer noch sehr imperativ ist. Das hat uns dazu veranlasst eine rein funktionale API in Scala zu implementieren, die auf JasperReports aufbaut, aber den Prinzipien der Nicht-Mutierbarkeit und der Kompositionalität folgt.

In diesem Beitrag demonstriere ich die Probleme mit der JasperReports-API, wie sie gelöst wurden, und welche funktionalen Grundprinzipien beim Design von APIs beachtet werden sollten.

Weiterlesen...

Im ersten Teil des Artikels haben wir in Haskell einen einfachen Server mit Rest-API für eine Blogging-Software geschrieben. Nun möchten wir noch ein einfaches Frontend dafür bauen. Wie bereits erwähnt wollen wir hier unter anderem die Soy-Templates-Sprache von Google und deren Kompiler verwenden, um über Templates mit JavaScript HTML zu erzeugen. Außerdem werden wir einen einfachen Controller in JavaScript schreiben, der die entsprechenden Funktionen zusammenfügt und mit Daten versorgt.

Weiterlesen...

Dieser Artikel zeigt den Einsatz von Monaden in der Praxis um GUI-Fenster zu beschreiben.

Für einen Kunden, der in der Sozialpädagogik tätig ist, entwickelt die ActiveGroup eine Software zur Dokumentation von Therapiemaßnahmen. Die Software erfasst die Stammdaten von Personen, die sich einer Therapie unterziehen, lässt die Personen Fragebögen ausfüllen, um den aktuellen Zustand und die Fortschritte der Therapie zu dokumentieren, und erlaubt das Erstellen zahlreicher Berichte.

Zur Entwicklung der Fragebögen verwenden wir eine Monade, welche die Darstellung des Fragebogens beschreibt und die Antworten einsammelt. Wieso eine Monade? Wir sehen folgende Vorteile:

• Komponierbarkeit Die Elemente des Fragebogens lassen sich unabhängig voneinander beschreiben und anschließend beliebig miteinander kombinieren. Damit lassen sich unterschiedliche Logiken im Ablauf eines Fragebogens darstellen, z.B. wenn Frage 1 mit ‚ja‘ beantwortet wurde, geht es weiter auf Seite 2, ansonsten auf Seite 3.

• Testbarkeit Da die Monade den Fragebogen nur beschreibt, lässt er sich relativ leicht testen. Statt Maus-Klicks zu synthetisieren, wertet man die Callbacks der Knöpfe innerhalb der Monade aus und testet ihre Auswirkungen auf die Beschreibung.

In diesem Artikel möchte die Komponierbarkeit anhand eines Beispiels illustrieren; die Testbarkeit und Implementierung überlasse ich späteren Artikeln. Als Beispiel dient ein kleiner Fragebogen, der festellt, ob der Befragte am Montag Zeit hat und falls ja, um wieviel Uhr.

Weiterlesen...