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