2019/2: On the "inevitable" triumph of FP
I like mathy and abstract things, I am pedantic and I am a developer. So of course I'm interested in Functional Programming.
Who wouldn't? The idea of building software on strong foundations and deriving our work from solid theory is enticing. And yet, I think it's safe to say that most software built today is not FP —unless you define FP as "having functions as first-class citizens".
I don't know why that's the case, and I don't want to guess (at least not right now). I am more interested in a prediction. If software built with FP is more maintainable, non-FP projects should have higher chances of dying under their own complexity, and so the difference in the amount of FP vs non-FP software should shrink over time.
This proposition has a lot of errors, and I think they can be illuminating.
The first error, and IMO the most obvious, is that a software project can die for a lot of reasons besides its quality. Maybe there is no market for it, or a better competitor appears, or every single person working on the project dies at the same time under strange circumstances. Maintainability can help: a more maintainable project can adapt better to a changing market or copy the competitor's features faster. But it's hard to think of some successful piece of software dying only because its codebase was bad (see for example this horror story about the Oracle Database; do you think Oracle will die any moment soon?)
The second error is thinking that FP is the only path to maintainability. This is the favourite argument of FP contrarians: you don't need no fancy monads, you need to write more unit tests! And while I think this counter-argument is in itself flawed (it's like saying you don't need airbags in a car; you need better seatbelts instead), the main idea is right: the same way software quality is just a factor in a project's success, FP is one of several techniques towards quality.
And the third error is one I've been consciously making from the beginning: talking about FP like it's a binary thing that you either have or you don't. FP, as I understand it, is a collection of principles and techniques: use functions as building blocks, avoid mutation as much as possible, make complexity explicit (my favourite), etc. It's hard to draw a neat line between doing and not doing these things. (And while we're at it, this is also the reason why the whole FP vs OOP flamewar is nonsense: you can apply principles and techniques from both camps.)
There's something else related to this false dichotomy: many of these things are already showing up in mainstream programming. Almost every modern language I know has functions as first-class citizens (or something similar enough). React and Redux popularized immutability in frontend development. Maybe React Hooks are a start towards the "making complexity explicit" thing?
And yet, I have the feeling that a hardcore FP programmer would say that this is not enough, that there's more to FP than the stuff I mentioned. Maybe they would be right, but this also reminds me of the Artificial Intelligence effect: «AI is whatever hasn't been done yet.» Perhaps we should say: FP is whatever the JavaScript guys are not doing.
Is there some point to all of this? I don't know. What's clear to me is that, as so often happens, economy is king: everything is a trade-off, etc. But I think there are some good questions that arise from thinking about this:
- Can we measure the FP-ness of a project? Or is it like trying to say what percentage of a novel is science fiction? Is there something like a cyclomatic complexity but for the amount of mutation in a project?
- What can we learn from the way those FP techniques became mainstream? Can that be done again to popularize more stuff from the FP rabbit hole?
- It's very likely that research in FP is advancing much faster than the rate at which is being adopted in mainstream. Is there any conclusion/prediction to draw from this fact (assuming it's right)?
- A lot of this assumes a capitalist/profit maximizing context. Open source is often outside of this logic. What does this mean for FP? Shouldn't we see more, say, Haskell projects that are so undeniably good that everyone builds over them? (Maybe Pandoc is an example of this.)
- Are FP and agile methodologies compatible?