On Thursday, August 26, 2010 10:51:02 Andrei Alexandrescu wrote: > 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.
I think that what it comes down to is that you need to be smart about what functionality that you do and don't include. David has an excellent point that when APIs become too complicated, they don't get used. For instance, I know _very_ few people who even _consider_ using C++'s algorithm library. It's just too hard to use. It has too many quirks (like how remove() works) and the lack of lambdas functions makes it incredibly painful to do simple things with it. Any library with much complexity is going to run into such issues, but they need to be minimized for a library to be properly useable. We can't afford to make ranges too complex. They need to be reasonably useable by your average programmer. Any time that we need to add functionality to make them do more, we need to weigh the benefits and costs. If adding ability X makes it possible to do thing Y, but only a few people need to do thing Y, and adding feature X greatly increases the complexity, then it probably shouldn't be added. On the other hand, if adding feature X doesn't add much complexity and/or a lot of people need to do thing Y, then it would likely be a good thing to add feature X. If we find something that a lot of people are trying to do and can't, then we need to really look at a reasonable way to make it possible. However, there are limits to what you can do without making Phobos' APIs unreasonably complex to understand and use. I do _not_ think that we should necessarily be hitting the 100% case. The cost for that is likely too high. However, we probably should be going for more like the 98% or 99% case. (after all 90% indicates that 1 out of 10 things that you try to do won't be feasible, and that's actually a lot, much as 90% sounds like a big number). So, I do think that we should be making ranges (and the rest of Phobos) as powerful we reasonably can, but there _are_ limits to what they can reasonably do, and we should not necessarily try to make it so that they can do absolutely everything. And when we do make ranges more powerful, we need to strive to limit the increase to complexity as much as possible. Ultimately, ranges really should be powerful enough to do virtually everything that you would normally do with iterators (along with what they can do that iterators can't), but they should also be useable by the average programmer. Whatever we do needs to reasonably balance those goals. And I think that there is legitmate concern that ranges are risking becoming too complex. - Jonathan M Davis
