Comment by rubyn00bie | Hacker News Reader

Comment by rubyn00bie | Hacker News Reader

Some small but I think important nit-picky things about Struct

1.) A struct in ruby isn't just data, it is an object.

2.) Structs come with some weird gotchas, most notably that it is an Enumerable!

3.) It's generally better to use a hash (in ruby) if you want "pure" data object (and they at least used to be faster).

I myself have written a lot of "weird" Ruby and I will say that more often than not it's detrimental to an application that is used/developed by others. Often times ideas that seem brilliant in one language, cannot be translated into another (immutability), and it's best to use the recommended paradigms. Especially when those using the software are not familiar with them, and most likely won't become familiar with them....

For me, many functional paradigms are just lost on ruby because it's so highly mutable that practicing them is more academic than practical (sadly). That's why I write Scala or Elixir now when I want/need those paradigms-- because they're the right tools for that job.

I definitely don't want to discourage innovation, or bringing great ideas to ruby from other places-- I just want to emphasize caution :)

Hashes are faster than structs? Not in my experience. You can speed up code considerably by using a struct instead of a hash.

An OpenStruct is slower than a hash, but then again, an OpenStruct is kind of pointless.

The question in my mind then becomes "what job is ruby the right tool for?"

If the reason not to use better principles is because Ruby makes them painful, rather than there's something about the domain that makes them a bad idea, why choose Ruby to begin with? Presumably the ecosystem.

I agree with emphasizing caution, but I definitely think it's worth being at least somewhat weird with your Ruby to get as much as you can from the best of both worlds, the Ruby ecosystem and functional principles.

You can always freeze your hashes in Ruby for safety if you want to. All that's missing is some sugar for declaring immutable hash literals. I guess one way would be to allow clojure-style minimal punctuation map literals and make them immutable...

> ou can always freeze your hashes in Ruby for safety if you want to. All that's missing is some sugar for declaring immutable hash literals.

And immutable structures with efficient "updates". Because otherwise every time you're altering the structure you have to copy it in full (though shallowly) then mutate it in place.

Well you could use this:

https://github.com/hamstergem/hamster

To go along with that--methods that have immutable/pure functional semantics, meaning they return a modified copy of the structure, with no side-effects, rather than mutating a shared object.

You can't. Freezing a hash does not make it immutable. Try it.

It requires a good knowledge and dedication to consistently return a new object (not mutate state). Further, chaining is problematic for tracing errors because so much happens on a single line. Ruby has many subtle features that can bite you in the ass.

Don't get me wrong, I LOVE RUBY, I would love these paradigms to be better suited (rbx/jruby come close). I just find if I embrace mutability, state, and OO principles in Ruby I am rewarded in quality by having other smart people who are more easily able to critique my code and better it.

The abstraction I (completely willing to admit being wrong/stupid) don't believe is worth it. I think less effort and more reward can be had using the right tool for that job. I, for what it is worth, came to my conclusion through the pain of trying.

When I try to modify a frozen hash it raises an exception "Can't modify a frozen hash" in ruby 2.2.

I generally agree with the rest of your comment though, however I think some ruby code (per the original post) can be improved by introducing some of these paradigms.

Yes, but you only freeze the hash, not the items it contains. It is also an issue for thread safety, as I wrote here: https://bearmetal.eu/theden/how-do-i-know-whether-my-rails-a...

Is there something in Scala that prevents one man's "val" from becoming another man's "var"?

Not that I don't wish we could swap tired old Java for Scala at work, but I worry that opt-in immutability means somebody will opt-out and foul things up in Scala, as well :-(

For languages (e.g. - Scala, Nim) that have separate keywords for declaring/initializing immutable and mutable symbols, I wish they would avoid short words like "var" for mutable identifiers, maybe using a keyword like "mutable", "datadivision" or "ipeedinthepool" to discourage mutable data.

Reply on news.ycombinator.com