iterators again

[Sean Kelly]

David B. Held wrote:
> 
> The main problem is that a lot of people make *abstract* arguments about 
> the pros and cons of various features or lack thereof (with, perhaps a 
> code snippet to illustrate the point).  That is what rarely gets any 
> mileage.  On the other hand, when people build actual libraries and say: 
> "Look, I spent a bunch of time building this awesome library, and I can 
> tell you from first-hand experience that feature Y would really make my 
> life easier", Walter looks at the library and goes "Eh" or "Man, that's 
> a cool library, I really want to polish it up by providing features that 
> will make it even better".  And I can tell you from direct observation 
> that not only does this happen, but Andrei is not the majority 
> beneficiary of such feature determinations.

Personally, when writing libraries if I discover that feature X would 
really simplify things then I'll post an abstract argument on the topic. 
  I think this is generally a better way to do things because it 
separates the discussion from any particular use case and allows the 
feature to be evaluated on its own terms.  That said, those posts have 
often gone completely unanswered so perhaps I'm going about it the wrong 
way.

> What Andrei brings to the table, which might surprise you, is a solid 
> practicality about features.  While D users typically ask for features 
> that require significant amounts of work, Andrei first argues for 
> features that would improve language consistency, which is building a 
> better foundation for the future than just trying to get everything you 
> want right away.  Another important point to make is that the so-called 
> "Inner Circle" is often as concerned as the D community as a whole about 
> many important features like reflection, macros, etc. (and remember that 
> Walter is a part of the "Inner Circle").

I think you'll find that many of the requests here in the past have 
actually been for consistency rather than fancy new features.  That's 
why, in my mind, Andrei's involvement was seen as such a good thing by 
many of us.  By and large, he echoed the sentiments the community as a 
whole, with macro features as a possible notable exception.

> This is what the community sees: "I want feature X, because it's cool!" 
>  This is what Walter sees: "That feature will take 40 hours of 
> bickering, arguing and fist-fighting to get just a few people to agree 
> on how it should be implemented and what it should mean in every 
> possible context in which it could appear."  The fact of the matter is, 
> most of the time is *not* spent picking and choosing features like the 
> Illuminati deciding the fate of the world.  It is more like construction 
> workers building a railroad.  Everyone points to the map and says where 
> they want the railroad to go and says how glorious it would be if it got 
> there, but only a few people are picking up hammers and blasting 
> mountains and building bridges and doing the not-very-glamaorous work of 
> just putting another mile on the track.

I've suggested that a mailing list for focused discussions might be 
useful, but it's still a poor alternative to talking to someone 
physically.  Still, I think many of us recognize that a newsgroup is far 
too large a forum for productive discussion.

> So when people bicker about not being in the "Inner Circle", I find it 
> fairly amusing, because if they only knew what a bunch of drudge work it 
> is, they would be much more grateful when a new feature magically pops 
> out of the next version of dmd.  Anyone who wants to be a part of the 
> "Inner Circle" effectively can be by A) writing a compelling library to 
> motivate the need for certain features, or B) writing a compelling 
> feature proposal with enough detail to actually implement it.  If you're 
> wondering how much detail that is, browse the C++ proposals, and 
> consider that probably 80% of them are not detailed enough to be fully 
> useful to a compiler writer.

I think this issue comes up because there has sometimes been very little 
communication about what is being developed.  I know that I have simply 
avoided developing certain libraries in the past because a proper 
implementation would have required feature X (usually some template 
thing that we now have), and I had no interest in writing temporary 
workarounds that may become permanent or may be obsolete a week after 
they were written.  I don't think that means we (or I) always want to 
help hash out the minutiae of how a feature is implemented however (I'm 
busy enough as it is, frankly).

That said, Walter has gotten a lot better about announcing or discussing 
new features here beforehand.  For the most part, we now have some 
warning about what is being developed and roughly how it will look.  And 
in most cases, that's enough to focus library development.


Sean