Why Developers Never Use State Machines (2011)

Post by dragonwriter » Tue, Feb 27, 2018, 2:30 PM UTC

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…

Post by dllthomas » Tue, Feb 27, 2018, 2:36 PM UTC

naasking wrote: post #112

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…

> 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. You're better off learning OCaml or F# for a small project or two, honestly. The jump from pure procedural to pure functional is big enoug…

Post by Jtsummers » Tue, Feb 27, 2018, 2:39 PM UTC

cbetti wrote: post #117

One thing formal state machines make difficult is component reuse. Let's say you have a music playback control component you wish to reuse across a feature rich player, as well as a mini playback controller. You COULD just use the full state machine to power the mini player, but most of the transitions would be unused. It would be unclear to the next maintainer which aspects were needed for each use case, thus making…

  function transitionsTo (stateName, fn) {
    return function (...args) {
      const returnValue = fn.apply(this, args);
      this[STATE] = this[STATES][stateName];
      return returnValue;
    };
  }

Post by bsenftner » Tue, Feb 27, 2018, 2:43 PM UTC

notacoward wrote: post #115

The biggest source of resistance that I've run into is not with the concept of state machines but with common implementations. Two examples: * A quarter-century ago I implemented a cluster membership protocol and coordination system as a state machine. This provided great benefits in terms of verifiability, extensibility, etc. but some developers complained while the current state was explicit the history of how we g…

Post by dllthomas » Tue, Feb 27, 2018, 2:44 PM UTC

moocowtruck wrote: post #119

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?

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