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.

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.

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. 

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.

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.

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.

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.

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.

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.

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.  

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

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

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.

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.