Comment by jongjong
2 years ago
The way I see it, functional programming converts are often people who failed to properly grasp other, more challenging methodologies and decided that they need training wheels on their bikes. Though they won't frame it that way of course; they'll say that other methodologies lack the 'proper guardrails' which is telling...
I'm yet to meet an FP fanatic who actually properly understood OOP. Few seem to even understand the core principles of 'high cohesion, loose coupling' and fewer are even able translate that into a programming methodology.
My view of FP proponents is the opposite as the author claims. They're not rockstars who can master anything. More like the opposite; they're often people who are incapable of taking something complex and simplifying it. They're people who can't keep complexity under control and they need an external tool to do it for them.
> they're often people who are incapable of taking something complex and simplifying it.
Excuse me? Haven't a ton of things in recent years been simplified by borrowing ideas from FP? LINQ in C#, Flask route decorators in Python, React Hooks and Redux reducers, Rx in Angular, Kafka streams, and more?
> Few seem to even understand the core principles
They do understand specific pain points experienced outside of FP - side effects, mutable state, uncontrolled complexity. Many FP proponents are well-versed in OOP but choose FP for reasons like simpler state management, declarative syntax, and powerful concurrency models.
> They're people who can't keep complexity under control
> they're often people who are incapable of taking something complex and simplifying it.
FP langs specifically provide advantages for easier reasoning about code, deterministic functions, and improved reusability. Why would someone willingly want to try and take control of exploding complexity if they have already know better tools to manage it? Tools that they understand more thoroughly and that feel more "natural" to them, closely aligning with mathematical function theory. Math is already one of the best tools for describing a vast number of things in the entire universe. Why would anyone who understands math want to go study some other voodoo-doll piercing technique, even if it claims to be particularly effective at solving specific problems?
Interesting take and it feels familiar. I'm definitely in the "I need a tool to keep complexity under control" camp but I don't see it as a bad thing. Coming from a support and sysadmin/ops position seeing the same kind of problem every time makes you want to avoid the problem class. Of course it's often a fantasy. However I realized most problems I experienced were due to a general lack of understanding of the tools and concepts used. This was Java, Spring Framework, Aspect Oriented Programming and an ORM wrapper (MyBATIS) and 99% of my ops problems were due to the devs working around and against these concepts and tools with lots of bad code and so many NPE's that I still get nightmares. A skilled crew of veterans familiar with i.e. Spring, MyBATIS could have refactored this in a few months and most problems would be gone just using each tool how it was meant to be used. But we only added poorly understood layers upon poorly understood layers...
I understand everyone that goes into functional programming after realizing classes of problems don't exist there. I like guardrails. I learned to like immutable functional data structures after realizing 70% of time is Java serialization in the flame graph and I'd rather had the clojure way of solving these problems instead of the hidden magic. But properly learning all the mentioned tools and not abusing them would be enough.
> I'm yet to meet an FP fanatic who actually properly understood OOP.
You just haven't met one who has realized that monads in FP map roughly to objects in OOP yet. :) Both are used for the same broad things: encapsulating/hiding/controlling state and allowing state transformations to be sequenced.
I actually have great sympathy for the functional programmer: having decided that managing both kinds of complexity is mentally exhausting, the functional programmer opts to eliminate, as much as possible, the accidental complexity of willy-nilly side effects in order to better address the inherent complexity of the problem domain. A good programmer can write mostly referentially transparent code with controlled side effects in any language, but it takes more care and forethought to do so in, say, Java.
This is why I say Lisp is really for bad programmers. If you're a programming genius, you can apply the same principles used in Lisp all the time to Java or even C++ code... it's just more work. Work you may not even notice because that stuff comes natural to you. But if you're a mid programmer, much of the friction of working in Java or C++ goes away in Lisp and you feel relieved of a burden. Much more feels within your reach. (I happen to love Lisp, and prefer working in it to anything else if I can, so maybe I'm a bad programmer.)
This hasn’t been my experience. One attraction of functional programming style is that you tend to separate pure/declarative code from effects, one way or another, and then express each using familiar patterns of computation or interaction that are the essence of what you’re implementing. This often results in simpler and more explicit code, with exactly the kind of high cohesion and low coupling you’re advocating.
It is no coincidence that an expressive functional language like Haskell has concise, descriptive names for numerous common folding patterns over common data structures such as mapAccumWithKey¹ that let you express what you want to achieve in just a line or two of code with minimal boilerplate or ambiguity, where using a generic loop in a mainstream imperative language would take 3x that and need a little thought to recognise the pattern being used and make sure there wasn’t anything else happening that was tangled up in the same code.
¹ https://hackage.haskell.org/package/containers-0.7/docs/Data...
Do you have a great example of a code base that meets your ideals?
I think one of the problems is that we just don’t have people that we admire in programming compared to other areas like biology or literature.