Posted in reply to David B. Held
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
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:
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."
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