_Disclaimer: this post is not intended to provoke or troll anyone. The idea isn't to present any language / paradigm as better or worse than any other. I have friends who prefer (& use on the daily basis) all the technologies mentioned below - I respect all of them as not only great guys but also top-notch professionals.
TL;DR - modern Functional Programming is quite diverse, but all the available languages seem to fall into one of two "families", identified by the background of their makers: scientific ones & engineering ones. Interestingly, people who favor particular languages from these families approach FP (as a paradigm) in a very predictable way ...
I don't find myself a Functional Programming (FP) zealot, but I appreciate its advantages & use few FP languages pretty much on daily basis. I would never call myself an active member of FP community, but I keep myself pretty much up-to-date with what's being cooked & I occasionally attend the events - i.a. recent Lambda Days 2017. This post is about one particular observation I've made regarding this community some time ago - it keeps coming back to me quite frequently & I've finally decided to write it down.
There seems to be a huge split that has polarised the community - a gap in attitude, "philosophy" / approach to FP. This split (fortunately) doesn't seem to antagonize people at all - guys'n'gals just keep to their own side, based on individual preference.
The sides are defined by main "language of choice" or rather (to be more precise) by its origin. There are two, clearly distinguishable "families" of FP programming languages:
- ones invented by hardcore scientists (usually mathematicians) - like Haskell or Scala
- ones invented by hardcore engineers - like Erlang or Elixir
What I find particularly interesting is completely different approach to FP by people who prefer 1st family or the 2nd one:
- while the latter ones appear to prefer simple, straightforward, practical solutions & don't seem to care much about advanced algebra at all & just use FP "features" (like function composability or immutability) that are built-in as syntactic elements of their preferred languages ...
- ... the former ones tend to go all out with the rich theoretical background & "masturbate with lambda calculus" (not my words, but I find them quite funny ;>) by embracing (& applying) free monads, catamorphisms, advanced category theory, algebraic data types, etc.
E.g. while Scala gets more & more increasingly popular pure-FP libraries (e.g. scalaz, cats, shapeless, monocle, eff) that operate on algebraic constructs & terms, Erlang barely has any ... (and this lang is 31 years old). What is more, if you ask any of experienced Erlang programmers or anyone from Elixir influencers about that: they don't really feel the need for such library.
Of course it goes far beyond the code itself - just compare blog posts, conference talks or podcasts - you'll see the same regularity. Have you seen Erlangista deliberating about Grothendieck group? Or maybe you've met Scala hacker who wasn't transfixed by famous Red Book?
See? That's why I'm writing about.
Diversity is good
"A monad is just a monoid in the category of endofunctors."
every Haskell aficionado ever
Obviously, there's nothing wrong about that, quite the opposite: everyone can pick her/his "weapons of choice" - the ones that fit individual's personal style. Both paths may work if applied correctly & given enough thought. In the end in both cases you'll be dissecting problems into pipelines of composable functions - the main difference will be about the conceptual models used & their atomic building blocks. These will:
- either closely reflect the mathematical foundations (which has a steep learning curve & may skyrocket the overall complexity, BUT expands your arsenal with strongest possible scientific tools)
- or be limited to the essence provided by concise, purely essential, "distilled" constructs that may (& do) sacrifice scientific purity for the sake of being easy-to-use & fit for engineering-driven purpose
This is one of the best things in software development today. It's so great to have a choice.
Pic: © Africa Studio - Fotolia.com
