I mean ... all programming is is manipulating state/data soo yea I guess this tracks.
All programming philosophies are about state
51–60 of 254 posts
Re: All programming philosophies are about state
#52An idea that sounds convincing at first, but falls apart on closer examination. I found myself less and less convinced with each example, some of which really seem to be grasping at straws. Programming philosophies encompass much more than just state management, and narrowing the focus to state doesn't seem particularly enlightening to me, at least with these summaries. I'd love to be proved wrong, though.
I think they are right about the first few: OO and FP are both most definitely about state management.
However, I definitely agree that it's a stretch to say that architectural patterns like monolith vs microservices are about state. Those have far more to do with structuring deployments and organizing work.
Re: All programming philosophies are about state
#53That doesn't really seem like a good summary of functional programming. It has state all over the place. But it's true that functional programming is about state management. I'd argue that the functional approach to state management is to make state explicit and visible.
[deleted]
Re: All programming philosophies are about state
#54Earlier quoted context omitted.
React is neither reactive nor declarative nor functional.
Instead of stonewalling, please explain what React is in your opinion. Edit: I mean it’s called „Functional components“, are they lying?
No, the React team means that they use JavaScript functions as the preferred authoring experience for React components. React components often have side effects & internal state and that's not necessarily a bad thing, notwithstanding strict mode.
Re: All programming philosophies are about state
#55As someone coming from a functional perspective I would humbly characterize my position as:
> Functional - Modifying state is hard to get correct; so let's focus on the rest of the problem (the part we can get right!)
Pushing state to the edges is actually just a consequence of this impulse.
In the end it isn't a satisfying solution, because you end up with every bit of low-level, inconsequential state percolating up to the top and polluting every single data structure along the way.
I feel there must be a better approach ... in which the "impertinent" state can be abstracted away and managed orthogonally to the functional description of the program.
Re: All programming philosophies are about state
#56The 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 category (OO, functional, imperative, or declarative).
Service-oriented architecture applies to both monoliths and microservices, and very few programmers still working in the industry have really seen what an alternative to service-oriented architecture actually looks like.
Re: All programming philosophies are about state
#57[deleted]
Re: All programming philosophies are about state
#58I mean ... all programming is is manipulating state/data soo yea I guess this tracks.
Exactly. The Turing machine is a state machine. The universe does a pretty good job of appearing stateful (amusing side note, Greg Bear's Moving Mars has a fundamentally object-oriented universe, as opposed to Wolfram's bent). All of our programming paradigms are built to, in the end, manipulate state. Imperative programming does this in a very direct manner, others are more indirect. Ultimately, this implies a tradeoff of some kind of overhead, plus some ... paradigm impedance mismatch, if I may coin a clumsy phrase ... at the edges.
You can try to ignore state but at the end of the day, you still want to do something with it at the start and at the end, at least one of the two.
Re: All programming philosophies are about state
#59I used to think this until I read Whitehead and Hickey and realized it’s all about time
Re: All programming philosophies are about state
#60State = context. In a pure functional language the state would be concerted into extra function parameters.
Many bugs arise from unexpected context: programmer writes code expecting one context but gets an oddly-shaped context they weren't planning for (the other bugs are typos, where the context is correct but your code is not what they planned it to be, or when downstream code has different behavior than they expected. Ultimately, the code is not doing what they expected it to).
But context is inevitable. Even "stateless" programs like compilers, which take an input and return an output, have a lot of context (e.g. scopes, prior analyses, virtual pc). In pure languages like Haskell this gets abstracted by monads (and not just the `State` monad, all of them); if you do not abstract the context you get a function with an obnoxious amount of parameters and return values which is even more unweidly.
When people say "managing state" what they really mean is managing context, so that you guarantee when a function is called it has the context (state and parameters) it was handled for. The way to do this is to make the context reliable, whether that be state invariants, strongly-typed parameters, less state/parameters, exhaustive case analysis, etc.