• Bill Baxter (9/9) May 27 2007 What's the deal with making iterators be classes in D, rather than
• David B. Held (5/14) May 27 2007 Iterators should almost certainly be value types (structs). The
• Bill Baxter (17/31) May 27 2007 Hmm, I can't think of a case where any of that would matter.
• David B. Held (7/13) May 27 2007 Classes have reference semantics, so you need to implement a clone()
• Bill Baxter (10/24) May 27 2007 Ok, the way you said it before made it sound like you were arguing
• David B. Held (5/10) May 28 2007 The language definitely needs to change, and fixing structs to be on par...
• Jarrett Billingsley (7/9) May 28 2007 Through what mystical channels of communication do you obtain such
• Frits van Bommel (2/12) May 28 2007 IIRC David talks to Alexei (and Walter?) IRL...
• Jarrett Billingsley (9/10) May 28 2007 That's good to know, but it would be _fantastic_ if the results of their...
• David B. Held (22/34) May 28 2007 If you want D to develop as quickly as C++, then Design by Committee is
• Jarrett Billingsley (17/37) May 28 2007 :P
• Bill Baxter (5/7) May 28 2007 Why does it disturb you? You can't please everyone, and ultimately it's...
• David B. Held (130/142) May 28 2007 A blog is an interesting idea, but Walter doesn't strike me as the
• Sean Kelly (6/9) May 28 2007 One could argue that Ada is such a language, and it's really pretty nice...
• David B. Held (17/26) May 28 2007 I actually used it in college because that's what my school taught for
• Bent Rasmussen (8/145) May 28 2007 Now that's one serious argument! It's actually strange how several langu...
• Don Clugston (14/35) May 29 2007 I agree. But I think the point was, that it would be nice to have *some
• Bruno Medeiros (16/177) May 30 2007 Nice post, I agree. However I also think that some language issues
• David B. Held (66/79) May 30 2007 I think if you have actual code where you can point to it and say: "In
• Sean Kelly (31/74) May 30 2007 Personally, when writing libraries if I discover that feature X would
• David B. Held (14/23) May 30 2007 The problem with talking about features abstractly is that it's hard to
• Sean Kelly (3/16) May 31 2007 Bah. The Tacoma Narrows Bridge was a fluke ;-)
• Bruno Medeiros (94/178) Jun 01 2007 I must contend against that. I would say most of D users (on the NG at
• Walter Bright (8/16) Jun 02 2007 It'll be an error, since there's no way to deduce the type of foo. But
• Bruno Medeiros (25/39) Jun 02 2007 Duh, yes, I forgot the type.
• David B. Held (7/27) Jun 02 2007 I think that Walter's scenario must type to const(int)*, for
• Bruno Medeiros (15/45) Jun 02 2007 Hum, you're right, it should type to const instead of invariant, I
• David B. Held (6/14) Jun 02 2007 Can you produce a realistic scenario where you need to take a pointer to...
• Bruno Medeiros (16/32) Jun 06 2007 Well, I wasn't saying that this is a terrible problem, for now I was
• Walter Bright (4/15) Jun 02 2007 final is not a type constructor, it is a storage class. And no, you
• Bruno Medeiros (5/21) Jun 02 2007 I should have clarified, Foo there is supposed to be a class, not a stru...
• Walter Bright (2/21) Jun 02 2007 You can still change the members of a final class instance.
• Bruno Medeiros (10/33) Jun 06 2007 I know I can change the members of a final class, if I use the class
• Walter Bright (2/8) Jun 06 2007 Yes.
• Walter Bright (4/6) May 30 2007 That's one reason why we'll be having the D conference in August. I'll
• Derek Parnell (8/9) May 30 2007 You say that now ...
• Jarrett Billingsley (3/7) May 31 2007 And so do I :S

Bill Baxter <dnewsgroup billbaxter.com> writes:

What's the deal with making iterators be classes in D, rather than 
simple value types like they are in C++?  I see that tango uses classes, 
and DTL used them too.  Chris commented over on the Tango forum that 
"there are problems with using structs".  So what are they?

The way people describe iterators in C++ is as a generalization of a 
pointer.  Including the fact that they are value types and can be 
copied.  DTL and tango iterators can't even be copied at all.  Just 
seems like a struct makes more sense for an iterator in D.

--bb

"David B. Held" <dheld codelogicconsulting.com> writes:

Bill Baxter wrote:
 What's the deal with making iterators be classes in D, rather than 
 simple value types like they are in C++?  I see that tango uses classes, 
 and DTL used them too.  Chris commented over on the Tango forum that 
 "there are problems with using structs".  So what are they?
 
 The way people describe iterators in C++ is as a generalization of a 
 pointer.  Including the fact that they are value types and can be 
 copied.  DTL and tango iterators can't even be copied at all.  Just 
 seems like a struct makes more sense for an iterator in D.

Iterators should almost certainly be value types (structs).  The 
problems are that structs currently don't have c'tors/d'tors nor do they 
have a fully useful copy c'tor.  However, both are planned for inclusion.

Dave

Bill Baxter <dnewsgroup billbaxter.com> writes:

David B. Held wrote:
 Bill Baxter wrote:
 What's the deal with making iterators be classes in D, rather than 
 simple value types like they are in C++?  I see that tango uses 
 classes, and DTL used them too.  Chris commented over on the Tango 
 forum that "there are problems with using structs".  So what are they?

 The way people describe iterators in C++ is as a generalization of a 
 pointer.  Including the fact that they are value types and can be 
 copied.  DTL and tango iterators can't even be copied at all.  Just 
 seems like a struct makes more sense for an iterator in D.

 
 Iterators should almost certainly be value types (structs).  The 
 problems are that structs currently don't have c'tors/d'tors nor do they 
 have a fully useful copy c'tor.  However, both are planned for inclusion.

Hmm, I can't think of a case where any of that would matter.
Looking at a few DTL iterators, none of them seem to contain anything 
that couldn't be done with static opCall.  I do see a somewhat dubious 
constructor in stack.d, however:

         this(value_type[] elements, index_type position)
         {
             m_position  =   position;
             m_elements  =   elements[position .. elements.length];
         }

This sets the size_t m_position to 10, say, but that becomes position 
zero in the slice m_elements.  Looks like a bug to me.

And classes don't have fully useful copy c'tors either, so you can't 
really hold that against structs.

The only think I've thought of (and this is probably Tango's main 
justification for classes) is that structs can't inherit.

--bb

"David B. Held" <dheld codelogicconsulting.com> writes:

Bill Baxter wrote:
 [...]
 And classes don't have fully useful copy c'tors either, so you can't 
 really hold that against structs.

Classes have reference semantics, so you need to implement a clone() 
method if you want deep copies.  Value types need to support 
copy/assign/swap as first-class operations.

 [...]
 The only think I've thought of (and this is probably Tango's main 
 justification for classes) is that structs can't inherit.

There is some talk about allowing structs to implement interfaces, but 
that is a technically non-trivial change.

Dave

Bill Baxter <dnewsgroup billbaxter.com> writes:

David B. Held wrote:
 Bill Baxter wrote:
 [...]
 And classes don't have fully useful copy c'tors either, so you can't 
 really hold that against structs.

 
 Classes have reference semantics, so you need to implement a clone() 
 method if you want deep copies.  Value types need to support 
 copy/assign/swap as first-class operations.

Ok, the way you said it before made it sound like you were arguing 
structs were no good for iterators because they can't do anything more 
than a bitwise copy.  But you were actually saying classes are no good 
for iterators because they can't be given value semantics.  Gotcha.

 [...]
 The only think I've thought of (and this is probably Tango's main 
 justification for classes) is that structs can't inherit.

 
 There is some talk about allowing structs to implement interfaces, but 
 that is a technically non-trivial change.

I'm struggling here.  I'm feeling the void when it comes to iterators in 
D, but none of the solutions I've seen implemented really resonate with 
me.  I'm not sure whether it's me, or the libraries, or D that need to 
change.  But I like my iterators to be value types, darnit.  :-)

--bb

"David B. Held" <dheld codelogicconsulting.com> writes:

Bill Baxter wrote:
 [...]
 I'm struggling here.  I'm feeling the void when it comes to iterators in 
 D, but none of the solutions I've seen implemented really resonate with 
 me.  I'm not sure whether it's me, or the libraries, or D that need to 
 change.  But I like my iterators to be value types, darnit.  :-)

The language definitely needs to change, and fixing structs to be on par 
with C++ is actually a priority for Walter.  However, finishing 
const/final/invariant comes first.

Dave

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"David B. Held" <dheld codelogicconsulting.com> wrote in message 
news:f3e2ji$2h7$2 digitalmars.com...
 The language definitely needs to change, and fixing structs to be on par 
 with C++ is actually a priority for Walter.

Through what mystical channels of communication do you obtain such 
information?  I've always found it rather disconcerting that no one knows 
what's on Walter's mind until one of a select few people talk about it on 
the NG as if everyone knew about it.  I never seem to hear Walter's opinions 
and plans from Walter. 

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Jarrett Billingsley wrote:
 "David B. Held" <dheld codelogicconsulting.com> wrote in message 
 news:f3e2ji$2h7$2 digitalmars.com...
 The language definitely needs to change, and fixing structs to be on par 
 with C++ is actually a priority for Walter.

 
 Through what mystical channels of communication do you obtain such 
 information?  I've always found it rather disconcerting that no one knows 
 what's on Walter's mind until one of a select few people talk about it on 
 the NG as if everyone knew about it.  I never seem to hear Walter's opinions 
 and plans from Walter. 

IIRC David talks to Alexei (and Walter?) IRL...

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
news:f3eond$146l$1 digitalmars.com...

 IIRC David talks to Alexei (and Walter?) IRL...

That's good to know, but it would be _fantastic_ if the results of their 
little brainstorming sessions were made public, or if the sessions 
themselves were.  It's very frustrating that this tiny core group of people 
is driving the development of D with little to no interaction with the rest 
of the users.  Don't get me wrong -- I really like that structs are being 
improved, I just don't like being in the dark, and I would imagine few 
people do. 

"David B. Held" <dheld codelogicconsulting.com> writes:

Jarrett Billingsley wrote:
 "Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
 news:f3eond$146l$1 digitalmars.com...
 
 IIRC David talks to Alexei (and Walter?) IRL...

 
 That's good to know, but it would be _fantastic_ if the results of their 
 little brainstorming sessions were made public, or if the sessions 
 themselves were.  It's very frustrating that this tiny core group of people 
 is driving the development of D with little to no interaction with the rest 
 of the users.  Don't get me wrong -- I really like that structs are being 
 improved, I just don't like being in the dark, and I would imagine few 
 people do. 

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

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.

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.

Dave

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

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

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

"David B. Held" <dheld codelogicconsulting.com> writes:

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 

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

Sean Kelly <sean f4.ca> writes:

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

"David B. Held" <dheld codelogicconsulting.com> writes:

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

"Bent Rasmussen" <incredibleshrinkingsphere gmail.com> writes:

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 

 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 

Don Clugston <dac nospam.com.au> writes:

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

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

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 

 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

"David B. Held" <dheld codelogicconsulting.com> writes:

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

Sean Kelly <sean f4.ca> writes:

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

"David B. Held" <dheld codelogicconsulting.com> writes:

Sean Kelly wrote:
 [...]
 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.
 [...]

The problem with talking about features abstractly is that it's hard to 
judge how necessary or compelling the feature is without the context of 
real examples.  Motivating use cases give hints as to whether the 
feature will only be used in obscure code, whether the feature could be 
easily simulated with an alternative, or whether it's something that you 
could imagine lots of other people running into.  So even though 
academically, it is better to reason about things abstractly, compiler 
design is not an academic pursuit; it's an engineering one.  And 
engineers are better off seeing how a bridge sways in the wind or under 
the feet of pedestrians than modeling it and theorizing about its 
properties abstractly.  When they stick with the abstract, they are 
often surprised by the details of reality.

Dave

Sean Kelly <sean f4.ca> writes:

David B. Held wrote:
 
 The problem with talking about features abstractly is that it's hard to 
 judge how necessary or compelling the feature is without the context of 
 real examples.  Motivating use cases give hints as to whether the 
 feature will only be used in obscure code, whether the feature could be 
 easily simulated with an alternative, or whether it's something that you 
 could imagine lots of other people running into.  So even though 
 academically, it is better to reason about things abstractly, compiler 
 design is not an academic pursuit; it's an engineering one.  And 
 engineers are better off seeing how a bridge sways in the wind or under 
 the feet of pedestrians than modeling it and theorizing about its 
 properties abstractly.  When they stick with the abstract, they are 
 often surprised by the details of reality.

Bah.  The Tacoma Narrows Bridge was a fluke ;-)


Sean

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

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

Walter Bright <newshound1 digitalmars.com> writes:

Bruno Medeiros wrote:
 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.

It'll be an error, since there's no way to deduce the type of foo. But 
let's rewrite it as:
	final int foo;
	auto fooptr = &foo;
Since foo cannot change its value, then fooptr must be an invariant(int)*.


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

It's written on paper, but not implemented. Designs have a way of 
morphing when they are actually implemented.

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

Walter Bright wrote:
 Bruno Medeiros wrote:
 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.

 
 It'll be an error, since there's no way to deduce the type of foo. But 
 let's rewrite it as:
     final int foo;
     auto fooptr = &foo;
 Since foo cannot change its value, then fooptr must be an invariant(int)*.
 
 

Duh, yes, I forgot the type.
Anyways, you've said before that invariant, like const, only applies to 
referenced data, and not to the immediate value. Such that const or 
invariant on primitive types has no effect:
   const int a;  // no effect, same as a normal int.
If that is the case, then do invariant(int) and invariant(const), as in 
the fooptr example above, have different semantics? Do they apply to the 
immediate value when used with that parenthesis syntax? Meaning that the 
following two vars would have different constraints? :
   invariant(int) i1;
   invariant int  i2;

Second, let's change the first example, let's have a Foo instead of an int:
    final Foo foo;
    auto fooptr = &foo;
What would be the type of fooptr?  Would it also be invariant(Foo)* ?
What would be the type of *fooptr? Would it be invariant(Foo) ?
If so, would that mean that the following would not be allowed:
   (*fooptr).membervar = 42 ;
even though this is:
   foo.membervar = 42;
?


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

"David B. Held" <dheld codelogicconsulting.com> writes:

Bruno Medeiros wrote:
 Walter Bright wrote:
 [...]
 It'll be an error, since there's no way to deduce the type of foo. But 
 let's rewrite it as:
     final int foo;
     auto fooptr = &foo;
 Since foo cannot change its value, then fooptr must be an 
 invariant(int)*.

 
 [...]
 Second, let's change the first example, let's have a Foo instead of an int:
    final Foo foo;
    auto fooptr = &foo;
 What would be the type of fooptr?  Would it also be invariant(Foo)* ?
 What would be the type of *fooptr? Would it be invariant(Foo) ?
 If so, would that mean that the following would not be allowed:
   (*fooptr).membervar = 42 ;
 even though this is:
   foo.membervar = 42;
 ?

I think that Walter's scenario must type to const(int)*, for 
consistency, even though const(int)* and invariant(int)* are equivalent, 
given that int is an elementary value type.  This leads to the proper 
conclusion that typeof(fooptr) == const(Foo)*, typeof(*fooptr) == 
const(Foo).

Dave

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

David B. Held wrote:
 Bruno Medeiros wrote:
 Walter Bright wrote:
 [...]
 It'll be an error, since there's no way to deduce the type of foo. 
 But let's rewrite it as:
     final int foo;
     auto fooptr = &foo;
 Since foo cannot change its value, then fooptr must be an 
 invariant(int)*.

 [...]
 Second, let's change the first example, let's have a Foo instead of an 
 int:
    final Foo foo;
    auto fooptr = &foo;
 What would be the type of fooptr?  Would it also be invariant(Foo)* ?
 What would be the type of *fooptr? Would it be invariant(Foo) ?
 If so, would that mean that the following would not be allowed:
   (*fooptr).membervar = 42 ;
 even though this is:
   foo.membervar = 42;
 ?

 
 I think that Walter's scenario must type to const(int)*, for 
 consistency, even though const(int)* and invariant(int)* are equivalent, 
 given that int is an elementary value type.  This leads to the proper 
 conclusion that typeof(fooptr) == const(Foo)*, typeof(*fooptr) == 
 const(Foo).
 
 Dave

Hum, you're right, it should type to const instead of invariant, I 
totally missed that. However I missed because I'm trying to look into 
another issue, what I really want to know is if the full type of 
(*(&foo)) will be the same as (foo), and so far it seems not, according 
to what Walter's said. So
   typeof(foo) is:  final Foo
but
   typeof(*(&foo)) is:  const(Foo)
which seems a breach in orthogonality, and meaning that this won't be 
allowed:
   (*(&foo)).membervar = 42;

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

"David B. Held" <dheld codelogicconsulting.com> writes:

Bruno Medeiros wrote:
 [...]
 So
   typeof(foo) is:  final Foo
 but
   typeof(*(&foo)) is:  const(Foo)
 which seems a breach in orthogonality, and meaning that this won't be 
 allowed:
   (*(&foo)).membervar = 42;

Can you produce a realistic scenario where you need to take a pointer to 
a final and get back the exact type?  Most of the time, you shouldn't 
even need to take addresses in D.  Most uses of pointers is with dynamic 
allocation.

Dave

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

David B. Held wrote:
 Bruno Medeiros wrote:
 [...]
 So
   typeof(foo) is:  final Foo
 but
   typeof(*(&foo)) is:  const(Foo)
 which seems a breach in orthogonality, and meaning that this won't be 
 allowed:
   (*(&foo)).membervar = 42;

 
 Can you produce a realistic scenario where you need to take a pointer to 
 a final and get back the exact type?  Most of the time, you shouldn't 
 even need to take addresses in D.  Most uses of pointers is with dynamic 
 allocation.
 
 Dave

Well, I wasn't saying that this is a terrible problem, for now I was 
just confirming if this indeed happens with the planned design.

Still, I do have a feeling that it might cause some problems, altough I 
can't think of any concrete scenario right now (which doesn't mean there 
is one). For example, advanced type-generic templates usually get more 
complicated because of special and nonorthogonal cases. I've heard 
people say they had some inconveniences (don't know how severe they were 
though) because typeof(T) == typeof(T.init) is true for all types, 
*except* static arrays.
Similarly, problems might arise because:
   typeof(*(&something)) == typeof(something)
is true for all vars, except those that are final.

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

Walter Bright <newshound1 digitalmars.com> writes:

Bruno Medeiros wrote:
 Hum, you're right, it should type to const instead of invariant, I 
 totally missed that. However I missed because I'm trying to look into 
 another issue, what I really want to know is if the full type of 
 (*(&foo)) will be the same as (foo), and so far it seems not, according 
 to what Walter's said. So
   typeof(foo) is:  final Foo
 but
   typeof(*(&foo)) is:  const(Foo)
 which seems a breach in orthogonality, and meaning that this won't be 
 allowed:
   (*(&foo)).membervar = 42;

final is not a type constructor, it is a storage class. And no, you 
won't be able to change the contents of an instance of a final struct, 
even if you do machinations to do so.

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

Walter Bright wrote:
 Bruno Medeiros wrote:
 Hum, you're right, it should type to const instead of invariant, I 
 totally missed that. However I missed because I'm trying to look into 
 another issue, what I really want to know is if the full type of 
 (*(&foo)) will be the same as (foo), and so far it seems not, 
 according to what Walter's said. So
   typeof(foo) is:  final Foo
 but
   typeof(*(&foo)) is:  const(Foo)
 which seems a breach in orthogonality, and meaning that this won't be 
 allowed:
   (*(&foo)).membervar = 42;

 
 final is not a type constructor, it is a storage class. And no, you 
 won't be able to change the contents of an instance of a final struct, 
 even if you do machinations to do so.

I should have clarified, Foo there is supposed to be a class, not a struct.

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

Walter Bright <newshound1 digitalmars.com> writes:

Bruno Medeiros wrote:
 Walter Bright wrote:
 Bruno Medeiros wrote:
 Hum, you're right, it should type to const instead of invariant, I 
 totally missed that. However I missed because I'm trying to look into 
 another issue, what I really want to know is if the full type of 
 (*(&foo)) will be the same as (foo), and so far it seems not, 
 according to what Walter's said. So
   typeof(foo) is:  final Foo
 but
   typeof(*(&foo)) is:  const(Foo)
 which seems a breach in orthogonality, and meaning that this won't be 
 allowed:
   (*(&foo)).membervar = 42;

 final is not a type constructor, it is a storage class. And no, you 
 won't be able to change the contents of an instance of a final struct, 
 even if you do machinations to do so.

 
 I should have clarified, Foo there is supposed to be a class, not a struct.

You can still change the members of a final class instance.

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

Walter Bright wrote:
 Bruno Medeiros wrote:
 Walter Bright wrote:
 Bruno Medeiros wrote:
 Hum, you're right, it should type to const instead of invariant, I 
 totally missed that. However I missed because I'm trying to look 
 into another issue, what I really want to know is if the full type 
 of (*(&foo)) will be the same as (foo), and so far it seems not, 
 according to what Walter's said. So
   typeof(foo) is:  final Foo
 but
   typeof(*(&foo)) is:  const(Foo)
 which seems a breach in orthogonality, and meaning that this won't 
 be allowed:
   (*(&foo)).membervar = 42;

 final is not a type constructor, it is a storage class. And no, you 
 won't be able to change the contents of an instance of a final 
 struct, even if you do machinations to do so.

 I should have clarified, Foo there is supposed to be a class, not a 
 struct.

 
 You can still change the members of a final class instance.

I know I can change the members of a final class, if I use the class 
reference directly (like "foo.membervar = 42"). However it seems that 
with that design, if one uses (*(&foo)) one won't be able to change the 
members of (*(&foo)) , as in "(*(&foo)).membervar = 42", even tough foo 
is conceptually the same as (*(&foo)). I was just checking if you 
recognized that this happens.

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

Walter Bright <newshound1 digitalmars.com> writes:

Bruno Medeiros wrote:
 I know I can change the members of a final class, if I use the class 
 reference directly (like "foo.membervar = 42"). However it seems that 
 with that design, if one uses (*(&foo)) one won't be able to change the 
 members of (*(&foo)) , as in "(*(&foo)).membervar = 42", even tough foo 
 is conceptually the same as (*(&foo)). I was just checking if you 
 recognized that this happens.

Yes.

Walter Bright <newshound1 digitalmars.com> writes:

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

That's one reason why we'll be having the D conference in August. I'll 
be there, so will Andrei, and I think David, too. You'll be able to bend 
all our ears. I'm looking forward to it!

Derek Parnell <derek psych.ward> writes:

On Wed, 30 May 2007 15:09:48 -0700, Walter Bright wrote:

 You'll be able to bend all our ears. I'm looking forward to it!

You say that now ... <G>

Damn I wish I could be there.
-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Derek Parnell" <derek psych.ward> wrote in message 
news:w6lhuw2k8eeu$.1b5hdec4p7dxw$.dlg 40tude.net...
 On Wed, 30 May 2007 15:09:48 -0700, Walter Bright wrote:

 You'll be able to bend all our ears. I'm looking forward to it!

 You say that now ... <G>

 Damn I wish I could be there.

And so do I :S