www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Handling constructive criticism

reply 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.
Apr 16 2008
next sibling parent 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
Apr 16 2008
prev sibling next sibling parent reply 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
Apr 16 2008
next sibling parent reply 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...
Apr 16 2008
next sibling parent 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
Apr 16 2008
prev sibling parent reply 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
Apr 16 2008
parent reply 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
Apr 16 2008
next sibling parent reply "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.
Apr 16 2008
next sibling parent 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.
Apr 16 2008
prev sibling next sibling parent 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
Apr 16 2008
prev sibling parent reply "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.
Apr 18 2008
next sibling parent reply 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.
Apr 18 2008
parent reply "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.
Apr 18 2008
parent reply 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.
Apr 18 2008
next sibling parent "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)
Apr 18 2008
prev sibling parent reply "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.
Apr 18 2008
next sibling parent reply "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.
Apr 18 2008
parent "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.
Apr 18 2008
prev sibling parent reply 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
Apr 18 2008
parent 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.
Apr 18 2008
prev sibling parent 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
Apr 18 2008
prev sibling next sibling parent 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.
Apr 17 2008
prev sibling parent reply 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
Apr 17 2008
next sibling parent reply 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?
Apr 17 2008
parent reply 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
Apr 17 2008
parent 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.
Apr 17 2008
prev sibling parent reply 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
Apr 25 2008
next sibling parent reply 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
Apr 25 2008
parent 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
Apr 25 2008
prev sibling parent 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
Apr 25 2008
prev sibling parent "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
Apr 17 2008
prev sibling parent reply 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
Apr 16 2008
next sibling parent 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)
Apr 16 2008
prev sibling next sibling parent reply 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.
Apr 16 2008
parent reply 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!
Apr 16 2008
next sibling parent 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.
Apr 16 2008
prev sibling parent 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..... ;)
Apr 17 2008
prev sibling next sibling parent reply 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
Apr 16 2008
parent reply 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.
Apr 16 2008
parent reply 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.
Apr 16 2008
parent 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?
Apr 17 2008
prev sibling parent "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.
Apr 16 2008