Whither Tango?

[Justin Johansson]

While moving off the formal topic of the informal list of "silly names",
me thinks Michel well articulates a valid point.

Cheers
Justin


Michel Fortin wrote:
> On 2010-02-19 09:11:11 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>> If you could provide a list of silly named symbols that could be a 
>> dealbreaker for a prospective D user, please let me know. Thanks.
> 
> I don't think there are really any 'silly' names (except perhaps iota), 
> it's just that many don't do exactly what you think they do on first 
> reading. For instance, the other day I was working with input ranges and 
> needed a way to take N elements from the range and put them aside to 
> work on them later. So I defined my own function "take" for that.
> 
> To me, "take" means you take one or more element and they aren't in the 
> range anymore afterwards.
> 
> If you look at std.range, you'll find the same function 'take', but it 
> does its job lazily. That's great, except when you don't expect it. The 
> name is not really silly, just not precise enough. I think there should 
> be a clue (in the name) telling you it does its job lazily, because in 
> general functions do what they say *when* you call them, not at a later 
> point in time.
> 
> In my case I often have to save some parts of the input for later, and 
> any use of lazy ranges in those cases would be a bug. I think 'take' 
> should do what it says: take N elements, and immediately, not later.
> 
> I know you can write "array(take(5, range))" do do what I want, but the 
> point is that take(5, range) alone doesn't do what you'd expect it to do 
> at first glance, which is to take 5 elements from the range. Beside, 
> "array(take(...))" can be wasteful sometime: for arrays (and some other 
> ranges) you can just slice them in two parts and return the first slice, 
> no heap allocation needed. But that optimization is harder to achieve 
> and expect with the "array(take(...))" combination.
> 
> I think this criticism applies to other parts of std.range too.
> 
> I expect you'll be unwilling to change the name because however you 
> rename it it'll be a little longer and give a less special function (the 
> eager one) the simpler name, and that'd be boring. But most people will 
> expect to see the less special function when seeing the simple name at 
> first, so having it as the default makes the learning curve easier and 
> less error-prone.
>