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

Programmers are bad at managing state (2020)

nolanlawson.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Programmers are bad at managing state (2020)

#41

Post by Jensson »

RangerScience wrote: post #19

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 ?

If you can refactor it then it isn't data, just programming bookkeeping. Some programming bookkeeping is tied to data, but a lot of it isn't.

For example, you can often add or remove state of things without changing how the program works.

Re: Programmers are bad at managing state (2020)

#42

Post by paulddraper »

0xbadcafebee wrote: post #16

I think this kind of misses the point. Yes, programmers are bad at managing state. But programmers aren't managing state, the programs they write are. Programmers are bad at programming. This isn't hard to understand at a fundamental level. Ask a programmer to write one simple algorithm during an interview, and there can be dozens of different bugs found. Modern software is made up of millions of these algorithms. So…

> there are no building codes for software

There are all sorts of standards...ODBC, SOC II, ISO 27001, POSIX, Unicode, HIPAA, ISO 8601, SOAP, GDPR, JSON-API, W3C, OCI, etc.

Codes coming out the ears.

Re: Programmers are bad at managing state (2020)

#43

Post by 0xbadcafebee »

paulddraper wrote: post #42
0xbadcafebee wrote: post #16

I think this kind of misses the point. Yes, programmers are bad at managing state. But programmers aren't managing state, the programs they write are. Programmers are bad at programming. This isn't hard to understand at a fundamental level. Ask a programmer to write one simple algorithm during an interview, and there can be dozens of different bugs found. Modern software is made up of millions of these algorithms. So…

> there are no building codes for software There are all sorts of standards...ODBC, SOC II, ISO 27001, POSIX, Unicode, HIPAA, ISO 8601, SOAP, GDPR, JSON-API, W3C, OCI, etc. Codes coming out the ears.

Those aren't really like building codes. Building codes are effectively minimum specifications for safety, with the requirement that they can be inspected and approved. The codes eventually became more uniform, but their original intent was to prevent shoddy workmanship from creating hazardous conditions.

SOC II and ISO 27001 have to do with security, which is close to safety, but not the same. GDPR and HIPAA are concerned with privacy, which is more related to security than safety. The rest are about compatibility.

If somebody breaks into a building, that's a security issue. If the building falls down, that's a safety issue. Software can be secure, private, and compatible, and still crash all the time. Safety isn't the same as reliability, but safety tends to lead to reliability, because if it wasn't reliable, it wouldn't be all that safe.

So I think we could use standards that focus more on safety [and reliability]. It won't make the products make more money - in fact, it'll cost more to make them. But the result will be better for people and society overall, the way building codes have been.

Re: Programmers are bad at managing state (2020)

#44

Post by btschaegg »

hnb2137 wrote: post #6
Ygg2 wrote: post #4

Earlier quoted context omitted.

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

And only once delivery. And only once delivery.

This reads more and more like Monty Python's Spanish inquisition sketches. I love it :)

Re: Programmers are bad at managing state (2020)

#45

Post by btschaegg »

RangerScience wrote: post #19

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 ?

Okay, I'll have a go:

State is the data required to continue the operation of a program. That's always the case (also in non-FP contexts), but state is often smeared all over a program as only loosely and implicitly connected pieces whereas FP is mainly concerned with how to manage state (and thus also with how to compose such pieces of state into a greater whole so it's easier to manage).

Edit: Note that there is also "data you don't need for continuing the operation of the program", which we could categorize as "input", "output" and "wasted memory/storage/cpu cycles". The last of the three can obviously still be crucial for other reasons than program execution (e.g. debugging), which makes the line between output and waste blurry.

Re: Programmers are bad at managing state (2020)

#46

Post by glangdale »

rhelz wrote: 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…

This would be, speaking as someone who has dealt with his share of state machines, quite confusing. The uncomfortable thing about regular expression implementation as automata is either (a) non-determinism (i.e. "being in many states at once" a la Glushkov or Thompson NFAs, not "non-determinism meaning something different might happen on any given execution") or (b) state explosion (in a DFA, to represent non-determinism).

This has a huge impact on trying to hook actions, call-backs, etc (your "arbitrary procedure") to NFA states as you're frequently making many overlapping entries to these states, many of which go nowhere. Trying to figure out which entries correspond to which other entries isn't easy.

There are very stylized automata that are used in parsing that do interesting things beyond the finite automata space (like pushing things onto a stack), but they don't correspond to regex per se - instead they are generated from a grammar.

Re: Programmers are bad at managing state (2020)

#47

Post by jonstewart »

rhelz wrote: 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…

Regex with callbacks? Congrats, you’ve reinvented lex.

Re: Programmers are bad at managing state (2020)

#48

Post by gavinhoward »

azornathogron wrote: post #23
RangerScience wrote: post #19

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 the correct formulation.

I also have a blog post coming out tomorrow with a bit of justification for this.

Re: Programmers are bad at managing state (2020)

#49

Post by paulddraper »

0xbadcafebee wrote: post #43
paulddraper wrote: post #42

Earlier quoted context omitted.

> there are no building codes for software There are all sorts of standards...ODBC, SOC II, ISO 27001, POSIX, Unicode, HIPAA, ISO 8601, SOAP, GDPR, JSON-API, W3C, OCI, etc. Codes coming out the ears.

Those aren't really like building codes. Building codes are effectively minimum specifications for safety, with the requirement that they can be inspected and approved. The codes eventually became more uniform, but their original intent was to prevent shoddy workmanship from creating hazardous conditions. SOC II and ISO 27001 have to do with security, which is close to safety, but not the same. GDPR and HIPAA are con…

> their original intent was to prevent shoddy workmanship from creating hazardous conditions

And therein lies the difference...a building collapsing will kill its tenants. Software collapsing will make someone late for dinner.

When software is critical, there are safety standards: DO-178C, DO-330, ISO 13485, ISO 14971, etc.

Re: Programmers are bad at managing state (2020)

#50

Post by Ygg2 »

btschaegg wrote: post #44
hnb2137 wrote: post #6

Earlier quoted context omitted.

And only once delivery. And only once delivery.

This reads more and more like Monty Python's Spanish inquisition sketches. I love it :)

Nobody expects the Spanish Programming inquisition! Amongst our weaponry are: bad naming, undefined 46$$43$_22#3off data races. by one errors,

And only once delivery. And only once delivery. And cache invalidation. And cache inva

Damn it! I can't say it, you'll have to say it.

Post reply on HN