• Jason House <jason.james.house gmail.com> Apr 16 2008
• downs <default_357-line yahoo.de> Apr 16 2008
• Sean Kelly <sean invisibleduck.org> Apr 16 2008
• Jason House <jason.james.house gmail.com> Apr 16 2008
• Sean Kelly <sean invisibleduck.org> Apr 16 2008
• Derek Parnell <derek psych.ward> Apr 16 2008
• Bill Baxter <dnewsgroup billbaxter.com> Apr 16 2008
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Apr 16 2008
• Robert Fraser <fraserofthenight gmail.com> Apr 16 2008
• Bill Baxter <dnewsgroup billbaxter.com> Apr 16 2008
• "Hans W. Uhlig" <huhlig gmail.com> Apr 18 2008
• Robert Fraser <fraserofthenight gmail.com> Apr 18 2008
• "Hans W. Uhlig" <huhlig gmail.com> Apr 18 2008
• Robert Fraser <fraserofthenight gmail.com> Apr 18 2008
• "Hans W. Uhlig" <huhlig gmail.com> Apr 18 2008
• "Bruce Adams" <tortoise_74 yeah.who.co.uk> Apr 18 2008
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Apr 18 2008
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Apr 18 2008
• Bill Baxter <dnewsgroup billbaxter.com> Apr 18 2008
• Mike Parker <aldacron71 yahoo.com> Apr 18 2008
• Bill Baxter <dnewsgroup billbaxter.com> Apr 18 2008
• Robert Fraser <fraserofthenight gmail.com> Apr 17 2008
• Sean Kelly <sean invisibleduck.org> Apr 17 2008
• Jason House <jason.james.house gmail.com> Apr 17 2008
• Sean Kelly <sean invisibleduck.org> Apr 17 2008
• Jason House <jason.james.house gmail.com> Apr 17 2008
• Bruno Medeiros <brunodomedeiros+spam com.gmail> Apr 25 2008
• Bill Baxter <dnewsgroup billbaxter.com> Apr 25 2008
• Bruno Medeiros <brunodomedeiros+spam com.gmail> Apr 25 2008
• Sean Kelly <sean invisibleduck.org> Apr 25 2008
• "Scott S. McCoy" <tag cpan.org> Apr 17 2008
• Walter Bright <newshound1 digitalmars.com> Apr 16 2008
• BCS <BCS pathlink.com> Apr 16 2008
• Jason House <jason.james.house gmail.com> Apr 16 2008
• Walter Bright <newshound1 digitalmars.com> Apr 16 2008
• Jason House <jason.james.house gmail.com> Apr 16 2008
• J Duncan <jtd514_ ameritech.net> Apr 17 2008
• Derek Parnell <derek psych.ward> Apr 16 2008
• Walter Bright <newshound1 digitalmars.com> Apr 16 2008
• Robert Fraser <fraserofthenight gmail.com> Apr 16 2008
• Spacen Jasset <spacenjasset yahoo.co.uk> Apr 17 2008
• "Jarrett Billingsley" <kb3ctd2 yahoo.com> Apr 16 2008

Jason House <jason.james.house gmail.com> writes:

I feel like I'm seeing a pattern with how constructive criticism in handled. 
Periodically, somebody will take the time to construct these long laundry lists
of issues they have with D (the language, the libraries, the community,
whatever), and a long thread of discussion ensues.  

Each item in the list tends to spawn it's own thread of discussion.  Usually,
this involves a lot of effort to understand why someone made a comment and why.
 The response is typically a defense of why stuff is the way it currently is or
maybe lamenting about the way things are.

What I don't see is an acknowledgment of the issue and a plan for addressing
it.  In the end, good ideas are lost over time as all the good discussion is
lost in the newsgroup archives.  I'd love to see stuff ending up in some kind
of issue tracker, or, at the very least, assigning someone to handle the issue.

Two threads come to mind.  The most recent one is "why I still won't use D",
and the other was posted online at
http://www.unknownbrackets.com/tutorials/polishing-d

The latter one did spawn website updates, but I don't really think anything
came out of the rest of the discussions.  Maybe I'm wrong and there's something
behind the scenes, but the perception is that nothing happened.

downs <default_357-line yahoo.de> writes:

Jason House wrote:
 I feel like I'm seeing a pattern with how constructive criticism in handled. 
Periodically, somebody will take the time to construct these long laundry lists
of issues they have with D (the language, the libraries, the community,
whatever), and a long thread of discussion ensues.  
 
 Each item in the list tends to spawn it's own thread of discussion.  Usually,
this involves a lot of effort to understand why someone made a comment and why.
 The response is typically a defense of why stuff is the way it currently is or
maybe lamenting about the way things are.
 
 What I don't see is an acknowledgment of the issue and a plan for addressing
it.  In the end, good ideas are lost over time as all the good discussion is
lost in the newsgroup archives.  I'd love to see stuff ending up in some kind
of issue tracker, or, at the very least, assigning someone to handle the issue.
 
 Two threads come to mind.  The most recent one is "why I still won't use D",
and the other was posted online at
http://www.unknownbrackets.com/tutorials/polishing-d
 
 The latter one did spawn website updates, but I don't really think anything
came out of the rest of the discussions.  Maybe I'm wrong and there's something
behind the scenes, but the perception is that nothing happened.


I predict that each item on your list will spawn its own thread of discussion
containing lots of bickering, but ultimately be ignored.

It's a catch-22 - addressing the problem first requires addressing the problem.

 --feep

Sean Kelly <sean invisibleduck.org> writes:

== Quote from Jason House (jason.james.house gmail.com)'s article
 I feel like I'm seeing a pattern with how constructive criticism in handled. 
Periodically, somebody will take the time to


thread of discussion ensues.
...
 The latter one did spawn website updates, but I don't really think anything
came out of the rest of the discussions.  Maybe



This is basically where Tango came from.  After years of people lamenting about
the situation
with Phobos, a few members of the community decided that the only way things
were going
to change is if we did it ourselves--that was Ares.  Sadly, community
participation faded fairly
quickly until I was left as the sole contributor and de facto owner of the
project.  After a year
or so of this, Kris and I basically came to the consensus that there was
precious little chance
of future community involvement and so we decided to start fresh with Tango,
following
design goals that emerged from our experience with Ares as well as Mango.

Please note that I'm not saying this to shift the focus of the discussion onto
Tango so much
as to provide evidence that, for better or worse, your observations have always
been true
of D and the only way we've found to change things is to do it ourselves. 
Unfortunately,
because the language has a BDFL there's nothing to be done on that front but
build a
new compiler, and assuming that forking the language is a bad thing, hope that
BDFL
doesn't make any language changes that the community dislikes.

I'm sorry if this sounds a bit defeatist, but in my defense it's a defeatism
that's been born
out of experience.  Insofar as the D language itself is concerned, it's largely
a "take it or
leave it" situation.


Sean

Jason House <jason.james.house gmail.com> writes:

Sean Kelly Wrote:

 == Quote from Jason House (jason.james.house gmail.com)'s article
 I feel like I'm seeing a pattern with how constructive criticism in handled. 
Periodically, somebody will take the time to


 thread of discussion ensues.
 ...
 The latter one did spawn website updates, but I don't really think anything
came out of the rest of the discussions.  Maybe


 
 This is basically where Tango came from.  After years of people lamenting
about the situation
 with Phobos, a few members of the community decided that the only way things
were going
 to change is if we did it ourselves--that was Ares.  Sadly, community
participation faded fairly
 quickly until I was left as the sole contributor and de facto owner of the
project.  After a year
 or so of this, Kris and I basically came to the consensus that there was
precious little chance
 of future community involvement and so we decided to start fresh with Tango,
following
 design goals that emerged from our experience with Ares as well as Mango.



I'm sure there are many people in the D community that are happy you guys did
that!   



 Please note that I'm not saying this to shift the focus of the discussion onto
Tango so much
 as to provide evidence that, for better or worse, your observations have
always been true
 of D and the only way we've found to change things is to do it ourselves. 
Unfortunately,
 because the language has a BDFL there's nothing to be done on that front but
build a
 new compiler, and assuming that forking the language is a bad thing, hope that
BDFL
 doesn't make any language changes that the community dislikes.


I don't mind Walter being our benevolent dictator, but I do hope that he'll
proactively pursue help and delegate responsibility.


 I'm sorry if this sounds a bit defeatist, but in my defense it's a defeatism
that's been born
 out of experience.  Insofar as the D language itself is concerned, it's
largely a "take it or
 leave it" situation.


Maybe with continued effort, things will change :)  Maybe one day I'll join you
with your defeatist attitude, but I'm not there yet...

Sean Kelly <sean invisibleduck.org> writes:

== Quote from Jason House (jason.james.house gmail.com)'s article
 Sean Kelly Wrote:
 I'm sorry if this sounds a bit defeatist, but in my defense it's a defeatism
that's been born
 out of experience.  Insofar as the D language itself is concerned, it's
largely a "take it or
 leave it" situation.





That's good to hear :-)  Someone needs to carry the banner, even if it's
gotten a bit heavy for some of us.


Sean

Derek Parnell <derek psych.ward> writes:

On Wed, 16 Apr 2008 13:21:21 -0400, Jason House wrote:

 I don't mind Walter being our benevolent dictator, but I do hope
 that he'll proactively pursue help and delegate responsibility.
 
 I'm sorry if this sounds a bit defeatist, but in my defense
 it's a defeatism that's been born out of experience.  Insofar
 as the D language itself is concerned, it's largely a "take it or
 leave it" situation.


 Maybe with continued effort, things will change :)  
 Maybe one day I'll join you with your defeatist attitude,
 but I'm not there yet...


I surrendered long ago. I can't even be bothered reading those post you
talk of now. Nothing will come of them. Walter won't change. D will fester
on for a while but all the good things that it could have been will not see
light of day. D is already lot better than the alternatives and that seems
to be good enough for Walter. Mediocracy rules. There is no desire to aim
higher.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Bill Baxter <dnewsgroup billbaxter.com> writes:

Derek Parnell wrote:
 On Wed, 16 Apr 2008 13:21:21 -0400, Jason House wrote:
 
 I don't mind Walter being our benevolent dictator, but I do hope
 that he'll proactively pursue help and delegate responsibility.

 I'm sorry if this sounds a bit defeatist, but in my defense
 it's a defeatism that's been born out of experience.  Insofar
 as the D language itself is concerned, it's largely a "take it or
 leave it" situation.


 Maybe one day I'll join you with your defeatist attitude,
 but I'm not there yet...


 I surrendered long ago. I can't even be bothered reading those post you
 talk of now. Nothing will come of them. Walter won't change. D will fester
 on for a while but all the good things that it could have been will not see
 light of day. D is already lot better than the alternatives and that seems
 to be good enough for Walter. Mediocracy rules. There is no desire to aim
 higher.


The current problem seems to be the opposite to me.  The problem *is* 
that Walter doesn't think D is good enough, and so he think he needs to 
add ingredient C to woo large-systems developers or ingredient P to try 
to leap ahead of the competition.  If anything he's aiming too high, 
into territory that no one knows anything about, and which may pan out 
to be ultimately not so useful.  Or it may pan out to be fantastic.  I 
don't think anyone knows.


--bb

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

"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:fu5u61$1m4u$1 digitalmars.com...

 I surrendered long ago. I can't even be bothered reading those post you
 talk of now. Nothing will come of them. Walter won't change. D will 
 fester
 on for a while but all the good things that it could have been will not 
 see
 light of day. D is already lot better than the alternatives and that 
 seems
 to be good enough for Walter. Mediocracy rules. There is no desire to aim
 higher.


 The current problem seems to be the opposite to me.  The problem *is* that 
 Walter doesn't think D is good enough, and so he think he needs to add 
 ingredient C to woo large-systems developers or ingredient P to try to 
 leap ahead of the competition.  If anything he's aiming too high, into 
 territory that no one knows anything about, and which may pan out to be 
 ultimately not so useful.  Or it may pan out to be fantastic.  I don't 
 think anyone knows.


I'm sure this is what you're getting at, but it's both.  Because W keeps 
adding feature C (lots, and lots, of feature C.  forever.) and thinks about 
feature P, feature M, and feature T don't get any love and so fall into 
decay.

It'd be great if development on featured C and P just _STOPPED_ for once and 
if we could get some other features working _properly_.  You can't build a 
house in a tidal zone without a hell of a foundataion. 

Robert Fraser <fraserofthenight gmail.com> writes:

Jarrett Billingsley wrote:
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:fu5u61$1m4u$1 digitalmars.com...
 
 I surrendered long ago. I can't even be bothered reading those post you
 talk of now. Nothing will come of them. Walter won't change. D will 
 fester
 on for a while but all the good things that it could have been will not 
 see
 light of day. D is already lot better than the alternatives and that 
 seems
 to be good enough for Walter. Mediocracy rules. There is no desire to aim
 higher.


 Walter doesn't think D is good enough, and so he think he needs to add 
 ingredient C to woo large-systems developers or ingredient P to try to 
 leap ahead of the competition.  If anything he's aiming too high, into 
 territory that no one knows anything about, and which may pan out to be 
 ultimately not so useful.  Or it may pan out to be fantastic.  I don't 
 think anyone knows.


 I'm sure this is what you're getting at, but it's both.  Because W keeps 
 adding feature C (lots, and lots, of feature C.  forever.) and thinks about 
 feature P, feature M, and feature T don't get any love and so fall into 
 decay.
 
 It'd be great if development on featured C and P just _STOPPED_ for once and 
 if we could get some other features working _properly_.  You can't build a 
 house in a tidal zone without a hell of a foundataion. 


This man speaks of truth. We need to go back, take a look at the bugs 
and some of the odd syntactic constructions, and get D as it is today 
ship-shape. Then look forward to all the cool new features.

Bill Baxter <dnewsgroup billbaxter.com> writes:

Jarrett Billingsley wrote:
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:fu5u61$1m4u$1 digitalmars.com...
 
 I surrendered long ago. I can't even be bothered reading those post you
 talk of now. Nothing will come of them. Walter won't change. D will 
 fester
 on for a while but all the good things that it could have been will not 
 see
 light of day. D is already lot better than the alternatives and that 
 seems
 to be good enough for Walter. Mediocracy rules. There is no desire to aim
 higher.


 Walter doesn't think D is good enough, and so he think he needs to add 
 ingredient C to woo large-systems developers or ingredient P to try to 
 leap ahead of the competition.  If anything he's aiming too high, into 
 territory that no one knows anything about, and which may pan out to be 
 ultimately not so useful.  Or it may pan out to be fantastic.  I don't 
 think anyone knows.


 I'm sure this is what you're getting at, but it's both.  Because W keeps 
 adding feature C (lots, and lots, of feature C.  forever.) and thinks about 
 feature P, feature M, and feature T don't get any love and so fall into 
 decay.


Yeh, that sums it up nicely.

 It'd be great if development on featured C and P just _STOPPED_ for once and 
 if we could get some other features working _properly_.  You can't build a 
 house in a tidal zone without a hell of a foundataion. 


I think he's /trying/ to balance the two.  Maybe the balance isn't 
falling in the right place, but every release does have some number of 
bug fixes.  And he does listen to pleas for help over bugs that are 
truly blockers for actual development.

I was really happy to see some progress being made on making structs 
smarter in the last D2 release.  Also, someone noticed that a 
description of opDot is now checked into the documentation repo.  Most 
of my serious troubles in porting C++ libraries to D has come from D's 
wussy structs.

I agree that it's sad that various features with good potential have 
fallen by the way-side, but on the other hand, strategically it makes 
sense to me to focus on issues that will have the biggest impact on how 
people write libraries.  Const and smarter structs are probably the two 
that will have the biggest impact.  So it makes sense to try to get 
those two settled as fast as possible.

--bb

"Hans W. Uhlig" <huhlig gmail.com> writes:

Jarrett Billingsley wrote:
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:fu5u61$1m4u$1 digitalmars.com...
 
 I surrendered long ago. I can't even be bothered reading those post you
 talk of now. Nothing will come of them. Walter won't change. D will 
 fester
 on for a while but all the good things that it could have been will not 
 see
 light of day. D is already lot better than the alternatives and that 
 seems
 to be good enough for Walter. Mediocracy rules. There is no desire to aim
 higher.


 Walter doesn't think D is good enough, and so he think he needs to add 
 ingredient C to woo large-systems developers or ingredient P to try to 
 leap ahead of the competition.  If anything he's aiming too high, into 
 territory that no one knows anything about, and which may pan out to be 
 ultimately not so useful.  Or it may pan out to be fantastic.  I don't 
 think anyone knows.


 I'm sure this is what you're getting at, but it's both.  Because W keeps 
 adding feature C (lots, and lots, of feature C.  forever.) and thinks about 
 feature P, feature M, and feature T don't get any love and so fall into 
 decay.
 
 It'd be great if development on featured C and P just _STOPPED_ for once and 
 if we could get some other features working _properly_.  You can't build a 
 house in a tidal zone without a hell of a foundataion. 
 
 


Perhaps this can best be accomplished with gdc. GDC from what I can 
gather is dead but the backend used by GCC is superior to the dm backend 
(not due to insufficient coding but simply due to significantly more 
people giving loving care, attention and eyes over a long period of 
time). I understand the dm chain will always be the formal one, but 
perhaps integrating some of the polishing into gdc might be a good way 
to complete a workable product. I would volunteer for this but my 
knowledge of compilers is rudimentary at best. Although I will be 
looking over source code to see if I can understand how it works.

Robert Fraser <fraserofthenight gmail.com> writes:

Hans W. Uhlig wrote:
 Perhaps this can best be accomplished with gdc. GDC from what I can 
 gather is dead 


It's not; it just progresses very slowly. You'll occasionally see a bug 
marked as closed, so it's going somewhere.

 but the backend used by GCC is superior to the dm backend 
 (not due to insufficient coding but simply due to significantly more 
 people giving loving care, attention and eyes over a long period of 
 time).


That's a gross generalization. the GCC backend generates better code for 
some things, the DigitalMars backend generates better code for others.

 I understand the dm chain will always be the formal one, but 
 perhaps integrating some of the polishing into gdc might be a good way 
 to complete a workable product.


DMD's frontend is used as the frontend of GDC and the backend is 
closed-source. So what are you thinking about integrating?

 I would volunteer for this but my 
 knowledge of compilers is rudimentary at best. Although I will be 
 looking over source code to see if I can understand how it works.


Cool!

I think Dil is where it's at. DMD's frontend is fast, but it's a total 
mess (I helped port it to Java, where it's even more of a mess), and Dil 
helps replace that with a sane and hopefully more easily debuggable 
frontend. Hopefully, Dil will be pluggable so that different backends 
(GCC, LLVM) will be easily added using just a visitor.

"Hans W. Uhlig" <huhlig gmail.com> writes:

Robert Fraser wrote:
 Hans W. Uhlig wrote:
 Perhaps this can best be accomplished with gdc. GDC from what I can 
 gather is dead 


 It's not; it just progresses very slowly. You'll occasionally see a bug 
 marked as closed, so it's going somewhere.
 
 but the backend used by GCC is superior to the dm backend (not due to 
 insufficient coding but simply due to significantly more people giving 
 loving care, attention and eyes over a long period of time).


 That's a gross generalization. the GCC backend generates better code for 
 some things, the DigitalMars backend generates better code for others.
 
 I understand the dm chain will always be the formal one, but perhaps 
 integrating some of the polishing into gdc might be a good way to 
 complete a workable product.


 DMD's frontend is used as the frontend of GDC and the backend is 
 closed-source. So what are you thinking about integrating?
 
 I would volunteer for this but my knowledge of compilers is 
 rudimentary at best. Although I will be looking over source code to 
 see if I can understand how it works.


 Cool!
 
 I think Dil is where it's at. DMD's frontend is fast, but it's a total 
 mess (I helped port it to Java, where it's even more of a mess), and Dil 
 helps replace that with a sane and hopefully more easily debuggable 
 frontend. Hopefully, Dil will be pluggable so that different backends 
 (GCC, LLVM) will be easily added using just a visitor.


oOo... First question what is Dil besides an herb. Second, where is this 
java code. Java I understand and would probably be a faster read then D 
or C source would.

Robert Fraser <fraserofthenight gmail.com> writes:

Hans W. Uhlig wrote:
 oOo... First question what is Dil besides an herb.


http://code.google.com/p/dil/ Sorry, should have posted the link when I 
was writing that.

 Second, where is this 
 java code. Java I understand and would probably be a faster read then D 
 or C source would.


http://www.dsource.org/projects/descent/browser/trunk/descent.core/src/descent/internal/compiler/parser

I promise you it's not. We copied/pasted the C++ source and edited it to 
make it compile under Java. If that meant throwing and catching an 
exception to replace a goto, then so be it.

"Hans W. Uhlig" <huhlig gmail.com> writes:

Robert Fraser wrote:
 Hans W. Uhlig wrote:
 oOo... First question what is Dil besides an herb.


 http://code.google.com/p/dil/ Sorry, should have posted the link when I 
 was writing that.
 
 Second, where is this java code. Java I understand and would probably 
 be a faster read then D or C source would.


 http://www.dsource.org/projects/descent/browser/trunk/descent.core/src/descent/inte
nal/compiler/parser 
 
 
 I promise you it's not. We copied/pasted the C++ source and edited it to 
 make it compile under Java. If that meant throwing and catching an 
 exception to replace a goto, then so be it.


umm... I withdraw my request (huddles in a corner frightened)

"Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:

On Fri, 18 Apr 2008 23:33:41 +0100, Robert Fraser  
<fraserofthenight gmail.com> wrote:

 Hans W. Uhlig wrote:
 oOo... First question what is Dil besides an herb.


 http://code.google.com/p/dil/ Sorry, should have posted the link when I  
 was writing that.

 Second, where is this java code. Java I understand and would probably  
 be a faster read then D or C source would.


 http://www.dsource.org/projects/descent/browser/trunk/descent.core/src/descent/internal/compiler/parser

 I promise you it's not. We copied/pasted the C++ source and edited it to  
 make it compile under Java. If that meant throwing and catching an  
 exception to replace a goto, then so be it.


Walter used a goto? Please say there was a sensible reason otherwise my  
opinion of him will be lowered several notches.

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

"Bruce Adams" <tortoise_74 yeah.who.co.uk> wrote in message 
news:op.t9twxmnvxikks4 starquake.cybernetics...

 Walter used a goto? Please say there was a sensible reason otherwise my 
 opinion of him will be lowered several notches.


It's not "a" goto, it's "gotos", plural.  See the DMDFE source and Phobos. 

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

"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:fubb4m$1omj$1 digitalmars.com...
 "Bruce Adams" <tortoise_74 yeah.who.co.uk> wrote in message 
 news:op.t9twxmnvxikks4 starquake.cybernetics...

 Walter used a goto? Please say there was a sensible reason otherwise my 
 opinion of him will be lowered several notches.


 It's not "a" goto, it's "gotos", plural.  See the DMDFE source and Phobos.


And to add to that: I don't know why. 

Bill Baxter <dnewsgroup billbaxter.com> writes:

Bruce Adams wrote:
 On Fri, 18 Apr 2008 23:33:41 +0100, Robert Fraser 
 <fraserofthenight gmail.com> wrote:
 
 Hans W. Uhlig wrote:
 oOo... First question what is Dil besides an herb.


 http://code.google.com/p/dil/ Sorry, should have posted the link when 
 I was writing that.

 Second, where is this java code. Java I understand and would probably 
 be a faster read then D or C source would.


 http://www.dsource.org/projects/descent/browser/trunk/descent.core/src/descent/inte
nal/compiler/parser 


 I promise you it's not. We copied/pasted the C++ source and edited it 
 to make it compile under Java. If that meant throwing and catching an 
 exception to replace a goto, then so be it.


 Walter used a goto? Please say there was a sensible reason otherwise my 
 opinion of him will be lowered several notches.


cd dmd/src/dmd
grep -nH -e 'goto ' *.c *.h | wc
     932    3913   50909

Walter used 932 goto's to be exact.  :-)

He's a low-level kinda guy.  Gotos are what the hardware does.  Gotos 
map nicely to what happens in a finite state machine.  I wouldn't write 
the code that way, but I wouldn't say it's all that unreasonable a way 
to write the code for a person that's used to programming ASM.

A lot of them seem to be of the "goto FINISHED;" variety to do some 
final tidying up before leaving a function no matter what path you took 
inside the function.  That's a pretty reasonable use of goto in C code 
in my opinion (though DMD is actually C++).

--bb

Mike Parker <aldacron71 yahoo.com> writes:

Bill Baxter wrote:

 
 A lot of them seem to be of the "goto FINISHED;" variety to do some 
 final tidying up before leaving a function no matter what path you took 
 inside the function.  That's a pretty reasonable use of goto in C code 
 in my opinion (though DMD is actually C++).
 


I use gotos that way myself in C. I've never understood why so many 
people continue to say that goto is evil. Once upon a time it was, in 
the days when you could jump to any label anywhere in the program. But 
with the restriction of using labels only in the current scope, I just 
don't see the evilness.

Bill Baxter <dnewsgroup billbaxter.com> writes:

Hans W. Uhlig wrote:
 Jarrett Billingsley wrote:
 "Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
 news:fu5u61$1m4u$1 digitalmars.com...

 I surrendered long ago. I can't even be bothered reading those post you
 talk of now. Nothing will come of them. Walter won't change. D will 
 fester
 on for a while but all the good things that it could have been will 
 not see
 light of day. D is already lot better than the alternatives and that 
 seems
 to be good enough for Walter. Mediocracy rules. There is no desire 
 to aim
 higher.


 that Walter doesn't think D is good enough, and so he think he needs 
 to add ingredient C to woo large-systems developers or ingredient P 
 to try to leap ahead of the competition.  If anything he's aiming too 
 high, into territory that no one knows anything about, and which may 
 pan out to be ultimately not so useful.  Or it may pan out to be 
 fantastic.  I don't think anyone knows.


 I'm sure this is what you're getting at, but it's both.  Because W 
 keeps adding feature C (lots, and lots, of feature C.  forever.) and 
 thinks about feature P, feature M, and feature T don't get any love 
 and so fall into decay.

 It'd be great if development on featured C and P just _STOPPED_ for 
 once and if we could get some other features working _properly_.  You 
 can't build a house in a tidal zone without a hell of a foundataion.




I think many people would like to see GCC become the official back-end 
of D.  It has certainly been proposed before.

Walter, however, is concerned about GPL taint, and he doesn't even want 
to *look* at any GCC code for fear that rabid GPL fans will claim he 
stole GPL code and put it into DigitalMars products.  Though the 
possibility seems remote, I can't say I blame him.

BUT! LLVM has no such licensing problems.  It's got a very nice liberal 
license that Apple and others have been taking advantage of to create 
both proprietary and non-proprietary stuff.
http://llvm.org/releases/2.2/LICENSE.TXT

LLVM is the way to go.  Go Thomas Go!

--bb

Robert Fraser <fraserofthenight gmail.com> writes:

Scott S. McCoy wrote:
 On Thu, 2008-04-17 at 07:21 +0900, Bill Baxter wrote:
 The current problem seems to be the opposite to me.  The problem *is* 
 that Walter doesn't think D is good enough, and so he think he needs to 
 add ingredient C to woo large-systems developers or ingredient P to try 
 to leap ahead of the competition.  If anything he's aiming too high, 
 into territory that no one knows anything about, and which may pan out 
 to be ultimately not so useful.  Or it may pan out to be fantastic.  I 
 don't think anyone knows.


 I've sort of had a similar feeling.  D has a quite astounding feature
 set, and is in a really strong position.  And unlike many languages
 actually has a solid reference implementation.  Unfortunately I've
 noticed a lot of corner-case sloppiness, some rather unfortunate syntax
 which seems to need be revisited, and a few other odds and ends which
 really need cleaning up -- but never the less, time is spent moving
 forward, not perfecting what is.
 
 There is a lot of perfecting what is that really aught to be addressed,
 I find, and I think if not a single additional feature was added to D
 it's already in an amazing position.  And a lot of the things which are
 done right in D (method references as delegates that actually work, for
 instance) are really strong enough that if realized correctly through
 the framework development that could easily take shape around them,
 could push D quickly into larger scale adoption.
 
 However, I see all this talk about adding strange concepts like "pure
 functions" which add inane complexity to the language, meanwhile
 interesting corner cases about "auto" and various other behaviors -- as
 well as various implementation bugs -- remain.  Syntactical sores stick
 around (Foo!() comes to mind) and nobody worries about them.  D has a
 lot of promise, I feel, and has a better feature-set for working with it
 than any other language I've seen to-date.  It seems absolutely
 picturesque for business infrastructure software; among other things,
 and I'd love to be able to employ it in the real world.  To get that
 though, I need to see adoption move at a better pace.
 
 The only thing holding me back, as a professional software architect,
 from trying to get D used at my day job is literally adoption.  const is
 nice, and I find the feature rather exciting -- but to be honest, it's
 not nearly as important as being able to point to articles showing other
 companies are using D.  And I think we'll see them as we see better
 programming frameworks and libraries take shape around D.  I think we'd
 see more of that if we cleaned up the miscellaneous issues, fixed a few
 of the syntax ambiguities, and got a focus on a solid, stable,
 non-tumultuous language specification that people can build on without
 fear of future change.
 
 Fear of change is a major issue, for any language looking for adoption.
 If the specification is changing rapidly, or a large "bigger, better"
 version is looming in the distance (especially of the language is-- and
 after that some stability might come about. already not particularly
 well established) then it provides reason for reservation for going and
 say, building a good web service stack and WSDL-based code generator for
 D.  If D 2.0 is "so close", why not wait for that?
 
 At the same time, the molasses rate of change that languages like C, C++
 and Java have is not something D should adopt by any means.  But
 nevertheless, I'm really hoping that once D 2 is ironed out -- it will
 have a lot of the corner cases dealt with and hopefully some of the
 syntax cleaned up -- and after that some stability might come about.
 
 Cheers,
 	Scott S. McCoy
 


Well, there's D1, which is quite stable and receiving a number of 
bugixes. Most tools/libraries right now are D1-based, anyway.

Sean Kelly <sean invisibleduck.org> writes:

== Quote from Scott S. McCoy (tag cpan.org)'s article
 On Thu, 2008-04-17 at 07:21 +0900, Bill Baxter wrote:
 The current problem seems to be the opposite to me.  The problem *is*
 that Walter doesn't think D is good enough, and so he think he needs to
 add ingredient C to woo large-systems developers or ingredient P to try
 to leap ahead of the competition.  If anything he's aiming too high,
 into territory that no one knows anything about, and which may pan out
 to be ultimately not so useful.  Or it may pan out to be fantastic.  I
 don't think anyone knows.


 set, and is in a really strong position.  And unlike many languages
 actually has a solid reference implementation.  Unfortunately I've
 noticed a lot of corner-case sloppiness, some rather unfortunate syntax
 which seems to need be revisited, and a few other odds and ends which
 really need cleaning up -- but never the less, time is spent moving
 forward, not perfecting what is.


Personally, I think D 1.0 is fantastic.  It has a few tiny warts, but overall
the syntax is elegant and imminently usable.  I would love for the 1.0
version of D to get some more attention and for the remaining functional
bits to be improved: template function overloading, inheritable contracts,
etc.  That said, the only compelling reasons for me to upgrade to 2.0 are
struct ctors and overload groups (or whatever they're called).  The const
syntax is a dis-incentive, as is the dual meaning of enum, dynamic
closures, etc.  They all complicate the syntax in undesirable ways or
cause problems while attempting to solve solutions I don't need solved
for the work I do.  I can appreciate that Walter thinks these are all the
best thing for D, so I hope that he can appreciate that they aren't the
best thing for me.  I would prefer more attention were paid to solidifying
the foothold D already has than erode it in an attempt to gain new users.

 However, I see all this talk about adding strange concepts like "pure
 functions" which add inane complexity to the language, meanwhile
 interesting corner cases about "auto" and various other behaviors -- as
 well as various implementation bugs -- remain.  Syntactical sores stick
 around (Foo!() comes to mind) and nobody worries about them.


hehe, I proposed that the template bit be dropped if no arguments are
necessary a year or so ago, but the proposal got no responses.  I can't
find the post, but perhaps someone else can.  It was in this group.

 The only thing holding me back, as a professional software architect,
 from trying to get D used at my day job is literally adoption.  const is
 nice, and I find the feature rather exciting -- but to be honest, it's
 not nearly as important as being able to point to articles showing other
 companies are using D.  And I think we'll see them as we see better
 programming frameworks and libraries take shape around D.  I think we'd
 see more of that if we cleaned up the miscellaneous issues, fixed a few
 of the syntax ambiguities, and got a focus on a solid, stable,
 non-tumultuous language specification that people can build on without
 fear of future change.


It would be nice if 64-bit support were improved (or at least the ABI were
modified to account for this) and if the linker discarded more unused code.
Fixing debug symbol output on linux would be nice as well (I believe symbols
are still mangled in gdb).  None of these are deal-breakers, but they are all
questions that come up for corporate developers when first encountering D.

 Fear of change is a major issue, for any language looking for adoption.
 If the specification is changing rapidly, or a large "bigger, better"
 version is looming in the distance (especially of the language is-- and
 after that some stability might come about. already not particularly
 well established) then it provides reason for reservation for going and
 say, building a good web service stack and WSDL-based code generator for
 D.  If D 2.0 is "so close", why not wait for that?


In my experience, the issue is more often a desire for stability and support.
An unpopular language is difficult to sell to management because they worry
about hiring developers to maintain the code.  An unstable language spec,
unreliable toolchain, or poor tool support is a difficult sell to the build team
because they have to maintain the build environment.  Issues like a lack of
const is far secondary to such practicalities--look at Java.

 At the same time, the molasses rate of change that languages like C, C++
 and Java have is not something D should adopt by any means.  But
 nevertheless, I'm really hoping that once D 2 is ironed out -- it will
 have a lot of the corner cases dealt with and hopefully some of the
 syntax cleaned up -- and after that some stability might come about.


There are other languages which have become quite popular in a fairly
short time which may be more worth looking at insofar as progress of
the syntax, community participation, etc, are concerned.  Take Ruby, for
example.


Sean

Jason House <jason.james.house gmail.com> writes:

Following my own advice for a more proacitve role to constructive criticism...

Sean Kelly Wrote:
 It would be nice if 64-bit support were improved
 (or at least the ABI were
 modified to account for this)


Who defines the ABI?  Is that just Walter?  Do people developing GDC and LLVMDC
have any kind of influence over this process?


 and if the linker discarded more unused code.


What is "the linker"?  is this a problem with the digital mars tools or a more
generic problem?


 Fixing debug symbol output on linux would be nice as well (I believe symbols
 are still mangled in gdb).


I thought someone created a GDB patch for D symbols.  Is that true?  if so, why
hasn't it been adopted by the GDB team?  How can we cause that to happen?

Sean Kelly <sean invisibleduck.org> writes:

== Quote from Jason House (jason.james.house gmail.com)'s article
 Following my own advice for a more proacitve role to constructive criticism...
 Sean Kelly Wrote:
 It would be nice if 64-bit support were improved
 (or at least the ABI were
 modified to account for this)





It's Walter.  Though I imagine he may be open to input, particularly for
platforms that DMD doesn't target.

 and if the linker discarded more unused code.




This has been mentioned most often regarding the DigitalMars linker, but
from what I understand, "ld" has the same problem, even with "gc-sections"
set.  Apparently, the LLVM linker works as desired, however.

 Fixing debug symbol output on linux would be nice as well (I believe symbols
 are still mangled in gdb).





No idea.  It would be nice to have the same patch applied to DMD as well,
if possible.  I'll admit to having never used GDB on D code though, so I'm just
relaying my perception of the state of things.  Perhaps someone with
more experience here could comment.


Sean

Jason House <jason.james.house gmail.com> writes:

Sean Kelly Wrote:

 == Quote from Jason House (jason.james.house gmail.com)'s article
 Following my own advice for a more proacitve role to constructive criticism...
 Sean Kelly Wrote:
 It would be nice if 64-bit support were improved
 (or at least the ABI were
 modified to account for this)




 
 It's Walter.  Though I imagine he may be open to input, particularly for
 platforms that DMD doesn't target.


Here's where I guess we have to hope Walter sees this and responds, or maybe
someone who has direct contact to Walter will ask him about this.  It'd be
really nice if gdc didn't have to break d standards to support 64 bit.



 and if the linker discarded more unused code.




 This has been mentioned most often regarding the DigitalMars linker, but
 from what I understand, "ld" has the same problem, even with "gc-sections"
 set.  Apparently, the LLVM linker works as desired, however.


Is there a feature request for this with digital mars already?

Does anyone know if the ld team is aware of this issue?  If not, someone should
submit a request to them.

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

Sean Kelly wrote:
 etc.  That said, the only compelling reasons for me to upgrade to 2.0 are
 struct ctors and overload groups (or whatever they're called).  The const
 syntax is a dis-incentive, as is the dual meaning of enum, dynamic
 closures, etc.  They all complicate the syntax in undesirable ways or
 cause problems while attempting to solve solutions I don't need solved
 for the work I do.  


Huh? I understand the issues with const and enum, but what's the problem 
with dynamic closures?

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

Bill Baxter <dnewsgroup billbaxter.com> writes:

Bruno Medeiros wrote:
 Sean Kelly wrote:
 etc.  That said, the only compelling reasons for me to upgrade to 2.0 are
 struct ctors and overload groups (or whatever they're called).  The const
 syntax is a dis-incentive, as is the dual meaning of enum, dynamic
 closures, etc.  They all complicate the syntax in undesirable ways or
 cause problems while attempting to solve solutions I don't need solved
 for the work I do.  


 Huh? I understand the issues with const and enum, but what's the problem 
 with dynamic closures?


The only problem is there's no way to turn it off now in the case that 
you were wanting a no-allocation delegate literal.  I think the compiler 
tries to guess if allocating a closure is necessary, but it errs on the 
side of caution and so can create them when  they aren't necessary.

--bb

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

Bill Baxter wrote:
 Bruno Medeiros wrote:
 Sean Kelly wrote:
 etc.  That said, the only compelling reasons for me to upgrade to 2.0 
 are
 struct ctors and overload groups (or whatever they're called).  The 
 const
 syntax is a dis-incentive, as is the dual meaning of enum, dynamic
 closures, etc.  They all complicate the syntax in undesirable ways or
 cause problems while attempting to solve solutions I don't need solved
 for the work I do.  


 Huh? I understand the issues with const and enum, but what's the 
 problem with dynamic closures?


 The only problem is there's no way to turn it off now in the case that 
 you were wanting a no-allocation delegate literal.  I think the compiler 
 tries to guess if allocating a closure is necessary, but it errs on the 
 side of caution and so can create them when  they aren't necessary.
 
 --bb


I've just read the relevant documentation, and there is no mention of 
optimizations, it just says that "The stack variables referenced by a 
nested function are still valid even after the function exits "

But I do recall a comment by Walter where he said the compiler would 
only allocate such outer variables if it was really necessary. However, 
like Sean mentioned, it's not safe to rely on such uncertain and 
unguaranteed optimization if one wants to have the code optimized.
Perhaps one should be able to use 'scope' somehow to allow specifying 
that a function/delegate should not escape the nested function. 'scope' 
fits perfectly with that purpose, and it should work well with function 
declarations, but with delegate literals it's another story... :S

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

Sean Kelly <sean invisibleduck.org> writes:

== Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
 Sean Kelly wrote:
 etc.  That said, the only compelling reasons for me to upgrade to 2.0 are
 struct ctors and overload groups (or whatever they're called).  The const
 syntax is a dis-incentive, as is the dual meaning of enum, dynamic
 closures, etc.  They all complicate the syntax in undesirable ways or
 cause problems while attempting to solve solutions I don't need solved
 for the work I do.


 with dynamic closures?


They currently allocate dynamic memory to store stack data for many delegates
that never actually escape the declaration scope.  No big deal for the average
program perhaps, but it eliminates delegates as an option for
performance-critical
code, at least without an examination of the assembly output.


Sean

"Scott S. McCoy" <tag cpan.org> writes:

On Thu, 2008-04-17 at 07:21 +0900, Bill Baxter wrote:
 The current problem seems to be the opposite to me.  The problem *is* 
 that Walter doesn't think D is good enough, and so he think he needs to 
 add ingredient C to woo large-systems developers or ingredient P to try 
 to leap ahead of the competition.  If anything he's aiming too high, 
 into territory that no one knows anything about, and which may pan out 
 to be ultimately not so useful.  Or it may pan out to be fantastic.  I 
 don't think anyone knows.


I've sort of had a similar feeling.  D has a quite astounding feature
set, and is in a really strong position.  And unlike many languages
actually has a solid reference implementation.  Unfortunately I've
noticed a lot of corner-case sloppiness, some rather unfortunate syntax
which seems to need be revisited, and a few other odds and ends which
really need cleaning up -- but never the less, time is spent moving
forward, not perfecting what is.

There is a lot of perfecting what is that really aught to be addressed,
I find, and I think if not a single additional feature was added to D
it's already in an amazing position.  And a lot of the things which are
done right in D (method references as delegates that actually work, for
instance) are really strong enough that if realized correctly through
the framework development that could easily take shape around them,
could push D quickly into larger scale adoption.

However, I see all this talk about adding strange concepts like "pure
functions" which add inane complexity to the language, meanwhile
interesting corner cases about "auto" and various other behaviors -- as
well as various implementation bugs -- remain.  Syntactical sores stick
around (Foo!() comes to mind) and nobody worries about them.  D has a
lot of promise, I feel, and has a better feature-set for working with it
than any other language I've seen to-date.  It seems absolutely
picturesque for business infrastructure software; among other things,
and I'd love to be able to employ it in the real world.  To get that
though, I need to see adoption move at a better pace.

The only thing holding me back, as a professional software architect,
from trying to get D used at my day job is literally adoption.  const is
nice, and I find the feature rather exciting -- but to be honest, it's
not nearly as important as being able to point to articles showing other
companies are using D.  And I think we'll see them as we see better
programming frameworks and libraries take shape around D.  I think we'd
see more of that if we cleaned up the miscellaneous issues, fixed a few
of the syntax ambiguities, and got a focus on a solid, stable,
non-tumultuous language specification that people can build on without
fear of future change.

Fear of change is a major issue, for any language looking for adoption.
If the specification is changing rapidly, or a large "bigger, better"
version is looming in the distance (especially of the language is-- and
after that some stability might come about. already not particularly
well established) then it provides reason for reservation for going and
say, building a good web service stack and WSDL-based code generator for
D.  If D 2.0 is "so close", why not wait for that?

At the same time, the molasses rate of change that languages like C, C++
and Java have is not something D should adopt by any means.  But
nevertheless, I'm really hoping that once D 2 is ironed out -- it will
have a lot of the corner cases dealt with and hopefully some of the
syntax cleaned up -- and after that some stability might come about.

Cheers,
	Scott S. McCoy

Walter Bright <newshound1 digitalmars.com> writes:

I can understand your frustration with this. The basic problem is I 
could easily spend 100% of my time just on this newsgroup responding to 
it all. That leaves no time at all for preparing action plans let alone 
trying to implement anything.

Important issues come up here *every single day*.

The scrolling issue is a real one, too. Things tend to scroll up and 
away. The way to have them not get lost is:

1) Enhancement requests should go into bugzilla with perhaps a link to 
the corresponding archives page

2) Other issues should go into the D wiki

BCS <BCS pathlink.com> writes:

Walter Bright wrote:
 1) Enhancement requests should go into bugzilla with perhaps a link to 
 the corresponding archives page
 
 2) Other issues should go into the D wiki


FWIW: I second that.

With regards to the (somewhat defensive) response that ideas get; I 
think that this is not that bad a way to run things. Walter need to be 
conservative in implementing stuff. As long as the thread stays in the 
realm of "this is the reasoning for the way things are" and stays out of 
"your wrong and this is why" I have no problem with things. A lot of 
work as gone into making D what it is and it /should/ take a very good 
reason to change stuff (and a very good reason /should/ change stuff)

Jason House <jason.james.house gmail.com> writes:

Walter Bright wrote:

 I can understand your frustration with this. The basic problem is I
 could easily spend 100% of my time just on this newsgroup responding to
 it all. That leaves no time at all for preparing action plans let alone
 trying to implement anything.


I am not so detatched from reality that I expect you to do everything.  D
has become larger than a one man project.  You shouldn't be the one
creating all the action plans, but you should be the one encouraging the
community to pursue specific directions.  

A little empowerment can go a long way.  Who wants to dedicate their spare
time to doing something that ultimately gets veto'd?  What you say may
carry more weight than you realize.

If you state something is a good idea and ask for volunteers to do pieces, I
bet you'll find volunteers.  There are many motivated people on this list
that are actively looking to contribute to the D community (just look at
all the proposals and discussions of proposals).

If someone makes a proposal and you encourage them to flesh it out and post
in bugzilla, they probably will. Those of us that make language design
proposals are already crazy enough to spend lots of our spare time
developing ideas and explaining them to others.

Walter Bright <newshound1 digitalmars.com> writes:

Jason House wrote:
 I am not so detatched from reality that I expect you to do everything.  D
 has become larger than a one man project.  You shouldn't be the one
 creating all the action plans, but you should be the one encouraging the
 community to pursue specific directions.  


I tried that once with DWT, and progress on it promptly halted (it has 
since been resurrected and finished, but there was a long hiatus there).

Essentially, I stink as a manager. The things that get done with D are 
ones done by people who don't need to be managed. They are entirely self 
motivated.


 A little empowerment can go a long way.  Who wants to dedicate their spare
 time to doing something that ultimately gets veto'd?  What you say may
 carry more weight than you realize.


I realize that what I say can carry a lot of weight - which is why I try 
to be very careful not to rain on anyone's parade here.


 If you state something is a good idea and ask for volunteers to do pieces, I
 bet you'll find volunteers.  There are many motivated people on this list
 that are actively looking to contribute to the D community (just look at
 all the proposals and discussions of proposals).
 
 If someone makes a proposal and you encourage them to flesh it out and post
 in bugzilla, they probably will. Those of us that make language design
 proposals are already crazy enough to spend lots of our spare time
 developing ideas and explaining them to others.


Yes, and that's great!

Jason House <jason.james.house gmail.com> writes:

Walter Bright wrote:

 Jason House wrote:
 I am not so detatched from reality that I expect you to do everything.  D
 has become larger than a one man project.  You shouldn't be the one
 creating all the action plans, but you should be the one encouraging the
 community to pursue specific directions.


 I tried that once with DWT, and progress on it promptly halted (it has
 since been resurrected and finished, but there was a long hiatus there).



Do you think that was your fault?



 Essentially, I stink as a manager. The things that get done with D are
 ones done by people who don't need to be managed. They are entirely self
 motivated.


One person described good management as "giving people the work they want to
do and then getting out of the way".  While I'm not suggesting that you
manage what gets done within the community at a low level, I think a few
gentle nudges may help.  If you decide on a few key initiatives and
consistently reinforce them, they'll happen.

Also, if you don't feel like you're able to selectively manage stuff, it may
help to empower a few trusted colleagues to help with this kind of thing.


 A little empowerment can go a long way.  Who wants to dedicate their
 spare
 time to doing something that ultimately gets veto'd?  What you say may
 carry more weight than you realize.


 I realize that what I say can carry a lot of weight - which is why I try
 to be very careful not to rain on anyone's parade here.


Good idea.  Similarly, praise/encouragement can have an equally strong
effect.

J Duncan <jtd514_ ameritech.net> writes:

Walter Bright wrote:
 
 I tried that once with DWT, and progress on it promptly halted (it has 
 since been resurrected and finished, but there was a long hiatus there).
 


to inflict it upon the D world.....  ;)

Derek Parnell <derek psych.ward> writes:

On Wed, 16 Apr 2008 11:08:05 -0700, Walter Bright wrote:

 I can understand your frustration with this. The basic problem is I 
 could easily spend 100% of my time just on this newsgroup responding to 
 it all. That leaves no time at all for preparing action plans let alone 
 trying to implement anything.


... I can see a bottleneck ...

 Important issues come up here *every single day*.
 
 The scrolling issue is a real one, too. Things tend to scroll up and 
 away. The way to have them not get lost is:
 
 1) Enhancement requests should go into bugzilla with perhaps a link to 
 the corresponding archives page
 
 2) Other issues should go into the D wiki


What purpose would that really serve? You still have to spend time
assessing, deciding, evaluating, analysing, exporing, prototyping, ...
which all happens at a lot slower pace than new items arrive at.  

The current development model is no longer the best one for a better D.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Walter Bright <newshound1 digitalmars.com> writes:

Derek Parnell wrote:
 What purpose would that really serve? You still have to spend time
 assessing, deciding, evaluating, analysing, exporing, prototyping, ...
 which all happens at a lot slower pace than new items arrive at.  


It serves to organize it. Right now, there is no easy way to sort 
through the archives looking for the threads that matter.


 The current development model is no longer the best one for a better D.


If you put 100 people working on the D compiler, it probably wouldn't 
move forward any faster. Take a look at the D compiler progress vs 
compilers for other languages with teams working on them.

Robert Fraser <fraserofthenight gmail.com> writes:

Walter Bright wrote:
 If you put 100 people working on the D compiler, it probably wouldn't 
 move forward any faster. Take a look at the D compiler progress vs 
 compilers for other languages with teams working on them.


But there may be more bug fixes.

Spacen Jasset <spacenjasset yahoo.co.uk> writes:

Robert Fraser wrote:
 Walter Bright wrote:
 If you put 100 people working on the D compiler, it probably wouldn't 
 move forward any faster. Take a look at the D compiler progress vs 
 compilers for other languages with teams working on them.


 But there may be more bug fixes.


I would agree with this. Some bodies that can fix bugs would be helpful 
if said issue is clearly a bug that doesn't involve deep discussion/spec 
interpretation etc.

Could this area of development not be helped by putting a few 
individuals on the case that stick to this remit?

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

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fu5fa2$ccv$1 digitalmars.com...
I can understand your frustration with this. The basic problem is I could 
easily spend 100% of my time just on this newsgroup responding to it all. 
That leaves no time at all for preparing action plans let alone trying to 
implement anything.


It's particularly frustrating, though, when legitimate RFCs go unanswered 
(and so, as far as anyone can tell, ignored) when stupid crap like "omg the 
DMD source code ends in .c instead of .cpp" gets ten replies.

Seriously now.