Old languages emerge and new languages are born when big things happen, and big things are happening now. In this keynote, we'll look at some of the biggest challenges facing programming evolution, and their likely impacts on programming.

Functional Programming Languages have a prominent role, but also there are interesting things happening in the browser and a pendulum shift toward better type models.

The rules we agree on define the games we play. We see this in methodologies we adopt for software development, in the mathematics we were forced to learn in high school, and in the syntax and grammar of the languages we choose to use. During this talk we'll explore cases in which the implication of axioms are clear and cases in which they are far from clear. There will be a quiz.

It's been around for a long time, but everyone's talking about it all of a sudden. But why and why now? We've been

programming in languages like Java for a while, quite well. Now we're asked to change and the languages themselves

are changing towards this style of programming. In this keynote, a passionate polyglot programmer and author of

"Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions" will share the reasons

we need to make the paradigm shift and the pure joy—the benefits—we will reap from it.

In this talk, we'll explore why some technologies end up inexplicably dominating our field while others fade away despite their obvious merits. What will it take for the languages we care about to succeed, and what are the consequences of success? Let's apply a broad perspective to the mess we've made of modern computer science, and explore our options for getting the situation back on track through a careful examination of history, science and ponies.

Code used during the talk: https://github.com/shashi/fuconf-talk
Slides: https://docs.google.com/presentation/d/16Xfqd-xU8y2JEN0TIcacDoYnp0b5-W7ESDB5v1SmcXs/edit#slide=id.p

Elm is a strongly typed functional reactive programming (FRP) language that compiles to HTML, CSS, and Javascript. In Elm, the Signal type represents a time-varying value--things like mouse position, keys pressed, current time are signals. With Signals, one can write terse code that is isomorphic to a dataflow diagram of the app. The code hence feels natural and is 100% callback free. All this, with powerful type inference.

This talk is an introduction to FRP. It explores functionally composing graphics and UIs, and creating interactions and animations with the Signal type. There will also be an overview of Elm’s execution mechanism and the time traveling debugger: a consequence of Elm's purely functional approach.

While instructive, it will be good fun too, in the spirit of Elm.

Immutable, persistent data structures form a big part of the value proposition of most functional programming languages.

It is important to understand why these data structures are useful and how they make it easier to reason about your program. 

It is also instructive to see how these data structures are implemented to get a greater appreciation for the inherent tradeoffs between performance and immutability.

In this talk I will do a walkthrough of some of these data structures drawing from the work of Chris Okasaki[1], and attempt to explain the essential ideas in a simple way. 

[1] Purely Functional Data Structures, Chris Okasaki, School of Computer Science, Carnegie Mellon University 

Sync, Async, Blocking, Non-Blocking, Streaming are the buzzwords in the reactive programming world. This talk will attempt to attach some meaning to them. It will also demo the performance and resource consumption patterns for blocking-io, Scala Futures and RxJava Observables for comparable programs. Finally, a command line application that consumes twitter streams API will demo what is possible using the new reactive abstractions.

Brief history of recursion 

Snippets from a few languages

What is tail recursion?

Design choices around recursion

The importance of tail recursion in erlang

How do you profile such improvements?

Traditionally functions return some value. Someone is waiting for that value and does some computation with it. This "someone" is called the continuation of this value. In a normal functional call, the continuation is "implicit". In the "continuation passing style" (hence forth called with the short form, CPS), we make the continuations explicit. In this style, function definitions take an extra argument called "continuation" and it never return. The "return value" of the function 'continues' by passing this value as an argument to the continuation. Continuations are sometimes called "gotos with arguments".

CPS is used as an intermediate stage while compiling a program since it makes the control structure of the program explicit and hence can be converted easily to machine code. Another feature of a CPS-transformed function is that it is tail-recursive even if the original function was not written in a tail-recursive style.

Continuations enable a programmer to build new control operators (if the language's built-in operators does not already provide the control operators the programmer need).

Javascript programmers have had a lot of choices when it comes to programming. There were days of mootools, scriptaculous and jQuery and then there are now days of Angular, Ember, Knockout and the like. As a javascript programmer myself, I find that Clojurescript/React as Om offers a fresh perspective into building performant Javascript UIs that are easy to write.

The talk will introduced concepts of React, immutable datastructures in Clojure and live code an application that demonstrates the concepts.

Manual testing is something that's error prone, incomplete and impossible to replicate on a large scale. We have instead been using xUnit style of testing for quite some time now. This approach has a number of drawbacks like (a) We need to write test cases by hand which again doesn't scale for large systems (b) We may miss out some of the edge cases (c) Safeguarding missing cases with coverage metrics doesn't help, since metrics are mostly based on heuristics (d) maintaining test cases and test data is a real pain.

In property based testing we write properties and not low level test cases. And let the system generate test cases which validate such properties. There are 2 main advantages with this approach:

1. You think in terms of properties (or specifications) of the domain model which is the right granularity to think about
2. You don't need to manage test cases, which is completely done by the system that generates a large collection of test data

This approach is ideal for the functional programming paradigm, which focuses on pure functions. Using functional programming it's easier to reason about your model - hence it's easier to test functional programs using properties. In this talk I will take some real world examples of property validation and verification using scalacheck (the property based testing library for Scala) and a real world domain model.

There is a growing need for scalable, realtime business systems that are continuously running and highly-available. Two very different frameworks/approaches you could use to build such systems are Storm and Akka.

Systems created with Storm or Akka are distributed, at runtime, on as many machines as you choose. The inherent concurrency implied by this brings the issues of State, Time and Failure into sharp focus. Functional programming has much to say about dealing with state and time; not surprisingly, both Storm and Akka have strong roots in functional languages (for Storm it is Clojure, and for Akka, Scala).

In this talk we'll explore the core concepts and challenges of distributed computation; the role of functional programming in concurrent distributed computing; we'll take a look at Storm and Akka, by example, and see that as different as these 2 approaches are, the underlying difficulties of distributed computation remains evident in both: dealing with time, and dealing with failure.

Functional programming has started (re)gaining prominence in recent years, and with good reason too. Functional programs lend an elegant solution to the concurrency problem, result in more modular systems, are more concise and are easier to test. While modern languages like Scala and Clojure have embraced the functional style whole-heartedly, Java has lagged a bit behind in its treatment of functions as first-class citizens. With the advent of Java 8 and its support for lambdas, however, Java programmers can finally start reaping the power of functional programs as well. Even without Java 8, it is possible to adopt a functional style with the aid of excellent libraries such as Guava.

This talk will explore how to apply functional concepts using the Java programming language and demonstrate how it can result in simpler, more elegant designs. We will conduct this in a hands-on workshop style with attendants being encouraged to code-along. So bring your favorite Java 8 aware IDE, an open mind and prepare to have a lot of fun.

Most applications running in the cloud are not optimized to do so. They make assumptions about the underlying operating system, resulting in larger footprints with increased costs and risks.  The open source Mirage OS represents a new approach where the application code is combined with the specific components of the operating system it needs into a single-purpose unikernel appliance. With Mirage OS, developers can create lean and efficient unikernels for secure, cost-effective and high-performance network applications. Mirage OS unikernels run directly on the Xen Project hypervisor, which allows them to be quickly deployed to many leading cloud platforms.

Mirage OS is fully written in OCaml, from the device drivers and network stack to higher-level synchronisation protocols and databases. In this presentation I will explain how we developed Mirage OS and why we choose to do so in a strongly typed functional language with a powerful module langage. I will then present some of the new features of Mirage OS v2.0 such as: support for ARM devices, Irmin: a Git-like distributed database and OCaml-TLS: a comprehensive implementation of the TLS protocol in pure OCaml. 

APL is a member of the family of languages that are approaching middle age (Ken Iverson’s book titled “A Programming Language” was published in 1962). APL was very influential in the 60’s and 70’s, and widely used to deliver “end user computing” - but although the REPL, dynamic scope and lack of a type system endeared APL to domain experts, it also drew fire from computer scientists, most famously when Edsger Dijkstra declared that “APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past it creates a new generation of coding bums.”

Dyalog is a modern, array-first, multi-paradigm programming language, which supports functional, object-oriented and imperative programming based on an APL language kernel. Dyalog allows people with good ideas – from bright high school students to PhDs – to contribute directly to the software development process using a notation which fits comfortably with those used in their own domains. Subject matter experts can write prototypes or, with suitable training and/or support, highly efficient, parallel and robust code that can be embedded in high-performance production applications.

Although Ruby is not known as a functional language, it does support higher order functions in the form of lambdas and procs. Ruby's support for both object oriented and functional approaches, along with its conciseness, clarity, and expressiveness, make it an excellent choice as a general purpose programming language.

This session, geared toward the functional novice, shows how to implement functional approaches in Ruby, and shows why you would want to.

Topics covered will include:

• in testing, using lambdas to verify that certain behaviors do or do not not raise errors
• lambdas as predicates
• deferred execution
• composite functions
• nested functions
• using lambdas to hide variables
• functions that return functions (partial application, currying)
• lightweight event handling
• chaining behavior with lambda arrays
• how lambdas differ from conventional Ruby methods

LINQ draws on principles of functional programming and represents a paradigm shift for developers used to an imperative/object oriented programming style. Thinking in LINQ explains the benefits of functional programming built into LINQ, allowing developers to use these techniques write more efficient and concise data-intensive applications.

While other books on the subject merely scratch the surface in terms of problem solving using LINQ, Thinking in LINQ (http://www.apress.com/9781430268451)  shows readers how use functional programming techniques to solve common every-day problems as well as more complex problems using LINQ’s features.

LINQ lets you write code that resembles natural language and is easier to debug compared to traditional loops and branching statements. The purpose of a well written LINQ Query will be immediately evident unlike the looping construct so commonly used in traditional programming. LINQ operators can be used in unison to orchestrate a solution for complex real world problems.

What viewers will learn

• Text Processing using LINQ
• Refactoring using LINQ
• Monitoring code health using LINQ
• Creating DSL using LINQ

Monads are a little bit like Quantum Physics: If you think you understand quantum mechanics, you don't understand quantum mechanics.

Monads are very useful for chaining computation together, in a simple way. The best explanation I've heard for them so far is that they are `programmable semicolons'.

In this session, I'll describe a few patterns that are solved by monads in some FP languages, and how you are already using them.

Some monads I plan to cover:

* Maybe Monad (being the easiest to explain)

* List monad, and how it is used to model non-determinism

* The state monad

* The IO monad

And maybe a few others

Since the introduction of lambda expressions in C#, we have had two different style of programming. Yet, programmers used to the habitual style often find it easy to fall back on those old practices. In this presentation we will take a number of common tasks we code in C#, discuss the downsides of the habitual style, transform it into functional style, and discuss the benefits. We will also discuss some techniques that can help make this transformation easier on everyday projects.