On Fri, 08 Oct 2010 09:46:54 -0400, Juanjo Alvarez <juan...@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
