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

91–100 of 164 posts

Re: Why Developers Never Use State Machines (2011)

#91

Post by weavie »

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 find OCaml is a much more accessible language for getting your head around functional paradigms.

Re: Why Developers Never Use State Machines (2011)

#92

Post by bmarkovic »

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 still and by far most commonly used in C, where, lo and behold, most low-level and embedded programming is still done.

And function pointers make up for pretty much the only fundamentally useful aspect of FPs regarding FSMs which is functions as first-class objects.

Everything else pretty much just substitutes one convenience for another. A pretty good case can be made about how the State Pattern makes traditional OOP indispensable in FSM design, and I'm sure that in OO languages with functions as first class objects (like Python, Lua or Javascript) people can showcase elegant designs that to them far surpass both classically OO or classically FP designs etc. etc.

Re: Why Developers Never Use State Machines (2011)

#94

Post by tanilama »

State machine is useful when it is useful. I can see for certain string matching problem, internal management of certain data structure, it is going to be a handy improvement.

However, specifically in web development, it is discouraged because the nature of the application itself. Think hard how states are managed in a typical service, the real states live in a DB. Which makes state machine less useful because the ground truth is stored elsewhere, and should be updated by DB's own primitives. And in a distributed settings, failure is something you have to put into consideration. Making your service stateful is a red herring that brings all kinds of operational troubles. That is why the dominant approach people seems to agree upon is to keep application stateless while delegate all dirty work to DB.

So realistically I think state machine is useful to write certain helper routines in a non-persistent, single-thread scenario, for the ease of reasoning, but really should be limited within the lifecycle of a single API call.

Re: Why Developers Never Use State Machines (2011)

#95

Post by xyhopguy »

gopalv wrote: post #57
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…

> Traditional programming languages and imperative thinking don't lend themselves to writing state machines That's probably not the problem - imperative development can start off from a level of complexity where state machines don't look relevant. Six weeks down the line, the whole codebase has overtaken the complexity of a state machine, though each of the development bugs were simple fixes to the original branching…

> (particularly the "go back" one).

Holy shit, once I built a web app for some biologists that wanted a "designer wizard." First I implemented a really shitty buggy wizard. Then I refactored it all into a state machine...........

Re: Why Developers Never Use State Machines (2011)

#96

Post by perlgeek »

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…

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

That might be the case, but you simply never see tutorials for writing a CRUD-like web application in Haskell. Maybe they exist, but they don't seem to show up very often here or on reddit or whatever.

Re: Why Developers Never Use State Machines (2011)

#97

Post by mtobi »

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…

Currently just started myself on http://haskellbook.com/, their philosophy seems to be just something for you, teaching functional programming with haskell from well defined fundamentals to make sure everything clicks. If they deliver on the promise I am yet to find out!

Re: Why Developers Never Use State Machines (2011)

#98

Post by lmm »

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…

What's worked for me is using Scala on real production projects and just taking it slow. First year or two I was writing Scala that looked like Java, last year or two I've been writing Scala that looks like Haskell, but because the language supports both styles I was able to learn one piece at a time and stay productive the whole time.

Re: Why Developers Never Use State Machines (2011)

#99

Post by vbezhenar »

oblio wrote: post #90
PeterisP wrote: post #88

Earlier quoted context omitted.

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

I agree. For me what matters most is language implementation (compiler/VM quality, GC quality, etc) and important libraries (and whether they are good). Language itself is not very important. I can write boilerplate, but I can't write GC implementation. So while I don't like Go language, for example, its implementation is very good and I can live with it.

Re: Why Developers Never Use State Machines (2011)

#100

Post by JasonFruit »

azeirah wrote: post #85
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…

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?

No, but if well done, it could be enough for me to say, "I get why this is worth pursuing further." I've had the same experience as the person above: Haskell tutorials seem to say, "Look what I can do!" and not, "See how you can do this?"
Post reply on HN