iterators again

[David B. Held]

Bruno Medeiros wrote:
> [...]
> Nice post, I agree. However I also think that some language issues 
> cannot be trivially shown to Walter to be inadequate or suboptimal (like 
> the Andrei allocator example). In fact probably *most* language design 
> issues are like that (the allocator example wasn't even a design issue, 
> but rather an implementation one, right?), because their effects, in 
> terms of code productivity or cleanliness, despite being considerable, 
> are also subtle and amortized accross large amounts of code and 
> development time. This is especially true of small, but important, 
> details, and it makes it very hard, if not impossible, to show hard 
> examples of why something should be changed. Instead, arguing is the 
> only option left, but which often is inneffective against Walter, 
> especially to those outside the D "Inner Circle". :7

I think if you have actual code where you can point to it and say: "In 
34 places I write this bit of code which would be improved by feature 
X", and Walter says: "Overall, I think your code is cool and I want to 
help it along", you have as much chance as anybody to get your wish. 
Here's a real-life example: Andrei *really* hates having to write 
.length for all his array references.  He would much rather have array.$ 
or something.  So he went through his code and found that he had to say 
array.length like 300+ times in a few thousand lines of code, and made 
the point that while this is a very minor feature, it impacts the 
readability of a lot of code.

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.

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").

To be perfectly honest, what Walter does with his colleagues on a 
regular basis would probably be considered rather boring by most people: 
he sits down and hashes out the tedious minutiae of implementing a 
particular feature, no matter how small or insignificant it might be. 
Considering that each feature has the potential to impact lots of 
aspects of the language, this isn't the exciting "We're designing a 
rocket ship" aspect of PL design that perhaps many people think it is. 
It's slow, frustrating, and sometimes difficult work.  If you don't 
believe me, pick your favorite feature, and try to write up a document 
that describes how it interacts with every major part of the language.

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.

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.

It's one thing to say: "It would be cool if my code could look like 
this", and quite another to say: "...and this is how we could get there."

Dave