X-perience: Functional Programming

Some consider it an unholy arcana. Others hail it as the future of programming. What cannot be denied, however, is that, with the advent of Redux and Elm, the interest in functional programming has exploded.

We have talked with an X-Teamer who has been a part of the functional programming community for a long time. Michal Kawalec, a dedicated member of the Haskell community, has shared with us his thoughts on all things FP.

Michal, thank you for doing this interview. Let me begin quite generally, if you had to sum up your thoughts on Functional Programming in just a few sentences, what would they be?

My take is that FP languages are the next step in the evolution of programming languages and that they allow for a clearer expression of ideas than Object Oriented/imperative techniques. However, we have to remember that there are some domains where OO still shines, mostly because it is more complex to map some functional concepts onto real-life hardware efficiently.

That being said, this field is small and getting smaller day by day, for instance with soon-to-be addition of linear types to Haskell.
 

Would you say that Haskell is a good language for one’s first foray into the world of FP?

The language to start really depends on a person - I am the kind of person who likes to bang his head against the wall for a while for that 'aha' moment, so Haskell is awesome for me. But many people are very productive in Clojure, Ocaml, Elm or Scala, so just choose what you fancy.

Ocaml is actually overlooked nowadays and it has a lot of features appealing to newcomers: Big projects (Flow), a good but less restrictive (than Haskell’s) typesystem, and it is crazy fast (around half the speed of C++), to name a few. It is lacking in tooling compared to Haskell, but could still be interesting to check out.
 

What about the language that has been conquering web developers’ hearts lately, Elm?

I think Elm is great but suffers from some key weaknesses. It is perfect for familiarizing people with Haskell-like syntax, the code it generates is really fast, It has a decent typesystem, solid theoretical foundations, and a maintainer with a good grasp of theory.

However, its strengths are also its weaknesses. While the typesystem is better than, say, Flow or cpp, it is still impossible to express a great many concepts from Haskell in it - no higher order types, no generalized algebraic datatypes, no typeclasses (!), no guards, nor a host of other features. It is great that Elm does not have these things from a learning perspective, as it is way easier to pick up, but after you pick it up, you are left without some of the strongest tools in the toolbox.

Elm’s other problem is the bundling of a programming language with data-flow concepts. This causes any major update to your dataflow ideas be a breaking, programming language-level change, completely blocking past code from functioning, unless maintainers do a time-consuming upgrade procedure. This is bad and has already taken its toll on Elm's ecosystem.
 

Do you believe that functional programming may become the most popular paradigm on the frontend, with the whole DOM generated by pure languages, not only JS-based React/Redux?

Ha! That is one of the reasons why I love doing frontend – because it is full of wonderful people who are open to accepting better solutions when they see them. And I think there has been a bit of a death pause in concepts in JS for the past two years we got Angular, we got React, we got Redux and now we are kind of stuck in search of better paradigms. And there is a lot of win to be had, not on the level of new libraries but rather of new programming languages that enable us to write code that just works.

For instance PureScript is a lightweight alternative to Haskell that compiles to small JS. You can actually compile any Haskell library (with tiny caveats here), but your bundle will be quite big (probably 500k of boilerplate libs and scaffolding to lift the whole thing), so it is slightly impractical.

There is also this thing BuckleScript for OCaml lovers, which aims to be super-fast, tiny and awesome.
 

What would you say are some of the more immediate benefits of FP?

Consider that with a strongly typed functional languages you can guarantee data immutability at compile time - you do not have waste time in runtime on doing the checks like you have to with JS

Another great thing about functional languages is the true TDD - Type Driven Development. You can have tests for your functions be generated automatically, and the only thing you have to do is define the behavior of your functions. This makes writing tests more fun and makes the testing library work hard at trying to find test cases that do not work, not you.
 

What are your thoughts on more esoteric functional languages, like Pony and Idris?

I am really interested in Idris, but I have not tried it enough to have a useful opinion about it. It is great that you can have a proof of your program doing the right thing, but it is just too much work to do complex practical things in it. Type-Driven Development With Idris is on my todo list, though.

Also, I think any functional language you pick up is going to be of great help in programming in general. After all, what takes the most time is not a particular syntax or libraries, but rather adapting to a different way of thinking.
 

With that different way of thinking in mind, what are the steps you would take at the planning stage of a project when using the functional programming paradigm? I.e. where do you start, and what are the main differences at this preparation stage in translating project requirements to code in contrast to how you would go about the same in an OO project?

It is hard to put in words, but I guess it is something like thinking more in terms of transformations of data than entities that do something. So data is the basic constituent and things happen to it.

It does not change project planning in any way, it is just a different coding style.

I write JS and some C++ currently. In both, I am trying to compose functions that work on data, keeping internal state to a minimum. I have also brought a typechecker (Flow) to our JS, and we may be rolling it out to the wider environment with the client I work at soon-ish.
 

How mature do you feel is the ecosystem around functional languages at this point?

There are already modules for many things, so in some cases you would have to write even less, and in some more, than you do in python or js.
 

Finally, to top everything off with something “lighter”, what do you think is best non-technical characteristic of FP languages?

One thing where Haskell absolutely shines is the quality of people in its community. It is small and pretty tight-knit and, because there is little money in Haskell (though this is changing fast), mostly composed of people doing it because they believe it is a better way of programming or because it is hard, or because it is fun.

There you have it, dear reader - be it because you want to try something many believe to be a better way, because you like to challenge yourself, or because you like to have fun with something completely different, you definitely cannot go wrong with testing your coder’s mettle with a functional programming language.