Letztes Jahr hat Apple mit Swift eine neue Programmiersprache vorgestellt. Über kurz oder lang wird Swift die Standardsprache werden, um Apps für iPhone, iPad, Mac und Co zu entwickeln. Und Swift enthält viele Elemente der funktionalen Programmierung, Zeit genug also, dass wir in diesem Blog mal einen genaueren Blick auf die Sprache werfen.

Interessant ist, dass Apple in Swift nicht nur einfach ein paar liebgewonnene Features aus funktionalen Sprachen eingebaut hat. Nein, es scheint vielmehr, dass grundlegende funktionale Designparadigmen wie „Werte statt veränderbare Objekte“ und „Seiteneffekte ja, aber mit Disziplin“ auch in Apples Vorstellung von guter Softwarearchitektur eine große Rolle spielen. Exemplarisch seien hier zwei Vorträge der Apple Worldwide Developers Conference genannt. Im Vortrag Building Better Apps with Value Types in Swift geht es um die Vorteile von Werttypen (value types) in Swift, also von Typen deren Werte unveränderbar sind. Und der Vortrag Advanced iOS Application Architecture and Patterns schlägt in dieselbe Kerbe, hier geht es ebenfalls um Werttypen und Unveränderbarkeit (immutability).

Weiterlesen...

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...

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...

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...

Freitag, den 11. September 2015 treffen sich alle, die an Haskell für die JVM interessiert sind, in den Räumlichkeiten von Canoo in Basel.

Weiterlesen...