"in" everywhere

[Steven Schveighoffer]

On Fri, 08 Oct 2010 09:46:54 -0400, Juanjo Alvarez <juanjux at gmail.com>  
wrote:

> Steven Schveighoffer Wrote:

>> That kind of "documentation" is useless, it doesn't prevent use, and it
>> doesn't feel right to the person who accidentally uses it.  When I call
>>
>> sort(x);
>>
>> and it performs horribly, am I going to blame x or sort?  Certainly,  
>> I'll
>> never think it's my own fault :)
>>
>> -Steve
>
> True! And that's the only drawback I see on generalizing "in", but there  
> are many things in programming languages that doesn't feel right when  
> you don't
> know the language well. That doesn't mean that D should be the  
> "programming for dummies on rails with a constant automated tutor  
> included" language; if I
> read well the site, it is mean to be a practical language with the  
> ability to shot yourself in the foot.
>
> Still, I don't understand how generalizing "in" could affect  
> std.algorithm et al if they only use "in" for AAs, just like now.

Let's move off of in for a minute, so I can illustrate what I mean.  in is  
kind of a non-universal operator (other languages define it differently).   
Let's try indexing.

If you see the following code:

for(int i = 0; i < x.length; i++)
    x[i]++;

If you see this code, you might think it's O(n).  But let's say the author  
of x didn't care about complexity, and just felt like [] should be for  
indexing, no matter what the cost.  Then x could possibly be a linked  
list, and each index operation is O(n), then this block of code becomes  
O(n^2), and your performance suffers.  You may not notice it, it might be  
"acceptable", but then somewhere down the road you start calling this  
function more, and your program all of a sudden gets really slow.  What  
gives?  Let's say you spend 1-2 hours looking for this and find out that  
the problem is that indexing x is linear, you can change the loop to this:

foreach(ref i; x)
     i++;

and all of a sudden your performance comes back.  Maybe the author of x  
puts right in his docs that indexing is an O(n) operation.  You might  
grumble about it, and move on.  But if this happens all the time, you are  
just going to start blaming the author of x more than your own  
incompetence.  It's one of those things where user interface designers get  
it, and most engineers don't -- people have certain flaws, and a big one  
is not reading the manual.  Making the interface as intuitive as possible  
is very important for the success of a product.

But what if we made the language such that this *couldn't possibly happen*  
because you don't allow indexing on linked lists?  This has the two very  
good properties:

1. It makes the user more aware of the limitations, even though the syntax  
is harder to use (hm.. it doesn't let me use indexing, there must be a  
good reason).
2. It makes *even experienced users* avoid this bug because they can't  
possibly compile it.

#2 is what I care about most.  As an experienced developer, I still might  
make the above mistake (look at Walter's mistake on the compiler that I  
mentioned earlier).  We don't want to set minefields for experienced  
developers if we can help it.  Yes they can shoot themselves in the foot,  
but we don't want to remove the safety on the gun so they are *more  
likely* to shoot themselves in the foot.

-Steve