May 28, 2007
"David B. Held" <dheld@codelogicconsulting.com> wrote in message news:f3f43e$1lth$1@digitalmars.com...
> If you want D to develop as quickly as C++, then Design by Committee is a great idea.  When does C++0x come out?  2009?  If you want to hear the status straight from the horse's mouth, so to speak, move to Seattle, where you can stalk him in person. ;)

:P

> If you notice, Walter does solicit public feedback directly from time to time, but you may also notice that it takes a long time for a feature to go from idea to implementation.  If he announced every thought he or someone else had about a feature while it was being designed, you'd find that most of it is noise or confusing.  If you multiply that by the number of people on the NG, I guarantee that absolutely nothing would get done. It's simply a matter of pragmatism to meet with people face-to-face to help flesh out ideas, because the bandwidth is much higher and it's easier to filter out the noise.

Sounds like a good place for a D development blog.  Walter could post saying what's on his mind for D development, and that could be a starting place for discussion on the NGs, not even necessarily with Walter involved.  It would also let people know what could be coming soon, so they don't spend time trying to come up with some horrendous hack to work around the lack of a feature that's coming soon.

What's a bit weird is that sometimes some feature will just come out of nowhere, with no announcement, no pre-discussion, no communication whatsoever besides a bullet on the "what's new with DMD 1.xxx" page.  And they're not always trivial features either -- import() and mixin() expressions, struct literals, scope() statements, and nested classes were all "well OK, never saw that one coming" features.

> But I will say this: Walter is influenced more by libraries that he thinks are cool or important than by many other considerations, and insists that features those libraries need to survive and thrive be given extra priority.  So people who want to lobby for a pet feature can do so most effectively by producing a significant library that demonstrates the need for the feature.  It seems only natural that if there isn't a significant use case, the value of a feature is unproven.

Walter also seems to be influenced by certain people more than others, which is more than a little disturbing.


May 28, 2007
Jarrett Billingsley wrote:

> Walter also seems to be influenced by certain people more than others, which is more than a little disturbing. 

Why does it disturb you?  You can't please everyone, and ultimately it's Walter's design, so he gets to decide who he agrees with and what his priorities are.

--bb
May 28, 2007
Jarrett Billingsley wrote:
> [...]
> Sounds like a good place for a D development blog.

A blog is an interesting idea, but Walter doesn't strike me as the blogging type.

> [...]
> What's a bit weird is that sometimes some feature will just come out of nowhere, with no announcement, no pre-discussion, no communication whatsoever besides a bullet on the "what's new with DMD 1.xxx" page.  And they're not always trivial features either -- import() and mixin() expressions, struct literals, scope() statements, and nested classes were all "well OK, never saw that one coming" features.

Walter is trying to evolve the language as quickly as possible, and even when he sets priorities, he later changes them for various reasons. There has been discussion of a roadmap to help smooth things out, but you should harrass Brad Roberts about that.  Which would you prefer: vaporware announcements or surprise announcements?  I'll always take overdeliver to overpromise every day of the week and twice on Sundays.

> [...]
> Walter also seems to be influenced by certain people more than others, which is more than a little disturbing. 

Is it more disturbing than the President being more influenced by his cabinet than his countrymen (say, yourself...assuming you aren't part of the Bush cabinet, of course)?  Is it more disturbing than Bjarne designing C++ with his local colleagues at AT&T?  More disturbing than James Gosling designing Java with a few friends at Sun?  More disturbing than Larry Wall single-handedly deciding what goes in Perl 6?

Pick a successful language, and I will show you a language that was not designed by democracy.  Unlike your government, you can pick your language, and I presume people have picked D so far because they thought it was designed well (or at least better than the alternatives for a sufficient range of cases).  If you can find a D-size language designed by a community to show that that is a Better Way, I'm sure we would all be both surprised and delighted to hear about it.  Until then, the proof of the pudding is in the eating, and everyone who has tasted the language design pudding has decided that a small group of individuals, however flawed they may be, produces a better product than a whole community.

At some point in a language's evolution, the weight of the community increases and becomes the dominant force.  COBOL, FORTRAN, Lisp, C and C++ are all too mature to be run by a maverick designer any more.  Even Java is moving towards a more heavily community-weighted input, and it's still a relatively young language.  However, D is barely out of the starting gate (and by some measures, has not even left the gate yet) and already you want to saddle it with bureaucracy?  Maturity leads to fossilization.  When everyone has an equal say, conflicting interests stifle progress.

All of the languages I mentioned could be seriously upgraded...if not for the fact that they all have millions of users whose code would get broken if you made more than minor changes.  Look at Java...despite being less than 10 years old, they couldn't even add first-class generics due to backwards compatibility.  C# is only a few years younger, but was able to do things the right way because its VM hadn't totally fossilized yet.

Walter knows and recognizes that everyone wants D to succeed.  And trust me, he reads the NGs as much as anyone, and takes the community quite seriously.  But at the end of the day, Walter only has one brain to design D with, and fully analyzing every input available to him would seriously overcommit the computing resources of that brain, however oversize it may already be.  I think he takes a very meritocratic approach while conceding the pragmatism of geography; and if you stack up his design approach against any other major language designer's, I think you'll see that few other designers are nearly as democratic at this stage in a language's development.

I personally wouldn't want a language designed by a committee of equals, because I've seen software produced that way, and it almost universally sucks.  If you don't trust the people who are designing a system, well, there's not much you can do about that but complain.  But if they've produced a decent product so far, perhaps they have earned some trust and should be given the benefit of the doubt.  If you can argue convincingly that the "cabal that meets behind closed doors" isn't doing a good job, I'm sure your argument would be given serious consideration.  But merely complaining about a process without any demonstration that it's a bad process is arguing on principles that are not well-established.

Let me give you an example from real life.  Consider The Simpsons.  When The Simpsons was written by Matt Groening and one or two other writers, the show was considered brilliant.  When Groening left to do other things and the show was handed over to a team of writers, the show was considered mediocre and continued merely on the weight of its momentum and the brand that Groening had established.  Now imagine if Groening had opened up The Simpsons writing to his fanbase, which would be the democratic thing to do.  How good would you think the episodes would be then?  Out of all the fans, there may be one or two really brilliant writers who could actually have improved the show.  But with "one man, one vote", their voices would have been lost in the cacophony of severe sub-mediocrity.

That's not to say that folks on the NGs are all mediocre or less.  I think the fact that they are willing to try out a new language puts them in a different class than your average coder.  But I will say that most of them are not committed programming language designers, and if you left them to design a language, they might create one or two really nice features, and then move on to other things.  That doesn't give you the kind of experience needed to understand how much a feature will cost to implement and how much value it provides relative to other ways of doing things.  Perhaps Walter is missing out on those one or two brilliant writers lurking out there.  But I don't think he is.

The people who push the language to its limits demonstrate the need for various features in quite palpable ways.  Those are the best arguments for change, and it doesn't take a committee to see that.  Do you want to know why Andrei has so much influence in D's design?  Because he uses D on a supercomputing cluster.  He showed that one of his programs was unnecessarily slow because of the design of the allocator and suggested an alternative that was known from C++.  When Walter implemented it, he found that it did indeed give enormous performance benefits.  Andrei argued for struct literals because it would seriously improve the readability of his code.

Andrei isn't just some "blessed expert".  He earns his clout through his code.  Is it fair that he has access to a cluster that most of us will never see?  No.  But do you want the design of D to be hamstrung by "fairness"?  I think Walter's approach to language design is fairly inspired because it is not so much about individual people as it is programs.  Walter cares about which programs are easiest to write and fastest to run, and it is these programs that guide his decisions. People turn out to be the representatives of the programs, even when the programs aren't actually written (because people have to write them after all), but it isn't so much the people themselves who influence the design so much as the resulting programs.

It's something like a genetic algorithm for language design.  The most compelling programs are assigned higher fitness and given more "survival tools" (features) for the next round of culling/evaluation.  Since Walter cannot directly inspect the space of all D programs in any meaningful way, he needs people to help him visualize the important parts of the space.  If he could do that without relying on people, I'm fairly certain that there would be nobody advising him.  Anybody can be that person that says: "Hey, look here!  This is a very interesting portion of the program space!"  But some people are naturally better at doing that than others, and that is why it appears that some people have more influence.  In reality, it is that some *programs* have more influence.

Perhaps Andrei seems like a Dick Cheney or Karl Rove, pulling Walter's strings like a political puppet.  But you quickly become disabused of that notion when you see Walter say to Andrei point-blank: "No, you are wrong!"  Even Andrei has to concede at the end of the day that Walter will decide for himself what is best for the language.  But if it appears that he has more influence, it is only because he has worked much, much harder for it than most.  Like I said, it's very meritocratic.  And like I said, while the people who meet with Walter face-to-face are constrained by geography, the people who have influence on the language's design are not.

I don't think Walter needs any defense of his approach to language design, but I hope that gives you a little insight from the perspective of someone who has seen both sides.

Dave
May 28, 2007
David B. Held wrote:
> If you can find a D-size language designed by a community to show that that is a Better Way, I'm sure we would all be both surprised and delighted to hear about it.

One could argue that Ada is such a language, and it's really pretty nice in my opinion.  But I wouldn't go so far as to call it a successful language.  People have heard of it and it's used in the circles for whom it was designed, but that's about it.


Sean
May 28, 2007
Sean Kelly wrote:
> David B. Held wrote:
>> If you can find a D-size language designed by a community to show that that is a Better Way, I'm sure we would all be both surprised and delighted to hear about it.
> 
> One could argue that Ada is such a language, and it's really pretty nice in my opinion.  But I wouldn't go so far as to call it a successful language.  People have heard of it and it's used in the circles for whom it was designed, but that's about it.

I actually used it in college because that's what my school taught for CS 1 and 2, and the most striking thing about Ada is that it was so far ahead of its time, it took about a decade for someone to implement a full compiler for the language.  Either that, or it was so overdesigned that nobody could implement it.  The problem was, it was only overdesigned at the time it was conceived.  By the time people got around to implementing it, other languages had already made it passe. It moved like molasses, and that's why the only major adopter has been an organization that moves like molasses: the DoD.

That being said, it has influenced subsequent languages, but has done so without being any of those languages, which is a dubious honor at best...one that I hope D can avoid by being smaller and nibler.  Of course, the counter-examples are all the major and popular languages that exist today that were primarily designed by one driving personality plus a small group of colleagues.

Dave
May 28, 2007
Now that's one serious argument! It's actually strange how several language designers are met with users who feel they somehow own the language just as much as the inventor does. Quite arrogant if you ask me. On the other hand it's also positive to have users that involved, entusiastic and passionate about a language. May the best argument win...

R, Bent

"David B. Held" <dheld@codelogicconsulting.com> wrote in message news:f3fgv2$27mg$1@digitalmars.com...
> Jarrett Billingsley wrote:
>> [...]
>> Sounds like a good place for a D development blog.
>
> A blog is an interesting idea, but Walter doesn't strike me as the blogging type.
>
>> [...]
>> What's a bit weird is that sometimes some feature will just come out of nowhere, with no announcement, no pre-discussion, no communication whatsoever besides a bullet on the "what's new with DMD 1.xxx" page.  And they're not always trivial features either -- import() and mixin() expressions, struct literals, scope() statements, and nested classes were all "well OK, never saw that one coming" features.
>
> Walter is trying to evolve the language as quickly as possible, and even when he sets priorities, he later changes them for various reasons. There has been discussion of a roadmap to help smooth things out, but you should harrass Brad Roberts about that.  Which would you prefer: vaporware announcements or surprise announcements?  I'll always take overdeliver to overpromise every day of the week and twice on Sundays.
>
>> [...]
>> Walter also seems to be influenced by certain people more than others, which is more than a little disturbing.
>
> Is it more disturbing than the President being more influenced by his cabinet than his countrymen (say, yourself...assuming you aren't part of the Bush cabinet, of course)?  Is it more disturbing than Bjarne designing C++ with his local colleagues at AT&T?  More disturbing than James Gosling designing Java with a few friends at Sun?  More disturbing than Larry Wall single-handedly deciding what goes in Perl 6?
>
> Pick a successful language, and I will show you a language that was not designed by democracy.  Unlike your government, you can pick your language, and I presume people have picked D so far because they thought it was designed well (or at least better than the alternatives for a sufficient range of cases).  If you can find a D-size language designed by a community to show that that is a Better Way, I'm sure we would all be both surprised and delighted to hear about it.  Until then, the proof of the pudding is in the eating, and everyone who has tasted the language design pudding has decided that a small group of individuals, however flawed they may be, produces a better product than a whole community.
>
> At some point in a language's evolution, the weight of the community increases and becomes the dominant force.  COBOL, FORTRAN, Lisp, C and C++ are all too mature to be run by a maverick designer any more.  Even Java is moving towards a more heavily community-weighted input, and it's still a relatively young language.  However, D is barely out of the starting gate (and by some measures, has not even left the gate yet) and already you want to saddle it with bureaucracy?  Maturity leads to fossilization. When everyone has an equal say, conflicting interests stifle progress.
>
> All of the languages I mentioned could be seriously upgraded...if not for the fact that they all have millions of users whose code would get broken if you made more than minor changes.  Look at Java...despite being less than 10 years old, they couldn't even add first-class generics due to backwards compatibility.  C# is only a few years younger, but was able to do things the right way because its VM hadn't totally fossilized yet.
>
> Walter knows and recognizes that everyone wants D to succeed.  And trust me, he reads the NGs as much as anyone, and takes the community quite seriously.  But at the end of the day, Walter only has one brain to design D with, and fully analyzing every input available to him would seriously overcommit the computing resources of that brain, however oversize it may already be.  I think he takes a very meritocratic approach while conceding the pragmatism of geography; and if you stack up his design approach against any other major language designer's, I think you'll see that few other designers are nearly as democratic at this stage in a language's development.
>
> I personally wouldn't want a language designed by a committee of equals, because I've seen software produced that way, and it almost universally sucks.  If you don't trust the people who are designing a system, well, there's not much you can do about that but complain.  But if they've produced a decent product so far, perhaps they have earned some trust and should be given the benefit of the doubt.  If you can argue convincingly that the "cabal that meets behind closed doors" isn't doing a good job, I'm sure your argument would be given serious consideration. But merely complaining about a process without any demonstration that it's a bad process is arguing on principles that are not well-established.
>
> Let me give you an example from real life.  Consider The Simpsons.  When The Simpsons was written by Matt Groening and one or two other writers, the show was considered brilliant.  When Groening left to do other things and the show was handed over to a team of writers, the show was considered mediocre and continued merely on the weight of its momentum and the brand that Groening had established.  Now imagine if Groening had opened up The Simpsons writing to his fanbase, which would be the democratic thing to do.  How good would you think the episodes would be then?  Out of all the fans, there may be one or two really brilliant writers who could actually have improved the show.  But with "one man, one vote", their voices would have been lost in the cacophony of severe sub-mediocrity.
>
> That's not to say that folks on the NGs are all mediocre or less.  I think the fact that they are willing to try out a new language puts them in a different class than your average coder.  But I will say that most of them are not committed programming language designers, and if you left them to design a language, they might create one or two really nice features, and then move on to other things.  That doesn't give you the kind of experience needed to understand how much a feature will cost to implement and how much value it provides relative to other ways of doing things. Perhaps Walter is missing out on those one or two brilliant writers lurking out there.  But I don't think he is.
>
> The people who push the language to its limits demonstrate the need for various features in quite palpable ways.  Those are the best arguments for change, and it doesn't take a committee to see that.  Do you want to know why Andrei has so much influence in D's design?  Because he uses D on a supercomputing cluster.  He showed that one of his programs was unnecessarily slow because of the design of the allocator and suggested an alternative that was known from C++.  When Walter implemented it, he found that it did indeed give enormous performance benefits.  Andrei argued for struct literals because it would seriously improve the readability of his code.
>
> Andrei isn't just some "blessed expert".  He earns his clout through his code.  Is it fair that he has access to a cluster that most of us will never see?  No.  But do you want the design of D to be hamstrung by "fairness"?  I think Walter's approach to language design is fairly inspired because it is not so much about individual people as it is programs.  Walter cares about which programs are easiest to write and fastest to run, and it is these programs that guide his decisions. People turn out to be the representatives of the programs, even when the programs aren't actually written (because people have to write them after all), but it isn't so much the people themselves who influence the design so much as the resulting programs.
>
> It's something like a genetic algorithm for language design.  The most compelling programs are assigned higher fitness and given more "survival tools" (features) for the next round of culling/evaluation.  Since Walter cannot directly inspect the space of all D programs in any meaningful way, he needs people to help him visualize the important parts of the space. If he could do that without relying on people, I'm fairly certain that there would be nobody advising him.  Anybody can be that person that says: "Hey, look here!  This is a very interesting portion of the program space!"  But some people are naturally better at doing that than others, and that is why it appears that some people have more influence.  In reality, it is that some *programs* have more influence.
>
> Perhaps Andrei seems like a Dick Cheney or Karl Rove, pulling Walter's strings like a political puppet.  But you quickly become disabused of that notion when you see Walter say to Andrei point-blank: "No, you are wrong!" Even Andrei has to concede at the end of the day that Walter will decide for himself what is best for the language.  But if it appears that he has more influence, it is only because he has worked much, much harder for it than most.  Like I said, it's very meritocratic.  And like I said, while the people who meet with Walter face-to-face are constrained by geography, the people who have influence on the language's design are not.
>
> I don't think Walter needs any defense of his approach to language design, but I hope that gives you a little insight from the perspective of someone who has seen both sides.
>
> Dave 

May 29, 2007
David B. Held wrote:
> Jarrett Billingsley wrote:
>> [...]
>> Sounds like a good place for a D development blog.
> 
> A blog is an interesting idea, but Walter doesn't strike me as the blogging type.
> 
>> [...]
>> What's a bit weird is that sometimes some feature will just come out of nowhere, with no announcement, no pre-discussion, no communication whatsoever besides a bullet on the "what's new with DMD 1.xxx" page.  And they're not always trivial features either -- import() and mixin() expressions, struct literals, scope() statements, and nested classes were all "well OK, never saw that one coming" features.
> 
> Walter is trying to evolve the language as quickly as possible, and even when he sets priorities, he later changes them for various reasons. There has been discussion of a roadmap to help smooth things out, but you should harrass Brad Roberts about that.  Which would you prefer: vaporware announcements or surprise announcements?  I'll always take overdeliver to overpromise every day of the week and twice on Sundays.

I agree. But I think the point was, that it would be nice to have *some idea* of what Walter's most interested in/currently coding/thinking about/etc. A list of 'areas most likely to change in the near term', or something. It does make a difference if you're trying to work around language limitations, to know whether a much better way is going to appear next week.
The 'future directions' page would do it if wasn't so completely useless: it's had "template inheritance" on it for years, but major stuff like CTFE wasn't on it.

The constness stuff is one of very few examples where Walter announced something *before* he'd implemented it <g>.

But hey, looking at the changelog when downloading the latest DMD release is like opening your Christmas presents <g>.
May 30, 2007
David B. Held wrote:
> Jarrett Billingsley wrote:
>> [...]
>> Sounds like a good place for a D development blog.
> 
> A blog is an interesting idea, but Walter doesn't strike me as the blogging type.
> 
>> [...]
>> What's a bit weird is that sometimes some feature will just come out of nowhere, with no announcement, no pre-discussion, no communication whatsoever besides a bullet on the "what's new with DMD 1.xxx" page.  And they're not always trivial features either -- import() and mixin() expressions, struct literals, scope() statements, and nested classes were all "well OK, never saw that one coming" features.
> 
> Walter is trying to evolve the language as quickly as possible, and even when he sets priorities, he later changes them for various reasons. There has been discussion of a roadmap to help smooth things out, but you should harrass Brad Roberts about that.  Which would you prefer: vaporware announcements or surprise announcements?  I'll always take overdeliver to overpromise every day of the week and twice on Sundays.
> 
>> [...]
>> Walter also seems to be influenced by certain people more than others, which is more than a little disturbing. 
> 
> Is it more disturbing than the President being more influenced by his cabinet than his countrymen (say, yourself...assuming you aren't part of the Bush cabinet, of course)?  Is it more disturbing than Bjarne designing C++ with his local colleagues at AT&T?  More disturbing than James Gosling designing Java with a few friends at Sun?  More disturbing than Larry Wall single-handedly deciding what goes in Perl 6?
> 
> Pick a successful language, and I will show you a language that was not designed by democracy.  Unlike your government, you can pick your language, and I presume people have picked D so far because they thought it was designed well (or at least better than the alternatives for a sufficient range of cases).  If you can find a D-size language designed by a community to show that that is a Better Way, I'm sure we would all be both surprised and delighted to hear about it.  Until then, the proof of the pudding is in the eating, and everyone who has tasted the language design pudding has decided that a small group of individuals, however flawed they may be, produces a better product than a whole community.
> 
> At some point in a language's evolution, the weight of the community increases and becomes the dominant force.  COBOL, FORTRAN, Lisp, C and C++ are all too mature to be run by a maverick designer any more.  Even Java is moving towards a more heavily community-weighted input, and it's still a relatively young language.  However, D is barely out of the starting gate (and by some measures, has not even left the gate yet) and already you want to saddle it with bureaucracy?  Maturity leads to fossilization.  When everyone has an equal say, conflicting interests stifle progress.
> 
> All of the languages I mentioned could be seriously upgraded...if not for the fact that they all have millions of users whose code would get broken if you made more than minor changes.  Look at Java...despite being less than 10 years old, they couldn't even add first-class generics due to backwards compatibility.  C# is only a few years younger, but was able to do things the right way because its VM hadn't totally fossilized yet.
> 
> Walter knows and recognizes that everyone wants D to succeed.  And trust me, he reads the NGs as much as anyone, and takes the community quite seriously.  But at the end of the day, Walter only has one brain to design D with, and fully analyzing every input available to him would seriously overcommit the computing resources of that brain, however oversize it may already be.  I think he takes a very meritocratic approach while conceding the pragmatism of geography; and if you stack up his design approach against any other major language designer's, I think you'll see that few other designers are nearly as democratic at this stage in a language's development.
> 
> I personally wouldn't want a language designed by a committee of equals, because I've seen software produced that way, and it almost universally sucks.  If you don't trust the people who are designing a system, well, there's not much you can do about that but complain.  But if they've produced a decent product so far, perhaps they have earned some trust and should be given the benefit of the doubt.  If you can argue convincingly that the "cabal that meets behind closed doors" isn't doing a good job, I'm sure your argument would be given serious consideration.  But merely complaining about a process without any demonstration that it's a bad process is arguing on principles that are not well-established.
> 
> Let me give you an example from real life.  Consider The Simpsons.  When The Simpsons was written by Matt Groening and one or two other writers, the show was considered brilliant.  When Groening left to do other things and the show was handed over to a team of writers, the show was considered mediocre and continued merely on the weight of its momentum and the brand that Groening had established.  Now imagine if Groening had opened up The Simpsons writing to his fanbase, which would be the democratic thing to do.  How good would you think the episodes would be then?  Out of all the fans, there may be one or two really brilliant writers who could actually have improved the show.  But with "one man, one vote", their voices would have been lost in the cacophony of severe sub-mediocrity.
> 
> That's not to say that folks on the NGs are all mediocre or less.  I think the fact that they are willing to try out a new language puts them in a different class than your average coder.  But I will say that most of them are not committed programming language designers, and if you left them to design a language, they might create one or two really nice features, and then move on to other things.  That doesn't give you the kind of experience needed to understand how much a feature will cost to implement and how much value it provides relative to other ways of doing things.  Perhaps Walter is missing out on those one or two brilliant writers lurking out there.  But I don't think he is.
> 
> The people who push the language to its limits demonstrate the need for various features in quite palpable ways.  Those are the best arguments for change, and it doesn't take a committee to see that.  Do you want to know why Andrei has so much influence in D's design?  Because he uses D on a supercomputing cluster.  He showed that one of his programs was unnecessarily slow because of the design of the allocator and suggested an alternative that was known from C++.  When Walter implemented it, he found that it did indeed give enormous performance benefits.  Andrei argued for struct literals because it would seriously improve the readability of his code.
> 
> Andrei isn't just some "blessed expert".  He earns his clout through his code.  Is it fair that he has access to a cluster that most of us will never see?  No.  But do you want the design of D to be hamstrung by "fairness"?  I think Walter's approach to language design is fairly inspired because it is not so much about individual people as it is programs.  Walter cares about which programs are easiest to write and fastest to run, and it is these programs that guide his decisions. People turn out to be the representatives of the programs, even when the programs aren't actually written (because people have to write them after all), but it isn't so much the people themselves who influence the design so much as the resulting programs.
> 
> It's something like a genetic algorithm for language design.  The most compelling programs are assigned higher fitness and given more "survival tools" (features) for the next round of culling/evaluation.  Since Walter cannot directly inspect the space of all D programs in any meaningful way, he needs people to help him visualize the important parts of the space.  If he could do that without relying on people, I'm fairly certain that there would be nobody advising him.  Anybody can be that person that says: "Hey, look here!  This is a very interesting portion of the program space!"  But some people are naturally better at doing that than others, and that is why it appears that some people have more influence.  In reality, it is that some *programs* have more influence.
> 
> Perhaps Andrei seems like a Dick Cheney or Karl Rove, pulling Walter's strings like a political puppet.  But you quickly become disabused of that notion when you see Walter say to Andrei point-blank: "No, you are wrong!"  Even Andrei has to concede at the end of the day that Walter will decide for himself what is best for the language.  But if it appears that he has more influence, it is only because he has worked much, much harder for it than most.  Like I said, it's very meritocratic.  And like I said, while the people who meet with Walter face-to-face are constrained by geography, the people who have influence on the language's design are not.
> 
> I don't think Walter needs any defense of his approach to language design, but I hope that gives you a little insight from the perspective of someone who has seen both sides.
> 
> Dave

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

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 30, 2007
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
May 30, 2007
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