[deleted]
All programming philosophies are about state
151–160 of 254 posts
Re: All programming philosophies are about state
#152I think paradigms rather than philosophies is a better term.
Re: All programming philosophies are about state
#153The 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?
Ethereum / bitcoin / some other crypto
Re: All programming philosophies are about state
#154I’ve been a programmer all my life, got first sw job around 2000 in business-oriented area (consulting + programming + “ops”). Before that were 5-7 years of toy programming as a kid. I experimented with tech a lot, got into paradigms early and never restricted myself to a single language/env/os/hw. I haven’t created nothing big, stellar or rocket science, but a couple of my projects lived for 10-17 years and counting.
Mind you, this “state management” thing and the fuss around it, which pops up for last ten years more actively, was never a concern that I found particularly useful to have a name for. 20+ years of a mediocre career and I still don’t get it, neither why, nor what the problem is. Maybe that’s why it is mediocre? Living in a bs country doesn’t help either. Otoh, I can make things work and ship mvps next week once there’s a plan and determination. (No, it’s not PHP.)
I believe that the fuss part comes from the fact that software becomes more and more low-level uncontrollably, so there’s a lot of self-imposed state that business isn’t even aware of and which becomes per-LoC routine that is easy to stumble upon but hard to document or explain to a person outside. State belongs to business and is not in your control, all other state is parasite. Mapping business state 1:1 in your program keeps everything simple to do, to change, to grow. It’s usually imperative, sometimes declarative (that’s where programming emerges) and never functional. Parasitic state’s place is under a rug. Library, syntactic sugar, framework, db/service, platform, whatever.
To conclude, well, I have nothing to say really. Still confusing.
Re: All programming philosophies are about state
#155Earlier quoted context omitted.
I really dislike this quote. It always comes across like it's designed to ease greedy people of their guilt for moving to the right as they earn more money. To me, being sound of mind is wanting everyone to have what you have, or at least an equal shot of getting there from wherever they had the roll of the dice of being born.
The quote is not nice and I don't blame anyone for taking issue with it. However I don't see people feeling any guilt as they move right. Nor do I see a need for greed to corelate with the right leaning politics. The same teachings that lead me to lean right also lead me to donate more than 10% of my income. I think all people that can should donate to charity but I don't think anyone should be forced to. I take issu…
I think that’s possibly a fundamental misunderstanding of left ideas.
The point is not to force generosity on others. The point is to fight back against unjustified value extraction by the powerful and to democratize the workplace.
Socialists see charity as trying to patch over symptoms of an inherently deeper problem. It’s not a philanthropic movement. It’s a worker movement.
Re: All programming philosophies are about state
#156It 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…
I found that a big jump in my quality of design was when I started thinking about what state was necessary, what transformation needed to be done, and by what entity. Before that, I used to code for the task at hand, and create data structures mostly for the task at hand. Thinking about what each program might need to know and in what format relative to it's role just made things smoother.
It wasn't a large leap conceptually, but the mental model change came from a long lost hacker news comment along similar lines.
Re: All programming philosophies are about state
#157It 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…
"all programming philosophies are about programming"
I don't think it is a reductive take. The second instance of the term here instead involves the more traditional concept
program: "a regular plan of action in any undertaking" https://www.dictionary.net/program
Programming (in the sense of software construction) paradigms, philosophies, indeed "languages" etc., are about regularizing plans of action for complex computational undertakings.. usually.
Re: All programming philosophies are about state
#158I’ve been a programmer all my life, got first sw job around 2000 in business-oriented area (consulting + programming + “ops”). Before that were 5-7 years of toy programming as a kid. I experimented with tech a lot, got into paradigms early and never restricted myself to a single language/env/os/hw. I haven’t created nothing big, stellar or rocket science, but a couple of my projects lived for 10-17 years and counting…
The text of a program does not show what is in memory, or what the devices attached to the machine are doing. You hope that if you run the program, in your head, you can reliably guess -- but often, you make mistakes.
Controlling "state" amounts to trying to force the world to match the text of your program as closely as possible, so you don't go wrong.
Re: All programming philosophies are about state
#159The 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?
Anything monolithic, where a single binary executable is run at the start, maybe spawning subprocesses to handle parallel tasks, possibly sharing memory through synching protocols to avoid interlocking.
SOA uses message passing only as the synch mechanism, but sharing memory allows for other strategies with synch primitives such as semaphores or mutexes (with the assumption that collaborating processes run on the same physical machine, or communicate through Remote Procedure Calls).
http://www.composingprograms.com/pages/48-parallel-computing...
Re: All programming philosophies are about state
#160Well, programming is about managing state. Also, you forgot Data Oriented Design: state should be modelled to match how the hardware.
Do you have any reccomended reading on DOD ? There seems to be some discusions around it, but i'd rather something more practical from someone who has practiced it.