www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Biggest Issue with D - Definition and Versioning

reply Zachary Lund <admin computerquip.com> writes:
D1 or D2 both don't have a very accurate definition. C and C++ has 
several hundred pages of specifications and while I'm hopefully not 
expecting that, I do want some certainty on what is *supposed* to happen.

There is also no versioning. D2 is definitely different from D1 in the 
case that it's not backwards compatible, but version for the actual 
example implementation isn't enough, especially when that implementation 
doesn't always do what it's supposed to do.
Jan 11 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/11/2012 12:29 PM, Zachary Lund wrote:

 D1 or D2 both don't have a very accurate definition. C and C++ has several
 hundred pages of specifications and while I'm hopefully not expecting that, I
do
 want some certainty on what is *supposed* to happen.

 There is also no versioning. D2 is definitely different from D1 in the case
that
 it's not backwards compatible, but version for the actual example
implementation
 isn't enough, especially when that implementation doesn't always do what it's
 supposed to do.


Please file bug reports for any errors/omissions in the specification on
bugzilla.
Jan 11 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-11 21:34, Walter Bright wrote:

 On 1/11/2012 12:29 PM, Zachary Lund wrote:

 D1 or D2 both don't have a very accurate definition. C and C++ has
 several
 hundred pages of specifications and while I'm hopefully not expecting
 that, I do
 want some certainty on what is *supposed* to happen.

 There is also no versioning. D2 is definitely different from D1 in the
 case that
 it's not backwards compatible, but version for the actual example
 implementation
 isn't enough, especially when that implementation doesn't always do
 what it's
 supposed to do.


 Please file bug reports for any errors/omissions in the specification on
 bugzilla.


That's the whole point. It's not clear what the actual specification IS. 
Is it DMD, dlang.org or TDPL?

-- 
/Jacob Carlborg
Jan 11 2012
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 1/11/2012 11:16 PM, Jacob Carlborg wrote:

 On 2012-01-11 21:34, Walter Bright wrote:

 On 1/11/2012 12:29 PM, Zachary Lund wrote:

 D1 or D2 both don't have a very accurate definition. C and C++ has
 several
 hundred pages of specifications and while I'm hopefully not expecting
 that, I do
 want some certainty on what is *supposed* to happen.

 There is also no versioning. D2 is definitely different from D1 in the
 case that
 it's not backwards compatible, but version for the actual example
 implementation
 isn't enough, especially when that implementation doesn't always do
 what it's
 supposed to do.


 Please file bug reports for any errors/omissions in the specification on
 bugzilla.


 
 That's the whole point. It's not clear what the actual specification IS. Is it
DMD, dlang.org or TDPL?


The website is the spec.  DMD is the reference instantiation of that spec. 
TDPL is a re-framing of it.

Now, given that none of the three are perfect, discrepancies exist which
obviously lead to questions.  That's where
bugzilla comes in to record and track the queue of issues to resolve among
them.  Where there's issues, until it's been
examined, any of the parties could be at fault.

My 2 cents,
Brad
Jan 11 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 12-01-2012 08:30, Brad Roberts wrote:

 On 1/11/2012 11:16 PM, Jacob Carlborg wrote:

 On 2012-01-11 21:34, Walter Bright wrote:

 On 1/11/2012 12:29 PM, Zachary Lund wrote:

 D1 or D2 both don't have a very accurate definition. C and C++ has
 several
 hundred pages of specifications and while I'm hopefully not expecting
 that, I do
 want some certainty on what is *supposed* to happen.

 There is also no versioning. D2 is definitely different from D1 in the
 case that
 it's not backwards compatible, but version for the actual example
 implementation
 isn't enough, especially when that implementation doesn't always do
 what it's
 supposed to do.


 Please file bug reports for any errors/omissions in the specification on
 bugzilla.


 That's the whole point. It's not clear what the actual specification IS. Is it
DMD, dlang.org or TDPL?


 The website is the spec.  DMD is the reference instantiation of that spec. 
TDPL is a re-framing of it.

 Now, given that none of the three are perfect, discrepancies exist which
obviously lead to questions.  That's where
 bugzilla comes in to record and track the queue of issues to resolve among
them.  Where there's issues, until it's been
 examined, any of the parties could be at fault.

 My 2 cents,
 Brad


In all honesty, the website can barely be called a spec. Sure, it has 
grammar and a few notes on semantics, but it's not even close to what 
people expect from a programming language specification in this day and 


If someone (probably among the DMD developers) was willing to flesh out 
a clean and complete grammar definition for the language (preferably in 
the form of one EBNF file, independent of doc format), I'd personally be 
willing to put in effort to write a spec around it.

- Alex
Jan 12 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-01-12 08:30, Brad Roberts wrote:

 On 1/11/2012 11:16 PM, Jacob Carlborg wrote:

 On 2012-01-11 21:34, Walter Bright wrote:

 On 1/11/2012 12:29 PM, Zachary Lund wrote:

 D1 or D2 both don't have a very accurate definition. C and C++ has
 several
 hundred pages of specifications and while I'm hopefully not expecting
 that, I do
 want some certainty on what is *supposed* to happen.

 There is also no versioning. D2 is definitely different from D1 in the
 case that
 it's not backwards compatible, but version for the actual example
 implementation
 isn't enough, especially when that implementation doesn't always do
 what it's
 supposed to do.


 Please file bug reports for any errors/omissions in the specification on
 bugzilla.


 That's the whole point. It's not clear what the actual specification IS. Is it
DMD, dlang.org or TDPL?


 The website is the spec.  DMD is the reference instantiation of that spec. 
TDPL is a re-framing of it.

 Now, given that none of the three are perfect, discrepancies exist which
obviously lead to questions.  That's where
 bugzilla comes in to record and track the queue of issues to resolve among
them.  Where there's issues, until it's been
 examined, any of the parties could be at fault.

 My 2 cents,
 Brad


When there is a difference it's hard to know which parts (dlang, dmd, 
tdpl) are correct and which parts a wrong.

-- 
/Jacob Carlborg
Jan 12 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/11/2012 11:30 PM, Brad Roberts wrote:

 The website is the spec.  DMD is the reference instantiation of that spec. 
TDPL is a re-framing of it.


To be fair, TDPL is not meant as a specification. It's meant as an explanation 
and guide to how to use D effectively.
Jan 12 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
I see the TDPL as having the same role as the C++ ARM did.

http://www.amazon.de/Annotated-C-Reference-Manual/dp/0201514591

For those that don't know this book, Bjarne and Margaret wrote as an attempt
to have the first written specifcation of how CFront behaved and what was
expected by C++ compilers.

--
Paulo


"Jacob Carlborg"  wrote in message news:jem1cr$2fco$1 digitalmars.com...

On 2012-01-11 21:34, Walter Bright wrote:

 On 1/11/2012 12:29 PM, Zachary Lund wrote:

 D1 or D2 both don't have a very accurate definition. C and C++ has
 several
 hundred pages of specifications and while I'm hopefully not expecting
 that, I do
 want some certainty on what is *supposed* to happen.

 There is also no versioning. D2 is definitely different from D1 in the
 case that
 it's not backwards compatible, but version for the actual example
 implementation
 isn't enough, especially when that implementation doesn't always do
 what it's
 supposed to do.


 Please file bug reports for any errors/omissions in the specification on
 bugzilla.


That's the whole point. It's not clear what the actual specification IS.
Is it DMD, dlang.org or TDPL?

-- 
/Jacob Carlborg
Jan 12 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/11/2012 11:16 PM, Jacob Carlborg wrote:

 That's the whole point. It's not clear what the actual specification IS. Is it
 DMD, dlang.org or TDPL?


It's the "Language Reference" section on dlang.org.
Jan 12 2012
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 12/01/12 5:54 PM, Walter Bright wrote:

 On 1/11/2012 11:16 PM, Jacob Carlborg wrote:

 That's the whole point. It's not clear what the actual specification
 IS. Is it
 DMD, dlang.org or TDPL?


 It's the "Language Reference" section on dlang.org.


Yes, but there's differences between the language reference and what DMD 
implements. Sometimes the language reference is right, sometimes DMD is 
right. The point is, there's no way for us to know. Only you can decide 
what is right.

One example off the top of my head (there are many more):

 From the Lexical page on dlang.org

q{   } // error,   is not a valid D token

But DMD accepts this.

How do we know who is right and who is wrong? Should DMD reject that, or 
is the spec wrong?

The problem is exacerbated by the fact that DMD has lots of language 
bugs, so many people assume that the spec is right and DMD is wrong, but 
it's often the other way round!

You've said to post bugs, but these don't receive any attention. For 
example, here's two bugs about the lack of documentation on .stringof, 
one from 2009 and one from early 2011:

http://d.puremagic.com/issues/show_bug.cgi?id=3007
http://d.puremagic.com/issues/show_bug.cgi?id=5404

Neither of which have received any comments or clarifications.

If things are documented then the community will implement them and the 

lack of tutorials is because no one knows what D is, except you.

We need a real, up to date, and detailed language specification! Leave 
the implementation to us.

In fact, in many cases, all we need is a "DMD is right in this case" and 
we can even do the documentation!

I've already submitted a pull request for the q{   } issue above. Can 
someone please either reject it saying that it is wrong, or accept it so 
that we can move towards a more complete specification.

https://github.com/D-Programming-Language/d-programming-language.org/pull/27
Jan 12 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/12/2012 1:55 PM, Peter Alexander wrote:

 It's the "Language Reference" section on dlang.org.


 Yes, but there's differences between the language reference and what DMD
 implements. Sometimes the language reference is right, sometimes DMD is right.
 The point is, there's no way for us to know. Only you can decide what is right.


For each difference, somebody has to make a decision which is right. That 
doesn't mean the Language Reference is not the D specification. It can have 
errors in it like anything else.

The idea is to identify those discrepancies and get them fixed.


 One example off the top of my head (there are many more):

  From the Lexical page on dlang.org

 q{   } // error,   is not a valid D token

 But DMD accepts this.


Yes, and now your pull request on that has been pulled. Thanks! That issue is 
now resolved. On to the next one.


 You've said to post bugs, but these don't receive any attention. For example,
 here's two bugs about the lack of documentation on .stringof, one from 2009 and
 one from early 2011:

 http://d.puremagic.com/issues/show_bug.cgi?id=3007
 http://d.puremagic.com/issues/show_bug.cgi?id=5404

 Neither of which have received any comments or clarifications.


I'm sorry about that, but I'm running as fast as I can, along with the help of
a 
number of prolific contributors. As you can see by the changelog, there are a 
zillion issues that do get resolved every month.



 We need a real, up to date, and detailed language specification! Leave the
 implementation to us.


The only way to do it is to identify the issues one by one. I don't know of any 
other way.

(And a number of people have submitted improvements to the spec, some of them 
quite extensive, like Stewart Gordon's, which have been incorporated.)
Jan 12 2012
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 13/01/2012 06:08, Walter Bright wrote:

 I'm sorry about that, but I'm running as fast as I can, along with the
 help of a number of prolific contributors. As you can see by the
 changelog, there are a zillion issues that do get resolved every month.


Would it be useful if the pull auto tester set up its own git repository 
you could pull from? You'd do something to mark pull requests which look 
good, then the pull tester could queue them up to be merged, and merge 
as many as it can while still passing the testsuite... Then you can pull 
from there and get more requests tried and tested.

This is slightly advantageous as you don't have to spend time waiting to 
see if the test suite passes for each pull request, you can set them off 
before you go to bed and pull lots in the morning (the ones that worked).

Of course this requires some work to get it working in the first place...

-- 
Robert
http://octarineparrot.com/
Jan 13 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/13/2012 6:01 AM, Robert Clipsham wrote:

 Would it be useful if the pull auto tester set up its own git repository you
 could pull from? You'd do something to mark pull requests which look good, then
 the pull tester could queue them up to be merged, and merge as many as it can
 while still passing the testsuite... Then you can pull from there and get more
 requests tried and tested.

 This is slightly advantageous as you don't have to spend time waiting to see if
 the test suite passes for each pull request, you can set them off before you go
 to bed and pull lots in the morning (the ones that worked).

 Of course this requires some work to get it working in the first place...


Brad has already implemented this.
Jan 13 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/13/12 12:08 AM, Walter Bright wrote:

 You've said to post bugs, but these don't receive any attention. For
 example,
 here's two bugs about the lack of documentation on .stringof, one from
 2009 and
 one from early 2011:

 http://d.puremagic.com/issues/show_bug.cgi?id=3007
 http://d.puremagic.com/issues/show_bug.cgi?id=5404

 Neither of which have received any comments or clarifications.


 I'm sorry about that, but I'm running as fast as I can, along with the
 help of a number of prolific contributors. As you can see by the
 changelog, there are a zillion issues that do get resolved every month.


One important metric we currently neglect is the date of the oldest bug 
or pull request. If we work on improving that with each release, we give 
a submitter confidence that their bug will be resolved in reasonable 
time. A simple policy like "address the oldest 3 bugzilla entries in 
each release" would be very healthy.


Andrei
Jan 13 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 13-01-2012 16:05, Andrei Alexandrescu wrote:

 On 1/13/12 12:08 AM, Walter Bright wrote:

 You've said to post bugs, but these don't receive any attention. For
 example,
 here's two bugs about the lack of documentation on .stringof, one from
 2009 and
 one from early 2011:

 http://d.puremagic.com/issues/show_bug.cgi?id=3007
 http://d.puremagic.com/issues/show_bug.cgi?id=5404

 Neither of which have received any comments or clarifications.


 I'm sorry about that, but I'm running as fast as I can, along with the
 help of a number of prolific contributors. As you can see by the
 changelog, there are a zillion issues that do get resolved every month.


 One important metric we currently neglect is the date of the oldest bug
 or pull request. If we work on improving that with each release, we give
 a submitter confidence that their bug will be resolved in reasonable
 time. A simple policy like "address the oldest 3 bugzilla entries in
 each release" would be very healthy.


 Andrei


The voting system also needs to be paid more attention to. It seems 
largely ignored.

-- 
- Alex
Jan 13 2012
prev sibling next sibling parent "Dejan Lekic" <dejan.lekic gmail.com> writes:
 One important metric we currently neglect is the date of the 
 oldest bug or pull request. If we work on improving that with 
 each release, we give a submitter confidence that their bug 
 will be resolved in reasonable time. A simple policy like 
 "address the oldest 3 bugzilla entries in each release" would 
 be very healthy.


 Andrei


I agree 100%. Many developers of "open" software projects make a 
big mistake by ignoring users' feedbacks, and then wonder why 
people suddenly stop reporting problems, and even more 
importantly - why they stopped sending patches.

Well-done!
Jan 13 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-01-13 16:05, Andrei Alexandrescu wrote:

 On 1/13/12 12:08 AM, Walter Bright wrote:

 You've said to post bugs, but these don't receive any attention. For
 example,
 here's two bugs about the lack of documentation on .stringof, one from
 2009 and
 one from early 2011:

 http://d.puremagic.com/issues/show_bug.cgi?id=3007
 http://d.puremagic.com/issues/show_bug.cgi?id=5404

 Neither of which have received any comments or clarifications.


 I'm sorry about that, but I'm running as fast as I can, along with the
 help of a number of prolific contributors. As you can see by the
 changelog, there are a zillion issues that do get resolved every month.


 One important metric we currently neglect is the date of the oldest bug
 or pull request. If we work on improving that with each release, we give
 a submitter confidence that their bug will be resolved in reasonable
 time. A simple policy like "address the oldest 3 bugzilla entries in
 each release" would be very healthy.


 Andrei


I completely agree.

-- 
/Jacob Carlborg
Jan 13 2012
prev sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 13/01/12 3:05 PM, Andrei Alexandrescu wrote:

 On 1/13/12 12:08 AM, Walter Bright wrote:

 You've said to post bugs, but these don't receive any attention. For
 example,
 here's two bugs about the lack of documentation on .stringof, one from
 2009 and
 one from early 2011:

 http://d.puremagic.com/issues/show_bug.cgi?id=3007
 http://d.puremagic.com/issues/show_bug.cgi?id=5404

 Neither of which have received any comments or clarifications.


 I'm sorry about that, but I'm running as fast as I can, along with the
 help of a number of prolific contributors. As you can see by the
 changelog, there are a zillion issues that do get resolved every month.


 One important metric we currently neglect is the date of the oldest bug
 or pull request. If we work on improving that with each release, we give
 a submitter confidence that their bug will be resolved in reasonable
 time. A simple policy like "address the oldest 3 bugzilla entries in
 each release" would be very healthy.


Yes, this would be very good, although I suspect we would quickly hit 
roadblock bugs, i.e. ones that require a massive amount of work (e.g. 
64-bit Windows support) or those that require fundamental changes to the 
language and require extra consideration (e.g. const postblit).
Jan 13 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/13/12 1:16 PM, Peter Alexander wrote:

 On 13/01/12 3:05 PM, Andrei Alexandrescu wrote:

 On 1/13/12 12:08 AM, Walter Bright wrote:

 You've said to post bugs, but these don't receive any attention. For
 example,
 here's two bugs about the lack of documentation on .stringof, one from
 2009 and
 one from early 2011:

 http://d.puremagic.com/issues/show_bug.cgi?id=3007
 http://d.puremagic.com/issues/show_bug.cgi?id=5404

 Neither of which have received any comments or clarifications.


 I'm sorry about that, but I'm running as fast as I can, along with the
 help of a number of prolific contributors. As you can see by the
 changelog, there are a zillion issues that do get resolved every month.


 One important metric we currently neglect is the date of the oldest bug
 or pull request. If we work on improving that with each release, we give
 a submitter confidence that their bug will be resolved in reasonable
 time. A simple policy like "address the oldest 3 bugzilla entries in
 each release" would be very healthy.


 Yes, this would be very good, although I suspect we would quickly hit
 roadblock bugs, i.e. ones that require a massive amount of work (e.g.
 64-bit Windows support) or those that require fundamental changes to the
 language and require extra consideration (e.g. const postblit).


I understand. Such issues are not appropriate for bugzilla and should be 
best filed as language feature requests and directions to pursue. We 
need to make progress in managing the age of the oldest bug.

IMHO, fixing const postblit (and the last mile of const) an immediate 
issue, followed by shared and threads. In light of that, working on simd 
now appears even more like a waste of time.


Andrei
Jan 14 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 14, 2012 14:58:19 Andrei Alexandrescu wrote:

 IMHO, fixing const postblit (and the last mile of const) an immediate
 issue, followed by shared and threads. In light of that, working on simd
 now appears even more like a waste of time.


I completely agree that const and shared issues are more important than SIMD, 
given that they affect far more people and have to do with some of the most 
frustrating bugs. So, I'm not sure that this work on SIMD is particularly 
well-timed. But I very much doubt that it's a waste of time. It could really 
help make D acceptable to some of the folks who would otherwise insist on 
using C or C++ for efficiency. And it's definitely addressing the complaints of 
some of D's users. Still, I'd very much like to see the remaining core 
language issues resolved sooner rather than implement enhancements like this 
right now.

- Jonathan M Davis
Jan 14 2012
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 I completely agree that const and shared issues are more important than SIMD, 
 given that they affect far more people and have to do with some of the most 
 frustrating bugs. So, I'm not sure that this work on SIMD is particularly 
 well-timed. But I very much doubt that it's a waste of time.


A lot of time ago Walter said that bugs are not all equal, some of them are
much more important than others. At that time I didn't fully understand his
words.

Now I am compiling DMD every time some bugs get fixed. And I have seen that
only a small percentage of those bug fixes has a big influence on my D2 code.
When one of such bugs gets fixed, I am able to remove work-arounds, make my
code more readable, introduce simpler or shorter idioms, they increase my
pleasure of using D2.

So I hope to see fixed every month some of such special bugs :-)

Bye and thank you,
bearophile
Jan 14 2012
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2012-01-15 01:06:23 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:


 On Saturday, January 14, 2012 14:58:19 Andrei Alexandrescu wrote:

 IMHO, fixing const postblit (and the last mile of const) an immediate
 issue, followed by shared and threads. In light of that, working on simd
 now appears even more like a waste of time.


 
 I completely agree that const and shared issues are more important than SIMD,
 given that they affect far more people and have to do with some of the most
 frustrating bugs. So, I'm not sure that this work on SIMD is particularly
 well-timed. But I very much doubt that it's a waste of time. It could really
 help make D acceptable to some of the folks who would otherwise insist on
 using C or C++ for efficiency. And it's definitely addressing the complaints of
 some of D's users. Still, I'd very much like to see the remaining core
 language issues resolved sooner rather than implement enhancements like this
 right now.


Still, Walter perfectly has the right to decide on what he wants to 
work. I understand that he saw implementing SIMD as an interesting 
challenge, and if working on SIMD keeps things interesting for him, 
that can only be great.

Fixing long standing bugs is boring stuff compared to that. Yes it's 
important, but does it needs to be Walter doing it? Even for an issue 
requiring a language change, couldn't someone design the language 
change, implements it, and create a pull request for it? Then it'd be 
up to Walter to look at it, ask for amendments, then accept it or 
reject it…

Looks good in theory, but in practice this approach hasn't worked very 
well for pull request number 3.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Jan 14 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 14, 2012 20:54:55 Michel Fortin wrote:

 Still, Walter perfectly has the right to decide on what he wants to
 work. I understand that he saw implementing SIMD as an interesting
 challenge, and if working on SIMD keeps things interesting for him,
 that can only be great.


Sure. I can understand why the most important thing to work  on might n=
ot be=20
the most interesting thing to work on. And Walter certainly has the rig=
ht to=20
work on whatever he wants to work on. It could even be that if the more=
=20
important stuff is tedious enough, working on something new and interes=
ting=20
could make it so that Walter is able to make progress on the more impor=
tant=20
stuff more quickly when he does work on it. But from the perspective of=
 the=20
language and community at large, SIMD support is great to have but not =
at all=20
the thing that we need the most.

Regardless, I don't wish to make a big deal about it. I was just echoin=
g=20
Andrei's sentiment that there are more important things to be working o=
n than=20
SIMD support right now.


 Fixing long standing bugs is boring stuff compared to that. Yes it's
 important, but does it needs to be Walter doing it? Even for an issue=



 requiring a language change, couldn't someone design the language
 change, implements it, and create a pull request for it? Then it'd be=



 up to Walter to look at it, ask for amendments, then accept it or
 reject it=E2=80=A6
=20
 Looks good in theory, but in practice this approach hasn't worked ver=


y

 well for pull request number 3.


It seems that the problem is that while Walter can be saved effort by h=
aving=20
someone else do that kind of work, it doesn't necessarily save him all =
that=20
much effort, since he still must ultimately take the time to fully unde=
rstand=20
what's being changed and what the implications are before he merges it =
in. And=20

sense if=20
it takes longer for it to be sorted out. Still, given the importance of=
 pull=20

ooner=20
than this. It's getting very close to being a year old.

- Jonathan M Davis
Jan 14 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/14/12 9:06 PM, Jonathan M Davis wrote:

 On Saturday, January 14, 2012 20:54:55 Michel Fortin wrote:

 Still, Walter perfectly has the right to decide on what he wants to
 work. I understand that he saw implementing SIMD as an interesting
 challenge, and if working on SIMD keeps things interesting for him,
 that can only be great.


 Sure. I can understand why the most important thing to work  on might not be
 the most interesting thing to work on. And Walter certainly has the right to
 work on whatever he wants to work on.


Exactly and perfectly right. To add to that, with my limited time, I can 
hardly afford to work on stuff that isn't fun (although lately I've done 
some of it - e.g. I'm not a web designer). There comes a point, however, 
when we need to decide whether our main priority is having fun or making 
D successful.

In the latter case:

1. SIMD is not the top of the list. Two weeks ago it wasn't _on_ the 
list. Now it's like the last 'copter outta Saigon.

2. We haven't identified game designers as a core market, and one that's 
more important than e.g. general purpose programmers who need the like 
of working qualifiers, multithreading, and shared libraries.

3. There was never a promise or even a mention that we'll deliver SIMD. 
We virtually promise we deliver threads and expressive qualifiers, and 
there's still work to do on that.

4. There was broad agreement that the main foci going forward would be 
quality, expressive qualifiers, shared libraries, Phobos work, and 
publicizing the language. We can't work with and publicize D's awesome 
concurrency design if parts of it aren't implemented.

5. The SIMD work has _zero_ acceleration on existing code; it only 
allows experts to write non-portable code that uses SIMD instructions. 
Updating to the next release of dmd has zero SIMD-related benefit to 
statistically our entire user base.

Walter and I spend hours on the phone discussing strategies and tactics 
to make D more successful. And then comes this binge. Doing anything on 
SIMD now is a mistake that I am sorry I was unable to stop. About the 
only thing that's good about it all is that it'll be over soon.


Andrei
Jan 14 2012
next sibling parent Gour <gour atmarama.net> writes:
On Sat, 14 Jan 2012 21:31:14 -0600
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 In the latter case:
=20
 1. SIMD is not the top of the list. Two weeks ago it wasn't _on_ the=20
 list. Now it's like the last 'copter outta Saigon.
=20
 2. We haven't identified game designers as a core market, and one
 that's more important than e.g. general purpose programmers who need
 the like of working qualifiers, multithreading, and shared libraries.
=20
 3. There was never a promise or even a mention that we'll deliver
 SIMD. We virtually promise we deliver threads and expressive
 qualifiers, and there's still work to do on that.
=20
 4. There was broad agreement that the main foci going forward would
 be quality, expressive qualifiers, shared libraries, Phobos work, and=20
 publicizing the language. We can't work with and publicize D's
 awesome concurrency design if parts of it aren't implemented.
=20
 5. The SIMD work has _zero_ acceleration on existing code; it only=20
 allows experts to write non-portable code that uses SIMD
 instructions. Updating to the next release of dmd has zero
 SIMD-related benefit to statistically our entire user base.


Very nicely put together. Thank you for that.


 Walter and I spend hours on the phone discussing strategies and
 tactics to make D more successful. And then comes this binge. Doing
 anything on SIMD now is a mistake that I am sorry I was unable to
 stop. About the only thing that's good about it all is that it'll be
 over soon.


It looks as some of the GTD wisdom to choose the rigt NextActions would
be beneficial in D community. ;)


Sincerely,
Gour


--=20
Everyone is forced to act helplessly according to the qualities=20
he has acquired from the modes of material nature; therefore no=20
one can refrain from doing something, not even for a moment.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Jan 15 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Sun, 15 Jan 2012 04:31:14 +0100, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 1/14/12 9:06 PM, Jonathan M Davis wrote:

 On Saturday, January 14, 2012 20:54:55 Michel Fortin wrote:

 Still, Walter perfectly has the right to decide on what he wants to
 work. I understand that he saw implementing SIMD as an interesting
 challenge, and if working on SIMD keeps things interesting for him,
 that can only be great.


 Sure. I can understand why the most important thing to work  on might  
 not be
 the most interesting thing to work on. And Walter certainly has the  
 right to
 work on whatever he wants to work on.


 Exactly and perfectly right. To add to that, with my limited time, I can  
 hardly afford to work on stuff that isn't fun (although lately I've done  
 some of it - e.g. I'm not a web designer). There comes a point, however,  
 when we need to decide whether our main priority is having fun or making  
 D successful.

 In the latter case:

 1. SIMD is not the top of the list. Two weeks ago it wasn't _on_ the  
 list. Now it's like the last 'copter outta Saigon.

 2. We haven't identified game designers as a core market, and one that's  
 more important than e.g. general purpose programmers who need the like  
 of working qualifiers, multithreading, and shared libraries.

 3. There was never a promise or even a mention that we'll deliver SIMD.  
 We virtually promise we deliver threads and expressive qualifiers, and  
 there's still work to do on that.

 4. There was broad agreement that the main foci going forward would be  
 quality, expressive qualifiers, shared libraries, Phobos work, and  
 publicizing the language. We can't work with and publicize D's awesome  
 concurrency design if parts of it aren't implemented.

 5. The SIMD work has _zero_ acceleration on existing code; it only  
 allows experts to write non-portable code that uses SIMD instructions.  
 Updating to the next release of dmd has zero SIMD-related benefit to  
 statistically our entire user base.

 Walter and I spend hours on the phone discussing strategies and tactics  
 to make D more successful. And then comes this binge. Doing anything on  
 SIMD now is a mistake that I am sorry I was unable to stop. About the  
 only thing that's good about it all is that it'll be over soon.


 Andrei


This is a huge selling point.
     float4 v1,v2,v3;
     v1 = v2;
     v1 = v2 + v3;
     v1 = v2 - v3;
     v1 = v2 * v3;
     v1 = v2 / v3;

Considering the recent switch to XMM it was just opportune to do
this now rather than later. Context switches are expensive.

martin
Jan 15 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 15, 2012 10:05:34 Martin Nowak wrote:

 This is a huge selling point.
      float4 v1,v2,v3;
      v1 = v2;
      v1 = v2 + v3;
      v1 = v2 - v3;
      v1 = v2 * v3;
      v1 = v2 / v3;


I think that the main point is that it is _not_ a big selling point for the 
majority of users, whereas things that the language has already promised to do 
are not currently working properly. So, for the vast majority of users, what's 
currently being worked on does not match what the highest priorities are.

It would be one thing to add SIMD support if there weren't major issues which 
are causing problems for the majority of users. It's quite another when there 
_are_ such issues.


 Considering the recent switch to XMM it was just opportune to do
 this now rather than later. Context switches are expensive.


That may be true. And maybe SIMD will be taken care of more efficiently this 
way, but it doesn't match what's supposed to be the main priorities right now.

- Jonathan M Davis
Jan 15 2012
prev sibling next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 15/01/12 3:31 AM, Andrei Alexandrescu wrote:

 1. SIMD is not the top of the list. Two weeks ago it wasn't _on_ the
 list. Now it's like the last 'copter outta Saigon.


That's not true. SIMD intrinsics has always been on the list. I've only 
been in this newsgroup for a year or so, but I've definitely seen D's 
lack of SIMD support mentioned in several discussions so far. It's a 
frequent complaint about the language.



 2. We haven't identified game designers as a core market, and one that's
 more important than e.g. general purpose programmers who need the like
 of working qualifiers, multithreading, and shared libraries.


Game programming is quite clearly a very large market for D. The game 
industry is perhaps one of the largest software industries that still 
relies on having C/C++ level of efficiency and low-level access. It's 
also an industry that is absolutely sick of having to use C++. D is 
quite close to the perfect language for game developers.

I think it's also telling that perhaps the most prolific (ex-)D coder, 
Tomasz, was a game programmer, and that one of the largest D libraries 
is Derelict, which is also aimed at games.

Finally, if you look at the dsource projects, 
http://dsource.org/projects/ you'll see that Games make up quite a large 
chunk of what people are using D for.

What do you think our core market is?



 3. There was never a promise or even a mention that we'll deliver SIMD.
 We virtually promise we deliver threads and expressive qualifiers, and
 there's still work to do on that.


Fair point.



 4. There was broad agreement that the main foci going forward would be
 quality, expressive qualifiers, shared libraries, Phobos work, and
 publicizing the language. We can't work with and publicize D's awesome
 concurrency design if parts of it aren't implemented.


I suspect that SIMD support will greatly help to publicize the language.



 5. The SIMD work has _zero_ acceleration on existing code; it only
 allows experts to write non-portable code that uses SIMD instructions.
 Updating to the next release of dmd has zero SIMD-related benefit to
 statistically our entire user base.


Where are you getting the figures for the % of people that will benefit 
from SIMD support? The SIMD support thread is rather large, so that 
suggests to me that a significant number of people are quite interested 
in the SIMD work.



 Walter and I spend hours on the phone discussing strategies and tactics
 to make D more successful. And then comes this binge. Doing anything on
 SIMD now is a mistake that I am sorry I was unable to stop. About the
 only thing that's good about it all is that it'll be over soon.


I can't speak on your private conversations with Walter, but I think 
you're underestimating how important SIMD support is for D.

Also, it appears (from his rate of progress) that Walter is quite 
enjoying the SIMD work. I see no harm in a short-lived "binge" if it 
reinvigorates Walter's interest in compiler work -- especially if you 
please a large part of the community in the process.
Jan 15 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/15/12 5:30 AM, Peter Alexander wrote:

 On 15/01/12 3:31 AM, Andrei Alexandrescu wrote:

 1. SIMD is not the top of the list. Two weeks ago it wasn't _on_ the
 list. Now it's like the last 'copter outta Saigon.


 That's not true. SIMD intrinsics has always been on the list. I've only
 been in this newsgroup for a year or so, but I've definitely seen D's
 lack of SIMD support mentioned in several discussions so far. It's a
 frequent complaint about the language.


I made a cursory search and the last thread before nowadays is 
"Vectorizations intrinsics for DMD?" started on 2/6/11 by... Peter 
Alexander.


 2. We haven't identified game designers as a core market, and one that's
 more important than e.g. general purpose programmers who need the like
 of working qualifiers, multithreading, and shared libraries.


 Game programming is quite clearly a very large market for D.


We've never identified it as such. My perception is that adoption of D 
is much larger in other industries (while still small in absolute numbers).


 The game
 industry is perhaps one of the largest software industries that still
 relies on having C/C++ level of efficiency and low-level access. It's
 also an industry that is absolutely sick of having to use C++. D is
 quite close to the perfect language for game developers.

 I think it's also telling that perhaps the most prolific (ex-)D coder,
 Tomasz, was a game programmer, and that one of the largest D libraries
 is Derelict, which is also aimed at games.

 Finally, if you look at the dsource projects,
 http://dsource.org/projects/ you'll see that Games make up quite a large
 chunk of what people are using D for.

 What do you think our core market is?


Walter and I think that our core market consists of general purpose 
programmers who don't want to compromise one of productivity and code 
efficiency in their work. This group includes programmers in other 
languages than C++.


 3. There was never a promise or even a mention that we'll deliver SIMD.
 We virtually promise we deliver threads and expressive qualifiers, and
 there's still work to do on that.


 Fair point.


Fair is not the half of it. As a speaker and ambassador of D, it is 
difficult for me to stay with the conservative examples, being unable to 
showcase the really strong differentiating features because they're 
insufficiently implemented.


 4. There was broad agreement that the main foci going forward would be
 quality, expressive qualifiers, shared libraries, Phobos work, and
 publicizing the language. We can't work with and publicize D's awesome
 concurrency design if parts of it aren't implemented.


 I suspect that SIMD support will greatly help to publicize the language.


I don't. I have zero evidence to believe that claim. Not one reader or 
one attendee asked me about that. They ask me about things such as (a) 
compiler quality; (b) concurrency; (c) availability on non-Intel 
platforms; (d) libraries, including the frequent "algorithms are cool, 
but when will you have STL-like containers?" Thank God the question 
"what's the deal with D1/D2 and Phobos/Tango?" is not asked anymore. 
Announcing support cessation for D1 must have been the best decision we 
took in 2011.


 5. The SIMD work has _zero_ acceleration on existing code; it only
 allows experts to write non-portable code that uses SIMD instructions.
 Updating to the next release of dmd has zero SIMD-related benefit to
 statistically our entire user base.


 Where are you getting the figures for the % of people that will benefit
 from SIMD support? The SIMD support thread is rather large, so that
 suggests to me that a significant number of people are quite interested
 in the SIMD work.


I think it's tempting but inaccurate to gather numbers from the thread. 
I predict SIMD support will come and stay, and it will make no impact on D.


 Walter and I spend hours on the phone discussing strategies and tactics
 to make D more successful. And then comes this binge. Doing anything on
 SIMD now is a mistake that I am sorry I was unable to stop. About the
 only thing that's good about it all is that it'll be over soon.


 I can't speak on your private conversations with Walter, but I think
 you're underestimating how important SIMD support is for D.


I understand. I think you're overestimating it. The future will tell.


 Also, it appears (from his rate of progress) that Walter is quite
 enjoying the SIMD work. I see no harm in a short-lived "binge" if it
 reinvigorates Walter's interest in compiler work -- especially if you
 please a large part of the community in the process.


Yes. Totally agree. The way I see it, it's a welcome vacation.


Andrei
Jan 15 2012
parent reply Kiith-Sa <42 theanswer.com> writes:
I'm interested in game development using D, so I'll post my opinion.

I think the discussions here show how particularly specialized people
here are. I've seen some Manu's posts and it was clear that he is a person
in gamedev who thinks most development is like gamedev and can't see the bigger
picture. For a gamedev person, SIMD support is not simply a cool feature, it's
a gamechanger. Just like const, ranges, D threading features and so on.
However, 
his posts often show that he doesn't understand positions of other people in
other 
areas, e.g. people here working on scientific computing, who are also interested
in SIMD but their thinking of terms such as "vector" is completely different.

I think you're making the same mistake here - you have very little (or no?)
idea about gamedev and aren't exposed to game programmers, so you just assume 
specific gamedev issues don't exist or are unimportant. I don't think you get
much of exposure to game devs when evangelizing D either - you don't evangelize
D in game companies.


For me, SIMD support is extremely important. I can live without it, because I'm
not working on some AAA title that needs to squeeze every last bit of 
performance from a PC/PS3/ARM phone or whatever (I'm an open source dev - doing
this for fun). But regardless it's bean a great disadvantage until now that the
only way to use SIMD was inline ASM which also happe

Also, I have been trying to evangelize D in my environment - an university 
(UPJS in Kosice, Slovakia) - and to other people who do game development as a 
hobby. The fact that there have been no SIMD intrinsics has been a disadvantage
when promoting D - in fact, I know at least one person who considered D for
his project and did _not_ use it due to that.

Furthermore, I think we can get even better than C/C++ compiler's vendor's 
solutions by creating portable Phobos modules that would encapsulate the 
platform-specific intrinsics - e.g. to provide basic vector and matrix structs
which are present in every game project and usually always implemented from 
scratch (in particular, I think the gl3n library, which was recently announced
and provides a very nice GLSL-plus-improvements syntax, could be built on top
of the SIMD intrinsics).

A game-oriented linear algebra module backed by SIMD in Phobos would be 
superior to the approach taken by various C/C++ compiler/library vendors - 
where the code must be rewritten for each compiler.

I could use that to better promote D.

D happens to be pretty much the perfect language for game development - the GC
scares people away but I found the combination of GC-in-most-code and 
manually-managed-critical-stuff to work quite well.

have been moving - and C++ is just getting obsolete

You also seem to be unaware of the size of game development industry - this is
in fact one of the largest software development industries that still needs a
systems programming language. You shouldn't underestimate that just because you
don't frequently come into contact with game developers.


To be clear: I'm not saying that fixing the advertised features is unimportant.
In fact, the greatest problems I see in promoting D are that we don't even
have finished containers in the API - and that many features described in TDPL
don't work correctly. But I find the statement that SIMD is a waste of time,
or, for that matter, that it will help little in promoting D's adoption - to
be completely incorrect.
Jan 15 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 15, 2012 18:42:25 Kiith-Sa wrote:

 To be clear: I'm not saying that fixing the advertised features is
 unimportant. In fact, the greatest problems I see in promoting D are that
 we don't even have finished containers in the API - and that many features
 described in TDPL don't work correctly. But I find the statement that SIMD
 is a waste of time, or, for that matter, that it will help little in
 promoting D's adoption - to be completely incorrect.



I think that given what D is setting out to do, game developers are among its 
target user base and that if we can add features to the language or libraries 
which make D more reasonable for them, that's great. Having SIMD support is 
definitely not a bad thing. Personally, I will _never_ use it, but it's 
something that C/C++ can do on many compilers and having that in D doesn't 
hurt people like me who don't care about the feature at all.

The problem is that there are more important things that not only affect game 
developers but affect developers in general which D already promises to do but 
fails to do. So, stuff like SIMD should be relatively low on the priority list 
until the more general purpose features have been fully implemented. And given 
that the general purpose stuff _also_ affects the game devs, I would have 
thought that they'd also really want that fixed soon, just like everyone else. 
Some of the same people who are clamoring for SIMD have been clamoring for 
fixes to const.

Walter is free to spend his time how he chooses. I don't really want to bash 
him for going off and doing something different and interesting, but I do think 
that from the perspective of the D community at large, the SIMD work is not 
something that's high enough on the priority list to be done right now. 
Eventually, yes, but not now.

So, hopefully it doesn't take much longer for the SIMD stuff to be sorted out, 
and then progress can be made on the more general purpose stuff again.

- Jonathan M Davis
Jan 15 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/15/12 11:42 AM, Kiith-Sa wrote:

 I'm interested in game development using D, so I'll post my opinion.

 I think the discussions here show how particularly specialized people
 here are. I've seen some Manu's posts and it was clear that he is a person
 in gamedev who thinks most development is like gamedev and can't see the bigger
 picture. For a gamedev person, SIMD support is not simply a cool feature, it's
 a gamechanger. Just like const, ranges, D threading features and so on.
However,
 his posts often show that he doesn't understand positions of other people in
other
 areas, e.g. people here working on scientific computing, who are also
interested
 in SIMD but their thinking of terms such as "vector" is completely different.

 I think you're making the same mistake here - you have very little (or no?)
 idea about gamedev and aren't exposed to game programmers, so you just assume
 specific gamedev issues don't exist or are unimportant. I don't think you get
 much of exposure to game devs when evangelizing D either - you don't evangelize
 D in game companies.


[snip]

You are making a good point, and I'm glad you chimed in.

I do have ties with the gaming community; I taught a course at ENDI and 
I am well acquainted with a few game developers. Also, at conferences 
and events gaming programmers are represented. Finally, game developers 
who are reading TDPL are likely to send me book feedback and questions 
in proportion to their representation. From where I stand, I can say 
there is more interest in D in other communities than in gaming.

Clearly gamedev-specific issues do exist and are important. But that's 
not even remotely the point. Allow me to explain.

Say we identified gaming programmers as an important community to 
address. If that happened, we would have done a /lot/ of things 
differently, and a ton of them before SIMD. That means focus on 
Windows64, graphic accelerators, and gaming CPUs. To claim that work on 
SIMD is good because it's good for gamers is to reverse engineer a 
rationalization after the fact. And the fact is - Walter has had the 
gusto to implement SIMD now. Technically, that's great. For gamers, 
that's an interesting development. Organizationally, that's a poor 
statement.

Again: if D is a hobby we have, all's great. Otherwise, we must show 
people that we are serious about finishing the core language 
implementation, that we make promises that we are able to keep, and that 
we make plans that we follow even in the broadest strokes. If we want to 
play with the big boys, we need to change the way we approach planning 
and organization quite drastically.


Andrei
Jan 15 2012
next sibling parent reply Gour <gour atmarama.net> writes:
On Sun, 15 Jan 2012 18:23:38 -0600
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 Again: if D is a hobby we have, all's great. Otherwise, we must show=20
 people that we are serious about finishing the core language=20
 implementation, that we make promises that we are able to keep, and
 that we make plans that we follow even in the broadest strokes. If we
 want to play with the big boys, we need to change the way we approach
 planning and organization quite drastically.


Thank you Andrei for this post...it's the essence of the problem!!

Playing with compiler & language features, running some (artificial)
benchmarks to compare with other languages etc. is nice for a hobby
project and may attract hobby programmers, but making language & 8its
ecoysstem attractive for serious projects is not so easy.

Whenever we mention D as the language for our project, we always get the
feedback it's not safe investment of our time & energy and it would be
better to use something else, either C(++), Java, Scala, Python etc.

Recently I was evaluating one CMS written in one popular Python
framework and after reporting bug which makes it unusable for even
simple page layout, hearing nothing from the developer and then seeing
it's fixed after more than two months, it was not difficult to abandon
idea to base our sites on such a product.

This is one of the comments I got in Oct '10 when asking at SO: "Based
on this i lost all hope that D has enough developers to be a save
language pick for a company doing a larger mission critical application.
You will fight with the tool chain and even pray to go back to C++
often."

I know that many things improved in D, but the question remains how much
the public opinion is channging? (I know that users still speak about
lighttpd leaking memory, and it's not easy to get rid of it.)


Sincerely,
Gour


--=20
The working senses are superior to dull matter; mind is higher=20
than the senses; intelligence is still higher than the mind;=20
and he [the soul] is even higher than the intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Jan 16 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/16/2012 12:00 AM, Gour wrote:

 Recently I was evaluating one CMS written in one popular Python
 framework and after reporting bug which makes it unusable for even
 simple page layout, hearing nothing from the developer and then seeing
 it's fixed after more than two months, it was not difficult to abandon
 idea to base our sites on such a product.



Your other ideas are well considered, but I have to take issue with this one.

I have submitted many, many bug reports over the decades to Major Software 
Vendors with well supported software products.

How many times have I gotten anything other than a robo-reply?

     zero

When my company has paid $ in the 5 figures for "premium" tech service, what is 
the response to bug reports?

     nothing

     -- or --

     that's not a bug

     -- or --

     you're a unique snowflake and nobody else has that problem
     so we won't fix it

How many times has a bug I reported ever been fixed, even waiting a year for
the 
next update?

     zero

I take that back. One time I got so mad about this I contacted the CEO of the 
Major Software Vendor (I knew him personally) and he got out a crowbar, went to 
see the dev team, and (allegedly) thwacked a few of them. The bug still never 
got fixed, but I got an acknowledgment.

This has obviously never impeded anyone from using their software tools.

It's also why:

1. I never bother filing bug reports to Major Software Vendors anymore.

2. With Digital Mars products, anyone can file a bug report with Bugzilla 
without needing me to acknowledge or filter it.

3. Anyone can read and comment on those bug reports.

4. I think we've had great success using Github and allowing anyone to fork & 
fix & publish.

I know our response to bug reports is far from perfect, but at least we aren't 
hiding under a rock.

It's also true that if a company wanted to bet the farm on D, and were willing 
to put some money behind it, their concerns would get priority, as full time 
professional developers could get hired to do it.
Jan 16 2012
next sibling parent reply Gour <gour atmarama.net> writes:
On Mon, 16 Jan 2012 20:32:40 -0800
Walter Bright <newshound2 digitalmars.com> wrote:


 Your other ideas are well considered, but I have to take issue with
 this one.


OK.


 4. I think we've had great success using Github and allowing anyone
 to fork & fix & publish.


I apologize for my (poor) attempt to illustrate Adrei's "Otherwise, we
must show people that we are serious about finishing the core language
implementation, that we make promises that we are able to keep, and that
we make plans that we follow even in the broadest strokes." and my post
was in no way trying to minimize community work when handling bug
reports. At the end, I never submitted even the single bug report, so it
wouldn't be fair to criticize it.

My example was just meant to show what might be the result when one
feels that developers are not behind their product in a sense that one
'cannot count on the project' which was supposed to be continuation on
my "we always get the feedback it's not safe investment of our time &
energy and it would be better to use something else, either C(++), Java,
Scala, Python etc."

So, I highly admire the work of all members within D community giving
something valuable for free, but being interested in success of D, I
wanted to share my experience I have when trying to advocate using of D
for real (open-source) projects *today*.

I'll try to be more sensitive next time...


Sincerely,
Gour

--=20
What is night for all beings is the time of awakening=20
for the self-controlled; and the time of awakening for=20
all beings is night for the introspective sage.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Jan 17 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/17/2012 2:07 AM, Gour wrote:

 My example was just meant to show what might be the result when one
 feels that developers are not behind their product in a sense that one
 'cannot count on the project' which was supposed to be continuation on
 my "we always get the feedback it's not safe investment of our time&
 energy and it would be better to use something else, either C(++), Java,
 Scala, Python etc."

 So, I highly admire the work of all members within D community giving
 something valuable for free, but being interested in success of D, I
 wanted to share my experience I have when trying to advocate using of D
 for real (open-source) projects *today*.

 I'll try to be more sensitive next time...


I'm not taking issue with sensitivity, just that one is *less* likely to get 
responsive bug fixes from Major Software Vendor, and so dismissing D for that 
reason is invalid.

I've seen people say "D doesn't have feature X, so I'm going to use language
B." 
But B doesn't have feature X, either. Again, the reason given is invalid.

The real issue is something they're not telling you. The trick is finding out 
the real issue, which can take some insight. Otherwise, you'll waste a lot of 
effort chasing rainbows.

Sometimes, the real issue is "nobody ever got fired for buying IBM." You could 
fix every issue on their list, and you still won't close the deal, because you 
are not IBM. You cannot please everyone, it's better to recognize who you *can* 
close the deal with (there's always someone who is not impressed by IBM), and 
work on their issues rather than the rainbows and smokescreens.

That means focus on what we are good at.
Jan 17 2012
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/17/12 4:52 AM, Walter Bright wrote:

 On 1/17/2012 2:07 AM, Gour wrote:

 My example was just meant to show what might be the result when one
 feels that developers are not behind their product in a sense that one
 'cannot count on the project' which was supposed to be continuation on
 my "we always get the feedback it's not safe investment of our time&
 energy and it would be better to use something else, either C(++), Java,
 Scala, Python etc."

 So, I highly admire the work of all members within D community giving
 something valuable for free, but being interested in success of D, I
 wanted to share my experience I have when trying to advocate using of D
 for real (open-source) projects *today*.

 I'll try to be more sensitive next time...


 I'm not taking issue with sensitivity, just that one is *less* likely to
 get responsive bug fixes from Major Software Vendor, and so dismissing D
 for that reason is invalid.

 I've seen people say "D doesn't have feature X, so I'm going to use
 language B." But B doesn't have feature X, either. Again, the reason
 given is invalid.


This is often mentioned, so I, too, thought about it a fair amount. I 
think it would be hasty to simplify that judgment.

I think the reasoning goes like this:

1. D lacks feature X that is often needed during the use of language B, 
which lacks it too.

2. The person reasons they'll see advantage in switching to a language 
if it did have X.

3. D doesn't, so the proposition of making the effort to switch from B 
is less appealing.

Similar lines of thinking may go about features that B has and D 
doesn't, or about features that both B and D have but D implements them 
poorly, or about promising differentiating features that D has that 
don't work reliably.


Andrei
Jan 17 2012
parent dolive <dolive89 sina.com> writes:
Andrei Alexandrescu Wrote:


 On 1/17/12 4:52 AM, Walter Bright wrote:

 On 1/17/2012 2:07 AM, Gour wrote:

 My example was just meant to show what might be the result when one
 feels that developers are not behind their product in a sense that one
 'cannot count on the project' which was supposed to be continuation on
 my "we always get the feedback it's not safe investment of our time&
 energy and it would be better to use something else, either C(++), Java,
 Scala, Python etc."

 So, I highly admire the work of all members within D community giving
 something valuable for free, but being interested in success of D, I
 wanted to share my experience I have when trying to advocate using of D
 for real (open-source) projects *today*.

 I'll try to be more sensitive next time...


 I'm not taking issue with sensitivity, just that one is *less* likely to
 get responsive bug fixes from Major Software Vendor, and so dismissing D
 for that reason is invalid.

 I've seen people say "D doesn't have feature X, so I'm going to use
 language B." But B doesn't have feature X, either. Again, the reason
 given is invalid.


 
 This is often mentioned, so I, too, thought about it a fair amount. I 
 think it would be hasty to simplify that judgment.
 
 I think the reasoning goes like this:
 
 1. D lacks feature X that is often needed during the use of language B, 
 which lacks it too.
 
 2. The person reasons they'll see advantage in switching to a language 
 if it did have X.
 
 3. D doesn't, so the proposition of making the effort to switch from B 
 is less appealing.
 
 Similar lines of thinking may go about features that B has and D 
 doesn't, or about features that both B and D have but D implements them 
 poorly, or about promising differentiating features that D has that 
 don't work reliably.
 
 
 Andrei


Solve d1, d2 to compatibility issues , Let d1 be popular , it¡®s are the
current balanced each side the best way to , can be quiet and wait for the
maturity of d2 .

thank's all

dolive
Jan 18 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 17/01/2012 11:52, Walter Bright a écrit :

 On 1/17/2012 2:07 AM, Gour wrote:

 My example was just meant to show what might be the result when one
 feels that developers are not behind their product in a sense that one
 'cannot count on the project' which was supposed to be continuation on
 my "we always get the feedback it's not safe investment of our time&
 energy and it would be better to use something else, either C(++), Java,
 Scala, Python etc."

 So, I highly admire the work of all members within D community giving
 something valuable for free, but being interested in success of D, I
 wanted to share my experience I have when trying to advocate using of D
 for real (open-source) projects *today*.

 I'll try to be more sensitive next time...


 I'm not taking issue with sensitivity, just that one is *less* likely to
 get responsive bug fixes from Major Software Vendor, and so dismissing D
 for that reason is invalid.

 I've seen people say "D doesn't have feature X, so I'm going to use
 language B." But B doesn't have feature X, either. Again, the reason
 given is invalid.

 The real issue is something they're not telling you. The trick is
 finding out the real issue, which can take some insight. Otherwise,
 you'll waste a lot of effort chasing rainbows.

 Sometimes, the real issue is "nobody ever got fired for buying IBM." You
 could fix every issue on their list, and you still won't close the deal,
 because you are not IBM. You cannot please everyone, it's better to
 recognize who you *can* close the deal with (there's always someone who
 is not impressed by IBM), and work on their issues rather than the
 rainbows and smokescreens.

 That means focus on what we are good at.


Switching has a cost in itself. To trigger change, you don't need to 
provide something more, but that is not enough. You need to provide 
enough to make the benefit of switching bigger than the cost that comes 
with swithing.

And that is only if you are rationnal. If you consider basic psychology, 
you'll notice that effect like cognitive dissonance and you'll notice 
that things are even worse. This is not fair, I do agree, but this is 
the world we live in.

As a last point, I'll mention that using D has obvious drawbacks : lack 
of documentation, lack of support, not that many exemple, compiler bugs, 
limited IDE integration, limited toolchain, etc . . . So this is 
rationnal to choose another language if both have the needed feature.
Jan 18 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2012 12:30 PM, deadalnix wrote:

 Switching has a cost in itself. To trigger change, you don't need to provide
 something more, but that is not enough. You need to provide enough to make the
 benefit of switching bigger than the cost that comes with swithing.

 And that is only if you are rationnal. If you consider basic psychology, you'll
 notice that effect like cognitive dissonance and you'll notice that things are
 even worse. This is not fair, I do agree, but this is the world we live in.


I fully understand that and agree with it. That is why I am often skeptical of 
the reason given for not switching - my experience is that it is likely not the 
real reason. It takes some digging and insight to get at the real reason.

Not understanding the real reasons leads us to waste effort solving the wrong 
problems.



 As a last point, I'll mention that using D has obvious drawbacks : lack of
 documentation, lack of support, not that many exemple, compiler bugs, limited
 IDE integration, limited toolchain, etc . . . So this is rationnal to choose
 another language if both have the needed feature.


Those are drawbacks, indeed, but sometimes are given as rationalizations for 
what might be other reasons entirely.

For example, let's assume we're talking to an expert Java developer. He has 
spent the last 10 years becoming an expert in every detail of Java. He's at the 
top of the Java community, and at the top of his game. Is he going to switch to 
D? Pretty unlikely, as now he'd be discarding a big chunk of that hard-won, 
valuable expertise. Is he going to give that as the reason for not switching? 
Not a chance.

(Andrei is a remarkable exception.)

We can beat ourselves to a bloody pulp trying to entice them to switch, or we 
can engage more fertile ground, which are the newer developers who haven't set 
their careers in concrete yet. And this is the way it always is for new 
technology adoption.
Jan 18 2012
parent reply Patrick Stewart <ncc1701d starfed.com> writes:
How about putting equal effort in keeping existing D users? There is more than
one blogs online of ex D users with some pretty solid arguments why they
abandoned D. And those args are usually not some missing shiny feature X but
feature Y D already has but it is broken.

Just saying focusing on bright future is not excuse to forget about imperfect
now.
Jan 18 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2012 1:27 PM, Patrick Stewart wrote:

 How about putting equal effort in keeping existing D users? There is more
 than one blogs online of ex D users with some pretty solid arguments why they
 abandoned D. And those args are usually not some missing shiny feature X but
 feature Y D already has but it is broken.


I do attach far more importance to that than to reasons people who never used D 
do not use D.



 Just saying focusing on bright future is not excuse to forget about imperfect
 now.


I'm not saying it is.

The point is, we have limited resources. We have to put those resources where 
they will have the most effect.
Jan 18 2012
next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Wed, 18 Jan 2012 13:57:58 -0800, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 1/18/2012 1:27 PM, Patrick Stewart wrote:

 How about putting equal effort in keeping existing D users? There is  
 more
 than one blogs online of ex D users with some pretty solid arguments  
 why they
 abandoned D. And those args are usually not some missing shiny feature  
 X but
 feature Y D already has but it is broken.


 I do attach far more importance to that than to reasons people who never  
 used D do not use D.



 Just saying focusing on bright future is not excuse to forget about  
 imperfect
 now.


 I'm not saying it is.

 The point is, we have limited resources. We have to put those resources  
 where they will have the most effect.


I would argue that what would have the most effect is a concerted effort  
to stabilize the compiler. That means normalizing the differences between  
DMD/DRT, the Spec, and TDPL. That means taking a break from anything new  
(regardless of how badly we want them ... *COFF*COFF*), doing a thorough  
audit of the open issues and prioritizing compiler issues first. Then  
dedicated a release or three to doing nothing but fixing those issues.  
There are 2719 open issues in the bugtracker; that number alone will scare  
off many potential users. And the number of ICE's is much higher than it  
really should be to call DMD stable. In open-source terms, DMD is beta.  
I'm leaving out Phobos here specifically because it doesn't interact with  
the compiler nearly as much as the runtime does.

I would also argue that the above point is even more important in light of  
the fact that DMD has such limited resources. Accurate and efficient  
targeting of those resources is crucial to D's survival. New features,  
while exciting, only introduce the opportunity for new bugs and  
regressions. But without a stable compiler a language is just a theory and  
some mathematical proofs.

Once we have a stable compiler it gets much easier to build out libraries  
of code. These libraries are what really sell the language as they not  
only provide a preexisting toolbox for new developers, but also show that  
the language is mature enough to reliably handle complex bodies of code.  
Also once a stable compiler exists writing coherent documentation also  
gets much easier as the number of undefined and undocumented behaviors is  
significantly reduced. Ideally the documentation would have been written  
first but at this point I think it is way to much work for said limited  
resources to document and code at the same time.

To be honest, I think this is the end-goal that Andrei is shooting for in  
his "Planning Software?" thread...

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Jan 18 2012
next sibling parent "mist" <none none.none> writes:
On Wednesday, 18 January 2012 at 22:15:25 UTC, Adam Wilson wrote:

 On Wed, 18 Jan 2012 13:57:58 -0800, Walter Bright 
 <newshound2 digitalmars.com> wrote:


 On 1/18/2012 1:27 PM, Patrick Stewart wrote:

 How about putting equal effort in keeping existing D users? 
 There is more
 than one blogs online of ex D users with some pretty solid 
 arguments why they
 abandoned D. And those args are usually not some missing 
 shiny feature X but
 feature Y D already has but it is broken.


 I do attach far more importance to that than to reasons people 
 who never used D do not use D.



 Just saying focusing on bright future is not excuse to forget 
 about imperfect
 now.


 I'm not saying it is.

 The point is, we have limited resources. We have to put those 
 resources where they will have the most effect.


 I would argue that what would have the most effect is a 
 concerted effort to stabilize the compiler. That means 
 normalizing the differences between DMD/DRT, the Spec, and 
 TDPL. That means taking a break from anything new (regardless 
 of how badly we want them ... *COFF*COFF*), doing a thorough 
 audit of the open issues and prioritizing compiler issues 
 first. Then dedicated a release or three to doing nothing but 
 fixing those issues. There are 2719 open issues in the 
 bugtracker; that number alone will scare off many potential 
 users. And the number of ICE's is much higher than it really 
 should be to call DMD stable. In open-source terms, DMD is 
 beta. I'm leaving out Phobos here specifically because it 
 doesn't interact with the compiler nearly as much as the 
 runtime does.

 I would also argue that the above point is even more important 
 in light of the fact that DMD has such limited resources. 
 Accurate and efficient targeting of those resources is crucial 
 to D's survival. New features, while exciting, only introduce 
 the opportunity for new bugs and regressions. But without a 
 stable compiler a language is just a theory and some 
 mathematical proofs.

 Once we have a stable compiler it gets much easier to build out 
 libraries of code. These libraries are what really sell the 
 language as they not only provide a preexisting toolbox for new 
 developers, but also show that the language is mature enough to 
 reliably handle complex bodies of code. Also once a stable 
 compiler exists writing coherent documentation also gets much 
 easier as the number of undefined and undocumented behaviors is 
 significantly reduced. Ideally the documentation would have 
 been written first but at this point I think it is way to much 
 work for said limited resources to document and code at the 
 same time.

 To be honest, I think this is the end-goal that Andrei is 
 shooting for in his "Planning Software?" thread...


Can't bypass without saying "+1".

I have been following D development for almost 2 years and most 
of the time this is what I was really _dreaming_ about. What 
prevents me most from using D other than for small experiments is 
not really lack of/unfinished features, but very unclear 
development processes. I have been reading newsgroup silently and 
attentively for about half a year before got any slightest 
understanding of what is really happening.

Just personal feeling, of course.
Jan 18 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2012 2:15 PM, Adam Wilson wrote:

 I would argue that what would have the most effect is a concerted effort to
 stabilize the compiler. That means normalizing the differences between DMD/DRT,
 the Spec, and TDPL. That means taking a break from anything new (regardless of
 how badly we want them ... *COFF*COFF*), doing a thorough audit of the open
 issues and prioritizing compiler issues first. Then dedicated a release or
three
 to doing nothing but fixing those issues. There are 2719 open issues in the
 bugtracker; that number alone will scare off many potential users. And the
 number of ICE's is much higher than it really should be to call DMD stable. In
 open-source terms, DMD is beta. I'm leaving out Phobos here specifically
because
 it doesn't interact with the compiler nearly as much as the runtime does.


Take a look at the changelog. I just don't see how anyone could conclude that
is 
not exactly what we are doing. Here's the current list for the upcoming version 
of D2:


314 - [module] Static, renamed, and selective imports are always public
796 - Asserting a null object reference throws AssertError Failure 
internal\invariant.d(14) or Access Violation
1313 - out/body disables escape analysis
2411 - Reference Tuple Foreach
2442 - opApply does not allow inferring parameter types when overloaded on const
2443 - opApply should allow delegates that are not ref if it makes no sense
2997 - allMembers does not return interface members
3092 - Indexing a tuple produces a tuple containing the indexed element
3187 - Nested foreach over opApply doesn't work
3235 - [tdpl] Function literals must be deduced as "function" or "delegate"
4251 - Hole in the const system: immutable(T)[] implicitly casts to ref
const(T)[]
4413 - typeof(this) doesn't work in method template signature
4523 - [tdpl] .remove method for Associative Arrays returns void in all cases
4550 - D2 Language Docs: http://www.digitalmars.com/d/2.0/statement.html
4553 - D2 Language Docs: http://www.digitalmars.com/d/2.0/struct.html
4647 - [tdpl] Cannot explicitly call final interface method, ambiguous calls
allowed
4675 - [tdpl] Eponymous Template should hide internal names
4711 - Incorrect handling of && operator with void operand
4940 - ICE(symbol.c): Accessing tuple-typed field of struct literal with 
user-defined constructor
5493 - Able to overwrite immutable data by passing through ref function
parameter
5605 - [tdpl] foreach with ranges doesn't support opSlice()
6037 - [CTFE] recursive ref parameters evaluated incorrectly
6205 - Strongly-pure nothrow functions with ignored return value are entirely 
stripped even if it contains a failing 'assert'.
6208 - Parameter storage classes are ignored in template function deducing.
6364 - Static struct's destructor called on exit of function
6473 - Stack overflow with struct destructor as default parameter
6701 - template specialization resolution failure
6714 - [tdpl] Type inference for parameters of function and delegate literals
6933 - Segfault(declaration.c) using struct with destructor in CTFE
6934 - [CTFE] can't use $ in a slice of an array passed by ref
6939 - wrong type qualifier combination
6940 - immutable(int*)*/immutable(int)** and int** do not combine
6964 - Error message with __error: static assert(undefined+1)
6984 - CTFE generates a torrent of spurious errors, if there was a previous
error
6985 - [CTFE] Non-constant case expressions can't be interpreted
6995 - [CTFE] can't interpret static template method
7011 - No line number error for vector power
7037 - TemplateTypeParameterSpecialization works differently from IsExpression 
regarding alias this
7043 - CTFE: ICE illegal reference value 0LU, only with -inline
7073 - Parsing of class-returning varargs function inside module ctor fails
7108 - ICE: TraitsExp::semantic(Scope*) 2.056 -> 2.057 regression - segfault
7120 - Scope Delegates + Delegate Literals
7123 - static assert(is(typeof(toDelegate(&main)))) is false
7124 - Alias this type is not considered in template type deduction
7127 - Const-related infinite recursion in DWARF generation
7133 - [tdpl] There should be no empty statement
7136 - alias this lookup should run before merging modifiers of both sides.
7143 - [CTFE] cannot compare class references with "is"
7144 - [CTFE] base class does not call overridden members
7154 - [CTFE] failing downcast causes error
7158 - [CTFE] ICE(interpret.c) calling a class member using a dotvar expression
7160 - Regression(2.057): ICE(dsymbol.c:1052) ICE using __traits(derivedMembers)
7162 - [CTFE] "bool || void" expression crashes dmd
7165 - [CTFE] ice converting null pointer to bool with constant member function
7168 - Regression(2.057) __traits(allMembers) returns wrong tuple
7170 - [UFCS] array + specialized template member syntax causes ICE
7173 - dmd: glue.c:1065: virtual unsigned int Type::totym(): Assertion `0'
failed.
7185 - [CTFE] ICE on changing char array length
7187 - Regression(head 12d62ca5): [CTFE] ICE on slicing
7189 - inline failed
7190 - Tuple length incorrect
7193 - Regression(2.058head): ICE: delete lambda expression crashes dmd
7194 - [CTFE] Incorrect behaviour with pointers as local struct variable
7196 - Unfair function address overload resolution
7201 - Lambda template assignment to variable
7207 - Explicit cast should resolve lambda type
7212 - Regression(Head): ICE with overload resolution and delegate/function 
inference
7217 - [CTFE] ICE on accessing struct array field
7218 - Nested function with contract is rejected
7232 - Warning: statement is not reachable has no line number
7239 - C style struct initialization doesn't work with aliases
7245 - [CTFE] Address of ref foreach parameter changes to point after array
7248 - [CTFE] Stack overflow on using struct filed pointer with address of
array 
element
7266 - [CTFE] Assign to ref param (that's taken from struct member) is noop
7278 - Templated struct (instantiated with null) can't access its own members
7285 - Implicit fixed-size array cast
7290 - Heap allocation with scoped delegate literal
7309 - [2.058] Regression caused by new inlining code
Jan 18 2012
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 Here's the current list for the upcoming version of D2:


It's an impressive list, as usual :-)

But as I have recently explained (on the base on an old comment of yours) not
all bugs are equal. Most bugs in that list are kind of irrelevant to me, they
don't hit my code significantly, or often enough. Only few of those bugs are
able to change the way I write D2 code, because their presence forces me to use
work-arounds, or they forbid me to use certain idioms or certain kinds of code.

This is why I think a little group of those bugs is more important than fixing
a hundred of other bugs (on the other hand I understand that other people write
code different from mine, so they may find different bugs as more important.
But the purpose of Bugzilla voting is right to average such differences in
programmers needs).

Fixing this bug improves my experience of using modules:

 314 - [module] Static, renamed, and selective imports are always public


Fixing this bug allows me to avoid to write many "helper" templates:

 4675 - [tdpl] Eponymous Template should hide internal names


The recent improvements in byKey and byValue allow me to use associative arrays
better and more efficiently.

The improvements of the way const/immutable arrays are giving to functions
allow me to use std.algorithm on const arrays, this avoids me to put cast() in
many situations, it suddenly makes std.algorithm a notch more useful.

Bye,
bearophile
Jan 18 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2012 3:52 PM, bearophile wrote:

 Most bugs in that list are kind of irrelevant to me, they
 don't hit my code significantly, or often enough.


All of them hit somebody.
Jan 18 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/18/12 5:13 PM, Walter Bright wrote:

 Take a look at the changelog. I just don't see how anyone could conclude
 that is not exactly what we are doing. Here's the current list for the
 upcoming version of D2:


[snip]

Great work everybody. Some issues are lateral to the size and might of 
the list:

1. There was no plan in place for fixing these bugs vs. others; the 
process was rather chaotic, and at least one bug was fixed because one 
user took the time to email me a little novel complaining about it.

2. There is no projected date of release.

3. There is no plan going forward, e.g. what bugs will be fixed later.

4. A lot of the important tdpl bugs should have been filed, triaged, and 
fixed a long time ago.

5. There's no sense of the "length of the pipeline", i.e. how long it 
takes until a given bug is triaged.

Until recently there were enough big issues that it didn't really matter 
which were solved - all fruit was low hanging! But at this point we must 
get better organized.


Andrei
Jan 18 2012
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 5. There's no sense of the "length of the pipeline", i.e. how long it 
 takes until a given bug is triaged.


Instead of fixing the N most old bugs every DMD release, I suggest to fix the N
(N = 2 or 3 seems enough) most Bugzilla-voted bugs every DMD release :-)  (If
this happens, then probably people will start voting more often and better).

Bye,
bearophile
Jan 18 2012
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/18/12 6:46 PM, bearophile wrote:

 Andrei Alexandrescu:


 5. There's no sense of the "length of the pipeline", i.e. how long
 it takes until a given bug is triaged.


 Instead of fixing the N most old bugs every DMD release, I suggest to
 fix the N (N = 2 or 3 seems enough) most Bugzilla-voted bugs every
 DMD release :-)  (If this happens, then probably people will start
 voting more often and better).



False choice. It's not "instead of".

Andrei
Jan 18 2012
prev sibling next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Wed, 18 Jan 2012 15:13:19 -0800, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 1/18/2012 2:15 PM, Adam Wilson wrote:

 I would argue that what would have the most effect is a concerted  
 effort to
 stabilize the compiler. That means normalizing the differences between  
 DMD/DRT,
 the Spec, and TDPL. That means taking a break from anything new  
 (regardless of
 how badly we want them ... *COFF*COFF*), doing a thorough audit of the  
 open
 issues and prioritizing compiler issues first. Then dedicated a release  
 or three
 to doing nothing but fixing those issues. There are 2719 open issues in  
 the
 bugtracker; that number alone will scare off many potential users. And  
 the
 number of ICE's is much higher than it really should be to call DMD  
 stable. In
 open-source terms, DMD is beta. I'm leaving out Phobos here  
 specifically because
 it doesn't interact with the compiler nearly as much as the runtime  
 does.


 Take a look at the changelog. I just don't see how anyone could conclude  
 that is not exactly what we are doing. Here's the current list for the  
 upcoming version of D2:


[snip]

I am not trying to devalue the work that you guys have done, it is frankly  
impressive. But D feels like it lacks any real direction, certain things  
get fixed while other languish. Bugs are fixed seemingly at random. To  
some people is says "to disorganized to work with" (no reasonable  
expectation my issue won't get forgotten in the hustle) to others it says  
"to many brush fires for the team to handle" (more critical issues than  
are acceptable, which means any blocking issues I may have will naturally  
fall down the list). I am not saying these are necessarily true, but D has  
a perception problem, and this perception is a large part of it.

I think what we are all trying to say that we need to know *when* things  
are going to get done ... and "sometime in the future" doesn't cut it.  
Then have those things actually GET done about when they were promised.  
People wouldn't feel like they had to get their issues addressed RIGHT  
NOW, if they had a reasonable expectation of when they will be addressed.

When large teams evaluate a language they care not only about what it can  
and can't do today, but also when it will be able to do what it was  
promised to do. As a project manager, I can work around the fact that  
something might not be working now, but will later, as long as I know  
roughly when it will start working. I'm not saying that we need a hard  
date, a window of a couple of months would be FANTASTICALLY useful in  
terms of planning a project, and I am sure that anyone else who has run a  
project would agree.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Jan 18 2012
prev sibling parent reply Heywood Floyd <soul8o8 gmail.com> writes:
 On 1/18/2012 2:15 PM, Adam Wilson wrote:

 [...] There are 2719 open issues in the
 bugtracker; that number alone will scare off many potential users.




Walter Bright Wrote:

 Take a look at the changelog. I just don't see how anyone could conclude that
is 
 not exactly what we are doing. Here's the current list for the upcoming
version 
 of D2:
 
 
 314 - [module] Static, renamed, and selective imports are always public
 [...]
 7309 - [2.058] Regression caused by new inlining code




Hello!

I agree the changelog is impressive and a solid proof the D community is hard
working.

However, I still subscribe to Adam's view that the D bug situation _is_ a
problem, even a scary one:
http://d.puremagic.com/issues/reports.cgi?product=D&datasets=NEW

That's over an ~8 year time frame. I think it's perfectly clear: D has a
chronic monthly bug surplus.

Of course, all software has bugs. The difference is healthy software has a
"rhythm", and as far as I can tell, D doesn't. Compare with a text-book example
(not exactly comparable, but close enough):
http://bugs.debian.org/release-critical/

The key here, I believe, is the psychological effects of bundling high-quality
stable software with buggy components. Although the curve above doesn't mean
all of D is "unstable", as features of course do get stable in time, it does
mean the perception of D is bound to be mostly negative. Why? If you buy a car
and it has a solid engine, good wheels, wonderful suspension, but the seats are
uncomfortable and the radio switches stations randomly, you're not going to
think "Ah, this is an overall nice car, because the awesome engine makes up for
the bad seats and radio", no, you're going to get annoyed and think "this is a
crap car that makes me irritated and hurts my back" and you'll wish you bought
another one, even one without a radio. With D2, because it mixes new features
and bug fixes into the same branch, there's always something that's the
annoying radio.

This is a perfectly good reason to add a lib namespace like "ext.*", "lab.*" or
even "beta.*" and add all new libs there with the warning that it's
experimental and not for production.

Then again, that's not really a solution. The latest SIMD lib is a perfect
example: It seems contained and like it could only do good for D's overall
quality. Yet it doesn't take long before someone realizes SIMD could perhaps
speedup regexp, then someone wants all float[4] to be optimized automatically,
of course std.math must be picked apart and reassembled with SIMD in place
sooner or later, then hashing, then crc, utf-8 tricks, who knows? The next tier
is that 3rd party libs will start using the half-baked SIMD lib too, because
they follow D's sloppy lead. And voilá, we have a bug soufflé spreading to all
D code, and the end-user doesn't have a choice. There's no such thing as an
isolated feature. Every new feature comes attached with a systemic cost. An
alternative way of thinking about SIMD is that, sure, it will speed up some
things, it will also add around 300 bugs over the next year to arbitrary parts
of D, as a measure of the effort needed to sustain D's current quality level,
with SIMD in place. And that would be ok, _if_ we could handle it, but not if
it means an overall bug surplus, and especially not if there already is a
surplus that it just adds to. Then D's quality will deteriorate from it.

I think D really needs to start thinking economically about new features and
bugs. New features must be picked carefully and strategically with a
maintenance budget in mind. This economy needs to be balanced, with the means
available here and now, not with some pie-in-the-sky idea that if we only get
this feature we'll get 50 new users and then we'll fix all bugs in a month.
That behavior will burn already existing users once the prediction fails, as it
must, from time to time. New features are costly, over a long period of time,
and need to be treated as such. New users typically do not evaluate software on
the basis on how good it could get if they fixed all the bugs first.

Then, I get the impression D is acting somewhat out of desperation,
understandably. At some level I see a talented and skillful community, with an
innovative and beautiful product, waiting for a lucky break. This can be a
frustrating situation. There seems to be a belief, subconsciously perhaps, that
if D would only have enough "wow" people would finally get impressed enough and
start to use it. I think this is a fundamentally flawed belief that leads to a
slow death sided by wasted efforts. I think when we all think about it, we
chose software, when we can chose, that works well over software that's cool
but annoying and frustrating. I mean look at other successful low-budget
software projects. Most got their break by doing a particular thing really
well, not by being impressive on paper or to an audience at a conference. D
needs to stop "wowing" and start focusing on becoming a focused high-quality
product, and given the psychology of humans and the things I've mentioned, I
see no other way of doing that except getting that bug curve back on the
ground, and then make an actual stable release. And getting a bug curve down
can only mean one thing: Freeze all new features.

Of course, halting development alltogether isn't good. Software projects needs
to be actively developed, creativity needs to be kept warm, or it dries up. But
this is a universal problem, not something unique to D, and it has already been
solved, many times over. The conventional industry-standard way of releasing
stable high-quality software, while still being able to work on the next cool
version, is to use stable/testing branches. This is no mystery. The question
is: Why doesn't D have this? If the answer is that D1 is the stable branch,
then the problem is a different one, but equally troublesome: The stable
release cycle of D, that is, the time the end-user have to wait for the next
batch of stable features, is what, 6 to 9 years? No one will wait around for
that long. D needs a new stable release every 1–2 years, especially in the
beginning when new features are available in abundance. No one cares about how
great D will be when all envisioned features are finally in place. People care
about what's here and now.

Summary
D can not liftoff with this monthly bug surplus. The surplus is in one way
good, because it shows there's creativity happening, but it needs to be
confined in a separate branch, out of the sight of the end-users. The version
of D that the end-users see needs to have a bug deficit, asap. Further, D needs
to start to think economically about features and bugs, and there probably
should be a policy in place that no new stable version is allowed to be
released before the current one has fixed 90% of its bugs, or something like
that. I think D is long due on putting the two activities of creative
development and maintenance on two separate planets, or moons, in this case, I
suppose.

Just to be clear, I don't think SIMD should never have happened. Creativity
must be allowed and creativity comes when it comes, but it shouldn't be
triumphantly dumped in the laps of the end-user every month like a dead mouse
the cat brought in. If D was an airline, it would be like you've just boarded
the airplane and you're waiting for takeoff, but then the pilot comes on: "Dear
passengers, we're just going to make a routine break here. Our engineers have
just come up with a new better wing flap and we'll just wait 20 minutes while
they install it". Huh? Is this a joke? you'd be thinking. Then you look out the
window, and there they are, the engineering team, disassembling part of the
wing. I mean it's madness to think the end-user will enjoy using a product
while it's in active development, especially when it's such a low-level product
as a programming language. It's also madness to think the end-user will wait 7
years for the next stable update. There needs to be a strong separation between
development and maintenance, and there needs to be regular timely stable
releases with near zero known critical bugs.

Anyway, I think D has great potential and I use it regularly for hobby stuff
and like it very much, especially as I'm allergic to C++. (No really.) There's
a lot of really good stuff in there.


Kind regards
/HF


(PS. ...oh, I forgot to bring up the documentation, oh my, next time perhaps...)
Jan 19 2012
next sibling parent Patrick Stewart <ncc1701d starfed.com> writes:
I agree 100% with this, must say, beautifully written essay.
Jan 19 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/19/2012 06:13 PM, Heywood Floyd wrote:

 However, I still subscribe to Adam's view that the D bug situation _is_ a
problem, even a scary one:
 http://d.puremagic.com/issues/reports.cgi?product=D&datasets=NEW


More than one fourth of those are enhancement requests, therefore it is 
somewhat less bad than it looks.
Jan 19 2012
parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 19.01.2012, 19:02 Uhr, schrieb Timon Gehr <timon.gehr gmx.ch>:


 On 01/19/2012 06:13 PM, Heywood Floyd wrote:

 However, I still subscribe to Adam's view that the D bug situation _is_  
 a problem, even a scary one:
 http://d.puremagic.com/issues/reports.cgi?product=D&datasets=NEW


 More than one fourth of those are enhancement requests, therefore it is  
 somewhat less bad than it looks.


Well written, Heywood. I liked the cat allegory. I could go on and on  
thinking about the philosophical aspects of using this "pet". But I also  
agree with Timon. The perceived situation on my end isn't bad any longer.  
Those who use D for a longer while have noticed that the annoying bug rate  
went down to an acceptable level, where you don't want to jump off and use  
C++. I just opened a bug report for a missing optimization opportunity. I  
would not have done that a year ago, thinking that there are still enough  
real bugs to be fixed first.
Jan 19 2012
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/12 11:13 AM, Heywood Floyd wrote:
[snip]

Thanks for a very insightful post.

Andrei
Jan 19 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Are you reading in my mind ?

Le 19/01/2012 18:13, Heywood Floyd a écrit :

 On 1/18/2012 2:15 PM, Adam Wilson wrote:

 [...] There are 2719 open issues in the
 bugtracker; that number alone will scare off many potential users.




 Walter Bright Wrote:

 Take a look at the changelog. I just don't see how anyone could conclude that
is
 not exactly what we are doing. Here's the current list for the upcoming version
 of D2:


 314 - [module] Static, renamed, and selective imports are always public
 [...]
 7309 - [2.058] Regression caused by new inlining code




 Hello!

 I agree the changelog is impressive and a solid proof the D community is hard
working.

 However, I still subscribe to Adam's view that the D bug situation _is_ a
problem, even a scary one:
 http://d.puremagic.com/issues/reports.cgi?product=D&datasets=NEW

 That's over an ~8 year time frame. I think it's perfectly clear: D has a
chronic monthly bug surplus.

 Of course, all software has bugs. The difference is healthy software has a
"rhythm", and as far as I can tell, D doesn't. Compare with a text-book example
(not exactly comparable, but close enough):
 http://bugs.debian.org/release-critical/

 The key here, I believe, is the psychological effects of bundling high-quality
stable software with buggy components. Although the curve above doesn't mean
all of D is "unstable", as features of course do get stable in time, it does
mean the perception of D is bound to be mostly negative. Why? If you buy a car
and it has a solid engine, good wheels, wonderful suspension, but the seats are
uncomfortable and the radio switches stations randomly, you're not going to
think "Ah, this is an overall nice car, because the awesome engine makes up for
the bad seats and radio", no, you're going to get annoyed and think "this is a
crap car that makes me irritated and hurts my back" and you'll wish you bought
another one, even one without a radio. With D2, because it mixes new features
and bug fixes into the same branch, there's always something that's the
annoying radio.

 This is a perfectly good reason to add a lib namespace like "ext.*", "lab.*"
or even "beta.*" and add all new libs there with the warning that it's
experimental and not for production.

 Then again, that's not really a solution. The latest SIMD lib is a perfect
example: It seems contained and like it could only do good for D's overall
quality. Yet it doesn't take long before someone realizes SIMD could perhaps
speedup regexp, then someone wants all float[4] to be optimized automatically,
of course std.math must be picked apart and reassembled with SIMD in place
sooner or later, then hashing, then crc, utf-8 tricks, who knows? The next tier
is that 3rd party libs will start using the half-baked SIMD lib too, because
they follow D's sloppy lead. And voil�, we have a bug souffl� spreading to
all D code, and the end-user doesn't have a choice. There's no such thing as an
isolated feature. Every new feature comes attached with a systemic cost. An
alternative way of thinking about SIMD is that, sure, it will speed up some
things, it will also add around 300 bugs over the next year to arbitrary parts
of D, as a measure of the effort needed to sustain D's curre


nt quality level, with SIMD in place. And that would be ok, _if_ we could
handle it, but not if it means an overall bug surplus, and especially not if
there already is a surplus that it just adds to. Then D's quality will
deteriorate from it.

 I think D really needs to start thinking economically about new features and
bugs. New features must be picked carefully and strategically with a
maintenance budget in mind. This economy needs to be balanced, with the means
available here and now, not with some pie-in-the-sky idea that if we only get
this feature we'll get 50 new users and then we'll fix all bugs in a month.
That behavior will burn already existing users once the prediction fails, as it
must, from time to time. New features are costly, over a long period of time,
and need to be treated as such. New users typically do not evaluate software on
the basis on how good it could get if they fixed all the bugs first.

 Then, I get the impression D is acting somewhat out of desperation,
understandably. At some level I see a talented and skillful community, with an
innovative and beautiful product, waiting for a lucky break. This can be a
frustrating situation. There seems to be a belief, subconsciously perhaps, that
if D would only have enough "wow" people would finally get impressed enough and
start to use it. I think this is a fundamentally flawed belief that leads to a
slow death sided by wasted efforts. I think when we all think about it, we
chose software, when we can chose, that works well over software that's cool
but annoying and frustrating. I mean look at other successful low-budget
software projects. Most got their break by doing a particular thing really
well, not by being impressive on paper or to an audience at a conference. D
needs to stop "wowing" and start focusing on becoming a focused high-quality
product, and given the psychology of humans and the things I've mentioned,


 I see no other way of doing that except getting that bug curve back on the
ground, and then make an actual stable release. And getting a bug curve down
can only mean one thing: Freeze all new features.

 Of course, halting development alltogether isn't good. Software projects needs
to be actively developed, creativity needs to be kept warm, or it dries up. But
this is a universal problem, not something unique to D, and it has already been
solved, many times over. The conventional industry-standard way of releasing
stable high-quality software, while still being able to work on the next cool
version, is to use stable/testing branches. This is no mystery. The question
is: Why doesn't D have this? If the answer is that D1 is the stable branch,
then the problem is a different one, but equally troublesome: The stable
release cycle of D, that is, the time the end-user have to wait for the next
batch of stable features, is what, 6 to 9 years? No one will wait around for
that long. D needs a new stable release every 1�2 years, especially in the
beginning when new features are available in abundance. No one cares about how
great D will be when all envisioned features are finally i


n place. People care about what's here and now.

 Summary
 D can not liftoff with this monthly bug surplus. The surplus is in one way
good, because it shows there's creativity happening, but it needs to be
confined in a separate branch, out of the sight of the end-users. The version
of D that the end-users see needs to have a bug deficit, asap. Further, D needs
to start to think economically about features and bugs, and there probably
should be a policy in place that no new stable version is allowed to be
released before the current one has fixed 90% of its bugs, or something like
that. I think D is long due on putting the two activities of creative
development and maintenance on two separate planets, or moons, in this case, I
suppose.

 Just to be clear, I don't think SIMD should never have happened. Creativity
must be allowed and creativity comes when it comes, but it shouldn't be
triumphantly dumped in the laps of the end-user every month like a dead mouse
the cat brought in. If D was an airline, it would be like you've just boarded
the airplane and you're waiting for takeoff, but then the pilot comes on: "Dear
passengers, we're just going to make a routine break here. Our engineers have
just come up with a new better wing flap and we'll just wait 20 minutes while
they install it". Huh? Is this a joke? you'd be thinking. Then you look out the
window, and there they are, the engineering team, disassembling part of the
wing. I mean it's madness to think the end-user will enjoy using a product
while it's in active development, especially when it's such a low-level product
as a programming language. It's also madness to think the end-user will wait 7
years for the next stable update. There needs to be a stro


ng separation between development and maintenance, and there needs to be
regular timely stable releases with near zero known critical bugs.

 Anyway, I think D has great potential and I use it regularly for hobby stuff
and like it very much, especially as I'm allergic to C++. (No really.) There's
a lot of really good stuff in there.


 Kind regards
 /HF


 (PS. ...oh, I forgot to bring up the documentation, oh my, next time
perhaps...)
Jan 19 2012
prev sibling parent reply Patrick Stewart <ncc1701d starfed.com> writes:
Walter Bright Wrote:


 On 1/18/2012 1:27 PM, Patrick Stewart wrote:

 How about putting equal effort in keeping existing D users? There is more
 than one blogs online of ex D users with some pretty solid arguments why they
 abandoned D. And those args are usually not some missing shiny feature X but
 feature Y D already has but it is broken.


 
 I do attach far more importance to that than to reasons people who never used
D 
 do not use D.
 
 

 Just saying focusing on bright future is not excuse to forget about imperfect
 now.


 
 I'm not saying it is.
 
 The point is, we have limited resources. We have to put those resources where 
 they will have the most effect.
 


Would you argue that standardizing and finishing language core is first step
and library is next?

Also, I would argue that resources are not limited as in modest, but wasted. 

I am sorry to see many D community projects and libraries dead as they are
targeted for D1 and not portable to D2, or just locked to specific version of D
and not transferable to latest version due some bug.

I think it is possible for community to make all necessary libraries and tools
once the D is "carved in stone". I suppose D1 is attempt to do that, but not
having ready substitute yet (D2 not working as advertised) and D1's clock
ticking away, it is risky gamble to say at least.

To put it plain and simple, I have strong feeling D development is motivated by
desire to add latest ideas and features and not by desire to produce practical
and stable tool.
Jan 18 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2012 4:03 PM, Patrick Stewart wrote:

 I am sorry to see many D community projects and libraries dead as they are
 targeted for D1 and not portable to D2, or just locked to specific version of
 D and not transferable to latest version due some bug.


I am sorry about Tango apps being incompatible. I cannot do anything about that.



 I think it is possible for community to make all necessary libraries and
 tools once the D is "carved in stone". I suppose D1 is attempt to do that,
 but not having ready substitute yet (D2 not working as advertised) and D1's
 clock ticking away, it is risky gamble to say at least.


What issue with D2 is blocking you?



 To put it plain and simple, I have strong feeling D development is motivated
 by desire to add latest ideas and features and not by desire to produce
 practical and stable tool.


People often write postings, where in the very same posting, they'll write that 
they absolutely must have new feature X now, and that no new features should be 
added.

How would you resolve this?
Jan 18 2012
next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Wed, 18 Jan 2012 16:29:23 -0800, Walter Bright  
<newshound2 digitalmars.com> wrote:


 On 1/18/2012 4:03 PM, Patrick Stewart wrote:

 I am sorry to see many D community projects and libraries dead as they  
 are
 targeted for D1 and not portable to D2, or just locked to specific  
 version of
 D and not transferable to latest version due some bug.


 I am sorry about Tango apps being incompatible. I cannot do anything  
 about that.



 I think it is possible for community to make all necessary libraries and
 tools once the D is "carved in stone". I suppose D1 is attempt to do  
 that,
 but not having ready substitute yet (D2 not working as advertised) and  
 D1's
 clock ticking away, it is risky gamble to say at least.


 What issue with D2 is blocking you?



 To put it plain and simple, I have strong feeling D development is  
 motivated
 by desire to add latest ideas and features and not by desire to produce
 practical and stable tool.


 People often write postings, where in the very same posting, they'll  
 write that they absolutely must have new feature X now, and that no new  
 features should be added.

 How would you resolve this?


Harsh as it sounds I'd ignore them, what they are really asking for is for  
you to stop working on everything else and work on their feature. Doing  
that is planning to fail.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
Jan 18 2012
parent Gour <gour atmarama.net> writes:
On Wed, 18 Jan 2012 16:41:28 -0800
"Adam Wilson" <flyboynw gmail.com> wrote:


 Harsh as it sounds I'd ignore them, what they are really asking for
 is for you to stop working on everything else and work on their
 feature. Doing that is planning to fail.


Right. Workers are out at the construction site and although they are
capable to build big scycrapers, there is need to provide basic
facilities for them in order they can start doing useful work.

Then when they prove that it's possible to build something useful, more
investments can be made to extend the scope.

At the moment, D is to risky to invest in it for commercial agents, so
open-source projects seems to be nice fit.

For a long time, GHC was practically the only serious project done (not
100% in Haskell (later Darcs appeared on the scene), what we have to
show as written in D2?

As mentioned in another thread, D with its features for paralleism,
FP-stuff etc. *could be* very  attractive as general programming
language suitable for those imperative programmers which cannot easily
grok monads and wants to take advantage of their multi-core CPUs idling
at the moment.

So, as Adam wrote, let's provide rounded feature set which works so
that, at least, (open-source) projects can write D2 code today, possibly
without too much sacrifice. :-)


Sincerely,
Gour


--=20
A person who has given up all desires for sense gratification,=20
who lives free from desires, who has given up all sense of=20
proprietorship and is devoid of false ego =E2=80=94 he alone can=20
attain real peace.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Jan 18 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-19 01:29, Walter Bright wrote:

 On 1/18/2012 4:03 PM, Patrick Stewart wrote:

 I am sorry to see many D community projects and libraries dead as they
 are
 targeted for D1 and not portable to D2, or just locked to specific
 version of
 D and not transferable to latest version due some bug.


 I am sorry about Tango apps being incompatible. I cannot do anything
 about that.


Tango for D2 is available: https://github.com/SiegeLord/Tango-D2
I ported one of projects from D1 Tango to D2 Tango with little effort.

-- 
/Jacob Carlborg
Jan 18 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2012 11:38 PM, Jacob Carlborg wrote:

 On 2012-01-19 01:29, Walter Bright wrote:

 On 1/18/2012 4:03 PM, Patrick Stewart wrote:

 I am sorry to see many D community projects and libraries dead as they
 are
 targeted for D1 and not portable to D2, or just locked to specific
 version of
 D and not transferable to latest version due some bug.


 I am sorry about Tango apps being incompatible. I cannot do anything
 about that.


 Tango for D2 is available: https://github.com/SiegeLord/Tango-D2
 I ported one of projects from D1 Tango to D2 Tango with little effort.


Great!
Jan 19 2012
prev sibling parent reply Patrick Stewart <ncc1701d starfed.com> writes:
Walter Bright Wrote:


 On 1/18/2012 4:03 PM, Patrick Stewart wrote:

 I am sorry to see many D community projects and libraries dead as they are
 targeted for D1 and not portable to D2, or just locked to specific version of
 D and not transferable to latest version due some bug.


 
 I am sorry about Tango apps being incompatible. I cannot do anything about
that.


Not only Tango, there is lot of work that staled and was abandoned or is frozen
due to technical difficulties with core (compilers, lang. specs, manuals, whole
bundle). It is significant number of man hours gone down the drain.


 
 

 I think it is possible for community to make all necessary libraries and
 tools once the D is "carved in stone". I suppose D1 is attempt to do that,
 but not having ready substitute yet (D2 not working as advertised) and D1's
 clock ticking away, it is risky gamble to say at least.


 
 What issue with D2 is blocking you?
 


It is not what issue is blocking me, there are enough issues to block more than
one user of D. In my opinion, that is not a way to direct development - by
listening to loudest complainer. And community not complaining is not proof
everything is going in right direction.


 

 To put it plain and simple, I have strong feeling D development is motivated
 by desire to add latest ideas and features and not by desire to produce
 practical and stable tool.


 
 People often write postings, where in the very same posting, they'll write
that 
 they absolutely must have new feature X now, and that no new features should
be 
 added.
 
 How would you resolve this?


First to say about myself is that my programming style is aimed at simplicity
and maintainability. Feature set I find in D1 is 90% sufficient to solve
problems my work places in front of me. Those 10% D1 lacks I solve with more
lines of code, and I find it preferable and better solution than to switch to
D2. 

Direction I imagine could solve current state is frozing D2 specs. Declare that
job is done. Announce that on site and NG. Take a week or month to think about
what is done. Let all the users do that. After that month, put on list of only
those rare cases and minor changes that could be added in matter of days as
last chance before language is locked for significant time to come.

Then inspect it critically. Give it care and attention. Fix all bugs. Write new
docs. Sync website with that docs. Give assurance language core is there to
stay as it is. Assure community their work is appreciated and all they make in
D will work with future compilers and not be in vain.

Long story short - I find new things added and premature optimizations The
worst enemy of language at the moment. They might look like selling point to
you, to me they look like distractions from fixing D's shaking legs and solving
some real problems underneath.
Jan 19 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/19/2012 2:06 AM, Patrick Stewart wrote:

 Long story short - I find new things added and premature optimizations The
 worst enemy of language at the moment. They might look like selling point to
 you, to me they look like distractions from fixing D's shaking legs and
 solving some real problems underneath.


Take a look at the D changelog.

https://github.com/D-Programming-Language/d-programming-language.org/blob/master/changelog.dd

I just don't see how it can be argued that we aren't doing exactly what you 
suggest we do.
Jan 19 2012
next sibling parent Patrick Stewart <ncc1701d starfed.com> writes:
Walter Bright Wrote:


 On 1/19/2012 2:06 AM, Patrick Stewart wrote:

 Long story short - I find new things added and premature optimizations The
 worst enemy of language at the moment. They might look like selling point to
 you, to me they look like distractions from fixing D's shaking legs and
 solving some real problems underneath.


 
 Take a look at the D changelog.
 
 https://github.com/D-Programming-Language/d-programming-language.org/blob/master/changelog.dd
 
 I just don't see how it can be argued that we aren't doing exactly what you 
 suggest we do.


Changelog is not replacement for published plans and direction, same as NG is
not replacement for documentation.

Time will tell.
Jan 19 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-19 11:11, Walter Bright wrote:

 On 1/19/2012 2:06 AM, Patrick Stewart wrote:

 Long story short - I find new things added and premature optimizations
 The
 worst enemy of language at the moment. They might look like selling
 point to
 you, to me they look like distractions from fixing D's shaking legs and
 solving some real problems underneath.


 Take a look at the D changelog.

 https://github.com/D-Programming-Language/d-programming-language.org/blob/master/changelog.dd


 I just don't see how it can be argued that we aren't doing exactly what
 you suggest we do.


Take a look at the latest commits, the language is not frozen. You have 
recently added support for SIMD and a new lambda syntax (which I really 
like BTW).

-- 
/Jacob Carlborg
Jan 19 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, January 19, 2012 14:59:54 Jacob Carlborg wrote:

 On 2012-01-19 11:11, Walter Bright wrote:

 On 1/19/2012 2:06 AM, Patrick Stewart wrote:

 Long story short - I find new things added and premature optimizations
 The
 worst enemy of language at the moment. They might look like selling
 point to
 you, to me they look like distractions from fixing D's shaking legs
 and
 solving some real problems underneath.


 
 Take a look at the D changelog.
 
 https://github.com/D-Programming-Language/d-programming-language.org/blo
 b/master/changelog.dd
 
 
 I just don't see how it can be argued that we aren't doing exactly what
 you suggest we do.


 
 Take a look at the latest commits, the language is not frozen. You have
 recently added support for SIMD and a new lambda syntax (which I really
 like BTW).


The language isn't frozen, but it's close. Almost all of the language changes 
at this point are backwards compatible. And I don't think that it necessarily 
ever makes sense to say that we won't make backwards compatible changes 
anymore. The issue is that we need to try and resolve any further issues that 
require non-backwards compatible changes sooner rather than later and that we 
need to get the compiler stabilized to the point that it can be reasonably 
used for fulltime development without fear of compiler bugs making that 
infeasible.

We're getting there, and aside from tangents such as SIMD, the only thing that 
I can think of that could be done better (aside from somehow fixing bugs 
faster) is to focus more on some of the more critical bugs - such as TDPL bugs 
and major bugs which prevent major features working properly (such as const-
related issues). But that's been improving as well of late, if perhaps not 
always as quickly as would be nice.

- Jonathan M Davis
Jan 19 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
Le 19/01/2012 11:11, Walter Bright a écrit :

 On 1/19/2012 2:06 AM, Patrick Stewart wrote:

 Long story short - I find new things added and premature optimizations
 The
 worst enemy of language at the moment. They might look like selling
 point to
 you, to me they look like distractions from fixing D's shaking legs and
 solving some real problems underneath.


 Take a look at the D changelog.

 https://github.com/D-Programming-Language/d-programming-language.org/blob/master/changelog.dd


 I just don't see how it can be argued that we aren't doing exactly what
 you suggest we do.


I know that a lot of bugs are fixed. This is a thing, and this is good.

But another point is that a lot f bugs exists. This point is much more 
revelant. It may sound harsh but the only thing that matter is the 
result. As computer scientist we all should know that. And the result 
for know is a bugguy compiler. No matter how much bugs are fixed in each 
release, what is important is how many bugs remains and how severe they are.

And let's face it, if you start to use some advanced feature of D, you 
trigger bugs really easily. Workaround exists for most of them, but what 
is the point of advanced feature if they always explode on your face ? 
And what is the point of D if its features cannot be used safely ?

I would be happy to help, but frankly, I have no clue how dmd works. I'm 
pretty sure many people are like me in D community. Maybe a good thing 
may be produce some documentation about dmd internal, to reduce the 
entry ticket to dmd internals.
Jan 19 2012
prev sibling parent Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
Hmm my experiences are similar for 90% of companies, though I have seen 
some exceptions (Perforce is receptive of feedback and bugs, Certain 
divisions of Microsoft are communicative, but not MSConnect).   The 
common denominator for communication looks pretty simple to me:

If there is anyone between you and the developer on the other end, it is 
doomed to be a black hole.   MSConnect is a form-letter 'your bug is a 
duplicate, we can't reproduce it, and please test it in our new version 
for us so we can fail to fix it even though we know about it', but 
working directly with divisions in Microsoft is much possible (i.e. 
console support for programmers working on XBOX is stellar for instance, 
completely the opposite experience of reporting bugs to MSConnect).


On 1/16/2012 10:32 PM, Walter Bright wrote:

 On 1/16/2012 12:00 AM, Gour wrote:

 Recently I was evaluating one CMS written in one popular Python
 framework and after reporting bug which makes it unusable for even
 simple page layout, hearing nothing from the developer and then seeing
 it's fixed after more than two months, it was not difficult to abandon
 idea to base our sites on such a product.



 Your other ideas are well considered, but I have to take issue with this
 one.

 I have submitted many, many bug reports over the decades to Major
 Software Vendors with well supported software products.

 How many times have I gotten anything other than a robo-reply?

 zero

 When my company has paid $ in the 5 figures for "premium" tech service,
 what is the response to bug reports?

 nothing

 -- or --

 that's not a bug

 -- or --

 you're a unique snowflake and nobody else has that problem
 so we won't fix it

 How many times has a bug I reported ever been fixed, even waiting a year
 for the next update?

 zero

 I take that back. One time I got so mad about this I contacted the CEO
 of the Major Software Vendor (I knew him personally) and he got out a
 crowbar, went to see the dev team, and (allegedly) thwacked a few of
 them. The bug still never got fixed, but I got an acknowledgment.

 This has obviously never impeded anyone from using their software tools.

 It's also why:

 1. I never bother filing bug reports to Major Software Vendors anymore.

 2. With Digital Mars products, anyone can file a bug report with
 Bugzilla without needing me to acknowledge or filter it.

 3. Anyone can read and comment on those bug reports.

 4. I think we've had great success using Github and allowing anyone to
 fork & fix & publish.

 I know our response to bug reports is far from perfect, but at least we
 aren't hiding under a rock.

 It's also true that if a company wanted to bet the farm on D, and were
 willing to put some money behind it, their concerns would get priority,
 as full time professional developers could get hired to do it.
Jan 17 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
 Again: if D is a hobby we have, all's great. Otherwise, we must show  
 people that we are serious about finishing the core language  
 implementation, that we make promises that we are able to keep, and that  
 we make plans that we follow even in the broadest strokes. If we want to  
 play with the big boys, we need to change the way we approach planning  
 and organization quite drastically.


 Andrei


There is a lot of time wasted having to "reinvent" the designated
behavior during implementation/bugfixing.
IMHO we would benefit a lot from encouraging collaboration on the
Language Reference and use it to design unimplemented features.

Another efficient approach to steer this process is providing
unit tests.

Also such a simple page can be very useful.
http://digitalmars.com/ctg/CPP0x-Language-Implementation.html
Jan 16 2012
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 16/01/2012 01:23, Andrei Alexandrescu a écrit :

 On 1/15/12 11:42 AM, Kiith-Sa wrote:

 I'm interested in game development using D, so I'll post my opinion.

 I think the discussions here show how particularly specialized people
 here are. I've seen some Manu's posts and it was clear that he is a
 person
 in gamedev who thinks most development is like gamedev and can't see
 the bigger
 picture. For a gamedev person, SIMD support is not simply a cool
 feature, it's
 a gamechanger. Just like const, ranges, D threading features and so
 on. However,
 his posts often show that he doesn't understand positions of other
 people in other
 areas, e.g. people here working on scientific computing, who are also
 interested
 in SIMD but their thinking of terms such as "vector" is completely
 different.

 I think you're making the same mistake here - you have very little (or
 no?)
 idea about gamedev and aren't exposed to game programmers, so you just
 assume
 specific gamedev issues don't exist or are unimportant. I don't think
 you get
 much of exposure to game devs when evangelizing D either - you don't
 evangelize
 D in game companies.


 [snip]

 You are making a good point, and I'm glad you chimed in.

 I do have ties with the gaming community; I taught a course at ENDI and
 I am well acquainted with a few game developers. Also, at conferences
 and events gaming programmers are represented. Finally, game developers
 who are reading TDPL are likely to send me book feedback and questions
 in proportion to their representation. From where I stand, I can say
 there is more interest in D in other communities than in gaming.

 Clearly gamedev-specific issues do exist and are important. But that's
 not even remotely the point. Allow me to explain.

 Say we identified gaming programmers as an important community to
 address. If that happened, we would have done a /lot/ of things
 differently, and a ton of them before SIMD. That means focus on
 Windows64, graphic accelerators, and gaming CPUs. To claim that work on
 SIMD is good because it's good for gamers is to reverse engineer a
 rationalization after the fact. And the fact is - Walter has had the
 gusto to implement SIMD now. Technically, that's great. For gamers,
 that's an interesting development. Organizationally, that's a poor
 statement.

 Again: if D is a hobby we have, all's great. Otherwise, we must show
 people that we are serious about finishing the core language
 implementation, that we make promises that we are able to keep, and that
 we make plans that we follow even in the broadest strokes. If we want to
 play with the big boys, we need to change the way we approach planning
 and organization quite drastically.


 Andrei


To add more to the point, game develloper also face the core language. 
const or even worse shared issues are very important to game devellopers 
(you need a good threading support to code a game engine that exploit 
modern CPU, and to not choke on IO). So core languages feature bugs also 
affect game devellopers.
Jan 18 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/18/2012 09:22 PM, deadalnix wrote:

 To add more to the point, game develloper also face the core language.
 const or even worse shared issues are very important to game devellopers
 (you need a good threading support to code a game engine that exploit
 modern CPU, and to not choke on IO). So core languages feature bugs also
 affect game devellopers.


Much less so than SIMD support. Type system features like const or 
shared may help but are not necessary at all for creating an efficient 
game engine. (in fact, an efficient engine will maximize parallelism 
while keeping concurrency at a minimum.)

But then, I am not a professional game developer. Is there any game 
developer frequenting this NG who thinks const/shared are more important 
than SIMD?
Jan 18 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 16 January 2012 02:23, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org

 wrote:



 I do have ties with the gaming community; I taught a course at ENDI and I
 am well acquainted with a few game developers. Also, at conferences and
 events gaming programmers are represented. Finally, game developers who are
 reading TDPL are likely to send me book feedback and questions in
 proportion to their representation. From where I stand, I can say there is
 more interest in D in other communities than in gaming.


I'd just like to add one more point, that gamedev is, in general,
windows-centric. And D's support for windows is basically disgraceful.
I know numerous gamedevs who have grabbed it, tried it out, and immediately
dismissed it on account of immaturity.
I didn't find D on my own, I only EVENTUALLY looked into it because it kept
coming up in the office (ignored it for years actually).
What I *found* is a GCC toolchain (thank god, or... iain), and a reference
(windows) compiler that only supports x86, and no ability to link
against/with VisualStudio.
VisualStudio integration is still very raw, not supported by the community,
and I can imagine that had I looked a few months earlier and VisualD wasn't
there/usable, I wouldn't have humoured the language for more than 5 minutes
either myself, no matter its merits as a cool language.

You probably *won't* hear from the gamedevs either until they are able to
do anything more than dismiss it within 5 minutes.
VisualD and COFF, and to a slightly lesser extent x64, for me, are the
biggest tickets (bigger than SIMD, I don't need that until I'm working on
something)
As soon as those exist, I may consider introducing colleagues at work to
the language in some smaller tools/projects.

Funny aside: All I originally wanted from the SIMD threads was to be
assured it was on the map, and an acceptable design proposal
existed. Forunately for me, Walter was interested in implementing SIMD
himself, I had no part in that, and it appeared almost instantly! :) .. All
my early posts were LISTS of things that I felt were missing before I
confidently invest time in the language. It was certainly outside of my
control which of those things excited the most people, and started
conversations on the topic.

Clearly gamedev-specific issues do exist and are important. But that's not

 even remotely the point. Allow me to explain.

 Say we identified gaming programmers as an important community to address.
 If that happened, we would have done a /lot/ of things differently, and a
 ton of them before SIMD. That means focus on Windows64, graphic
 accelerators, and gaming CPUs. To claim that work on SIMD is good because
 it's good for gamers is to reverse engineer a rationalization after the
 fact. And the fact is - Walter has had the gusto to implement SIMD now.
 Technically, that's great. For gamers, that's an interesting development.
 Organizationally, that's a poor statement.

 Again: if D is a hobby we have, all's great. Otherwise, we must show
 people that we are serious about finishing the core language
 implementation, that we make promises that we are able to keep, and that we
 make plans that we follow even in the broadest strokes. If we want to play
 with the big boys, we need to change the way we approach planning and
 organization quite drastically.



I generally agree actually. For myself (and perhaps on behalf of my
industry), Win64, COFF, and assurance that some VisualStudio integration
team is getting proper support is far more important/should receive
priority.

You lead me to an interesting though though...
I have been realising one thing that is concerning me more and more though,
and that is that for some reason, it always comes back to Walter. This
seems absurd.
Why should any feature be contingent on Walters time/excitement for the
feature? He should be allowed to work on the SIMD if he wants, and it
shouldn't significantly affect anyone. Is he being paid? (I don't actually
know)
I was initially under the impression that D was an open source language,
and there were a significant number of contributors... if Walter were hit
by a bus, what would happen to D?

This point is highlighted by your anger/frustration that Walter worked on
the SIMD stuff out of step. If you're the second(?) most authoritive voice
around here, what does that say about the state of the language development
and the team responsible?
Jan 19 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/12 3:25 AM, Manu wrote:

 On 16 January 2012 02:23, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org <mailto:SeeWebsiteForEmail erdani.org>>
 wrote:

     I do have ties with the gaming community; I taught a course at ENDI
     and I am well acquainted with a few game developers. Also, at
     conferences and events gaming programmers are represented. Finally,
     game developers who are reading TDPL are likely to send me book
     feedback and questions in proportion to their representation. From
     where I stand, I can say there is more interest in D in other
     communities than in gaming.


 I'd just like to add one more point, that gamedev is, in general,
 windows-centric. And D's support for windows is basically disgraceful.


[snip]

 You probably /won't/ hear from the gamedevs either until they are
 able to do anything more than dismiss it within 5 minutes.


This notion is akin to my "if we considered gamers a core market, we 
would have done a lot of things differently".

[snip]

 You lead me to an interesting though though...
 I have been realising one thing that is concerning me more and more
 though, and that is that for some reason, it always comes back to
 Walter. This seems absurd.
 Why should any feature be contingent on Walters time/excitement for the
 feature? He should be allowed to work on the SIMD if he wants, and it
 shouldn't significantly affect anyone. Is he being paid? (I don't
 actually know)


Walter is working full time on D. I and most others are working on it 
part-time. (I'm not counting people who work _with_ D.)


 I was initially under the impression that D was an open source language,
 and there were a significant number of contributors... if Walter were
 hit by a bus, what would happen to D?


That hasn't been an issue for a while now. There are several other 
people who know and understand the language, dmd compiler, and the 
standard library very well. But as of now Walter is the gatekeeper of 
fixes and features for the simple reason that he wants to still 
understand what's going on. This is a common approach. He's also the 
foremost decision maker for what major features go into the language.


 This point is highlighted by your anger/frustration that Walter worked
 on the SIMD stuff out of step. If you're the second(?) most authoritive
 voice around here, what does that say about the state of the language
 development and the team responsible?


To me it says we need to improve our organization.


Andrei
Jan 19 2012
parent Manu <turkeyman gmail.com> writes:
On 19 January 2012 18:10, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org

 wrote:



 On 1/19/12 3:25 AM, Manu wrote:


 On 16 January 2012 02:23, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org
<mailto:SeeWebsiteForEmail **erdani.org<SeeWebsiteForEmail erdani.org>




 wrote:

    I do have ties with the gaming community; I taught a course at ENDI
    and I am well acquainted with a few game developers. Also, at
    conferences and events gaming programmers are represented. Finally,
    game developers who are reading TDPL are likely to send me book
    feedback and questions in proportion to their representation. From
    where I stand, I can say there is more interest in D in other
    communities than in gaming.


 I'd just like to add one more point, that gamedev is, in general,
 windows-centric. And D's support for windows is basically disgraceful.


 [snip]


 You probably /won't/ hear from the gamedevs either until they are
 able to do anything more than dismiss it within 5 minutes.


 This notion is akin to my "if we considered gamers a core market, we would
 have done a lot of things differently".


But with this in mind, do you think it's possible that your perceived
'interested users' statistics may be slightly skewed. What IS your core
market?
It stands to perfect reason that, while the linux toolchain is the only one
that works properly, the majority of users you will come in contact with
will be researchers and students through universities, and the occasional
linux/language geek, who is generally interested from a research point of
view too.

What commercial industries are using/interested in using D?

I really feel that the state of the tools excludes a potentially huge
industry from being interested, but it sounds like that was intentional,
ie. not identified as a core market, and therefore the windows tools were
never made a priority?



 Jan 19 2012



prev sibling  parent reply Brad Roberts <braddr puremagic.com>  writes:


On 1/19/2012 1:25 AM, Manu wrote:

 You lead me to an interesting though though...
 I have been realizing one thing that is concerning me more and more though,
and that is that for some reason, it always
 comes back to Walter. This seems absurd.
 Why should any feature be contingent on Walters time/excitement for the
feature? He should be allowed to work on the
 SIMD if he wants, and it shouldn't significantly affect anyone.


Focusing on dmd for this email, phobos and druntime are essentially not
dependent on Walter in any way:

Very little is truly contingent on Walter (though some parts are, such as
optlink).  Currently, for dmd, all the patches
flow through him (there's a couple others that do have commit privs but we
don't use them).  ANYONE is free to develop
changes and submit pull requests.  The problem is that there's few who
currently do (around a dozen, and only 3 or 4
that are particularly active).  For changes that don't come from the community,
Walter fills in the gaps.  Over the last
couple years, the number of contributors to dmd has grown nicely, if slowly. 
If someone wrote the code for dmd to emit
coff format .obj files and it was demonstrated to work well with the microsoft
compiler tool chain, I'll bet my next
paycheck that it'd be integrated seriously fast.

I pulled the stats on the number of pull requests we've seen since moving to
github yesterday (see the phobos list for
the full details), but I'll repeat one from memory.  There's been 615 pulls to
dmd of which only 58 are still open.
That's 91% handled and 9% left.  A decent number of requests are delt with on a
daily basis.

Another interesting tool is github's impact grph:
  https://github.com/D-Programming-Language/dmd/graphs/impact

Anyway, hope that colors things a bit for you.

Later,
Brad



 Jan 19 2012



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/19/12 1:30 PM, Brad Roberts wrote:

 Another interesting tool is github's impact grph:
    https://github.com/D-Programming-Language/dmd/graphs/impact


I was never able to interpret that saliently.

Andrei



 Jan 19 2012



  parent  Brad Roberts <braddr puremagic.com>  writes:


On 1/19/2012 12:27 PM, Andrei Alexandrescu wrote:

 On 1/19/12 1:30 PM, Brad Roberts wrote:

 Another interesting tool is github's impact grph:
    https://github.com/D-Programming-Language/dmd/graphs/impact


 
 I was never able to interpret that saliently.
 
 Andrei



From below the graph:


Blocks represent "impact". Impact is (lines added + lines deleted) for all
non-merge commits during a week period.

So, for a given day, it's showing the people who's contributed changes for that
day.  For each person, their
contributions through time are linked into one flow.  You can click on any
day+person block and it will highlight that
flow across time to make it easier to follow.

Or at least, that's how I read it.  It's more cute than super useful, but it
does give a quick visual description of
who's contributing.



 Jan 19 2012



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/19/2012 11:30 AM, Brad Roberts wrote:

 Focusing on dmd for this email, phobos and druntime are essentially not
dependent on Walter in any way:


There is also a fair amount of low hanging fruit in bugzilla. For example,
there 
are patches that can be turned into pull requests, and some one liners.



 Jan 19 2012



prev sibling  parent  Manu <turkeyman gmail.com>  writes:


On 15 January 2012 19:42, Kiith-Sa <42 theanswer.com> wrote:


 I'm interested in game development using D, so I'll post my opinion.

 I think the discussions here show how particularly specialized people
 here are. I've seen some Manu's posts and it was clear that he is a person
 in gamedev who thinks most development is like gamedev and can't see the
 bigger
 picture.



I just want to clarify, I don't think this is a fair call, but I can see
why you might think that.
I am obviously a professional gamedev, and I am interested in D. I'm just
trying to illustrate my case that, for me to consider D for
professional/commercial use, there are some (rather small really) features
that I need to do my job.
I can see the bigger picture, but I'm not a representative of any other
part of it. I can only present, with confidence, important points that are
important to my industry.
I expect other people from other industries to make sure their perspectives
are heard and assure they're covered.
I'm certainly not trying to turn D into a gamedev language, I'm just trying
to encourage proper implementation of some key missing features that
support being used in the gamedev environment (and for performance oriented
systems programming in general actually).

I think my single point that started this whole thing off was something to
the tune of: "As a high end company, we could not possibly choose D for a
high end title until this feature existed"

From then on, it was just discussing details, and backing up my claim.




 For a gamedev person, SIMD support is not simply a cool feature, it's
 a gamechanger. Just like const, ranges, D threading features and so on.
 However,
 his posts often show that he doesn't understand positions of other people
 in other
 areas, e.g. people here working on scientific computing, who are also
 interested
 in SIMD but their thinking of terms such as "vector" is completely
 different.


I don't actually see how it really affects other users, except with library
maturity, they'll see faster libraries too.
Non-SIMD/conventional vectors are already well defined in D. Science will
need to deal with arbitrary sized vectors, and arbitrary sized matrices.
This is a fundamentally different topic than raw access to the hardware
instructions (something like 50% of the CPUs silicone (excluding
cache) that sit there dormant in any D program to date).
A nice library for use in scientific computing should exist for that
audience (if it doesn't already), and I'm sure it too can implement some
nice efficiency gains by using the low level API I have been proposing
under the hood.

What most people don't seem to understand is that the SIMD API I've been
pushing for in D will NOT be used directly by almost anyone. It's too low
level for general use. It exposes the hardware facilities for optimisation
in the most efficient way possible to facilitate *library development*.
This can be games oriented, physics oriented, scientifically oriented,
anything. It's all about the libraries :)

I think you're making the same mistake here - you have very little (or no?)

 idea about gamedev and aren't exposed to game programmers, so you just
 assume
 specific gamedev issues don't exist or are unimportant. I don't think you
 get
 much of exposure to game devs when evangelizing D either - you don't
 evangelize
 D in game companies.


I support this point. We discuss D fairly regularly at work. Most people
don't have the time or interest to involve themselves in the NG or IRC. I
just like making a noise, and it's nice to see progress in a direction that
supports us.

I realise you're actually arguing on my side of the fence in general, but I
just wanted to clear those points up :)



 Jan 19 2012



prev sibling next sibling parent  "F i L" <witte2008 gmail.com>  writes:


On Sunday, 15 January 2012 at 03:31:15 UTC, Andrei Alexandrescu 
wrote:

 On 1/14/12 9:06 PM, Jonathan M Davis wrote:

 On Saturday, January 14, 2012 20:54:55 Michel Fortin wrote:

 Still, Walter perfectly has the right to decide on what he 
 wants to
 work. I understand that he saw implementing SIMD as an 
 interesting
 challenge, and if working on SIMD keeps things interesting 
 for him,
 that can only be great.


 Sure. I can understand why the most important thing to work  
 on might not be
 the most interesting thing to work on. And Walter certainly 
 has the right to
 work on whatever he wants to work on.


 Exactly and perfectly right. To add to that, with my limited 
 time, I can hardly afford to work on stuff that isn't fun 
 (although lately I've done some of it - e.g. I'm not a web 
 designer). There comes a point, however, when we need to decide 
 whether our main priority is having fun or making D successful.


I would argue that a happy coder is a productive coder. I'm 
personally very please Walter and others are so interested in 
SIMD support. Then again, it suites my interests so I admit bias.



 2. We haven't identified game designers as a core market, and 
 one that's more important than e.g. general purpose programmers 
 who need the like of working qualifiers, multithreading, and 
 shared libraries.
 
 3. There was never a promise or even a mention that we'll 
 deliver SIMD. We virtually promise we deliver threads and 
 expressive qualifiers, and there's still work to do on that.



 5. The SIMD work has _zero_ acceleration on existing code; it 
 only allows experts to write non-portable code that uses SIMD 
 instructions. Updating to the next release of dmd has zero 
 SIMD-related benefit to statistically our entire user base.

 Walter and I spend hours on the phone discussing strategies and 
 tactics to make D more successful. And then comes this binge. 
 Doing anything on SIMD now is a mistake that I am sorry I was 
 unable to stop. About the only thing that's good about it all 
 is that it'll be over soon.


 Andrei


To put it plainly, I wouldn't really be interested in D if it 
wasn't for game design and art applications. C/C++ has been 

business/server world for years because of painless development, 
fancy libraries, and features like Linq. But one area C/C++ still 
remain strong is among performance critical code. Given D's 
opening message: "Modeling power. Native efficiency." and it's 
goal of succeeding C++, I don't see how you can sideline one of 
C's most invested parties so easily.



 Jan 15 2012



prev sibling next sibling parent  bearophile <bearophileHUGS lycos.com>  writes:


Andrei Alexandrescu:


 2. We haven't identified game designers as a core market, and one that's 
 more important than e.g. general purpose programmers who need the like 
 of working qualifiers, multithreading, and shared libraries.


From what I've seen games were one of the very few significant applications of
D1 language.

Bye,
bearophile



 Jan 15 2012



prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org>  writes:


On 01/14/2012 10:31 PM, Andrei Alexandrescu wrote:

 2. We haven't identified game designers as a core market


You probably should, as C++ is the de facto standard in the games

or Java. You might even be able to get some funding from big companies
like EA or others if you can convince them you're on the right track.


 and one that's more important than e.g. general purpose programmers
 who need the like of working qualifiers, multithreading, and shared
 libraries.


And this is just as, if not more important, in the games industry as
elsewhere. I do agree that a correct and full implementation of these
features is more important than Walter getting distracted on a late-game
feature request. Since Walter is gating pull requests, he should either
prioritize them or delegate the responsibility.



 Jan 15 2012



  parent  =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com>  writes:


On 15-01-2012 18:02, Jeff Nowakowski wrote:

 On 01/14/2012 10:31 PM, Andrei Alexandrescu wrote:

 2. We haven't identified game designers as a core market


 You probably should, as C++ is the de facto standard in the games

 or Java. You might even be able to get some funding from big companies
 like EA or others if you can convince them you're on the right track.


Not gonna happen until the GC is fixed. That much is safe to say.


 and one that's more important than e.g. general purpose programmers
 who need the like of working qualifiers, multithreading, and shared
 libraries.


 And this is just as, if not more important, in the games industry as
 elsewhere. I do agree that a correct and full implementation of these
 features is more important than Walter getting distracted on a late-game
 feature request. Since Walter is gating pull requests, he should either
 prioritize them or delegate the responsibility.


--
- Alex



 Jan 15 2012



prev sibling  parent reply "Nick Sabalausky" <a a.a>  writes:


"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jetha2$2csv$1 digitalmars.com...

 2. We haven't identified game designers as a core market, and one that's 
 more important than e.g. general purpose programmers who need the like of 
 working qualifiers, multithreading, and shared libraries.


I have to strongly take issue with this one. Let's take a look at what D 
intends to be:

A multi-paradigm, natively-compiled, systems language that's designed as a 
reimagined C++, and is better at high-level than C++, and goes every bit as 
low-level as C++.

How the fuck does that *not* implicitly say "game dev" already?

Hell, it's already *more* of a gamedev langauge than a "general purpose 
programmers" langauge anyway: General purpose programmers *already* have 
fucking billions of VM and interpreted langauges that most of them are 
perfectly happy with. What the hell do game devs have besides D? Umm, 

anyway)...and, oh yea, that's it! If it weren't the the prospect of gamedev, 
I never would have even gotten into D in the first place.

It doesn't matter if *you've* identified game dev as a market you care 
about: D *is already* a gamedev language. And gamedev is already an *ideal* 
audience for D to target.

(And like other have mentioned: Derelict - a game oriented library - is one 
of the *oldest* still-alive D libs out there.)



 Jan 15 2012



 next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com>  writes:


On 15-01-2012 21:57, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jetha2$2csv$1 digitalmars.com...

 2. We haven't identified game designers as a core market, and one that's
 more important than e.g. general purpose programmers who need the like of
 working qualifiers, multithreading, and shared libraries.


 I have to strongly take issue with this one. Let's take a look at what D
 intends to be:

 A multi-paradigm, natively-compiled, systems language that's designed as a
 reimagined C++, and is better at high-level than C++, and goes every bit as
 low-level as C++.

 How the fuck does that *not* implicitly say "game dev" already?

 Hell, it's already *more* of a gamedev langauge than a "general purpose
 programmers" langauge anyway: General purpose programmers *already* have
 fucking billions of VM and interpreted langauges that most of them are
 perfectly happy with. What the hell do game devs have besides D? Umm,

 anyway)...and, oh yea, that's it! If it weren't the the prospect of gamedev,
 I never would have even gotten into D in the first place.

 It doesn't matter if *you've* identified game dev as a market you care
 about: D *is already* a gamedev language. And gamedev is already an *ideal*
 audience for D to target.

 (And like other have mentioned: Derelict - a game oriented library - is one
 of the *oldest* still-alive D libs out there.)


.
And yet, D's situation on Windows, the main gaming platform, is less 
than ideal. If we're really going to cater to game devs, we need to fix 
the entire Windows situation long before adding SIMD, IMHO.

That being said, I do agree that D is a great language for game dev. 
It's really just the Windows tool chain that's in a rather bad state.

--
- Alex



 Jan 15 2012



  parent reply "Nick Sabalausky" <a a.a>  writes:


"Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
news:jevgk4$2nq3$1 digitalmars.com...

 On 15-01-2012 21:57, Nick Sabalausky wrote:

 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jetha2$2csv$1 digitalmars.com...

 2. We haven't identified game designers as a core market, and one that's
 more important than e.g. general purpose programmers who need the like 
 of
 working qualifiers, multithreading, and shared libraries.


 I have to strongly take issue with this one. Let's take a look at what D
 intends to be:

 A multi-paradigm, natively-compiled, systems language that's designed as 
 a
 reimagined C++, and is better at high-level than C++, and goes every bit 
 as
 low-level as C++.

 How the fuck does that *not* implicitly say "game dev" already?

 Hell, it's already *more* of a gamedev langauge than a "general purpose
 programmers" langauge anyway: General purpose programmers *already* have
 fucking billions of VM and interpreted langauges that most of them are
 perfectly happy with. What the hell do game devs have besides D? Umm,

 anyway)...and, oh yea, that's it! If it weren't the the prospect of 
 gamedev,
 I never would have even gotten into D in the first place.

 It doesn't matter if *you've* identified game dev as a market you care
 about: D *is already* a gamedev language. And gamedev is already an 
 *ideal*
 audience for D to target.

 (And like other have mentioned: Derelict - a game oriented library - is 
 one
 of the *oldest* still-alive D libs out there.)


 .
 And yet, D's situation on Windows, the main gaming platform, is less than 
 ideal. If we're really going to cater to game devs, we need to fix the 
 entire Windows situation long before adding SIMD, IMHO.

 That being said, I do agree that D is a great language for game dev. It's 
 really just the Windows tool chain that's in a rather bad state.


I'm on windows, and I think it's good enough. Yes, it *is* definitely a 
problem for new D users, but all the OMF/COFF stuff *does* have viable 
workarounds, so it's not exactly a dealbreaking issue.



 Jan 15 2012



  parent  "Nick Sabalausky" <a a.a>  writes:


"Nick Sabalausky" <a a.a> wrote in message 
news:jf0au6$12jv$1 digitalmars.com...

 "Alex Rønne Petersen" <xtzgzorex gmail.com> wrote in message 
 news:jevgk4$2nq3$1 digitalmars.com...

 .
 And yet, D's situation on Windows, the main gaming platform, is less than 
 ideal. If we're really going to cater to game devs, we need to fix the 
 entire Windows situation long before adding SIMD, IMHO.

 That being said, I do agree that D is a great language for game dev. It's 
 really just the Windows tool chain that's in a rather bad state.


 I'm on windows, and I think it's good enough. Yes, it *is* definitely a 
 problem for new D users, but all the OMF/COFF stuff *does* have viable 
 workarounds, so it's not exactly a dealbreaking issue.


Of course, I don't mean to say the windows toolchain is perfectly ok as-is, 
or that it doesn't have big issues that do need to be resolved (prefereably 
sooner than later). I'm just saying it isn't a blocking matter. Critical, 
maybe, but not blocking.

Oh, and Windows is the main *desktop* gaming platform. Not so sure about 
"main gaming platform" as desktop gaming itself is mostly (I said "mostly", 
not "entirely") limited to PopCap-grannies and a vocal-but-minority group of 
kids who sink hundreds of dollars into their overpowered rigs every year (I 
would know - I used to be one of them (the kids, not the grannies ;) ) until 
I grew up).

Although, with all the non-desktop gaming platforms, D's toolchain may 
actually be *worse* on than on windows. *That* needs to be fixed - much 
moreso than the windows issues, IMO. Hell, even with non-gaming, can D 
currently be used on mobile at all? These are exactly the sorts of platforms 
where D really fits *best*. These systems have limited langauge options and 
high requirements for a good langauge - desktop and web people (like me :/ ) 
already have five gazillion languages.



 Jan 15 2012



prev sibling  parent reply Gour <gour atmarama.net>  writes:


On Sun, 15 Jan 2012 15:57:27 -0500
"Nick Sabalausky" <a a.a> wrote:


 It doesn't matter if *you've* identified game dev as a market you
 care about: D *is already* a gamedev language. And gamedev is already
 an *ideal* audience for D to target.


Then it would be nice if the gamedev industry could identify D as
gamedev language as well and pour some $s, =E2=82=ACs...to support/speed up
development, but I wonder why it does not happen. ;)


Sincerely,
Gour


--=20
Bewildered by the modes of material nature, the ignorant fully=20
engage themselves in material activities and become attached. But=20
the wise should not unsettle them, although these duties are inferior=20
due to the performers' lack of knowledge.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810



 Jan 16 2012



  parent reply Russel Winder <russel russel.org.uk>  writes:


On Mon, 2012-01-16 at 09:03 +0100, Gour wrote:
[...]

 Then it would be nice if the gamedev industry could identify D as
 gamedev language as well and pour some $s, =E2=82=ACs...to support/speed =


up

 development, but I wonder why it does not happen. ;)


<devils-advocate>
The games industry works with C, C++, assembly language, Python and Lua.
They have serious toolchains for working with serious graphics and
modeling libraries.  The last thing they need is a new, incomplete,
poorly resourced, one-man-band implementation programming language with
very few programmers, and no experience of being used in this arena.

Existing games company executives would be labelled as suicidal to
switch from the current toolchains to the lack of toolchain
infrastructure that is D.  Thus D has no chance of any traction in that
arena unless it can show a huge decrease in time to market, and massive
increase in quality of game (gameplay management, speed of rendering,
etc.) -- not just theoretically, but actually.

Working with Visual Studio is the only route to Windows market.  This
means working in harmony with the C and C++ toolchains.=20

In the current climate D has no chance in the game industry.
</devils-advocate>

On the constructive front, what D needs is a few startups to use it and
be successful.  The only way to get traction and create success in the
current state of the world is to already have success.  The way of
getting that is to have people who have nothing to lose and everything
to gain, even if they have no money, use it to create successful systems
and promulgate a culture of success.

Any system and community that doubts itself won't be taken seriously.
Any system and community that gets too introverted and/or arrogant is
doomed.  cf. Ruby, Scala, ...

Fortran is a special case.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Jan 16 2012



  parent reply "Paulo Pinto" <pjmlp progtools.org>  writes:



Sony now

PlaySuite, it
might already be too late for D in the gaming world.

There are already quite a few iPhone major game titles that are actually 
developed with Unity.

But I am an outsider, here the other members with game industry experience 
like Manu might
explain better the situation.

--
Paulo

"Russel Winder"  wrote in message 
news:mailman.435.1326708497.16222.digitalmars-d puremagic.com...
On Mon, 2012-01-16 at 09:03 +0100, Gour wrote:
[...]

 Then it would be nice if the gamedev industry could identify D as
 gamedev language as well and pour some $s, €s...to support/speed up
 development, but I wonder why it does not happen. ;)


<devils-advocate>
The games industry works with C, C++, assembly language, Python and Lua.
They have serious toolchains for working with serious graphics and
modeling libraries.  The last thing they need is a new, incomplete,
poorly resourced, one-man-band implementation programming language with
very few programmers, and no experience of being used in this arena.

Existing games company executives would be labelled as suicidal to
switch from the current toolchains to the lack of toolchain
infrastructure that is D.  Thus D has no chance of any traction in that
arena unless it can show a huge decrease in time to market, and massive
increase in quality of game (gameplay management, speed of rendering,
etc.) -- not just theoretically, but actually.

Working with Visual Studio is the only route to Windows market.  This
means working in harmony with the C and C++ toolchains.

In the current climate D has no chance in the game industry.
</devils-advocate>

On the constructive front, what D needs is a few startups to use it and
be successful.  The only way to get traction and create success in the
current state of the world is to already have success.  The way of
getting that is to have people who have nothing to lose and everything
to gain, even if they have no money, use it to create successful systems
and promulgate a culture of success.

Any system and community that doubts itself won't be taken seriously.
Any system and community that gets too introverted and/or arrogant is
doomed.  cf. Ruby, Scala, ...

Fortran is a special case.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: 
sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder 



 Jan 16 2012



  parent reply Peter Alexander <peter.alexander.au gmail.com>  writes:


== Quote from Paulo Pinto (pjmlp progtools.org)'s article




360/Windows/WP7 and

 Sony now



and

 PlaySuite, it
 might already be too late for D in the gaming world.
 There are already quite a few iPhone major game titles that are


actually

 developed with Unity.
 But I am an outsider, here the other members with game industry


experience

 like Manu might
 explain better the situation.



professional AAA games are still written in C or C++.


to develop in C++. D isn't so painful, so there's an opportunity to




 Jan 16 2012



 next sibling parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


I always thought D would be a great language for making tools for
gamedevs, e.g. UnrealEd. AFAIK UED was originally written in VBasic
before being ported to C++.



 Jan 16 2012



prev sibling  parent reply "Paulo Pinto" <pjmlp progtools.org>  writes:


According to the latest issue from the German games developer magazine,
most people only buy one to two AAA games per year. Spending much more
money in casual games.

As such, what AAA studios use, is to some extent irrelevant. As only a few 
studios
worldwide are able to produce AAA games.

For example, there are several game studios in Hamburg and Berlin that are 
quite
happy selling games that are Flash based with a J2EE/.NET solution for the 
game server.

--
Paulo



"Peter Alexander"  wrote in message news:jf17uj$2tfk$1 digitalmars.com...

== Quote from Paulo Pinto (pjmlp progtools.org)'s article




360/Windows/WP7 and

 Sony now



and

 PlaySuite, it
 might already be too late for D in the gaming world.
 There are already quite a few iPhone major game titles that are


actually

 developed with Unity.
 But I am an outsider, here the other members with game industry


experience

 like Manu might
 explain better the situation.



professional AAA games are still written in C or C++.


to develop in C++. D isn't so painful, so there's an opportunity to




 Jan 16 2012



  parent reply =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim gmail.com>  writes:


Hi, here are my random 2 cents about the gamedev point, as someone who have
worked in the game industry and will get to full-indie gamedev in the
future :

A.


 1. It's easier to code with than C++ and with decent performance;

 3. It have full support of Visual Studio (even better than C++ at the
moment);

Also Sony is going the same way than Microsoft in providing a framework to


1. can be done by D if it have a stable and complete implementation
2. cannot be done by D without a GUI framework. It don't exist in D (and I
guess it will get in the same state than C++ having to work with
non-c++-idiom-based-Qt library...)
3. cannot be done without a very big plugin in VS (that can be done but
require fare more work than the current VisualD plugin)

B.


target the same goals. For gamedevs, having the core game in D would be
interesting but for instance, without a killer app to demonstrate D power,
it's hard to know what's teh D state and how it helps.

Also, D have one HUGE advantage over C++ that could be a killer feature :
it compiles faster.

C.

As already said, having access to C++ libraries would have heavy weight in
the choice of language for game developer (startup or not).

However, if some basic bricks libraries would be available directly in D,
it would help some people build interesting games in D. Assuming they are
not binding over other libraries, D would need 1 or more (more is better):

 - generic graphic library (like Ogre3D - not as low as OpenGL/DirectX, but
very flexible)
 - generic input library (like OIS - not as low as directly having hardware
inputs, but very flexible)
 - generic audio library (like FMod/IrkkLang, etc. - not as low as OpenAL,
but very flexible)

At least.
I think D-idiomatic libraries that would implement such systems would make
game dev. easier for anyone wanting to use D for gam dev.
Also, note that SDL and SFML can be used in D but they are C++ idiomatic
and that feels in the design. Any additional layer over libraries is just a
potential point of headache. Game devs avoid those additional layers.

D.

Personally, I would have tried D for making some experimental games if I
had more time and if wasn't a bit disapointed by the language not being
implemented fully. That's the main reason I'm sticking with reading this
community discussions, to know when it seems stable enough for me to try
something small. I don't really mind having (open source) libraries issues,
but compiler issues are kind of a showstopper for me.

E.

Are there any contacts from D developers to console companies? I think it
would be very helpful for the D-team to have somme discussions with them,
see what they think about allowing game devs to use this language instead
of C++.

Hope that this random feedback helps.

Jo=C3=ABl Lamotte



 Jan 16 2012



  parent reply Kiith-Sa <42 theanswer.com>  writes:


A:
1 - 
I think we're getting close to that point. I do encounter compiler bugs
from time to time, but the frequency is rapidly decreasing with the recent
releases. We already have the "Easier to code" and "Decent performance" 
parts, but there's a lot of room to improve (standard build system, package
manager, better Phobos, better GC or better noGC options).

2 -
This is a problem and it probably will continue to be so for some time.
Native D GUI framework of size of GTK/Qt is infeasible. 
AFAIK GtkD is usable now, but not sure how D-like its API is, probably
not much?

I'm now pretty much forced to write a simple D game GUI library now 
(think CEGUI on a much smaller scale) - I spent some time convincing
my teacher (university) to accept a project in D and now I'll have 
to produce something. I don't expect to turn that into something 
massive like Gtk/Qt, though.

3 -
That, too is a problem, and I'm saying that as a Vim user.
I think the situation is improving, though, and outside AAA industry
Visual Studio is not quite as dominant. E.g. if we ever get decent 
ARM/Android support, an Android dev working with Eclipse/Java might
find it easy to move to Eclipse/D (again, if D is stable enough).


B:


sight it looks closer to C++.

As for killer app, yeah, we need that. I'm pretty sure some people on this
newsgroup are trying to work on that.


C:

For a 3D engine, there is YAGE which AFAIK is still developed, but it's in D1.
Not sure what the dev's plans are when D1 gets unsupported.

OIS: Didn't know about this one, will take a look.
Could something similar be built on top of SDL or does it provide more
low-level stuff not supported by SDL?

Audio library - probably not going to happen in a while.

I think we can't realistically expect someone to write an SDL/SFML equivalent
in pure D in the near future. I'd like to look at creating a D-style 
SDL wrapper once SDL2 is stable (no point wrapping SDL 1.2, it's pretty 
outdated and SDL2 AFAIK drastically changes the API).


D:

As said before, compiler errors are getting rare (at least for me).
Expect to be able to use D in a few months.


E:

I'm pretty sure D has very little chance becoming a language used in 
the next generation of consoles - D would have to be stable right now
(and compile on PowerPC and/or ARM) for that to work. Also the AAA 
game industry in general already depends on massive amount of C++
middleware they're not going to throw out. 

I think, however, that general purpose mobile devices are going to 
be more important than consoles in the near future. That market is 
still changing and we might get some chance there IF we get usable 
ARM support ASAP. 

Also, some of the indie PC developers might be more likely
to try out D than the AAA industry - if we get some decent basic libraries.



 Jan 16 2012



 next sibling parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/16/2012 1:02 PM, Kiith-Sa wrote:

 Also, some of the indie PC developers might be more likely
 to try out D than the AAA industry - if we get some decent basic libraries.


Keep in mind that D can directly access any C library.

The Deimos project https://github.com/D-Programming-Deimos/ is growing rapidly. 
If there is a C library you (or anyone else) need to use that doesn't have an 
interface in Deimos, and you find yourself having to write one, please 
contribute it to Deimos.



 Jan 16 2012



  parent reply Kiith-Sa <42 theanswer.com>  writes:


Walter Bright wrote:


 On 1/16/2012 1:02 PM, Kiith-Sa wrote:

 Also, some of the indie PC developers might be more likely
 to try out D than the AAA industry - if we get some decent basic libraries.


 
 Keep in mind that D can directly access any C library.
 
 The Deimos project https://github.com/D-Programming-Deimos/ is growing rapidly.
 If there is a C library you (or anyone else) need to use that doesn't have an
 interface in Deimos, and you find yourself having to write one, please
 contribute it to Deimos.


I'm well aware of the fact - my work depends on SDL, OpenGL and FreeType 
using the Derelict bindings (Those probably don't belong to Deimos as they're
not absolutely thin bindings although they don't wrap the APIs in any way)

I'm trying to write D libraries instead of bindings to C when possible, 
though - this results less dependencies and much better API. (That only
works for small libraries, though - I have no interest in spending
next 10 years rewriting something like OGRE3D)



 Jan 16 2012



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/16/2012 3:26 PM, Kiith-Sa wrote:

 I'm well aware of the fact - my work depends on SDL, OpenGL and FreeType
 using the Derelict bindings (Those probably don't belong to Deimos as they're
 not absolutely thin bindings although they don't wrap the APIs in any way)


It would be nice to split the Derelict bindings in twain - a thin layer for 
Deimos, and then the more D-ish layer for Derelict on top of that.


 I'm trying to write D libraries instead of bindings to C when possible,
 though - this results less dependencies and much better API. (That only
 works for small libraries, though - I have no interest in spending
 next 10 years rewriting something like OGRE3D)


Of course. It makes little sense to re-engineer well developed libraries like 
openssl, but a lot of sense to wrap a D-ish interface around it.



 Jan 16 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-01-17 02:05, Walter Bright wrote:

 On 1/16/2012 3:26 PM, Kiith-Sa wrote:

 I'm well aware of the fact - my work depends on SDL, OpenGL and FreeType
 using the Derelict bindings (Those probably don't belong to Deimos as
 they're
 not absolutely thin bindings although they don't wrap the APIs in any
 way)


 It would be nice to split the Derelict bindings in twain - a thin layer
 for Deimos, and then the more D-ish layer for Derelict on top of that.


It doesn't contain a D-ish layer. The only idea beside the bindings are 
to help loading the libraries at runtime platform independent.

-- 
/Jacob Carlborg



 Jan 16 2012



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2012-01-16 22:02, Kiith-Sa wrote:

 A:
 1 -
 I think we're getting close to that point. I do encounter compiler bugs
 from time to time, but the frequency is rapidly decreasing with the recent
 releases. We already have the "Easier to code" and "Decent performance"
 parts, but there's a lot of room to improve (standard build system, package
 manager, better Phobos, better GC or better noGC options).

 2 -
 This is a problem and it probably will continue to be so for some time.
 Native D GUI framework of size of GTK/Qt is infeasible.
 AFAIK GtkD is usable now, but not sure how D-like its API is, probably
 not much?


DWT is a GUI library completely written in D:

http://www.dsource.org/projects/dwt

-- 
/Jacob Carlborg



 Jan 16 2012



  parent  Kiith-Sa <42 theanswer.com>  writes:


Jacob Carlborg wrote:


 On 2012-01-16 22:02, Kiith-Sa wrote:

 A:
 1 -
 I think we're getting close to that point. I do encounter compiler bugs
 from time to time, but the frequency is rapidly decreasing with the recent
 releases. We already have the "Easier to code" and "Decent performance"
 parts, but there's a lot of room to improve (standard build system, package
 manager, better Phobos, better GC or better noGC options).

 2 -
 This is a problem and it probably will continue to be so for some time.
 Native D GUI framework of size of GTK/Qt is infeasible.
 AFAIK GtkD is usable now, but not sure how D-like its API is, probably
 not much?


 
 DWT is a GUI library completely written in D:
 
 http://www.dsource.org/projects/dwt
 


DWT is a plain rewrite of SWT.
When writing D, I want to write D, not Java. I'd even prefer a C toolkit with 
a D-style wrapper to that. I do think that D is an awesome language to 
build a GUI toolkit from ground up - it's just unlikely to happen soon because
of the effort involved.



 Jan 17 2012



prev sibling  parent reply Michel Fortin <michel.fortin michelf.com>  writes:


On 2012-01-15 03:06:22 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:


 It seems that the problem is that while Walter can be saved effort by 
 having someone else do that kind of work, it doesn't necessarily save 
 him all that much effort, since he still must ultimately take the time 
 to fully understand what's being changed and what the implications are 
 before he merges it in.


It still saves the effort of coming up with a solution, implementing 
that solution, updating the test suite, etc. I think this is 
significant. But you're right, it's more effort to review than most 
other pull requests, and it might not be something he likes to do.




 makes sense if it takes longer for it to be sorted out. Still, given 

 have been handled much sooner than this. It's getting very close to 
 being a year old.


A year old and outdated: it won't merge cleanly anymore (despite the 
update I made this summer). I should probably keep maintaining it, but 
as it is now I don't think I'll bother until Walter is ready to look at 
it.

But I'm a little surprised he hasn't even looked at it yet given this 
is a problem he tried to fix himself before. In his place, I'd be very 
curious to understand how it works.


with one day (D/Objective-C).

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Jan 14 2012



  parent  Jacob Carlborg <doob me.com>  writes:


On 2012-01-15 06:00, Michel Fortin wrote:

 On 2012-01-15 03:06:22 +0000, Jonathan M Davis <jmdavisProg gmx.com> said:


 It seems that the problem is that while Walter can be saved effort by
 having someone else do that kind of work, it doesn't necessarily save
 him all that much effort, since he still must ultimately take the time
 to fully understand what's being changed and what the implications are
 before he merges it in.


 It still saves the effort of coming up with a solution, implementing
 that solution, updating the test suite, etc. I think this is
 significant. But you're right, it's more effort to review than most
 other pull requests, and it might not be something he likes to do.




 makes sense if it takes longer for it to be sorted out. Still, given

 have been handled much sooner than this. It's getting very close to
 being a year old.


 A year old and outdated: it won't merge cleanly anymore (despite the
 update I made this summer). I should probably keep maintaining it, but
 as it is now I don't think I'll bother until Walter is ready to look at it.

 But I'm a little surprised he hasn't even looked at it yet given this is
 a problem he tried to fix himself before. In his place, I'd be very
 curious to understand how it works.


 with one day (D/Objective-C).


Oh, yeah. But I'm looking forward to it.

-- 
/Jacob Carlborg



 Jan 15 2012



prev sibling  parent reply "Daniel Murphy" <yebblies nospamgmail.com>  writes:


"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:jetbld$23qt$1 digitalmars.com...

 Looks good in theory, but in practice this approach hasn't worked very 
 well for pull request number 3.


I may have mentioned this before, but there are a couple of things that make 
me think pull 3 shouldn't be merged as is. (Even if it was made merge-ready)

1. The patch tries (and in some places, doesn't try) to match implicit 
conversion and template deduction behaviour for pointers and arrays which 
are badly defined and in some cases don't make any sense.  I'd prefer to get 
those sorted out before adding a third referencey TypeNext to dmd.

2. The addition of head() means a huge amount of changes that aren't really 
necessary.  Most of the changes are insertions of calls to this function, 
which introduces quite a bit of mess and potential for easy bugs if someone 
forgets to use it.

I don't know if Walter has a similar list of reservations he's keeping to 
himself, or just hasn't gotten around to it yet.  Hopefully I'll find some 
time to work on these issues (or somebody else will).



 Jan 15 2012



 next sibling parent reply Robert Clipsham <robert octarineparrot.com>  writes:


On 15/01/2012 14:26, Daniel Murphy wrote:

 "Michel Fortin"<michel.fortin michelf.com>  wrote in message
 news:jetbld$23qt$1 digitalmars.com...

 Looks good in theory, but in practice this approach hasn't worked very
 well for pull request number 3.


 I may have mentioned this before, but there are a couple of things that make
 me think pull 3 shouldn't be merged as is. (Even if it was made merge-ready)

 1. The patch tries (and in some places, doesn't try) to match implicit
 conversion and template deduction behaviour for pointers and arrays which
 are badly defined and in some cases don't make any sense.  I'd prefer to get
 those sorted out before adding a third referencey TypeNext to dmd.

 2. The addition of head() means a huge amount of changes that aren't really
 necessary.  Most of the changes are insertions of calls to this function,
 which introduces quite a bit of mess and potential for easy bugs if someone
 forgets to use it.

 I don't know if Walter has a similar list of reservations he's keeping to
 himself, or just hasn't gotten around to it yet.  Hopefully I'll find some
 time to work on these issues (or somebody else will).


Might be worth adding this as a comment on the pull request!

-- 
Robert
http://octarineparrot.com/



 Jan 15 2012



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 1/15/2012 6:47 AM, Robert Clipsham wrote:

 Might be worth adding this as a comment on the pull request!



Yes, please do.



 Jan 15 2012



prev sibling  parent  Michel Fortin <michel.fortin michelf.com>  writes:


On 2012-01-15 14:26:45 +0000, "Daniel Murphy" <yebblies nospamgmail.com> said:


 I may have mentioned this before, but there are a couple of things that make
 me think pull 3 shouldn't be merged as is. (Even if it was made merge-ready)
 
 1. The patch tries (and in some places, doesn't try) to match implicit
 conversion and template deduction behaviour for pointers and arrays which
 are badly defined and in some cases don't make any sense.  I'd prefer to get
 those sorted out before adding a third referencey TypeNext to dmd.
 
 2. The addition of head() means a huge amount of changes that aren't really
 necessary.  Most of the changes are insertions of calls to this function,
 which introduces quite a bit of mess and potential for easy bugs if someone
 forgets to use it.
 
 I don't know if Walter has a similar list of reservations he's keeping to
 himself, or just hasn't gotten around to it yet.  Hopefully I'll find some
 time to work on these issues (or somebody else will).


Great points. You should post them in the pull request, which is the 
right place to discuss them (especially the second one, since you 
already sort-of commented on the first issue by annotating the test 
cases).

Also, if Walter has similar reservations, I hope he'd write them in a 
pull request comment. Negative feedback is much better than no feedback 
at all, because with no feedback there is nothing anyone can do to 
improve things.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/



 Jan 15 2012



prev sibling  parent  Mehrdad <wfunction hotmail.com>  writes:


On 1/12/2012 9:54 AM, Walter Bright wrote:

 On 1/11/2012 11:16 PM, Jacob Carlborg wrote:

 That's the whole point. It's not clear what the actual specification 
 IS. Is it
 DMD, dlang.org or TDPL?


 It's the "Language Reference" section on dlang.org.


There's a reason this page isn't titled /"C++ Language Specification"/: 
http://msdn.microsoft.com/en-us/library/3bstk3k5.aspx



 Jan 12 2012



prev sibling  parent reply deadalnix <deadalnix gmail.com>  writes:


Le 11/01/2012 21:34, Walter Bright a écrit :

 On 1/11/2012 12:29 PM, Zachary Lund wrote:

 D1 or D2 both don't have a very accurate definition. C and C++ has
 several
 hundred pages of specifications and while I'm hopefully not expecting
 that, I do
 want some certainty on what is *supposed* to happen.

 There is also no versioning. D2 is definitely different from D1 in the
 case that
 it's not backwards compatible, but version for the actual example
 implementation
 isn't enough, especially when that implementation doesn't always do
 what it's
 supposed to do.


 Please file bug reports for any errors/omissions in the specification on
 bugzilla.


Sorry to disapoint, but I don't think a newcomer can reasonably fill 
this type of bugs.

Usually, a newcomer isn't even sure if the bug comes from his/her code 
or from the compiler. How can you expect them to fill a bug about the 
spec ???



 Jan 18 2012



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/18/2012 12:10 PM, deadalnix wrote:

 Usually, a newcomer isn't even sure if the bug comes from his/her code or from
 the compiler. How can you expect them to fill a bug about the spec ???


That's what these forums are for - to ask.



 Jan 18 2012



 next sibling parent reply "Zachary Lund" <admin computerquip.com>  writes:


On Wednesday, 18 January 2012 at 20:41:14 UTC, Walter Bright 
wrote:

 On 1/18/2012 12:10 PM, deadalnix wrote:

 Usually, a newcomer isn't even sure if the bug comes from 
 his/her code or from
 the compiler. How can you expect them to fill a bug about the 
 spec ???


 That's what these forums are for - to ask.


You don't think that lowers the probability of someone wanting to 
use D?



 Jan 18 2012



  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 1/18/2012 1:12 PM, Zachary Lund wrote:

 On Wednesday, 18 January 2012 at 20:41:14 UTC, Walter Bright wrote:

 On 1/18/2012 12:10 PM, deadalnix wrote:

 Usually, a newcomer isn't even sure if the bug comes from his/her code or from
 the compiler. How can you expect them to fill a bug about the spec ???


 That's what these forums are for - to ask.


 You don't think that lowers the probability of someone wanting to use D?


What do you suggest?



 Jan 18 2012



  parent  Peter Alexander <peter.alexander.au gmail.com>  writes:


On 18/01/12 9:55 PM, Walter Bright wrote:

 On 1/18/2012 1:12 PM, Zachary Lund wrote:

 On Wednesday, 18 January 2012 at 20:41:14 UTC, Walter Bright wrote:

 On 1/18/2012 12:10 PM, deadalnix wrote:

 Usually, a newcomer isn't even sure if the bug comes from his/her
 code or from
 the compiler. How can you expect them to fill a bug about the spec ???


 That's what these forums are for - to ask.


 You don't think that lowers the probability of someone wanting to use D?


 What do you suggest?


Well, it's kind of too late now, but ideally the implementation and 
documentation should have evolved together, so that the situation we are 
in now wouldn't have happened.

What happened instead was an incomplete spec popped up with no 
implementation then the implementation tried to match it, whilst 
changing parts of it (without updating the documentation) along the way. 
We also now have the TDPL, which in parts disagrees with both the 
implementation and the original spec.

What we can do now:

1. Hope that people are knowledgeable and willing enough to update the 
documentation to match the current language state.

2. Ensure that any submitted pull requests into DMD that change language 
features are also documented in the language spec at the same time. 
Recent example: array covariance changed, but the language spec didn't. 
I'm working on a pull request to fix the spec now.

We have to be much more diligent about keeping the spec up to date.



 Jan 18 2012



prev sibling  parent reply deadalnix <deadalnix gmail.com>  writes:


Le 18/01/2012 21:41, Walter Bright a écrit :

 On 1/18/2012 12:10 PM, deadalnix wrote:

 Usually, a newcomer isn't even sure if the bug comes from his/her code
 or from
 the compiler. How can you expect them to fill a bug about the spec ???


 That's what these forums are for - to ask.


Seriously, that isn't a solution at all. Just imagine yourself as a 
newcomer.

You have this idea of program, and think this is a good opportunity to 
start using a language that seems promising : D.

You write some code and they face an error. As you are new to the 
language, unless you are crazy, you'll asume that the mistake comes from 
you and not from the compiler (this is an usual experience in other 
languages : I almost never encounter compiler bugs).

So you begin to dig more and more in every documentation you can find 
and try several alternatives. You also search on the web for article 
about a similar problem and face a desert. After 1, 2 or 3 hours you 
decide to post on this newgroup. At this point, your program as made no 
significant progress.

After several hours again (probaly one or two days later in fact) you 
discover in the newgroups that you faced a compiler/phobos bug and that 
you have to use a dirty hack or another way to do your stuff. At this 
point, you program has made no progress, and worse, you know you have to 
recode a part of it.


or whatever.

We need a more reliable technology for the compiler and the standard 
lib. I would say that even if it require to break some existing code 
(like to solve the toString issue and make it const compilant). This 
have to be annonced in advance, but shouldn't stop us. The code base 
will only grow (and if it stop to grow, we can consider the language as 
actually dead). So the earlier we fix thoses, the better.

Let me explain an exprience of mine. I was studying std.concurrency when 
I figured out that it can be greatly improved (using something close to 
a disruptor for message passing). I wanted to propose a patch for that, 
but I figured out that shared was actually broken and that the compiler 
is unable to ensure what is specified in the doc. This is a deal breaker 
for disruptor. So no disruptor in std.concurency, poorer performance and 
still problems with shared.

It's time to secure the basics. Ensure a good experience for newcomers. 
thoses people will be embassador of D tomorow.



 Jan 19 2012



  parent reply Manu <turkeyman gmail.com>  writes:


On 19 January 2012 22:52, deadalnix <deadalnix gmail.com> wrote:


 You write some code and they face an error. As you are new to the
 language, unless you are crazy, you'll asume that the mistake comes from
 you and not from the compiler (this is an usual experience in other
 languages : I almost never encounter compiler bugs).

 So you begin to dig more and more in every documentation you can find and
 try several alternatives. You also search on the web for article about a
 similar problem and face a desert. After 1, 2 or 3 hours you decide to post
 on this newgroup. At this point, your program as made no significant
 progress.

 After several hours again (probaly one or two days later in fact) you
 discover in the newgroups that you faced a compiler/phobos bug and that you
 have to use a dirty hack or another way to do your stuff. At this point,
 you program has made no progress, and worse, you know you have to recode a
 part of it.


 or whatever.

 We need a more reliable technology for the compiler and the standard lib.
 I would say that even if it require to break some existing code (like to
 solve the toString issue and make it const compilant). This have to be
 annonced in advance, but shouldn't stop us. The code base will only grow
 (and if it stop to grow, we can consider the language as actually dead). So
 the earlier we fix thoses, the better.


As a new comer, I really felt this. I intended to write a program in 1
evening, it was about 100 lines. It took me over a week, thanks to the
reasons you listed and more.
I don't know why I didn't give up (probably because of how much I hate
C++), but the experience for a new comer is not good.

With regard to breaking changes, I know people are radically against it,
but I wonder, how many major/commercial programs are there written in D?
How many people are financially invested?
How many are small or hobby programs by contrast? and... as an early
adapter to D, do you accept that you might have to make some minor
modifications to your existing program due to a spec change?
If I had an active project, and I had more experience with D (such that I
wasn't a frustrated newcomer), I would not mind mending my code due to
breaking changes one little bit where it was clear that the fix was for
good reason.

I personally think getting the experience right, for new comers, and in
general, far outweighs asking some experienced people with mature projects
to make some small changes occasionally. I am quite sad that a lot of the
broken things in there now are un-fixable.



 Jan 20 2012



  parent reply bearophile <bearophileHUGS lycos.com>  writes:


Manu:


 I am quite sad that a lot of the
 broken things in there now are un-fixable.


If you want to write a short list of such broken things... :-)

Bye,
bearophile



 Jan 20 2012



 next sibling parent  Manu <turkeyman gmail.com>  writes:


On 20 January 2012 14:47, bearophile <bearophileHUGS lycos.com> wrote:


 Manu:


 I am quite sad that a lot of the
 broken things in there now are un-fixable.


 If you want to write a short list of such broken things... :-)

 Bye,
 bearophile


Renaming receiveOnly() to receive() is a trivial example. I have
encountered others which I can't recall off the top of my head of a
similarly trivial nature that would really enhance the intuitive
application of libraries.
I wonder if libraries become 'std' too soon? They should go through some
incubation process for a year or something, or some minimum number of
successful usages within real applications before they become 'std'...?

virtual-by-default is my single biggest gripe in the entire language, which
has perfectly workable, I'd argue better&more well defined solutions, but
would be a breaking change, and will never be considered. (No, I'm not
trying to open this topic again)



 Jan 20 2012



prev sibling  parent  deadalnix <deadalnix gmail.com>  writes:


Le 20/01/2012 13:47, bearophile a écrit :

 Manu:


 I am quite sad that a lot of the
 broken things in there now are un-fixable.


 If you want to write a short list of such broken things... :-)

 Bye,
 bearophile


toString to begin with. This isn't const compliant.

Just like a big part of the standard lib.

.sort on array is broken.

I have a recent piece of code implementing a radix sort, it has 3 or 4 
workaround compiler bugs (that are in the buglist).

Interfacing with C in 64bits can silently screw up your memory when you 
manipulate struct.

shared isn't working as specified, making writing lock free concurent 
code almost impossible in practice (it is not like even smartphone have 
multi core processor nowadays . . .).

And so on . . .

And this is a 2 minutes answer. I can list more and more without 
thinking too much. All of them are known issue, filled in the bugtracker 
or discussed on github.



 Jan 20 2012