>I think your mistake is that it's not about the "abstract"/academic/philosophical or etymological meaning of those terms (functional, imperative, etc).

No mistake made by me. The popular or even academic usage of the terms isn't relevant to the topic here. The reason is because the way these terms are used are highly inconsistent even in academia. They're not formally defined, they're just used for informal fuzzy communication.

I simply define a hierarchy here that's inline with our intuition to point out things the author and you completely missed.

I'm totally with you in that the popular usage is relevant in MOST cases. But in this specific context it doesn't work because the author attempts to do a very broad isomorphism across terms with fuzzy definitions stating that all of these styles are different forms of managing state and he misses the actual true meaning of what's going on.

Let's not get into language specifics like CLOS for lisp. Let's just focus on the core programming style without considering a specific language. All of these programming styles, more or less can imitate each other when managing state. None of them have a crystal clear way of handling state that's specific to their style. OOP can imitate Imperative and vice versa. In fact I'll list all the connections here:

   OOP -> FP
   OOP -> Imperative
   OOP -> Declarative
   Imperative -> OOP
   Imperative -> FP
   Imperative -> Declarative
   Declarative -> OOP
   Declarative -> FP
   Declarative -> Imperative

An arrow represents "can manage state in the same way as".

Basically almost every programming style listed here is so similar they can practically imitate each other. An isomorphism is obvious and the differences in state management are trivial. However, there is one exception above. You will note FP is not at the left side of the table.

Functional programming Cannot imitate ANY of the other paradigms. Both the author and you completely missed this.

What I am saying is this, there's really only two basic ways of handling state and these two ways are fully exemplified between functional and imperative styles.

All the other styles including the SOA stuff is just fluff. Different ways of doing the same thing. It's like replacing every letter in the alphabet with a different symbol and calling it a new language even though it's still more or less the alphabet.

>Not in any colloquial use of the term. SSA form might be "functional programming", but it's not what 99% of devs (and the author) means by functional programming, which includes the trappings and idioms offered by traditional languages called functional programming languages.

This statement here is categorically wrong even when considering colloquial understanding of THIS concept. It is just factually completely incorrect. Have you tried doing this? map, reduce, recursion, and all FP patterns become your ONLY tools when things become immutable.

Try writing fibonacci with everything immutable in say something simple like JS or python. Good luck doing it without using recursion or reduce.

The isomorphism between FP and imperative programs that use immutable variables is something well known, but apparently, not by you.

> Try writing fibonacci with everything immutable in say something simple like JS or python. Good luck doing it without using recursion or reduce.

SSA, no recursion, no reduce ;)

    def factorial(X: int) -> int:
        encode = lambda n: ((lambda N: lambda g: lambda f: lambda x: x if N == 0 else f(g(N-1)(g)(f)(x)))(n)
                            (lambda N: lambda g: lambda f: lambda x: x if N == 0 else f(g(N-1)(g)(f)(x))))
        decode = lambda f: f(lambda x: x + 1)(0)
        fact = (lambda f: lambda n: cond(vaut0(n))(lambda _: un)(lambda _: mult(n)(f(f)(pred(n)))))(
               (lambda f: lambda n: cond(vaut0(n))(lambda _: un)(lambda _: mult(n)(f(f)(pred(n))))))(n)
        return decode(fact(encode(X)))

Of course, I'm joking, as the Y combinator is clearly visible here.

Full form for those interested : https://termbin.com/cd3q

Clever. Very cool. Of course the y combinator. Even so my point stands.

This snippet was clearly functional .

>All of these programming styles, more or less can imitate each other when managing state. None of them have a crystal clear way of handling state that's specific to their style. OOP can imitate Imperative and vice versa.

And the point is that this doesn't matter. It's not about C++ OOP being able to "imitate imperative" or not, it's about what C++ (or OOP in general) adds to the table regarding how programmers should think and hide state.

>All the other styles including the SOA stuff is just fluff. Different ways of doing the same thing.

Like above, you're still reasoning from lower levels of abstraction to point the similarities and underlying unity, whereas TFA is all about the level of working with each language and its "programming paradigm" as a programmer.

It's like you're arguing that "in the end, chemistry is just physics". Or worse, "in the end, cooking is just physics". Sure, but that is pedantically irrelevant information in a regular cookbook or when talking about cuisines.

>Try writing fibonacci with everything immutable in say something simple like JS or python. Good luck doing it without using recursion or reduce. The isomorphism between FP and imperative programs that use immutable variables is something well known, but apparently, not by you.

My whole point was that it's not about the isomorphism, but the higher level trappings.

Funny how you've managed to miss the whole argument, it's not even like I didn't spell it out (or like I haven't already said that SSA is nominally "functional programming") but it doesn't matter

>And the point is that this doesn't matter. It's not about C++ OOP being able to "imitate imperative" or not, it's about what C++ (or OOP in general) adds to the table regarding how programmers should think and hide state.

That's your point. And MY POINT is that your point is missing the true relationship between these programming styles. C++ is not a topic here. That is a specific implementation of a programming style. We are talking about programming paradigms, not specific languages.

Additionally How is anything added to the table if every language can more or less imitate one another? Obviously you're referring to a bias that a language sort of pushes you toward. This is what YOU are saying. What I am saying is that YOUR perspective, again, is the one missing MY point.

Let me put it to you this way. When you notice everything is more or less isomorphic then you notice a true difference. FP is fundamentally different. Imperative and FP styles are MORE different then all the other styles of state management compared. Then from this you can see that there's a missing hierarchy within all these programming language paradigms. This is what I am pointing out. I'm presenting flaws of the original point, and making a new point.

>It's like you're arguing that "in the end, chemistry is just physics". Or worse, "in the end, cooking is just physics". Sure, but that is pedantically irrelevant information in a regular cookbook or when talking about national cuisines.

No I'm not. I'm saying that YOUR and the OP's point is wrong because the "everything is the same" result is what you get when you compare programming paradigms this way. You need a hierarchy and only sibling nodes in the hierarchy can be compared.

>My whole point was that it's not about the isomorphism, but the higher level trappings. Funny how you've managed to miss the whole argument, it's not even like I didn't spell it out (or like I haven't already said that SSA is nominally "functional programming") but it doesn't matter

In logic and in programming as you get more and more higher level things become more and more isomorphic until finally at the highest level of abstraction everything is the same thing. This follows logic.

In programming and in nature as you get more and more lower level things ALSO tend to become the same. But this does not follow logic. From our observations everything looks to be made out of atoms, and by design all programming styles compile into assembly instructions. But this doesn't follow any form of logic; it doesn't HAVE to be this way by logic, it is simply this way by observation or by design.

That being said, your comment about higher level trappings make no sense. Going in EITHER direction things should become more and more samey. Additionally I'm not even going to a higher level or a lower level. I am simply saying these programming paradigms have hierarchy. I am also saying within each paradigm, things are so flexible that there is no specific way of managing state. You can manage state the EXACT same way in all paradigms, except ONE style. By seeing it this way a clear hierarchy emerges. That is it.

SSA has nothing to do with this. This is a term from compiler design and you're accusing me of going to a lower level? Still I get your point and in SSA from the way you use it is not "nominally" functional programming. IT IS functional programming. Literally look at the other persons post who implemented fib. That's totally functional.

"SSA form"?

Static single assignment is a property of an intermediate representation, the language used by the front-end of the compiler (the part that handles a specific language, parsing, semantics, and whatnot) to the back-end of the compiler (the part that handles a specific architecture, emitting assembler instructions as well as optimizations).

One of the tricks of making compilers is transforming the code into whatever form makes the thing you're trying to do easier. SSA is one of those forms, and it means that each variable has exactly one assignment. There is some "cheating" (phi nodes) involved to handle things like "if (...) { a = 0 } else { a = 1 }".

Notably, LLVM IR is SSA.

Since there's no mutation, it's technically a functional language.

Thanks! TIL.