BOB Konferenz 2016 läuft an!

Nachdem die BOB 2015 ein voller Erfolg war, laufen die Vorbereitungen für die BOB 2016 auf vollen Touren. Am

  1. Februar 2016 treffen sich in Berlin wieder alle Software-Entwickler, Architekten und Entscheider, die sich für die besten Techniken und Technologien interessieren, die es in der Software-Entwicklung gibt.

Der Call for Contributions ist eröffnet. Schicken Sie uns also (bis zum 30. Oktober) Ihren Vorschlag für einen Vortrag oder ein Tutorial! Das Programmkomittee freut sich darauf! Zum ersten Mal gibt es auch Referenten-Zuschüsse für Referenten aus unterrepräsentierten Gruppen.

Außerdem freuen wir uns auf die Keynote von Elise Huard, die sich bei Mastodon C mit Big Data und funktionaler Programmierung beschäftigt.

Weiterlesen...

Kommandozeilenparser in Haskell - Teil 2

Im ersten Teil des Artikels haben wir Kommandozeilenoptionen mit der Bibliothek System.Console.GetOpt verarbeitet.

Die geparsten Kommandozeilenoptionen wurden, dabei in Form einer Liste zurückgeliefert, die man durchsuchen muss, um festzustellen, ob eine bestimmte Kommandozeilenoption angegeben wurde. Da es für die Weiterverarbeitung der Kommandozeilenoptionen in der Anwendung von Vorteil ist, die Optionen als Record-Typ darzustellen, haben wir eine Umwandlungsfunktion geschrieben, die die Daten von der Form als Liste des Summentyps in den Produkttyp umwandelt.

Der Ansatz führte jedoch dazu, dass wir jede Kommandozeilenoption einmal als Konstruktor im Summentyp, und einmal als Feld im Recordtyp definiert haben. Zusammen mit dem Eintrag in der Optionsliste (vom Typ [OptDescr a]) und dem Code in der Umwandlungsfunktion hatten wir dadurch vier Stellen, die angepasst werden müssten, wenn man z.B. eine Kommandozeilenoption hinzufügt. Allerdings kann es bei späteren Anpassungen leicht passieren, dass man den Summentyp erweitert, aber den Eintrag in der Optionsliste nicht anpasst, ohne dass es hierdurch zu einem Compilerfehler kommt.

Bei der Entwicklung von komplexen Anwendungen sind redundant vorhandene Informationen oft eine Fehlerquelle und führen zu höherem Wartungsaufwand (vgl. auch DRY Prinzip). Um die Redundanz an dieser Stelle zu reduzieren kann man in Haskell die Spracherweiterungen Generics und Literale auf der Typebene einsetzen. Die beiden Spracherweiterungen ermöglichen eine typsichere Abstraktion über die Datenstrukur - insbesondere werden hierdurch Fehler bereits bei der Kompilierung des Programms erkannt, statt erst zur Laufzeit.

Wir wollen in diesem zweiten Teil des Artikels mit Hilfe der obigen Spracherweiterung einen generischen Kommandozeilenparser entwickeln, mit dem das Parsen von Kommandozeilenoptionen in einen Record-Typ ohne redundanten Code möglich ist.

Weiterlesen...

Optimierung von Haskellprogrammen - Teil 2

Im vorherigen Teil unserer Serie haben wir uns Optimierungen angeschaut, die durch das Erzwingen von Berechnungen und Typ-Annotationen das Speicherverhalten und die Laufzeit von Haskellprogrammen verbesserten. Um den Wahrheitsgehalt solcher Behauptungen zu überprüfen, messen wir einfach das Verhalten der Programme. Um aber auch die Auswirkungen der gemachten Veränderungen zu verstehen und sicher zu gehen, dass tatsächlich das passiert was passieren soll, müssen wir uns den vom Compiler generierten Code anschauen. Was bei Low-Level-Sprachen wie C und C++ Assemblercode und bei JVM-Spachen Java-Bytecode wäre, ist bei dem Glasgow Haskell Compiler (GHC) Core.

Weiterlesen...