Loops are among the most critical programming constructs. These features shape core ideas about programming in the Erlang ecosystem; from how languages work to how programming features interact with other code and the outside world. How systems scale and are resilient. They are also metaphors for the way we think, build things, and grow. In Erlang and Elixir, loops define servers that form reliable, fault tolerant and scalable services. This keynote will explore Elixir and Erlang's approach to concurrency with a nautical adventure called the Great Loop.

This talk dives into the origins of functional programming, going all the way back to where the term was first introduced, to see how it evolved over time into our modern understanding of what FP essentially involves.

With polymorphic functions you can often tell how they are implemented by looking at their outputs. The more polymorphic the function, the more you can tell about its internal workings. Lenses, as well as more general optics, have convenient polymorphic implementations in terms of functors and profunctors. But under layers of abstractions they are hiding some simple truths. We are going to get to the bottom of this conspiracy.

Don't ask what you can do for your testing library, ask what it can do for you! So what can it do? It turns out that much more than displaying a nice green and red report. What if we make the library generate the test data? And while we're at it, maybe it could also think of the edge cases for which our code is wrong? Oh, and when it finds them, it should simplify them a bit before returning to us, so that we can quickly identify the root cause of the problem. And repeat that a thousand times, just to be sure. Sounds good? That's exactly what property-based testing has to offer. I'll show how to get started with this kind of testing, using jqwik (https://jqwik.net/) as an example. But isn't it all too good to be true, surely there's some fine print? Of course there is. I'll cover that as well.

Web services are typically stateless entities, that need to operate at scale at large. Functional paradigm can be used to model these web services work and offer several benefits like scalability, productivity, and correctness. This talk describes how to implement Event-Driven Microservices in functional programming languages with examples in F#.

Immutability allows infinite scalability as it eliminates the need to worry about a mutex, a lock, or a race. As functional code is much more terse compared to object-oriented code, it provides productivity benefits. Its strict typing makes writing correct code easy as mismatches of types are caught at compile time.

The objective of the talk is to show how to create a scalable & highly distributed web service in F#, and demonstrate how various characteristics of functional paradigm captures the behavior of such services architecture very naturally.

Some people even say names don't matter. While it is widely held that good naming is one of the most important aspects of programming, is there such a thing as an objectively good name?

As part of a discussion of the philosophy of programming, we'll look at what are the real aims of naming things well, and what considerations we should have in mind when discussing them. We'll have a look at alternatives and what they bring that names do not.

When I say "Multiplayer online game development in Clojure" 2 questions probably pop right up : WHY? HOW?
Why? because you can do it in under 100 lines of code, and it is pure FUN.
How? Well that's exactly what we'll talk about in this session.
I will present a simple MOG written in Clojure and go through each line of code - so you'll understand how you can do that yourself, even if you've never written a single line of Clojure before.
Whether you’re a real Clojurian at heart or just interested in hearing a talk about Clojure from a sworn star wars fan - this talk is for you :)

You may be familiar with what map, filter, and reduce do. But have you ever heard how these functions sound?

The Alda language is centered around the idea that music can be represented as data. alda-clj is a Clojure library that maps Clojure data structures to the music theory concepts in the Alda language, including notes and chords. The library serves as an interface that takes Clojure code as input and produces music as output.

In addition to the basic functions that you will find in the standard libraries of most functional programming languages, Clojure's standard library offers a wealth of interesting and useful functions that facilitate working with immutable data. In this talk, we will explore the Clojure standard library by applying interesting functions like cycle, mapcat, partition and reductions to transform data that represents music. Using the alda-clj library, we will not only see the result of each function call, we will also hear the results and observe how they can help us understand how each function works.

Have you ever experienced vendor lock-in from your observability tooling? Don't you wish you could instrument your code once and send telemetry data to multiple vendors to see what their platforms have to offer before signing a contract and investing a lot of engineering time?

The future is now, with OpenTelemetry!

OpenTelemetry has finally reached general availability, with the Erlang and Elixir library leading the way as one of the first official implementations to be compliant with this new industry specification. Now is the time to start thinking about how to get your services instrumented using this exciting new vendor-neutral instrumentation.

This talk will quickly cover the basics you need to know to get started and send data to both open-source tooling and vendor platforms, so that you can get the observability you need, without being locked into a specific vendor's instrumentation library!

Quantum Computing is all the rage these days, but, as an emerging technology, it's difficult to find practical applications right away. One area which allows us to invest in a quantum future is to use quantum- and nature- inspired optimization algorithms, which can run on classical computing infrastructure today and leverage quantum hardware when it is available.

In this talk, I'd like to give a short overview of the state of the art in quantum computing, and introduce two widely used optimization algorithms made better in F# with functional principles.

Fable is an F# to JS compiler that has been successfully used in production by thousands of developers for more than 5 years. Thanks to steady improvements and a great community and ecosystem, including the SAFE stack, the Elmish architecture and the Feliz React API, it has become one of the best options to write robust, succinct and performant web applications nowadays.

Fable was originally designed to integrate F# with the JS ecosystem instead of trying it to hide it. With this same philosophy, the Fable team is working now to target other languages beyond .NET and JS. There are already working prototypes to compile F# into Php, Python and Rust code, and we expect to release a beta in the upcoming months. Let's see how Fable 4 will further empower F# and functional programmers!

Typescript has gained a lot of traction with majority of javascript frameworks adopting it and gaining the power of static types.

Given the Typescript types are a language themselves and they are Turing complete, lets put our type flavoured favourite language of the web to test - for fun & profit.

With the advent of fp-ts, typescript's boundary to statically type FP algebras like Functor, Monoid & Monad are just a import away!.

But why restrict ourselves when we can achieve more with almost "Dependent types" in typescript - Like solving logical puzzles to proving properties of the program (like type level regex check, indexed list & matrices etc) for correctness.

What do you do with a multi-step function with different kinds of user input that may be required at different steps? 

I'm using Elm to build a game client for Codex, a complex strategy board game by David Sirlin with lots of interesting side effects in the game design. The pure functional programming of Elm is very powerful for managing these side effects, but how should I handle when there are many different kinds of user input required to complete the behaviour of a single feature?

There’s a “railway oriented programming” metaphor to understand how to handle multiple-steps of errors. I’ll extend this metaphor – with stations – to show how to make what looks like a complex functional problem into a simple pattern of abstraction.

Some familiarity with functional programming idioms is recommended, though the examples themselves are easy to follow. Attendees will walk away seeing functional programming applied in a fresh way, perhaps opening their mind to alternative perspectives to approach the complicated problems in their projects.

This talk will introduce the audience to algorithmic trading, the design of an algorithmic trading system, and various snippets written in Kotlin that fulfil specific tasks that collectively contribute towards a full trading system. The rough sketch will be as follows

The biggest power of functional programming comes from the ability to treat functions as first class objects and the power to compose them incrementally to evolve larger functions out of smaller ones. Designing such functions as referentially transparent enables us to treat functions in programming just like functions in mathematics - side-effects are carefully abstracted through “effects” and delayed till the algebra of our program gets submitted to the run time system.

In this talk I will discuss a few idioms and patterns on how using the power of composition can lead to development of modular abstractions. Instead of committing to an implementation prematurely we can define abstractions that focus on “what” it does deferring the “how” part to later stages of the lifecycle. In functional programming terminology we call the “what” part the algebra of our abstraction, and the “how” part the interpreter. Decoupling the two is one of the basic recommendations in functional programming. 

I will use Haskell and Scala for the examples. I will discuss common functionalities that we use everyday in programming our domain models like validations, database interactions, managing exceptions, talking to external services etc. and show how to use the power of typed functional programming to make them more compositional.

Is functional programming for experts? We have found that children learning programming also benefit!

Over the last 5 years, we have taught 25K children through the McMaster University’s outreach program McMaster Start Coding (Canada), and started training undergraduates from peer institutions, including Vellore Institute of Technology, Cihan University (Kurdistan), and Narasu’s Sarathy Institute of Technology (India), so that they they can create their own programs.

Our main motivation for teaching functional programming to children is the similarity between algebra and functional programming. Algebra is a barrier to secondary and postsecondary education, and helping children overcome this barrier can have a huge impact.

We continued to develop our program because both children and teachers loved it. Children find it easy to learn about functions when the functions draw shapes on their screen using a compositional language they find easy to learn. Teachers love it, because children immediately understand concepts including Cartesian coordinates which are difficult to motivate for some.

In this talk we will explain the design philosophy behind our open-source graphics library GraphicSVG for Elm, and why we think Elm (with pure functions, and well-typed standard library) is the best language to teach 10- to 14-year olds.

We will give you a toolkit for advocating functional programming in your local schools, and show what children can create, including children from Vikas School in Hyderabad who were isolating at home with only a smartphone to learn programming on.