On 8/26/10 9:18 PDT, dsimcha wrote:
I'm starting to think that the whole concept of ranges is starting to get too complicated. We're already seeing it with this moveFront() stuff that's a special case to deal with structs that have expensive postblits. We need a healthy dose of "worse is better" to throw at ranges. IMHO generic code should solve 90% of the problem in a way that's robust, not terribly hard to implement and easy to use and understand. Trying to solve 100% of the problem with generic code means that your solution will be absurdly complicated in both interface and implementation, and therefore will be a buggy POS that nobody can figure out how to use.
[...]
It's better to have ranges that can solve 90% of the problem for the most competent 80% of programmers than ranges that can solve 100% of the problem, but only for the 1% who are hardcore gurus.
I'm weary of this philosophy. I've seen a phenomenon happen time and again with myself and others: you hit a 10% case exactly when you (a) know what you want to do, (b) you know that the library could and should help you, and (c) you are working on a difficult enough problem to be wary of implementing it by hand.
Two examples from recent history: A poster used std.algorithm for the _first_ (sic!) time, and found a fundamental limitation: std.algorithm doesn't work with immutable arrays. Second, Peter Alexander wanted to implement nextPermutation (a nontrivial algorithm in which you need all the help you can get) as his _first_ (sic again!) artifact of a new library, and hit the bidirectional range composition limitation.
I don't think we want to aim std.algorithm and others for a 90% thing. That's what Visual Basic did. We should aim for making it a 100% thing without losing the other costs from sight (something that I believe we have a good track record on).
In light of that, it's worth looking at optional functionality of the kind I described (allBefore etc.) would add power without aggravating everyone.
Also, regarding moveFront and friends, I think it's a good time to start the following discussion: do we want to support types with arbitrarily expensive copying, or could we simply require reference counting and copy-on-write for such types? Let's start a new thread about this!
Andrei
