iterators again

[Bruno Medeiros]

David B. Held wrote:
> 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. 

I must contend against that. I would say most of D users (on the NG at 
least), myself included, argue about languages changes (some of them 
trivial to implement) to existing features, and not about new features.
If you check my D wiki page ( 
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D ) you'll see I 
keep track of issues I have looked into and think should be changed one 
way or the other. All of them except two ("Copy Operator", "Ctors as 
regular functions") are trivial or easy changes to existing features, 
they are not new features. (I won't get started on what I think of AST 
macros)

>(and remember that 
> Walter is a part of the "Inner Circle").
>

Of course he is, he's the center of it! Duuh :P

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

Yes, but some people do not have the time or inclination to write large 
amounts of D code just to prove a point. And it really should not be 
necessary, as one's previous experience (with other languages or D 
itself) should be enough to extrapolate and make a valid argument about 
a given language issue.
Furthermore, some issues may be subtle or specific enough that building 
exemplifying code won't really help much than an argument.

Let me give you an example. One of my first "big" posts here in the NG 
was about entity/symbol visibility issues ("Entity naming revised" 
http://www.digitalmars.com/d/archives/digitalmars/D/28423.html). It 
discussed and argued for four separate(as in orthogonal) proposals. Two 
of them (FQN import, and private import by default) were accepted into 
D, but only *one year later*, when, Kris, the developer of Mango (a 
large D library), complain about it, referring actual annoyances in his 
Mango development experience.
Now, was my "abstract" argument not valid then just because I didn't 
have D code experience to back it up? I don't think so. I indeed did not 
have any D code experience on it, but I had experience on other 
medium-large code in other languages (both *having* and *not having* FQN 
import), from which I (and anyone else with a typical development 
experience) could clearly extrapolate that not having FQN import in D 
would suck.
(And on a side note, I think proposal 3 will also be placed into effect 
eventually, even if "only" at the IDE level)

Another example is the "Is Type Expression trickyness" issue (please 
read on it on my wiki page, it's just one paragraph). Now, I stumbled on 
that very bug (a typo) myself when writing a small experimental D 
template code. It took me a while to find the bug (about 5 minutes), 
whereas it would be instantly found if the Is-Type expression would not 
accept semantic errors. Now, how much D code would I have to write, and 
then stumble on that bug, to show to Walter that that aspect should 
change? Why isn't an argument that extrapolates from a singular 
experience enough?


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

I also contend against that. First, not all changes require examining 
large "minutiae" to make them work, namely for minor changes to existing 
features where the greatest issue is not *how* the change should be 
made, but whether *should* the change be made or not. One example is the 
"Entity Naming Revised" post I mentioned above. It was a big post but 
the core of it was about *why* should the changed be made, and not 
*how*, since the changes and syntax themselves where very trivial.
Second, as for the big languages changes, yes, they do require thinking 
about all possible interactions and a lot of details, and sometimes 
people don't do that when arguing about features, but *I* actually do 
that (when actually arguing about it, at least). You mentioned writing a 
detailed proposal. That's quite a timing, since I actually did that 
recently, sparked by Andrei's intellectual challenges and increased 
involvement in NG interaction. It's about the frontline 
const/immutability issue
(http://www.digitalmars.com/d/archives/digitalmars/D/Extended_Type_Design._50225.html#N50476)
and it details what I believe is a complete, working and very near 
compiler-implementable const set of features. And more significantly, I 
must say the same cannot be said about Andrei/Walter's design, at least 
in what has been posted in the NG. For example, in their proposal, I 
still don't what is the typeof(fooptr) as in the code below:
   final foo;
   auto fooptr = &foo;
even though I asked 2 or 3 times now. And there also has not yet been 
any mention of how const/final/etc. will work in regards of template 
specialization (how to specialize on const, etc.). Do they even have a 
complete design? I don't know. Maybe it is just the case that they do, 
and have not posted all their new info in the NG (specially since Andrei 
is now away). In any case, my point is just to disprove your point :) . 
I.e., that people here (not just me) usually do think in detail about 
what they are proposing. (not like: HAI THAR GUYS, CAN I HAVE REFLEXION 
AND MACROS PLZ?? KTHXBYE!!1) :P

> 
> 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

Just to finish off, this post is not meant to be in a bicker tone. I 
also am not bicker about Walter mostly only listening to the small Inner 
Circle, as I do agree that this is best than design by committee, or 
than design by popular vote, or similar stuff, like you mentioned. My 
point is that
a) this approach (one man design) does still have some disadvantages 
which we should be aware of. Particularly since I believe Walter has a 
very atypical programming experience, making it hard to present some 
otherwise IMO obvious points (which is why I looked with good eyes to 
the increased involvement of Inner Circle member Andrei in the NG, I 
hope he comes back).
b) "abstract" arguments should not be discarded, for the reasons 
mentioned above.
c) I like the term "Inner Circle" :P

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D