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

141–150 of 164 posts

Re: Why Developers Never Use State Machines (2011)

#141

Post by AstralStorm »

acrive wrote: post #74

The state machine is very near at Design by contract pattern. There are states, preconditions and other stuff. The question now will be "Why developers never use design by contract pattern?" :) https://github.com/nhatminhle/cofoja for example

Design by contact is a lot more general. You can have preconditions and postconditions in stateless code. And statelessness is the best way to handle concurrency. When stateful and concurrent, you get to handle outdated requests intelligently and with as little blocking as possible.

Re: Why Developers Never Use State Machines (2011)

#142

Post by zaarn »

AstralStorm wrote: post #137
JoachimS wrote: post #65

Earlier quoted context omitted.

Agreed. When I worked on last years Advent of Code problems (amazingly good problems btw) I ended up writing many solutions as small FSMs. Typically you read a token, moved to a new position and then acted based on the current state and the token, position. You don't need a library since the code is just a few switch statements. https://adventofcode.com/2017

And then everything ends up in Error state with no history. At least function stack has stack traces...

FSM's usually don't have error states, you tend to crash them first.

Though that is preventable, mostly because the code you run is inbetween transitions and that will return very nice stack traces.

Otherwise, you don't need a trace of a state machine, the state you're in and the current transition should tell you exactly where it's breaking.

If it doesn't, chances are you're breaking state machine definitions by storing wildly complex state outside the machine.

Re: Why Developers Never Use State Machines (2011)

#143

Post by noir_lord »

mikekchar wrote: post #76
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…

Very nicely put.

I've worked with lots of programmers over the years and a CS degree has been a very poor indicator of their ability to program in the large.

Re: Why Developers Never Use State Machines (2011)

#144

Post by [deleted] »

simonh wrote: post #78
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 wh…

[deleted]

Re: Why Developers Never Use State Machines (2011)

#145

Post by lph »

Saying that developers "don't use" state machines just because code isn't littered with things like instantiations of machine and state classes is an interesting point, but kind of glib. I use state machines all the time as an abstraction to reason about programs.

Re: Why Developers Never Use State Machines (2011)

#146

Post by moocowtruck »

dllthomas wrote: post #129
moocowtruck wrote: post #119

Earlier quoted context omitted.

you forgot the "oh and requirements will change randomly as you're getting employee record from xml file to etc etc

In my experience, that's really not an argument against Haskell. I find it easier to make large changes in my representation of the world in Haskell than in any other language I've worked in.

As much as I love haskell and want to say I've had those same experiences, that hasn't been my experience. Haskell forces me to write better code so often that it's painful when bad code will do just as fine.

I'm always surprised how often bad code is the solution too.. And when I say the solution, I mean to all the points along the path that I may take to get to the final destination. And I'm not saying this because you can't write this type of code in haskell but because haskell makes it more difficult and that's not always a good thing

Re: Why Developers Never Use State Machines (2011)

#148

Post by oblio »

moocowtruck wrote: post #146
dllthomas wrote: post #129

Earlier quoted context omitted.

In my experience, that's really not an argument against Haskell. I find it easier to make large changes in my representation of the world in Haskell than in any other language I've worked in.

As much as I love haskell and want to say I've had those same experiences, that hasn't been my experience. Haskell forces me to write better code so often that it's painful when bad code will do just as fine. I'm always surprised how often bad code is the solution too.. And when I say the solution, I mean to all the points along the path that I may take to get to the final destination. And I'm not saying this because…

Well, despite what we tell ourselves, I think that most code we write is actually short lived. As in, it is only used for a short time. It might be in a zombie state for many years and even be revived, if it's an Open Source project, but that's not the common scenario.

As a result, if most of the code written by most programmers is short lived and during that short life changes drastically, super-strict languages actually slow you down a lot.

The real problem is: sometimes certain parts of our code live very long and intense lives. But we never know which parts and at which moments. If we knew, we'd just write those parts in Rust/Haskell and the rest in Javascript or Visual Basic and live merrily ever after.

To paraphrase P.T. Barnum: I know that 10% of my code needs to be extremely fast, easy to refactor and readable, I just don't know which 10% :D

Re: Why Developers Never Use State Machines (2011)

#149

Post by throwaway010317 »

seanmcdirmid wrote: post #24
tytytytytytytyt wrote: post #22

Earlier quoted context omitted.

> State machines are also intrinsically stateful, that should be obvious. So are lots of data types, but those are still useful in FP.

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

This comment reminds me of something I read recently on Yaron Minsky's twitter:

"An odd habit of functional programmers: when confronted with a nice, but clearly imperative way of structuring a program, they will often declare that this technique is in fact functional." (https://twitter.com/yminsky/status/950883335324225541)

and then

"Case in point: structuring a program as an imperative, deterministic state machine, where the state is determined fully by the state machine logic plus the sequence of transactions." (https://twitter.com/yminsky/status/950883598189686784)

Re: Why Developers Never Use State Machines (2011)

#150

Post by cimmanom »

Sean1708 wrote: post #131
cimmanom wrote: post #84

Earlier quoted context omitted.

The erlang tutorial is pretty effective at that, IMO. The biggest problem with it is that erlang syntax is so foreign to most programmers you're going to spend enough mental effort understanding that to detract from the brainpower available for understanding the functional paradigms.

Isn't that why Elixir came about, to be Erlang with a less esoteric interface?

Sure, but does Elixir have the exact same tutorial?
Post reply on HN