Funktionale Tests, also Tests die das Ergebnis einer Berechnung überprüfen, und Benchmarks sind fester Bestandteil moderner Softwareentwicklung. Manchmal möchte man jedoch sicherstellen, dass der Compiler bestimmte Optimierungen durchführt oder zeigen, dass der generierte Code genau so ist wie erwartet.
Für GHC, dem Standard-Compiler für Haskell, gibt es genau zu diesem Zweck die Library inspection-testing. Hierzu gab es auf der letzten BOB-Konferenz in Berlin auch einen Vortrag.
Weiterlesen...Unsere Konferenz BOB ist im Jahr 2019 mächtig aktiv. Neben der „üblichen“ Auflage im Februar/März findet dieses Jahr auch eine einmalige Sommerausgabe, ebenfalls in Berlin, statt. Zur Sommerausgabe gab‘s in diesem Blog schon mal was zu lesen, aber auch die Ausgabe im März verdient Aufmerksamkeit in Form eines Rückblicks, fand im März 2019 doch die 5. Ausgabe der Konferenz und somit auch ein kleines Jubiläum statt.
Weiterlesen...Elixir bietet uns eine einfache Möglichkeit, Testdaten übergreifend zu nutzen. Mit sogenannten Kontexten können wir eine Startbasis an Daten definieren, die unsere Tests komplett oder in Teilen verwenden können. Wir lernen das Konstrukt setup kennen. Neben Beispieldaten können wir auch Funktionsaufrufe mit Seiteneffekten im Setup ausführen, z. B. Löschen von vorherigen Testerzeugnissen auf der Festplatte oder Starten von externen Diensten.
Wer neu in Elixir ist, kann mit Test-ABC mit Elixir eine kurze Einführung in die Elixir-Test-Welt bekommen. Weiterlesen...
Dieses Jahr veranstalten wir einmalig eine Sommer-BOB. Sie findet am 21. August 2019 in Berlin im Scandic Hotel Potsdamer Platz statt, gemeinsam mit der International Conference on Functional Programming.
Das Programm steht! Es gibt zwei Tracks, in denen Forscherinnen und Entwickler über neue Ergebnisse und praktische Erfahrungen mit Techniken und Technologien berichten, die das Beste in der Softwareentwicklung repräsentieren.
Ein Track ist besetzt mit hochkarätigen Forscherinnen und Forschern aus der der Szene der funktionalen Programmierung, der andere mit spannenden Berichten über besonders effektive Techniken und Technologien in der Entwicklung, wie immer mit einem Fokus auf funktionaler Programmierung.
Die Registrierung ist eröffnet, es gibt Frühbucher-Rabatte bis zum 18. Juli.
Weiterlesen...Jeder Javascript Programmierer ist bestimmt schon mal über den Laufzeitfehler
undefined is not a function oder auch Cannot read property ‚length‘ of null gestolpert.
Der Fehler tritt immer dann auf, wenn man mit einem Wert etwas machen möchte (z.B. als Funktion
aufrufen oder auf die length Property zugreifen), der Wert dann aber undefined oder
null ist. Auch Java oder C# Programmier kennen dieses Problem unter dem Name
NullPointerException oder NullReferenceException, und in C oder C++ gibt es das Problem
natürlich auch, hier stürzt das Programm gleich ab.
Die Idee einer speziellen null-Referenz, die überall anstelle einer „echten“ Referenz verwendet
werden kann, geht auf Tony Hoare und ALGOL in den 1960er Jahren zurück. Tony Hoare nannte seine
Erfindung in der Retrospektive den
„billion dollar mistake“,
da die dadurch entstehenden Laufzeitfehler sehr häufig die Ursache von Bugs sind und somit
hohe Kosten verursachen.
Interessanterweise haben statisch getypte, funktionale Programmiersprachen diesen „billion dollar
mistake“ nicht wiederholt. So gibt es z.B. in Haskell den Typ
Maybe, der die
Abwesenheit eines Werts explizit im Typsystem repräsentiert.
Aber auch in Sprachen wie Javascript hat man die Notwendigkeit erkannt, statisch erkennen
zu wollen, ob Werte null oder undefined sein können. So ist in
Typescript, ein statisch getypter Javascript-Dialekt,
seit einiger Zeit die strictNullChecks Option verfügbar. Wir werden in diesem Artikel sehen,
wie man mit dieser Option Laufzeitfehler vermeiden kann, welche weiteren sinnvollen Optionen
es zur Fehlervermeidung gibt, wie man die strictNullChecks Option für eine große Codebasis
inkrementell einführen kann und ob man zwischen null und undefined unterscheiden sollte.