16 ms·

All programming philosophies are about state

377 points by signa11 4y ago

gumby 4y ago
Side effects: can't live with 'em, can't live without 'em.
rightbyte 4y ago
"Functional - Modifying state is hard to get correct; keep it at the boundaries and keep logic pure so that it is easier to verify the logic is correct." My main beef with functional programming is that you essentially put the state in the "instruction pointer" and its history of walking the call stack instead of bound to symbols. It does not fit my way of thought. I personally prefer more or less statemachines.
- xwdv 4y ago
  You don’t need history. Embrace one way data flow and your life will be simpler and more easy to reason about.
- epgui 4y ago
  I think what you're missing is that functional programming is about referential transparency. There should be no need for an instruction pointer in your mental model.
  - deleted 4y ago
    [deleted]
  - vc8f6vVV 4y ago
    Not really. Try to interact with DB in FP. Yes, there is a referential transparency ... when combining functions which call DB (e.g. using monads). As a result you get a composite function, which is the same every time you run that composition. Who cares really? When you execute that composite function though you will potentially get different results and your "referential transparency" goes out the window. Of course one can write a "pure" FP program without effects, but any side effect reduces referential transparency to combining functions, is it really easier to reason about computations this way? Nope, it is not. Basically how FP sells: def a 1 end def b 2 end def c a + b end You see? c = 3! Now try to apply this logic to (real world with effects): def a (conn: DBConn) => { .... some complex code ... } end def b (conn: DBConn) => { .. another complex code ... } end def c (conn: DBConn) => a(conn) + b(conn) end So c = ? Still transparent?
    - ARandomerDude 4y ago
      DB operations are not what is being described in the conversation about referential transparency. We’re talking about something that starts with things like reduce vs. a for loop with mutable variables to accumulate values. Once the language forces you to think in terms of stateful operations to perform even basic tasks, the reflexive tendency is to use mutable state to perform any task. At that point, nobody really knows what a functional does because you have to understand the entire system to know what the output of a function will be.
      - vc8f6vVV 4y ago
        But we do have loops in the real world, don't we? So in a true FP we are talking about recursion as an alternative to for loops. Can you easily reduce recursive function? If you can, I can as well "reduce" for loop. Otherwise we are talking about a paradigm without recursions and side effects.
        ARandomerDude 4y ago
        https://clojuredocs.org/clojure.core/reduce https://clojuredocs.org/clojure.core/reduce
        vc8f6vVV 4y ago
        Recursion, what was the point of the link?
        epgui 4y ago
        Your problem is that you’re trying too hard to argue and your time would be better spent trying to understand.
    - vore 4y ago
      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.
- Twisol 4y ago
  Is this another way of putting what you're saying? In functional programming, we think of computation as reducing an expression; a computation is complete when it can't be reduced anymore. In imperative programming, we think of computation as updating a store of data; a computation is complete when we run out of steps to perform. When you're partway through execution, the "rest of the program" in an imperative system is captured by the current state of the store (including the stack). In a functional program, the "rest of the program" is just the program expression itself, reduced as it has been up to this point. I tend to like the functional model, myself, but I can see the mental appeal of keeping the program text fixed, and isolating all changes to a separate store of data.
- dustingetz 4y ago
  modern FP (effect systems) says the opposite - having separating the pure from the impure, we can now bring them back together and orchestrate fine grained fabrics of effects at greater scale with deterministic lifecycle and strong real source cleanup guarantees; for example signals based reactive dom rendering
q845712 4y ago
It's been a while but I used to enjoy telling folks in the early years of their career that software engineers and anarchists have a lot in common because both view "the state" as the main cause of problems.
- eyelidlessness 4y ago
  Former long time anarchist, current long time FP proponent, presently having a laugh with you on this.
  - weatherlight 4y ago
    A Classless and stateless society! sign me up!
  - shaunxcode 4y ago
    we must build a Functional Economy.
  - epolanski 4y ago
    I bet 1 $ you work in crypto.
    - eyelidlessness 4y ago
      Nope! You can actually find out what I do for work pretty easily tho because it’s all open source and I use the same handle. Edit: please donate the proceeds of your bet loss to victims of the earthquakes in Türkiye.
    - deleted 4y ago
      [deleted]
  - IngoBlechschmid 4y ago
    Out of curiosity, why former?
    - bcherny 4y ago
philosopher1234 4y ago
i want to see someone elaborate a state-maximizing, instead of state-minimizing, philosophy. lean in
- swagasaurus-rex 4y ago
  ... Recurrent neural networks?
- deleted 4y ago
  [deleted]
- chapium 4y ago
  Spaghetti architecture. There is so much state organizational controls outside the codebase limit which parts of the code may be executed at any given time.
- mostlylurks 4y ago
  Forth in its simpler implementations seems like it goes about as far as one could conceivably go in terms of maximizing state, or minimizing non-state. No parameters or perhaps even local variables, everything is just pushed onto a stack (or one of many stacks) that can be freely manipulated at any point. No major opaque control flow mechanisms, ifs and loops are implemented as functions operating on an exposed "return stack" which can be freely manipulated. No opaque function definitions compiled into a binary, function implementations are placed in a data structure that can be freely accessed at any time. No separate compile stage that manipulates state otherwise inaccessible to the program, compilation happens at run-time by manipulating freely accessible data structures, and the "syntax" for compiling things is essentially just function calls that manipulate globally accessible state based on what's in the input stream and you can write your own alternatives if you want. If the functional paradigm tends towards avoiding state, then it would seem to me that forth does the opposite: making almost everything a part of the state of a program that a developer can access and manipulate, even things that most structured programming languages do not expose to the developer.
- dqpb 4y ago
  State machines?
chowells 4y ago
That 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.
- epolanski 4y ago
  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.
  - frutiger 4y ago
    > 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.
    - EugeneOZ 4y ago
      While you can’t read the state, it's not a “state”, it's just a chaotic mess of data in memory.
  - User23 4y ago
    > FP is about evaluating expressions and it doesn't have state all over the place. FP is all about side effects. Every time you declare something you're effecting a compile time side effect. And then there's monads, which are literally reinventing state with a worse API. I find it odd that no mainstream functional language has an explicit call stack monad and an explicit symbol table monad. Maybe because even the "purists" realize how asinine that would be. > 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. Mutable state is a powerful tool. And it's true that if carpenters used table saws with the same level of discipline that programmers use compilers, there wouldn't be a carpenter left with any fingers. Nevertheless, powerful tools can be used in a responsible and disciplined way and if you do you can be highly confident no unexpected dismemberment, literal or metaphorical, will occur. Edit: to be more explicit, the mathematicians who invented Algol were well aware of all the theory for so-called functional programming and rejected it in favor of treating programs as transformations of a multidimensional space with good reason.
tweroiu23o43 4y ago
No it is not. Lisp stands in stark contrast to this. The lisp philosophy is this: as with every science, you mould your language to your problem, not the other way around.
- ihatepython 4y ago
  Yes, it goes without saying that Lisp and mold go hand in hand. I find that Lisp is very organic, kind of like fungus.
- astrange 4y ago
  Sure, because they haven't heard of the rule of least power, which is why it's sometimes good for languages to be about stopping you from doing the wrong thing vs. easily doing things.
georgeoliver 4y ago
Has anyone or any PL theory in CS made a useful distinction between data and state?
- taneq 4y ago
  They're different levels of abstraction. Data is used to describe state.
- Twisol 4y ago
  State is made of data. The difference is that state is data together with a persistent identity (morally, a location), and the data associated with that identity may change over time.
- bheadmaster 4y ago
  Turing Machines are defined in a way which makes a distinction between data and state - it consists of a state machine (which controls what happens when each symbol is read) and a tape (which records symbols - data - which will be manipulated). The state machine is part of the Turing Machine's definition - so one Turing Machine can only have one particular state machine configuration, but can operate on any tape with any content. However, the existence of Universal Turing Machine (a Turing Machine that can simulate behavior of any other Turing Machine) demonstrates that data can also represent state - i.e. you can encode an arbitrary Turing Machine's state machine in the tape, without changing the Universal Turing Machine's state machine at all. That's how we got stored program computers. In a more practical sense, a useful distinction between data and state is within the boundaries of the program - any data that is internal to your program can be considered state, while any data that you read from an external source/write to an external sink can be considered just plain data. Separating the two is a helpful technique in writing reliable software.
pharmakom 4y ago
Functional and declarative are the same to me
- eyelidlessness 4y ago
  I think what the article intended by “declarative” is roughly occupied by the “logic programming” paradigm and DSLs like SQL. If my intuition is right, they have a lot of conceptual overlap. But they differ mostly in how much they realize a goal of “what, not how”.
- epgui 4y ago
  They're related, but "declarative" is a broader category that includes relations. Functions are a special case of relations (see also: prolog, datalog, sql...).
  - manmal 4y ago
    You can write declarative code in an imperative language, and you can write non-declarative code in a functional language (eg IO monad). So IMO they can’t be related. That’s assuming that „declarative“ means „describing outcomes rather than describing process“.
    - epgui 4y ago
      You can write functional code in an imperative language and you can write imperative code in a language like Haskell, but that’s irrelevant.
- manmal 4y ago
  They are orthogonal. React (FC) is a declarative _and_ functional approach. The declarative part is where React code describes what should be rendered, instead of adding/removing DOM elements manually. The old React is not 100% functional (partially OO), but it still is declarative.
  - epgui 4y ago
throwawaaarrgh 4y ago
They forgot Immutable! The best way to handle state.
- skibidibipiti 4y ago
  [dead]
- manmal 4y ago
  Is that not covered by functional programming?
nagonago 4y ago
An 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.
- lolinder 4y ago
  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.
mellis 4y ago
There's a great discussion of state in one of the original lambda papers: "The Art of the Interpreter or, the Modularity Complex" by Gerald Sussman and Guy Steele from 1978: https://dspace.mit.edu/bitstream/handle/1721.1/6094/AIM-453.pdf https://dspace.mit.edu/bitstream/handle/1721.1/6094/AIM-453.... (Part 2).
oluwie 4y ago
I mean ... all programming is is manipulating state/data soo yea I guess this tracks.
- at_a_remove 4y ago
  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.
bhk 4y ago
As 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.
- macintux 4y ago
  Almost certainly there’s no meaningful insight to my random thought, but your comment reminded me of a conversation I had with Joe Armstrong about 10 years ago, discussing control vs data plane for Riak. Originally Riak shipped its data around as part of Erlang’s standard messaging mechanism, the process mailboxes. Over time that was recognized as a bottleneck and data started being handled differently (honestly it’s been such a long time I don’t remember the details, or how far down that road we went). I have no conclusion to this ill-formed rumination, I’m afraid, just that your point about managing state independently reminded me of that conversation.
- BulgarianIdiot 4y ago
  The trick of bubbling to the top is to keep the top nearby. Like erlang. Functional process in an imperative message passing shell.
_skel 4y ago
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 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.
- noduerme 4y ago
  I agree this is mixing apples and oranges. To the degree that server architecture has to preserve state in various situations, though, coming from running my own dedicated monoliths and federated systems to service-oriented architecture about a decade ago, I have to grudgingly admit that the service model really is just cleaner and easier to wrangle. I'm thinking right now of a major version DB upgrade I have to pull this week where I'm going to have a go at the new blue/green provisioning provided by RDS. The old way would have required major downtime, rewiring web services, lots of risk of data collision, not to mention time on the phone with a datacenter just to get up and running. Ultimately the old ways always felt duct taped in some regard, like trying to switch the scenery of a stage production in the middle of an act. I hate that I'm so reliant on Amazon now, but it's just wildly more efficient.
  - auggierose 4y ago
    Would you say that this distinction between SOA and micro services is correct, which I found in an O'Reilly report [1]: > One of the fundamental concepts to remember is that microservices architecture is a share-as-little-as-possible architecture pattern that places a heavy emphasis on the concept of a bounded context, whereas SOA is a share-as-much-as-possible architecture pattern that places heavy emphasis on abstraction and business functionality reuse. By understanding this fundamental concept—as well as the other characteristics, capabilities, and shortcomings of both micro‐ services and SOA that I discussed in this report—you can make a more informed decision about which architecture pattern is right for your situation. Or is this a distinction you would not make (or were not even aware of)? [1] Mark Richards - Microservices vs. Service-Oriented architecture
deleted 4y ago
[deleted]
strangemonad 4y ago
I used to think this until I read Whitehead and Hickey and realized it’s all about time
- harry8 4y ago
  I thought maybe you were referring to a known text or paper. "whitehead and Hickey" search links back to this comment and only one other thing that can't be relevant. So, WTF are you talking about that we should know it and search engines don't?
  - jsty 4y ago
    Rich Hickey's "Simple Made Easy" talk discusses value and time - how mutability ties these together such that value is always time-dependent - and the complexity that results. https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
  - nicklaf 4y ago
    Google turns up a Clojure library called Avout [0]. The library itself isn't too important here, but its website cites the philosophy of Rich Hickey and Alfred North Whitehead on state being an illusion: Rich Hickey has spoken eloquently on mutable state in his talk "Are We There Yet?" [1]. To summarize, Rich and Alfred North Whitehead [2] don't believe in mutable state, it's an illusion. Rather, there are only successions of causally-linked immutable values, and time is derived from the perception of these successions. Causally-linked means the future is a function of the past; processes apply pure functions to immutable values to derive new immutable values, and we assign identity to these chains of values, and perceive change where there is none. Hickey's talk itself is quite interesting and goes into detail on the relevance of Whitehead's ideas in his book Process and Reality to concurrent programming. [0] https://avout.io/ https://avout.io/ [1] https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey/ https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi... [2] https://archive.org/details/AlfredNorthWhiteheadProcessAndReality https://archive.org/details/AlfredNorthWhiteheadProcessAndRe...
- 4y ago
x0054 4y ago
This is dumb. That’s like saying that every food in the world is about carbs because they happen to all contain some amounts of carbs.
armchairhacker 4y ago
State = 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.
- layer8 4y ago
  State is not the same as context, because (nonpure) functions also perform state changes, and concurrent execution can cause shared state to change at any time during the execution of a function, including for objects the function created itself (weren’t existing context). Bugs arise from incorrect assumptions. These can be assumptions about state or context, but really it can be any kind of assumption. Assumptions are a kind of dependency. Minimizing dependencies also helps to minimize assumptions. Similarly, statically checked type systems help by having the compiler double-check at least some of the developer’s assumptions. The more powerful the type system, the more assumptions can be expressed and hence checked. OOP tries to minimize the assumptions and dependencies between code by encapsulation/data hiding and interface contracts. FP tries to minimize them by having the result of a function only depend on its parameters. Declarative programming tries to minimize them by having the program only describe relationships between inputs and outputs. How to minimize the assumptions a given piece of code has to make, and minimizing its dependencies, are the bedrock of all software engineering advice, IMO.
lincpa 4y ago
[dead]
omginternets 4y ago
I mean sure, if you ignore all the non-state related issues...
jxf 4y ago
This article makes an error: All programming philosophies are about state, but they're not _just_ about state.
- bawolff 4y ago
  Disagreeing with someone's thesis is not the same as them making an error. Like maybe you don't find their argument compelling, but that's not the same as them making a factual error.
  - paper_good 4y ago
    Since everyone already clearly understand what he means, so let's avoid playing semantics and instead focus on being clear and straightforward. It seems that your questions are only leading to more confusion and not offering any valuable perspectives.
    - bawolff 4y ago
      My objection was i thought the original comment was being rude, not that it was hard to understand.
      - TheUndead96 4y ago
        Politeness is an orthogonal concept to truth. The article clearly states that programming philosophies "can be boiled down into a simple statement", and the comment you were referring to takes issue with this.
HackOfAllTrades 4y ago
If you trivialize everything, everything looks trivial.
deleted 4y ago
[deleted]
kazinator 4y ago
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 the definition of a Monoid in that particular Monoidal Category. You got that? Declarative: I'm gonna need a corner office with a view, and $200K/y.
- noman-land 4y ago
  This made me laugh. Especially because I've read that exact monad snippet before and had several wtf moments in rapid succession.
- bradrn 4y ago
  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.
  - epwr 4y ago
    You might want to look a bit more closely before you write functional programming off like this. Eg. Clojure is a modern functional language that is used for a lot of things & happens to be dynamic.
    - bradrn 4y ago
      Since when was I writing off FP? My main language for personal projects is Haskell. I was just pointing out that the category theory stuff isn’t really relevant at all.
  - fulafel 4y ago
    Yep, the FP scene is split into the pragmatic and the academic sides. 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.
paper_good 4y ago
Not exactly, how do you connect between Generics Programming and State?
MichaelMoser123 4y ago
well, a program is moving around bits in computer memory, now state is a fancy name for the these bits. Makes sense that the philosophy of p. has something to do with this state of affairs. But the philosophy of p. is also dealing with ways of creating abstractions, because you can't view everything exclusively on a very low level of abstraction, without loosing your mind.
jjtheblunt 4y ago
It feels like the art of choosing strategic abstractions is an underlying theme in SICP, for example, and has “state”, as argued in the blog post, as just one aspect.
sciencesama 4y ago
State laws are different from the central laws
beebmam 4y ago
I don't think this applies to Jonathan Blow's philosophy about programming (in short: that everything in the application stack should be visible, understandable, and debuggable by its developers). So it doesn't apply to all philosophies.
deleted 4y ago
[deleted]
ioquatix 4y ago
"All Programming is about State". All code is state. All state is code. It's turtles all the way down.
- jongjong 4y ago
  Code is logic. Data is state. To say that code is state is like saying that electrical circuits are electricity. Code carries data in the same way that electrical circuits carry electricity.
  - butternoodle 4y ago
    State is data over time!
quickthrower2 4y ago
state, computation, IO … thats all there is!
slaymaker1907 4y ago
There are definitely ones that aren’t: 1. Language Oriented 2. Relational (the main thing there is largely about reversibility) 3. Procedural: Control flow is way more important here than state. Strict procedural might doesn’t allow early return since you then have a block with more than one exit. Therefore, procedural and language oriented seem more about control flow.
ggm 4y ago
Since in reductive sense function theory and turing machines are equivalent (church-turing thesis), and a turing machine is rules and a tape (state) then if a language is turing-complete by definition ...
mirekrusin 4y ago
Political and economic philosophies are also about state. Religions as well. Drinking alcohol also. Colors. Mental states (hey this one even has it in the name). And kind of potateos.
kilgnad 4y ago
I agree with the imperative, oop and functional part. The declarative part is just stretching it. It's like saying using chatGPT to write your code is just a form of state management. Technically yes, but this viewpoint is overly pedantic. Declarative programming is therefore more then just state management.
hsn915 4y ago
Well, programming is about managing state. Also, you forgot Data Oriented Design: state should be modelled to match how the hardware.
- ungamedplayer 4y ago
  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.
csomar 4y ago
This article is bad at managing the state of its examples. Just kidding. But deep down, it's turtles all the way down. All of programming, working and else is about managing state. Especially if you think of state as entropy, then all the meaning of life is about managing state.
osigurdson 4y ago
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.
- yipbub 4y ago
  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.
- skedaddle 4y ago
  "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 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.
- catapart 4y ago
  I feel this, but I think it's just a thing that programmers do. It was 10 years ago when I realized that all programming methods are about dealing with (conceptualizing/architecting) state. It made a lot of stuff "simple" to me that had previously been "complex" and I got a lot of value out of that change in paradigm. Not so much that I didn't assume all my peers didn't already know it (I find I'm usually "behind the curve" when it comes to piecing obvious things together), so didn't evangelize it to anyone, but I definitely understand why someone would. It feels secret, because no one really talks directly about how all programming paradigms are about state. But once you realize it, you can start to see how a lot of high-level programmers reference it when they talk, all the time. Just something that "everybody knows", once you spend enough time working in code. Personally, it wasn't the realization that it's all about state that was particularly exciting. It was using that new interpretation to understand how I could mix and match different types within a single project, to make each separable/modular piece of it, rather than dogmatically sticking to a single paradigm throughout. I think there's a definite mental breakthrough when a programmer can confidently use multiple different state paradigms to handle what would otherwise be a clunky or unwieldy implementation in a single paradigm.
college_physics 4y ago
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
deleted 4y ago
[deleted]
bmitc 4y ago
I think paradigms rather than philosophies is a better term.
- kolme 4y ago
  OO / FP are paradigms. Monolith / microservices are architectures. Paradigm and architecture are orthogonal. I guess the author used "philosophies" because they are mixing pears and apples, so the most specific word that can be stretched enough to encompass those concepts is "philosophy".
wruza 4y ago
I’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.
- mjburgess 4y ago
  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.
- drsopp 4y ago
  Thinking about state helps me write better code. If the codebase for a project is small enough, and I can enumerate all states and all ways that states can change into other states, I can make code that is so stable it can run indefinitely. Very satisfying. The next logical step from this point, I guess, is TLA+ (I still haven't tried it).
vinodkd 4y ago
Funny, I arrived at this "all software is.." piece last week. Hypothesis: All of software *is* about change management ---- It dawned on me that all the software design efforts - Design patterns, programming styles, management practices - are all geared towards one thing at its core - managing change. For example: * Command pattern: Figure out all the things that can be called and instead of a giant if/switch, look them up by name and call them. That way when you need to *change* the list of things you want to call, nothing else is affected. * Structured programming: Keep the common code in one place and call them from many places. That way when the common code *changes*, we can contain the change to one place * Object Oriented Programming: Keep the data and behavior common to one actor in the system contained in an object/class so that when it *changes* we have to change only that thing. * Functional programming: *Changing* data is bad. Instead create copies of data and change them. * Scrum: It's hard to predict too far into the future because things *change*. So let's try to plan for just the next n weeks.
- diatone 4y ago
  If you haven’t already, you might benefit from learning about the idea of OODA loops.
  - vinodkd 4y ago
    Thanks. Also, nice blog post about MMM. Good analogy to finance.
fedeb95 4y ago
you can't really minimize state. functions are stored in the stack, which is... state.
- Dwood023 4y ago
  isn't it minimised if the compiler/OS manages it instead of you?
- Warwolt 4y ago
  The problem isn't that there is any state involved, it's that we as programmers must reason about that state. Evaluating "(1 + 2) * 3" requires some state in the CPU, but I can treat it mentally as just an expression that be reduced down to 9 without me feeling like there's state involved. The only thing that matters in my opinion is if it affects our ability to _reason_ about it
bryanrasmussen 4y ago
surely there must be some focused on naming things and cache invalidation? on edit: yeah I guess cache invalidation is state too.
veltas 4y ago
All state philosophies are about programming, man!
jdthedisciple 4y ago
What happened to good ol' saving state in variables and modifying it using simple operations as needed?
- nicky0 4y ago
  That's covered by Imperative programming in the post.
- wheelerof4te 4y ago
  From my experience, most internal business logic is coded using simple imperative style, even if the language used offers object-oriented solution. Frequently, there are 30+ local variables inside a procedure or a function. It is very rare to even see a class definition. I am talking about mostly financial logic.
- jcrites 4y ago
  When state is stored simply in variables, especially public fields in a structure, then any code can access them -- even if doing so will violate invariants that the type is expected to uphold. For example, if I have a `String` whose byte sequences must be valid UTF8 (as in the case of Rust's `String` type), or if I have a `UnitVector3` (which is a `Vector3` that must be of unit length), then allowing direct manipulation of structure fields (X, Y, Z) creates the possibility of instances existing that break the invariant. In the case of Rust `String` that leads to memory unsafety. Abstractions make it possible to enforce invariants using the type system. If `UnitVector3` provides functions such as a constructor that either (1) takes a valid unit vector as input, or else fails or (2) takes any vector as input, and changes its length to become a unit vector (etc.); and also all of the type's functions return `UnitVector3` (where appropriate, e.g. transformations such as rotation), then it is impossible for an invalid `UnitVector3` to exist! To continue the example, if I add two vectors together, then their sum will be a `Vector3`, not a `UnitVector3` -- so that operation should have the appropriate return type (`Vector3`). Meanwhile rotating a `UnitVector3` will always return a `UnitVector3`. But translating a `UnitVector3` yields a `Vector3`. And so on. Any code written using these operations can determine from their return type what scenarios it needs to handle (is the return value guaranteed to be another unit vector, or could it be any vector?). If any code can access and manipulate the X, Y, Z coordinates of `UnitVector3`, then any code that relies upon instances being actual unit vectors has the potential to misbehave. That code is correct -- it's the code that created an invalid `UnitVector3` that's wrong! But the error will show up somewhere else at runtime. Encapsulating these fields within a type (that provides getter methods), and provides a constructor that validates the input (and fails on invalid), makes this entire class of error impossible. It is still possible for code to attempt to construct an invalid `UnitVector3`, but the call to the constructor (which validates its input) will fail, thus causing the program to fail as soon as possible, and in the most relevant place!: In the code that's creating an invalid vector -- not some obscure other part of the program that is processing the invalid `UnitVector3`. Using the type system to enforce soundness properties is impractical to achieve without encapsulation, and the ability to hide data and provide interfaces to it. Structures with public fields, where any code can modify their value, is very high risk by comparison.
qikInNdOutReply 4y ago
Dont have state. Try to derive it from the data aka the environment. Rather prefer adding state to the environment (timestamps, recipesteps of a product), then keeping seperate track from it, because seperation is, additional state. And state is a curse:re. So dont. If it cant be avoided, dont duplicate state, add a machine that resets it upon sensors detecting a changed environment (data) and revert wherever you can back to deriving it from data. If it is unavoidable, make it concise, so that at least the maintainers can follow the state and see were it goes wrong.
suncore 4y ago
Data (state, context, whatever) is more important to structure than code. Make sure your programming language lets you structure data the way you feel is natural. The code comes later and the main function is to massage the data. At least this is how I usually think about it, but everyones mind works differently... :-)
agumonkey 4y ago
Declarative/logic is a bit of meta-state IMO, the only state is exploration space, but the actual information has no state per se. Also I wonder if algebraic thinking is not different from state, since you map / combine subsets of the domain[0] with more interesting operations. You don't got from 2->3->4, you can (+ 2 2). [0] which some would say, is state, but here it's reified as a standalone value
madsbuch 4y ago
The original author was smart in calling it programming philosophies as it avoids a lot of puristic discussion. As mentioned elsewhere: Pure functional programming (as in lambda calculus and its friends) does not consider state. It consider expressions that need to be reduced – the user can on top of that build something that mimics state, which is entirely up the programmer. However, I think the most productive way of assessing programming languages for real world software applications is by looking at state management, as it usually turns out to be the most complex part of that application.
- bluetomcat 4y ago
  The so maligned "state" in FP resides in the call stack: f(g(h(x))) It's a mutable and invisible data structure that drives the execution of the program.
  - naasking 4y ago
    It's not mutable and it's not a stack in the model, that's just an implementation artifact used for efficiency. You could equally well allocate every function context on the heap.
HenriTEL 4y ago
OP just discovered that computer science is 99% about data manipulation, duh.
yak0 4y ago
All programming philosophies are about 0-1
tristramb 4y ago
[dead]
tristramb 4y ago
[dead]
m0llusk 4y ago
And as states all programming philosophies are going to need some structure in order to function consistently. Laws and enforcement, representation, and an executive to lead things and maintain consistent direction.
jorgeleo 4y ago
1. Yes, software development is about managing state change. If the state has not change, the software is idle or not running 2. The mix of concepts between programming paradigms, architectural design, etc. doesn't body well supporting the conclusion about "every programming philosophy" It feels to me like much ADO about nothing
revskill 4y ago
To me, they're more about minimization of if then else statement.
JohnDeHope 4y ago
I thought of adding external relational databases. The state of the program at runtime isn't really the most important thing. The state of the whole system over the span of days / weeks / months / years is what's really important to get right.
jononor 4y ago
No, all programming philosophies is a about composition? What units one expresses a program in, and how they can be combined together.
seanhunter 4y ago
Since we are programming Von Neumann machines, at their core all programs are about state. Therefore it seems intuitive that all programming philosophies would reflect that.
dqpb 4y ago
Good idea, bad execution

377 points by signa11 4y ago

Side effects: can't live with 'em, can't live without 'em.

"Functional - Modifying state is hard to get correct; keep it at the boundaries and keep logic pure so that it is easier to verify the logic is correct." My main beef with functional programming is that you essentially put the state in the "instruction pointer" and its history of walking the call stack instead of bound to symbols. It does not fit my way of thought. I personally prefer more or less statemachines.

xwdv 4y ago
You don’t need history. Embrace one way data flow and your life will be simpler and more easy to reason about.
epgui 4y ago
I think what you're missing is that functional programming is about referential transparency. There should be no need for an instruction pointer in your mental model.
- deleted 4y ago
  [deleted]
- vc8f6vVV 4y ago
  Not really. Try to interact with DB in FP. Yes, there is a referential transparency ... when combining functions which call DB (e.g. using monads). As a result you get a composite function, which is the same every time you run that composition. Who cares really? When you execute that composite function though you will potentially get different results and your "referential transparency" goes out the window. Of course one can write a "pure" FP program without effects, but any side effect reduces referential transparency to combining functions, is it really easier to reason about computations this way? Nope, it is not. Basically how FP sells: def a 1 end def b 2 end def c a + b end You see? c = 3! Now try to apply this logic to (real world with effects): def a (conn: DBConn) => { .... some complex code ... } end def b (conn: DBConn) => { .. another complex code ... } end def c (conn: DBConn) => a(conn) + b(conn) end So c = ? Still transparent?
  - ARandomerDude 4y ago
    DB operations are not what is being described in the conversation about referential transparency. We’re talking about something that starts with things like reduce vs. a for loop with mutable variables to accumulate values. Once the language forces you to think in terms of stateful operations to perform even basic tasks, the reflexive tendency is to use mutable state to perform any task. At that point, nobody really knows what a functional does because you have to understand the entire system to know what the output of a function will be.
    - vc8f6vVV 4y ago
      But we do have loops in the real world, don't we? So in a true FP we are talking about recursion as an alternative to for loops. Can you easily reduce recursive function? If you can, I can as well "reduce" for loop. Otherwise we are talking about a paradigm without recursions and side effects.
      - ARandomerDude 4y ago
        https://clojuredocs.org/clojure.core/reduce https://clojuredocs.org/clojure.core/reduce
        vc8f6vVV 4y ago
        Recursion, what was the point of the link?
        epgui 4y ago
        Your problem is that you’re trying too hard to argue and your time would be better spent trying to understand.
  - vore 4y ago
    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.
Twisol 4y ago
Is this another way of putting what you're saying? In functional programming, we think of computation as reducing an expression; a computation is complete when it can't be reduced anymore. In imperative programming, we think of computation as updating a store of data; a computation is complete when we run out of steps to perform. When you're partway through execution, the "rest of the program" in an imperative system is captured by the current state of the store (including the stack). In a functional program, the "rest of the program" is just the program expression itself, reduced as it has been up to this point. I tend to like the functional model, myself, but I can see the mental appeal of keeping the program text fixed, and isolating all changes to a separate store of data.
dustingetz 4y ago
modern FP (effect systems) says the opposite - having separating the pure from the impure, we can now bring them back together and orchestrate fine grained fabrics of effects at greater scale with deterministic lifecycle and strong real source cleanup guarantees; for example signals based reactive dom rendering

q845712 4y ago

It's been a while but I used to enjoy telling folks in the early years of their career that software engineers and anarchists have a lot in common because both view "the state" as the main cause of problems.

eyelidlessness 4y ago
Former long time anarchist, current long time FP proponent, presently having a laugh with you on this.
- weatherlight 4y ago
  A Classless and stateless society! sign me up!
- shaunxcode 4y ago
  we must build a Functional Economy.
- epolanski 4y ago
  I bet 1 $ you work in crypto.
  - eyelidlessness 4y ago
    Nope! You can actually find out what I do for work pretty easily tho because it’s all open source and I use the same handle. Edit: please donate the proceeds of your bet loss to victims of the earthquakes in Türkiye.
  - deleted 4y ago
    [deleted]
- IngoBlechschmid 4y ago
  Out of curiosity, why former?
  - bcherny 4y ago

philosopher1234 4y ago

i want to see someone elaborate a state-maximizing, instead of state-minimizing, philosophy. lean in

swagasaurus-rex 4y ago
... Recurrent neural networks?
deleted 4y ago
[deleted]
chapium 4y ago
Spaghetti architecture. There is so much state organizational controls outside the codebase limit which parts of the code may be executed at any given time.
mostlylurks 4y ago
Forth in its simpler implementations seems like it goes about as far as one could conceivably go in terms of maximizing state, or minimizing non-state. No parameters or perhaps even local variables, everything is just pushed onto a stack (or one of many stacks) that can be freely manipulated at any point. No major opaque control flow mechanisms, ifs and loops are implemented as functions operating on an exposed "return stack" which can be freely manipulated. No opaque function definitions compiled into a binary, function implementations are placed in a data structure that can be freely accessed at any time. No separate compile stage that manipulates state otherwise inaccessible to the program, compilation happens at run-time by manipulating freely accessible data structures, and the "syntax" for compiling things is essentially just function calls that manipulate globally accessible state based on what's in the input stream and you can write your own alternatives if you want. If the functional paradigm tends towards avoiding state, then it would seem to me that forth does the opposite: making almost everything a part of the state of a program that a developer can access and manipulate, even things that most structured programming languages do not expose to the developer.
dqpb 4y ago
State machines?

chowells 4y ago

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

epolanski 4y ago
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.
- frutiger 4y ago
  > 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.
  - EugeneOZ 4y ago
    While you can’t read the state, it's not a “state”, it's just a chaotic mess of data in memory.
- User23 4y ago
  > FP is about evaluating expressions and it doesn't have state all over the place. FP is all about side effects. Every time you declare something you're effecting a compile time side effect. And then there's monads, which are literally reinventing state with a worse API. I find it odd that no mainstream functional language has an explicit call stack monad and an explicit symbol table monad. Maybe because even the "purists" realize how asinine that would be. > 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. Mutable state is a powerful tool. And it's true that if carpenters used table saws with the same level of discipline that programmers use compilers, there wouldn't be a carpenter left with any fingers. Nevertheless, powerful tools can be used in a responsible and disciplined way and if you do you can be highly confident no unexpected dismemberment, literal or metaphorical, will occur. Edit: to be more explicit, the mathematicians who invented Algol were well aware of all the theory for so-called functional programming and rejected it in favor of treating programs as transformations of a multidimensional space with good reason.

tweroiu23o43 4y ago

No it is not. Lisp stands in stark contrast to this. The lisp philosophy is this: as with every science, you mould your language to your problem, not the other way around.

ihatepython 4y ago
Yes, it goes without saying that Lisp and mold go hand in hand. I find that Lisp is very organic, kind of like fungus.
astrange 4y ago
Sure, because they haven't heard of the rule of least power, which is why it's sometimes good for languages to be about stopping you from doing the wrong thing vs. easily doing things.

georgeoliver 4y ago

Has anyone or any PL theory in CS made a useful distinction between data and state?

taneq 4y ago
They're different levels of abstraction. Data is used to describe state.
Twisol 4y ago
State is made of data. The difference is that state is data together with a persistent identity (morally, a location), and the data associated with that identity may change over time.
bheadmaster 4y ago
Turing Machines are defined in a way which makes a distinction between data and state - it consists of a state machine (which controls what happens when each symbol is read) and a tape (which records symbols - data - which will be manipulated). The state machine is part of the Turing Machine's definition - so one Turing Machine can only have one particular state machine configuration, but can operate on any tape with any content. However, the existence of Universal Turing Machine (a Turing Machine that can simulate behavior of any other Turing Machine) demonstrates that data can also represent state - i.e. you can encode an arbitrary Turing Machine's state machine in the tape, without changing the Universal Turing Machine's state machine at all. That's how we got stored program computers. In a more practical sense, a useful distinction between data and state is within the boundaries of the program - any data that is internal to your program can be considered state, while any data that you read from an external source/write to an external sink can be considered just plain data. Separating the two is a helpful technique in writing reliable software.

pharmakom 4y ago

Functional and declarative are the same to me

eyelidlessness 4y ago
I think what the article intended by “declarative” is roughly occupied by the “logic programming” paradigm and DSLs like SQL. If my intuition is right, they have a lot of conceptual overlap. But they differ mostly in how much they realize a goal of “what, not how”.
epgui 4y ago
They're related, but "declarative" is a broader category that includes relations. Functions are a special case of relations (see also: prolog, datalog, sql...).
- manmal 4y ago
  You can write declarative code in an imperative language, and you can write non-declarative code in a functional language (eg IO monad). So IMO they can’t be related. That’s assuming that „declarative“ means „describing outcomes rather than describing process“.
  - epgui 4y ago
    You can write functional code in an imperative language and you can write imperative code in a language like Haskell, but that’s irrelevant.
manmal 4y ago
They are orthogonal. React (FC) is a declarative _and_ functional approach. The declarative part is where React code describes what should be rendered, instead of adding/removing DOM elements manually. The old React is not 100% functional (partially OO), but it still is declarative.
- epgui 4y ago

throwawaaarrgh 4y ago

They forgot Immutable! The best way to handle state.

skibidibipiti 4y ago
[dead]
manmal 4y ago
Is that not covered by functional programming?

nagonago 4y ago

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

lolinder 4y ago
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.

mellis 4y ago

There's a great discussion of state in one of the original lambda papers: "The Art of the Interpreter or, the Modularity Complex" by Gerald Sussman and Guy Steele from 1978: https://dspace.mit.edu/bitstream/handle/1721.1/6094/AIM-453.pdf https://dspace.mit.edu/bitstream/handle/1721.1/6094/AIM-453.... (Part 2).

oluwie 4y ago

I mean ... all programming is is manipulating state/data soo yea I guess this tracks.

at_a_remove 4y ago
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.

bhk 4y ago

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

macintux 4y ago
Almost certainly there’s no meaningful insight to my random thought, but your comment reminded me of a conversation I had with Joe Armstrong about 10 years ago, discussing control vs data plane for Riak. Originally Riak shipped its data around as part of Erlang’s standard messaging mechanism, the process mailboxes. Over time that was recognized as a bottleneck and data started being handled differently (honestly it’s been such a long time I don’t remember the details, or how far down that road we went). I have no conclusion to this ill-formed rumination, I’m afraid, just that your point about managing state independently reminded me of that conversation.
BulgarianIdiot 4y ago
The trick of bubbling to the top is to keep the top nearby. Like erlang. Functional process in an imperative message passing shell.

_skel 4y ago

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

noduerme 4y ago
I agree this is mixing apples and oranges. To the degree that server architecture has to preserve state in various situations, though, coming from running my own dedicated monoliths and federated systems to service-oriented architecture about a decade ago, I have to grudgingly admit that the service model really is just cleaner and easier to wrangle. I'm thinking right now of a major version DB upgrade I have to pull this week where I'm going to have a go at the new blue/green provisioning provided by RDS. The old way would have required major downtime, rewiring web services, lots of risk of data collision, not to mention time on the phone with a datacenter just to get up and running. Ultimately the old ways always felt duct taped in some regard, like trying to switch the scenery of a stage production in the middle of an act. I hate that I'm so reliant on Amazon now, but it's just wildly more efficient.
- auggierose 4y ago
  Would you say that this distinction between SOA and micro services is correct, which I found in an O'Reilly report [1]: > One of the fundamental concepts to remember is that microservices architecture is a share-as-little-as-possible architecture pattern that places a heavy emphasis on the concept of a bounded context, whereas SOA is a share-as-much-as-possible architecture pattern that places heavy emphasis on abstraction and business functionality reuse. By understanding this fundamental concept—as well as the other characteristics, capabilities, and shortcomings of both micro‐ services and SOA that I discussed in this report—you can make a more informed decision about which architecture pattern is right for your situation. Or is this a distinction you would not make (or were not even aware of)? [1] Mark Richards - Microservices vs. Service-Oriented architecture

deleted 4y ago

[deleted]

strangemonad 4y ago

I used to think this until I read Whitehead and Hickey and realized it’s all about time

harry8 4y ago
I thought maybe you were referring to a known text or paper. "whitehead and Hickey" search links back to this comment and only one other thing that can't be relevant. So, WTF are you talking about that we should know it and search engines don't?
- jsty 4y ago
  Rich Hickey's "Simple Made Easy" talk discusses value and time - how mutability ties these together such that value is always time-dependent - and the complexity that results. https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/SimpleMadeEasy.md https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
- nicklaf 4y ago
  Google turns up a Clojure library called Avout [0]. The library itself isn't too important here, but its website cites the philosophy of Rich Hickey and Alfred North Whitehead on state being an illusion: Rich Hickey has spoken eloquently on mutable state in his talk "Are We There Yet?" [1]. To summarize, Rich and Alfred North Whitehead [2] don't believe in mutable state, it's an illusion. Rather, there are only successions of causally-linked immutable values, and time is derived from the perception of these successions. Causally-linked means the future is a function of the past; processes apply pure functions to immutable values to derive new immutable values, and we assign identity to these chains of values, and perceive change where there is none. Hickey's talk itself is quite interesting and goes into detail on the relevance of Whitehead's ideas in his book Process and Reality to concurrent programming. [0] https://avout.io/ https://avout.io/ [1] https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey/ https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hi... [2] https://archive.org/details/AlfredNorthWhiteheadProcessAndReality https://archive.org/details/AlfredNorthWhiteheadProcessAndRe...
4y ago

x0054 4y ago

This is dumb. That’s like saying that every food in the world is about carbs because they happen to all contain some amounts of carbs.

armchairhacker 4y ago

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

layer8 4y ago
State is not the same as context, because (nonpure) functions also perform state changes, and concurrent execution can cause shared state to change at any time during the execution of a function, including for objects the function created itself (weren’t existing context). Bugs arise from incorrect assumptions. These can be assumptions about state or context, but really it can be any kind of assumption. Assumptions are a kind of dependency. Minimizing dependencies also helps to minimize assumptions. Similarly, statically checked type systems help by having the compiler double-check at least some of the developer’s assumptions. The more powerful the type system, the more assumptions can be expressed and hence checked. OOP tries to minimize the assumptions and dependencies between code by encapsulation/data hiding and interface contracts. FP tries to minimize them by having the result of a function only depend on its parameters. Declarative programming tries to minimize them by having the program only describe relationships between inputs and outputs. How to minimize the assumptions a given piece of code has to make, and minimizing its dependencies, are the bedrock of all software engineering advice, IMO.

lincpa 4y ago

[dead]

omginternets 4y ago

I mean sure, if you ignore all the non-state related issues...

jxf 4y ago

This article makes an error: All programming philosophies are about state, but they're not _just_ about state.

bawolff 4y ago
Disagreeing with someone's thesis is not the same as them making an error. Like maybe you don't find their argument compelling, but that's not the same as them making a factual error.
- paper_good 4y ago
  Since everyone already clearly understand what he means, so let's avoid playing semantics and instead focus on being clear and straightforward. It seems that your questions are only leading to more confusion and not offering any valuable perspectives.
  - bawolff 4y ago
    My objection was i thought the original comment was being rude, not that it was hard to understand.
    - TheUndead96 4y ago
      Politeness is an orthogonal concept to truth. The article clearly states that programming philosophies "can be boiled down into a simple statement", and the comment you were referring to takes issue with this.

HackOfAllTrades 4y ago

If you trivialize everything, everything looks trivial.

deleted 4y ago

[deleted]

kazinator 4y ago

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 the definition of a Monoid in that particular Monoidal Category. You got that? Declarative: I'm gonna need a corner office with a view, and $200K/y.

noman-land 4y ago
This made me laugh. Especially because I've read that exact monad snippet before and had several wtf moments in rapid succession.
bradrn 4y ago
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.
- epwr 4y ago
  You might want to look a bit more closely before you write functional programming off like this. Eg. Clojure is a modern functional language that is used for a lot of things & happens to be dynamic.
  - bradrn 4y ago
    Since when was I writing off FP? My main language for personal projects is Haskell. I was just pointing out that the category theory stuff isn’t really relevant at all.
- fulafel 4y ago
  Yep, the FP scene is split into the pragmatic and the academic sides. 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.

paper_good 4y ago

Not exactly, how do you connect between Generics Programming and State?

MichaelMoser123 4y ago

well, a program is moving around bits in computer memory, now state is a fancy name for the these bits. Makes sense that the philosophy of p. has something to do with this state of affairs. But the philosophy of p. is also dealing with ways of creating abstractions, because you can't view everything exclusively on a very low level of abstraction, without loosing your mind.

jjtheblunt 4y ago

It feels like the art of choosing strategic abstractions is an underlying theme in SICP, for example, and has “state”, as argued in the blog post, as just one aspect.

sciencesama 4y ago

State laws are different from the central laws

beebmam 4y ago

I don't think this applies to Jonathan Blow's philosophy about programming (in short: that everything in the application stack should be visible, understandable, and debuggable by its developers). So it doesn't apply to all philosophies.

deleted 4y ago

[deleted]

ioquatix 4y ago

"All Programming is about State". All code is state. All state is code. It's turtles all the way down.

jongjong 4y ago
Code is logic. Data is state. To say that code is state is like saying that electrical circuits are electricity. Code carries data in the same way that electrical circuits carry electricity.
- butternoodle 4y ago
  State is data over time!

quickthrower2 4y ago

state, computation, IO … thats all there is!

slaymaker1907 4y ago

There are definitely ones that aren’t: 1. Language Oriented 2. Relational (the main thing there is largely about reversibility) 3. Procedural: Control flow is way more important here than state. Strict procedural might doesn’t allow early return since you then have a block with more than one exit. Therefore, procedural and language oriented seem more about control flow.

ggm 4y ago

Since in reductive sense function theory and turing machines are equivalent (church-turing thesis), and a turing machine is rules and a tape (state) then if a language is turing-complete by definition ...

mirekrusin 4y ago

Political and economic philosophies are also about state. Religions as well. Drinking alcohol also. Colors. Mental states (hey this one even has it in the name). And kind of potateos.

kilgnad 4y ago

I agree with the imperative, oop and functional part. The declarative part is just stretching it. It's like saying using chatGPT to write your code is just a form of state management. Technically yes, but this viewpoint is overly pedantic. Declarative programming is therefore more then just state management.

hsn915 4y ago

Well, programming is about managing state. Also, you forgot Data Oriented Design: state should be modelled to match how the hardware.

ungamedplayer 4y ago
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.

csomar 4y ago

This article is bad at managing the state of its examples. Just kidding. But deep down, it's turtles all the way down. All of programming, working and else is about managing state. Especially if you think of state as entropy, then all the meaning of life is about managing state.

osigurdson 4y ago

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.

yipbub 4y ago
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.
skedaddle 4y ago
"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 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.
catapart 4y ago
I feel this, but I think it's just a thing that programmers do. It was 10 years ago when I realized that all programming methods are about dealing with (conceptualizing/architecting) state. It made a lot of stuff "simple" to me that had previously been "complex" and I got a lot of value out of that change in paradigm. Not so much that I didn't assume all my peers didn't already know it (I find I'm usually "behind the curve" when it comes to piecing obvious things together), so didn't evangelize it to anyone, but I definitely understand why someone would. It feels secret, because no one really talks directly about how all programming paradigms are about state. But once you realize it, you can start to see how a lot of high-level programmers reference it when they talk, all the time. Just something that "everybody knows", once you spend enough time working in code. Personally, it wasn't the realization that it's all about state that was particularly exciting. It was using that new interpretation to understand how I could mix and match different types within a single project, to make each separable/modular piece of it, rather than dogmatically sticking to a single paradigm throughout. I think there's a definite mental breakthrough when a programmer can confidently use multiple different state paradigms to handle what would otherwise be a clunky or unwieldy implementation in a single paradigm.

college_physics 4y ago

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

deleted 4y ago

[deleted]

bmitc 4y ago

I think paradigms rather than philosophies is a better term.

kolme 4y ago
OO / FP are paradigms. Monolith / microservices are architectures. Paradigm and architecture are orthogonal. I guess the author used "philosophies" because they are mixing pears and apples, so the most specific word that can be stretched enough to encompass those concepts is "philosophy".

wruza 4y ago

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

mjburgess 4y ago
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.
drsopp 4y ago
Thinking about state helps me write better code. If the codebase for a project is small enough, and I can enumerate all states and all ways that states can change into other states, I can make code that is so stable it can run indefinitely. Very satisfying. The next logical step from this point, I guess, is TLA+ (I still haven't tried it).

vinodkd 4y ago

Funny, I arrived at this "all software is.." piece last week. Hypothesis: All of software *is* about change management ---- It dawned on me that all the software design efforts - Design patterns, programming styles, management practices - are all geared towards one thing at its core - managing change. For example: * Command pattern: Figure out all the things that can be called and instead of a giant if/switch, look them up by name and call them. That way when you need to *change* the list of things you want to call, nothing else is affected. * Structured programming: Keep the common code in one place and call them from many places. That way when the common code *changes*, we can contain the change to one place * Object Oriented Programming: Keep the data and behavior common to one actor in the system contained in an object/class so that when it *changes* we have to change only that thing. * Functional programming: *Changing* data is bad. Instead create copies of data and change them. * Scrum: It's hard to predict too far into the future because things *change*. So let's try to plan for just the next n weeks.

diatone 4y ago
If you haven’t already, you might benefit from learning about the idea of OODA loops.
- vinodkd 4y ago
  Thanks. Also, nice blog post about MMM. Good analogy to finance.

fedeb95 4y ago

you can't really minimize state. functions are stored in the stack, which is... state.

Dwood023 4y ago
isn't it minimised if the compiler/OS manages it instead of you?
Warwolt 4y ago
The problem isn't that there is any state involved, it's that we as programmers must reason about that state. Evaluating "(1 + 2) * 3" requires some state in the CPU, but I can treat it mentally as just an expression that be reduced down to 9 without me feeling like there's state involved. The only thing that matters in my opinion is if it affects our ability to _reason_ about it

bryanrasmussen 4y ago

surely there must be some focused on naming things and cache invalidation? on edit: yeah I guess cache invalidation is state too.

veltas 4y ago

All state philosophies are about programming, man!

jdthedisciple 4y ago

What happened to good ol' saving state in variables and modifying it using simple operations as needed?

nicky0 4y ago
That's covered by Imperative programming in the post.
wheelerof4te 4y ago
From my experience, most internal business logic is coded using simple imperative style, even if the language used offers object-oriented solution. Frequently, there are 30+ local variables inside a procedure or a function. It is very rare to even see a class definition. I am talking about mostly financial logic.
jcrites 4y ago
When state is stored simply in variables, especially public fields in a structure, then any code can access them -- even if doing so will violate invariants that the type is expected to uphold. For example, if I have a `String` whose byte sequences must be valid UTF8 (as in the case of Rust's `String` type), or if I have a `UnitVector3` (which is a `Vector3` that must be of unit length), then allowing direct manipulation of structure fields (X, Y, Z) creates the possibility of instances existing that break the invariant. In the case of Rust `String` that leads to memory unsafety. Abstractions make it possible to enforce invariants using the type system. If `UnitVector3` provides functions such as a constructor that either (1) takes a valid unit vector as input, or else fails or (2) takes any vector as input, and changes its length to become a unit vector (etc.); and also all of the type's functions return `UnitVector3` (where appropriate, e.g. transformations such as rotation), then it is impossible for an invalid `UnitVector3` to exist! To continue the example, if I add two vectors together, then their sum will be a `Vector3`, not a `UnitVector3` -- so that operation should have the appropriate return type (`Vector3`). Meanwhile rotating a `UnitVector3` will always return a `UnitVector3`. But translating a `UnitVector3` yields a `Vector3`. And so on. Any code written using these operations can determine from their return type what scenarios it needs to handle (is the return value guaranteed to be another unit vector, or could it be any vector?). If any code can access and manipulate the X, Y, Z coordinates of `UnitVector3`, then any code that relies upon instances being actual unit vectors has the potential to misbehave. That code is correct -- it's the code that created an invalid `UnitVector3` that's wrong! But the error will show up somewhere else at runtime. Encapsulating these fields within a type (that provides getter methods), and provides a constructor that validates the input (and fails on invalid), makes this entire class of error impossible. It is still possible for code to attempt to construct an invalid `UnitVector3`, but the call to the constructor (which validates its input) will fail, thus causing the program to fail as soon as possible, and in the most relevant place!: In the code that's creating an invalid vector -- not some obscure other part of the program that is processing the invalid `UnitVector3`. Using the type system to enforce soundness properties is impractical to achieve without encapsulation, and the ability to hide data and provide interfaces to it. Structures with public fields, where any code can modify their value, is very high risk by comparison.

qikInNdOutReply 4y ago

Dont have state. Try to derive it from the data aka the environment. Rather prefer adding state to the environment (timestamps, recipesteps of a product), then keeping seperate track from it, because seperation is, additional state. And state is a curse:re. So dont. If it cant be avoided, dont duplicate state, add a machine that resets it upon sensors detecting a changed environment (data) and revert wherever you can back to deriving it from data. If it is unavoidable, make it concise, so that at least the maintainers can follow the state and see were it goes wrong.

suncore 4y ago

Data (state, context, whatever) is more important to structure than code. Make sure your programming language lets you structure data the way you feel is natural. The code comes later and the main function is to massage the data. At least this is how I usually think about it, but everyones mind works differently... :-)

agumonkey 4y ago

Declarative/logic is a bit of meta-state IMO, the only state is exploration space, but the actual information has no state per se. Also I wonder if algebraic thinking is not different from state, since you map / combine subsets of the domain[0] with more interesting operations. You don't got from 2->3->4, you can (+ 2 2). [0] which some would say, is state, but here it's reified as a standalone value

madsbuch 4y ago

The original author was smart in calling it programming philosophies as it avoids a lot of puristic discussion. As mentioned elsewhere: Pure functional programming (as in lambda calculus and its friends) does not consider state. It consider expressions that need to be reduced – the user can on top of that build something that mimics state, which is entirely up the programmer. However, I think the most productive way of assessing programming languages for real world software applications is by looking at state management, as it usually turns out to be the most complex part of that application.

bluetomcat 4y ago
The so maligned "state" in FP resides in the call stack: f(g(h(x))) It's a mutable and invisible data structure that drives the execution of the program.
- naasking 4y ago
  It's not mutable and it's not a stack in the model, that's just an implementation artifact used for efficiency. You could equally well allocate every function context on the heap.

HenriTEL 4y ago

OP just discovered that computer science is 99% about data manipulation, duh.

yak0 4y ago

All programming philosophies are about 0-1

tristramb 4y ago

[dead]

tristramb 4y ago

[dead]

m0llusk 4y ago

And as states all programming philosophies are going to need some structure in order to function consistently. Laws and enforcement, representation, and an executive to lead things and maintain consistent direction.

jorgeleo 4y ago

1. Yes, software development is about managing state change. If the state has not change, the software is idle or not running 2. The mix of concepts between programming paradigms, architectural design, etc. doesn't body well supporting the conclusion about "every programming philosophy" It feels to me like much ADO about nothing

revskill 4y ago

To me, they're more about minimization of if then else statement.

JohnDeHope 4y ago

I thought of adding external relational databases. The state of the program at runtime isn't really the most important thing. The state of the whole system over the span of days / weeks / months / years is what's really important to get right.

jononor 4y ago

No, all programming philosophies is a about composition? What units one expresses a program in, and how they can be combined together.

seanhunter 4y ago

Since we are programming Von Neumann machines, at their core all programs are about state. Therefore it seems intuitive that all programming philosophies would reflect that.

dqpb 4y ago

Good idea, bad execution