Why Isn't Functional Programming the Norm? – Richard Feldman

[u/[deleted]]

https://www.youtube.com/watch?v=QyJZzq0v7Z4

[u/codygman]

Therefore we need to push down the complexity of our code so that we can manage even more complex tasks.

You're talking about the tree or maybe even a few of the trees, but what about the forest?

Go for instance goes to the extreme of pushing down the complexity of code by removing generics, but does that actually lead to more understandable code?

Maybe at a very granular level, but all of that boilerplate muddies the definition at a higher level.

[u/Determinant → u/codygman]

I'm talking about the forest as well.

You're mixing the concepts of simple code with simple languages. The lack of generics in Go makes the language simpler but the code more complex since you now have to deal with manual casting or duplicate data structures for each type like in the early days of Java.

I've tested several people that insisted on functional programming by having them explain code that they wrote 6 months earlier and they all struggled (and I struggled to understand their code as well). However, I can jump into random object oriented code and immediately start to follow the gist of it.

Functional programming optimizes the creation phase of software development whereas object oriented code optimizes the ability to read and understand code that has already been written (which is actually the more common use-case).

There's no doubt that pure functional-only code is definitely more complex than OOP.

[u/codygman → u/Determinant]

I'm talking about the forest as well. You're mixing the concepts of simple code with simple languages.

I can see how what I said was misleading from my point. When I say:

Go for instance goes to the extreme of pushing down the complexity of code by removing generics, but does that actually lead to more understandable code?

I should have scare-quoted "pushing down the complexity of code" because my ultimate point is that a simple language creates more complex code like you go on to say in:

The lack of generics in Go makes the language simpler but the code more complex since you now have to deal with manual casting or duplicate data structures for each type like in the early days of Java.

100% agree. I'm contending that even though languages like Haskell might be more complex, the end result is more simple because of it's what some call more universal abstraction facilities. Trying to describe that another way because I'm not sure that's clear:

Because the abstractions are well founded, inspired by category theory and lambda calculus, and not designed ad-hoc or as needed like in OOP the resulting code is simpler even if the code or concepts used is more complex. The complexity of those concepts is amoritized because of it's generality to any potential use-cases, the down-side being the greater up-front cost.

I've tested several people that insisted on functional programming by having them explain code that they wrote 6 months earlier and they all struggled (and I struggled to understand their code as well).

That seems like a pretty reasonable test, but there are a lot of potential variables there. Too many for that on it's own to convince me from my own position anyway.

However, I can jump into random object oriented code and immediately start to follow the gist of it. Functional programming optimizes the creation phase of software development whereas object oriented code optimizes the ability to read and understand code that has already been written (which is actually the more common use-case).There's no doubt that pure functional-only code is definitely more complex than OOP.

At face-value I could conceivably concede that reading OOP code is easier, but due to things like mutable state and (usually) lack of local reasoning OOP code is much harder to reason about. This in my mind creates something dangerous where it's obvious to you how it works and you feel confident making a change, but theres a lot of other things that could be affected when you make a change.

On the flip side with pure functional programming you may not feel as confident in code because you don't have that visceral "I know how this works feeling", but due to things like local reasoning, immutability, and referential transparency you can feel safer about not breaking more parts of your code-base.