In this talk I want to revisit the parametricity theorem: from parametrically polymorphic types, i.e., types that contain type variables that can be arbitrarily instantiated, we can directly infer certain properties of the underlying functions, without ever having to look at their implementation.

A simple example in Haskell is the type forall a. a -> a, which (apart from looping or crashing functions) can only be inhabited by the identity function.

This may sound like a curiosity, but I will argue that it is in fact an invaluable tool in program design and day-to-day reasoning about programs, and explain how to build an intuition that allows you to do so without the need for deep or complicated theory. We will look at several interesting examples and hopefully make a few perhaps surprising discoveries along the way.

I will also try to explain how in the case of parametricity, making types more abstract can really help in making functions easier to understand, whereas it often feels like the opposite may be true. To this end, I will try to contrast abstraction in the context of parametricity with other kinds of type-level abstraction common in Haskell, in particular abstraction via type classes, and show how they are different.

Die Netze BW als Verteilnetzbetreiber für Strom, Gas und Wasser in Baden-Württemberg entwickelt und betreibt Software für den Betrieb von Netzen. Als Teil kritischer Infrastruktur des öffentlichen Lebens waren die Anforderung an Zuverlässigkeit immer sehr hoch. Kombiniert mit der zunehmenden Komplexität der Energiewende müssen immer mehr und immer komplexere Prozesse abgebildet und mittels Software realisiert werden.

In diesem Vortag wird der bisherige Weg von #NETZlive, einem Softwareprojekt der Netze BW, gezeigt, wie mittels Microservices, Containerisierung, Clusterbildung, redundanten Anwendungen, fehlertoleranten Entwicklungssprachen und der funktionalen Programmierung an sich die Zuverlässigkeit der Systeme gesteigert wurde und wie es noch weiter gesteigert werden muss.

Dazu fordert die Energiewende eine höhere Automatisierung von kritischen, ins Netz eingreifenden Prozessen, was zusätzlich die höchste Sicherheitsbewertung der Software mit sich bringt. Der Vortrag gibt einen Ausblick, was hier mittelfristig erforderlich sein wird.

The recent shift toward signals in frontend development is redefining how we approach state management, making declarative programming more practical and accessible. By embracing signals, developers can now build applications that are more predictable, maintainable, and less prone to unintended state changes. This presentation dives deep into the principles and practices of this declarative approach, contrasting it with previous imperative patterns and demonstrating how signal-based architectures lead to cleaner and more manageable code.

Through a series of practical examples, we’ll explore the benefits of signals for creating a stable, unchanging state in applications, reducing unexpected behaviors and improving readability. We’ll also examine common pitfalls developers face when working with signals and how to avoid them, enabling participants to make the most of this powerful tool. Finally, we’ll push the boundaries of declarative design by integrating signals with reactive streams, demonstrating how to harness the full power of functional programming with RxJS.

Join us to discover how signals and streams can transform your approach to frontend development, leading to applications that are not only robust and scalable but also easier to reason about and maintain.

"Mob AI Driven Test Driven Development" - Wir haben das Buzzword-Bingo gewonnen! Was sich hinter diesem illustren Begriff verbirgt ist eine Session, bei der wir gemeinsam (im Mob-Programming) die Schnittstelle aus AI-Helpern (Github-Copilot) und testgetriebener Entwicklung (TDD) erforschen.

Was sollten wir generieren und was selbst schreiben? Wie sieht ein guter Workflow aus? Wie stellen wir Qualität sicher, wenn Code generiert wird?

Wir haben nicht auf alle diese Fragen definitive Antworten, aber bei dieser Session habt ihr die Gelegenheit, einige der Antworten selbst zu finden...

This talk is going to focus on peer-to-peer apps. We'll try to answer the question: how to build an app that will enable information exchange between our clients without a need to maintain heavy backend infrastructure? Is it even possible? We'll walk through different ways of data exchange, from local to wide arena networks, and how to make them work for us.

LSP has greatly standardised the behaviour of IDEs, in a good direction: we can provide, de-facto, decent language support in editors supporting LSP.
But it also imposes a standardisation that often assumes that all languages behave like TypeScript. In this presentation, I'll introduce you to Merlin, the IDE service library for OCaml, and cover the custom features (via code-action and custom-request) that enhance the OCaml development experience (covering expression destructuring, expression construction, search by types (à la hoogle, directly in the IDE), type enclosures etc.).

The aim of the presentation was to show how to go beyond the default features offered by LSP and offer a development experience adapted to a more expressive language.

Concurrent programs destructively updating shared memory are
notoriously hard to get right. Concurrent separation logics
are logics with built-in notions of e.g. ownership of memory
regions, concurrent accesses, and lock mechanisms. They give
experts a way to verify a posteriori that complex concurrent
imperative programs hopefully abide by their formal
specification.

We will see how next generation languages let us get rid of
a posteriori verification in favour of a correct-by-construction
approach whereby the program is interactively built in a
specification-respecting dialogue with the compiler.
For this presentation we will be using Idris 2,
a general purpose functional language with an expressive
type system combining dependent types to enforce complex
invariants and linear logic to track resource usage.

We will demonstrate how a simple library can capture ideas
from concurrent separation logic by providing proof-carrying
concurrent primitives. These make it impossible to write into
memory one does not own or to release a lock without having
proven that its associated invariant has been re-established.
They also guarantee that whatever is read from the shared
memory is invariant-respecting.

This will culminate in worked out example e.g. the definition
of map-reduce primitives repeatedly and safely breaking down
a buffer into chunks that can be processed concurrently
and/or a naïve bank with concurrent cash machines.

Domain-specific languages (DSLs) are languages specialized for a particular domain, and are typically equipped with features that make them well-suited for programming within that domain. This talk explores and compares three common strategies to creating DSLs:

• Standalone DSLs, which are entirely new languages.
• DSLs embedded in existing host languages.
• DSLs that are subsets of existing host languages, which may employ one of two techniques: metaprogramming and compiler plugins.

Each strategy comes with its own benefits and drawbacks, and the optimal choice will vary based on your unique needs. We'll give an in-depth comparison of these approaches with real-world examples, considering the viewpoints of both language developers and language users. An example domain is smart contract languages for the Cardano blockchain, where DSLs employing each of the three strategies can be found. We’ll also draw examples from fields such as flight control systems, signal processing and more.

Despite sophisticated tooling, data scientists still battle fundamental challenges day to day, like reproducibility, maintainability, and sharing their work. While traditional notebooks offer interactivity and quick feedback, they're plagued with hidden state dependencies, version control complexity, and production deployment hurdles. Converting notebook-based analyses into production-ready code often requires extensive refactoring, untangling implicit dependencies, debugging hidden state issues, and deciphering sparse documentation. And that's before tackling today's reality of excessively large, unstructured data dumps typically lacking any metadata or explanation, making it difficult to find useful data in the first place.

Clojure's data science ecosystem has been maturing rapidly in recent years. With it's stable toolkit, immutable data structures, and functional paradigm, Clojure offers a compelling alternative to traditional data science workflows. Imagine knowing exactly which version of your code produced which dataset. Or seamlessly deploying the same code you used in an exploratory analysis to production. And imagine that code also ran in a state of the art literate programming environment, but also simultaneously in your own, familiar IDE.

This hands-on workshop will introduce a new way of thinking about working with data, demonstrating how Clojure's libraries and tooling solve many pain points in current data science workflows.

In diesem Tutorial wird praxisnah vermittelt, wie mit Elixir stabile und fehlertolerante Systeme gestaltet werden können. Zu Beginn nehmen wir das GenServer-Modul und dessen Funktion im Umgang mit Zustand und Nebenläufigkeit genauer unter die Lupe. Anschließend setzen wir ein einfaches, fehleranfälliges Prozessmodell um, das bewusst Schwachstellen enthält, die typisch für reale Produktionsumgebungen sind und die die Stabilität eines Systems beeinträchtigen können.

Nachdem typische Ausfallszenarien identifiziert sind, optimieren wir das Prozessmodell durch den gezielten Einsatz von Supervisor-Strategien. So wird nach und nach eine robuste Struktur aufgebaut, die Fehler isoliert und Prozesse bei Bedarf automatisch neu startet. Durch den Einsatz von Supervision Trees und kontrollierten Neustarts lässt sich ein resilientes System entwickeln, das auch unter hoher Last zuverlässig läuft und im Ernstfall eine selbstheilende Architektur aufweist.

Dieses Tutorial richtet sich an Entwickler*innen, die das robuste Systemdesign mit Elixir kennenlernen möchten und nachvollziehen wollen, wie man stabile Anwendungen für anspruchsvolle Einsatzbereiche konzipiert.

Domain-specific languages (DSL) are well-studied tools for solving problems specific to a domain.
Especially in the Haskell Community, DSLs are quite popular due to parser-combinators and succinct definitions of abstract syntax trees (AST).
However, it is often difficult to integrate a particular DSL into any modern IDE.
This causes a DSL to be harder to use in practice and negatively affects productivity.
Sometimes, developers combat this by implementing plugins that introduce syntax highlighting specific to an editor.
However, we argue that it is preferable to use existing infrastructure, such as the Language Server Protocol, which provides out-of-the-box IDE support for most editors.

In this talk, we focus on key challenges for implementing a Language Server, as a Language Server simply has different requirements from a parser or an interpreter.
We discuss how to approach the design and implementation of a DSL such that we get Language Server support (almost) for free.
In particular, we show how to provide advanced IDE features, such as semantics-aware syntax highlighting or automatic refactorings, with minimal effort.
To implement this, we augment the AST to retain additional information about the sources, such as parentheses, comments, and whitespace, in a non-intrusive way.

Formal methods are very often touted as a necessary evolution of software development to cope with increasing complexity, risks, and challenges. This is especially true in functional programmers' circles, as there's historically a strong link between functional programming languages and formalisation of computing. After all, if software engineers really want to be considered as "true" engineers like mechanical or nuclear engineers, they will need to embrace formalisation and root their practices and tools in solid mathematical foundations.
But one can ask the question: is this narrative true? Is it necessary for software development to come of age and embrace formal methods? And, perhaps more importantly, is it desirable?
Based on my experience developing software over the past 30 years, in a wide array of environments, some of which even using formal methods, and some theoretical, epistemological and philosophical references, I try to answer those questions in a more nuanced way.
This presentation puts formal methods (FM) in perspective within the broader domain of software development, as yet another tool to deliver value. I shall present my experience working with FM, identify various shortcomings and issues of FM in the software development lifecycle, and suggest ways to mitigate those issues in order to help teams benefit the most from FM.

Consider the following example, where an error is triggered if some input
bytestring starts with "bad!":

if input[0] == 'b' {
    if input[1] == 'a' {
        if input[2] == 'd' {
            if input[3] == '!' {
                error "input must not be bad!"
            }
        }
    }
}

If we were to try to find this error using vanilla property-based testing,
where we restrict the input strings to always be of length four, then it would
take about (2^8)^4 = 2^32 (about 4 billion) tries.

Using coverage-guidance we keep track of inputs that resulted in increased
coverage. So, for example, if we generate the bytestring "b" then we get
further into the nested ifs, and so we take note of that and start generating
longer bytestrings that start with "b" and see if we can get further coverage,
etc. By building on previous successes in getting more coverage, we can
effectively reduce the problem to only need (2^8)*4 = 2^10 = 1024 tries.

In order words coverage-guidance turns an exponential problem into a polynomial
problem!

In this talk I'll show how coverage-guidance can be added to the first version
of QuickCheck, that can be found in the appendix of the original paper, in
about 35 lines of code.

There’s a world outside of Java and C#. Well, you know there is, because you know there's the dreadful PHP, there are JavaScript, TypeScript, Go, Kotlin, Scala and Swift.
But let's look at bit further. If you're interested in programming languages, you probably heard about Haskell with its pure functions and lazy evaluation. And about Rust, with it's ownership and borrowing based memory management. Let's skip even those and go just a tiny bit less mainstream, so you have something to think about over Easter.
I'll show you four innovative programming languages and briefly introduce their concepts. And not silly ones like Whitespace or Brainf**k. Serious ones, pushing the boundaries, truly innovating. I won't name them now, to not spoil the surprise. I can't guarantee it, but I think there’s a very good chance that there's going to be at least one you've never heard of, but that will capture your interest.

Das Schreiben von Dokumentation ist ein leidiges Thema: Verschiedene Werkzeuge, die Zusammenarbeit im Team oder die Integration in den Arbeitsalltag hindern uns oft daran, überhaupt damit zu beginnen.

In diesem Tutorial zeige ich Euch den Ansatz, den wir beim iSAQB für die Erstellung unserer Lehrpläne entwickelt haben. Ihr lernt die Grundlagen von asciidoc und asciidoctor kennen und arbeitet Schritt für Schritt an einer Verfeinerung des Erstellungsprozesses. Das Ziel: Am Ende haltet Ihr ein ansprechendes und professionell gestaltetes Dokument in den Händen – und habt das Know-how, Eure eigene Dokumentation effizient zu erstellen.

Das Tutorial richtet sich an alle, die technische Dokumentation einfacher, kollaborativer und effizienter gestalten möchten. Es ist praxisnah und interaktiv – bringt also gerne Eure Fragen und Herausforderungen mit!

One of the intriguing features of Swift is its distinction between value types and reference types. Conceptually, value types are always copied in assignments and passed-by-value in function calls — i.e., they are semantically immutable. In contrast, for reference types, Swift only copies a pointer to an object on an assignment and they are being passed-by-reference to functions. If such an object gets mutated, it changes for for all references. While most languages feature both value and reference types, Swift is unique in that (1) it makes it easy to define and use both flavours of types and (2) it supports fine-grained mutability control.

For large values, such as arrays, frequent copying carries a significant performance penalty. Hence, the Swift compiler goes to great length to avoid copying whenever it is safe. For large values, this effectively boils down to a copy-on-write strategy, where a large value is only copied when it actually is being mutated (on one code path). Swift facilitates for user-defined value types to also adopt this copy-on-write strategy.

In this talk, I will explain the semantic difference between value and reference types, and I will illustrate how this facilitates safe and robust coding practices in Swift. Moreover, I will explain how the copy-on-write strategy for large values works and how it interacts with Swift’s memory management system. Finally, I will demonstrate how you can define your own copy-on-write large value types.

I'm a functional programmer at heart, and believe that the declarative semantics of functional programming are vastly superior to the kind of OOP we've been doing for the past 30 years. In most cases, that means based on imperative concepts, with some class, inheritance and subtyping structure added. And, as we will see in this talk: Subtyping polymorphism is not very good at avoiding
unsafe type conversions, inheritance is not very good ad code reuse, and classes are not very good at being extensible.

When it comes to building larger systems, however, we can get back to the ideas and concepts that drove the invention of Object Orientation: Independent entities that encapsulate and hide their own state, that communicate via message passing, and that can be exchanged at runtime without having to replace the entire system. And I'd argue that most of the systems we build today actually follow these concepts – in a good way! And in that sense, I believe that Object Orientation is actually a good and successful concept – just not on code level, but on a system and infrastructure level.

In this talk, we’re going to explore the history of the term “Object-Oriented”, how that concept evolved, where it went wrong, and how to redeem it.

Based on my experience as Tech Lead, I recap the successful path my team took to modularise a monolithic React frontend - without micro frontends. The goal was to scale the software development of the frontend to multiple teams.

Starting from a monolithic architecture and a Git Flow integration and deployment process, we modularised the code incrementally and also made significant progress towards Continuous Integration / Continuous Deployment (CI/CD).

It was important to never hinder the continuous development of new features therefore we favoured incremental refactorings over big bang approaches.

The technology-agnostic approach of the talk focuses on the principles of incremental refactoring. Particular attention is paid to creating the conditions that allow different teams to work on the same code base at the same time.

With this experience report, I want to encourage Tech Leads and Software Developers to approach refactorings incrementally and not to view architecture decisions in a binary way. You will also get tips on tooling and how to guide incremental refactoring organisationally.

An introduction to Functional Reactive Programming and a tutorial on building Android, IOS or web apps using Haskell, nix and the Reflex FRP libraries.

Programming with weak consistency guarantees is both a necessity and a pain. It is a necessity, because more and more platforms opt for weak consistency guarantees or even give the developer means of influencing the consistency guarantees. It is a pain, because well-known idioms for synchronization and communication break if the consistency guarantees are chosen too weak.

Since its proposal in 2010, the programming language CAT has become the de-facto standard for formulating consistency guarantees. The Linux kernel, the languages C, C++, Java, and OCaml, the architectures of ARM, Intel, and IBM, as well as NVIDIA and Vulkan all have their consistency guarantees formulated in CAT.

We introduce Dartagnan, a formal verification tool that helps the programmer reason about the behavior of a given (C or SPIR-V) program relative to given consistency guarantees (formulated in CAT). Dartagnan checks whether all consistent executions meet all assertions in the code, reports bugs otherwise, or terminates without a conclusion. Dartagnan is a bounded model checker that unrolls the program into an acyclic form and translates it into logical constraints that are solved with an SMT solver, like Microsoft's Z3 or Yices.

Dartagnan has been instrumental in finding a bug in qspinlock, one of the major lock implementations of the Linux kernel, a development that ultimately lead to new consistency guarantees for the Linux kernel.

This year marks the 25th anniversary of QuickCheck, the canonical property-based testing library that has found its way into virtually every programming language in different forms. In these 25 years, the implementers of these new libraries, along with the research community, has made significant advances to Property-Based Testing literature, transformed the way in which we see PBT, and continue to do so. In this talk, I’ll present to you the challenges that have been solved, and the ones that aren’t. I’ll present you with the latest advances that haven’t been incorporated into existing libraries, talk about our work with my collaborators on opening new avenues for the future of property based testing, and share my vision of what the future shall bring to us.

In den letzten Jahren hat das Strategische Design aus DDD einen enormen Zuspruch gewonnen, was auf jeden Fall gut und wichtig ist. Aber das bedeutet nicht, dass wir das Taktische Design von DDD vernachlässigen sollten.

Für diesen Vortrag beginnen wir mit einer starren und fragilen Codebase, wie sie häufig im Laufe der Jahre entsteht. Wir führen Schritt für Schritt Refactorings durch, wobei wir den Supple Design Strategien (supple: englisch für “geschmeidig”) aus DDD sowie anderen bekannten Refactoring-Patterns folgen. Dabei führen wir Value Objects, Entities und weitere Elemente des Taktischen Designs nach und nach ein. Dies erlaubt es uns, die Codebase klar zu strukturieren, so dass Änderungen schnell und leicht möglich sind und das Arbeiten mit dem Code wieder Freude bereitet.

Tired of firefighting when a downstream service throws a curveball? We were too, so we figured out a way to build microservices that expect the unexpected. In this talk, I'll share our journey from fragile systems to an architecture where resilience is the norm, not the exception.

Get an honest glimpse into our early microservices struggles – how our initial approaches led to chaos, and the breakthrough architectural pattern that changed everything.

This talk isn’t just a war story; it’s a blueprint for resilience. You'll walk away with a crucial pattern that you can immediately apply to your systems, turning potential disasters into manageable events, and achieve a 99.999% uptime.