Why Developers Never Use State Machines (2011) • Hacker News Board

Re: Why Developers Never Use State Machines (2011)

#81

Post by danmaz74 » Tue, Feb 27, 2018, 9:55 AM UTC

jrimbault wrote: post #69

danmaz74 wrote: post #58

Using (explicit) state machines in Rails is so easy, thanks to the gem of the same name(1), that we use them very often, with good results. I think that ease of setting them up and integrating them in whatever framework/language you use is a very important factor in their adoption. 1 current version: https://github.com/pluginaweek/state_machine 1a original unmaintained version: https://github.com/pluginaweek/state_ma…

https://github.com/state-machines/state_machines

Thanks for the correction, I pasted the same link twice - can't edit :(

Re: Why Developers Never Use State Machines (2011)

#82

Post by nailer » Tue, Feb 27, 2018, 10:41 AM UTC

nailer wrote: post #2

Can't read the article as site is down but: fear of the unknown, along with some of the unnecessarily complex language around the topic. I got over both of these and now use state machines in production where they make sense as a model.

Not complaining about the down votes, but it is odd to see an honest self-critical opinion being downmodded.

Re: Why Developers Never Use State Machines (2011)

#83

Post by oblio » Tue, Feb 27, 2018, 10:44 AM UTC

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…

Heh, very often their problem domain is also an issue.

"We're going to write a compiler in our shiny FP language".

"We're going to implement a Fourier transform".

Nah, thanks, could you show me instead how I can get the Employee record from an XML file, stick it in a PostgreSQL database and also send it down the wire through a REST API as JSON?

Re: Why Developers Never Use State Machines (2011)

#84

Post by cimmanom » Tue, Feb 27, 2018, 10:49 AM UTC

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…

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.

Re: Why Developers Never Use State Machines (2011)

#85

Post by azeirah » Tue, Feb 27, 2018, 10:53 AM UTC

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…

I don't think 'three haskell tutorials' is ever enough to teach you a completely new programming language/paradigm. You wouldn't learn C in 'three C tutorials' either, would you?

Perhaps a Haskell book with a project or two would be a better alternative?

Re: Why Developers Never Use State Machines (2011)

#86

Post by cimmanom » Tue, Feb 27, 2018, 10:54 AM UTC

Isn't one component of this that so many people develop for web now? And that HTTP is inherently stateless.

That means we have to resort to hacks to store state (databases, cookies) - and like most hacks, those are fragile (such as assuming a single instance of state and then breaking when the user opens another copy of the site in a tab).

With the rise of single page apps, there's a more coherent concept of state on the front end, but that doesn't fix the fragility of the server side portions.

Re: Why Developers Never Use State Machines (2011)

#87

Post by jwilk » Tue, Feb 27, 2018, 10:56 AM UTC

nailer wrote: post #2

Can't read the article as site is down but: fear of the unknown, along with some of the unnecessarily complex language around the topic. I got over both of these and now use state machines in production where they make sense as a model.

Archived copy: https://archive.is/3v9Gm

Re: Why Developers Never Use State Machines (2011)

#88

Post by PeterisP » Tue, Feb 27, 2018, 10:59 AM UTC

oblio wrote: post #83

simonh wrote: post #78

Earlier quoted context omitted.

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

Heh, very often their problem domain is also an issue. "We're going to write a compiler in our shiny FP language". "We're going to implement a Fourier transform". Nah, thanks, could you show me instead how I can get the Employee record from an XML file, stick it in a PostgreSQL database and also send it down the wire through a REST API as JSON?

Haskell code for that looks quite nice as well - however, it's less about a language per se but rather about availability of libraries and how mature / well-built their API is.

For quite a few FP languages the ecosystem is there and you can do all these problem domains nicely, they just tend to be skipped in tutorials as they rely on non-core third party libraries (sometimes with multiple nice but very different alternatives). Perhaps a "batteries-included" stance of Ruby(+Rails) and Python would simplify that, but it's more of a political issue.

Re: Why Developers Never Use State Machines (2011)

#89

Post by PeterisP » Tue, Feb 27, 2018, 11:04 AM UTC

jjjensen90 wrote: post #55

vvanders wrote: post #15

Earlier quoted context omitted.

Plenty of imperative domain spaces use state machines, gamedev and the like come to mind in particular.

Definitely true for gamedev in my experience. I don't think I've worked in a game code base of nontrivial size without seeing some implementation of state machines.

The "some implementation" probably is part of the problem - if there was a good generic implementation included in the standard library so that it could and would be used in language tutorials (especially in languages where rolling nice state machine code is tricky), then developers would use them much more.

Re: Why Developers Never Use State Machines (2011)

#90

Post by oblio » Tue, Feb 27, 2018, 11:08 AM UTC

PeterisP wrote: post #88

oblio wrote: post #83

Earlier quoted context omitted.

Heh, very often their problem domain is also an issue. "We're going to write a compiler in our shiny FP language". "We're going to implement a Fourier transform". Nah, thanks, could you show me instead how I can get the Employee record from an XML file, stick it in a PostgreSQL database and also send it down the wire through a REST API as JSON?

Haskell code for that looks quite nice as well - however, it's less about a language per se but rather about availability of libraries and how mature / well-built their API is. For quite a few FP languages the ecosystem is there and you can do all these problem domains nicely, they just tend to be skipped in tutorials as they rely on non-core third party libraries (sometimes with multiple nice but very different alte…

> It's less about a language per se but rather about availability of libraries and how mature / well-built their API is.

In the real world, those matter just as much as the language. They usually matter even more :)

Look at what Rust is doing - I think at least half of their effort is spent towards building up a large collection of high quality, well maintained (i.e. feature requests implemented, bugs fixed quickly) and well documented libraries.