i want to see someone elaborate a state-maximizing, instead of state-minimizing, philosophy. lean in
All programming philosophies are about state
131–140 of 254 posts
Re: All programming philosophies are about state
#132The article is grouping things together that don't belong in the same categories. OO, functional, imperative, declarative: these are ways of controlling dispatch . Monoliths and microservices are both ways to organize codebases and teams of programmers and control whether dispatch is intermediated by the network or not. Either way, both of these options are implemented by some kind of language in the previous categor…
First OO programming is a specific style of imperative programming. OO is simply imperative programming with state and functions scoped into instances. If you are doing OO, you are also still doing imperative programming.
You can't really compare OO to functional because it would be like comparing a very specific concept to a very general concept. Like comparing cars and planes, but instead you're comparing a 2020 tesla with all planes in general. No... either compare specific cars with specific planes or planes in general with cars in general.
Declarative programming, on the other hand, can be stateless or stateful so it doesn't really apply here. Declarative programming is sort of left field to all these programming styles because technically chatGPT is declarative. Declarative programming is more about linguistics, AI and natural language processing. It's completely orthogonal to state management.
Functional programming and Imperative Programming are the two correct categories to compare here. They are siblings in the hierarchy and they are distinct and in essence simply two different ways of handling state.
Case in point: If you change one thing in your imperative programs. One thing... then your imperative program immediately becomes functional.
This thing is immutable state. Imperative programming with immutable state IS functional programming. Change the way you manage state, then you essentially change the name of your programming style.
The two paradigms are in essence two different styles of state management. All the other stuff with OO and Declarative is sort of fluff and distracts from the true essence of the isomorphism the author noticed here.
Re: All programming philosophies are about state
#133Also, you forgot Data Oriented Design: state should be modelled to match how the hardware.
Re: All programming philosophies are about state
#134Earlier quoted context omitted.
“He who is not a républicain at twenty compels one to doubt the generosity of his heart; but he who, after thirty, persists, compels one to doubt the soundness of his mind.”
God, this is such condescending nonsense. The older I get, the more left I lean, because the more of the world you see the more you see what chaos our current ideology has wreaked upon it. The only people I see going the way this quote does are unthinking idiots who were fashionably "liberal" in their youth without understanding any political theory, and are now fashionably "conservative" with even lesser understandi…
Re: All programming philosophies are about state
#135Imperative: modifying state is the point of a bit-flipping machine; get out of my way so I can have fun! OOP: OK, I mostly had enough fun, can we try to tame the bit-flipping chaos with real-world analogies, without deflating all the fun? Functional: Any Monad is by definition an Endofunctor, which also means it's an object in the category of Endofunctors, where the monadic μ(flatMap) and η(unit) operators satisfy th…
Isn’t OOP a subset of imperative programming and functional a subset of declarative programming?
Re: All programming philosophies are about state
#136Earlier quoted context omitted.
FP is about evaluating expressions and it doesn't have state all over the place. I would also add that statefulness is incredibly hard and complex to get right in complex applications and pure fp languages like haskell lack enough emphasis on runtimes to handle this gracefully.
> FP is about evaluating expressions and it doesn't have state all over the place. All the state is in the function stack and the instruction pointer.
Re: All programming philosophies are about state
#137Re: All programming philosophies are about state
#138Imperative: modifying state is the point of a bit-flipping machine; get out of my way so I can have fun! OOP: OK, I mostly had enough fun, can we try to tame the bit-flipping chaos with real-world analogies, without deflating all the fun? Functional: Any Monad is by definition an Endofunctor, which also means it's an object in the category of Endofunctors, where the monadic μ(flatMap) and η(unit) operators satisfy th…
I feel I should point out that that ‘functional’ quote is (a) only applicable to pure, strongly-typed functional languages, and (b) pretty much irrelevant unless you happen to be interested in category theory.
Eg. Clojure is a modern functional language that is used for a lot of things & happens to be dynamic.
Re: All programming philosophies are about state
#139Earlier quoted context omitted.
Former long time anarchist, current long time FP proponent, presently having a laugh with you on this.
Out of curiosity, why former?
I don’t want to get more into that here because there be many dragons. But I’m easy to contact if you want :)
Re: All programming philosophies are about state
#140Imperative: modifying state is the point of a bit-flipping machine; get out of my way so I can have fun! OOP: OK, I mostly had enough fun, can we try to tame the bit-flipping chaos with real-world analogies, without deflating all the fun? Functional: Any Monad is by definition an Endofunctor, which also means it's an object in the category of Endofunctors, where the monadic μ(flatMap) and η(unit) operators satisfy th…
I feel I should point out that that ‘functional’ quote is (a) only applicable to pure, strongly-typed functional languages, and (b) pretty much irrelevant unless you happen to be interested in category theory.
I think it is not precisely delineated along the static vs dynamic sides: In addition to Elixir/Erlang, and Clojure we have eg F# and Elm from the static side in the pragmatic team.