Gem adds support for creating state machines for attributes on any Ruby class

Then you explicitly pass the transitions as a hash, or provide other methods for those specific options, but part of my point was that adding so many options in the first place is part of the problem of that API. It's trying to do way too much at the same time, and the result is you're ending up with really excessive code.

My example code was a quick and dirty example; instead of state= you could use "event" or whatever name you prefer. You're having the discussion about API whether you have it explicitly or have it by having the discussion about pulling in those gems.

And the point was the verbosity of it, not the details. If you need "a solution" for a state machine, odds are your state machine is too big and convoluted and ought to be decomposed, because to me at least their examples obfuscates the state machine they're defining in a way that is a huge red flag.

I definitely would not trust "the community's" experience on this - it's by no means "the rest of the world" that has settled on this, but a tiny subset. Thankfully I've never had to deal with code using either of these gems "in the wild" in 19 years of Ruby development.

Having looked at the source of the state_machine gem, I'm now even less inclined to want it anywhere near my code. It's grossly over-engineered. A quick look at aasm makes it look slightly saner, but it's still grossly invasive and huge amounts of code.

There are thresholds in both directions, and I find the state_machines examples go way too far in the direction of verbosity to the point where it makes it harder rather than easier to see what is going on.

I'd argue the same for your P-lang example.

The state transitions in your example are trivial to the point where a "framework" is entirely unnecessary, but even then they are hidden inside the implementation details in a way that forced me to read the implementation to realise that they're trivial.

If I have a state machine that is complex enough that I want a "framework" to simplify things, my first requirement will be that it makes clear the state transitions and criteria separate from the implementation of them. Both the state_machines gem and the other Ruby gem mentioned in this thread have examples that in my opinion does a far better job at separating that.

Selection bias

To expand on this:

Contrary to constants which are fixed+ references to values, symbols are pure values: they're like integers but with a textual name. Explicitly they are not strings.

They used to be very useful because a symbol takes little memory and comparing two symbols means comparing two integers; it's a bit like `#define FOO 42` in C, except `42` is automatically picked up and you don't care what the value actually is.

They are less useful today because there have been a lot of improvements e.g with frozen string literals (which are now stored only once and thus can be compared much more efficiently). Still that has a lot to do as to why they're used for kwargs and hash keys and method names and a ton of other stuff, where without symbols you'd have a ton of the same strings showing up over and over, so instantiated and compared.

The hash syntax used to be only arrow but it was so common to do `:foo => "bar"` that at some point Ruby (1.9) introduced `foo: "bar"`, which makes writing hashes look like JSON/YAML and kwargs more like other languages like Python. This does make it a bit surprising because suddenly there's a symbol that is not prefixed with `:` but it also makes things a ton more readable in many cases.

I do use the "new hash syntax" liberally, but also still use arrow hashes a lot because it all depends on the way things are written around and sometimes one is more readable than the other.

For example in general I don't like writing rake task target dependencies or Rails routes with the new syntax, the arrow one makes more sense to me. Or when one can have mixed keys that can be symbols or some other types, I find it more readable to have a consistent hash syntax, so I go to the old arrow one.

+ well, although frowned upon, constants can be reassigned, they're essentially just some variables albeit with a different scope and resolution system.

So it's just a symbol, but in this context it will be used to look up the "state" method? Not unlike how symbols are sometimes used as "designators" of various things in Lisp?

It's more like an integer with a textual name.

Indeed I know all of this. But in terms of "what this code does," the information that a method is passed a block that calls another method is not particularly interesting. The major problem I have with this sort of DSL is it encourages people to infer what it does based on what the ad hoc method names make it sound like this is intended to do. So many of these custom DSLs are documented by example rather than by any decent specification. The attitude that these clever little grammars make it so you can "just read it and it's obvious" is, in my opinion, sloppiness in code comprehension taken to an extreme.