A few "reality-check" questions and suggestions:

`1.  Is this language and this website ready to entertain a 10X to 100X jump in traffic - bugs, questions/bugs, questions/info, argumentation about features, etc by next summer?

2.  I think the language is generally well-defined, but I would hate to have it lock-in upward compatibility as a requirement yet.

3.  Is there any direct support for Walter for bugfixes and feature enhancements to handle a lot of yelping would-be users?

4.  Should the phobos limitations be dealt with immediately?  How about startng multiple libraries beyond just phobos to classify, accept, distribute user submissions?  They should have varying degrees of stability required for inclusion, and therefore "officialness".  Incidentally, phobos MUST be split into basic and OS-dependent libraries, or linux and Solaris and MacOS and ... are going to become a quick hell.  I have tried to research this back a bit, but I don't see any benefit to mixing basic and OS-dependent stuff in a single library except that it has been easier to just maintain a single lib.  This is not likely to be the case any more.

4.  There should be a drop point other than this list (or email to Walter) for contributions of fixes, doc-changes, compiler addins, library addins, specialized libraries or programs.  If it's not standardized as a method now, a whole crop of supporting sites with conflicting versions of the same things may well arise.  This would not show D well to potential new users, and ALL companies will want "the official versions" - pissing off all concerned.  CVS has been mentioned, as SourceForge or other - doesn't matter where, Mars or elsewhere, but the process needs a home.  More than it needs bosses, Lars, but that will be needed too - hopefully as welcoming and non-authoritarian as possible.  We need knowledgeable people in control, but ones with the time (not me, I'm afraid) to keep things moving well.  Hopefully not too much "process" or red-tape - at least for a while yet.

5.  There probably should be a feature requests vs. status list somewhere centralized and accessible.   Bugzilla possibly, or a Wiki with some locked pages as well as open ones, or ???  Would be nice if something similar for bugs vs. fixes status.  The traffic on these will likely not be handled well by the message list, and anyway it's hard to see what has already been proposed or submitted, and what the response was.  Having a central status viewing point does not prevent us from requesting a post to the message list about new entries and/or discussions there.

6.  The news-group stuff should be pursued, but I agree completely that it's a not-until-full-status-can-be-attained thing.

7.  I hate formality, but love appropriate support for appropriate processes. It's a fine line between doing what is needed and establishing unnecessary rules.  Let's keep this as open, fair, and productive as possible.

-larry

D should have 100% source code compatibility between different operating systems, like Java. Implementation and O/S details must be hidden under the libraries. This is what is the major C++ problem. Having to write once, run everywhere (or rather, compile everywhere in D's case) is what made Java a huge success (and the sheer amount of existing libraries).

"larry cowan" <larry_member@pathlink.com> wrote in message news:c00vhs$24aq$1@digitaldaemon.com...
> A few "reality-check" questions and suggestions:
>
> `1.  Is this language and this website ready to entertain a 10X to 100X
jump in
> traffic - bugs, questions/bugs, questions/info, argumentation about
features,
> etc by next summer?
>
> 2.  I think the language is generally well-defined, but I would hate to
have it
> lock-in upward compatibility as a requirement yet.
>
> 3.  Is there any direct support for Walter for bugfixes and feature
enhancements
> to handle a lot of yelping would-be users?
>
> 4.  Should the phobos limitations be dealt with immediately?  How about
startng
> multiple libraries beyond just phobos to classify, accept, distribute user submissions?  They should have varying degrees of stability required for inclusion, and therefore "officialness".  Incidentally, phobos MUST be
split
> into basic and OS-dependent libraries, or linux and Solaris and MacOS and
...
> are going to become a quick hell.  I have tried to research this back a
bit, but
> I don't see any benefit to mixing basic and OS-dependent stuff in a single library except that it has been easier to just maintain a single lib.
This is
> not likely to be the case any more.
>
> 4.  There should be a drop point other than this list (or email to Walter)
for
> contributions of fixes, doc-changes, compiler addins, library addins, specialized libraries or programs.  If it's not standardized as a method
now, a
> whole crop of supporting sites with conflicting versions of the same
things may
> well arise.  This would not show D well to potential new users, and ALL companies will want "the official versions" - pissing off all concerned.
CVS
> has been mentioned, as SourceForge or other - doesn't matter where, Mars
or
> elsewhere, but the process needs a home.  More than it needs bosses, Lars,
but
> that will be needed too - hopefully as welcoming and non-authoritarian as possible.  We need knowledgeable people in control, but ones with the time
(not
> me, I'm afraid) to keep things moving well.  Hopefully not too much
"process" or
> red-tape - at least for a while yet.
>
> 5.  There probably should be a feature requests vs. status list somewhere centralized and accessible.   Bugzilla possibly, or a Wiki with some
locked
> pages as well as open ones, or ???  Would be nice if something similar for
bugs
> vs. fixes status.  The traffic on these will likely not be handled well by
the
> message list, and anyway it's hard to see what has already been proposed
or
> submitted, and what the response was.  Having a central status viewing
point
> does not prevent us from requesting a post to the message list about new
entries
> and/or discussions there.
>
> 6.  The news-group stuff should be pursued, but I agree completely that
it's a
> not-until-full-status-can-be-attained thing.
>
> 7.  I hate formality, but love appropriate support for appropriate
processes.
> It's a fine line between doing what is needed and establishing unnecessary rules.  Let's keep this as open, fair, and productive as possible.
>
> -larry
>
>

"larry cowan" <larry_member@pathlink.com> wrote in message news:c00vhs$24aq$1@digitaldaemon.com...
> A few "reality-check" questions and suggestions:
>
> `1.  Is this language and this website ready to entertain a 10X to 100X
jump in
> traffic - bugs, questions/bugs, questions/info, argumentation about
features,
> etc by next summer?

Yes. It's done fine even during two slashdottings. Jan Knepper's company hosts the server, which has survived viral attacks, slashdottings, power failures, and at least one assault from the 7th dimension. Rumor has it that during the last slashdotting, the glow from the data pipe feeding it turned night into day.

> 2.  I think the language is generally well-defined, but I would hate to
have it
> lock-in upward compatibility as a requirement yet.

1.0 is going to happen shortly.

> 3.  Is there any direct support for Walter for bugfixes and feature
enhancements
> to handle a lot of yelping would-be users?

Not sure what you mean here.

> 4.  Should the phobos limitations be dealt with immediately?  How about
startng
> multiple libraries beyond just phobos to classify, accept, distribute user submissions?  They should have varying degrees of stability required for inclusion, and therefore "officialness".  Incidentally, phobos MUST be
split
> into basic and OS-dependent libraries, or linux and Solaris and MacOS and
...
> are going to become a quick hell.  I have tried to research this back a
bit, but
> I don't see any benefit to mixing basic and OS-dependent stuff in a single library except that it has been easier to just maintain a single lib.
This is
> not likely to be the case any more.
>
> 4.  There should be a drop point other than this list (or email to Walter)
for
> contributions of fixes, doc-changes, compiler addins, library addins, specialized libraries or programs.  If it's not standardized as a method
now, a
> whole crop of supporting sites with conflicting versions of the same
things may
> well arise.  This would not show D well to potential new users, and ALL companies will want "the official versions" - pissing off all concerned.
CVS
> has been mentioned, as SourceForge or other - doesn't matter where, Mars
or
> elsewhere, but the process needs a home.  More than it needs bosses, Lars,
but
> that will be needed too - hopefully as welcoming and non-authoritarian as possible.  We need knowledgeable people in control, but ones with the time
(not
> me, I'm afraid) to keep things moving well.  Hopefully not too much
"process" or
> red-tape - at least for a while yet.
>
> 5.  There probably should be a feature requests vs. status list somewhere centralized and accessible.   Bugzilla possibly, or a Wiki with some
locked
> pages as well as open ones, or ???  Would be nice if something similar for
bugs
> vs. fixes status.  The traffic on these will likely not be handled well by
the
> message list, and anyway it's hard to see what has already been proposed
or
> submitted, and what the response was.  Having a central status viewing
point
> does not prevent us from requesting a post to the message list about new
entries
> and/or discussions there.
>
> 6.  The news-group stuff should be pursued, but I agree completely that
it's a
> not-until-full-status-can-be-attained thing.
>
> 7.  I hate formality, but love appropriate support for appropriate
processes.
> It's a fine line between doing what is needed and establishing unnecessary rules.  Let's keep this as open, fair, and productive as possible.

Something like that will have to be done in the fugure. The current process, while a bit chaotic and random, seems to be serving reasonably well at the moment.

You bring up some important points. Reply embedded...

larry cowan wrote:
> A few "reality-check" questions and suggestions:
> 
> `1.  Is this language and this website ready to entertain a 10X to 100X jump in
> traffic - bugs, questions/bugs, questions/info, argumentation about features,
> etc by next summer?

I hope so.

It seems like there's been a lot of see-how-I-made-the-compiler-fail messages recently. I think these posts are made in good faith.

When I first started following this newsgroup many, many months ago, I got the impression that many of the posters didn't actually try out the compiler. There was a lot of discussion about which features would be included in the ultimate programming languge.

Now, people are actually trying to do things in D. So we post more messages trying to help Walter squash bugs by showing weaknesses in the compiler.

Fortunately, this newsgroup is basically troll-free. Sometimes there's a disagreement about how much the compiler should hold the programmer's hand, but there are a lot of knowledgeable folks around here who want D to succeed. And I think newbies are treated pretty well.


> 2.  I think the language is generally well-defined, but I would hate to have it
> lock-in upward compatibility as a requirement yet.

You probably need bring up your specific crticisms ASAP if you want Walter to slow down (or back up). I've already brought up my specific issues with D.


> 3.  Is there any direct support for Walter for bugfixes and feature enhancements
> to handle a lot of yelping would-be users?

He sometimes replies that he'll fix stuff. When he does fix it, he replies to the bug author (and sometimes the newsgroup) that it's fixed. Walter would rather spend time improving D that talking about how he's going to improve D.


> 4.  Should the phobos limitations be dealt with immediately?  How about startng
> multiple libraries beyond just phobos to classify, accept, distribute user
> submissions?  They should have varying degrees of stability required for
> inclusion, and therefore "officialness".  Incidentally, phobos MUST be split
> into basic and OS-dependent libraries, or linux and Solaris and MacOS and ...
> are going to become a quick hell.  I have tried to research this back a bit, but
> I don't see any benefit to mixing basic and OS-dependent stuff in a single
> library except that it has been easier to just maintain a single lib.  This is
> not likely to be the case any more. 

I disaggree.

It's one lib of source code, but it's compiled twice. One of the goals of D is to be cross-platform. It's hard to have a strong cross-platform library if all of the OS-dependent stuff is removed.  Really, what would be left of phobos? Just std.string?


> 4.  There should be a drop point other than this list (or email to Walter) for
> contributions of fixes, doc-changes, compiler addins, library addins,
> specialized libraries or programs.  If it's not standardized as a method now, a
> whole crop of supporting sites with conflicting versions of the same things may
> well arise.  This would not show D well to potential new users, and ALL
> companies will want "the official versions" - pissing off all concerned.  CVS
> has been mentioned, as SourceForge or other - doesn't matter where, Mars or
> elsewhere, but the process needs a home.  More than it needs bosses, Lars, but
> that will be needed too - hopefully as welcoming and non-authoritarian as
> possible.  We need knowledgeable people in control, but ones with the time (not
> me, I'm afraid) to keep things moving well.  Hopefully not too much "process" or
> red-tape - at least for a while yet.

This is a weakness in the state of D right now.  I think an even more pressing problem is all of the "stale" code out there (e.g. it worked great with DMD 0.69, but won't even compile since phobos got re-arranged in DMD 0.75). We probably should include a version number and date when we upload code to a website (so if we fall behind with D updates at least a person can tell before he downloads the whole thing).


> 5.  There probably should be a feature requests vs. status list somewhere
> centralized and accessible.   Bugzilla possibly, or a Wiki with some locked
> pages as well as open ones, or ???  Would be nice if something similar for bugs
> vs. fixes status.  The traffic on these will likely not be handled well by the
> message list, and anyway it's hard to see what has already been proposed or
> submitted, and what the response was.  Having a central status viewing point
> does not prevent us from requesting a post to the message list about new entries
> and/or discussions there.

I think Bugzilla would be great. I think Walter has some concerns that the Anti-D Militia would make announcements like "look how many unresolved bugs has! Oh, the horror!" (When in reality, their favorite language has many bugs, but their vendor sweeps all the bugs underneath the rug.)

There's already a Wiki page set up (it's all open) relating to requested features: http://www.wikiservice.at/d/wiki.cgi?FeatureRequestList

It's basically a list of some common (and not-so-common) requests with a link to the newsgroup post where it was requested. I've put some similiar pages on the Wiki for topics that come up repeatedly so that we don't necessarily have the same discussions over and over again.

It's a Wiki, so anyone and everyone is encouraged to expand and revise these pages to improve them.


> 6.  The news-group stuff should be pursued, but I agree completely that it's a
> not-until-full-status-can-be-attained thing.

The world needs news:comp.lang.d.

> 7.  I hate formality, but love appropriate support for appropriate processes.
> It's a fine line between doing what is needed and establishing unnecessary
> rules.  Let's keep this as open, fair, and productive as possible.

Yes.

> 
> -larry
> 
> 


-- 
Justin
http://jcc_7.tripod.com/d/

> I think Bugzilla would be great. I think Walter has some concerns that the Anti-D Militia would make announcements like "look how many unresolved bugs has! Oh, the horror!" (When in reality, their favorite language has many bugs, but their vendor sweeps all the bugs underneath the rug.)

So true ... and most times they dont even think its a bug just a language restriction ( or a "Thats a poor design" , when most likely , their language is incapable of implementing it , and they cant see past their own noses ) In my D advocacy , ive run into so many people who just refuse to try anything new or keep an open mind , its sad and depressing.  There arguing against me , never even having tried the language ... , I tell them to just try it they'll love it , but they just flat refuse.  So sad.

C

"J C Calvarese" <jcc7@cox.net> wrote in message news:c01fje$31d7$1@digitaldaemon.com...
> You bring up some important points. Reply embedded...
>
> larry cowan wrote:
> > A few "reality-check" questions and suggestions:
> >
> > `1.  Is this language and this website ready to entertain a 10X to 100X
jump in
> > traffic - bugs, questions/bugs, questions/info, argumentation about
features,
> > etc by next summer?
>
> I hope so.
>
> It seems like there's been a lot of see-how-I-made-the-compiler-fail messages recently. I think these posts are made in good faith.
>
> When I first started following this newsgroup many, many months ago, I got the impression that many of the posters didn't actually try out the compiler. There was a lot of discussion about which features would be included in the ultimate programming languge.
>
> Now, people are actually trying to do things in D. So we post more messages trying to help Walter squash bugs by showing weaknesses in the compiler.
>
> Fortunately, this newsgroup is basically troll-free. Sometimes there's a disagreement about how much the compiler should hold the programmer's hand, but there are a lot of knowledgeable folks around here who want D to succeed. And I think newbies are treated pretty well.
>
>
> > 2.  I think the language is generally well-defined, but I would hate to
have it
> > lock-in upward compatibility as a requirement yet.
>
> You probably need bring up your specific crticisms ASAP if you want Walter to slow down (or back up). I've already brought up my specific issues with D.
>
>
> > 3.  Is there any direct support for Walter for bugfixes and feature
enhancements
> > to handle a lot of yelping would-be users?
>
> He sometimes replies that he'll fix stuff. When he does fix it, he replies to the bug author (and sometimes the newsgroup) that it's fixed. Walter would rather spend time improving D that talking about how he's going to improve D.
>
>
> > 4.  Should the phobos limitations be dealt with immediately?  How about
startng
> > multiple libraries beyond just phobos to classify, accept, distribute
user
> > submissions?  They should have varying degrees of stability required for inclusion, and therefore "officialness".  Incidentally, phobos MUST be
split
> > into basic and OS-dependent libraries, or linux and Solaris and MacOS
and ...
> > are going to become a quick hell.  I have tried to research this back a
bit, but
> > I don't see any benefit to mixing basic and OS-dependent stuff in a
single
> > library except that it has been easier to just maintain a single lib.
This is
> > not likely to be the case any more.
>
> I disaggree.
>
> It's one lib of source code, but it's compiled twice. One of the goals of D is to be cross-platform. It's hard to have a strong cross-platform library if all of the OS-dependent stuff is removed.  Really, what would be left of phobos? Just std.string?
>
>
> > 4.  There should be a drop point other than this list (or email to
Walter) for
> > contributions of fixes, doc-changes, compiler addins, library addins, specialized libraries or programs.  If it's not standardized as a method
now, a
> > whole crop of supporting sites with conflicting versions of the same
things may
> > well arise.  This would not show D well to potential new users, and ALL companies will want "the official versions" - pissing off all concerned.
CVS
> > has been mentioned, as SourceForge or other - doesn't matter where, Mars
or
> > elsewhere, but the process needs a home.  More than it needs bosses,
Lars, but
> > that will be needed too - hopefully as welcoming and non-authoritarian
as
> > possible.  We need knowledgeable people in control, but ones with the
time (not
> > me, I'm afraid) to keep things moving well.  Hopefully not too much
"process" or
> > red-tape - at least for a while yet.
>
> This is a weakness in the state of D right now.  I think an even more pressing problem is all of the "stale" code out there (e.g. it worked great with DMD 0.69, but won't even compile since phobos got re-arranged in DMD 0.75). We probably should include a version number and date when we upload code to a website (so if we fall behind with D updates at least a person can tell before he downloads the whole thing).
>
>
> > 5.  There probably should be a feature requests vs. status list
somewhere
> > centralized and accessible.   Bugzilla possibly, or a Wiki with some
locked
> > pages as well as open ones, or ???  Would be nice if something similar
for bugs
> > vs. fixes status.  The traffic on these will likely not be handled well
by the
> > message list, and anyway it's hard to see what has already been proposed
or
> > submitted, and what the response was.  Having a central status viewing
point
> > does not prevent us from requesting a post to the message list about new
entries
> > and/or discussions there.
>
> I think Bugzilla would be great. I think Walter has some concerns that the Anti-D Militia would make announcements like "look how many unresolved bugs has! Oh, the horror!" (When in reality, their favorite language has many bugs, but their vendor sweeps all the bugs underneath the rug.)
>
> There's already a Wiki page set up (it's all open) relating to requested features: http://www.wikiservice.at/d/wiki.cgi?FeatureRequestList
>
> It's basically a list of some common (and not-so-common) requests with a link to the newsgroup post where it was requested. I've put some similiar pages on the Wiki for topics that come up repeatedly so that we don't necessarily have the same discussions over and over again.
>
> It's a Wiki, so anyone and everyone is encouraged to expand and revise these pages to improve them.
>
>
> > 6.  The news-group stuff should be pursued, but I agree completely that
it's a
> > not-until-full-status-can-be-attained thing.
>
> The world needs news:comp.lang.d.
>
> > 7.  I hate formality, but love appropriate support for appropriate
processes.
> > It's a fine line between doing what is needed and establishing
unnecessary
> > rules.  Let's keep this as open, fair, and productive as possible.
>
> Yes.
>
> >
> > -larry
> >
> >
>
>
> -- 
> Justin
> http://jcc_7.tripod.com/d/

Nevertheless I think nothing beats open-ness.  Let vendors have a rug, they can afford it.  An open project like D cannot.


"C" <dont@respond.com> wrote in message news:c01g0d$tr$1@digitaldaemon.com...
> > I think Bugzilla would be great. I think Walter has some concerns that the Anti-D Militia would make announcements like "look how many unresolved bugs has! Oh, the horror!" (When in reality, their favorite language has many bugs, but their vendor sweeps all the bugs underneath the rug.)
>
> So true ... and most times they dont even think its a bug just a language restriction ( or a "Thats a poor design" , when most likely , their
language
> is incapable of implementing it , and they cant see past their own noses ) In my D advocacy , ive run into so many people who just refuse to try anything new or keep an open mind , its sad and depressing.  There arguing against me , never even having tried the language ... , I tell them to
just
> try it they'll love it , but they just flat refuse.  So sad.

C wrote:
> 
> So true ... and most times they dont even think its a bug just a language
> restriction ( or a "Thats a poor design" , when most likely , their language
> is incapable of implementing it , and they cant see past their own noses )
> In my D advocacy , ive run into so many people who just refuse to try
> anything new or keep an open mind , its sad and depressing.  There arguing
> against me , never even having tried the language ... , I tell them to just
> try it they'll love it , but they just flat refuse.  So sad.

I just heard about D a few days ago (thanks to a thread Walter is in on the MS STL newsgroup) so I'm still getting up to speed on the language, but on paper it seems like the language I *wish* C++ were.  If people discount D out of hand it's probably because they're inexperienced, in which case perhaps they'll come around eventually.  For D to become a true alternative to C++ for me though, it's going to need to scale to handle enterprise-level issues.  Multiplexed i/o, better thread support, etc.  I was going to work on this a bit for Boost but I may do it here instead :p


Sean

"Sean Kelly" <sean@ffwd.cx> wrote in message news:c01mhe$d5u$1@digitaldaemon.com...
> C wrote:
> >
> > So true ... and most times they dont even think its a bug just a
language
> > restriction ( or a "Thats a poor design" , when most likely , their
language
> > is incapable of implementing it , and they cant see past their own
noses )
> > In my D advocacy , ive run into so many people who just refuse to try anything new or keep an open mind , its sad and depressing.  There
arguing
> > against me , never even having tried the language ... , I tell them to
just
> > try it they'll love it , but they just flat refuse.  So sad.
>
> I just heard about D a few days ago (thanks to a thread Walter is in on the MS STL newsgroup) so I'm still getting up to speed on the language, but on paper it seems like the language I *wish* C++ were.  If people discount D out of hand it's probably because they're inexperienced, in which case perhaps they'll come around eventually.

I'm a simple fellow, and that used to incline me to think that C++ was the undisputed best language. I've just written a book called "Imperfect C++", whose title was more an ironic aside than heartfelt when I started it. Out the other side, I still think it's the current best language, but I now see it as much less perfect looking than I had expected to going into it.

Anyway, still being a simple fellow, my new simple rule is that anyone who thinks that any one technology/language/operating-system/whatever is always best is a bit of a dill. :)

In any case, playing around with lots of different languages is far more fun than being stuck in a rut with one. It also opens your eyes to new things that you can do with your existing ones. (I invented a mechanism for providing space&speed efficienct properties in C++; Chapter 35 of the "Imperfect C++" <G>)

Anyhoo, that's enough blatant self-aggrandisement for one posting. Now to address your other issues ...

> For D to become a
> true alternative to C++ for me though, it's going to need to scale to
> handle enterprise-level issues.  Multiplexed i/o, better thread support,
> etc.  I was going to work on this a bit for Boost but I may do it here
> instead :p

Please do. I'd love to help out here and there if you get into IO Completion ports. Love those guys! (There's one technology in which MS can genuinely say that Win32 is superior to UNIX. It may be the only one ...)

And yes, the threading needs a real strong broom, but it's all doable.

Please do make some contributions. At the moment Phobos is missing in several areas, so there's plenty of scope for immortality.

Cheers


-- 
Matthew Wilson

Director, Synesis Software
    (www.synesis.com.au)
STLSoft moderator
    (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
    (www.synesis.com.au/articles.html#columns)

-----------------------------------------------------

"Sean Kelly" <sean@ffwd.cx> wrote in message news:c01mhe$d5u$1@digitaldaemon.com...
> I just heard about D a few days ago (thanks to a thread Walter is in on
> the MS STL newsgroup)

It's microsoft.public.vc.stl for anyone interested in it.

> so I'm still getting up to speed on the language,
> but on paper it seems like the language I *wish* C++ were.

You hit the nail on the head with that. That's exactly the motivation behind D. I love what I can do with C++, but its flaws are so many it inspires me, as an engineer, to fix them.

> If people
> discount D out of hand it's probably because they're inexperienced, in
> which case perhaps they'll come around eventually.  For D to become a
> true alternative to C++ for me though, it's going to need to scale to
> handle enterprise-level issues.  Multiplexed i/o, better thread support,
> etc.  I was going to work on this a bit for Boost but I may do it here
> instead :p

We'd love to have your help here.

"C" <dont@respond.com> wrote in message news:c01g0d$tr$1@digitaldaemon.com...
> So true ... and most times they dont even think its a bug just a language restriction ( or a "Thats a poor design" , when most likely , their
language
> is incapable of implementing it , and they cant see past their own noses ) In my D advocacy , ive run into so many people who just refuse to try anything new or keep an open mind , its sad and depressing.  There arguing against me , never even having tried the language ... , I tell them to
just
> try it they'll love it , but they just flat refuse.  So sad.

That fits right in line with the demographics of D users being younger programmers. I ain't so young anymore (my father fought in the Civil War, ya know <g>), but I'm having more fun with this project than anything I've done in the past. The huge response D is getting, as evidenced here, is more than justifying my confidence that D's future is unlimited.