All programming philosophies are about state

I wish people would quit propagating this hostile view of functional programmers. The vast majority of them — even in academia — are happy to never mention or even fully learn about the scary math words, and most of those who _do_ learn about them work really hard to not make the community unwelcoming to those who don't know or don't want to know. But the reputation precedes, which causes people to avoid it altogether, which is really a shame.

The whole "a monad is a monoid in the category of endofunctors, what's the big deal?"-in-a-condescending-tone bit comes from "A Brief, Incomplete, and Mostly Wrong History of Programming Languages": a satirical blog post from 2009 (http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...). It is not indicative of the general community, but the joke has been reproduced enough that people who don't know anything will encounter it, think the practitioners are serious about it, and write off the whole thing as unwelcoming. It's a bummer.

It’s hard to tell. My gut feeling, especially the one I get from popular state management libraries, says I actually gravitate away from it, in a sense. I see what they are for, but it feels like they are made with a sugar-coated landing/tutorial page in mind, while at the same time making things more complex, basically trading more for less. They turn languages and paradigms indise out to get cool effects, but make your way of thinking diverge from how business requirements speak, creating a gap between programmers and consultants.

As others noted, the size of my projects may skew the perspective. But I’m not sure how big something should be (and tightly coupled) to start worrying about it, unless my primitives aren’t too great to use without a second thought. What bugs me even more us that popular libraries don’t even provide them out of box, suggesting to write code and to spread structures in a special convoluted way instead.

I never claimed they were, and I don't know if they are. But relations are in the category of declarative, and are a generalization of functions.

>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.

The problem with your desire is that the most cutting edge OOP paradigm is event-sourcing, which is essentially functional. Event sourcing isn't a clearly defined pattern, but it kinda blends functional ideas, "given a state and a change, i'll give you a new state" such that your system will give a non-deterministic new state based on a change. That's de facto functional programming.

Having said that, the leanest system will be reference types under the hood, as for example, the C# stack frame is limited to 1mb and can't contain your app's entire state.

So we arrive at today's cutting edge which is F#, Clojure, etc. that are functional wrappers around heap-based lookups.