import concerns (was Re: Historical language survey)

[Walter Bright]

John Reimer wrote:
> The use of "alias" still looks like a hack.  We know you've always been firm in
> your belief that "alias" is the way to do it.  I doubt that all these people
> would be discussing options here if they were satisfied with that solution
> (which has been around for a looong time).
> 
> We know it can be done with alias. Kris knows. We don't think it's good enough.
> That's why this whole topic is being wrangled.  
> 
> So if you choose to make the internal machinery do it with alias, fine!  We just
> want something that's better, nicer, more professional looking! :) (please not
> "static import," though).

What I don't get is what is "unprofessional" or hackish about alias? Is 
it (as I posted to Kris) that it looks too much like #define?


> While I do agree that D would suffer if you followed the communities whim for
> every little feature suggested, yet I think you are far too independent minded
> most of the time.  The quote in your recent interview at Bitwise -- "D is going
> wherever the D community wants it to go" -- is really a farce.  D is going where
> /you/ want it to go, Walter.

If it was only what I wanted, there'd be exactly one D user - me. D 
really is a community effort, and it really does go where the community 
wants it to go (although it may not seem that way at times). Every day, 
and I mean every day, there are feature proposals. I have no choice but 
to say "no" to 99% of them, which sure comes off as me sounding like 
Negative Nellie or Dr. No.

This is despite the fact that many of them are incredibly good ideas, 
like Don's idea on temporaries.

Each idea goes through a gauntlet of:
1) is lack of this idea turning users away from D
2) how much power it adds
3) how much complexity it adds
4) is it consistent with the rest of D
5) how hard is it to implement
6) how does it rank in importance against all the other ideas

Here's one example: I'm not personally enamored with inner classes. 
There are better ways to do the same thing. But Kris made a compelling 
argument that supporting inner classes would open the door wide to mass 
conversion of Java code to D. That's a lot of leverage for a fairly 
modest implementation effort.


> And there's nothing wrong with admitting that.  I just think a honesty is
> important here.  This is your language.  You've made that very plain over the
> years, and most of us who have stuck around have accepted that. You strongly
> disfavour committees and bureaucracy, which is completely understandable; but,
> your over-protectiveness and fear of them may be doing the same sort of damage
> on the opposite end of the spectrum.

Sure, at the moment I make the final decisions. But that only is 
possible because the D community suffers me to do it. If I cease to act 
in the best interests of the D community, then the community can easily 
take D off in their own direction (D is GPL).

> Don't take this wrong:  I'm very thankful about all you've done with D; I just
> get a little frustrated at how hard you are to convince of anything, a trait
> that may do well for you in some ways but probably hurts you so much more in
> other ways.

Being hard to convince is the only practical way to find the 1% that 
must be done out of the 99% that I am forced to say no to.

P.S. If you think I'm hard to convince, try convincing the C++ standards 
committee of something <g>.

P.P.S. Don't think of it as just convincing me. You have to make an 
argument that is compelling to current and potential future users of D. 
The latter group is predisposed to be very skeptical about new 
languages. I've seen them in the audience of my talks, with arms crossed 
and head back. I have to present a pretty darned convincing case to get 
their attention.