From: Yorick Peterse <yorickpeterse@...>
Date: 2013-02-08T00:51:56+09:00
Subject: [ruby-core:51992] Re: [ruby-trunk - Feature #7797] Hash should be renamed to StrictHash and a new Hash should be created to behave like AS HashWithIndifferentAccess

> The only real reason I remember people mentioning is the performance
> thing and how they are different internally. It shouldn't really
> matter to the language design its implementation details (if they are
> different internally or not, for instance).

There are so many cases where the implementation of X does affect its
presentation. The way your database tables are layed out will ultimately
affect your views. Is this bad too? No, it's a fundamental part of how
things work.

While in many cases you can work around that and come up with a language
design that isn't too heavily influenced by its implementation it would
in this case fundamentally change the way MRI works. On top of that it
would mean that all the other Ruby implementations such as JRuby and
Rubinius had to be modified as well to be compatible with the Ruby
specification.

I think the latter is something a lot of people don't think about. A
change this big doesn't just affect the people using MRI, it affects
every developer and every implementation out there. It will also affect
existing resources such as books and tutorials as basically everything
has to be re-written from scratch. The amount of effort required for
this is way too much for it to make a change that can be solved in many
different (and much easier) ways.

> And for the performance argument I really believe symbols cause more
> harm than good to the overall performance given all conversions that
> it will require in most code bases (even if you don't do that directly
> it is likely that you rely on some gem that will do that).

I'd be interested in seeing the actual numbers for this. I also find it
interesting to see that your general opinion seems to be "the
performance overhead of this change is not important" yet you do seem to
care about the overhead of converting Symbols to Strings. I find this a
rather contradicting opinion but maybe I'm misunderstanding things.

> Have no idea! My suspect is that someone thought: "hey maybe it would
> be a great idea if we could optimize some constant strings - we could
> create a symbol for that - hey, look at my micro-benchmarks, it really
> is a great idea!".

Yes, Matz took some crystal meth one evening and decided to introduce
Symbols because he thought it was a fun idea to (apparently) piss people
off with it.

If you honestly believe choices like these were made randomly or because
of some hypothetical micro benchmark I suggest you actually spend some
time getting to know the MRI code base. As with many things getting to
know the inner workings of something will help you understand why
choices were made, in this case I think it can greatly help you clear up
your mind about making such a big change as well as understanding as to
why it's not going to happen any time soon.

> On micro-benchmarks I agree they may do some small difference. On real
> world-case apps though I'd suspect its presence is actually causing
> code to perform worse.

Based on what? The conversion of a Symbol to a String is no more
in-efficient than creating a String yourself. Again show a benchmark if
you're so convinced this is not the case.

> Why do you think that removing symbols would change Ruby in a
> fundamental way? I believe 99.9% of all Ruby code would still work
> without any changes if :symbol was the same as 'symbol'.freeze.

See my comment above about all the implementations and resources having
to be changed. It would also require substantial changes of the MRI
source code. This would be a non trivial change.

> This is your opinion. I don't agree.

Again take a look at the MRI code base before you disagree on this
matter.

On another note, you also seem to be unaware that it's not trivial to
suddenly replace the usage of Hash with LazyDeveloperHash. Yes, in the
Ruby source code it might be easier but at least in the C code it's
going to take time and effort for something that has little value.

In your other threads I gave you various examples on how you can work
around your issue and even do so in such a way that will save you a lot
of future work. However, it seems you're hell bent on ignoring that and
continue to argue about why you disagree with something you (at least
from my point of view) don't have a good understanding of.

This is also going to be my last Email for these 3 (or 4 now?)
discussions. I've given plenty of examples and explanations (and so have
others) and I have no interest anymore in trying to explain it.

Yorick