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.
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.
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.
This is becoming increasingly true as the years pass and the number of times I've had to drop whole mature architectures and reimplement something worse because some engineer's feefees got hurt can no longer be counted on my fingers & toes.
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.
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.
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.
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.
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 ...
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++).
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.
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.
skybrian•2h ago
Code review or pair programming might help here, to learn the team’s common idioms.
IshKebab•1h ago
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•1h ago
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.
delta_p_delta_x•54m ago
Unironically, C++.
ndriscoll•44m ago
Mond_•1m ago
> Unironically, C++.
At best C++ falls under "equally unergonomic".
Philpax•26m ago
amluto•20m ago
Compare to most "functional" languages, in which prepending an item to a list and ending up with immutable references to the old and new lists is almost the defining feature of the language.
IshKebab•4m ago
jen20•1h ago
elevation•43m ago
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.
vjerancrnjak•33m ago
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•32m ago
/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.
ekidd•13m ago
"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.)
IshKebab•2m ago
jazzypants•1h ago