You know how to code in Elixir; now learn to think in it. Learn to design libraries with intelligent layers that shape the right data structures, flow from one function into the next, and present the right APIs. Embrace the same OTP that’s kept our telephone systems reliable and fast for over 30 years. Move beyond understanding the OTP functions to knowing what’s happening under the hood, and why that matters. Using that knowledge, instinctively know how to design systems that deliver fast and resilient services to your users, all with an Elixir focus.

Elixir is gaining mindshare as the programming language you can use to keep your software running forever, even in the face of unexpected errors and an ever-growing need to use more processors. This power comes from an effective programming language, an excellent foundation for concurrency and its inheritance of a battle-tested framework called the OTP.

If you’re using frameworks like Phoenix or Nerves, you’re already experiencing the features that make Elixir an excellent language for today’s demands. This book shows you how to go beyond simple programming to designing, and that means building the right layers. Embrace those data structures that work best in functional programs and use them to build functions that perform and compose well, layer by layer, across processes. Test your code at the right place using the right techniques. Layer your code into pieces that are easy to understand and heal themselves when errors strike.

Of all Elixir’s boons, the most important one is that it guides us to design our programs in a way to most benefit from the architecture that they run on. The experts do it and now you can learn to design programs that do the same.

This full day workshop will focus on applying Haskell to normal, everyday programming. We'll be focusing on getting comfortable with common tasks, libraries, and paradigms, including:

• Understanding strictness, laziness, and evaluation
• Data structures
• Structuring applications
• Concurrency and mutability
• Library recommendations

By the end of the workshop, you should feel confident in working on production Haskell codebases. While we obviously cannot cover all topics in Haskell in one day, the goal is to empower attendees with sufficient knowledge to continue developing their Haskell skillset through writing real applications.

This session is an whirlwind tour of the FP land and is primarily meant for developers wanting to embark on their functional programming journey. We will use Java to understand most of the concepts, however, where it falls short to explain certain concepts, we will use Scala or Groovy or Clojure or even Haskell to demonstrate it. Starting with the basics - introducing the concepts with examples, we will evolve our understanding to take the mystery out of the monads (hopefully!)

Startups and web developers take note. Phoenix LiveView is the revolutionary framework that allows rapid development of real-time web interactive applications without custom JavaScript. You read that right the first time, and the Elixir community is buzzing. So far, the performance numbers have been nothing short of earth-shattering.

In this session, you’ll see how it all works. We will do some live coding to show you LiveView under the hood.

We will be spending the day learning the fundamentals of Functional Programming (FP) using the Haskell programming language. The exercise material will be a condensed selection of the NICTA/course which is regularly held in Australia over three days.

This one day session is targeted to experienced industry programmers who are looking to break into Functional Programming and develop the rudimentary skills and techniques that enable continued independent study. A refresher on Haskell syntax will be provided, however, it is highly recommended to practice with the syntax and development tools prior to obtain the best outcome for the day.

You will be required to bring a suitable development machine (portable) for working through the exercises. You will also need to install Glasgow Haskell Compiler (http://www.haskell.org/ghc/) version 7.8 or higher on that machine prior to the day.

Going from Java to Erlang is not hard if given proper support. This talk is about the roller coaster journey with Erlang to build a scalable, soft real-time transaction platform. If you are a Java developer struggling to understand and adapt to Erlang this talk is for you.

Intuitive collections types can certainly help developers positively in terms of increased developer productivity and higher readability. As a developer on JVM you have plenty of options from the community. In this presentation, I compare three popular collections libraries - Eclipse Collections, Java Streams API, and Vavr. I present the code examples using all the three APIs. I firmly believe, there is no one library that is perfect for all situations. Hence we compare these libraries along the dimensions of mutability/ immutability, eager/lazy evaluation, richness of expression, error handling aspects. By the end of the presentation, we identify the strong areas for each of these APIs.

Have you ever wondered what happens beneath the covers when you talk to your Database? Well, you are in for a treat! In this talk, we are going to uncover the dark magic behind Database Drivers. We will look at everything that is needed to talk to a database, query its data and transform it into the native data types in Elixir.

Pattern Matching and Destructuring are two simple, yet powerful features in functional programming languages. There are several ways we can leverage them to make cleaner code. It also encourages you to think data as a first-class citizen and provide the essential tooling.

In this session, we are going to learn what these techniques bring to the table by looking at some real-world use-cases in Kotlin & Clojure.

If you are writing a stateless web application backed up by a database, there is a good chance Elixir is a great fit. However, this is not where it shines. In this talk, we will discuss how to architect Elixir applications in order to leverage the features of the language and of its runtime.

In this session, we will look Currying and Partial Function Application (PFA) in Functional Programming. Languages like Clojure don't have currying, but PFA, where has Haskell currying and not PFA, whereas Scala has both, Groovy wants you to call methods like curry() and rcurry(). In OO paradigm, we use DI (dependency Injection) and we will see how this is automatically subsumed using Currying and PFA.

One of the strategies being adopted by RoR or Java software developers in adopting Elixir is they have not yet adapted themselves to unlearn the OOP in developing the web systems. This has caused OOP concepts to creep into full fledged Elixir systems. This presentation seeks to highlight these subtle points that need to be avoided to make the code more FP and less OOP.

Language interoperability is the capability of two different programming languages to natively interact as part of the same system. Interoperability is advantageous because different programming languages are optimized for specific tasks, and allowing them to communicate can create better systems.

Apart from the Java language, the most common or well-known JVM languages are:

• Scala, a statically-typed object-oriented and functional programming language
• Clojure, a modern, dynamic, and functional dialect of the Lisp programming language
• Kotlin, a statically-typed language

In this session, we'll demonstrate how your program can interop with different JVM languages.

'Let it crash' gets thrown around a lot in the Erlang community. An experienced
programmer (with understandably different experiences) on first encountering
this idea in Erlang is often found asking what we let crash? And what happens
after?

I will attempt to answer this question.

Erlang puts distributed systems programming ideas front and center. We'll also
talk about this in the context of letting processes crash and how that affects the
design of our software.

Even though there was a delay; but JAVA has been catching up quite nicely when it comes to FP. With frequent releases and feature inclusions at a faster pace, the FP landscape in JAVA is becoming better and better every day. A lot of cutting edge projects(inspired by other languages like clojure, scala, oCaml, haskell, F# etc..) with their high-end/superior APIs complementing the language. The best part is these are just not syntactic sugars; the underlying impact of functional programming(from the language as well as the libraries) when analyzed deeply is extremely enriching and profound. The KPIs which can directly get a face-lift is a lot

1. Reduced dev/unit-testing effort

2. Less boilerplate code

3. Less mutation and higher thread safety

4. High perf persistent data-structures

5. Proven performance improvement, reduced allocation and higher throughput

Developers who have been practicing java/jvm languages for several years will find this really appealing and intriguing.

During the Code Beam Lite conference you might have had questions that did not get answered, this is your opportunity to get them answered by our expert panel group

We'll take a close look at core.async - the CSP library for Clojure(script).

• The motivation
• Problems suitable for CSPs to handle
• Syntax
• Patterns

Given the minimalist nature of Lisps, the syntax is underwhelming, but applications can be exciting in the manner they make complex problems within reach.

I've been working on a logic programming framework in Haskell, called guanxi (關係) with an eye towards scalability. To build it I leaned heavily on my previous work on propagators and a bunch of other little bits and pieces of algebra and category theory in the design process. A number of patterns have arisen repeatedly throughout the process of building this library. I'll give a tour through the current state of guanxi and try to extract some of the more reusable bits of its design for your inspection.

Haskell's Web Application Interface (WAI- pronounced "why") provides an abstraction between web applications and web servers. This allows many different web frameworks (e.g., Yesod, Spock, and Servant) to share servers like Warp and middlewares.

Haskell's web frameworks offer a wide variety of feature sets, type-level and metaprogramming, and intended use cases. And for most use cases, I would recommend using an existing web framework, which will help you avoid common pitfalls and more quickly address common use cases.

But not today! In this tutorial, we're going to step through building a functioning web server using just the bare-bones WAI interface and Warp as a server. Familiarity with the basics of Haskell will be a plus, but this will be a talk open to all FP and Haskell skill levels.

Bolero (http://fsbolero.io) is a functional, reactive web development library for F# developers targeting WebAssembly via Blazor. Next to building on a familiar Model-View-Update (MVU) architecture, Bolero also integrates a number of power features from WebSharper (http://websharper.com) to enable ultra-efficient, full-stack F# web applications. By plugging into the ever-growing Blazor ecosystem, you will enjoy developing most of your code base without JavaScript, and discover a new and promising alternative to building performant web applications. Come to this talk and learn everything you need to know about developing Bolero applications, and jumpstart your productivity with skills that will leave any Blazor developer impressed.

Have you ever wondered how we can build a real-world, production-ready, end-to-end application using the functional programming principles? Immutability, Pure Functions and all other functional programming things sound good on paper but How can we build something useful by applying it?

At Ajira, We recently built an e-commerce marketplace middleware in Clojure for a leading retail chain to sell their products on multiple e-commerce sites seamlessly. In this case study, we are going to build a minimal version of this project using which I will be sharing how we implemented it.

In this talk, we go back to first principles, defining and examining the definition for a cons list, then take a look at the ubiquitous right and left fold functions on a list.

The primary focus of this talk is to develop an intuition for how these functions work so that we can best decide when to apply them. Multiple programming languages will be used to help emphasise the independence of the gained intuition. This talk will generally be interactive with the audience as we solve problems and build confidence in our new knowledge.

Knowing how to apply the various list fold functions is a common question by the student of FP. This talk aims to provide a solid, reliable answer to this question. No prior understanding of list folds is necessary.

This is an experience talk from my work with NRK, the

Norwegian Broadcasting Company, Norway's public broadcaster.

Over the last 3-4 years we've taken the TV and radio streaming sites from a monolith to multiple

domain based services. We'll look at how we've transitioned the from a pure object oriented development team to a function friendly organzation, how gorwing the organization forced us to work with Conways law, as well as a deep dive into the bounded context of personalization.

Keeping track of user progress and favorite shows is the responsibility of Personalization domain, with high performance requirements and surprisingly

complex business rules. With new business rules and changing architecture, Personalization was in dire need of work. Combining FSharp and its typesystem and immutability with Orleans, an open source Virtual Actor platform for distributed high-scale computing applications, provided us with functional programming with OO principles in a fast and scalable platform. I'll show why we chose this path, the benefits we gained going from C# to F# and some of the lessons learned building on an actor model.

Overview

IOT is ubiquitous now a days. With time series data pouring in from all possible sources, there is an increasing need to process the data at near real time. However, the transmission, storage and compute cost associated with this data is ever increasing.

Functional Data Structure for Time Series

In this talk, we will look at functional implementation of discrete wavelet transforms implemented using Haskell. We will use Haar wavelets for the the demo. The high and low pass filter definition of a wavelet allows a very simple functional implementation of Haar wavelet transform.

Wavelet Transform

We will look at simple recursive definition for forward and reverse wavelet transforms. The wavelet transform is very simple to implement in O(N) time complexity using recursive definition, and higher order functions.

Wavelet as a Container

Though, these transform functions are good for bulk transform i.e. to convert incoming data to/from wavelet space at once, they are not good for point queries. We will look at how we can partition a wavelet vector in dyadic ranges, and dynamically construct orthonormal basis of the wavelet by directly querying only log N coefficients.

Wavelet Approximation

The wavelet container that we constructed can be sparse. i.e. it is possible to prune the coefficients that are not contributing to approximation, and still use the wavelet container.

Wavelet Sketching

Sketches are random algorithms to estimate the result with a given accuracy with high probability.

We can use sum-of-square energy function property to prune the coefficients. Finally we use sublinear AMS sketching algorithm to predict the energy, and prune the coefficients efficiently in log N time rather than O(N) time. This allows us to quickly prune the wavelet container by getting rid of large number of coefficients. This allows very compact representation of the time series data that allows point queries.

We show Haskell implementation

• Sketch as a class, and linear properties of Sketch
• Implementation of AMS using hash functions, and probability distributions
• Using AMS with hash bucketing to prune wavelet coefficents

Use Case

We will look at a historical stock data, and use wavelet transform and sketching to reduce the data size.

Current Status

Currently being studied at my organization, such functional application is found to be useful in representing data for quick analytics.

What scares the Shell out of people?

Artefacts of the long and idiosyncratic history of Unix.

We have so many powerful, stable, widely-available Unix tools and standards, but also plenty of inconsistencies, variants, and arcane caveats; enough to help us... surprise... ourselves in creative new ways. See that cliff you're currently falling off? Yeah, someone went down that road when you were still eating chalk in kindergarten. (Or perhaps you fell off it once before, when I was eating chalk in kindergarten, but it was so long ago that you forgot you've been there done that :-))

Worse, there's no adult supervision, only user manuals. Within Shell's neon-lit environs, one must learn to tread with care, creativity, and cool calculation.

One must learn to accept the silent echo as reward for success.

Why go to Shell at all?

Several of us already get by just fine with a few memorised spells from Shell. That's not a bad way to live, but we miss out on tremendous everyday value that we can unlock with the Unix way.

For there exists a vast no-man's land between memorised tricks and large scale "designed" solutions; wherein no single software tool can really solve all the problems we encounter.

Yet, any modern *nix PC has all one needs to adequately and speedily tailor-make solutions for almost any problem we may encounter in the underserved no man's land.

Solutions that we can use effectively until we truly hit the kind of scale problems or domain complexity that merit use of specialised tools.

Unix nature is deeply Functional

The Unix tools philosophy naturally leads to functional architectures that can scale almost effortlessly. And functional programmers could do worse than learn to exploit such power.

I'll just leave you with Douglas McIlroy's answer to "Read a file of text, determine the n most frequently used words, and print out a sorted list of those words along with their frequencies.", as seen in More Shell, Less Egg:

tr -cs A-Za-z '\n' |
tr A-Z a-z |
sort |
uniq -c |
sort -rn |
sed ${1}q

A purely functional, automatically buffered data processing pipeline, built with standard reusable parts, written in 1986, directly usable on today's computers.

Imaginative Functional Programmers (aren't we all?!) will find striking parallels between the facilities, concepts, and design principles available in their $Langs, and their *nix environments.

No surprise, because in the dreamy mists of time, the wise hackers of Unix lore, and SmallTalk lore, and APL lore, and Lisp lore, and Forth lore etc... were all different, but they were all together, too.

OCaml is a multi-paradigm programming language with a pragmatic mix of functional and imperative programming features. OCaml, which has been around since 1996, has grown to be a battle tested language, widely deployed and used in production systems. In this talk, we will look at the support for Generalized Algebraic Data Types (GADTs), a powerful generalization of the more mundane Algebraic Data Types (ADTs). We will start with an example of building an interpreter for a small language and add type safety through GADTs. We will then look at a few powerful type-safe design patterns that GADTs enable.

UPDATE: Please setup https://github.com/ajnsit/purescript-react-starter (follow the instructions in the README) on your laptops as a **prerequisite**.

Purescript is a purely functional, strongly typed language, that compiles to Javascript.

It provides several high quality libraries for frontend development, and comes with excellent tooling and editor support that makes writing code a snap!

In this talk I will provide a quick introduction to some basics of Purescript, and then dive into an interactive demonstration of building a non-trivial web application from scratch. I will show how to interface with React bindings, and how to interface with some existing Javascript libraries (a React UI component lib).

The presentation will be interactive and similar to an inpromptu talk I gave which is linked below. However, I will also demonstrate live coding of an actual purescript application which people can follow along.

Bring your laptop to follow along.

Over a period of 7 years, we have applied Haskell across Web apps, compilers, parsers for our customers across various industries. This is our report on how some of the unique features of Haskell have not only helped us create stable production environments but also break barriers. On the other hand, there is a high cost of on-boarding new developers and few other pain points. So, is Haskell worth the investment?

Overview: Streamly is a Haskell library for writing programs in a high level, declarative data flow programming paradigm. It provides a simple API, very close to standard Haskell lists. A program is expressed as a composition of data processing pipes, generally known as streams. Streams can be generated, merged, chained, mapped, zipped, and consumed concurrently – enabling a high level, declarative yet concurrent composition of programs. Programs can be concurrent or non-concurrent without any significant change. Concurrency is auto scaled based on consumption rate. Programmers do not have to be aware of threads, locking or synchronization to write scalable concurrent programs. Streamly provides C like performance, orders of magnitude better compared to existing streaming libraries.

Motivation: Haskell has a beautiful abstraction capability. Haskell lists, several streaming and concurrency libraries are some examples of good programming abstractions. The problem is that concurrency is not handled elegantly and declaratively by these libraries. Moreover, the lack of good performance gives rise to special purpose performance centric libraries like text and bytestring creating more confusion. Streamly unifies, lists, streaming, concurrency, logic programming and reactive programming with unparalleled performance. We can finally have a unified string handling.

Audience: Streamly is designed to express the full spectrum of programs. Do not think that if you are writing a small and simple program it may not be for you. It expresses a small program with the same efficiency, simplicity and elegance as a large scale concurrent application. It unifies many different aspects of special purpose libraries into a single yet simple framework. It is especially suitable for high performance and scalable backend data processing systems. If you use or plan to use any real time streaming or data flow programming frameworks including Apache Flink, Apache Spark or asynchronous/reactive programming frameworks like ReactiveX/RxJs then you may be interested in Streamly.

I got excited about property-based testing after hearing John Hughes talk at Functional Conf 2016. I tried it that year with QuickCheck, but failed miserably (it almost derailed the entire project delivery). I cribbed about it in my talk at Functional Conf 2017. In 2018, Srihari's talk got me excited again. This time, I tried with Hedgehog, and got it to work!

This talk is about this journey and its learnings. We'll talk about how Hedgehog was used to test [1]:

• A Postgres backed task/job queue
• A small Wai/Servant based webapp

And no, we will not talk about the most common (and completely useless) example of reversing a list!

[1] Both of these are part of an open-sourced task/job queue library.

C++ as a Programming Languages had ruled the programming world for quite some time. It was so much synonymous to Object Oriented Programming that when functional programming came into the picture, nobody initially thought of C++ as a candidate for the same.

Fortunately, the C++ Standardization (isocpp.org) committee had a different idea and they later came up with C++11 which was a paradigm shift in the language. C++ now not only allows programmers to write functional code, but it has also evolved the language into a meta programming language.

The core of these changes which enables functional programming in C++ revolves around the introduction of Lambdas. Suddenly, with lambdas, we’re not only writing functional code in C++ but can also have functional threads, functional locks, and functional memory management.

The beauty of lambdas can also be judged from the fact that it has also made many of the STL (Standard Template Library) algorithms functional which, along with the concepts and ideas of Closures makes C++ an ideal candidate to be considered for writing functional codes which includes immutability, Partial function specialization, and pattern matching.

In this talk, I’ll take you on the journey of functional Programming in modern C++ and how to write awesome and simple C++ code which conforms to all tenets of Functional Programming.

The talk shall contain full fledged examples which shall be made available to participants post conference

We’ll also see how the language has evolved and why it’s still a favorite for doing performance intensive jobs which we can, of course, do in a functional way

Programs are getting fat. They're becoming slow. They're taking up more computing resources. They're getting harder to maintain and more complex from the ground up. Layer upon layer of sophistication is causing us to lose our ability to predict what software will do. Where's that bug? Why is everything going so slowly? Am I even using the right data structures? Where's that important point in the documentation again?

What's happened to us? In this meta-dive into the nature of our approach to programming, we will explore some of the dangers of our current approaches to programming and the how/why of our current programming obesity problem. We will look at real case studies and see just how bad the situation can be.

But we will also explore how we can battle these sources of obesity. In this passionate plea for code that we can gain control over again, we will look at examples of how we can return to a state of high-performance on all levels, from code size to code scalability. We will look at the principles that can help us to reach leaner, more efficient, more usable, less buggy code. We will hopefully find some light at the end of the tunnel, and how we can change our outlook on programming to push ourselves towards code that benefits not only ourselves, but also those that will come after us.

Many people in our industry are programmers because we're curious and passionate about coding. Each of us can remember latching onto a trivial programming problem and staying with it deep into the night. For far too many of us, that passion for programming fades under the slow, wilting heat of the day to day grind.

In this talk, Bruce Tate, author of Seven Languages in Seven Weeks, takes a frank look at the grind and offers some practical advice on putting the "fun" back into "functions". We'll introduce some pragmatic ideas to get you excited about the journey again. We can't always dramatically change our circumstances, but we can often make small tweaks to how we approach problems.

Come along. Enjoy the journey.

There are a lot of algorithms that revolve around iterating a form of information propagation until it attains a deterministic fixed point. CRDTs, Datalog, SAT solving, functional reactive programming, and constraint programming all fit into this mold.

One framework for these sorts of algorithms is the notion of a “propagator” due to Sussman and Radul, but until now little rigor has applied to know how such algorithms terminate with consistent results. Another framework is Lindsey Kuper’s work on the notion of “lattice variables” (LVars), which addresses termination, parallelism and eventual consistency well, but not iteration.

By blending these frameworks, I’ll build up a series of sufficient conditions for propagators to terminate with consistent results and proceed to show how we can use this common framework to steal insights and quirks from each individual domain to try to optimize the rest.

APL is getting a lot of attention lately due to its potential for very high performance portability and suitability for both rapid prototyping of complex solutions as well as deployment of complex algorithms to high-speed, modern parallel hardware. It has the potential to vastly improve the speed, scalability, and size of your code bases. But APL has a reputation as an intimidating language to learn.

In this back to the basics tutorial, we will explore the core of APL, and focus on those areas that usually trip up the beginner in learning APL. We will also walk you through how to approach an APL expression, how to reason about them, and how to read them efficiently. We will teach you the skills that the expert APLer has internalized, and how you can work through these skills externally and explicitly in a way that will help you to eventually internalize these critical skills in a way that makes you efficient at using APL on real world problems.

Sylvester is an F# DSL for scientific computing which implements an advanced type system where vector, matrix, tensor, neural-network and other types have numeric properties like dimension sizes, rank, layer node size, etc., encoded as part of the type. Type-level constraints for operations like matrix multiplication or network layer construction utilize the F# type checker as a type-checker for linear algebra and other mathematical domains which allows for type-level verification of mathematical operations and for Intellisense-enabled IDEs to provide immediate feedback that helps the user avoid errors in mathematical expressions..

What is a Type for a function? When can you say that a function is a sub-type of another function? Why should you even bother?

Function sub-typing is one of the most confusing areas of FP. In this talk, I'll take a deep dive and explain the core concepts of function types which applies to many different languages. More than just explaining the mere rules, I will be deriving those rules in a step-by-step fashion till the eureka moment so that you will never be confused again.

The topics covered:

1. Sub-typing basics
2. Covariance & Contravariance
3. Function sub-typing
4. Implementation gotchas in different languages (Java, Scala, Haskell, JavaScript)

The term zipper is a colloquial used to describe n-hole (most often, 1-hole) contexts. That is, a data structure that has a _hole_ or _pointer_ focused on a specific element with the ability to efficiently traverse to its neighbouring elements, providing an elegant solution for the need to efficiently traverse and _modify_ immutable data structures.

In this talk, we will look at examples of zippers for canonical data structures such as lists and other products and sums. We will then define comonads and see the relationship between zippers and comonads.

Most of this talk will be spent on the practical application of zippers in everyday programming. We will solve some simple problems using zippers. We will then contrast why we might use a zipper, compared to a lens.

Finally, for a fun and interesting observation, we will look at the algebraic structure of products and sums, then compute the derivative of these structures. Turns out, a derivative of a data structure is its zipper ("McBride, Conor, et al (2005). ∂ for Data: Differentiating Data Structures").

Most talks on APL at FunctionalConf have focused on the way array oriented programming allows you to quickly deliver concise and efficient solutions to problems with an analytical core. This talk will focus on the development environment, and follow the life of an APL code snippet from it's interactive discovery, via testing and debugging, through to delivery as a web service and a shared object, embedded into a solution implemented in Python.

Debuggers are one of the most essential tools for any kind of development.

Debuggers in Lispy languages make use of Lisp's homoiconicity. They are a bit different from debuggers for languages like C or Java.

This kind of information is usually not needed in day to day development and hence it remains hidden.

In this talk, I will take Clojure's cider-debug as an example and explain how it uses homoiconicity. Along with cider-debug, I will also talk about REPLs and how REPL client-server communication happens (with nREPL as an example).

Haskell is notoriously hard to learn. I have struggled with the learning curve. I have seen others struggle with it. And I have seen developers struggling to wield the language effectively even after months of learning.

We'll talk about five things that give Haskell this (understandably) bad rep, and how to effectively deal with them during your learning phase.

At Helpshift, we face managing complexity of these side effects which touch 10s of different systems. Each side effect poses a failure scenario which can lead to it's own business decision. Compounded failures pose even more complexity. To add to the problems we extending the codebase to add new business logic regularly.

I will present a solution which is a combination of Clojure and FP following techniques. We will also discuss how ideas when combined together can create an elegant solution,

1. Data - Side effects definition as data

2. Almost no syntax - Minimal definition

3. Many functions for one DS - Multiple execution and failure recovery modes for side effects

When it comes to developers blogging, expectations are high and many find that it’s a worthwhile effort to develop simple scripts, tools and even full engines to enhance and support blogging about their favorite language. In this hands-on session, you will implement your own blog engine from scratch in just a few hundred lines of F# code using WebSharper, and use its static file generation capabilities to generate blog pages that you can deploy directly into GitHub Pages or host in any web server. The resulting blog can easily be styled using WebSharper’s powerful templating capabilities, and even automated to rebuild when you commit new content or blog articles in your blog repository. You will also learn about adding dynamic functionality to your generated blog pages, or even turning your blog engine to a hosted solution that provides further capabilities as well. No more searching for blog engines with the right features, code what you need and enjoy!

Elixir is a modern programming language built for concurrency, robustness, and maintainability. Although the Elixir team comes from “industry” backgrounds, the history of Elixir is full of cases where the team has reached for existing research in order to solve problems arising with the language. For example, we based our implementation of a code formatter on a series of papers on pretty printing and formatting code. In this talk, I’d like to go share our learnings and experiences as a bunch of industry folks getting help from academia to approach and tackle real-world problems and come up with real-world solutions.

We take a dive into probabilistic programming, beginning with a high-level explanation of what probabilistic programming is. We then continue to see how to use the monad-bayes library for performing tasks such as regression in a bayesian formalism. We also look into the implementation of the library, which involves performing an interesting sampling method (markov-chain-monte-carlo) on a very unique space (the space of computational traces of the program). We finally end with next-steps for the haskell community to improve in the probablistic programming space, ala pyro for python

Here is our tiny re-implementation of monad-bayes, boiled down to the essentials: https://github.com/bollu/shakuni

Paper on which the talk is based on: http://mlg.eng.cam.ac.uk/pub/pdf/SciGhaGor15.pdf

Functional Programming is going through the same process of rethinking as Object Oriented Programming has passed already. FP today is not only something mystical, something barely applicable for day-to-day tasks, but rather a whole philosophy of building big, complex applications, with own tools, approaches and methodologies. We can see a lot of ideas about software design and architecture emerging from the FP community: talks, books, articles. We’re actively discussing Final Tagless, Free Monads, effect systems and other approaches, but it seems the theme not yet covered and we don’t know about possibilities we have.

In this talk, I’ll tell you about the power of Free Monads in building complex applications in Haskell and PureScript. These applications will be satisfying the requirements like maintainability, testability, simplicity. You’ll know how to create a safe concurrent application state, how to divide the application into layers and how to keep the code sane. In fact, you can do the same with Final Tagless or extensible effects, but the approach with hierarchical Free Monads has some specific properties making it the best tool to separate concerns and create a very interesting eDSLs with different semantics.

The talk is based on the ideas I’m describing in my book “Functional Design and Architecture”. I also gave several talks about this theme earlier (you can find all my talks here).

I’ve used these ideas to build software for different companies, including Juspay (Bengaluru), Restaumatic (Poland), Enecuum (Hong Kong). We’ve created several interesting technologies that were not possible to make without Free Monads. Some of them are open sourced.

We'll discuss how to use strongly typed functional programming to build a typesafe and highly declarative DSL to generate SQL, that allows better abstractions and minimises runtime errors. We'll focus on type systems, and build an intuition for row types and how it guarantees correctness for SQL. I'll cover some parts of actual SQL generation.

A similar talk was given at IIIT Delhi earlier, however that was more geared towards beginners to Functional Programming (link below). I plan to give a more intermediate level talk this time.

The type-system of Haskell is well-known as well as notorious for its rigour & strong mathematical foundations.
In this talk, we would like to explain about the recent idea of GADT's and how they help eliminate runtime checks & issues.

Our hope is that newbies to Functional Programming, and esp., Haskell are no longer intimidated by the term GADT's but instead see them as their ally in conquering some types of problems.

During the conference you might have had questions that did not get answered, this is your opportunity to get them answered by our expert panel group

Let's Lens presents a series of exercises, in a similar format to the Data61 functional programming course material. The subject of the exercises is around the concept of lenses, initially proposed by Foster et al., to solve the view-update problem of relational databases.

The theories around lenses have been advanced significantly in recent years, resulting in a library, implemented in Haskell, called lens.

This workshop will take you through the basic definition of the lens data structure and its related structures such as traversals and prisms. Following this we implement some of the low-level lens library, then go on to discuss and solve a practical problem that uses all of these structures.

We'll explore how to built connected, real-time web applications using Elixir and the Phoenix framework.

• Look at the basics of Elixir, or rather the things we need to dive into the workshop
• Get started with the basics of Phoenix and how to build simple HTML web applications with it
• Introduce channels and learn how to use them in order to communicate with clients in real time
• Talk about distribution and how to work with Phoenix on multiple servers
• Talk about LiveView and learn how to update data on a page from the server without any JavaScript

This is an intensive workshop for those who are interested in learning how to think, read, and write APL. It will help give you the tools, mental framework, and structure for doing things "the APL way." In this workshop, you will have the chance to spend intensive time thinking like an APL programmer. What makes it different? How does the code look at the end? What thought process do you go through to get there? Get a chance to play around with a wide array of problems and solving them "the APL way."

Taijiquan Classics say, "Four ounces deflects a thousand pounds."

APLers might say instead, "Fifty characters solve a thousand problems."