On Saturday, 20 June 2015 at 09:27:16 UTC, Vladimir Panteleev wrote:
>
> Two examples of controversial name pairs: setExt/setExtension, and toLower/toLowerCase. These functions have the same functionality, but one of them is eager, and the other is lazy. Can you guess which is which

If I had to hazard a guess, I'd go with "the shorter one is lazy", but that presumes I'd notice there were two nearly-identical functions in the first place and pick up on the not-well-conveyed implication that one is lazy and the other is not.  That's a Bad Thing.

And it's a bad thing everyone seems to be tip-toeing around, too.  None of the suggestions I've seen so far really call out to me "hey, this is lazy and has a non-lazy counterpart".  Would it be so wrong to add "lazy" to the beginning or end so it's super obvious at a glance with zero cognitive overhead?

-Wyatt

On Monday, 22 June 2015 at 11:45:31 UTC, Wyatt wrote:
> On Saturday, 20 June 2015 at 09:27:16 UTC, Vladimir Panteleev wrote:
>>
>> Two examples of controversial name pairs: setExt/setExtension, and toLower/toLowerCase. These functions have the same functionality, but one of them is eager, and the other is lazy. Can you guess which is which
>
> If I had to hazard a guess, I'd go with "the shorter one is lazy", but that presumes I'd notice there were two nearly-identical functions in the first place and pick up on the not-well-conveyed implication that one is lazy and the other is not.

Well, you'd be wrong. Although setExt is the lazy version of setExtension, toLowerCase is the lazy version toLower. Who needs consistency, eh?

> And it's a bad thing everyone seems to be tip-toeing around, too.
>  None of the suggestions I've seen so far really call out to me "hey, this is lazy and has a non-lazy counterpart".  Would it be so wrong to add "lazy" to the beginning or end so it's super obvious at a glance with zero cognitive overhead?

Just to reiterate, I want to stress that finding a perfect name is of secondary concern to deciding to change the name in the first place. A big part of the argument against renaming things is "look how much debate there is about what it should be called, it's obvious there is no consensus, let's just leave things as they are".

On Monday, 22 June 2015 at 07:17:56 UTC, Mike wrote:
> It makes me disappointed to see contributions that dot the 'i's and cross the 't's get turned away and belittled.  But, I don't think there's anything I can do about it, and although you've made an excellent argument, I've gathered enough wisdom in my time here to make a reasonable prediction of the outcome.  I also believe the relatively little response you've received in this thread is likely not an indication that few care, or that few support your argument, but rather that they've seen it before, and they know how it ends.

I agree with this, and given all the complaints by the leadership about lack of contribution, it's shocking to see the same individuals constantly putting down the work of others as not being of sufficient importance.

On Monday, 22 June 2015 at 11:51:27 UTC, Vladimir Panteleev wrote:
> Just to reiterate, I want to stress that finding a perfect name is of secondary concern to deciding to change the name in the first place. A big part of the argument against renaming things is "look how much debate there is about what it should be called, it's obvious there is no consensus, let's just leave things as they are".

I think that it's abundantly clear that the names are not well chosen. It's a guarantee that you're going to have to look at the docs to have any clue as to which is lazy and which isn't. I completely agree with adding lazy versions of the functions like Walter is doing, and our naming situation sucks on some level given that we have never named things based on whether they were lazy or not, and so there really is no way that all of the names in Phobos are going to be consistent in that manner (not without breaking more code than we're willing to break anyway), but the new names do seem particularly bad. A function that starts with set doesn't even sound like it's lazy anyway - not to mention, wasn't setExt the old function that std.path had before it was revamped?

Naming stuff is hard, but there is definitely a cost to poor names, which is something that Walter rarely seems to acknowledge, especially if it means changing an existing name - but since this is about functions that haven't even been released yet, I wouldn't think that it would be as big a deal to change them.

- Jonathan M Davis

On Monday, 22 June 2015 at 14:09:11 UTC, Jonathan M Davis wrote:
> Naming stuff is hard, but there is definitely a cost to poor names, which is something that Walter rarely seems to acknowledge, especially if it means changing an existing name - but since this is about functions that haven't even been released yet, I wouldn't think that it would be as big a deal to change them.

It seems everyone in this thread is in agreement, so what would be the next step? It is a time-sensitive matter as preparations for 2.068's release are already underway. After two pings I failed to engage Walter Bright in this conversation; I don't think I should just reopen my pull request a second time, and I fear that if I merge someone else's pull request, I just might get my commit privileges revoked :)

I agree with Vladimir --

There should be a naming convention for identifying whether a function is eager or lazy. Learning a naming convention once and applying it repeatedly is a better process than repeatedly referencing documentation.

A programming language should have built-in functionality that is named in such a way that it clearly expresses its intent. For newbies, it can be very off-putting to be introduced to a language where this is not the case. Perhaps some veterans of the D language can't clearly see this.

There is no good reason that the new introduction of built-ins should not follow a well-defined naming scheme. I'd actually go a bit further and deprecate old functions that do not meet the scheme and phase them out over time.

Bikeshedding is arguing over trivial naming schemes. Choosing to adhere to a naming scheme is not bikeshedding, IMHO.

Thanks,

On Monday, 22 June 2015 at 16:06:33 UTC, Kelet wrote:
> I agree with Vladimir --
>
> There should be a naming convention for identifying whether a function is eager or lazy. Learning a naming convention once and applying it repeatedly is a better process than repeatedly referencing documentation.
>
> A programming language should have built-in functionality that is named in such a way that it clearly expresses its intent. For newbies, it can be very off-putting to be introduced to a language where this is not the case. Perhaps some veterans of the D language can't clearly see this.
>
> There is no good reason that the new introduction of built-ins should not follow a well-defined naming scheme. I'd actually go a bit further and deprecate old functions that do not meet the scheme and phase them out over time.
>
> Bikeshedding is arguing over trivial naming schemes. Choosing to adhere to a naming scheme is not bikeshedding, IMHO.
>
> Thanks,

Well put. I don't like how often I have to refer to the documentation. And I have been trying to use D for a while. A naming convention expressing intent should reduce the need for frequenting the documentation. This would be a welcome addition. Even at the cost of dusruptive change.

Joseph

On Monday, 22 June 2015 at 11:45:31 UTC, Wyatt wrote:
>  None of the suggestions I've seen so far really call out to me "hey, this is lazy and has a non-lazy counterpart".  Would it be so wrong to add "lazy" to the beginning or end so it's super obvious at a glance with zero cognitive overhead?
>
> -Wyatt

This would be my preferred option. When C# introduced asynchronous counterparts of existing methods, they appended "Async" to the names, which seems to have worked out well - eg, Wait/WaitAsync, Read/ReadAsync. So we'd have setExtension/setExtensionLazy etc.

On Saturday, 20 June 2015 at 20:43:21 UTC, Nick Sabalausky wrote:
> On 06/20/2015 05:27 AM, Vladimir Panteleev wrote:
>> [...]
>
> +1kazillion

+1 ;)

On 6/22/2015 7:22 AM, Vladimir Panteleev wrote:
> It seems everyone in this thread is in agreement, so what would be the next
> step? It is a time-sensitive matter as preparations for 2.068's release are
> already underway. After two pings I failed to engage Walter Bright in this
> conversation; I don't think I should just reopen my pull request a second time,
> and

I've been reading these things, but not engaging in them because it seemed best to let everyone have their say without interference from me.


> I fear that if I merge someone else's pull request, I just might get my
> commit privileges revoked :)

I don't know where I get this terrible reputation - I've never revoked anyone's commit privileges. And certainly not yours - your track record of contributions and positive influence on D is impeccable.