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 ...
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.
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.
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.
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.
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.
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; which 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.
Would be interested in an article about stopping OOP. I see myself often drifting towards classes and abstractions once my code grows in complexity
This literally happened to me with Functional Reactive Programming, around the same time frame (2016.)
I still have to advocate for minimizing mutable state. At least since then, popular languages and frameworks are putting in a ton of work to make functional programming look more like the imperative spaghetti that is still prevalent and taught.
Thought the title read, “How to _slop_ functional programming,” and got excited. “It’s happening!!!”
I do love a bit of FP. Here's the canonical Hello, World! program.
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE QuasiQuotes #-}
{-# LANGUAGE TemplateHaskell #-}
module Main where
import Foreign.C.Types
import Language.C.Inline qualified as C
C.include "<stdio.h>"
C.include "<stdlib.h>"
main :: IO ()
main = [C.block| void {
system("python -c 'print \"Hello, World!\"'");
} |]when I see the word function or someone uses parenthesis to call one, it clearly is fp. Management was clear that this would not be tolerated, this source is too addictet to the good pure shit.
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++).
(2016)
My final days at Planet Labs involved me telling people "oh hey, I'm going to do this functional thing" and everyone saying "oh wow! that's great!" And then I went around to key engineers and explained in detail what I was doing in the code and they said "OMG! THAT'S AWESOME!" And then I checked it in and the response was "I HAVE NO IDEA WHAT THE FUCK YOU'RE DOING HERE!?"
Yeah. I don't want to work with those people. Did I quit? Was I fired? I can't really remember. But ultimately, I moved on to a better environment.
Using Scala and then complaining about unnecessary complexity is a bit much. Like, if you made the technologically brave decision to use a niche language like Scala that isn't just a slightly better Java like Kotlin then you'd better expect to accommodate the inexperienced developers by training them, possibly via pair programming, instead of constricting the experienced developers.
There's only one universal lesson that I've learned over my 25+ year career so far and it's that software engineering types are fragile creatures whose egos must be tended to. Delicately.
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.
If this code is too complicated for you then you should reconsider your career.
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.