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

Why Developers Never Use State Machines (2011)

skorks.com

Post reply on HN
Print view View original

71–80 of 164 posts

Re: Why Developers Never Use State Machines (2011)

#71

Post by nottorp »

IamNotAtWork wrote: post #28

I really don't like state machines because if you need to add a new event, each of the states need to be updated to handle that event. If you add a new state, you have to figure out how to handle each of the transitions from other states. So as your states grow, the maintenance on the developer's side grows faster than linear. Additionally, I find that I cannot understand how the program works without actually drawin…

What's wrong with drawing the state machine diagram? And generally, what's wrong with drawing your code structure?

You may be able to keep it all in your head when you write it the first time... try again when you're doing maintenance after 6 months of not touching it though.

Re: Why Developers Never Use State Machines (2011)

#72

Post by coldtea »

noblethrasher wrote: post #52
seanmcdirmid wrote: post #24

Earlier quoted context omitted.

Yes, that should be obvious also. State machines have no strong relationship with FP. I'm not sure where this claim even comes from!

In 's4vi0r’s defense, “FP” usually means ML-style FP, which does happen to be pretty biased towards creating stack-based FSMs since it has literal syntax for stacks (list literals), states (discriminated unions + tuples), and transitions (pattern matching).

>“FP” usually means ML-style FP

Only after sometime around 2010. Before that it was mostly Lisp and Scheme. Sometime around then, the trend around Haskell, purity, and co overtook them as what people mean when they talk about FP.

Re: Why Developers Never Use State Machines (2011)

#73

Post by coldtea »

IamNotAtWork wrote: post #28

I really don't like state machines because if you need to add a new event, each of the states need to be updated to handle that event. If you add a new state, you have to figure out how to handle each of the transitions from other states. So as your states grow, the maintenance on the developer's side grows faster than linear. Additionally, I find that I cannot understand how the program works without actually drawin…

>I really don't like state machines because if you need to add a new event, each of the states need to be updated to handle that event. If you add a new state, you have to figure out how to handle each of the transitions from other states. So as your states grow, the maintenance on the developer's side grows faster than linear.

State machines have been designed to neatly capture and componentize exactly that.

Anything else is less explicit, and even more error prone.

That new even and those new transitions you've mentioned? You still need to handle them anyway -- only you do it in an informal manner without a SM.

Re: Why Developers Never Use State Machines (2011)

#76

Post by mikekchar »

aplorbust wrote: post #61

"Why Developers Should Be Force-Fed State Machines" https://shopifyengineering.myshopify.com/blogs/engineering/1... I always thought all computer science students had to take a compilers course, or some course on theory of computation that required some level of competency in lexing/scanning/tokenizing and parsing. This blog post appears to be directed at "web application developers" who lack "awareness about state m…

Quite a lot of software developers were never CS students. In fact in some industries engineers are very much desired as programmers. In others, math and physics majors are desirable. And even when we exhaust all of those, I don't think there is any need to look down our noses at those who took an apprenticeship style approach to the industry. In fact, in my career I have met many CS graduates who dismissed grammars and automata as irrelevant and insisted on writing that parser for a context sensitive language using regular expressions and about 400 global variables (and they still can't understand why it doesn't always work). Besides some of us "web application developers" actually have CS degrees and have worked in half a dozen other industries besides "web application development". Programming is programming and a programmer is a programmer. There's a lot to learn and you have to stay humble your whole career. Not everybody manages it easily.

Re: Why Developers Never Use State Machines (2011)

#78

Post by simonh »

s4vi0r wrote: post #12

Traditional programming languages and imperative thinking don't lend themselves to writing state machines, so its not really that surprising that they're under utilized. Its kind of frustrating constantly reading posts where people shit on functional programm(ers|ing) for being too ivory tower-y or whatever, when its kind of hard not to be when a lot of the older FP guys have spent the last like 20-30 years going "yo…

>the older FP guys have spent the last like 20-30 years going "yo this is dope you guys should really be doing this" and getting largely ignored

I've not been ignoring them. I tried at least three different Haskell tutorials and articles explaining how cool it is. The problem was the author would show some code sand say 'see how easy it is to do this, and this, and this!', but I'd look at the code and have no idea whatever what it was doing or how it was doing it, and the guide/tutorial wouldn't tell me. After a few tries, I just gave up.

Maybe there's a canonical newbie's tutorial that takes you through the shift from imperative/procedural thinking?

Re: Why Developers Never Use State Machines (2011)

#79

Post by arkh »

s4vi0r wrote: post #12

Traditional programming languages and imperative thinking don't lend themselves to writing state machines, so its not really that surprising that they're under utilized. Its kind of frustrating constantly reading posts where people shit on functional programm(ers|ing) for being too ivory tower-y or whatever, when its kind of hard not to be when a lot of the older FP guys have spent the last like 20-30 years going "yo…

As a whole, a database-backed CGI server can be considered a state machine.

Re: Why Developers Never Use State Machines (2011)

#80

Post by NicoJuicy »

sevensor wrote: post #19
s4vi0r wrote: post #12

Traditional programming languages and imperative thinking don't lend themselves to writing state machines, so its not really that surprising that they're under utilized. Its kind of frustrating constantly reading posts where people shit on functional programm(ers|ing) for being too ivory tower-y or whatever, when its kind of hard not to be when a lot of the older FP guys have spent the last like 20-30 years going "yo…

> State machines are super commonly used in languages where you can (easily) construct ADTs and pattern match on them. I had the opportunity to use F# for the first time last month, and I experienced this first hand -- it was far easier to write a procedure as a sum type with transition functions than it would have been to write it procedurally. And with all the advantages of having the states of the system and their…

Github?
Post reply on HN