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.

Scala 3 was introduced last year. It introduced significant changes to the language, many of which were motivated by the lessons learned from the past 15 or so years of actual use in many open-source and commercial applications.

I'll explore these lessons and how Scala 3 addresses them. Many revolve around the pros and cons of implicits. Also, changes to the type system make it more "regular", robust, and expressive. Finally, the new, optional, and controversial "Python-like" syntax promotes even more brevity. It also acknowledges how influential and pervasive Python has become across our industry.

But there are many practical areas where future work is required, many of which are larger than the scope of Scala itself. We still live in "dependency hell". We still use too many obsolete idioms that hide accidental complexity, rather than forcing us to fix it. What should we do about these issues? 

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 :)

In the front-end world, we finally can take an important decision: Familiarity or Guarantees?

Do we keep using frameworks that are familiar to JavaScript (bringing with them all JS idiosyncrasies) or do we embrace a world of guarantees where functions are pure, data is immutable, types are correct, and runtime exceptions don’t exist?

In Rakuten, we went the way of guarantees three years ago, choosing Elm.

In this talk, I am going to explain what are the benefits of Elm in the front-end, and what was our experience.

I will showcase examples, best practices, things that we liked, and things that we didn't like.

Many Java developers believe that FP arrived in Java 8, with the addition of first-class lambda expressions and the Streams API. But is this really true? In this talk, Ben Evans will talk about what FP really is, examine whether Java can really be said to be FP or not - and consider whether things have improved with more recent versions, as well as some possibilities of how we could have done things differently (in another world).

The Chunk data structure powers the fs2 (Functional Streams for Scala) streaming library. In this talk, we’ll look at the design of Chunk and in particular, how design constraints guided its evolution.

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.

A Metric-driven approach to reduce Cognitive Complexity in a code base, using Functional Programming, demoed **hands-on**, by solving a complex real-world ubiquitous design challenge - REST API Bulk Request Validation, with an extensible Framework that separates what-to-do (Validations) from how-to-do (Validation Orchestration). Let's do a case study of a successful implementation done by our team in the world's largest SaaS org, _Salesforce_, through our in-house baked FOSS library **Vader**.

Doordash recently made their software engineers deliver food to better understand how the product works. https://twitter.com/briannawu/status/1475953356644532230

Likewise, organisations that hire junior engineers should also explore into teaching/mentoring to better understand how to not just build a team but to create a self-sustaining legacy.

Over the last five years, I have taught programming to six people. The most consciously intentional effort being in the last eight months, where I taught programming to an experienced individual from a field that is completely unrelated to Computer Science. https://otee.dev

In this talk, I wish to summarise my findings about what I thought would work, what actually worked, and what I could improve on in hindsight.

It is also a critical appreciation of how functional programming concepts play a role in expediting the learner’s journey, even though it’s hard at first.

Lastly, I also wish to introspect on how the act of teaching has changed the way I think: primarily on how teaching has made a better engineer at my day job. 

Footnote: Learning by teaching, oddly resembles the metacircular evaluator popularised through SICP.

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.

At Microsoft, Phillip worked on the F# language and tools from 2016 to 2021. In this talk, Phillip will recount the various strategies he and his team used to try and increase adoption of F#, and by extension, FP as a whole. Over this period of time, the F# language evolved and grew its user base substantially.

Lots of experiments to increase adoption were tried, such as pivoting to data science, and most failed ... but some succeeded, hinting at some paths to adoption for FP that don't just involve a more mainstream language appropriating FP features. If you're interested in storytelling, learning about fun ways things failed, and curious about some things that succeeded in increasing adoption, check out this talk!

Haskell is known for its cutting-edge type system. All the major developments of the language are related to types today: Linear Types, Dependent Types, deep type-level features for enhancing ADTs. The language has taken the path of a trendsetter in this field, and many other languages derive their ideas bit by bit.

What else Haskell is known for is the lack of understanding of how to use these complicated features in practice. What real tasks the type-level Haskell solves better than usual approaches. How to apply this rich world to day-to-day work. And what are the drawbacks of this type-level fanciness?

My talk continues developing the methodology of pragmatic Haskell that I call Functional Declarative Design as I first introduced it in my book Functional Design and Architecture. I’ll present a couple of ways to build useful type-level eDSLs and will show the use cases of many important type features of the language. This is not just my voluntary exploration of the depths of Haskell, but rather a practical material one can take and solve own problems with the full understanding of the consequences. This will be a part of the material I’m preparing for my second book, Pragmatic Type-Level Design. 

How do we start introducing functional constructs into a OOPs heavy project, without overwhelming the other developers? In our attempt to drive functional programming adoption, we tried to show how the existing OO patterns in the project and are inherently subsumed in a functional paradigm. This helped to make the concepts relatable and in due course increased adoption.

Here we want to share our learning and show how most popular OO patterns can be expressed in a functional way.