Programs are getting fat. They're becoming slow. They're taking up more computing resources. They're getting harder to maintain and more complex from the ground up. Layer upon layer of sophistication is causing us to lose our ability to predict what software will do. Where's that bug? Why is everything going so slowly? Am I even using the right data structures? Where's that important point in the documentation again?

What's happened to us? In this meta-dive into the nature of our approach to programming, we will explore some of the dangers of our current approaches to programming and the how/why of our current programming obesity problem. We will look at real case studies and see just how bad the situation can be.

But we will also explore how we can battle these sources of obesity. In this passionate plea for code that we can gain control over again, we will look at examples of how we can return to a state of high-performance on all levels, from code size to code scalability. We will look at the principles that can help us to reach leaner, more efficient, more usable, less buggy code. We will hopefully find some light at the end of the tunnel, and how we can change our outlook on programming to push ourselves towards code that benefits not only ourselves, but also those that will come after us.

If you are writing a stateless web application backed up by a database, there is a good chance Elixir is a great fit. However, this is not where it shines. In this talk, we will discuss how to architect Elixir applications in order to leverage the features of the language and of its runtime.

Sylvester is an F# DSL for scientific computing which implements an advanced type system where vector, matrix, tensor, neural-network and other types have numeric properties like dimension sizes, rank, layer node size, etc., encoded as part of the type. Type-level constraints for operations like matrix multiplication or network layer construction utilize the F# type checker as a type-checker for linear algebra and other mathematical domains which allows for type-level verification of mathematical operations and for Intellisense-enabled IDEs to provide immediate feedback that helps the user avoid errors in mathematical expressions..

One of the strategies being adopted by RoR or Java software developers in adopting Elixir is they have not yet adapted themselves to unlearn the OOP in developing the web systems. This has caused OOP concepts to creep into full fledged Elixir systems. This presentation seeks to highlight these subtle points that need to be avoided to make the code more FP and less OOP.

Functional Programming is going through the same process of rethinking as Object Oriented Programming has passed already. FP today is not only something mystical, something barely applicable for day-to-day tasks, but rather a whole philosophy of building big, complex applications, with own tools, approaches and methodologies. We can see a lot of ideas about software design and architecture emerging from the FP community: talks, books, articles. We’re actively discussing Final Tagless, Free Monads, effect systems and other approaches, but it seems the theme not yet covered and we don’t know about possibilities we have.

In this talk, I’ll tell you about the power of Free Monads in building complex applications in Haskell and PureScript. These applications will be satisfying the requirements like maintainability, testability, simplicity. You’ll know how to create a safe concurrent application state, how to divide the application into layers and how to keep the code sane. In fact, you can do the same with Final Tagless or extensible effects, but the approach with hierarchical Free Monads has some specific properties making it the best tool to separate concerns and create a very interesting eDSLs with different semantics.

The talk is based on the ideas I’m describing in my book “Functional Design and Architecture”. I also gave several talks about this theme earlier (you can find all my talks here).

I’ve used these ideas to build software for different companies, including Juspay (Bengaluru), Restaumatic (Poland), Enecuum (Hong Kong). We’ve created several interesting technologies that were not possible to make without Free Monads. Some of them are open sourced.

APL is getting a lot of attention lately due to its potential for very high performance portability and suitability for both rapid prototyping of complex solutions as well as deployment of complex algorithms to high-speed, modern parallel hardware. It has the potential to vastly improve the speed, scalability, and size of your code bases. But APL has a reputation as an intimidating language to learn.

In this back to the basics tutorial, we will explore the core of APL, and focus on those areas that usually trip up the beginner in learning APL. We will also walk you through how to approach an APL expression, how to reason about them, and how to read them efficiently. We will teach you the skills that the expert APLer has internalized, and how you can work through these skills externally and explicitly in a way that will help you to eventually internalize these critical skills in a way that makes you efficient at using APL on real world problems.

Most talks on APL at FunctionalConf have focused on the way array oriented programming allows you to quickly deliver concise and efficient solutions to problems with an analytical core. This talk will focus on the development environment, and follow the life of an APL code snippet from it's interactive discovery, via testing and debugging, through to delivery as a web service and a shared object, embedded into a solution implemented in Python.

Have you ever wondered how we can build a real-world, production-ready, end-to-end application using the functional programming principles? Immutability, Pure Functions and all other functional programming things sound good on paper but How can we build something useful by applying it?

At Ajira, We recently built an e-commerce marketplace middleware in Clojure for a leading retail chain to sell their products on multiple e-commerce sites seamlessly. In this case study, we are going to build a minimal version of this project using which I will be sharing how we implemented it.

'Let it crash' gets thrown around a lot in the Erlang community. An experienced
programmer (with understandably different experiences) on first encountering
this idea in Erlang is often found asking what we let crash? And what happens
after?

I will attempt to answer this question.

Erlang puts distributed systems programming ideas front and center. We'll also
talk about this in the context of letting processes crash and how that affects the
design of our software.

Over a period of 7 years, we have applied Haskell across Web apps, compilers, parsers for our customers across various industries. This is our report on how some of the unique features of Haskell have not only helped us create stable production environments but also break barriers. On the other hand, there is a high cost of on-boarding new developers and few other pain points. So, is Haskell worth the investment?

Debuggers are one of the most essential tools for any kind of development.

Debuggers in Lispy languages make use of Lisp's homoiconicity. They are a bit different from debuggers for languages like C or Java.

This kind of information is usually not needed in day to day development and hence it remains hidden.

In this talk, I will take Clojure's cider-debug as an example and explain how it uses homoiconicity. Along with cider-debug, I will also talk about REPLs and how REPL client-server communication happens (with nREPL as an example).