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!

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.

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.

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.

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.

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. 

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.

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.

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.  

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.

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.
   
   

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.

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

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.

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.

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.

GNU Emacs is a popular text editor for functional programming (Clojure, Haskell, Idris et. al.). This talk provides a demonstration of using GNU Emacs as part of your daily workflow. The different topics that will be addressed include project and time management, development, IRC, DevOps, managing secret files, e-mail, listening to music, reading news feeds, blogging, book publishing, etc. Emacs Lisp code snippets will be shared to demonstrate the setup and customization. The ~/.emacs.d configuration is available at:

https://github.com/shakthimaan/cask-dot-emacs

Functional programming has it roots in Lambda Calculus and Recursion Theory. As we start getting deeper into type systems and type theory, another branch of mathematics becomes significant - Category Theory. If, as a programmer, you tried to read and understand Category Theory chances are high that you dropped the book and went back to life! It happened with me. As users of modern programming languages and libraries, we are often unaware of the amount of design concepts the latter borrow from ideas of Category Theory. 

This talk would give a gentle introduction to three of such functional design patterns, I prefer to call them containers - Functors, Applicative Functors and Monads - keeping the all the abstract math away and focusing on getting introduced to them with very simple code examples in Swift. We will also point out some types in the Swift language and the standard library that conform to these patterns. Finally, we prove how the existence of these concepts could make your code better - how they help achieve separation of concerns, eliminate code duplication and managing side effects. Though languages like Haskell make it very easy to express these concepts, they could be expressed in any modern language with a tad bit of code. 

We have been rewriting our CoreData and NSOperationQueue based sync system with RxSwift. This talks presents our benefits with moving with RxSwift and some of the challenges we faced while we implemented a persistent job queue with RxSwift.