

Hamster - Efficient, Immutable, Thread-Safe Collection classes for Ruby - justinweiss
https://github.com/harukizaemon/hamster/

======
exDM69
Is it just me or is anyone else annoyed about Ruby people calling their hash
table based dictionaries a "hash"? As a non-Ruby programmer, I always get
confused when people talk about hashes and you can never be quite sure if it's
a dictionary or an integer hash value.

~~~
keymone
from <http://en.wikipedia.org/wiki/Hash>

Hash may refer to: <http://en.wikipedia.org/wiki/Hash_table>

i'm sure it's not just you though, people get annoyed over whole bunch of
things

~~~
exDM69
I first started hearing the word used that way about at the same time as Ruby
started becoming more popular.

------
josteink
Not to be a pedant, but wouldn't thread-safe automatically follow immutable?

If a structure is immutable, how would you be able to fuck it up, even if you
abuse it via threading? I would argue the relation is so strong, that
something which _isn't_ thread-safe cannot be immutable. But there may
ofcourse be something which I'm missing.

Different languages and platforms handling different key concepts differently
etc.

Is there some properties of Ruby which makes this possible, or gives you a
need for a double-guarantee, or is the declaration here simply redundant?

~~~
asynchrony
Consider a balanced tree that only exposes an immutable interface but uses
destructive updates internally when rebalancing. In principle it would be
immutable, though it wouldn't necessarily be threadsafe without additional
work.

~~~
josteink
From my point of view, that would not be something I considered a immutable
data-structure.

But I guess at this point we are starting to argue technicalities and it's
getting quite outside the scope of this submission.

I'll just take a mental note with regard to immutable evidently being a lossy
concept ;)

------
kristianp
Hmm, I assumed this would have to be written in C so that it could use
multiple threads in parallel in MRI, but it seems not. Then I remembered
concurrent != parallel.

~~~
scotth
You forget that MRI isn't the only Ruby implementation. JRuby has no GIL.

------
sirclueless

        def dup
          self
        end
    

Weehee, immutability is great at some things.

------
alttab
How many people do multi threading in ruby? I'm assuming this is mostly for
jruby?

~~~
SeoxyS
I use threading in MRI ruby quite often… maybe I'm the odd man out here.

~~~
guns
Threading in MRI is still entirely appropriate for juggling IO. So that makes
two of us.

~~~
alttab
I guess I jumped to quickly to the conclusion that more work would be done in
Ruby. I suppose it works for IO. I like non-blocking libraries like em-http-
request and event machine for these things.

If I wanted to do concurrent programs, I usually chose C :)

------
mitchellh
As of git HEAD at the time of this comment (5edce74):

1499 lines of Ruby code.

19 lines of comments.

Nope, nope, nope. I would never touch this library.

Good amount of tests, but the moment this library doesn't work as expected and
you need to jump into the code, you're completely screwed.

Not usable.

~~~
mweibel
didn't look at the code but if it's good code, why would you need more
comments? Good code explains itself.

~~~
nirvdrum
Do you have an example of good code that explains rationale or "why" without
comments? I rarely come across code and can't figure out what it's doing, but
I routinely come across code and can't figure out why it's doing something.
And I haven't found a good way to deal with that outside of comments or some
external documentation. I'd love to see examples of code that's able to
overcome this.

~~~
mweibel
Well done code has good variables, good method/function naming and small
methods/functions. If you have those 3 parts, you won't need any comments
because it's self explanatory.

Comments often tend to explain the same thing as the code exactly does and
what you see w/o looking at the comment. Also, they tend to be forgotten - if
someone changes the code, he/she often doesn't change the comment. As a
result, you'll have an outdated comment which can confuse you.

I recommend "Clean Code"[1] for more info on this subject. Beside other
chapters, there's a chapter about what's a good and what's a bad comment.

[1]: [http://www.amazon.com/Clean-Code-Handbook-Software-
Craftsman...](http://www.amazon.com/Clean-Code-Handbook-Software-
Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1341586548&sr=8-1&keywords=clean+code)

~~~
nirvdrum
I've never come across self-documenting code that can explain "why," which is
what I was seeking. The closest thing I've ever come across was a PhD student
working on a system called Seurat, but even that was really metadata attached
to the code (something akin to an SCM). I agree clean code can help with the
"what" or the "how", but that's almost never the problem to begin with.

In any event, I was looking for solid examples, not a general discussion on
whether comments are good or bad. We clearly are not going to agree on that
point so we'll save the Internet another pointless argument :-)

~~~
mweibel
Ok I might have misunderstood you ;) Well I'm not saying comments are
generally bad. But I think a lot of comments can be replaced by better code :)
Solid examples I can't really show you atm (I'm not yet there where I'd say
from myself that I write the cleanest code ever) ;)

