Jacob Carlborg wrote:
> 
> I never understood the reason for that the names need to be short. I think the most important thing is that the names are clear. Just look at the C standard library, it's horrible, almost every name is an abbreviation of some kind.

Clarity is very important, but if you have long names which are used frequently, it can quickly result in long lines of code which end up on multiple lines and can be hard to read. If a word isn't used very often, then it's not that big a deal, but the more often it's used - especially when it can be used multiple times on the same line - the worse it gets. Really, the ideal situation is to find words which are short and clear, but a balance must be struck between the two regardless. Too long and it's cumbersome. Too short and it's likely to be unclear.

There's no question that programmers often use words for variable names and such which are ludicrously short and unclear, but long words can be a problem too.

- Jonathan M Davis

== Quote from Jacob Carlborg (doob@me.com)'s article
> I never understood the reason for that the names need to be short. I think the most important thing is that the names are clear. Just look at the C standard library, it's horrible, almost every name is an abbreviation of some kind.

Names should be short to save typing and clutter.  Of course, clarity also matters.  I tend to prefer short names for frequently used language and library constructs that everyone who has been using the language for more than two weeks should know.  Longer names have their use in **your** programs and in less frequently used constructs, where the overhead of memorizing what a short, unclear name means is less than the overhead of typing a long name.

Andrei Alexandrescu, el 14 de febrero a las 11:18 me escribiste:
> Leandro Lucarella wrote:
> >Michel Fortin, el 14 de febrero a las 07:48 me escribiste:
> >>On 2010-02-14 05:12:41 -0500, Jacob Carlborg <doob@me.com> said:
> >>
> >>>It iterates backwards, all the way back to the 50s. I think "reverse" is a much better word.
> >>Agree.
> >>
> >>My dictionary says: "retro": imitative of a style, fashion, or design from the recent past.
> >>
> >>It's an amusing name in the way Andrei likes it, but the meaning isn't very clear. "reverse" would be a better name.
> >
> >This is a pattern in Andrei, which I think it really hurts the language (the names are very clever and funny, but that shouldn't be the point of a name, a name should be clear).
> 
> At least in this case being funny was not the point. I needed a name
> that was (a) short, (b) different from "reverse", (c) memorable. It
> is understood that other paint colors are available, but please
> don't forget to give a little love to the painter. :o) It would be

I'm not trying to hurt you :)

I just pointing out that you sometimes pick up clever or creative or niche names, which might look like a good idea to you but it's not for me. They are different points of view, I'm sure a lot of people would "look, D has these very clever names, it sure is a good language", but I think, from a practical point of view, that it's a bad idea because they are less natural and harder to learn, remember and *read*.

> of course best if names that arguably hurt the language were changed, so please compile a list.

Well, they were discussed several times, sometimes with huge threads (like
the range methods names). iota() is another really hard to
remember/understand name for me (I said that before). I just didn't know
what iota() was before you used it in phobos. I even couldn't follow some
examples before I searched what iota was (which it took me some time
because I was a little embarrassed that I didn't knew its meaning =).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------

Andrei Alexandrescu, el 14 de febrero a las 12:08 me escribiste:
> bearophile wrote:
> >Mike James:
> >>1.   Contrawise
> >>2.   Rearward
> >>3.   AssBackwards
> >>4.   Reorientated
> >>5.   Turnedabout
> >>6.   Turnedaround
> >>7.   Inversified
> >>8.   Flipped
> >>9.   Refluxed
> >>10. VolteFace
> >>
> >>or how about Reverse...
> >
> >Wonderful, I elect you the official namer for Phobos :-)
> >And I think Andrei meant a list of all the bad names in Phobos :-)
> >What about "reversed"? :-)
> 
> I don't mind "reversed" but it's longer than "retro" and the convention doesn't scale. For example, both active and passive forms of "split" look the same.

Well, english sucks, you can't fix that ;)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------

Andrei Alexandrescu, el 14 de febrero a las 20:24 me escribiste:
> retard wrote:
> >Sun, 14 Feb 2010 11:18:02 -0600, Andrei Alexandrescu wrote:
> >
> >>Leandro Lucarella wrote:
> >>>Michel Fortin, el 14 de febrero a las 07:48 me escribiste:
> >>>>On 2010-02-14 05:12:41 -0500, Jacob Carlborg <doob@me.com> said:
> >>>>
> >>>>>It iterates backwards, all the way back to the 50s. I think "reverse" is a much better word.
> >>>>Agree.
> >>>>
> >>>>My dictionary says: "retro": imitative of a style, fashion, or design from the recent past.
> >>>>
> >>>>It's an amusing name in the way Andrei likes it, but the meaning isn't very clear. "reverse" would be a better name.
> >>>This is a pattern in Andrei, which I think it really hurts the language (the names are very clever and funny, but that shouldn't be the point of a name, a name should be clear).
> >>At least in this case being funny was not the point. I needed a name that was (a) short, (b) different from "reverse", (c) memorable. It is understood that other paint colors are available, but please don't forget to give a little love to the painter. :o) It would be of course best if names that arguably hurt the language were changed, so please compile a list.
> >
> >It sounds like a flaw in the language design if the symbols for reversing arrays and ranges somehow conflict.
> 
> There are two operations: reverse the thing in place, and span it in retrograde order.

I think reverse (in-place) and reversed (returns a range that iterates in
reverse order) are *very* clear in terms of that distinction.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------

dsimcha:
> I tend to prefer short names for frequently used language and library
> constructs that everyone who has been using the language for more than two weeks
> should know.  Longer names have their use in **your** programs and in less
> frequently used constructs, where the overhead of memorizing what a short, unclear
> name means is less than the overhead of typing a long name.

http://en.wikipedia.org/wiki/Zipf_law

Bye,
bearophile

On 2010-02-15 09:04:11 -0500, Leandro Lucarella <llucax@gmail.com> said:

> Andrei Alexandrescu, el 14 de febrero a las 20:24 me escribiste:
>> There are two operations: reverse the thing in place, and span it in
>> retrograde order.
> 
> I think reverse (in-place) and reversed (returns a range that iterates in
> reverse order) are *very* clear in terms of that distinction.

But now how do you distinguish between a function returning the reversed form of something and a function returning true when that thing is reversed?

:-)

In Ruby syntax things are generally pretty easy:

	something.reverse!  # reverse in place ('dangerous!' method)
	something.reverse   # reverse a copy
	something.reversed? # return whether something is reversed or not

Cocoa would use a slightly different notation:

	[something reverse];           // reverse in place
	[something reversedSomething]; // reverse a copy
	[something isReversed];        // return whether something is reversed or not

Both conventions are very clear and scale well even for words like 'split' which are identical in their past and present tense.

It's unclear to me how we want this to be done in D...

	something.reverse();  // reverse in place
	something.reversed;   // reverse a copy
	something.reversed(); //   ditto
	something.reverse();  //   ditto
	something.reversed;   // return whether something is reversed or not
	something.isReversed; //   ditto

If we want some consistency, someone with authority over Phobos will have to draw some guidelines about this, and sooner the better.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On 2010-02-15 08:59:43 -0500, Jonathan M Davis <jmdavisProg@gmail.com> said:

> Clarity is very important, but if you have long names which are used
> frequently, it can quickly result in long lines of code which end up on
> multiple lines and can be hard to read. If a word isn't used very often,
> then it's not that big a deal, but the more often it's used - especially
> when it can be used multiple times on the same line - the worse it gets.

Well, the problem is that whether you're using something often or not depends on the context. If in a context your function name is used once or two, but in another it's used a lot, which prevails: shortness or clarity?

I'd tend to put clarity over short names in D because the language makes it very easy to create shorter aliases limited in scope when the need arise. But you shouldn't repeat the argument types nor the module's name: the language takes care of that for you.


> Really, the ideal situation is to find words which are short and clear, but
> a balance must be struck between the two regardless. Too long and it's
> cumbersome. Too short and it's likely to be unclear.

> There's no question that programmers often use words for variable names and
> such which are ludicrously short and unclear, but long words can be a
> problem too.

I think it's a question of locality. The broader is the scope of a name the more self-explaining the name should be. As an extreme example, I don't mind much seeing a local variable named 'x' in a short function, but I wouldn't accept that as a member variable in a class, and even less for a global variable.

It's easy for someone to create short names when he is all absorbed in what he's doing. But I think it generally takes some detachment to get the names right for a public API. Ideally, API names should be understandable as soon as you understand the underlying concepts. But even more important is that __functions should never be understood wrong__, the name should be clear enough to ensure that.

I don't think std.range fare very well at this readability test. Take this example:

	int[] array = [1,2,3,4,5,6,7,8,9];
	auto five = take(5, array);
	writeln(array); // what are you expecting here?

In the case above, 'take' returns a range that lazily takes N elements when you iterate over it. If you don't use the returned range, 'take' is as good as a no-op. But this subtle interaction isn't very clear when you just read the code.

Last week I defined my own function named 'take' for some kind of parser, advancing the range by the number of specified elements and returning an array of all the 'taken' elements. Then I realized it had the same name as the one above but with this subtle difference in semantics, subtle but very important for what I was doing. I renamed my function since then to make things less confusing, but I'm still a little shaken by this whole incident.

I think the lazy nature of 'take' should be visible when calling the function. This could be achieved by a name change, or perhaps in another way.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

>>>
>>> This is a pattern in Andrei, which I think it really hurts the language
>>> (the names are very clever and funny, but that shouldn't be the point of
>>> a name, a name should be clear).
>>
>> At least in this case being funny was not the point. I needed a name
>> that was (a) short, (b) different from "reverse", (c) memorable. It is
>> understood that other paint colors are available, but please don't
>> forget to give a little love to the painter. :o) It would be of course
>> best if names that arguably hurt the language were changed, so please
>> compile a list.
>>
>> Andrei
> 
> I never understood the reason for that the names need to be short. I think the most important thing is that the names are clear. Just look at the C standard library, it's horrible, almost every name is an abbreviation of some kind.

Are you trying to start a flame war?
What's wrong with LISP's car and cdr?

Isn't it obvious to all and sundry that car is the head element
of a singly linked list and cdr is the rest of the list with the
head element removed?

Justin Johansson :-) :-) :-)

On Sun, 14 Feb 2010 00:53:31 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Gone, that is. Walter agreed to remove it.
>
> To achieve the functionality of
>
> foreach_reverse (r) { ... }
>
> use
>
> foreach (retro(r)) { ... }
>
> using retro in std.range.

Will retro work on AA's?

Other than that (and how to do foreach(1..100) that others have brought up) I think this is a great move.

BTW, for those bemoaning the loss of opApplyReverse, it is easy to change this:

struct S(T)
{
   int opApplyReverse(int delegate(ref T t) dg) {...}
}

S!int s;
foreach_reverse(i; s) {...}

into this:

struct S(T)
{
   int inReverse(int delegate(ref T t) dg) {...}
}

S!int s;
foreach(i; &s.inReverse){...}

Of course, I'd prefer it without the &, but that is a separate issue (see bug http://d.puremagic.com/issues/show_bug.cgi?id=2498)

Also, while your attention is focused on foreach, look at this bug: http://d.puremagic.com/issues/show_bug.cgi?id=2443

:)

-Steve