Live data from Hacker News

Programmers are bad at managing state (2020)

nolanlawson.com

31–40 of 60 posts

Re: Programmers are bad at managing state (2020)

#31
post #5

Whenever someone mentions state I think of Rich Hickey's talk "Simple Made Easy" in which he seems almost terrified of state and strives always for pure functions, because as a human he has a hard limit as to how much state he can keep in his head at once when reasoning about the program. He's right. I've worked on enough bad code, including sometimes my own, to know that programmers are bad at managing state. "Simpl…

That just developers being lazy! As a user, I want my computer and my software to manage all state for me. This means remembering all data I entered (so I can continue work from where I left off), all files I saved (so I can search for them easily), all actions I've taken (so I can undo them), all sites I browsed (so I can find them again), all info I uploaded (so I can check which website knows what about me), etc.

Re: Programmers are bad at managing state (2020)

#32
post #18
post #4

Earlier quoted context omitted.

There are only two hard things in Computer science: cache validation, off bdata races. y one,

Don't forget naming things. I can never decide whether to call two arguments 'a' and 'b', or 'x' and 'y'.

It was consumed by undefined behavior.

Re: Programmers are bad at managing state (2020)

#33
post #20

We actually have a great tool to manage state, but nobody seems to have used it to its full potential: regular expressions. Imagine your program is a big state machine, and inputs and other events are making it transition from one state to another, and when in a state the apropos actions are performed. On this view, your program just is a regular expression parser--the tokenized stream of input events is what it is p…

Well, actually, you store your part of your state in a theoretically unbounded random access memory device, or equivalently, a tape.

Except the tape gets overwritten/looped over. What GP was referring to is event-sourcing the state in an append-only log and running finite state automata on this sequence.

Here is a java lib that apply regex to stream of Objects that could be used to achieve this purpose.

https://github.com/norswap/skelex

Re: Programmers are bad at managing state (2020)

#34
post #5

Whenever someone mentions state I think of Rich Hickey's talk "Simple Made Easy" in which he seems almost terrified of state and strives always for pure functions, because as a human he has a hard limit as to how much state he can keep in his head at once when reasoning about the program. He's right. I've worked on enough bad code, including sometimes my own, to know that programmers are bad at managing state. "Simpl…

Pure functions are useless without inputs and outputs. The missing piece of the puzzle here is that we only want transitions between valid states. One way to define valid states is by enforcing invariants which must always be true. Armed with these, all the stuff that happens in-between can be guarded against, much like constraints in a database schema.

Contrast this with non-pure functions which incrementally mutate from a valid state, to a sequence of invalid states, and end up at a valid state again. If something goes wrong along the way, we end up with an invalid state. Think about program state like it's a journaling file system.

Re: Programmers are bad at managing state (2020)

#35

Earlier quoted context omitted.

Well, actually, you store your part of your state in a theoretically unbounded random access memory device, or equivalently, a tape.

Except the tape gets overwritten/looped over. What GP was referring to is event-sourcing the state in an append-only log and running finite state automata on this sequence. Here is a java lib that apply regex to stream of Objects that could be used to achieve this purpose. https://github.com/norswap/skelex

Thanks for the link, exactly the kind of thing I was talking about.

Re: Programmers are bad at managing state (2020)

#36
post #5

Whenever someone mentions state I think of Rich Hickey's talk "Simple Made Easy" in which he seems almost terrified of state and strives always for pure functions, because as a human he has a hard limit as to how much state he can keep in his head at once when reasoning about the program. He's right. I've worked on enough bad code, including sometimes my own, to know that programmers are bad at managing state. "Simpl…

That just developers being lazy! As a user, I want my computer and my software to manage all state for me. This means remembering all data I entered (so I can continue work from where I left off), all files I saved (so I can search for them easily), all actions I've taken (so I can undo them), all sites I browsed (so I can find them again), all info I uploaded (so I can check which website knows what about me), etc.

I also found this to be defeatist (and the basis of the post):

> As a programmer, it’s impossible to predict all the states that your program can end up in.

It's true that we can't predict all the things other programmers will change the program to do in the future, but we can take precautions such as rejecting invalid states, or if being liberal in the input it accepts transform it to something usable.

Re: Programmers are bad at managing state (2020)

#37
post #5

Whenever someone mentions state I think of Rich Hickey's talk "Simple Made Easy" in which he seems almost terrified of state and strives always for pure functions, because as a human he has a hard limit as to how much state he can keep in his head at once when reasoning about the program. He's right. I've worked on enough bad code, including sometimes my own, to know that programmers are bad at managing state. "Simpl…

[deleted]

Re: Programmers are bad at managing state (2020)

#38
Hiding in Jetpack Compose (Google's modern UI framework built for Android) is an incredible MVCC-based state management system that solves several problems at once:

1. Concurrent modifications: Variables wrapped in the State interface are automatically snapshotted, and readers see the most recent snapshot.

2. Observability: State reads are recorded since the last snapshot, which invalidates the Composable functions that contain the read, triggering a refresh of the UI.

3. Consistency: Because you're operating on snapshots, you don't need to wrap all mutable state in an immutable sum type; all changes are consistent with each other within a snapshot. So you can fearlessly keep state as a disconnected set of mutable variables and write naïve UI code without the boilerplate that comes with encoding state machines (or state charts).

I understand that React and SwiftUI are similar to an extent, but this feels better because it's actually completely disconnected from Compose-the-UI-framework. I would love the snapshot system to be ported to other environments.

Re: Programmers are bad at managing state (2020)

#39

Popped in here to say that AFAIK/IMO, most of the things people treat as "state" is actually "data". And then I started thinking myself in circles around "okay, so what is state?". Rather than /keep/ thinking myself in circles, I'll ask: What do y'all think "state" is ?

State is data that you use in control flow decisions. (This is a 5-second reaction, not a deeply considered opinion, don't take it too seriously)

> (This is a 5-second reaction, not a deeply considered opinion, don't take it too seriously)

If you have to put a disclaimer that basically invalidates your statement, why make the statement at all?

Re: Programmers are bad at managing state (2020)

#40

Earlier quoted context omitted.

State is data that you use in control flow decisions. (This is a 5-second reaction, not a deeply considered opinion, don't take it too seriously)

> (This is a 5-second reaction, not a deeply considered opinion, don't take it too seriously) If you have to put a disclaimer that basically invalidates your statement, why make the statement at all?

It doesn't invalidate it, it offers context.
Post reply on HN