How do you decide whether a programming language is worth using or not? By necessity, such decisions are usually based on assessments that can be made relatively quickly: the ease of using the language, how productive you feel in the first week, and so on. Unfortunately, this tells us very little about the costs involved in continuing to maintain a project past that initial phase. And in reality, the vast majority of time spent on most projects is spent in those later phases.

I'm going to claim, based on my own experience and analysis of language features, that functional programming in general, and Haskell in particular, are well suited for improving this long tail of projects. We need languages and programming techniques that allow broad codebase refactorings, significant requirements changes, improving performance in hotspots of the code, and reduced debug time. I believe Haskell checks these boxes.

48 years after it's invention, logic programming remains a less frequently used paradigm.

What can functional programming learn from logic programming?

Unification and nondeterminism are powerful constructs not strictly relegated to logic programming. We'll look at unification, nondeterministic completion, probabilistic computation, and constraint propagation in functional contexts.

APL is known for its concise problem-solving expressiveness, and it is used very successfully in places where high-quality and rapid iteration are requirements, not luxuries. Static Type Systems have had tremendous success throughout the computing industry, even receiving positive HCI usability studies that demonstrate their effectiveness on a number of metrics with mainstream and functionally-oriented programming languages. This success leads many programmers to take the value of type systems as a given, especially as mission-criticality and the age of a project increase. Therefore, it comes as a surprise to many, when learning about APL, that it has spent so long as an untyped, interpreted language in domains and use cases where traditional wisdom would suggest the need for a typed, compiled language.

But APL is not like other languages, and its unique features and historical uses warrant a careful revisiting of the question of type systems. In this talk we will explore whether or not APL needs a type system, whether it would benefit from having one, what that might look like, and how the interaction between APL and type theory might inform the design and use of type systems in general.

We write programs in a different language than we talk about them. "So we get a request, do the security mumble, pass it to the middleware that grabs ..."

Can we get closer to writing programs that describe the program's desired behavior? And why do such attempts always get poo-pooed by programmers?

This is a foofy cloud shaped drawings exploration of other ways to express software design intent, mostly by cheating.

Tests are good. Generative tests are better. But we don't write them often enough. Why not?

Generative testing isn't new; John Hughes' QuickCheck is now implemented in 30 languages. Yet, it is still not an every day tool for most software teams. Why not?

I have seen that maintaining a generative, or simulation testing suite can require the full-time attention of a few senior engineers. And over time, the tests become complex, brittle, ineffective, and hard to diagnose.

But isn't generative testing supposed to make testing simpler, and more effective?

I believe that it requires a rather different paradigm of thought from what we're used to with traditional testing. And recognising this paradigm shift can help us leverage it effectively.

I'll discuss a holistic perspective of generative testing to elucidate this thought paradigm.

Using a practical scenario, I'll discuss the patterns that emerge from this thinking, and how they address the concerns of making generative tests more effective, and maintainable.

As machine learning matures, it is becoming obvious that we need explainable solutions. As functional programming matures it becomes obvious that we need inference and nondeterminism. And linked open data demands reasoning. This all day workshop will introduce the logic programming paradigm, in which programs are expressed as a set of logical rules and executed by finding proofs of queries.

SWI-Prolog is the most highly developed and widely used language for logic programming.

The language, which has been in continuous use in academic research settings since it's invention in 1972, provides unparalleled power. Many problems which would be difficult to express in other languages are simple in SWI-Prolog. SWI-Prolog is a 'batteries included' modern language, ready for real world tasks like web development and process control.

In this dynamic hands on workshop we'll learn the basics of SWI-Prolog, and look at some of the amazing things it can do.

Because of some perceived complexities and the mathematical background in functional programming, the beginners get bogged down while learning and putting it into practice. As a matter of fact, few people give up after some initial attempts. But it is not as much harder as we think. It is just different!

Together, let's experience a different perspective of functional programming and get started in a better way

We sorely missed the rapid "refresh-based" feedback loop available in Rails (and other dynamically typed web frameworks), while writing Haskell. Change your code, hit save, and refresh your browser!

In this talk we will share a few tips on how we finally hit productivity nirvana with ghcid and automated code-gen.

Best of both worlds -- rock-solid type-safety AND being able to reload code with every change.

Functional programming is built around a foundation of well-defined Types, and when you throw in Typeclasses into the mix, you get the love-child that is Algebraic Data Types. In this talk I aim to explore the mathematical foundations of Type theory and how it can be used practically in Scala for wide variety of applications like Machine Learning (Apache Spark MLlib), API design (using Vertx), DSLs and the like.

I will also be introducing the scalacheck library for Property-based testing and how you can quickly validate your ADT domains.

The talk will further deep-dive into how you can utilize the amazing Cats library and Shapeless to build generic libraries around your ADTs, having Circe as a case-study.

Domain Specific Languages (or Libraries because embedded DSLs are just that) are already quite popular.

Modern languages have many useful language features that are conducive to create DSLs with more ease than ever before. Kotlin from JetBrains is a beautifully blended pragmatic programming language that packages many features from many programming languages. Kotlin also have infix operation which makes code written in a DSL made with Kotlin very easy to read (and therefore less error-prone).

In this demonstration, I shall show couple DSLs made from Kotlin

and will dissect the code LIVE to show audience how several language features in Kotlin (which sometimes requires playing with higher order functions) to develop these languages.

*A Unit Testing DSL (a DSL to simplify unit testing of Kotlin, Java Code) that our grand/m/pa can use.

-- All unit test frameworks serve the purpose but elegance is a different matter. A code that works, and a code that is elegant and works is art. In this example, audience will see how they can use several language features that Kotlin has to offer can be put together to create an elegant and expandable unit testing DSL.

* A DSL for Web Scraping and Transformation.

- - A special case of ETL, where Extraction happens from raw HTML, Transformation happens in memory using the DSL designed. and the Load happens by loading this data to a different schema/db/form/representation.

Category Theory has been found to have a vast field of applications not limited to programming alone.

In this fun-filled talk (Yes! We promise!) , we want to make the audience fall in love with Math & Category Theory in general, and Haskell in particular.

We will address questions such as below:

• What is the mysterious link between the abstract mathematical field of Category Theory and the concrete world of real-world Programming ? And why is it relevant especially in Functional Programming?
• Most of all, how can You benefit knowing Category Theory ? (Examples in Haskell)

Haskell can and does perform as well as C, sometimes even better. However,
writing high performance software in Haskell is often challenging especially
because performance is sensitive to strictness, inlining and specialization.
This talk focuses on how to write high performance code using Haskell. It is
derived from practical experience writing high performance Haskell libraries. We
will go over some of the experiences from optimizing the "unicode-transforms"
library whose performance rivals the best C library for unicode normalization.
From more recent past, we will go over some learnings from optimizing and
benchmarking "streamly", a high performance concurrent streaming library. We
will discuss systematic approach towards performances improvement, pitfalls and
the tools of the trade.

Easy concurrency is one of the main prophesied benefits of the modern functional programming (FP) languages. But the implementation of concurrency differs widely between different FP languages. In this talk, we shall explore the methods and primitives of concurrency across three FP languages: Haskell, Erlang, and Clojure (with core.async).

We shall learn about and compare the trade-offs between

• the green threads and STM channels oriented concurrency of Haskell
• everything-is-a-process and message-passing actor pattern of Erlang
• macro-based CSP transformation of Clojure/core.async

distance(clojure-code, production)→ 0

Clojure is capable of leveraging everything your JVM provides. And you are convinced of the benefits this LISP brings to your productivity. In this workshop, we target bridging the gap between your expressive and beautiful Clojure code, and the huge, daunting world of the Enterprise. With some small, helpful steps.

We'll specifically target

• Going beyond the linear flows - making core.async practical
• Confidence building measures - Clojure spec
• Demystifying the wormhole - JVM interop
• Practical tidbits - Introducing Clojure to your existing apps
• Graduating - Build tooling and publishing for both library and standalone application use-cases

In this talk, we define the principle of functional programming, then go into
detail about what becomes possible by following this principle. In particular,
parametricity (Wadler, 1989) and exploiting types in API design are an essential
property of productive software teams, especially teams composed of volunteers
as in open-source. This will be demonstrated.

Some of our most important programming tools are neglected, often argued away
under a false compromise. Why then, are functional programming and associated
consequences such as parametricity so casually disregarded? Are they truly so
unimportant? In this talk, these questions are answered thoroughly and without
compromise.

We will define the principle of functional programming, then go into
detail about common problems to all of software development. We will build the
case from ground up and finish with detailed practical demonstration of a
solution to these problems. The audience should expect to walk away with a
principled understanding and vocabulary of why functional programming and
associated techniques have become necessary to software development.

In this case study presentation, SumAll's CTO, Todd Sundsted, and Senior Software Engineer, Michael Ho, will discuss the move from Java to Haskell along two parallel paths. First, the business/political story — how SumAll convinced the decision makers, fought the nay-sayers, and generally managed the people impacted by the transition. Second, the technical story — how they actually replaced their Java code with Haskell code. Along the way, they will address their hopes and expectations from transitioning from Java to Haskell, and will conclude with the results they've gained and seen to date.

A virtual cottage industry has sprung up around Purely functional UI development, with many available libraries that are essentially just variants on two distinct approaches: Functional Reactive Programming (FRP), and some form of functional views like "The Elm Architecture". After having worked extensively with each of them, I have found that none of the approaches scale with program complexity. Either they are too difficult for beginners trying to build a hello world app, or they have unpredictable complexity curves with some simple refactorings becoming unmanageably complex, or they "tackle" the scaling problem by restricting developers to a safe subset of FP which becomes painful for experienced developers who start hitting the complexity ceiling.

In this talk I give an overview of the current Purely Functional UI Development Landscape, and then present "Concur", a rather unusual UI framework, that I built to address the shortcomings of the existing approaches. In particular, it completely separates monoidal composition in "space" (i.e. on the UI screen), from composition in "time" (i.e. state transitions), which leads to several benefits. It's also a general purpose approach, with Haskell and Purescript implementations available currently, and can be used to build user interfaces for the web or for native platforms.

The biggest advantage of Concur that has emerged is its consistent UI development experience that scales linearly with program complexity. Simple things are easy, complex things are just as complex as the problem itself, no more. Reusing existing widgets, and refactoring existing code is easy and predictable. This means that Concur is suitable for all levels of experience.

1. For Learners - Concur provides a consistent set of tools which can be combined in predictable ways to accomplish any level of functionality. Due to its extremely gentle learning curve, Concur is well suited for learners of functional programming (replacing console applications for learners).
2. For experienced folks - Assuming you are already familiar with functional programming, Concur will provide a satisfying development experience. Concur does not artificially constrain you in any form. You are encouraged to use your FP bag of tricks in predictable ways, and you are never going against the grain. It's a library in spirit, rather than a framework.

When we talk about domain models, we talk about entities that interact with each other to accomplish specific domain functionalities. We can model these behaviors using pure functions. Pure functions compose to build larger behaviors out of smaller ones. But unfortunately the real world is not so pure. We need to manage exceptions that may occur as part of the interactions, we may need to write stuff to the underlying repository (that may again fail), we may need to log audit trails and there can be many other instances where the domain behavior does not guarantee any purity whatsoever. The substitution model of functional programming fails under these conditions, which we call side-effects.

In this session we talk about how to manage such impure scenarios using the power of algebraic effects. We will see how we can achieve function composition even in the presence of effects and keep our model pure and referentially transparent. We will use Scala as the implementation language.

In discussing effects we will look at some patterns that will ensure a clean separation between the algebra of our interface and the implementation. This has the advantage that we can compose algebras incrementally to build richer functionalities without committing to specific implementations. This is the tagless final approach that offers modularity and extensibility in designing pure and effectful domain models.

Laws, laws, laws. It seems as though whenever we learn about a new abstraction in functional programming, we hear about its associated laws. Laws come up when we learn about type classes like Functors, Monoids, Monads, and more! Usually laws are mentioned and swiftly brushed past as we move on to examples and applications of whatever structure we're learning about. But not today.

In this talk, we'll learn about Functors and Monoids, paying close attention to their laws. Why should our abstractions have laws? We'll answer this question both by seeing powers we gain by having laws, and by seeing tragedies that can befall us without laws.