Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

All programming philosophies are about state

worldofbs.com

Post reply on HN
Print view View original

141–150 of 254 posts

Re: All programming philosophies are about state

#141

Post by osigurdson »

It seems that the author is trying to make a kind of grand statement but the epiphany isn't felt. A program without any state seems uninteresting, state without logic to manipulate it seems uninteresting as well - no computer ships with only registers or only an ALU after all. It seems that we must include logic in the discussion as well but if we do, the title needs to be updated to "all programming philosophies are about programming".

This is not a deliberately reductive take, I just can't think of any other meaning.

Re: All programming philosophies are about state

#142

Post by nkzd »

_skel wrote: post #56

The 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…

Younger developer here. What does non-SOA style CRUD app look like?

Re: All programming philosophies are about state

#143

Post by eyelidlessness »

jjoonathan wrote: post #123
xmonkee wrote: post #100

Earlier quoted context omitted.

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…

Yeah, it starts condescending and gets worse once you understand the argument: "as an elite, you will learn in your 20s how the policies and goals of conservatism are self-serving, and you will therefore adopt them." In my 20s I bought a house, started filling a brokerage account, started managing people -- so I certainly started to feel those incentives, but I am both principled enough to not act entirely out of sel…

Solidarity forever, rare as it may be!

Re: All programming philosophies are about state

#144

Post by manmal »

threatofrain wrote: post #54
manmal wrote: post #37

Earlier quoted context omitted.

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.

Functional programming doesn’t mean no side effects though. At some point, every language/platform has to have them, or it can’t be used for dynamic inputs.

React (can) have referential transparency and up to a degree immutability (yes hooks are not side effect free, but so isn’t the IO monad).

Re: All programming philosophies are about state

#145

Post by manmal »

epgui wrote: post #117
manmal wrote: post #42

Earlier quoted context omitted.

Using extremes for both, that would mean there is overlap between languages like Haskell and languages like SQL? (Edited for clarity)

Well… I’m not sure how helpful that example is, but yes you could probably find something in common between SQL and Haskell, and on the other hand, no, what I said did not mean that. Look up Graham Hutton’s writings on relations. He has published quite a bit about this, and he knows a thing or two about functional programming.

I think relations are not a precondition for something to be called declarative programming. Most definitions I‘ve found are way broader and generic.

Re: All programming philosophies are about state

#146

Post by remexre »

vc8f6vVV wrote: post #91
vore wrote: post #85

Earlier quoted context omitted.

No, but this is why we have things like linear types or encapsulating side effects in a state monad to describe these kinds of strict sequencings. I personally think pure functional programming is still very unergonomic but referential transparency in the face of side effects is not an unsolved problem. Besides, it's good practice to limit how widespread side effects are in any program, anyway.

Referential transparency is something you can reason about. While technically monads are "reasonable" you are not going to reduce them by substitution. Yes, you can if you have a good imagination, but how does it help? While combining effects is thread safe etc., executing resulting function not necessary is. So we just kicked the can down the road adding another layer on top of existing compiler. Monads is a nice wa…

I'd argue that the difference between a monad and any old type with operations of bind and pure's types is precisely reasonableness -- I can expect Control.Monad.forever to work because the monad laws allow me to reason about monads as an abstraction rather than caring about the precise way the Writer monad might be implemented.

Re: All programming philosophies are about state

#147

Post by password4321 »

nkzd wrote: post #142
_skel wrote: post #56

The 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…

Younger developer here. What does non-SOA style CRUD app look like?

Maybe https://en.wikipedia.org/wiki/Visual_FoxPro

Re: All programming philosophies are about state

#148

Post by shrimpx »

nkzd wrote: post #142
_skel wrote: post #56

The 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…

Younger developer here. What does non-SOA style CRUD app look like?

A p2p serverless app with storage replicated across peers.

Re: All programming philosophies are about state

#149

Post by college_physics »

The author is onto something. What is needed to flesh out the "map of state philosophies" (and counter the criticism of apples and oranges) is I believe more resolution about of where state is physically expressed (memory, disk, remote machine etc)

Having a good representation / classification of alternative choices and tradeoffs could help people with more informed design choices and selection of tools

Re: All programming philosophies are about state

#150

Post by dgb23 »

kazinator wrote: post #73

Imperative: 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…

There’s another variation to ‘functional’:

Let’s treat data as what it is so I can sleep at night again.

Post reply on HN