Live data from Hacker News

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

github.com

11–20 of 50 posts

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

#11
post #2

I think Ruby is OK enough, but what is this? state_machine :state, initial: :parked do I think in their zeal to "golf" the language, they forgot to actually keep it readable

This is pretty standard Ruby stuff. It’s different for sure. But works really nicely in practice.

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

#12

Earlier quoted context omitted.

I've been writing Ruby for about 16 years, and I find that eminently readable. You're apply state_machine to the attribute state , and giving it an initial value of :parked . Then there's a block that ostensibly encapsulates state transitions following (hence the do ). Ruby can be written extremely tersely, and that can be difficult for non-Rubyists to read. This might help: state_machine(:state, {:initial => :parked…

Positionally-significant colons is more nightmarish than significant whitespace. Speaking as a critic of significant whitespace. Put them at the front and make them mean something, or put them at the back and make them mean something, Making both places mean something entirely different, or even allowing both as an allowable syntax, is horrible for readability.

Ruby uses symbols (strings prefixed with a semicolon) very liberally. It’s just a value literal. Ive never met anyone who writes Ruby that has an issue with the readability of it.

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

#13
post #12

Earlier quoted context omitted.

Positionally-significant colons is more nightmarish than significant whitespace. Speaking as a critic of significant whitespace. Put them at the front and make them mean something, or put them at the back and make them mean something, Making both places mean something entirely different, or even allowing both as an allowable syntax, is horrible for readability.

Ruby uses symbols (strings prefixed with a semicolon) very liberally. It’s just a value literal. Ive never met anyone who writes Ruby that has an issue with the readability of it.

Selection bias

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

#14
post #2

I think Ruby is OK enough, but what is this? state_machine :state, initial: :parked do I think in their zeal to "golf" the language, they forgot to actually keep it readable

I've been writing Ruby for about 16 years, and I find that eminently readable. You're apply state_machine to the attribute state , and giving it an initial value of :parked . Then there's a block that ostensibly encapsulates state transitions following (hence the do ). Ruby can be written extremely tersely, and that can be difficult for non-Rubyists to read. This might help: state_machine(:state, {:initial => :parked…

I find it way easier to read this modified version — and I use ruby at work. It’s not even close.

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

#15
post #2

I think Ruby is OK enough, but what is this? state_machine :state, initial: :parked do I think in their zeal to "golf" the language, they forgot to actually keep it readable

I've been writing Ruby for about 16 years, and I find that eminently readable. You're apply state_machine to the attribute state , and giving it an initial value of :parked . Then there's a block that ostensibly encapsulates state transitions following (hence the do ). Ruby can be written extremely tersely, and that can be difficult for non-Rubyists to read. This might help: state_machine(:state, {:initial => :parked…

First of all these are not new gems. In the past I used both and I strongly prefer this one to aasm. I like the DSL of it. It seems more convenient to me.

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

#16
post #6

Earlier quoted context omitted.

I've been writing Ruby for about 16 years, and I find that eminently readable. You're apply state_machine to the attribute state , and giving it an initial value of :parked . Then there's a block that ostensibly encapsulates state transitions following (hence the do ). Ruby can be written extremely tersely, and that can be difficult for non-Rubyists to read. This might help: state_machine(:state, {:initial => :parked…

Wait, is :state a keyword or an instance attribute? Using the same syntax for both seems really confusing.

It's a symbol. Basically a glorified string literal.

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

#17
post #2

I think Ruby is OK enough, but what is this? state_machine :state, initial: :parked do I think in their zeal to "golf" the language, they forgot to actually keep it readable

It’s a function call, with a positional arg and a keyword arg?

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

#18
post #12

Earlier quoted context omitted.

Ruby uses symbols (strings prefixed with a semicolon) very liberally. It’s just a value literal. Ive never met anyone who writes Ruby that has an issue with the readability of it.

Selection bias

I’m a Perl guy, and I find Ruby bizarrely verbose. I don’t understand how people can enjoy their symbols with all those word things.

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

#20
I've worked extensively on a project that has used this gem. Its reliance on metaprogramming can be cumbersome and difficult to debug.

It's kind of funny to me that this is somehow making the front page of HN given that it is a pretty old gem and has many shortcomings, e.g. only getting Ruby 3.x support in the last year.

Post reply on HN