This is indeed a very interesting question! I’ve also asked myself that time and time again, along the path of slowly discovering what this FP thing is all about over the course of my career. It does look wonderful, it does save you a lot of effort in some cases, where “some” is a vast swathes of computational problems. And its so damn elegant.
A lot of examples are thrown around were a bunch of lambda calculus can result in 10-20 fold reduction in source code size. So where’s the catch?There has to be something wrong right?
Well recently I stumbled upon a clojure conf talk that tried to tackle precisely this question. https://youtu.be/QyJZzq0v7Z4
The short of it is that its more of a historical inertia and chance than any specific hidden gotcha. Fascinating talk.
I'm sorry but this all strikes me as rather delusional.
The reason why functional languages doesn't take off is because programming languages are tools, not an end in themselves. Carpenters that are obsessed with perfecting their power tools would rightly be out of a job in a very short amount of time. Furthermore most of these "perfections" aren't even virtuous - in the sense of searching for improvement - but just self-indulgence and aesthetics.
Functional languages are dense, hard to read, have a high cognitive load, and are thus unproductive beyond the proverbial garage startup. They are also designed and used mostly by mentioned power tool decorators rather than practitioners, with the inevitable end result.
Totally understand the sentiment. I was very dismissive at first, as a self thought dev. Its really hard for me to learn something unless its helps directly to solve a concrete business problem I’m facing, so I know where you’re coming from.
I think my epiphany was when I was trying to learn me some clojure on a couple of weeks sabbatical from work.
As a mostly js/frontend/react dev at the time I was deep into React ecosystem for building SPAs. I knew and largely disliked the amount of code a redux based app would require in order to be “complete” with all the data fetching and state management (this was before hooks and contexts). And then I sew re-frame, that implements a lot of the features in that whole ecosystem, in like 100ish lines of code.
Thats BS I told myself. Things are missing! It cannot be just this code in front of me. But no, it was all there, just elegant and clear. All of the “meat” of the logic distilled to its essence, without any of the boilerplate.
It was just that I had to learn all the “higher level” stuff around FP, but it turns out those things are shared and repeated in lots of places, so once you index it in your brain, you can read the business logic itself, without all the additional “fat” of the code. Simply beautiful.
> As a mostly js/frontend/react dev at the time I was deep into React ecosystem for building SPAs.
Not to be too dismissive but I think that's the problem. Modern SPAs with React et al are very bloated and imo a massive wrong turn compared with the simple boring tech that was before it, with very little gain to show for it as well.
"Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities. Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance." - Eric Evans
A lot of examples are thrown around were a bunch of lambda calculus can result in 10-20 fold reduction in source code size. So where’s the catch?There has to be something wrong right?
Well recently I stumbled upon a clojure conf talk that tried to tackle precisely this question. https://youtu.be/QyJZzq0v7Z4
The short of it is that its more of a historical inertia and chance than any specific hidden gotcha. Fascinating talk.