Full day hands-on workshop on building concurrent, fault-tolerant and scalable systems in Erlang/OTP in the Erlang Ecosystem. We will look at three languages in the Ecosystem, Erlang, Elixir and LFE, and show how they can all be used together when building systems.

Erlang is in many ways quite old though many of the problems for which it used are quite modern. The Erlang language and system was designed around a set of requirements for telecom systems. They were distributed, massively concurrent systems which had to scale with demand, be capable of handling massive peak loads and never fail. The Erlang concurrency and error-handling model was developed around these requirements. We will describe the development of the language and the design of systems based on the Erlang showing how well the functional paradigm suits attacking these types of problems. We will also look at the further development with the introduction of new languages in the Erlang environment - the Erlang ecosystem.

We are constantly presented with trade-offs when writing software. What are the trade-offs when applying functional programming? What costs arise? When is it not worth doing? When should pragmatism kick in and when should we start using side-effects?

This talk will give you some tools to be able to answer the above questions for both functional programming and types. The tools have been refined over many professional years of both doing and not doing purely functional programming.

The streaming of data in a purely functional language is a fascinating problem that have been extensively explored over the years.

In this talk we'll first briefly outline historical solutions to the problem and discuss their advantages and disadvantages,
we will then follow with a practical introduction to the great `machines` library from Edward Kmett.

We will see how the library usage compare to other players in the ecosystem (pipes, conduit, ...),
and walk through real world examples giving us a chance to write our own combinators and understand some of the internals.

Homoiconicity (code as data, data as code) is one of the hallmarks of Lisp. Clojure, a Lisp-1 language, has this wonderful feature too. In this talk I will discuss about performance optimization techniques that leverage homoiconicity.

No discussion on performance optimization can happen without discussing performance benchmarking. In this talk I will show how to do comparative benchmarking while trying to find performance bottlenecks. I will then proceed to showing techniques on using Clojure's homoiconicity to optimize performance. I will also show how to discover latency breakup of any Clojure code in a waterfall-chart model using homoiconicity.

Types allow us to structure data to match the functional requirements of the problem we are trying to solve. But, in most languages, we end up choosing/building types that are the closest to our requirement. They don't exactly fit our bill, as a result of which, we write runtime code to enforce those conditions. Then we write tests because the compiler can't help us. Dependently Typed Languages like Idris allow us to encode a wide range of invariants into the type itself allowing us to possibly have zero runtime errors.

Domain modeling is usually implemented using OO design. In this approach of "nouns-first" we design object hierarchies using subtyping to model the various elements of the domain. In this talk we will take a different approach using Scala:

1. Start with focus on verbs first
2. Think how we can model domain behaviors using pure functions grouped within extensible modules
3. Use an algebraic approach towards evolution of modules,the algebra being composed of functions,types & laws
4. See how the domain algebra can be constructed from categorical structures like monoids, functors & monads
5. Discuss how the functional patterns lead to compositionality - an extremely important quality that scales your domain model.
   
   

The JVM is a state-of-the-art, cross-platform virtual machine supported by the vast Java platform and ecosystem, but is cursed with an ancient and clumsy language that is slowly modernizing. Haskell is a state-of-the-art programming language with immature platform and tooling and no commercial development of its primary implementation. GHCVM's objective is to combine the best of both worlds and reap the benefits.

In this talk, I will share my journey of how I waded through the internals of GHC and got Haskell and Java to play nice with each other.  

Equational Reasoning [1,2] is an intermediate/advanced FP technique, that sits at the intersection of programming and mathematics and has many interesting uses. It can be used to prove that a piece of code is correct, has specific performance properties,  to drastically reduce the size of a particular piece of code , assure that your code will scale to a bazillion servers, etc etc.

But how this technique works is often considered a mystery. What is also  missing is a step by step way to learn this method so you can use it in your code. Many books and blog entries show you examples and then you, the reader, are supposed to infer from these examples how Equational Reasoning  works.  When I first ventured into FP, I could (more or less) follow published examples, but never could figure out how this technique works and how to apply it to my code.

The key to such understanding (as I discovered much later) is to grok the underlying mathematical structure, specifically the nature of the logic and proof technique that provides the working machinery of Equational Reasoning.

In this presentation, I look at the mathematical underpinnings of this excellent programming technique. Once you understand how the math works [3], it is easy to see how the programming technique works. And once you know how that  works, you can use Equational Reasoning as just another tool in your dev toolbox.

Once they learn the basics of FP, most programmers are stuck with respect to how to get to the next  level.

The most common solution  (especially for Haskellers) is to try to deep dive into  Category Theory and Algebra, and their uses in FP.  Which is a good step if you can pull it off, but  in practice this is  much harder than it needs to be (which is the topic of another lecture someday), and many people give up at this point.

(imo) Understanding Equational Reasoning levels up your FP skills without necessarily having to learn CT structures simultaneously (though, of course nothing prevents you from learning both and combining them, as many Haskellers do), and is a gentler 'level up' than wrestling with Categories and Arrows and such.

This presentation reveals the nuts and bolts of why and how Equational Reasoning works. Then you can read the existing literature and gain much more out of it than otherwise.

Essentially, this talk  is what I wish someone had told me when I was trying to learn FP and got stuck.  You might be able to gain from my struggles!

[1] A blog entry explaining the basics

[2] A good book with many examples 

Some quotes from the preface

".. I (Richard Bird) was interested in the specific task of taking a clear but inefficient functional program, a program that acted as a specification of the problem in hand, and using equational reasoning to calculate a more efficient one."

" One factor that stimulated growing interest
in functional languages in the 1990s was that such languages were good for
equational reasoning. Indeed, the functional language GOFER, invented by
Mark Jones, captured this thought as an acronym. GOFER was one of the
languages that contributed to the development of Haskell, the language on
which this book is based. Equational reasoning dominates everything in this
book."

To be clear, this talk is not about the problems tackled in the book, though I'll use a couple of them as dissection specimens. The book shows (excellent) examples of applied ER, with a focus on generating efficient algorithms. My talk is about how ER works, and bridging the mathematical and programmatic machinery. We'll see, for example, why such derivation of efficient algorithms via ER works.

[3] I keep the math bits programmer friendly, so don't worry if you are not big on formal math. This is a talk addressed to programmers.  If you can write nested if statements or SQL queries, say, (iow if you have a couple of years of programming experience), specifically if you understand how logical operators (and, or, not) work,  you'll be fine. I'll fill in the rest.

Don't use metaprogramming! Don't use macros! You will often hear those statements. But metaprogramming or speaking more specific macros are heavily used in scala ecosystem. Almost every big project in functional or "reactive" technology stack uses them somewhere under the hood. What are macros? Why they are so controversial? What macros can offer to an engineer? Why they are useful? How they can minimize amount of boilerplate code? After answering those questions by showing small examples, we will start to develop library(or maybe better term will be DSL) for parsing XML.

But there is something more I didn't mention. If you are familiar with Scala ecosystem and up to date with roadmap of new Scala versions, you should be aware that...MACROS ARE DEAD. So why bother? Because there is new, bright future of metaprogramming in Scala called Scala Meta. We will see that knowledge gained after learning macros will be helpful when we will learn new approach presented in Scala Meta.

Julia is a programming language for data science and numerical computing. Julia is a high-level, high-performance dynamic language, it uses just-in-time compilation to provide fast machine code - dynamic code runs at about half the speed of C, and orders of magnitude faster than traditional numerical computing tools.

Julia borrows two main ideas from Lisp lore:

1. Multiple-dispatch: a method is identified by a name and the types of all of its arguments (traditional OOP only uses the type of a single argument) multiple-dispatch allows for a natural programming model suitable for mathematics and general purpose programming. Interestingly, the same feature is responsible for Julia's ability to generate really fast machine code.
2. Macros: Julia has syntax that is familiar to users of other technical computing environments, however, Julia expressions are homoiconic -- Julia code can be represented as Julia data structures, and transformed from one form to another via hygienic macros. There are some very interesting uses of macros to create domain-specific languages for effective programming. 

The session will present design and implementation of Hspark. A library that implements a framework to enable running a distributed map-reduce job over a set of nodes. The session will also showcase an extensible DSL to specify distributed map-reduce job.

The session will focus mainly on 

• Creation of DSL (Specification) for map reduce. The DSL is similar (actually based on) Apache Spark
• Translation of DSL into scheduling the jobs across the nodes, and
• Executing and handling failures.

Current implementation of hspark is at https://github.com/yogeshsajanikar/hspark and implements first two points mentioned above. Currently, I am trying to enforce it with separation of execution framework so that failures can be handled correctly.

Note that this project was implemented as a part of course project for CS240H at Stanford. The implementation details can be found at http://www.scs.stanford.edu/16wi-cs240h/projects/sajanikar.pdf

25 years ago I published "Why Functional Programming Matters", a manifesto for FP--but the subject is much older than that!

As software becomes more and more complex, it is more and more important to structure it well. Well-structured software is easy to write, easy to debug, and provides a collection of modules that can be re-used to reduce future programming costs. Conventional languages place conceptual limits on the way problems can be modularised. Functional languages push those limits back. In this paper we show that two features of functional languages in particular, higher-order functions and lazy evaluation, can contribute greatly to modularity. As examples, we manipulate lists and trees, program several numerical algorithms, and implement the alpha-beta heuristic (an algorithm from Artificial Intelligence used in game-playing programs). Since modularity is the key to successful programming, functional languages are vitally important to the real world.

In this talk we'll take a deep dive into history to revisit our personal selection of highlights.

We've several conference attendees who would show how they've used Functional Programming to do something really awesome! If you are trying to convince other people to use Functional Programming, you should watch these demos and show them these demos.

Since the original APL\360 interpreter saw the light of day in 1966, a large part of the of primitive functions in APL (A Programming Language) implicitly map operations to all elements of array arguments (and arrays of numbers or characters are the only “types” available in the language). Over the decades, the parallelism at the core of the notation has been extended, to nested arrays in the 80’s and arrays of objects in the 00’s. In this decade, arrays of futures have been added to provide users of APL with the ability to express asynchronous – but deterministic -algorithms.

This talk will introduce the most important parallel constructs available in current Dyalog APL, which (despite the name) essentially remains an executable mathematical notation.

We (ClearTax) build a full product in F#, and it's been in production for two years now. This talk will cover our learnings from building this product – what we did well and what went wrong. We will discuss the joys and the challenges that come with using a functional language day-in and day-out.

I want to share our journey, so the community can learn from our experiences and we can get feedback from the experts as well.

This talk will be about how we applied Typed functional programming and object-functional concepts inspired from languages like Scala, Haskell in building an Ads serving engine using Java 8 and made the stack extensible for multiple Ads serving usecases like App, Desktop, Exchange and ML model execution for CTR prediction, Guaranteed delivery etc.

This talk will focus on how we solved problems in an Ads serving engine using functional programming constructs for:

• Relevance and Ranking
• CTR prediction
• Bidding models
• Guaranteed delivery (Convex Optimization)
• Explore / Exploit (Multi-armed bandit)
• Attribution, Deduplication etc

From a language level, it will focus on how we applied our learnings from other functional languages like Scala, Clojure, Haskell in Java 8 to write elegant code for:

• Composing Ad selection workflows from reusable components
• Reasoning about code through immutability
• Defining interfaces like function types. Functions as first class objects to express behaviour.
• Using Builders and Filter predicates for adding new features
• Transforming collections using streams, lambdas, map, reduce, flatMap, groupBy
• Optional for writing null safe code and handling defaults using map, flatMap, orElse
• Functional operations like partition, zip for simplifying code
• Pattern matching and other features from libraries
• Caching and memoization

Kotlin is a statically-typed programming language released by JetBrains. With the arrival of Kotlin, Android's functional power has enhanced as Kotlin brings a bouquet of features such as type inference,higher-order functions, lambda expressions, operator overloading, lazy evaluation,immutability,recursive functions and lots of useful methods to work with collections. Kotlin comes up with essential functional facilities such as filter,take & drop, first & last, fold & foldRight, forEach, reduce,etc making it a perfect match for Android .This talk will focus on leveraging Kotlin's functional constructs for Android App development.

APL will be 50 years old in November 2016 (50 years from 1966-11-27 15.53.58, to be exact), and it remains unsurpassed in manifesting Kenneth E. Iverson’s five important characteristics of notation: 

• ease of expression
• suggestivity
• subordination of detail
• economy
• amenability to proof

These characteristics are demonstrated by working through 16 APL expressions. The material is approachable for beginners and yet thought-provoking for experts.

One of the 16 expressions is a fast computation of the partition function without use of the Hardy-Ramanujan (1918) results.

Two years after its introduction, the Swift programming language finds itself at rank # 14 on the TIOBE index for July 2016. Some of the prime reasons for Swift’s meteoric rise are its carefully designed syntax and semantics - it borrows heavily from the best features of a wide range of languages. The syntax is intuitive and new Swift learners can often relate it to the language of their choice. Introduced primarily as a client-side language, Swift was open sourced in December 2015 via swift.org. Since then, there has been a community effort on extending its capabilities to the server side too. Swift is available on Linux today, and it is poised to become a language enabling end to end development - from mobile apps to server backends. 

Swift falls in the category of “modern native languages” - like Rust and Go. These runtimes run code in bare metal, boosting performance. They are statically, strongly typed and with type-inference. This makes them safe. Their modern syntax also makes them expressive enough for high level abstractions like those seen in functional programming. They try to solve some of the tradeoffs that languages of the past battled with. On the other hand, functional programming has found new oxygen in the last couple of years when agile methodologies become as pervasive as multicore hardware . While we do have languages like Haskell that are purely functional and provide excellent support to express functional concepts, it is important to separate functional thinking away from the language. Functional programming is supported by most of the languages today because the returns of it in terms of expression, conciseness, readability, correctness and performance are unmatched. Swift is not a purely functional language. However, it provides syntactic and semantic support for functional programming to a large extent.

Persisting the State is an integral part of any application, and it profoundly influences how we architect the application. But do we need to store the state in the first place? Is there any alternative?

Together, let's experience a difference perspective of State Management.

JVM is one of the most widely used platforms and has attracted several languages. Though functional programming support is available through several languages, developers targeting JVM do not have an option that combines static typing with pure functional programming. Frege tries to address this space by providing a Haskell implementation on JVM. It comes with a good support for Java interoperability too.

I will be presenting this topic from the context of a developer targeting Java platform looking for pure functional programming options, not as a Haskell developer targeting JVM.

Depending on the people in the room, we would either do a panel or a birds of feather session. We'll be agile and decide on the last responsible moment!

Property-based testing is an approach that combines test case generation, automated test execution, and the first steps of diagnosis by automatically simplifying failing tests to minimal examples. When used well it seems almost like magic: you give a simple specification of how your code should behave, and in return a tool tells you your bugs. This workshop will introduce the basics of property-based testing, using Quviq's tool QuickCheck. The workshop will be very hands-on, so you will develop property-based tests for simple systems on your own laptop during the day.

You will learn about properties (the specifications that we test), generators (used to generate test cases), and state machine models (used to specify stateful behaviour). You will be using Erlang to write tests, and testing code in both Erlang and C. Finally we'll dip into race-condition testing, which is something of a "killer app" for this approach.

Dyalog is a modern, array-first, multi-paradigm programming language, which supports functional, object-oriented and imperative programming based on an APL language kernel. During the morning and early afternoon, we will explore the fundamentals of functional programming in APL. At the end of the day, Dyalog CXO Morten Kromberg will round off with an application development session, showing how a simple application with a HTML5/JS front-end and a RESTful web service can be used to deliver the power of APL to end users, or as embeddable components for other application tools. The "hands on" sections of the workshop can be followed under Mac OS X, Linux, or Microsoft Windows.

PureScript is a small, typed, functional programming language which compiles to JavaScript. Some of the goals are to require no runtime by compiling to minimal JavaScript and to provide a simple Foreign Function Interface to interact with existing JavaScript. PureScript has seen some commercial adoption and has many libraries available for writing functional web front-ends.

This workshop will cover writing an interactive web application using PureScript.