Arbitrary abbreviations in phobos considered ridiculous

[Jonathan M Davis]

On Thursday, March 08, 2012 06:55:17 Steven Schveighoffer wrote:
> On Wed, 07 Mar 2012 21:14:34 -0500, Ary Manzana <ary at esperanto.org.ar>
> 
> wrote:
> > The problem is not mistaking it with something else. The problem is when
> > you want to write it. In Ruby my mind works like this:
> > 
> > Mind: "How would I get a span for 5 seconds?"
> > Mind: "Let's try 5.seconds"
> > Mind: "Wow, it works!"
> > 
> > I'm trying to remember cases when I just wrote what my mind thought it
> > was correct and I was *so* surprised it worked out of the box in Ruby.
> > Like writing array.last, and get it to work, instead of
> > array[array.length - 1]. But in D, from the docs
> > (http://dlang.org/arrays.html )
> > 
> > bar[$-1] // retrieves last element of the array
> > 
> > I read: bar dollar minus one wait what??
> 
> array.back;
> 
> http://dlang.org/phobos/std_array.html#back
> 
> This is the issue with "intuition". It's easy to say, "hey I guessed
> right in Ruby! Ruby must be more intuitive!". But if you were someone
> who knew the range interfaces, wouldn't you try array.back in Ruby and say
> "well, obviously D is more intuitive, it knew what I wanted without even
> looking up the docs!"
> 
> You are never going to come up with something that's *perfectly* intuitive
> for everyone in every situation.

Yeah. I don't understand how anyone can expect to just write code and have it 
work without looking anything up. Best case, the IDE does code completion for 
you, and maybe you don't have to actually look at the docs, but without 
knowing what the functions do, that's not necessarily wise even if the 
functions are well-named, because they still might not do _exactly_ what you 
expect (and everyone's expectations vary).

The names need to be good enough that the code is reasonably understandable 
without necessarily having to look at the documentation (though there's a good 
chance that you're still going to have to look at the docs), and they should 
be good enough that most people have a good chance of finding what they're 
looking for when they look for a funcition or type in the docs. But there are 
so many variations on how things can be named, and so many people expect 
different things, that you're never going to win. At best, you please the 
majority. But names are _always_ bikeshedding issues.

A _lot_ of what goes into symbol naming is personal preference and a matter of 
what you've previously been exposed to rather than anything objective, and 
there will pretty much always be disagreements on it.

- Jonathan M davis