Ein Streifzug durch die Features von TypeScript

In den letzten Jahren hat sich die Entwicklung von Web-Anwendungen in eine Richtung gedreht, in der immer größere Teile komplexer Softwaresysteme im Browser leben. Damit haben sich auch die Ansprüche an den Browser als Softwareplattform geändert, und die Kapselungs- und Abstraktionsmöglichkeiten der ehemals als HTML-Erweiterung angelegten Browser-Programmiersprache JavaScript genügen nicht mehr.

Inzwischen gibt es eine Reihe von Programmiersprachen, die mit unterschiedlichen Ansätzen an JavaScript andocken können. In einem Artikel über ClojureScript wurde in diesem Blog bereits eine Sprache aus der LISP-Familie vorgestellt. Im vorliegenden Artikel geht es um TypeScript, eine Alternative, die sich durch ein statisches, von C# inspiriertes Typsystem und niedrige Einsatzhürden auszeichnet.

Weiterlesen...

Web-Apps mit Reacl programmieren

Bei der Active Group arbeiten wir an mehreren Projekten mit Web-Frontends. Dies ist inzwischen auch für „normale“ Applikationen eine echte Alternative zu den oft umständlichen und eingeschränkten GUI-Toolkits von Java, .NET & Co, da fast alle mit einem „Web-Widget“ geliefert werden, in dem JavaScript/HTML5-Anwendungen laufen können. HTML5 und die reichlich vorhandenen Frameworks für die Web-Programmierung bieten größeren Gestaltungsspielraum als die traditionellen GUI-Toolkits und sind außerdem leichter zu portieren.

Trotzdem macht die DOM-Programmierung mit Javascript (und auch mit vielen Frameworks, die das eigentlich vereinfachen sollen) oft nicht so richtig Freude. Geändert hat sich das für uns mit dem Open-Source-Release von Facebooks Framework React, bei dem Ideen aus der funktionalen Programmierung deutlich zu erkennen sind. Um die Entwicklung noch weiter zu vereinfachen, setzen wir für die React-Programmierung ClojureScript ein, und zwar mit einem eigenen Wrapper für React namens Reacl, der ebenfalls als Open Source verfügbar ist. Um Reacl geht es in diesem Posting, das etwas länger ausgefallen ist.

Weiterlesen...

Funktionale Programmierer(innen) gesucht!

Aufmerksame Leser dieses Blogs wissen, dass wir nicht nur mit viel Spaß funktional programmieren, sondern auch, um damit unser Geld zu verdienen. So entwickelt z.B. die factis research GmbH in der funktionalen Sprache Haskell das Produkt Checkpad MED, eine elektronische Patientenakte für iPad, iPhone und Co. Wir haben die technischen Zusammenhänge von Checkpad bereits in einem früheren Artikel vorgestellt.

Inzwischen ist Checkpad mit mehrere Produktiv-Installationen, vielen Pilot-Projekten und noch mehr Kundenanfragen so erfolgreich, dass wir dringend Verstärkung brauchen! Und zwar in allen technischen Bereichen, z.B. als Kernentwickler, Schnittstellenentwickler, QA-Entwickler, DevOps-Entwickler und mehr. Alle Stellen haben etwas mit funktionaler Programmierung zu tun, manche mehr, manche weniger. Es ist also sowohl für Experten und Expertinnen der funktionalen Programmierung, als auch für Leute, die das noch werden wollen, etwas dabei.

Wenn Sie Lust haben, gemeinsam mit uns in einem tollen Team etwas voranzubringen, dann schauen Sie doch einfach mal auf unserer Webseite vorbei, dort finden Sie alle weiteren Informationen. Wir sind gespannt!

Mehr Typsicherheit durch GADTs

Statische Typsysteme haben zahlreiche Vorteile. Der naheliegendste Vorteil ist vermutlich, dass mögliche Laufzeitfehler verhindert werden.

Stellen wir uns zum Beispiel vor, wir wollten SQL-Anfragen modellieren. Wählen wir einen String als Repräsentation, so können wir ohne weiteres syntaktisch inkorrekte Anfragen basteln, und haben keinen hohen Grad an Sicherheit. Wählen wir statt dessen einen spezifischen Datentyp SQL, der einen abstrakten Syntaxbaum modelliert, so können wir uns auf syntaktische Korrektheit verlassen, aber wir können noch immer andere Fehler machen. Was, wenn wir sicherstellen wollten, dass die verwendeten Namen von Tabellen und Feldern tatsächlich in unserer Datenbank enthalten sind? Was, wenn wir garantieren wollen, dass wir SQL-Operatoren in typkorrekter Art und Weise verwenden wollen? Es ist einfach, sich vorzustellen, dass wir dies durch Tests zur Laufzeit sicherstellen können. Aber ist es auch möglich, dies bereits durch statische Typen zu garantieren?

Ein einfacheres Beispiel: Wir haben eine Applikation, die Fragebögen und zugehörige Antworten verwaltet. Es gibt verschiedene Sorten von Fragen. Manche Fragen sollten mit „Ja“ oder „Nein“ beantwortet werden, andere mit einer Antwort aus einer vorgegebenen Auswahl, wieder andere mit einer quantitativen Angabe. Sicher können wir Datentypen definieren, die die verschiedenen Sorten von Fragen und die verschiedenen Sorten von Antworten modellieren. Aber wenn wir nun Fragen und zugehörige Antworten haben, wie wissen wir dann, dass die Sorten der Fragen und die Sorten der Antworten zueinander passen? Wiederum ist es einfach, dies zur dynamisch zu testen. Es ist nicht ganz so einfach – aber durchaus möglich – dies auch statisch im Typsystem sicherzustellen.

Das Sprachmittel, welches wir dazu verwenden werden, heißt „GADT“. Die Abkürzung steht für „Generalized Algebraic Data Type“, zu Deutsch „generalisierter algebraischer Datentyp“. GADTs stehen in Haskell bereits seit vielen Jahren als Spracherweiterung zur Verfügung (und werden vermutlich auch irgendwann in den Standard Einzug halten), und sind mittlerweile auch in einigen anderen Programmiersprachen verfügbar.

Im folgenden will ich das Beispiel mit den Fragebögen in Haskell etwas näher beleuchten. Zunächst werden wir mit normalen Sprachmitteln skizzieren, wie man eine solche Applikation in Haskell implementieren könnte. Dann werden wir sehen, an welcher Stelle die Verwendung von GADTs sinnvoll wird, und was GADTs genau sind.

Weiterlesen...

Noch mehr über Software Transactional Memory

Heute geht‘s nochmal um Software Transactional Memory (STM), eine schöne und saubere Möglichkeit, um in Programmen mit Nebenläufigkeit umzugehen. Hier im Blog gab‘s ja schon eine Einleitung zu STM sowie einen weiterführenden Artikel. Bisher haben wir gesehen, dass STM traditionellen Techniken zum Umgang mit Nebenläufigkeit (wie z.B. Locks) überlegen ist:

  • Atomare Blöcke werden einfach als solche deklariert werden und der Programmier muss Atomizität nicht explizit durch Locks sicherstellen.
  • Mit STM entwickelte Komponenten können einfach zu neuen Komponenten zusammengebaut werden, was mit Locks oftmals die Überarbeitung des Locking-Modells nach sich zieht.

Heute soll es nun abschließend um ein mögliches Ausführungsmodell für STM gehen. Das vorgestellte Modell ist konzeptionell sehr einfach und vom Prinzip auch so im GHC Compiler für Haskell umgesetzt. Natürlich können anderen STM-Implementierungen auch anderes Ausführungsmodelle verwenden, vorausgesetzt die Atomizitätsgarantien werden nicht verletzt.

Weiterlesen...