On Thursday, March 08, 2012 06:55:17 Steven Schveighoffer wrote: > On Wed, 07 Mar 2012 21:14:34 -0500, Ary Manzana <a...@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