[com2kid]

> Computational complexity allows us to quantify which algorithm is faster and better. But whether that algorithm was better implemented using FP concepts or OOP concepts, we don't know... we can't know.

The CPUs code runs on are imperative, with a lot of complexities and details hidden from programmers by magic the CPU does involving things like reordering and automatic parallelization.

However, none of the current languages are great at writing code that maps to how the CPU works. One can comment that functional programming does a better job of breaking up data dependencies, but imperative code can also do that just fine.

The problem with mapping paradigms to performance is that none of the paradigm purists care about performance, end of the day they care about theoretical purity.

CPUs don't care about paradigms, they care about keeping execution units busy and cache lined filled up.

[deltasevennine]

>The problem with mapping paradigms to performance is that none of the paradigm purists care about performance, end of the day they care about theoretical purity.

It's not theoretical purity. It's more tech debt. How do I code things in a way where there's zero tech debt. Such that all code can be re-used anywhere at anytime.

[com2kid]

Separate problem!

Answer is good code review and design practices. Real CRs early on in the process, not just before signing off on feature complete.

I've seen horribly unusable code that was "good examples" of both OOP and FP. The OOP peeps have so much DI going on that tracing what actually happens is impossible, not to even get started on debugging.

The FP purists have so many layers of indirection before stuff actually happens (partial function application all over the place and then shove everything through a custom built pipe operator and abuse the hell out of /map/ to do the simplest of things).

Meanwhile some crusty old C programmer writes a for loop and gets the job done in 10, obvious, easy to read, lines.

[deltasevennine]

I am from the camp that FP code produces much less tech debt then other forms of programming.

But the problem here is that no one here can prove or disprove what I just said. And that is the point of my thread.

In fact I believe tech debt is a fuzzy word that is is ripe for formalism such that we can develop a theory around what tech debt is and how to definitively eliminate it through calculation,... the same way you calculate the shortest distance between two points. I believe that the FP style is a small part of that theory.

But that's besides the point. Because since this theory doesn't exist yet, you and I have no way of verifying anything. You can leave me a code review and I can disagree with every qualitative opinion you leave in it.