Hacker News Reader

Comment by knodi123 | Hacker News Reader

Counterpoint: State machines in Ruby should be used sparingly, and only when necessary, because they start out quick and easy, but almost always grow into things that are big, ugly, and difficult to refactor or remove.

Here are somebody's notes from a Railsconf talk that made this point, plus a link to the video:

https://gist.github.com/benoittgt/05521e272e13c7b7c9c89eb4a9...

But the short version is the takeaway quote:

> State machines are magnetic : they attract more states, transitions, events, callbacks and they accumulate callback logic where our bugs hide

View on HN

Of all the things I've seen in my time writing software I can qualify that some of the most fucked up things involved state machines. The worst of which was a 200 state hand written one in C for an embedded measurement system. There was no documentation, no comments and the states were numbered rather than named. The guy who wrote it originally was "anti RTOS" and had died after riding his motorbike recklessly leaving this shit for everyone to deal with.

It took me two weeks to do a trivial change because I had to reverse engineer a ton of it. And the only debugger I had was a couple of LEDs on the board I could wiggle on and off.

Send this by mail to thedailywtf, would love to read the expanded version

Sounds like a confused author or potentially an implementation-driven architectural decision (eg. regulatory or policy requirement, direct map from exposed states of a prior implementation that had been black box reverse engineered, etc.). AFAIK the normal way to implement state machines in embedded since ages yore is to use interlocking networks of state machines per isolate subsystem. At least, that's what I do and that's what seems natural in C and assembly where concerns such as manual memory management, code re-use and programmer cognitive load would all tend toward such an architecture. What was the hardware?

Was Coldfire + IAR. The design was driven entirely by idiocy and showboating. I was hired just to limp it along a bit further while they spun a new board and software as the MCU was obsolete anyway.

I call this crap enterprise grade spaghetti code. It's "structured programming" with dynamic dispatch of gotos.

> The guy who wrote it originally was "anti RTOS" and had died after riding his motorbike recklessly

That's literally the example in the literal textbook of why you shouldn't write code like this!

Thanks for sharing this. For other people who are hovering over this and unsure if they want to watch a 40 minute video, it's time stamped and the two parts I found super valuable were the 'Anti-Pattern: Custom Methods' and the 'Anti-Pattern: State Machines' sections. The TL;DR there is it's alright to create a controller that manipulates a single field on a single model. If it is enough of a resource to expose it by a custom url (think update password) it is enough of a resource to get its own controller.

And going beyond that, to the state machine, if each state (or really, value of a particular field) is important enough to have it's own contextual validation, transition points, etc, then it's important enough to expose each state as a resource with it's own controller.

Super cool stuff and I've got some thinking to do about some side projects now.

Indeed, a coworker at a previous job was fascinated/fixated with state machine patterns. After spending two weeks trying to force a process we were paired on into a state machine pattern and failing, I rewrote it in an afternoon without the state machine stuff.

It started out small and easy, when there were two states. A third state was manageable but to me already looked like it was going the wrong direction. The fourth state (out of IIRC 6) was never finished.

Reply on news.ycombinator.com