How to stop functional programming (2016)
46 comments
·September 21, 2025astrobe_
dimal
> When writing code you have the motto "don't make me think" in mind
I disagree with this phrasing. We’re engineering after all. The entire job is thinking. If someone doesn’t want to think, then they shouldn’t be a programmer.
Readability matters, though. I try to have a narrative structure in my code, so it leads the reader along. Formatting matters. And documentation helps. If you want to introduce an unfamiliar idiom that might be more functional, good, but document it. Share it with the team and talk about it. I know that writing and reading documentation is usually seen as a waste of time unless you’re doing it for AI, but I’ve seen it work well in multiple teams. In my experience, the teams with poor docs have the worst code.
politelemon
Teams are not a static concept, they change members over time and so talking to them has a net zero effect. The newer members will not understand this clever new concept that was introduced, worse, they will misunderstand it or work around it. Which brings us back to don't make me think. If the concepts can be kept as simple as possible, which overlaps greatly with readability, it will have achieved its purpose.
odyssey7
"I didn’t have time to write you a short letter, so I wrote you a long one." -- Mark Twain
It's difficult to explain how to write well, but bad writing and bad computing systems typically impose far greater cognitive burden on readers than might have been necessary. There is an art to software engineering.
Functional programming does involve idioms, though I would say no fewer than imperative programming, or OOP, or some other paradigm. One of the overarching themes of FP is to reduce the cognitive footprint to only the essential properties of the problem to be solved.
A novice artist can produce a recognizable figure using many pencil strokes. It takes a master to produce a compelling likeness with only the lines that are necessary.
firesteelrain
> one has to think about the "audience"
This 100%
When I am doing MBSE, and I discuss what level of detail is required in my abstract models one of my senior coworkers would remind me to “know your audience”. It has helped me and I use the same phrasing when I am coaching my teams now.
ChrisMarshallNY
Well, this is one of the reasons that I like coding for myself. The pay sucks, but I don't have to bowdlerize my work.
When someone pays me to write code for them, they get to call the shots; even if I think their judgement sucks.
If they want to hire incompetent programmers, that can't understand even halfway-advanced code, then that's their prerogative, and I need to suck it up, and play by their rules. These may include the need for me to write code as if I just started yesterday, because it will need to be maintained by folks that, um, just started yesterday.
apalmer
Ultimately the important thing is that the development team align on the style of programming that they will use at least per project. And the larger the codebase and more developers working on it the more important the consistency in implementing the style guide is.
Imperative programming style has many advantages over functional for some problems. Functional programming style has many advantages over imperative for some problems.
The only clearly 'wrong' approach is codebases where you can look at the code and determine a specific developer on the team wrote feature x because it fundamentally looks completely different from the other sections.
skybrian
Apparently, someone doesn’t really get what makes functional programming hard to understand? It’s not writing the occasional pure function.
Code review or pair programming might help here, to learn the team’s common idioms.
IshKebab
Yeah this 100%. FP isn't hard because of FP - it's all the other things that popular FP languages come with that makes them hard to understand. Arguably most of them are not related to FP; they're just style choices:
1. Global type inference.
2. Implicit syntax (no brackets for function calls, commas to separate arguments, semicolons to end statements/expressions, etc.)
3. Currying & point free style.
4. Tendency to have very deep nested expressions. The gap between `let foo =` and it's actual value can often be hundreds of lines.
I'm sure you can write FP code that avoids these issues and is easy to follow but it doesn't seem like people do that in practice.
Rust avoided all of these issues fortunately.
(Oh I forgot about monads.)
amluto
Also: avoidance of mutable state, even locally. A lot of functions can be more straightforwardly expressed using mutable variables and data structures, and most functional languages can handle local mutable state, but a lot of code in functional languages avoids it.
Conversely, a lot of code written in imperative languages would be clearer and/or less bug-prone if it avoided mutable state and used persistent data structures.
I wish there was a mainstream, high performance language that made both styles equally ergonomic.
Philpax
Does Rust not meet that description?
null
delta_p_delta_x
> I wish there was a mainstream, high performance language that made both styles equally ergonomic.
Unironically, C++.
elevation
> I forgot about monads
I've been solving business problems with code for decades. I love pure, composable functions, they make my job easier. So do list comprehensions, and sometimes, map and filter. Currying makes sense.
But for the life of me, no forum post or FP tutorial that I could find explained monads in clear language. I've googled "what is a monad" once a year, only to get the vague idea that you need monads to handle IO.
I wondered if my brain was broken, but now I'm wondering if most FP adherents are simply ineffective communicators: they've got an idea in their head but can't/won't express it in a way that others after them can understand. In other words, the exact same reason why TFAuthor was corrected by his employer.
ekidd
So, one way to understand a monad is that it's essentially a container type with "map" and "flatten" operations. Let's say your monad is type M<T>. The "map" operation allows you to take a function T->U and a container M<T>, and transform each element, giving you a container M<U>.
"Flatten" takes a container of type M<M<T>> and returns a container of type M<T>. So a List<List<Int>> becomes a List<Int>.
Now comes the trick: combine "map" and "flatten" to get "flatMap". So if you have a M<T> and a function T->M<U>, you use "map" to get an M<M<U>> and "flatten" to get an M<U>.
So why is this useful? Well, it lets you run computations which return all their values wrapped in weird "container" types. For example, if "M" is "Promise", then you can take a Promise<T> and an async function T->Promise<U>, and use flatMap to get a Promise<U>.
M could also be "Result", which gets you Rust-style error handling, or "Optional", which allows you to represent computations that might fail at each step (like in languages that support things like "value?.a?.b?.c"), or a list (which gets you a language where each function returns many different possible results, so basically Python list comprehensions), or a whole bunch of other things.
So: Monads are basically any kind of weird container that supports "flatMap", and they allow you to support a whole family of things that look like "Promise<T>" and async functions, all using the same framework.
Should you need to know this in most production code? Probably not! But if you're trying to implement something fancy that "works a bit like promises, or a bit like Python comprehensions, or maybe a bit like Rust error handling", then "weird containers with flatMap" is a very powerful starting point.
(Actual monads technically need a bit more than just flatMap, including the ability to turn a basic T into a Promise<T>, and a bunch of consistency rules.)
null
vjerancrnjak
I felt similar with lenses. The problem lens solve is horrible. You don’t even want that problem.
FP can be the pragmatic as well. You’re going to glue up monad transformers, use lenses like there’s no runtime cost, and compute whatever you need in days but at least you know it works. Maybe there’s accidentally quadratic behavior in lifting or lenses but that’s by design. The goal is to just throw software at things as fast as possible as correctly as possible.
eddlgtm
Monads are just monoids in the category of endofunctors.
/s
Monads are, in my head, just a wrapper around a type. Or a box another type is inside. For example we can have an Int and we can put the Int in a box like Maybe<Int>.
Imagine Python code that gets a value from a function that is an Int or None, then another function that takes an Int and returns an Int or None, then another function that takes an Int and returns an Int or None. How hellish is that to handle? If not None, if not none, if not none, ad nauseam...
In Haskell I could use a Traverse function that takes a monad and passes the Int value to the next function or handles the None error, avoiding all the boilerplate.
Other Monads are like the State monad - a box that contains some variables I want to maintain over functions.
Or an IO monad to handle network calls / file calls.
It's probably not a perfect analogy, but I work with functional languages and it tends to hold up for my beginner/intermediate level.
jen20
Also the unwillingness of so many enterprise developers to learn anything that wasn't commonplace in 2001, regardless of whether they were in the workforce by then.
jazzypants
This is written by the same guy who made a big stink about how JS promises weren't pure monads and somehow that was a problem-- a zealot, in other words.
nor0x
Would be interested in an article about stopping OOP. I see myself often drifting towards classes and abstractions once my code grows in complexity
jmmv
Missed chance to do something like:
class User:
def calculateCoworkers() = {
this.coworkers.clear()
for { d <- this.departments }
this.coworkers ++ d.employees
}
user.calculateCoworkers()
... many lines after ...
for { c <- user.coworkers }
... do something ...
flohofwoe
When did method chaining become 'functional programming'?
It's not 'functional programming' that makes the code unreadable, but overly long chains of array-processing functions. Sometimes a simple for-loop which puts all operations that need to happen on an array item into the loop-body is indeed much more readable.
mrkeen
> When did method chaining become 'functional programming'?
As soon as you stop calling it "method chaining" and start calling it "function composition".
If you chain together a bunch of methods ('.' operator) in an OO setting, that's called a "fluent interface". It's a sign of good design and is to be commended.
If you compose a bunch of functions ('.' operator) in an FP setting, it's an unreadable mess, and you will receive requests to break it into separate assignment statements and create named variables for all the intermediate states.
jolux
> When did method chaining become 'functional programming'?
It's very similar to applicative style in FP. Conceptually, method chaining is equivalent to nested function application, it just comes with syntax sugar for specifying the `self` parameter.
null
_aleph2c_
The manager solved the wrong problem. People should be sharing their tricks with each other. This was a perfect time to set up some peer-to-peer training.
jen20
Or in the age of AI, "have you asked Claude to explain what the code does so you can learn something?"
seanhunter
By the looks of the code snippets he should have explained that he’s not doing functional programming, he’s just writing unnecessarily non-idiomatic python code. I’m sure his manager would have understood.
ndriscoll
The code snippets are Scala. The first snippet is idiomatic. I can't imagine a team adopting Scala and complaining about functional programming though.
mrkeen
I've been there. One of the more functionally-minded devs wrote something to do with putting Keys and Values into some kind of json store, and a less functionally-minded dev complained about all the type variables - Ks and Vs I guess.
tengbretson
I thought "idiomatic Scala" was an oxymoron.
cies
FP code is often easier to read (the article provides a case to that point).
What gave FP a bad rep is, i guess, Haskell (and the "pure functional approach w/ monad transformer stacks").
Every shop I worked at the devs were already at a level that they'd appreciate FP code: easier to read, refactor and test.
The tendency is also towards FP: see the features in recent Java/C# version. Or languages that gain popularity recently (Kotlin, Rust) are more FP'ish than their predecessors (respectively Java and C++).
macintux
(2016)
Beyond the satire, one is supposed to write code which is readable, and like often with written works, one has to think about the "audience", the readers. When you write technical documentation, you have to decide ahead of time the expected skill level of the reader - often that decision is written too in the intro as "prerequisite(s)".
When writing code you have the motto "don't make me think" in mind, but how to know what's the maximum level of trickiness for readers? There are familiar techniques and idioms when it is your main programming language, but they are not for someone using this language on the side.
In any case, neither code nor comments should be tutorials. To a reasonable extent, it is up to the reviewer to do their homework or just ask. Then based on that interaction you can add a comment or a parenthesis, or uncompress a bit the code. But not to the point that it means to "dumb down" things, because it is a downward spiral.