APL is a notorious language with a reputation for being "write only" and difficult to learn. Yet, many people consider APL to be their single most productive, advantageous tool that they hope never to give up. In particular, it is generally observed that many computer scientists have a poor opinion of the usability of APL, while many data scientists and domain experts find the language to be exceptionally usable.

This session focuses on the experienced programmer's struggle to gain real facility with APL beyond the basic, trivial understanding of its semantics and syntax (which can be taught in a few hours). We will observe this struggle through a "human-centered" experience analysis identifying a set of Pattern/Anti-pattern tensions that are at the heart of the intermediate APL learning "wall." By examining the experience of thinking and working with APL code versus regular code, we can identify principles of APL coding practice that directly oppose the widely taught and embraced best practices of the broader programming community. We'll see not only what these principles are, but also why they survive in APL and how they contribute to the positive development cycle of an experienced APL programmer, instead of the negative impact such practices usually have when writing in other languages.

Understanding these practices will provide a focus point for the discussion of programming experience design and the use of concise array language, as well as provide a structure for becoming better able to write, read, and think in APL expert.

This talk presents how we use the Eff monad at Zalando to structure a REST microservice. Even when programming with functions, modules and components still matter, and I will present a new approach for dependency injection using the Reader monad (classic) and tree rewriting (what?). Then we will see how to specify more precisely several components (authentication, request to other services and database access) with the Eff monad and support additional concerns like logging or asynchronous execution.

Once you get the basic idea, the possibilities are endless! Rate limiting is just another component and another set of effects involving time and state, testing becomes really clean and easy.

In Indian classical music, we have Jugalbandi, where two lead musicians or vocalist engage in a playful competition. There is jugalbandi between Flutist and a Percussionist (say using Tabla as the instrument). Compositions rendered by flutist will be heard by the percussionist and will replay the same notes, but now on Tabla and vice-versa is also possible.

In a similar way, we will perform Code Jugalbandi to see how the solution looks using different programming languages and paradigms.This time the focus of code jugalbandi will be on solutioning in different paradigms - object-oriented or functional programming and array-oriented paradigms.

During the session, Morten and Dhaval will take turns at coding the same problem using different languages and paradigms. There would be multiple such rounds during the Jugalbandi.

Graphics, animation, and games programming in Haskell faces a dilemma. We can either use existing frameworks with their highly imperative APIs (such as OpenGL, Cocos2D, or SpriteKit) or we waste a lot of energy trying to re-engineer those rather complex systems from scratch. Or, maybe, we can escape the dilemma. Instead of a Haskell program directly manipulating the mutable object-graph of existing high-level frameworks, we provide an API for purely functional transformations of a Haskell data structure, together with an adaptation layer that transcribes those transformations into edits of the mutable object-graph.

I this talk, I will explain how I used this approach to architect a Haskell binding to the animation system and physics engine of Apple’s SpriteKit framework. I will discuss both how the binding is structured and how it achieves the translation of Haskell side changes to SpriteKit and vice versa, such that it is sufficiently efficient. Moreover, I will demonstrate by example how to use the Haskell library to implement a simple game.

In this talk & demo, we have a look at some of the low-hanging problems in general aviation and how functional programming can be applied to provide significant improvements in efficiency and air safety. The current solutions to problems such as navigation, traffic/terrain collision avoidance and weight/balance calculations will be demonstrated to the audience, mostly for amusement. More seriously, we will have a look at the legacy that has led to the way things are, and how to improve by applying our programming skills.

We will look at:

• how aviation safety is regulated.
• how aeronautical services are provided to flight operators.
• how aeronautical navigation is conducted and regulated.
• how the weight and balance for a flight is conducted.
• the methods by which aircraft and ground coordinate between each other.

We will see:

• some real (and basic) data management problems in aviation, that very obviously threaten safety, then solve them, using programming.
• we will see a live demonstration of aeronautical navigation methods, investigate incident reports where lives were lost as a result, and consider how our programming skills can yield improvements, possibly even save lives.
• we will conduct a real weight&balance calculation for a flight, then once hilarity inevitably ensues, we will look at the problems that arise by this method, then solve them using data structures and functional programming. Some
  of these practical problems are obvious, even to a non-aviator, and the predictable incident reports are the end result.
• finally, we will have a look at a live demonstration of a software defined radio (SDR), receiving ADS-B transmissions from aircraft (live), an AHRS implementation and GNSS receiver using off-the-shelf, low-cost parts. We will look at why these instruments are helpful to aircraft pilots and interact with that device using the Haskell programming language.

In this workshop you will learn how to build microservices with Aeron and SBE in Java. Microservices capable of handling millions of messages per second with very low and predictable response times. We will cover some networking theory and the design of Aeron so you know how to use it with mechanical sympathy.

The core design of Aeron uses a new functional data structure and functional concepts. In this workshop we will explore how functional designs applied with mechanical sympathy can result in the highest performance messaging system available.

Service Discovery is an important aspect of microservices, particularly when using containers on elastic infrastructure. Most popular approaches for service discovery require a standalone fault tolerant cluster like Consul, Zookeeper or etcd.

If you are already using Akka as a clustering platform for your services, there is an interesting alternative available for Service Discovery. CRDTs, or Conflict-free Replicated Data Types are a relatively new primitive in distributed systems. CRDTs allows concurrent updates without coordination and has provisions for tuning consistency levels. 'Distributed Data' extension natively supports CRDTs on top of Akka-Cluster.

We used CRDTs in Akka to build the service registration and discovery mechanism for TMT's (Thirty Meter Telescope) software platform. TMT will be world's largest optical telescope once operational. The ongoing software work is open source and available on github. We would like to share the details of our implementation and also compare it existing approaches.

In recent years, the impact of functional programming on mainstream languages has grown significantly.

After conquering server applications and distributed systems,
the paradigm is now conquering the fields of web development and data analytics.

So what remains? The land of system programming.

When Mozilla did release the language Rust in 2012,
it did immediately striked interest from functional programming enthusiasts due to it's strong emphasis on safety.

Even though it currently lacks some advanced features like higher kinded types,
it is built with functional programming principles as it's core.

Like a Trojan horse (or the parasite mushroom after the language is named),
Rust looks like the next C on the outside... while it might actually be closer to Haskell on the inside!

Let's take a tour and discover an other side of system programming by learning together how to do functional programming in Rust.

There are several great books and courses that serve as an introduction to functional programming in Haskell. Typically, these introductions focus on the original core of Haskell ("Haskell 98").

However, going from there into real world Haskell systems can be a bewildering experience. This is because Haskell has evolved significantly since Haskell 98. In this talk we will investigate the key advances in the type-system that make up "modern Haskell".

• type-system extensions: GADTs, multi-param type-classes, functional dependencies, ...
• kind-system extensions: type functions, kind polymorphism, type promotion, ...

By taking a historical perspective we will look at why new language extensions were introduced, and the context in which they first appeared. This approach gives us a layered view of seemingly disparate language features.

We will see that the evolution of the type system has been a steady march from term-level programming to type-level programming, and ultimately dependently-typed programming in Haskell.

(This talk will draw from the book "Haskell Design Patterns")

Reporting data for finite state machine transactions like calls require exhaustive data mining into 10s and 100s of parameters for 1000s of calls per hour. These postmortems require heavy processing and can demand millions of maps per reduction. The presentation is a case study and demonstration of near-realtime asynchronous event processing based plotting of events and states of FSMs. Thus creating semi-cooked event plots delivering lightening fast reports with extensive customizability.

We will be spending the day learning the fundamentals of Functional Programming (FP) using the Haskell programming language. The exercise material will be a condensed selection of the NICTA/course which is regularly held in Australia over three days.

This one day session is targeted to experienced industry programmers who are looking to break into Functional Programming and develop the rudimentary skills and techniques that enable continued independent study. A refresher on Haskell syntax will be provided, however, it is highly recommended to practice with the syntax and development tools prior to obtain the best outcome for the day.

You will be required to bring a suitable development machine (portable) for working through the exercises. You will also need to install Glasgow Haskell Compiler (http://www.haskell.org/ghc/) version 7.8 or higher on that machine prior to the day.

Using a programming language that supports first class functional programming doesn’t necessarily imply that the code you write is functional. Functional programming has the nice properties of being compositional - you design smaller abstractions and then reuse them to build larger ones. You use the power of algebraic properties that these abstractions offer to build larger elements of your model out of smaller ones.

However often we find that many code bases designed in a functional programming language are inherently imperative, especially when you are using a multi-paradigm language like Scala or Java. There’s nothing wrong with imperative code, but it lacks the niceties of expression based composition that makes reasoning about your code so much easier. Also assignments used in imperative code are inherent side-effects that are best avoided (or at least minimized) in an expression oriented language.

In this session I will discuss some of my experiences of mining imperative code and refactoring them into functional patterns. You will be surprised to see how much functional goodness can be derived through functional thinking. Algebraic structures like Monoids, Monads and Kleislis are just buried within the reams of imperative statements crying to come out. In an exercise of half an hour we will liberate them and see how the code quality improves from the point of view of modularity, compositionality and simplicity.

The slides of the talk has been uploaded at https://www.slideshare.net/debasishg/mining-functional-patterns.

Swift’s strong functional programming support generates a lot of interest in adapting functional programming techniques to improve designing, developing, and maintaining Cocoa applications. This workshop will help you unlock this potential.

We will explore the foundations of functional programming and how functional programming helps to improve software development. We will start by discussing the main goals of functional programming, followed by surveying Swift’s language features that support functional programming. Then, we will look at how to put functional programming principles into practice using Swift. We will focus on immutable data structures, value types, and functional reactive programming.

= Value types

One of the biggest changes in the transition from Objective-C to Swift is the new type system. This change is at the heart of Swift’s language design, from optionals over value types to constrained generics, and to truly understand the language, a thorough understanding of its type system is indispensable. We will survey these type system features with special attention to value types. We will discuss how structs and enums in Swift can be used to help avoid bugs by design and how immutable data structures help to avoid unwelcome side effects.

= Functional reactive programming

Functional reactive programming (FRP) promises to replace unstructured side effects by structured change propagation in response to user input, network events, sensor activity, and similar. Typically explained by way of sophisticated, but often also complex functional reactive programming frameworks, such as ReactiveCocoa and RxSwift, it can be difficult to see the simple principles underlying functional reactive programming. In fact, these principles are sufficiently simple that we can explain them by building a functional reactive programming library from scratch.

We will discuss how we can construct our own lightweight functional reactive programming library out of simple components using Swift’s support for protocol-oriented programming. Moreover, we will discuss how to use this library to design and implement the change propagation between the model and view components of a Cocoa app.

All of this is illustrated with hands-on coding exercises based on simple iPhone application that incorporates the discussed techniques.

Summary: An Experience Report on How a very time constrained Haskeller learned Erlang and PureScript "in small pieces" to create programmatic opponents aka 'bots' for complex boardgames

Every experience report tells a story - the story of a project, unvarnished and without artifice, programmer to programmer, out of the sight and hearing of the manager folks, often involving one or more of comedy, tragedy, farce etc. This report is no exception.

I have a fulltime 'dayjob' and my standard 'language toolkit' is Haskell + C + Lua. My co-founder is a bit of an Erlang maniac, and challenged me to learn Erlang and actually building something in it and *then* go on about the superiority of Haskell.

This is the story of my response to the challenge and how I learned and coded Erlang/Elixir in very small chunks of time (about 10 - 20 )minutes a day max) and attacked an interesting problem. This severe time constraint (and lack of any previous knowledge of Erlang) shaped the nature of the (still evolving) system.

The problem:

The number of boardgames that you can whip out at a gathering and expect people to want play is very small.. Monopoly, Snakes and Ladders, and maybe, if you are *very* lucky, Settlers of Catan. And that's about it.

Getting people to play these games is relatively easy.

However the world of boardgames is *much* wider.

There are literally tens of thousands of boardgames that simulate everything from very abstract geometry puzzles to ones that simulate complex economies and political situations.

Some of the latter are used in very unexpected ways, e.g to train spies and military officers.

Here is an example of an interesting game.

A Distant Plain (by GMT Games) is a boardgame for 4 players that put them in the roles of the US military forces, the Afghan government, the Taliban, and Warlords/drug dealers, all competing for power in Afghanistan.

Here is another
The War of the Ring, a game for 2 players.

"In War of the Ring, one player takes control of the Free Peoples (FP), the other player controls Shadow Armies (SA). Initially, the Free People Nations are reluctant to take arms against Sauron, so they must be attacked by Sauron or persuaded by Gandalf or other Companions, before they start to fight properly ...."

And one more

"The battle of Sekigahara, fought in 1600 at a crossroads in Japan, unified that nation under the Tokugawa family for more than 250 years.

Sekigahara allows you to re-contest that war as Ishida Mitsunari, defender of a child heir, or Tokugawa Ieyasu, Japan's most powerful daimyo (feudal lord)."

."

What these games have in common
1. They are wonderful games, immersing you into their respective worlds.
2. They have (relative to Snakes and Ladders or Monopoly) complex rulesets, which take effort and time to master.
3. They are rarely played in India.
4. Even when people own them, opponents are almost impossible to find and schedule.

Which means that if you own these games and live in India, getting to actually play these games is close to impossible.

Which is a problem.

The (incomplete, but ongoing) solution

Being a programmer, I solve this problem by writing programmatic opponents (aka 'bots') to take the place of other players. This involves all kinds of interesting sub problems - game representation, logic processing for rules, building AI 'smarts' for your opponents, gui and event handling etc.

Since I am doing this in my non existent spare time, and this being a response to an Erlang user's challenge, I learned (am sill learning) Erlang and Elixir (and some minimal PureScript), and built ( am still building) the system at the same time..

This talk is about the many challenges I faced in building automated game players (and extracting common frameworks/libraries) from them, while simultaneously learning two FP languages.

Since this is an experience report, it is basically a highly subjective list of lessons learned, victories *and defeats*, what worked *and more importantly what didn't work*.

If you can't use FP at work, but are considering doing so on a personal project, or want to learn how to get going on an FP learning effort, you might benefit from my experience - both successes and failures. I also talk about how to go about learning Erlang/Elixir in the shortest possible time.

Monad transformers are a neat way to compose effectful computations: pass some configuration, read/write from disk, track errors... However they can be a bit cumbersome to deal with, especially if you want to use different stacks sharing some common effects: for example a stack to interact with AWS and another one for Hadoop computations.

This talk will shortly introduce monad transformers in Scala and their drawbacks then present the Eff monad.

The Eff monad has some really interesting properties:

• effects can be developed completely independently from each other
• effects can be interpreted in different ways and the interpreters can be composed together
• it is based on an efficient "Free monad" (avoiding the issue of quadratic flatMaps)
• with the Eff monad you will never have to re-implement the Monad operations (point / flatMap) again!

What I cannot create, I do not understand - Richard Feynman

Most of the time, we end up being consumers of a language. Language creation is not something which many of us do as part of our daily job. And as such, we become consumers of using various concepts like types of a language, functions-as-first-class citizens, closures, let expressions, etc. But what are these? What is semantics behind them? And how do language creators enable a language to have these? Once we understand what these mean, we go beyond the language specific implementations and can be true polyglots who can think in terms of these composable abstractions.

This beginner focussed talk+demonstration hopes to clarify few fundamental concepts by building a language from the ground up. This talk has its foundations in a couple of academic courses which I got to be part of during 2012/2013.

Using Racket(a variant of Scheme) as a vehicle, a hypothesized programming language (MathL) is introduced with its specifications, syntax, and rules. And slowly this language is built up with more features.The language is realized via an interpreter/executor. [We would not be discussing compilers here].
Some tests also would be done which would help to verify the language implementation.

Programming in Scala is sometimes very time consuming. Finding the most efficient way to solve a problem can end up in days of frustration. This talk is a story of trail and error with a twist at the end. It's a story of API endpoints, generic programming, Shapeless and what happens when they all come together. Everything with examples and plenty of code.

In 1991 Erik Meijer, Maarten Fokkinga, and Ross Paterson published "Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire." This paper is a classic one, widely recognizable in the FP community. Constructs described - known as recursion schemas - have real world applications. Strictly speaking, explicit recursion is the ‘goto’ of pure functional programming. Recursion schemas provide same level of sanity as loops did for structural programming back in the day.

Over the years a lot of the progress have been made. Papers like "Recursion schemes from comonads" by Tarmo Uustalu, Varmo Vene & Alberto Pardo or "Unifying Structured Recursion Schemes" by Ralf Hinze, Nicolas Wu & Jeremy Gibbons - pushed the concept forward.

This talk is about generalization of a very specific recursion schema (called catamorphism) over fixed point data type. After providing introduction the concept of catamorphism, we will jump straight to fix point data types trying to solve some real-world problems. Code examples are in Scala. Code examples use Matryoshka - which is an open sourced project design to generalize folds, unfolds, and traversals for fixed point data structures in Scala.

Application configuration and initialization are tangential to delivering business value, yet we frequently get bogged down by their incidental complexity. They crosscut various (Dev/QA/Prod etc.) environments and impact the workflow in subtle, disparate ways. In this session, I will discuss the experience of tackling this beast for several projects in a large team using an elegant functional programming approach. The approach was turned into a data-driven Clojure framework for applications to use. This success story is over two years old in production and it scales from a junior developer looking to learn the ropes to experienced folks focusing on advanced use cases. I will discuss the fundamentals of this approach, how it is used in production, in QA, and in development. I will also share the REPL-enabled development workflow and how it facilitates automated unit and integration testing.

Apache Beam (based on Google’s Dataflow Model) provides a simple, unified programming model for both batch and streaming data processing. If only it wasn’t so unfamiliar and verbose for our Scala engineers. Learn how Scio leverages Scala’s type system, macros and functional paradigm to provide more engineer-friendly and type safe API.