www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's the current state of D?

reply "Ameer Armaly" <ameer.armaly furman.edu> writes:
Hi all.
When I last used D a couple years ago, 2.0 was the experimental branch and 
1.0 was stable. Now that I have a little time on my hands I'm wondering: 
what is the current landscape? Is 2.0 approaching any sort of stability? Are 
there still two competing runtime libraries or have they been merged? 
Basically I want to know if it's worth using 2.0 for anything of importance 
or is it still in flux?
Thanks,

Ameer
May 07 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Ameer,


 Hi all.
 When I last used D a couple years ago, 2.0 was the experimental branch and
 1.0 was stable.


still true


 Now that I have a little time on my hands I'm wondering:
 what is the current landscape? Is 2.0 approaching any sort of stability?


the const system is stable and now it's starting to play with threading


 Are
 there still two competing runtime libraries or have they been merged?


No not for 1.0 (and they never will be) but /when/ Tango gets ported to 2.0 
they will coexist.


 Basically I want to know if it's worth using 2.0 for anything of
 importance
 or is it still in flux?


Don't use it for bet-the-bank code. Use it for, fun-n-games code. Between 
them, it's up to you.



 Thanks,
 Ameer
May 07 2009
parent reply Steve Teale <steve.teale britseyeview.com> writes:
BCS Wrote:


 Hello Ameer,
 

 Hi all.
 When I last used D a couple years ago, 2.0 was the experimental branch and
 1.0 was stable.


 
 still true
 

 Now that I have a little time on my hands I'm wondering:
 what is the current landscape? Is 2.0 approaching any sort of stability?


 
 the const system is stable and now it's starting to play with threading
 

 Are
 there still two competing runtime libraries or have they been merged?


 
 No not for 1.0 (and they never will be) but /when/ Tango gets ported to 2.0 
 they will coexist.
 

 Basically I want to know if it's worth using 2.0 for anything of
 importance
 or is it still in flux?


 
 Don't use it for bet-the-bank code. Use it for, fun-n-games code. Between 
 them, it's up to you.
 
 

 Thanks,
 Ameer
 


 


This is the sort of answer that will kill D. The guy comes back after 2 years,
asks a straight question, and get's told "business as usual, we're still
arguing among ourselves about what it should be".

Maybe Tiobe is right! Lots of others may not even bother to ask. They just
visit the newsgroup, read a page of it, and conclude "same old, same old", and
go away.

D should be D, not maybe 1.043, or let's wait a while and see what happens with
D2. Potential real users hate uncertainty. If they are going to commit, then D
must do so too.
May 08 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steve Teale wrote:

 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".
 
 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.
 
 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.


What bothers me about this sentiment is that every other mainstream 
language undergoes revision, sometimes major ones, but that never seems 
to be an excuse for people to not use it.

For example, C++ is quite in flux with C++0x.

The only languages that are not undergoing revision are dead ones.
May 08 2009
next sibling parent reply grauzone <none example.net> writes:
Walter Bright wrote:

 Steve Teale wrote:

 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".

 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.

 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.


 
 What bothers me about this sentiment is that every other mainstream 
 language undergoes revision, sometimes major ones, but that never seems 
 to be an excuse for people to not use it.
 
 For example, C++ is quite in flux with C++0x.
 
 The only languages that are not undergoing revision are dead ones.


But C++ programs still compile and run correctly with C++0x compilers. I 
bet none of the projects on dsource are even compilable with dmd2 (even 
if they were written for D2.0). And _many_ projects probably need minor 
fixes, before they compile with the latest dmd1 compiler.
May 08 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:

 But C++ programs still compile and run correctly with C++0x compilers.


True enough, but that wasn't true for C++98, or C89. Nobody refused to 
use C or C++ because of that.


 I bet none of the projects on dsource are even compilable with dmd2 (even 
 if they were written for D2.0).


Take any C++ project from 15 years ago and I bet it won't compile today, 
either.


 And _many_ projects probably need minor 
 fixes, before they compile with the latest dmd1 compiler.


Nearly all of those are due to inadvertent reliance on bugs in D1. You 
see this quite a bit in the C++ world. Every time g++ gets updated, I 
have to tweak something in my sources.

Every binary release of dmd is available for download. If you require an 
unchanging compiler, it's trivial to operate that way. dmd isn't going 
to auto-update itself and break your compiles.
May 08 2009
next sibling parent reply grauzone <none example.net> writes:
 Nearly all of those are due to inadvertent reliance on bugs in D1. You 
 see this quite a bit in the C++ world. Every time g++ gets updated, I 
 have to tweak something in my sources.


In the case of D, the problem is that sometimes you don't really know if 
it's a bug or a feature.
May 08 2009
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
grauzone wrote:


 Nearly all of those are due to inadvertent reliance on bugs in D1. You  
 see this quite a bit in the C++ world. Every time g++ gets updated, I  
 have to tweak something in my sources.


 In the case of D, the problem is that sometimes you don't really know if  
 it's a bug or a feature.


So you file a bug, and if nothing else, the spec should be clarified.

--
  Simen
May 08 2009
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 grauzone wrote:


 And _many_ projects probably need minor
 fixes, before they compile with the latest dmd1 compiler.


 Nearly all of those are due to inadvertent reliance on bugs in D1. You
 see this quite a bit in the C++ world. Every time g++ gets updated, I
 have to tweak something in my sources.


And this is often unavoidable.  Look at all the workarounds in Boost
code for various versions of the MS compiler, for example (particularly
VC6 vs. later versions).  I can't think of how much code I've written in
C++ that used preprocessor switches to vary implementation between
compiler versions, even though they all claimed to support C++98.
Fortunately, a little experience with the quirks of each compiler makes
transitioning code fairly mechanical in most cases.
May 08 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:


 grauzone wrote:

 But C++ programs still compile and run correctly with C++0x compilers.


 
 True enough, but that wasn't true for C++98, or C89. Nobody refused to
 use C or C++ because of that.
 

 I bet none of the projects on dsource are even compilable with dmd2 (even
 if they were written for D2.0).


 
 Take any C++ project from 15 years ago and I bet it won't compile today,
 either.
 

 And _many_ projects probably need minor
 fixes, before they compile with the latest dmd1 compiler.


 
 Nearly all of those are due to inadvertent reliance on bugs in D1. You
 see this quite a bit in the C++ world. Every time g++ gets updated, I
 have to tweak something in my sources.
 
 Every binary release of dmd is available for download. If you require an
 unchanging compiler, it's trivial to operate that way. dmd isn't going
 to auto-update itself and break your compiles.


That's a really good thing imho. I remember when I got the Civilization 4 
C++ SDK, it would only compile with the MS 2003 compiler. Which at the time 
was outdated and unavailable for download in a legal way. It was also 130K 
LoC and beyond my ability to fix of course, very frustrating.
May 08 2009
prev sibling parent reply Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:

 grauzone wrote:

 But C++ programs still compile and run correctly with C++0x compilers.


 
 True enough, but that wasn't true for C++98, or C89. Nobody refused to 
 use C or C++ because of that.


At the time, C[++] users didn't feel like they exactly had a choice, did 
they?


 I bet none of the projects on dsource are even compilable with dmd2 
 (even if they were written for D2.0).


 
 Take any C++ project from 15 years ago and I bet it won't compile today, 
 either.
 

 And _many_ projects probably need minor fixes, before they compile 
 with the latest dmd1 compiler.


 
 Nearly all of those are due to inadvertent reliance on bugs in D1. You 
 see this quite a bit in the C++ world. Every time g++ gets updated, I 
 have to tweak something in my sources.
 
 Every binary release of dmd is available for download. If you require an 
 unchanging compiler, it's trivial to operate that way. dmd isn't going 
 to auto-update itself and break your compiles.


Now, that is something the random user doesn't expect. Right? And his 
boss definitely not.

As part of our Public Front (as in "keeping up appearances", the 
TV-show), shouldn't we make it a point not to lose public awareness of 
such good things? (Meaning, it's not enough to have it mentioned in an 
obscure niche of a corner of a second-level reference to documentation.)

__________________________________________________________

** The following is way off-topic, so don't read it **
And it's written on a Saturday night, before the pub.

Yesterday, I got into a discussion about the merits of Picasso, Dali, 
and a third [local] painter. One of us had read the book written by 
Picasso's last wife. Picasso lived a life like any sane man would [or 
should] dream of: Wife, lover, and random paintees. Heads of state and 
celebrities bowing to their knees before him, etc. One day his wife and 
his mistress together approached him, stating that this can't go on, 
it's intolerable. You have to choose or do something!!!

Picasso looked at them, took a sip of his wine, a slow puff of his 
cigar, and then remarked "I'm fine." To their astounded faces, he 
continued "If the two of you have a problem, then go sort it out between 
yourselves."

No wonder he had it in hand. And, IMHO, with the crappy paintings he did 
[at the top of his time], nobody modest, honest and humble would have 
got a living off of that stuff.

________________________________________________________

What's the relevance of this story to us??  Well, it is all about how 
you handle things like the public opinion and the attitudes of folks 
around you. Even if D were an amateur language with bribed articles on 
CUJ and DDJ, with the right attitude, you could get away with having the 
world believe this is the Holy Grail of languages.

So, let's not do the opposite, please.

Things we have (like every binary release [and I assume, an implicit 
promise of keeping it that way] downloadable forever), the source code 
to /both/ the front end and the back end distributed every time -- for 
both reading example usage, learning by looking at unittests, and for a 
deep understanding of both the compiler and the library code in detail, 
... it's stuff like this we don't advertise enough. (( Of course, not to 
mention actual language highlights that are really smashing! But they're 
outside of this post.))

And the parts of D that are unique, we don't see them splashed all over 
the net either. It can and should be possible without the PR budget of 
Oracle, too.

Anybody over 40 knows that Pascal was an excellent language for 
programmming classes. (Yes, it was even created for that purpose, 
originally.) But then, nobody at all knows that out of all "known" 
languages, D is (by FAR!!) the one a university /should/ choose as the 
introductory language. Hah, and even fewer can imagine that D is the 
language they should use in advanced classes! And, thus, virtually 
nobody knows that being blessed with having originally learned a 
language that has the strength to carry you all the way from intro to 
PhD, makes you seriously privileged. And with a robust and solid mother 
tongue like this, forages into C++, Java, Ruby, Haskell, Scheme, ASM, 
and the like, will seem like a breeze, and don't destroy or *undo* /the 
very foundations of/ your world as a programmer.
May 09 2009
parent reply Steve Teale <steve.teale britseyeview.com> writes:
Georg Wrede Wrote:


 Things we have (like every binary release [and I assume, an implicit 
 promise of keeping it that way] downloadable forever), the source code 
 to /both/ the front end and the back end distributed every time -- for 
 both reading example usage, learning by looking at unittests, and for a 
 deep understanding of both the compiler and the library code in detail, 
 ... it's stuff like this we don't advertise enough. (( Of course, not to 
 mention actual language highlights that are really smashing! But they're 
 outside of this post.))
 
 And the parts of D that are unique, we don't see them splashed all over 
 the net either. It can and should be possible without the PR budget of 
 Oracle, too.
 
 Anybody over 40 knows that Pascal was an excellent language for 
 programmming classes. (Yes, it was even created for that purpose, 
 originally.) But then, nobody at all knows that out of all "known" 
 languages, D is (by FAR!!) the one a university /should/ choose as the 
 introductory language. Hah, and even fewer can imagine that D is the 
 language they should use in advanced classes! And, thus, virtually 
 nobody knows that being blessed with having originally learned a 
 language that has the strength to carry you all the way from intro to 
 PhD, makes you seriously privileged. And with a robust and solid mother 
 tongue like this, forages into C++, Java, Ruby, Haskell, Scheme, ASM, 
 and the like, will seem like a breeze, and don't destroy or *undo* /the 
 very foundations of/ your world as a programmer.


Yes! I may continue to bitch, but you are so right. D is extraordinarily cool!
Poa sana as I could say in the domain of my current residency.

Somehow we have to advance the announcements and learn newsgroups so that they
are primary, and change perceptions such that the "suggestions for the next
version of D" newsgroup - currently the main newsgroup - is a specialist affair
that most readers think they can safely ignore.

Walters logic is unchallengeable, but most of life isn't about logic, it's
about perceptions.

D is great. How do we spread that particular perception?
May 09 2009
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Steve Teale wrote:

 D is great. How do we spread that particular perception?


Use it.  Tell people you're using it.  Produce tools, libraries, applications,
whatever.. that are interesting enough that people want to know more.

Later,
Brad
May 09 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Brad Roberts wrote:

 Steve Teale wrote:

 D is great. How do we spread that particular perception?


 
 Use it.  Tell people you're using it.  Produce tools, libraries, applications,
 whatever.. that are interesting enough that people want to know more.


Also write about it. Of all programming languages of comparable breadth, 
D is probably the one that made it with the least (amazingly little) 
written material.

Andrei
May 09 2009
prev sibling next sibling parent Daniel Toffetti <dtoffe yahoo.com.ar> writes:
Brad Roberts Wrote:


 Steve Teale wrote:

 D is great. How do we spread that particular perception?


 
 Use it.  Tell people you're using it.  Produce tools, libraries, applications,
 whatever.. that are interesting enough that people want to know more.
 
 Later,
 Brad


    I second this. A great language and compiler is often not enough to get a
lot of people interested. Since a parent post mentioned Pascal, look at the
Lazarus installer you can download for Windows for example.
    I've already seen a couple of posts in the Netbeans users forum asking for
a D plugin, and there is one already for Eclipse.
    People _is_ interested in being more productive and enjoying its work. But
developers nowadays take some things for granted, besides the compiler.

    But there are simpler things that could help a lot, IMHO. For example,
recent news in the front page, updated regularly. It doesn't need to be big
anouncements, minor revisions or community news are ok, just enough to let
people know this is moving.
    A small roadmap of completed features, showing reached milestones and
future milestones. You don't need to show expected release date for future
milestones, but it's nice to show approximate date of completion of already
reached milestones. This also helps to give a perception of progress.
    This two should be in the front page or, if not possible, at least in a
clearly visible link near the top of front page.

HTH, cheers,

Daniel
May 09 2009
prev sibling parent Daniel Toffetti <dtoffe yahoo.com.ar> writes:
Brad Roberts Wrote:


 Steve Teale wrote:

 D is great. How do we spread that particular perception?


 
 Use it.  Tell people you're using it.  Produce tools, libraries, applications,
 whatever.. that are interesting enough that people want to know more.
 
 Later,
 Brad


    I second this. A great language and compiler is often not enough to get a
lot of people interested. Since a parent post mentioned Pascal, look at the
Lazarus installer you can download for Windows for example.
    I've already seen a couple of posts in the Netbeans users forum asking for
a D plugin, and there is one already for Eclipse.
    People _is_ interested in being more productive and enjoying its work. But
developers nowadays take some things for granted, besides the compiler.

    But there are simpler things that could help a lot, IMHO. For example,
recent news in the front page, updated regularly. It doesn't need to be big
anouncements, minor revisions or community news are ok, just enough to let
people know this is moving.
    A small roadmap of completed features, showing reached milestones and
future milestones. You don't need to show expected release date for future
milestones, but it's nice to show approximate date of completion of already
reached milestones. This also helps to give a perception of progress.
    This two should be in the front page or, if not possible, at least in a
clearly visible link near the top of front page.

HTH, cheers,

Daniel
May 09 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Steve Teale wrote:

 D is great. How do we spread that particular perception?


All these are free and effective:

Write articles/blogs about your experiences using D.

Submit patches for better D support for gnu tools like gdb.

Give a presentation on D at your local programmers' club meeting.

Submit presentation abstracts on D to conferences.

Read programming articles and if they don't mention D, but should, email 
the author and point it out.

Make relevant comments about D on programming threads on Reddit, 
Slashdot, Gamedev.net, stackoverflow, ycombinator, etc.

Promote open source D applications that you or others have written.

Email tool vendors and ask for D support.

Email web sites that have categories for programming languages that 
don't include D, and ask for a D category.

Improve Wikipedia pages that mention D. Add mention of D to Wikipedia 
pages that should mention it.
May 09 2009
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Steve Teale wrote:

 Georg Wrede Wrote:
 

 Things we have (like every binary release [and I assume, an implicit 
 promise of keeping it that way] downloadable forever), the source code 
 to /both/ the front end and the back end distributed every time -- for 
 both reading example usage, learning by looking at unittests, and for a 
 deep understanding of both the compiler and the library code in detail, 
 ... it's stuff like this we don't advertise enough. (( Of course, not to 
 mention actual language highlights that are really smashing! But they're 
 outside of this post.))

 And the parts of D that are unique, we don't see them splashed all over 
 the net either. It can and should be possible without the PR budget of 
 Oracle, too.

 Anybody over 40 knows that Pascal was an excellent language for 
 programmming classes. (Yes, it was even created for that purpose, 
 originally.) But then, nobody at all knows that out of all "known" 
 languages, D is (by FAR!!) the one a university /should/ choose as the 
 introductory language. Hah, and even fewer can imagine that D is the 
 language they should use in advanced classes! And, thus, virtually 
 nobody knows that being blessed with having originally learned a 
 language that has the strength to carry you all the way from intro to 
 PhD, makes you seriously privileged. And with a robust and solid mother 
 tongue like this, forages into C++, Java, Ruby, Haskell, Scheme, ASM, 
 and the like, will seem like a breeze, and don't destroy or *undo* /the 
 very foundations of/ your world as a programmer.


 
 Yes! I may continue to bitch, but you are so right. D is extraordinarily cool!
Poa sana as I could say in the domain of my current residency.
 
 Somehow we have to advance the announcements and learn newsgroups so that they
are primary, and change perceptions such that the "suggestions for the next
version of D" newsgroup - currently the main newsgroup - is a specialist affair
that most readers think they can safely ignore.


I agree. When someone clicks the "D Forum" link on the front page, they 
should get to the D.learn newsgroup. Also, said link should be more 
prominent, not tucked away at the bottom of the menu.

-Lars
May 11 2009
prev sibling next sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
Walter Bright Wrote:


 Steve Teale wrote:

 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".
 
 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.
 
 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.


 
 What bothers me about this sentiment is that every other mainstream 
 language undergoes revision, sometimes major ones, but that never seems 
 to be an excuse for people to not use it.
 
 For example, C++ is quite in flux with C++0x.
 
 The only languages that are not undergoing revision are dead ones.


Yes Walter, but C++ went through a tedious standardization process - itself a
long argument. So there was some basis for people to think that it had 'got
there'.

But to come back after 2 years and find the same stuff still going on is
depressing - been there done that. OK, it didn't put me off, I'm still in
there, but it bothers me. I'd be dishonest if I said otherwise.

I am not criticizing you. I think you are doing a great job under the pressure
of a slew of suggestions. But maybe a line in the sand at some point?

OK so for those who crave stability there is D1.x, but when all the focus
appears to be on D2, what level of confidence is afforded to D1 users. Can a
project Manager cross his heart and say that D1 will still be alive and well in
five years time?
May 08 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steve Teale wrote:

 I am not criticizing you. I think you are doing a great job under the
 pressure of a slew of suggestions. But maybe a line in the sand at
 some point?


But there *is* a line in the sand - D1.


 OK so for those who crave stability there is D1.x, but when all the
 focus appears to be on D2, what level of confidence is afforded to D1
 users. Can a project Manager cross his heart and say that D1 will
 still be alive and well in five years time?


This just makes me very frustrated. Every fix going into D2 that also 
applies to D1 has been folded into D1. There are even some fixes that 
only apply to D1 that only go into D1. These average about 20 per month. 
D1 even got the FreeBSD port before D2. What other language gets that 
kind of support?
May 08 2009
next sibling parent grauzone <none example.net> writes:
Nobody is saying that you don't put enough effort into making it stable 
or so. It's just sad reality, that the unstable state of the D toolchain 
drives away users and potential users.

Anyway, having a stable version of D and making the full compiler source 
available were great steps into the right direction.
May 08 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Steve Teale wrote:

 I am not criticizing you. I think you are doing a great job under the
 pressure of a slew of suggestions. But maybe a line in the sand at
 some point?


 But there *is* a line in the sand - D1.

 OK so for those who crave stability there is D1.x, but when all the
 focus appears to be on D2, what level of confidence is afforded to D1
 users. Can a project Manager cross his heart and say that D1 will
 still be alive and well in five years time?


 This just makes me very frustrated. Every fix going into D2 that also
 applies to D1 has been folded into D1. There are even some fixes that
 only apply to D1 that only go into D1. These average about 20 per month.
 D1 even got the FreeBSD port before D2. What other language gets that
 kind of support?


This sometimes makes me wonder if D1 and D2 are going to evolve into separate
but
related languages with separate niches at some point, something like Scheme vs.
Common Lisp or C vs. C++.  D1, with its simplicity and the availability of
Tango,
seems well suited to be a Java++ kind of language.  D2, with its extremely
powerful metaprogramming, greater complexity and the availability of Phobos2,
seems more like a (C++0x)++.
May 08 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:

 This sometimes makes me wonder if D1 and D2 are going to evolve into separate
but
 related languages with separate niches at some point, something like Scheme vs.
 Common Lisp or C vs. C++.  D1, with its simplicity and the availability of
Tango,
 seems well suited to be a Java++ kind of language.  D2, with its extremely
 powerful metaprogramming, greater complexity and the availability of Phobos2,
 seems more like a (C++0x)++.


D1, by definition, isn't going to evolve any more than C++98 is going to 
evolve.
May 08 2009
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Fri, May 8, 2009 at 8:56 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Steve Teale wrote:

 I am not criticizing you. I think you are doing a great job under the
 pressure of a slew of suggestions. But maybe a line in the sand at
 some point?


 But there *is* a line in the sand - D1.


 OK so for those who crave stability there is D1.x, but when all the
 focus appears to be on D2, what level of confidence is afforded to D1
 users. Can a project Manager cross his heart and say that D1 will
 still be alive and well in five years time?


 This just makes me very frustrated. Every fix going into D2 that also
 applies to D1 has been folded into D1. There are even some fixes that only
 apply to D1 that only go into D1. These average about 20 per month. D1 even
 got the FreeBSD port before D2. What other language gets that kind of
 support?


A lot of good points have been brought forward in this thread. To me
the big problem with D1 is that we *still* don't have a conforming
(what does that even mean with D) compiler.

Yes I'm thinking forward reference problems and such. Sure, these are
hard problems to fix in the compiler, at least at this point. It's
something that should have been fixed immediately when the first bug
report came in.

From my work on LDC I've seen a lot of the DMD frontend source code,
its glitches, but of course also those "wow, that's neat" moments.
However, one thing is very certain, it has some horrible problems with
order-of-things issues, which the spec says should not matter.

I'm talking about forward references, differing semantic trees
depending on the order of declarations, imports etc. even the order in
which modules are passed on the command line can affect the resulting
semantic trees (yes I mean AST, but DMD has no distinction, it
rewrites the AST happily until it thinks the result is sane).

The main feeling I've come to settle on during the soon two years I've
spent with LDC, is: we need a new frontend! D1 and D2 both have these
problems, and they're not going away by themselves.

-Tomas
May 09 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Tomas Lindquist Olsen escribió:

 On Fri, May 8, 2009 at 8:56 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Steve Teale wrote:

 I am not criticizing you. I think you are doing a great job under the
 pressure of a slew of suggestions. But maybe a line in the sand at
 some point?


 But there *is* a line in the sand - D1.


 OK so for those who crave stability there is D1.x, but when all the
 focus appears to be on D2, what level of confidence is afforded to D1
 users. Can a project Manager cross his heart and say that D1 will
 still be alive and well in five years time?


 This just makes me very frustrated. Every fix going into D2 that also
 applies to D1 has been folded into D1. There are even some fixes that only
 apply to D1 that only go into D1. These average about 20 per month. D1 even
 got the FreeBSD port before D2. What other language gets that kind of
 support?


 
 A lot of good points have been brought forward in this thread. To me
 the big problem with D1 is that we *still* don't have a conforming
 (what does that even mean with D) compiler.
 
 Yes I'm thinking forward reference problems and such. Sure, these are
 hard problems to fix in the compiler, at least at this point. It's
 something that should have been fixed immediately when the first bug
 report came in.
 
 From my work on LDC I've seen a lot of the DMD frontend source code,
 its glitches, but of course also those "wow, that's neat" moments.
 However, one thing is very certain, it has some horrible problems with
 order-of-things issues, which the spec says should not matter.
 
 I'm talking about forward references, differing semantic trees
 depending on the order of declarations, imports etc. even the order in
 which modules are passed on the command line can affect the resulting
 semantic trees (yes I mean AST, but DMD has no distinction, it
 rewrites the AST happily until it thinks the result is sane).
 
 The main feeling I've come to settle on during the soon two years I've
 spent with LDC, is: we need a new frontend! D1 and D2 both have these
 problems, and they're not going away by themselves.
 
 -Tomas


That's my feeling also. A new front-end must be done, and the 
specification of the language must be clear in every aspect. No surprises.
May 09 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Tomas Lindquist Olsen, el  9 de mayo a las 15:55 me escribiste:

 The main feeling I've come to settle on during the soon two years I've
 spent with LDC, is: we need a new frontend! D1 and D2 both have these
 problems, and they're not going away by themselves.


Are you saying Dlang is comming? 8-)~

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
cederrón.
	(De CD-ROM, y este sigla del ingl. Compact Disc Read-Only Memory).
	1. m. Inform. CD-ROM.
	-- Real Academia Española
May 11 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  8 de mayo a las 11:56 me escribiste:

 Steve Teale wrote:

I am not criticizing you. I think you are doing a great job under the
pressure of a slew of suggestions. But maybe a line in the sand at
some point?


 
 But there *is* a line in the sand - D1.
 

OK so for those who crave stability there is D1.x, but when all the
focus appears to be on D2, what level of confidence is afforded to D1
users. Can a project Manager cross his heart and say that D1 will
still be alive and well in five years time?


 
 This just makes me very frustrated. Every fix going into D2 that also applies
to D1 has been folded into D1. There are even some fixes that only apply to D1 
 that only go into D1. These average about 20 per month. D1 even got the
FreeBSD port before D2. What other language gets that kind of support?


D1 is INCOMPLETE (for example pre/post conditions inheritance are
missing). I tend to forget which features are there for real what aren't
(there are a few, true, but still).

Another very *BIG* issue is lack of mainstream tools support.

C++98 was finished before starting C++0x. A lot of effort was made to make
mainstream tools to support C++. Most tools demangle C++ names (even when
they aren't standard!). At least GDB should be able to do that, and
Valgrind and GNU binutils, if you want people to be comfortable working
with D. There are patches here and there but nothing works out of the box.

I think what D1 is *really* missing is that 2 things: completeness and
tools support. Without that is really hard to take it seriously.

I think the D team should be working more in that direction before
finishing D2. I know is very boring comparing it to making D2, but I think
that is what is transmitted from D maintainers: "D1 is boring, don't pay
attention to it, D2 is fun, let's play with that!". And this is what
happening. People are playing with D2 and forgetting to finish D1.

The Tango vs. Phobos is still a *BIG* issue for D1. I think don't
addressing that is a huge error. It's only hurting D1 and preventing its
adoption.

The result is 2 incomplete, unsupported (by mainstream tools) languages.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
No existe nada más intenso que un reloj, ni nada más flaco que una
bicicleta. No intenso como el café, ni flaco como escopeta.
	-- Ricardo Vaporeso
May 09 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 D1 is INCOMPLETE (for example pre/post conditions inheritance are
 missing). I tend to forget which features are there for real what aren't
 (there are a few, true, but still).


Array ops weren't there for a long time, many argued that D1 wasn't 
complete without them, and a few months ago I added them in.

As far as I can tell, nobody cared about array ops.

In C++ land, only one compiler actually completely implements C++98, and 
this is after more than 10 years. (Exported templates and template name 
lookup rules remain unimplemented by major compilers.) (P.S. Digital 
Mars C++ does the correct name lookup rules!) The fact is, nobody 
actually cares about those incomplete features. Nobody uses exported 
templates, even if they are using a compiler that supports it.

So that leaves contract inheritance. I find it hard to see how not 
having it is a showstopper for using D1. Contracts in D haven't been the 
big win I thought they might be at first. They aren't use much at all. 
There are a lot of other issues that do make a big difference, and those 
are the issues that get attention.

We've got only so many chips (time) to play with, and it's real 
important that we play them for maximum effect.



 Another very *BIG* issue is lack of mainstream tools support.
 
 C++98 was finished before starting C++0x. A lot of effort was made to make
 mainstream tools to support C++. Most tools demangle C++ names (even when
 they aren't standard!). At least GDB should be able to do that, and
 Valgrind and GNU binutils, if you want people to be comfortable working
 with D. There are patches here and there but nothing works out of the box.


GDB does have an official D mode. There are demanglers for D 
identifiers. Can you submit patches for GDB to the official source tree?



 I think what D1 is *really* missing is that 2 things: completeness and
 tools support. Without that is really hard to take it seriously.
 
 I think the D team should be working more in that direction before
 finishing D2. I know is very boring comparing it to making D2, but I think
 that is what is transmitted from D maintainers: "D1 is boring, don't pay
 attention to it, D2 is fun, let's play with that!". And this is what
 happening. People are playing with D2 and forgetting to finish D1.


It isn't about boring. It's about allocating our very limited resources 
for maximum effect. If I thought that contract inheritance was a 
showstopper for D1, it'd move way up on the priority list. But I have a 
hard time believing it is a showstopper, like array ops turned out to 
not be.

Most of the work I do on dmd is bug fixes, and nearly all of those wind 
up in D1 as well. It's just not true that D1 is being overlooked or 
ignored, and the D1 changelog should amply illustrate that.

http://www.digitalmars.com/d/1.0/changelog.html



 The Tango vs. Phobos is still a *BIG* issue for D1. I think don't
 addressing that is a huge error. It's only hurting D1 and preventing its
 adoption.


Doing a merge would be a very breaking change. D2's support for Tango is 
probably the biggest breaking change in moving D1 code to D2.



 The result is 2 incomplete, unsupported (by mainstream tools) languages.
May 09 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  9 de mayo a las 11:23 me escribiste:

 Leandro Lucarella wrote:

D1 is INCOMPLETE (for example pre/post conditions inheritance are
missing). I tend to forget which features are there for real what aren't
(there are a few, true, but still).


 
 Array ops weren't there for a long time, many argued that D1 wasn't complete
without them, and a few months ago I added them in.
 
 As far as I can tell, nobody cared about array ops.
 
 In C++ land, only one compiler actually completely implements C++98, and
 this is after more than 10 years. (Exported templates and template name
 lookup rules remain unimplemented by major compilers.) (P.S. Digital
 Mars C++ does the correct name lookup rules!) The fact is, nobody
 actually cares about those incomplete features. Nobody uses exported
 templates, even if they are using a compiler that supports it.
 
 So that leaves contract inheritance. I find it hard to see how not
 having it is a showstopper for using D1. Contracts in D haven't been the
 big win I thought they might be at first. They aren't use much at all.
 There are a lot of other issues that do make a big difference, and those
 are the issues that get attention.


Exported templates was unpractical and unimplementable AFAIK (but I guess
you know that better than me). And C++ is an ISO standard language. D is
not. If something is unpractical and unimplementable in D (I don't think
is the case of contract inheritance) why didn't you removed a long time
ago when you decided that it wasn't useful?

And maybe you are right, but the bottom line is how D is perceived. People
usually don't go through the C++98 standard to learn C++, but it goes
through the D specs to learn D. Nobody talks about exported templates in
C++ because they don't exist in reality, but the D specs talks about
features that are missing in what is supposed to be a finished version.
And that makes D looks bad.


Another very *BIG* issue is lack of mainstream tools support.
C++98 was finished before starting C++0x. A lot of effort was made to make
mainstream tools to support C++. Most tools demangle C++ names (even when
they aren't standard!). At least GDB should be able to do that, and
Valgrind and GNU binutils, if you want people to be comfortable working
with D. There are patches here and there but nothing works out of the box.


 
 GDB does have an official D mode. There are demanglers for
 D identifiers. Can you submit patches for GDB to the official source
 tree?


Official? I don't see any official support for D in GDB. I can only find
this patches:
http://www.dsource.org/projects/gdb-patches/

And this thread about integrating the patches in GDB:
http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html

But I can't see any mention in the official GDB documentation and
certainly it doesn't automatically recognize D programs as such.


I think what D1 is *really* missing is that 2 things: completeness and
tools support. Without that is really hard to take it seriously.
I think the D team should be working more in that direction before
finishing D2. I know is very boring comparing it to making D2, but I think
that is what is transmitted from D maintainers: "D1 is boring, don't pay
attention to it, D2 is fun, let's play with that!". And this is what
happening. People are playing with D2 and forgetting to finish D1.


 
 It isn't about boring. It's about allocating our very limited resources
 for maximum effect. If I thought that contract inheritance was
 a showstopper for D1, it'd move way up on the priority list. But I have
 a hard time believing it is a showstopper, like array ops turned out to
 not be.


I don't think it's a *showtopper*. I'm trying to explain one of the
reasons I think D is perceived as a toy/incomplete/not-ready-for-business
language. But I certainly think D 1.0 should be finished before 2.0 though
=)


 Most of the work I do on dmd is bug fixes, and nearly all of those wind
 up in D1 as well. It's just not true that D1 is being overlooked or
 ignored, and the D1 changelog should amply illustrate that.
 
 http://www.digitalmars.com/d/1.0/changelog.html


I know that. Everybody knows that. And I don't think anybody is arguing
that. Lack of bug-fixing is not a mentioned problem AFAIK.


The Tango vs. Phobos is still a *BIG* issue for D1. I think don't
addressing that is a huge error. It's only hurting D1 and preventing its
adoption.


 
 Doing a merge would be a very breaking change. D2's support for Tango is
probably the biggest breaking change in moving D1 code to D2.


How is that? Most runtime code is not used by the user directly. And for
this item I think not merging it does more damage than introducing
a breaking change (is much better to introduce a breaking change to solve
this problem than to add a predefined Posix version ;).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 09 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 Official? I don't see any official support for D in GDB. I can only find
 this patches:
 http://www.dsource.org/projects/gdb-patches/


Dwarf has an official value for the language, DW_LANG_D = 0x13.



 How is that? Most runtime code is not used by the user directly. And for
 this item I think not merging it does more damage than introducing
 a breaking change (is much better to introduce a breaking change to solve
 this problem than to add a predefined Posix version ;).


Tango chose to use a number of incompatible names and a fundamentally 
different class hierarchy for the same thing(s).
May 09 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  9 de mayo a las 22:05 me escribiste:

 Leandro Lucarella wrote:

Official? I don't see any official support for D in GDB. I can only find
this patches:
http://www.dsource.org/projects/gdb-patches/


 
 Dwarf has an official value for the language, DW_LANG_D = 0x13.


I'm talking about GDB. GDB has no official D support. There was a thread
in the NG asking for possible copyright issues to include the GDB patch
upstream, and it had no answer for example. I don't think you *have* to
answer that mail, but I think helping this kind of things happening
instead of ignoring them is good for D promotion too =)


How is that? Most runtime code is not used by the user directly. And for
this item I think not merging it does more damage than introducing
a breaking change (is much better to introduce a breaking change to solve
this problem than to add a predefined Posix version ;).


 
 Tango chose to use a number of incompatible names and a fundamentally
 different class hierarchy for the same thing(s).


How many people is using that? How bad would it be to call the next
version of DMD that include the Tango/Druntime runtime D 1.100 or
something (is really hard to pick right version numbers under the version
scheme you use[*]) to make clear there is compatibility break in that
version?

Seriously, there were several (silly) compatibility breaks since 1.0 was
out, I think is a huge issue that deserves it...


[*] I really wonder how would you call D2 when it's stable. You will just
    say D 2.134 is D2 final/stable? I think this is another problem with
    D, version naming is really confusing and lame. You can't know
    anything from a D version number. And DMD compiler and D specs are too
    much coupled. It would be nice to have separate version numbers if you
    really want to encourage some kind of D standard and compiler vendors
    to start making D compilers.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
MATAN AL PERRO: DICEN QUE ESTABA POSEIDO POR EL DEMONIO...
	-- Crónica TV
May 10 2009
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Leandro Lucarella wrote:


 How many people is using that? How bad would it be to call the next
 version of DMD that include the Tango/Druntime runtime D 1.100 or
 something (is really hard to pick right version numbers under the version
 scheme you use[*]) to make clear there is compatibility break in that
 version?
 
 [*] I really wonder how would you call D2 when it's stable. You will just
     say D 2.134 is D2 final/stable? I think this is another problem with
     D, version naming is really confusing and lame. You can't know
     anything from a D version number. And DMD compiler and D specs are too
     much coupled. It would be nice to have separate version numbers if you
     really want to encourage some kind of D standard and compiler vendors
     to start making D compilers.


For what it's worth, there's at least one other major product that follows a
similar versioning scheme.. mysql.

Later,
Brad
May 10 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el 10 de mayo a las 10:12 me escribiste:

 Leandro Lucarella wrote:
 

 How many people is using that? How bad would it be to call the next
 version of DMD that include the Tango/Druntime runtime D 1.100 or
 something (is really hard to pick right version numbers under the version
 scheme you use[*]) to make clear there is compatibility break in that
 version?
 
 [*] I really wonder how would you call D2 when it's stable. You will just
     say D 2.134 is D2 final/stable? I think this is another problem with
     D, version naming is really confusing and lame. You can't know
     anything from a D version number. And DMD compiler and D specs are too
     much coupled. It would be nice to have separate version numbers if you
     really want to encourage some kind of D standard and compiler vendors
     to start making D compilers.


 
 For what it's worth, there's at least one other major product that follows a
 similar versioning scheme.. mysql.


At least MySQL uses major, minor, and patchlevel version numbering scheme
;)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
The biggest lie you can tell yourself is
When I get what I want I will be happy
May 10 2009
parent Brad Roberts <braddr puremagic.com> writes:
Leandro Lucarella wrote:

 Brad Roberts, el 10 de mayo a las 10:12 me escribiste:

 Leandro Lucarella wrote:


 How many people is using that? How bad would it be to call the next
 version of DMD that include the Tango/Druntime runtime D 1.100 or
 something (is really hard to pick right version numbers under the version
 scheme you use[*]) to make clear there is compatibility break in that
 version?

 [*] I really wonder how would you call D2 when it's stable. You will just
     say D 2.134 is D2 final/stable? I think this is another problem with
     D, version naming is really confusing and lame. You can't know
     anything from a D version number. And DMD compiler and D specs are too
     much coupled. It would be nice to have separate version numbers if you
     really want to encourage some kind of D standard and compiler vendors
     to start making D compilers.


 For what it's worth, there's at least one other major product that follows a
 similar versioning scheme.. mysql.


 
 At least MySQL uses major, minor, and patchlevel version numbering scheme
 ;)
 


Mysql uses an x.y.z numbering scheme.  DMD uses a y.z numbering scheme.  With
mysql's x.y being equavilent to dmd's y.  The use of z in both is the same.
Given that mysql's increase of its x.y component being somewhat arbitrary, it
might as well just be one number.

Either way, the transition of the z component through various stages from alpha
to release being at arbitrary points along the number line, my point still
stands. :)

Later,
Brad
May 10 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 Walter Bright, el  9 de mayo a las 22:05 me escribiste:

 Leandro Lucarella wrote:

 Official? I don't see any official support for D in GDB. I can only find
 this patches:
 http://www.dsource.org/projects/gdb-patches/


 Dwarf has an official value for the language, DW_LANG_D = 0x13.


 
 I'm talking about GDB. GDB has no official D support.


GDB officially supports Dwarf, and Dwarf officially has a D identifier. 
While gdb may not go any further than that, it's a start.


 There was a thread
 in the NG asking for possible copyright issues to include the GDB patch
 upstream, and it had no answer for example. I don't think you *have* to
 answer that mail, but I think helping this kind of things happening
 instead of ignoring them is good for D promotion too =)


Can you point me to that thread? There are an awful lot of posts, and I 
miss things.



 How is that? Most runtime code is not used by the user directly. And for
 this item I think not merging it does more damage than introducing
 a breaking change (is much better to introduce a breaking change to solve
 this problem than to add a predefined Posix version ;).


 Tango chose to use a number of incompatible names and a fundamentally
 different class hierarchy for the same thing(s).


 
 How many people is using that? How bad would it be to call the next
 version of DMD that include the Tango/Druntime runtime D 1.100 or
 something (is really hard to pick right version numbers under the version
 scheme you use[*]) to make clear there is compatibility break in that
 version?


Given all the beating of breasts and rending of robes about D1 not being 
stable and breaking code even when a bug is fixed in it, I just can't 
see coming out with a new D1 that substantially breaks every existing D1 
code base.



 Seriously, there were several (silly) compatibility breaks since 1.0 was
 out, I think is a huge issue that deserves it...


This is what I mean when I say that it's simply impossible to ask for 
breaking changes for D1 while pillorying D1 for breaking changes. I also 
believe it is impractical to divide D1 into two incompatible versions - 
then there'd be 3 D versions to simultaneously support.

D2 has already taken the steps necessary to support both Phobos and Tango.
May 10 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 10 de mayo a las 11:21 me escribiste:

 Leandro Lucarella wrote:

Walter Bright, el  9 de mayo a las 22:05 me escribiste:

Leandro Lucarella wrote:

Official? I don't see any official support for D in GDB. I can only find
this patches:
http://www.dsource.org/projects/gdb-patches/


Dwarf has an official value for the language, DW_LANG_D = 0x13.


I'm talking about GDB. GDB has no official D support.


 
 GDB officially supports Dwarf, and Dwarf officially has a D identifier. While
gdb may not go any further than that, it's a start.
 

There was a thread
in the NG asking for possible copyright issues to include the GDB patch
upstream, and it had no answer for example. I don't think you *have* to
answer that mail, but I think helping this kind of things happening
instead of ignoring them is good for D promotion too =)


 
 Can you point me to that thread? There are an awful lot of posts, and I miss
things.


I posted it in this very same thread, just before the link to the GDB
patches link. Here it is again:
http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html


How is that? Most runtime code is not used by the user directly. And for
this item I think not merging it does more damage than introducing
a breaking change (is much better to introduce a breaking change to solve
this problem than to add a predefined Posix version ;).


Tango chose to use a number of incompatible names and a fundamentally
different class hierarchy for the same thing(s).


How many people is using that? How bad would it be to call the next
version of DMD that include the Tango/Druntime runtime D 1.100 or
something (is really hard to pick right version numbers under the version
scheme you use[*]) to make clear there is compatibility break in that
version?


 
 Given all the beating of breasts and rending of robes about D1 not being
 stable and breaking code even when a bug is fixed in it, I just can't
 see coming out with a new D1 that substantially breaks every existing D1
 code base.


It would break all existing D1 code base?


Seriously, there were several (silly) compatibility breaks since 1.0 was
out, I think is a huge issue that deserves it...


 
 This is what I mean when I say that it's simply impossible to ask for
 breaking changes for D1 while pillorying D1 for breaking changes. I also
 believe it is impractical to divide D1 into two incompatible versions
 - then there'd be 3 D versions to simultaneously support.


If the compiler were really open source, and the frontend were in a public
repository, and fixes would be well separated patches, you wouldn't have
to maintain 3 D version. You probably even have to maintain 2 D versions.
Other people could take over and apply fixes to the stable D branches
while you with D2. The problem is doing that right now is really hard,
because to see what changed in the DMDFE from one version to another you
have to download 2 complete compiler version, make a diff yourself and you
end up with a big diff that you can't possible break in small chunks with
individual bugfixes.


 D2 has already taken the steps necessary to support both Phobos and Tango.


But D2 is not nearly ready for production use. D1 is almost there... Is
missing so little that it's frustrating.

In case you are not following the thread about interior pointers, here is
another drawback for the Tango vs. Phobos problem, here is copy&pasted
fragment:

  I think it would be great to have a centralized place where to put this
  improvements. This is another situation where I think Tango vs. Phobos
  issue is killing D. When I started my work in the thesis I had to decide
  whether to work with Phobos or Tango. I finally decided for Tango, because
  is the only option for LDC and because is way better organized (and more
  receptive to patches). But I hate knowing that my work will be available
  (in the best case) only for people using Tango.


-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
De tan fina la condesa, por no cagarse, reza.
	-- Ricardo Vaporeso
May 10 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 Walter Bright, el 10 de mayo a las 11:21 me escribiste:
 I posted it in this very same thread, just before the link to the GDB
 patches link. Here it is again:
 http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html


Thank you.


 Given all the beating of breasts and rending of robes about D1 not being
 stable and breaking code even when a bug is fixed in it, I just can't
 see coming out with a new D1 that substantially breaks every existing D1
 code base.


 
 It would break all existing D1 code base?


I suspect it would break pretty much all the non-trivial code.



 If the compiler were really open source, and the frontend were in a public
 repository, and fixes would be well separated patches, you wouldn't have
 to maintain 3 D version.


It's not just me, it's the poor sap who has to maintain 3 different 
versions of his library.



 D2 has already taken the steps necessary to support both Phobos and Tango.


 But D2 is not nearly ready for production use. D1 is almost there... Is
 missing so little that it's frustrating.


I don't believe that contract inheritance is the key to production use. 
There shouldn't be anything standing in the way of using D1 for 
production use, and in fact it is being used that way.



 In case you are not following the thread about interior pointers, here is
 another drawback for the Tango vs. Phobos problem, here is copy&pasted
 fragment:
 
   I think it would be great to have a centralized place where to put this
   improvements. This is another situation where I think Tango vs. Phobos
   issue is killing D. When I started my work in the thesis I had to decide
   whether to work with Phobos or Tango. I finally decided for Tango, because
   is the only option for LDC and because is way better organized (and more
   receptive to patches). But I hate knowing that my work will be available
   (in the best case) only for people using Tango.


I don't believe that splitting D into yet another separate version can 
fix this, as then the user has to decide which D to use.
May 10 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 10 de mayo a las 15:42 me escribiste:

 Leandro Lucarella wrote:

Walter Bright, el 10 de mayo a las 11:21 me escribiste:
I posted it in this very same thread, just before the link to the GDB
patches link. Here it is again:
http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html


 
 Thank you.


You are welcome. I'm very glad this is taking some attention =)

In case you missed my other mail, I opened a bug report in GDB bugzilla to
keep track of the patch:
http://sourceware.org/bugzilla/show_bug.cgi?id=10142


Given all the beating of breasts and rending of robes about D1 not being
stable and breaking code even when a bug is fixed in it, I just can't
see coming out with a new D1 that substantially breaks every existing D1
code base.


It would break all existing D1 code base?


 
 I suspect it would break pretty much all the non-trivial code.


What are exactly the user-visible changes?


If the compiler were really open source, and the frontend were in a public
repository, and fixes would be well separated patches, you wouldn't have
to maintain 3 D version.


 
 It's not just me, it's the poor sap who has to maintain 3 different
 versions of his library.


This is not fixable by adding a aliases for old names and leave them as
deprecated?


D2 has already taken the steps necessary to support both Phobos and Tango.


But D2 is not nearly ready for production use. D1 is almost there... Is
missing so little that it's frustrating.


 
 I don't believe that contract inheritance is the key to production use.
 There shouldn't be anything standing in the way of using D1 for
 production use, and in fact it is being used that way.


Honestly I'm not confident enough in D1 for production use if it's
incomplete and if the Tango/Druntime runtime is not merged because
2 codebases should be maintained and you can't use the few libraries
available for one runtime with the other (without using some hackish
wrappers). Lack of support in mainstream tools is the other thing
preventing me to use D at work. I *can't* use D for something serious
(sadly, because I'd love to).


In case you are not following the thread about interior pointers, here is
another drawback for the Tango vs. Phobos problem, here is copy&pasted
fragment:
  I think it would be great to have a centralized place where to put this
  improvements. This is another situation where I think Tango vs. Phobos
  issue is killing D. When I started my work in the thesis I had to decide
  whether to work with Phobos or Tango. I finally decided for Tango, because
  is the only option for LDC and because is way better organized (and more
  receptive to patches). But I hate knowing that my work will be available
  (in the best case) only for people using Tango.


 
 I don't believe that splitting D into yet another separate version can
 fix this, as then the user has to decide which D to use.


Use the latest stable version, as you do with any serious language =)
You shouldn't introduce breaking changes too often. I think a language
version bump every (half) year is very acceptable.

I mean, just see how Python/Ruby/PHP/Java/Haskel/<pick any other language>
development model works, all very evolving languages that don't break
backwards compatibility very often and with a lot of well maintained
programs and libraries.

But this is getting repetitive, so I guess it has no point to keep
discussing it. Once in a while I have the crazy idea that you can be
convinced otherwise (hey! You finally got convinced to fork D2 from D1!
=)...

Maybe I'll try again in a few months...

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Si ella es el sol, yo soy la luna
Si ella es el mar, soy el desierto
Y estamos en eclipse total
Y estamos en eclipse total
May 10 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 In case you missed my other mail, I opened a bug report in GDB bugzilla to
 keep track of the patch:
 http://sourceware.org/bugzilla/show_bug.cgi?id=10142


This is great. I'm glad you're pushing this.
May 10 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 10 de mayo a las 21:03 me escribiste:

 Leandro Lucarella wrote:

In case you missed my other mail, I opened a bug report in GDB bugzilla to
keep track of the patch:
http://sourceware.org/bugzilla/show_bug.cgi?id=10142


 
 This is great. I'm glad you're pushing this.


I just hope one day in a near future we have D support in the tools I use
daily to develop as good as C++ so I can have a chance to convince my boss
to be able to use it at work =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Are you such a dreamer?
To put the world to rights?
I'll stay home forever
Where two & two always
makes up five
May 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 I just hope one day in a near future we have D support in the tools I use
 daily to develop as good as C++ so I can have a chance to convince my boss
 to be able to use it at work =)


Hoping is one thing, but submitting patches, bug reports, etc. to the 
tool developers is much more effective!
May 11 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 11 de mayo a las 11:46 me escribiste:

 Leandro Lucarella wrote:

I just hope one day in a near future we have D support in the tools I use
daily to develop as good as C++ so I can have a chance to convince my boss
to be able to use it at work =)


 
 Hoping is one thing, but submitting patches, bug reports, etc. to the tool 
 developers is much more effective!


Sure, but people already done that and got ignore. I'm just glad you only
overlooked that mail and you're willing to help to iron out any licensing
issue.

GDB people have spoken (I don't see you subscribed to the bug report so
I transcribe the comment from GDB):

--------------------------------------------------------------------------
For a patch this size we would need copyright assignments from all
the authors of the patch.  I would suggest emailing the gdb list
and asking for the paperwork; one of the maintainers will get you started.

Also, send the patch to the gdb-patches list, as described here:
http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/CONTRIBUTE?content-type=text/x-cvsweb-markup&cvsroot=src
gdb doesn't really use bugzilla for patch tracking, much.

I glanced quickly at the patch; it will need some reformatting and it will
need to be rebased to the current cvs.  It may require other changes, too,
but I didn't read that closely.
--------------------------------------------------------------------------

When all licensing issues are resolved I can do any adjustments to the
patch to comply with GDB coding style and rebase it to current CVS if the
original author is missing.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 11 2009
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Leandro Lucarella wrote:

 GDB people have spoken (I don't see you subscribed to the bug report so
 I transcribe the comment from GDB):
 
 --------------------------------------------------------------------------
 For a patch this size we would need copyright assignments from all
 the authors of the patch.  I would suggest emailing the gdb list
 and asking for the paperwork; one of the maintainers will get you started.
 
 Also, send the patch to the gdb-patches list, as described here:
 http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/CONTRIBUTE?content-type=text/x-cvsweb-markup&cvsroot=src
 gdb doesn't really use bugzilla for patch tracking, much.
 
 I glanced quickly at the patch; it will need some reformatting and it will
 need to be rebased to the current cvs.  It may require other changes, too,
 but I didn't read that closely.
 --------------------------------------------------------------------------
 
 When all licensing issues are resolved I can do any adjustments to the
 patch to comply with GDB coding style and rebase it to current CVS if the
 original author is missing.


If the original author is missing, you have a bigger problem. He presumably 
needs to sign the paperwork they mentioned...
May 11 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Frits van Bommel, el 11 de mayo a las 22:15 me escribiste:

 Leandro Lucarella wrote:

GDB people have spoken (I don't see you subscribed to the bug report so
I transcribe the comment from GDB):
--------------------------------------------------------------------------
For a patch this size we would need copyright assignments from all
the authors of the patch.  I would suggest emailing the gdb list
and asking for the paperwork; one of the maintainers will get you started.
Also, send the patch to the gdb-patches list, as described here:
http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/CONTRIBUTE?content-type=text/x-cvsweb-markup&cvsroot=src
gdb doesn't really use bugzilla for patch tracking, much.
I glanced quickly at the patch; it will need some reformatting and it will
need to be rebased to the current cvs.  It may require other changes, too,
but I didn't read that closely.
--------------------------------------------------------------------------
When all licensing issues are resolved I can do any adjustments to the
patch to comply with GDB coding style and rebase it to current CVS if the
original author is missing.


 
 If the original author is missing, you have a bigger problem. He
 presumably needs to sign the paperwork they mentioned...


Yes, I meant if he is alive and willing to give the rights to GDB but
don't want to bother to fix the style and rebase the patch himself.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Skepticism is the beginning of failure
May 11 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 Hoping is one thing, but submitting patches, bug reports, etc. to the tool 
 developers is much more effective!


 Sure, but people already done that and got ignore. I'm just glad you only
 overlooked that mail and you're willing to help to iron out any licensing
 issue.


I'm not the tool vendor for gdb. I also looked over the patches to gdb 
and don't see anything that requires approval or action from me.


 GDB people have spoken (I don't see you subscribed to the bug report so
 I transcribe the comment from GDB):
 
 --------------------------------------------------------------------------
 For a patch this size we would need copyright assignments from all
 the authors of the patch.  I would suggest emailing the gdb list
 and asking for the paperwork; one of the maintainers will get you started.
 
 Also, send the patch to the gdb-patches list, as described here:
 http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/CONTRIBUTE?content-type=text/x-cvsweb-markup&cvsroot=src
 gdb doesn't really use bugzilla for patch tracking, much.
 
 I glanced quickly at the patch; it will need some reformatting and it will
 need to be rebased to the current cvs.  It may require other changes, too,
 but I didn't read that closely.
 --------------------------------------------------------------------------
 
 When all licensing issues are resolved I can do any adjustments to the
 patch to comply with GDB coding style and rebase it to current CVS if the
 original author is missing.


It would be great if you could be the champion for this and get it 
through. It'll help out a lot!
May 11 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 11 de mayo a las 14:03 me escribiste:

 Leandro Lucarella wrote:

Hoping is one thing, but submitting patches, bug reports, etc. to the tool
developers is much more effective!


Sure, but people already done that and got ignore. I'm just glad you only
overlooked that mail and you're willing to help to iron out any licensing
issue.


 
 I'm not the tool vendor for gdb. I also looked over the patches to gdb
 and don't see anything that requires approval or action from me.


Isn't the demangle code taken from DMDFE?

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Y2K
<Aztech_> hmm, nothing major has happend, what an anticlimax
<CaPS> yeah
<CaPS> really sucks
<CaPS> I expected for Australia to sink into the sea or something
<CaPS> but nnoooooooo
May 11 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 Isn't the demangle code taken from DMDFE?


It didn't look like it, especially since the DMDFE doesn't have a 
demangler in it! The one in Phobos is explicitly listed as Public Domain.
May 11 2009
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Leandro Lucarella wrote:

 Isn't the demangle code taken from DMDFE?


Why would DMDFE need a demangler? It can just not mangle in the first place :).
May 12 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Frits van Bommel (fvbommel REMwOVExCAPSs.nl)'s article

 Leandro Lucarella wrote:

 Isn't the demangle code taken from DMDFE?


 Why would DMDFE need a demangler? It can just not mangle in the first place :).


You need name mangling for templates and function overloading to work.
May 12 2009
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
dsimcha wrote:

 == Quote from Frits van Bommel (fvbommel REMwOVExCAPSs.nl)'s article

 Leandro Lucarella wrote:

 Isn't the demangle code taken from DMDFE?


 Why would DMDFE need a demangler? It can just not mangle in the first place :).


 
 You need name mangling for templates and function overloading to work.


Mangling, yes. Demangling, no.
(i.e. anywhere it needs the un-mangled name it can just look it up directly, 
without running the mangler)
May 12 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Frits van Bommel, el 12 de mayo a las 16:28 me escribiste:

 Leandro Lucarella wrote:

Isn't the demangle code taken from DMDFE?


 
 Why would DMDFE need a demangler? It can just not mangle in the first
 place :).


Yes, yes, yes, I get the point. I meant Phobos...

¬¬

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 Yes, yes, yes, I get the point. I meant Phobos...


Which is (std.demangle) explicitly public domain. If FSF has a problem 
with public domain submissions, please let me know. (The FSF can change 
one byte of it and copyright the "derived work" however way they please, 
and so can anyone else.)
May 12 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 12 de mayo a las 10:18 me escribiste:

 Leandro Lucarella wrote:

Yes, yes, yes, I get the point. I meant Phobos...


 
 Which is (std.demangle) explicitly public domain. If FSF has a problem with 
 public domain submissions, please let me know. (The FSF can change one byte of 
 it and copyright the "derived work" however way they please, and so can anyone 
 else.)


I took a quick look at phobos demangle code and it doesn't look similar to
the one in the GDB patch. I guess I should checked first, my apologies for
bugging you when it looks like you have nothing to do with this patch.
I was under the impression that it used your code for some reason.

Now the only think to do is wait until Mihail Zenkov answer my mail (no
news for now =( ).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 Now the only think to do is wait until Mihail Zenkov answer my mail (no
 news for now =( ).


If he doesn't, just recode the patch and submit it. There doesn't look 
like there's much to it. My understanding from the FSF is the only 
concern is with patches that are more than 10 lines. The single line 
changes here and there in the gdb patch don't need to be redone.

The point of making std.demangle public domain is so that other tools 
can freely incorporate it and support D!
May 12 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Walter Bright wrote:

 Leandro Lucarella wrote:

 Now the only think to do is wait until Mihail Zenkov answer my mail (no
 news for now =( ).


 
 If he doesn't, just recode the patch and submit it. There doesn't look 
 like there's much to it. My understanding from the FSF is the only 
 concern is with patches that are more than 10 lines. The single line 
 changes here and there in the gdb patch don't need to be redone.
 
 The point of making std.demangle public domain is so that other tools 
 can freely incorporate it and support D!



OK, Leandro, so quoting to them the above post, and quoting the 
beginning of the file demangle.d ought to do the trick:

  * Placed into the Public Domain.
...
/* Authors:
  *      Walter Bright, Digital Mars, www.digitalmars.com
  *      Thomas Kuehne
  *      Frits van Bommel


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

Knowing what (*seriously excuse* the wording here) fascists the FSF guys 
are, they obviously assume similar behavior of any opposition. That 
explains why they appear paranoid and unreasonable in their demands of 
the copyright statements for any code even remotely considered for 
inclusion.

PS: even if the intent is benign, there's no reason for anti-benign 
action or attitudes. That's why their track record forced me to use 
harsh language, above. ((( please don't nobody get me started on this 
one )))
May 12 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Georg Wrede wrote:

 Knowing what (*seriously excuse* the wording here) fascists the FSF guys 
 are, they obviously assume similar behavior of any opposition. That 
 explains why they appear paranoid and unreasonable in their demands of 
 the copyright statements for any code even remotely considered for 
 inclusion.


Copyright assignment makes management a hell of a lot easier for them. 
They have the authority to sue anyone who uses any part of their 
projects, and they don't have to go through their records to determine this.

This is one reason why public domain code is not particularly 
interesting for them.

Of course, they can put a comment the relevant code to the effect that 
the original is in the public domain, which should take care of the problem.
May 12 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Christopher Wright wrote:

 Georg Wrede wrote:

 Knowing what (*seriously excuse* the wording here) fascists the FSF 
 guys are, they obviously assume similar behavior of any opposition. 
 That explains why they appear paranoid and unreasonable in their 
 demands of the copyright statements for any code even remotely 
 considered for inclusion.


 
 Copyright assignment makes management a hell of a lot easier for them. 
 They have the authority to sue anyone who uses any part of their 
 projects, and they don't have to go through their records to determine 
 this.
 
 This is one reason why public domain code is not particularly 
 interesting for them.
 
 Of course, they can put a comment the relevant code to the effect that 
 the original is in the public domain, which should take care of the 
 problem.


Well (still resisting opening Pandora's box!!!!), I see Public Domain as 
a superset of any of the OSS &co licenses. Oper source simply means (to 
me, anyway), free to use anyway you want, including selling and 
incorporating into other people's apps.

So, licencing somethign as Public Domain, ought to make FSF and others, 
to be able (er, willing would be the word) to incorporate the code, as 
they see fit.
May 12 2009
parent reply BCS <none anon.com> writes:
Hello Georg,


 Well (still resisting opening Pandora's box!!!!), I see Public Domain
 as a superset of any of the OSS &co licenses. Oper source simply means
 (to me, anyway), free to use anyway you want, including selling and
 incorporating into other people's apps.
 
 So, licencing somethign as Public Domain, ought to make FSF and
 others, to be able (er, willing would be the word) to incorporate the
 code, as they see fit.
 


The issue might be that the GPL code forbids some thing and unless FSF owns 
the original code, the question can come up of if someone is misusing the 
GPL copy or correctly using the public domain copy.
May 12 2009
parent Brad Roberts <braddr puremagic.com> writes:
BCS wrote:

 Hello Georg,
 

 Well (still resisting opening Pandora's box!!!!), I see Public Domain
 as a superset of any of the OSS &co licenses. Oper source simply means
 (to me, anyway), free to use anyway you want, including selling and
 incorporating into other people's apps.

 So, licencing somethign as Public Domain, ought to make FSF and
 others, to be able (er, willing would be the word) to incorporate the
 code, as they see fit.


 
 The issue might be that the GPL code forbids some thing and unless FSF
 owns the original code, the question can come up of if someone is
 misusing the GPL copy or correctly using the public domain copy.


Suggestion.. avoid speculation about the FSF motives or requirements and the
reasons behind them.  Let's let whoever can/will pursue it with them and see how
it unfolds.
May 12 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 There was a thread
 in the NG asking for possible copyright issues to include the GDB patch
 upstream, and it had no answer for example. I don't think you *have* to
 answer that mail, but I think helping this kind of things happening
 instead of ignoring them is good for D promotion too =)


 Can you point me to that thread? There are an awful lot of posts, and I miss
things.


 
 I posted it in this very same thread, just before the link to the GDB
 patches link. Here it is again:
 http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html


If someone has a patch ready to submit to GDB, and needs some licensing 
change for it, I'm happy to provide that.
May 10 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 10 de mayo a las 20:54 me escribiste:

 Leandro Lucarella wrote:

Walter Bright, el 10 de mayo a las 15:44 me escribiste:
  

Leandro Lucarella wrote:
    

There was a thread
in the NG asking for possible copyright issues to include the GDB patch
upstream, and it had no answer for example. I don't think you *have* to
answer that mail, but I think helping this kind of things happening
instead of ignoring them is good for D promotion too =)
          


Can you point me to that thread? There are an awful lot of posts, and I miss
things.
        


I posted it in this very same thread, just before the link to the GDB
patches link. Here it is again:
http://www.digitalmars.com/d/archives/digitalmars/D/Getting_D_language_patch_into_GDB_82597.html
      


If someone has a patch ready to submit to GDB, and needs some licensing
change for it, I'm happy to provide that.
    


I've opened a new "bug" in GDB bugzilla to keep track of D support patch.
It would be great if people that has anything to do with the patch (the
patch author and Walter, I guess, if the demangle code is from DMD) can
follow the bug report.
  


 
 URL, please!


http://sourceware.org/bugzilla/show_bug.cgi?id=10142


 (Also, did you mean to post this in the n.g.?)


Yes, sorry!

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
CHINO ATRAPA COTORRAS
	-- Crónica TV
May 11 2009
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Leandro Lucarella wrote:

 
 Another very *BIG* issue is lack of mainstream tools support.
 
 C++98 was finished before starting C++0x. A lot of effort was made to make
 mainstream tools to support C++. Most tools demangle C++ names (even when
 they aren't standard!). At least GDB should be able to do that, and
 Valgrind and GNU binutils, if you want people to be comfortable working
 with D. There are patches here and there but nothing works out of the box.


A critical error that keeps being made.. in MOST compiled languages, the authors
of the compilers are not the ones that are producing the eco-systems above them.
 Even for the VM based languages, the language/compiler/runtime authors rarely
venture much above those.  Eclipse isn't a sun invention, nor are any of the
other development environments.  Microsoft is about the only one that produces
an large tool chain, but the groups that do the various parts are different.
The compiler team doesn't produce (or in many cases even use) Visual Studio.

Etc..

So, want the tool chain to mature.. go to work.  Work with the GDB community to
build and incorporate changes.  The same with all the things you want to see
changed or created.

If there's things that need to change in what the compiler emits, Walter has
shown himself to be willing to rapidly change them where the required changes
are clearly described in terms of both 'what' and 'why'.  In other words, "it's
broken" isn't sufficient but "if the frobble was changed to frobnosticator for
each wobble, it would work" results in the next release having that change made.


 I think what D1 is *really* missing is that 2 things: completeness and
 tools support. Without that is really hard to take it seriously.
 
 I think the D team should be working more in that direction before
 finishing D2. I know is very boring comparing it to making D2, but I think
 that is what is transmitted from D maintainers: "D1 is boring, don't pay
 attention to it, D2 is fun, let's play with that!". And this is what
 happening. People are playing with D2 and forgetting to finish D1.


If you've gotten the impression that "d1 is boring" is the message from whatever
this "the d team" (team suggests many people, but there's really just a tiny few
involved -- this isn't microsoft or sun with hundreds of worker ants) is, then
you're impression is off.  The message is "d1 is only receiving bug fixes -- and
only those with the right balance of risk/reward".


 The Tango vs. Phobos is still a *BIG* issue for D1. I think don't
 addressing that is a huge error. It's only hurting D1 and preventing its
 adoption.
 
 The result is 2 incomplete, unsupported (by mainstream tools) languages.


This is, in my honest opinion, the most clearly debatable point.  I happen to
have originally been on the side of "we must do something for D1" but since then
I've agreed that the effort is best spent moving forward than disrupting the
current.

---

All of the above is _my_ opinion, and everyone is entitled to their own.

Later,
Brad
May 09 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el  9 de mayo a las 12:31 me escribiste:

 Leandro Lucarella wrote:

 
 Another very *BIG* issue is lack of mainstream tools support.
 
 C++98 was finished before starting C++0x. A lot of effort was made to make
 mainstream tools to support C++. Most tools demangle C++ names (even when
 they aren't standard!). At least GDB should be able to do that, and
 Valgrind and GNU binutils, if you want people to be comfortable working
 with D. There are patches here and there but nothing works out of the box.


 
 A critical error that keeps being made.. in MOST compiled languages, the
authors
 of the compilers are not the ones that are producing the eco-systems above
them.
  Even for the VM based languages, the language/compiler/runtime authors rarely
 venture much above those.  Eclipse isn't a sun invention, nor are any of the
 other development environments.  Microsoft is about the only one that produces
 an large tool chain, but the groups that do the various parts are different.
 The compiler team doesn't produce (or in many cases even use) Visual Studio.
 
 Etc..


I know that, but the "language" should push forward in that direction.
I don't know why this happen with D, what can be made to improve the
situation, but I think putting all the attention in D2 doesn't help, and
doesn't encourage people to work on D1.

I've decided to work in D1 GC instead of D2 partially because of this.
I think D1 is a great language, very *very* close to be complete. It's
a shame to through that because D2 is cooler. For example, I can't use
D for work. I can't convince my bosses to use D when you have to compile
your own toolchain to get a debugger that works with it. C++ sucks, but
I'm stucked with that as long as it has better tools support than D. And
I think this is where D1 can start taking off, when it's ready for
busyness, because unfortunatelly is really hard to produce things for
D just as a hobby.

And why this only happen to D? Really, don't you even ask yourselves?
I think there is a "social" problem with D, or a "leadership" problem.
I think people is not encouraged to work on D1.


 So, want the tool chain to mature.. go to work.  Work with the GDB community to
 build and incorporate changes.  The same with all the things you want to see
 changed or created.


Unfortunatelly I'm putting my work in the GC now. I was so annoyed a weak
ago about not being able to use gdb, valgrind or nm with D that
I downloaded valgrind to see how hard it would be to add D support to it,
but I had to desist because I don't have the time right now.


 I think what D1 is *really* missing is that 2 things: completeness and
 tools support. Without that is really hard to take it seriously.
 
 I think the D team should be working more in that direction before
 finishing D2. I know is very boring comparing it to making D2, but I think
 that is what is transmitted from D maintainers: "D1 is boring, don't pay
 attention to it, D2 is fun, let's play with that!". And this is what
 happening. People are playing with D2 and forgetting to finish D1.


 
 If you've gotten the impression that "d1 is boring" is the message from
whatever
 this "the d team" (team suggests many people, but there's really just a tiny
few
 involved -- this isn't microsoft or sun with hundreds of worker ants) is, then
 you're impression is off.  The message is "d1 is only receiving bug fixes --
and
 only those with the right balance of risk/reward".


When I say "D team" I mean Walter, Andrei and Bartoz mostly, maybe Don and
Seam too =)

The impression is what it is. It can't be off. If something gives an
impression it doesn't matter if you don't want to make that impression,
that's the point (I know this maybe has no sense as it is written, english
is not my first language and I don't know how to explain it better).

And I think ignoring that that impression is made, when every month (or
weak!) there is a thread about it, is dumb.


-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Es mas posible, que un elefante maneje un cero km a que un camello
habite un departamento de un ambiente.
	-- Peperino Pómoro
May 09 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el  9 de mayo a las 12:31 me escribiste:

 If there's things that need to change in what the compiler emits, Walter has
 shown himself to be willing to rapidly change them where the required changes
 are clearly described in terms of both 'what' and 'why'.  In other words, "it's
 broken" isn't sufficient but "if the frobble was changed to frobnosticator for
 each wobble, it would work" results in the next release having that change
made.


BTW, here is something that should be fixed in the compiler to improve GNU
binutils support =)
http://d.puremagic.com/issues/show_bug.cgi?id=2932

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Un paracaidista, que no deja de caer.
Lo que me lleva hacia arriba, es lo que me tira hacia abajo.
May 09 2009
parent reply Brad Roberts <braddr puremagic.com> writes:
Leandro Lucarella wrote:

 Brad Roberts, el  9 de mayo a las 12:31 me escribiste:

 If there's things that need to change in what the compiler emits, Walter has
 shown himself to be willing to rapidly change them where the required changes
 are clearly described in terms of both 'what' and 'why'.  In other words, "it's
 broken" isn't sufficient but "if the frobble was changed to frobnosticator for
 each wobble, it would work" results in the next release having that change
made.


 
 BTW, here is something that should be fixed in the compiler to improve GNU
 binutils support =)
 http://d.puremagic.com/issues/show_bug.cgi?id=2932
 


A great illustration of a less than ideal bug report.  "A tool breaks in some
way, fix the compiler."  It's entirely possible that dmd is producing the wrong
thing, but there's an definite lack of specificity about what's wrong on the
compiler side.  Those errors are coming out of the linker.  It's not even
particularly clear that the bug is with dmd and not the new linker (one that's
not shipped as the default linker on any distribution yet, unless I've lost
track again).  In other words, it's not at all surprising to me that the bug
report hasn't received a lot of attention yet.

Prioritization is a difficult exercise, and there's no way everyone will ever be
happy.

Later,
Brad
May 09 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el  9 de mayo a las 21:42 me escribiste:

 Leandro Lucarella wrote:

 Brad Roberts, el  9 de mayo a las 12:31 me escribiste:

 If there's things that need to change in what the compiler emits, Walter has
 shown himself to be willing to rapidly change them where the required changes
 are clearly described in terms of both 'what' and 'why'.  In other words, "it's
 broken" isn't sufficient but "if the frobble was changed to frobnosticator for
 each wobble, it would work" results in the next release having that change
made.


 
 BTW, here is something that should be fixed in the compiler to improve GNU
 binutils support =)
 http://d.puremagic.com/issues/show_bug.cgi?id=2932
 


 
 A great illustration of a less than ideal bug report.  "A tool breaks in some
 way, fix the compiler."  It's entirely possible that dmd is producing the wrong
 thing, but there's an definite lack of specificity about what's wrong on the
 compiler side.  Those errors are coming out of the linker.  It's not even
 particularly clear that the bug is with dmd and not the new linker (one that's
 not shipped as the default linker on any distribution yet, unless I've lost
 track again).


No, it's not (it's shipped but not as the default linker), because they
are making sure that it works well with other tools. Usually when you use
a tool that is a de facto standard and have some bug, people start relying
in that bug as a feature. I know I had some linking bugs because of this,
and I spotted them thanks to Gold. I'm not saying that Gold is perfect,
but since it's a complete rewrite there are some bugs fixed (or things
where is more strict than the old GNU ld) that should be adjusted to work
well with the new linker.

I reported the bug because I think that could be the case. If is not, it's
a Gold bug and it should be reported. If it is, it should be fixed in DMD.
I don't have the knowlegde to check that myself, and that's why I reported
the bug to both tools.


 In other words, it's not at all surprising to me that the bug report
 hasn't received a lot of attention yet.


So you are saying you have to be a compiler hacker to report a bug? Great,
that make sense!

I think the error message is pretty clear (the ELF header size is supposed
to be wrong). I think somebody that know the compiler can check if this
bug report is right or if it's a bug in GNU Gold in a couple of minutes
(maybe seconds). And BTW GDC and LDC works just fine. I guess you can
argue that GDC uses the GCC backend which can be tightly coupled with GNU
binutils being both a GNU product, but LDC is not. So the bug report has
a high probability to be right, I wasn't saw the error message and run to
the D bugzilla to report the bug, I tested other tools first, and from my
own experience with Gold, when it said there was an error and I thought
the error was in Gold, I was wrong and Gold was right (because what I said
before, I was relying on some bugs in the old GNU ld), so I have some
degree of confidence in that Gold is not a piece of crap full of bugs.

And you may take a look to the GNU Gold linker bug report:
http://sourceware.org/bugzilla/show_bug.cgi?id=10126

It is having attention. That's why GNU tools are widely used and D isn't.
This kind of things make very sad...

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
VECINOS RESCATARON A CABALLITO ATROPELLADO
	-- Crónica TV
May 10 2009
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Leandro Lucarella wrote:


 I reported the bug because I think that could be the case. If is not, it's
 a Gold bug and it should be reported. If it is, it should be fixed in DMD.
 I don't have the knowlegde to check that myself, and that's why I reported
 the bug to both tools.
 

 In other words, it's not at all surprising to me that the bug report
 hasn't received a lot of attention yet.


 
 So you are saying you have to be a compiler hacker to report a bug? Great,
 that make sense!


You seem to have missed my point.  The point was, the more detailed the report,
the clearer the steps to reproduce, the more obvious it is that the compiler is
what's broken.. all of these things increase the likelihood of a bug report
having a higher priority.

The incoming rate is higher than the fix rate (as evidenced by the number of
open bugs) and so something has to give.  All I was doing was illustrating some
reasons that might have contributed to that specific report not having been
fixed yet.

Do I encourage filing bugs without the level of detail I suggest help get bugs
fixed fast?  Absolutely.  An un-filed bug is an un-fixed bug.

Take these points as ways to help make sure your important issues can be
addressed quickly and easily.

Later,
Brad
May 10 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Brad Roberts, el 10 de mayo a las 16:08 me escribiste:

 Leandro Lucarella wrote:
 

 I reported the bug because I think that could be the case. If is not, it's
 a Gold bug and it should be reported. If it is, it should be fixed in DMD.
 I don't have the knowlegde to check that myself, and that's why I reported
 the bug to both tools.
 

 In other words, it's not at all surprising to me that the bug report
 hasn't received a lot of attention yet.


 
 So you are saying you have to be a compiler hacker to report a bug? Great,
 that make sense!


 
 You seem to have missed my point.  The point was, the more detailed the report,
 the clearer the steps to reproduce, the more obvious it is that the compiler is
 what's broken.. all of these things increase the likelihood of a bug report
 having a higher priority.
 
 The incoming rate is higher than the fix rate (as evidenced by the number of
 open bugs) and so something has to give.  All I was doing was illustrating some
 reasons that might have contributed to that specific report not having been
 fixed yet.
 
 Do I encourage filing bugs without the level of detail I suggest help get bugs
 fixed fast?  Absolutely.  An un-filed bug is an un-fixed bug.
 
 Take these points as ways to help make sure your important issues can be
 addressed quickly and easily.


I totally agree, but you put my bug report as an example of a bad bug
report. I don't think it is a bad bug report, so please let me know if you
think I can improve it without being a compiler hacker.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
He used to do surgery
On girls in the eighties
But gravity always wins
May 10 2009
prev sibling parent reply "Ameer Armaly" <ameer.armaly furman.edu> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20090509161148.GA23213 homero.springfield.home...

 The Tango vs. Phobos is still a *BIG* issue for D1. I think don't
 addressing that is a huge error. It's only hurting D1 and preventing its
 adoption.


Yes. This is the showstopper for me and what caused me to quietly walk away 
from D to begin with. In my opinion the fact that having two runtimes is not 
only tolerable but acceptable as normal has and will continue to hurt D1. We 
have Phobos, the "official" runtime and then we have Tango, the "community" 
runtime. Moreover having two runtimes casts doubt on the state of D as a 
whole; if we can't even decide on a uniform runtime then people will wonder 
what other unknown traps of incompleteness are in store. The fact that 
nobody bothered to work all this out makes perfect sense- it's a lot more 
fun to be hashing out new features- but if we intend to gain some semblance 
of mainstream respect then it will be much easier with a single robust 
runtime.

Ameer
May 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ameer Armaly wrote:

 Yes. This is the showstopper for me and what caused me to quietly walk away 
 from D to begin with. In my opinion the fact that having two runtimes is not 
 only tolerable but acceptable as normal has and will continue to hurt D1. We 
 have Phobos, the "official" runtime and then we have Tango, the "community" 
 runtime. Moreover having two runtimes casts doubt on the state of D as a 
 whole; if we can't even decide on a uniform runtime then people will wonder 
 what other unknown traps of incompleteness are in store. The fact that 
 nobody bothered to work all this out makes perfect sense- it's a lot more 
 fun to be hashing out new features- but if we intend to gain some semblance 
 of mainstream respect then it will be much easier with a single robust 
 runtime.


It has been bashed out for D2. Doing such changes to D1 will break 
everyone's D1 code, which destroys its mission of being stable.
May 11 2009
parent reply "Ameer Armaly" <ameer.armaly furman.edu> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gua3u3$19c1$2 digitalmars.com...

 Ameer Armaly wrote:

 Yes. This is the showstopper for me and what caused me to quietly walk 
 away from D to begin with. In my opinion the fact that having two 
 runtimes is not only tolerable but acceptable as normal has and will 
 continue to hurt D1. We have Phobos, the "official" runtime and then we 
 have Tango, the "community" runtime. Moreover having two runtimes casts 
 doubt on the state of D as a whole; if we can't even decide on a uniform 
 runtime then people will wonder what other unknown traps of 
 incompleteness are in store. The fact that nobody bothered to work all 
 this out makes perfect sense- it's a lot more fun to be hashing out new 
 features- but if we intend to gain some semblance of mainstream respect 
 then it will be much easier with a single robust runtime.


 It has been bashed out for D2. Doing such changes to D1 will break 
 everyone's D1 code, which destroys its mission of being stable.


Really? I was under the impression that Tango will be ported to D2 to 
continue the battle of standard libs but if I'm mistaken, then it's a lot 
better than I originally figured.
May 11 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Ameer Armaly Wrote:


 
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:gua3u3$19c1$2 digitalmars.com...

 Ameer Armaly wrote:

 Yes. This is the showstopper for me and what caused me to quietly walk 
 away from D to begin with. In my opinion the fact that having two 
 runtimes is not only tolerable but acceptable as normal has and will 
 continue to hurt D1. We have Phobos, the "official" runtime and then we 
 have Tango, the "community" runtime. Moreover having two runtimes casts 
 doubt on the state of D as a whole; if we can't even decide on a uniform 
 runtime then people will wonder what other unknown traps of 
 incompleteness are in store. The fact that nobody bothered to work all 
 this out makes perfect sense- it's a lot more fun to be hashing out new 
 features- but if we intend to gain some semblance of mainstream respect 
 then it will be much easier with a single robust runtime.


 It has been bashed out for D2. Doing such changes to D1 will break 
 everyone's D1 code, which destroys its mission of being stable.


 Really? I was under the impression that Tango will be ported to D2 to 
 continue the battle of standard libs but if I'm mistaken, then it's a lot 
 better than I originally figured. 


The druntime project is mostly a port of the Tango runtime to D2. On top of
that, Don has ported the Tango math stuff to D2 Phobos. The stage is set for D2
Tango to be smaller and be installed alongside Phobos in D2.

There really is only three reasons I'm aware of that stop D2 Tango from
existing today:
1. There is no practical way to write code that compiles with both D1 and D2
2.  There are bugs that limit how easily Tango can be ported to D2
3. D2 is a moving target


make D2 a reality.
May 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:

 There really is only three reasons I'm aware of that stop D2 Tango
 from existing today:
 [...]
 2.  There are bugs that limit how easily Tango can be ported to D2



I've heard this now and then, along with a bugzilla number or two. I've 
fixed every one those problems brought to my attention weeks (months?) ago.

If there are other bugzilla issues that prevent Tango from working with 
D2, please let me know what they are.
May 11 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:


 Jason House wrote:

 There really is only three reasons I'm aware of that stop D2 Tango
 from existing today:


  > [...]

 2.  There are bugs that limit how easily Tango can be ported to D2


 
 
 I've heard this now and then, along with a bugzilla number or two. I've 
 fixed every one those problems brought to my attention weeks (months?) ago.
 
 If there are other bugzilla issues that prevent Tango from working with 
 D2, please let me know what they are.
 


Obviously, Tango devs should answer, but...
IIRC, the whole "return const" thing is still an issue
May 11 2009
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Jason House (jason.james.house gmail.com)'s article

 Walter Bright Wrote:

 Jason House wrote:

 There really is only three reasons I'm aware of that stop D2 Tango
 from existing today:


  > [...]

 2.  There are bugs that limit how easily Tango can be ported to D2



 I've heard this now and then, along with a bugzilla number or two. I've
 fixed every one those problems brought to my attention weeks (months?) ago.

 If there are other bugzilla issues that prevent Tango from working with
 D2, please let me know what they are.


 Obviously, Tango devs should answer, but...
 IIRC, the whole "return const" thing is still an issue


Yeah, I can see why noone wanted to design a half-baked solution to this before
shared was implemented, since that's going to need a similar fix.  Shared is
coming next release.  Therefore, I think it will soon be high time to address
this
issue.
May 11 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ameer Armaly wrote:

 It has been bashed out for D2. Doing such changes to D1 will break 
 everyone's D1 code, which destroys its mission of being stable.


 Really? I was under the impression that Tango will be ported to D2 to 
 continue the battle of standard libs but if I'm mistaken, then it's a lot 
 better than I originally figured. 


D2 has the "druntime" core which is designed to be the common root of 
Phobos and Tango. Switching to it involved a lot of changes to Phobos 
that broke existing user code.
May 11 2009
parent reply "Ameer Armaly" <ameer.armaly furman.edu> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:guafcv$1tmg$3 digitalmars.com...

 Ameer Armaly wrote:

 It has been bashed out for D2. Doing such changes to D1 will break 
 everyone's D1 code, which destroys its mission of being stable.


 Really? I was under the impression that Tango will be ported to D2 to 
 continue the battle of standard libs but if I'm mistaken, then it's a lot 
 better than I originally figured.


 D2 has the "druntime" core which is designed to be the common root of 
 Phobos and Tango. Switching to it involved a lot of changes to Phobos that 
 broke existing user code.


I see. What about the actual "standard library bits" for common tasks like 
file I/O, strings, date and time, filesystem manipulation, etc. My main 
gripe is having two regularly accepted libraries that do the same extremely 
common functions; it makes us look unpolished, especially when there is the 
"community" versus "official" difference I mentioned earlier. Why not just 
merge the two libraries into the one D standard library and be done with it? 
I have yet to see a language with two standard libraries like we have now. 
[1] Thanks though for what's already been done.

Ameer

[1] I haven't really seen that many though- probably about a dozen.
May 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ameer Armaly wrote:

 I see. What about the actual "standard library bits" for common tasks like 
 file I/O, strings, date and time, filesystem manipulation, etc. My main 
 gripe is having two regularly accepted libraries that do the same extremely 
 common functions; it makes us look unpolished, especially when there is the 
 "community" versus "official" difference I mentioned earlier. Why not just 
 merge the two libraries into the one D standard library and be done with it?


That's being done for D2. It is not for D1, as that would break 
everyone's code.
May 11 2009
next sibling parent "Ameer Armaly" <ameer.armaly furman.edu> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:guakkp$285n$1 digitalmars.com...

 Ameer Armaly wrote:

 I see. What about the actual "standard library bits" for common tasks 
 like file I/O, strings, date and time, filesystem manipulation, etc. My 
 main gripe is having two regularly accepted libraries that do the same 
 extremely common functions; it makes us look unpolished, especially when 
 there is the "community" versus "official" difference I mentioned 
 earlier. Why not just merge the two libraries into the one D standard 
 library and be done with it?


 That's being done for D2. It is not for D1, as that would break everyone's 
 code.


Ah. If we're aiming for one standard library, then I'll shut up and try and 
understand const.
May 11 2009
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:

 Ameer Armaly wrote:

 I see. What about the actual "standard library bits" for common tasks
 like file I/O, strings, date and time, filesystem manipulation, etc.
 My main gripe is having two regularly accepted libraries that do the
 same extremely common functions; it makes us look unpolished,
 especially when there is the "community" versus "official" difference
 I mentioned earlier. Why not just merge the two libraries into the one
 D standard library and be done with it?


 
 That's being done for D2. It is not for D1, as that would break
 everyone's code.


Well, one runtime library.  Anything beyond that isn't at all clear, is it?

There's some rather fundamental design differences -- neither right nor wrong --
between Phobos and Tango.  I don't see those converging at this point.

Regardless, able to sit side by side is still a big step forward.

Later,
Brad
May 11 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Steve Teale (steve.teale britseyeview.com)'s article

 OK so for those who crave stability there is D1.x, but when all the focus
appears to be on D2, what level of confidence is afforded to


D1 users. Can a project Manager cross his heart and say that D1 will still be
alive and well in five years time?

Will that project manager care?  Most build teams don't update compiler
versions very often--once a version has been settled upon that's pretty
much it, unless a show-stopping bug appears during development that
for some reason can't be worked around.  In fact, I can't even see a team
bothering to speculate about the future popularity of a language when
choosing it for a project.  The only thing that matters is whether it's a
good decision today, not five years from now.  If that weren't the case,
then there would have never been a call for COBOL programmers
during the Y2K transition.
May 08 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:

 Will that project manager care?  Most build teams don't update compiler
 versions very often--once a version has been settled upon that's pretty
 much it, unless a show-stopping bug appears during development that
 for some reason can't be worked around.  In fact, I can't even see a team
 bothering to speculate about the future popularity of a language when
 choosing it for a project.  The only thing that matters is whether it's a
 good decision today, not five years from now.  If that weren't the case,
 then there would have never been a call for COBOL programmers
 during the Y2K transition.


Back in the 80's, the company I worked for did a project in a particular 
dialect of pascal. The company making that dialect went bust, and the 
company was left holding the bag with mission critical app. The compiler 
was binary only, had bugs, required old hardware to run on, etc.

The dmd compiler source being available goes a very long way to 
alleviating such problems.

Also, any significant dev project needs to archive the compiler used to 
build it along with the project. Regardless of the language. That just 
only makes sense.
May 08 2009
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Back in the 80's, the company I worked for did a project in a particular
 dialect of pascal. The company making that dialect went bust, and the
 company was left holding the bag with mission critical app. The compiler
 was binary only, had bugs, required old hardware to run on, etc.
 The dmd compiler source being available goes a very long way to
 alleviating such problems.


Definitely.  A big build team would want the compiler source code
available to future-proof their investment.  This obviously also
supports the assertion that such teams aren't likely to upgrade
compiler versions very often :-)
May 08 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Sean Kelly wrote:

 == Quote from Steve Teale (steve.teale britseyeview.com)'s article

 OK so for those who crave stability there is D1.x, but when all the focus
appears to be on D2, what level of confidence is afforded to


 D1 users. Can a project Manager cross his heart and say that D1 will still be
alive and well in five years time?
 
 Will that project manager care?  Most build teams don't update compiler
 versions very often--once a version has been settled upon that's pretty
 much it, unless a show-stopping bug appears during development that
 for some reason can't be worked around.  In fact, I can't even see a team
 bothering to speculate about the future popularity of a language when
 choosing it for a project.  The only thing that matters is whether it's a
 good decision today, not five years from now.  If that weren't the case,
 then there would have never been a call for COBOL programmers
 during the Y2K transition.


In the Windows world, you get a new compiler every two to three years, 
so that's hardly an issue. Similarly with Java.

Open source projects tend to have to support wider ranges of compilers. 
I've seen OSS projects where they prioritized issues specific to 
gcc-3.4.2 as highly as any other issue, even if the developers typically 
used the 4.x branch.
May 08 2009
parent reply torhu <no spam.invalid> writes:
On 09.05.2009 00:29, Christopher Wright wrote:

 Open source projects tend to have to support wider ranges of compilers.
 I've seen OSS projects where they prioritized issues specific to
 gcc-3.4.2 as highly as any other issue, even if the developers typically
 used the 4.x branch.


That's probably because they wanted to be cross-platform, since 3.4.2 
was the latest GCC supported by minGw for a long time.
May 08 2009
parent Christopher Wright <dhasenan gmail.com> writes:
torhu wrote:

 On 09.05.2009 00:29, Christopher Wright wrote:

 Open source projects tend to have to support wider ranges of compilers.
 I've seen OSS projects where they prioritized issues specific to
 gcc-3.4.2 as highly as any other issue, even if the developers typically
 used the 4.x branch.


 
 That's probably because they wanted to be cross-platform, since 3.4.2 
 was the latest GCC supported by minGw for a long time.


No; there has sadly never been a release of Enlightenment DR17 for MinGW.
May 09 2009
prev sibling parent reply "Tyro[a.c.edwards]" <nospam home.com> writes:
On 5/9/2009 3:38 AM, Steve Teale wrote:

 Walter Bright Wrote:


 Steve Teale wrote:

 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".

 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.

 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.


 What bothers me about this sentiment is that every other mainstream
 language undergoes revision, sometimes major ones, but that never seems
 to be an excuse for people to not use it.

 For example, C++ is quite in flux with C++0x.

 The only languages that are not undergoing revision are dead ones.


 Yes Walter, but C++ went through a tedious standardization process - itself a
long argument. So there was some basis for people to think that it had 'got
there'.

 But to come back after 2 years and find the same stuff still going on is
depressing - been there done that. OK, it didn't put me off, I'm still in
there, but it bothers me. I'd be dishonest if I said otherwise.

 I am not criticizing you. I think you are doing a great job under the pressure
of a slew of suggestions. But maybe a line in the sand at some point?

 OK so for those who crave stability there is D1.x, but when all the focus
appears to be on D2, what level of confidence is afforded to D1 users. Can a
project Manager cross his heart and say that D1 will still be alive and well in
five years time?


This is quite interesting! Before there was D1, I can remember the same 
requests being submitted over and over again. Tool developers complained 
that they could not use D for anything serious because of its constant 
state of flux. They continuously requested that a line be drawn. 
Shortly after that line was drawn in January 2007, a good majority of 
the community complained that it wasn't exactly what they asked for and 
a majority of the most active members of the community disappeared into 
thin air.

The sad thing is, even after D1 became stable following a number of bug 
fixes, very few people used it for much of anything. Those "advocates of 
stability" all disappeared; abandoning their tools/projects in the process.

The same thing is beginning again and it seems to me that instead of 
something that is actually useful, people a waiting for MicroMoney or 
some other name brand begins to invest in their own D compiler. As far 
as I see it, there will come a time when D language will soar above all 
the rest (not only in capability, which it already does, but also 
commercial usage), I will continue to support it until then and well 
beyond and I'm quite sure that I'm not the only one. For all the 
Naysayers out there... Keep saying nay and go the hell away. D2 is just 
where it is supposed to be. Let’s not end up in the same mess we did by 
trying to make impatient people happy and releasing D1.

Andrew
May 08 2009
next sibling parent reply grauzone <none example.net> writes:
 beyond and I'm quite sure that I'm not the only one. For all the 
 Naysayers out there... Keep saying nay and go the hell away. D2 is just 
 where it is supposed to be. Let’s not end up in the same mess we did by 
 trying to make impatient people happy and releasing D1.


What about the people who want to use D for something actually useful?
May 08 2009
next sibling parent reply "Tyro[a.c.edwards]" <nospam home.com> writes:
On 5/9/2009 11:24 AM, grauzone wrote:

 beyond and I'm quite sure that I'm not the only one. For all the
 Naysayers out there... Keep saying nay and go the hell away. D2 is
 just where it is supposed to be. Let’s not end up in the same mess we
 did by trying to make impatient people happy and releasing D1.


 What about the people who want to use D for something actually useful?


Well, for those cases, there is D1. Which, if I may add, is extremely 
stable. Take a network administrator running his server or firewall on 
say DragonFly or any of the many flavors of BSD or Linux; he does not 
upgrade his server with nightly builds, he sticks instead with a 
"stable," well tested branch of the OS and experiments with "current." 
When current becomes stable, the OS developer does not stop developing 
his OS, he continues on with his vision while the "users" further 
stress-tests the newly stabilized branch and take steps to find and 
correct any holes in the system. And our system administrator, well, he 
doesn't switch until he is comfortable that the newly stabilized branch 
meets all his criteria for upgrade. If they are not met... he waits 
until the OS branches again.

We cannot expect the compiler developer to stop developing compilers 
until after the tools developers decide to build tools. He has done his 
job, which is to develop a stable, documented compiler. Use it to 
develop your tools which will in turn allow the compiler/language to 
gain popularity. Report any bug reports on anything that seems out of 
the ordinary so that it can either be clarified in documentation or 
corrected with code.

Walter is a damn good Engineer but I don't think his interests lie in 
writing tools (IDE and the like). So those people that do write those 
tools may want to take the "stable" compiler and start developing. So 
what if this feature "that is in D2" is not in D1? Use what you have in 
D1 and develop your tools and simply stay abreast with the development 
of D2 so that when it is time to switch, you are not in the dark.

Andrew
May 08 2009
parent Christopher Wright <dhasenan gmail.com> writes:
Tyro[a.c.edwards] wrote:

 On 5/9/2009 11:24 AM, grauzone wrote:

 beyond and I'm quite sure that I'm not the only one. For all the
 Naysayers out there... Keep saying nay and go the hell away. D2 is
 just where it is supposed to be. Let’s not end up in the same mess we
 did by trying to make impatient people happy and releasing D1.


 What about the people who want to use D for something actually useful?


 
 Well, for those cases, there is D1. Which, if I may add, is extremely 
 stable.


Agreed -- I haven't had to update my D1 code due to compiler changes, 
even if it's over a year old. Only library changes force me to update 
it. The only reason I bother updating my compiler is because of bugfixes 
and Tango updates which require those bugfixes.
May 09 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:

 beyond and I'm quite sure that I'm not the only one. For all the 
 Naysayers out there... Keep saying nay and go the hell away. D2 is 
 just where it is supposed to be. Let’s not end up in the same mess we 
 did by trying to make impatient people happy and releasing D1.


 
 What about the people who want to use D for something actually useful?


They can if they really want, just as much as others can keep on 
naysaying if they really want :o).

Andrei
May 08 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Tyro[a.c.edwards] wrote:

 On 5/9/2009 3:38 AM, Steve Teale wrote:

 Walter Bright Wrote:


 Steve Teale wrote:

 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".

 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.

 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.


 What bothers me about this sentiment is that every other mainstream
 language undergoes revision, sometimes major ones, but that never seems
 to be an excuse for people to not use it.

 For example, C++ is quite in flux with C++0x.

 The only languages that are not undergoing revision are dead ones.


 Yes Walter, but C++ went through a tedious standardization process - 
 itself a long argument. So there was some basis for people to think 
 that it had 'got there'.

 But to come back after 2 years and find the same stuff still going on 
 is depressing - been there done that. OK, it didn't put me off, I'm 
 still in there, but it bothers me. I'd be dishonest if I said otherwise.

 I am not criticizing you. I think you are doing a great job under the 
 pressure of a slew of suggestions. But maybe a line in the sand at 
 some point?

 OK so for those who crave stability there is D1.x, but when all the 
 focus appears to be on D2, what level of confidence is afforded to D1 
 users. Can a project Manager cross his heart and say that D1 will 
 still be alive and well in five years time?


 
 This is quite interesting! Before there was D1, I can remember the same 
 requests being submitted over and over again. Tool developers complained 
 that they could not use D for anything serious because of its constant 
 state of flux. They continuously requested that a line be drawn. Shortly 
 after that line was drawn in January 2007, a good majority of the 
 community complained that it wasn't exactly what they asked for and a 
 majority of the most active members of the community disappeared into 
 thin air.
 
 The sad thing is, even after D1 became stable following a number of bug 
 fixes, very few people used it for much of anything. Those "advocates of 
 stability" all disappeared; abandoning their tools/projects in the process.
 
 The same thing is beginning again and it seems to me that instead of 
 something that is actually useful, people a waiting for MicroMoney or 
 some other name brand begins to invest in their own D compiler. As far 
 as I see it, there will come a time when D language will soar above all 
 the rest (not only in capability, which it already does, but also 
 commercial usage), I will continue to support it until then and well 
 beyond and I'm quite sure that I'm not the only one. For all the 
 Naysayers out there... Keep saying nay and go the hell away. D2 is just 
 where it is supposed to be. Let’s not end up in the same mess we did by 
 trying to make impatient people happy and releasing D1.
 
 Andrew


Very well and heartfelt put.

D needs many things, but probably above all it needs the dedication of 
bright people.

I've had a great time at BoostCon, and enjoyed many interesting 
conversations with as many bright people. Beman Dawes, the originator of 
Boost and an extraordinary gentleman, gave me a little history of Boost. 
Essentially Boost has been toiling in anonymity until Dave Abrahams came 
about. Dave is a design, coding, and organizational powerhouse all in 
one. He not only contributed a great deal of design and code to Boost, 
but also managed organizational and logistics aspects, in addition to 
exercising the charisma necessary for attracting other extraordinarily 
qualified people to dedicate their prime to Boost. And it has snowballed 
ever since. It was amazing just being at Boostcon to see how much 
expertise punch those people packed.

We are lacking such a powerhouse for D. Walter is a great lone wolf kind 
of coder, but not a team organizer and charismatic leader. Things have 
been changed to the better since he has made Phobos accessible on 
dsource.org and since he released the source of the compiler. 
Integration with druntime was another great step forward (thanks Sean!) 
Soon we may convince Walter to put the entire dmd source on dsource.org, 
which would improve things even more. But the role of "Dave" for D is 
still up for grabs.

Of course it's not that easy to find that, but in the meantime there's a 
lot of good things to be done. If you do something great, sooner or 
later it will be picked up. The perfect example is Don, who became a 
prominent contributor solely through the sheer quality and quantity of 
his work. (There are many others that come to mind, but please allow me 
to stay with one because as soon as I mention more than one, I'd feel 
I'm unjust to others that I might even forget for the moment.)

So what I think D really needs is your heart and soul :o). Let me 
(re)try to make a step in that direction by reopening the Phobos czar 
position. Gregor Richards has held that position for a while but hasn't 
done anything with it. (I'm not saying this with reproach; Gregor has 
been busy with school and if I don't know what that means...) I can 
hardly imagine what someone like Dave could do with that role. So if 
anyone is interested, speak up!


Andrei
May 08 2009
parent Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:


 Tyro[a.c.edwards] wrote:

 On 5/9/2009 3:38 AM, Steve Teale wrote:

 Walter Bright Wrote:


 Steve Teale wrote:

 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".

 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.

 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.


 What bothers me about this sentiment is that every other mainstream
 language undergoes revision, sometimes major ones, but that never seems
 to be an excuse for people to not use it.

 For example, C++ is quite in flux with C++0x.

 The only languages that are not undergoing revision are dead ones.


 Yes Walter, but C++ went through a tedious standardization process - 
 itself a long argument. So there was some basis for people to think 
 that it had 'got there'.

 But to come back after 2 years and find the same stuff still going on 
 is depressing - been there done that. OK, it didn't put me off, I'm 
 still in there, but it bothers me. I'd be dishonest if I said otherwise.

 I am not criticizing you. I think you are doing a great job under the 
 pressure of a slew of suggestions. But maybe a line in the sand at 
 some point?

 OK so for those who crave stability there is D1.x, but when all the 
 focus appears to be on D2, what level of confidence is afforded to D1 
 users. Can a project Manager cross his heart and say that D1 will 
 still be alive and well in five years time?


 
 This is quite interesting! Before there was D1, I can remember the same 
 requests being submitted over and over again. Tool developers complained 
 that they could not use D for anything serious because of its constant 
 state of flux. They continuously requested that a line be drawn. Shortly 
 after that line was drawn in January 2007, a good majority of the 
 community complained that it wasn't exactly what they asked for and a 
 majority of the most active members of the community disappeared into 
 thin air.
 
 The sad thing is, even after D1 became stable following a number of bug 
 fixes, very few people used it for much of anything. Those "advocates of 
 stability" all disappeared; abandoning their tools/projects in the process.
 
 The same thing is beginning again and it seems to me that instead of 
 something that is actually useful, people a waiting for MicroMoney or 
 some other name brand begins to invest in their own D compiler. As far 
 as I see it, there will come a time when D language will soar above all 
 the rest (not only in capability, which it already does, but also 
 commercial usage), I will continue to support it until then and well 
 beyond and I'm quite sure that I'm not the only one. For all the 
 Naysayers out there... Keep saying nay and go the hell away. D2 is just 
 where it is supposed to be. Let’s not end up in the same mess we did by 
 trying to make impatient people happy and releasing D1.
 
 Andrew


 
 Very well and heartfelt put.
 
 D needs many things, but probably above all it needs the dedication of 
 bright people.
 
 I've had a great time at BoostCon, and enjoyed many interesting 
 conversations with as many bright people. Beman Dawes, the originator of 
 Boost and an extraordinary gentleman, gave me a little history of Boost. 
 Essentially Boost has been toiling in anonymity until Dave Abrahams came 
 about. Dave is a design, coding, and organizational powerhouse all in 
 one. He not only contributed a great deal of design and code to Boost, 
 but also managed organizational and logistics aspects, in addition to 
 exercising the charisma necessary for attracting other extraordinarily 
 qualified people to dedicate their prime to Boost. 


That's a rather rare find. Typically, that would require the contribution of
many individuals to achieve the same effect. Even if you only consider the time
required to do all that, it can be a tall order!



 And it has snowballed 
 ever since. It was amazing just being at Boostcon to see how much 
 expertise punch those people packed.
 
 We are lacking such a powerhouse for D. Walter is a great lone wolf kind 
 of coder, but not a team organizer and charismatic leader. Things have 
 been changed to the better since he has made Phobos accessible on 
 dsource.org and since he released the source of the compiler. 
 Integration with druntime was another great step forward (thanks Sean!) 
 Soon we may convince Walter to put the entire dmd source on dsource.org, 
 which would improve things even more. 


I've been hoping for that! I tried to create a thread about that a while back,
but it passed silently into oblivion.



 But the role of "Dave" for D is 
 still up for grabs.
 
 Of course it's not that easy to find that, but in the meantime there's a 
 lot of good things to be done. If you do something great, sooner or 
 later it will be picked up. The perfect example is Don, who became a 
 prominent contributor solely through the sheer quality and quantity of 
 his work. (There are many others that come to mind, but please allow me 
 to stay with one because as soon as I mention more than one, I'd feel 
 I'm unjust to others that I might even forget for the moment.)
 
 So what I think D really needs is your heart and soul :o). Let me 
 (re)try to make a step in that direction by reopening the Phobos czar 
 position. Gregor Richards has held that position for a while but hasn't 
 done anything with it. (I'm not saying this with reproach; Gregor has 
 been busy with school and if I don't know what that means...) I can 
 hardly imagine what someone like Dave could do with that role. So if 
 anyone is interested, speak up!



Like many, I can't become a/the czar, but will slowly contribute from the
sidelines. I submitted a weak reference library for druntime and am now working
on a high throughput lockless hashmap.
 

 
 Andrei
May 09 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 Steve Teale wrote:

 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".

 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.

 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.


 What bothers me about this sentiment is that every other mainstream
 language undergoes revision, sometimes major ones, but that never seems
 to be an excuse for people to not use it.
 For example, C++ is quite in flux with C++0x.
 The only languages that are not undergoing revision are dead ones.


Exactly my feelings, but I'll add that the time to make huge, sweeping changes
like the ones we're seeing now is before the language becomes mainstream.  Once
the language has a large base of crufty production code that nobody still
understands and can fix quickly and easily when the language changes, it becomes
much harder to make these kinds of changes.
May 08 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:

 Exactly my feelings, but I'll add that the time to make huge, sweeping changes
 like the ones we're seeing now is before the language becomes mainstream.  Once
 the language has a large base of crufty production code that nobody still
 understands and can fix quickly and easily when the language changes, it
becomes
 much harder to make these kinds of changes.


Yes.

The next D2 update will have one such change, which has been planned for 
maybe the past year. All static and global variables will default to 
being thread local (instead of being implicitly shared). Doing this is 
disruptive, but is critical to credibly supporting multithreaded 
programming.

In testing this out, I've uncovered at least a dozen implicit sharing 
bugs in Phobos. I think this change will have a big payoff for 
multithreaded code.
May 08 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article

 dsimcha wrote:

 Exactly my feelings, but I'll add that the time to make huge, sweeping changes
 like the ones we're seeing now is before the language becomes mainstream.  Once
 the language has a large base of crufty production code that nobody still
 understands and can fix quickly and easily when the language changes, it
becomes
 much harder to make these kinds of changes.


 Yes.
 The next D2 update will have one such change, which has been planned for
 maybe the past year. All static and global variables will default to
 being thread local (instead of being implicitly shared). Doing this is
 disruptive, but is critical to credibly supporting multithreaded
 programming.
 In testing this out, I've uncovered at least a dozen implicit sharing
 bugs in Phobos. I think this change will have a big payoff for
 multithreaded code.


Awesome.  I actually found a few of these bugs in the past few days, and was
meaning to report them.  I guess I don't need to now.  Just out of curiosity,
though, you use __gshared in a lot of places and I haven't seen it in any of the
discussions.  What is it?
May 08 2009
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from dsimcha (dsimcha yahoo.com)'s article

 Awesome.  I actually found a few of these bugs in the past few days, and was
 meaning to report them.  I guess I don't need to now.  Just out of curiosity,
 though, you use __gshared in a lot of places and I haven't seen it in any of
the
 discussions.  What is it?


It's a way to declare something as "classic global" so you can sidestep any bugs
that crop up with the implementation of 'shared'.  The hope is that you'll
eventually just be able to do a search/replace of '__gshared' to 'shared' once
everything is working correctly.
May 08 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:

 It's a way to declare something as "classic global" so you can sidestep any
bugs
 that crop up with the implementation of 'shared'.  The hope is that you'll
 eventually just be able to do a search/replace of '__gshared' to 'shared' once
 everything is working correctly.


I like the moniker "classic global", or perhaps even better, "global 
classic" as a term for it.
May 08 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:

 Just out of curiosity,
 though, you use __gshared in a lot of places and I haven't seen it in any of
the
 discussions.  What is it?


__gshared is the "cowboy" approach, it means make it global and I don't 
care about any weenie synchronization or type checking. It's handy for 
initial ports of "I just want it to compile, I'll fix it later".

Naturally, it won't be allowed in safe mode.
May 08 2009
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Walter Bright schrieb:

 dsimcha wrote:

 Exactly my feelings, but I'll add that the time to make huge, sweeping
 changes
 like the ones we're seeing now is before the language becomes
 mainstream.  Once
 the language has a large base of crufty production code that nobody still
 understands and can fix quickly and easily when the language changes,
 it becomes
 much harder to make these kinds of changes.


 
 Yes.
 
 The next D2 update will have one such change, which has been planned for
 maybe the past year. All static and global variables will default to
 being thread local (instead of being implicitly shared). Doing this is
 disruptive, but is critical to credibly supporting multithreaded
 programming.
 
 In testing this out, I've uncovered at least a dozen implicit sharing
 bugs in Phobos. I think this change will have a big payoff for
 multithreaded code.


can you allow "shared" or "__gshared" in D1 as do-nothing keywords? That
will make it more easy to write code that compiles for D1 and D2.
Or is there a trick to accomplish this?
May 08 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Frank Benoit wrote:

 can you allow "shared" or "__gshared" in D1 as do-nothing keywords? That
 will make it more easy to write code that compiles for D1 and D2.
 Or is there a trick to accomplish this?


I think that making code that will compile under both is an impractical 
task.
May 08 2009
parent Derek Parnell <derek psych.ward> writes:
On Fri, 08 May 2009 16:20:48 -0700, Walter Bright wrote:


 Frank Benoit wrote:

 can you allow "shared" or "__gshared" in D1 as do-nothing keywords? That
 will make it more easy to write code that compiles for D1 and D2.
 Or is there a trick to accomplish this?


 
 I think that making code that will compile under both is an impractical 
 task.


I'm thinking that D1 is really the prototype edition of D, and D2 will be
the first release edition of the "D Programming Language". By this I mean
that D1 has worked out to be a sounding board that has helped define what
the design requirements for "D" have really been. The process is not over
as usage of D1 is still pointing out things that need to be in D2.

This is a good thing. And if we end up with two languages (D1=D_proto and
D2=D_proper) in which both are stable, then that is not such a bad outcome.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 08 2009
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:


 Steve Teale wrote:

 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".
 
 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.
 
 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.


 
 What bothers me about this sentiment is that every other mainstream
 language undergoes revision, sometimes major ones, but that never seems
 to be an excuse for people to not use it.
 
 For example, C++ is quite in flux with C++0x.
 
 The only languages that are not undergoing revision are dead ones.


There are some differences though:

- other mainstream languages release new compilers and features every couple 
of years, you do so every couple of months!

- these other languages go out of their way to make new releases backwards 
compatible, sometimes at great costs. They almost never completely succeed 
though.

To be clear, I do think these are good things for D evolution, but most 
people are wary to invest energy in change. Reflecting back on the 
commitment to D1, I think this was a good move in two ways: it allowed 
larger programs and libraries to rely on it and may have freed the way for 
D2 to incorporate bolder changes.
May 08 2009
next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Lutger wrote:

 - other mainstream languages release new compilers and features every couple 
 of years, you do so every couple of months!


Rapid evolution is a good thing.  For every improvement that will be
made to the D2 language, I'd rather see that improvement in a week than
in a couple of years.  *Especially* for improvements that break
backwards compatibility.

D2 is incomplete right now.  The faster it evolves, the sooner it'll
reach completion, at which point it should be as stable as any language.


-- 
Rainer Deyke - rainerd eldwood.com
May 08 2009
prev sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Lutger wrote:


 - these other languages go out of their way to make new releases  
 backwards
 compatible, sometimes at great costs. They almost never completely  
 succeed
 though.


And D1 makes an effort to follow the spec, and will not incorporate
breaking changes. D2 is, in many ways, a whole new language. Sure,
you could argue that D1 code should be compilable in D2, but it
would matter no more than the argument that C code should be
compilable in D1.

--
  Simen
May 08 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
Simen Kjaeraas wrote:


 Lutger wrote:
 

 - these other languages go out of their way to make new releases  
 backwards
 compatible, sometimes at great costs. They almost never completely  
 succeed
 though.


 
 And D1 makes an effort to follow the spec, and will not incorporate
 breaking changes. D2 is, in many ways, a whole new language. Sure,
 you could argue that D1 code should be compilable in D2, but it
 would matter no more than the argument that C code should be
 compilable in D1.
 
 --
   Simen


I'm certainly not making that argument. In the talk Andrei and Walter gave 
at the D conference they mentioned the design goal 'no issue left behind' 
This is what makes D evolution so much more interesting. 


(C is not fair, too old): you can easily upgrade from 2.0 to 3.5 and beyond. 
Most important part of that ease is the ability to use older libraries in a
May 08 2009
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Steve,


 BCS Wrote:
 

 Hello Ameer,
 

 Hi all.
 When I last used D a couple years ago, 2.0 was the experimental
 branch and
 1.0 was stable.


 still true
 

 Now that I have a little time on my hands I'm wondering: what is the
 current landscape? Is 2.0 approaching any sort of stability?
 


 the const system is stable and now it's starting to play with
 threading
 

 Are
 there still two competing runtime libraries or have they been
 merged?


 No not for 1.0 (and they never will be) but /when/ Tango gets ported
 to 2.0 they will coexist.
 

 Basically I want to know if it's worth using 2.0 for anything of
 importance
 or is it still in flux?


 Don't use it for bet-the-bank code. Use it for, fun-n-games code.
 Between them, it's up to you.
 

 Thanks,
 Ameer




 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".


What, should I lie? Of am I smoking something? If what I said is true and 
will kill D than we need to fix something. (that said...)


 
 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.
 


I don't see how that can be done. For people to use it there needs to be 
a stable platform to work with. For it to evolve it needs to be able to make 
breaking changers. These fundamentally conflict. The only solution I can 
see is that D1.0 is the first and should be used for things that need stability 
and 2.0 is the evolving version and shouldn't be used for things that need 
stability until it stabilizes.

How would you have it done?
May 08 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Steve Teale wrote:

 This is the sort of answer that will kill D. The guy comes back after 2 years,
asks a straight question, and get's told "business as usual, we're still
arguing among ourselves about what it should be".


Last week I asked Andrei what DMD2/Phobos to use, looking for something 
stable. I wanted to use D2, but he couldn't answer that question. So why 
is it a problem to give this person an honest answer?

I don't want D2 to be a rush job. Cool things are happening with it. I 
am, however, impatient for it to be stable, but I'm not upset that it 
isn't. It just means I won't use D2 for most of my projects just yet.
May 08 2009
prev sibling next sibling parent reply F <x y.com> writes:
I agree. Yes, I still use D/D2 for my home-based projects and not in my work.
So, you could say it is (still) a toy. But, with every release and bug fix, it
becomes better and better language. I upgrade to the new release with joy, but
I am not forced to do so if that will break my code.

Finally, new releases are provided as optional, not as compulsory. If someone
wants to stick with one compiler version, he/she could do the job with that
version and that's all.

I don't think stability should become an obstacle in looking for better. Life
evolves, compilers and languages should do that too. It is us, people, which
should come at length with that truth.



Walter Bright Wrote:


 Steve Teale wrote:

 This is the sort of answer that will kill D. The guy comes back after
 2 years, asks a straight question, and get's told "business as usual,
 we're still arguing among ourselves about what it should be".
 
 Maybe Tiobe is right! Lots of others may not even bother to ask. They
 just visit the newsgroup, read a page of it, and conclude "same old,
 same old", and go away.
 
 D should be D, not maybe 1.043, or let's wait a while and see what
 happens with D2. Potential real users hate uncertainty. If they are
 going to commit, then D must do so too.


 
 What bothers me about this sentiment is that every other mainstream 
 language undergoes revision, sometimes major ones, but that never seems 
 to be an excuse for people to not use it.
 
 For example, C++ is quite in flux with C++0x.
 
 The only languages that are not undergoing revision are dead ones.
May 08 2009
parent reply BCS <ao pathlink.com> writes:
Reply to F,


 Finally, new releases are provided as optional, not as compulsory. If
 someone wants to stick with one compiler version, he/she could do the
 job with that version and that's all.
 


The one issue with that re 2.0 is that you can be faced with choosing between 
working thought a breaking change or not getting bug fixes ever again.
May 08 2009
parent Don <nospam nospam.com> writes:
BCS wrote:

 Reply to F,
 

 Finally, new releases are provided as optional, not as compulsory. If
 someone wants to stick with one compiler version, he/she could do the
 job with that version and that's all.


 
 The one issue with that re 2.0 is that you can be faced with choosing 
 between working thought a breaking change or not getting bug fixes ever 
 again.
 
 


Yes, but there's no way it would make sense to standardize on a 
particular release of D2 -- it's still in way too much of an alpha 
state. In another six months, I think it would make sense.
May 09 2009
prev sibling next sibling parent reply mpt <mpt ikikiki.fi> writes:
I keep making 2 mistakes in my D programs, and fixing them feels
troublesome.

1. Null references. I get a segfault and gdb is useless (ldc thing maybe).
2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
the real cause of error.

Shouldn't there be an automatic null check for references and stack
traces? Sometimes I think I'm using the wrong tool as others have
solutions for these.
May 09 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"mpt" <mpt ikikiki.fi> wrote in message 
news:gu4unq$16e2$1 digitalmars.com...

I keep making 2 mistakes in my D programs, and fixing them feels
 troublesome.

 1. Null references. I get a segfault and gdb is useless (ldc thing maybe).
 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
 the real cause of error.

 Shouldn't there be an automatic null check for references and stack
 traces? Sometimes I think I'm using the wrong tool as others have
 solutions for these.


These are two very common complaints, and there has been a lot of disussion 
about both. Hopefully they'll get taken care of.
May 09 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gu51vu$1e2f$1 digitalmars.com...

 "mpt" <mpt ikikiki.fi> wrote in message 
 news:gu4unq$16e2$1 digitalmars.com...

I keep making 2 mistakes in my D programs, and fixing them feels
 troublesome.

 1. Null references. I get a segfault and gdb is useless (ldc thing 
 maybe).
 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
 the real cause of error.

 Shouldn't there be an automatic null check for references and stack
 traces? Sometimes I think I'm using the wrong tool as others have
 solutions for these.


 These are two very common complaints, and there has been a lot of 
 disussion about both. Hopefully they'll get taken care of.


To elaborate:

Pretty much everyone agrees we need stack traces on exceptions. I'm actually 
kind of surprised DMD still doesn't have them, I wouldn't think it would be 
a real major change (at least compared to some other things). IIRC, I think 
the Linux LDC already has this feature.

About the null references, most people seem to agree that the right way to 
fix that is with some sort of "non-nullable". But there's a lot of 
disagreement on exactly how non-nullables should work.
May 09 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
Nick Sabalausky wrote:

 About the null references, most people seem to agree that the right way to 
 fix that is with some sort of "non-nullable". But there's a lot of 
 disagreement on exactly how non-nullables should work.


And whether they *can* work. D2 has struct constructors, so structs can 
have non-nullable fields, but you can't have an array of non-nullable 
elements (you can set the length, and suddenly your non-nullable-element 
array has a bunch of nulls in it). Similarly, no arrays of structs 
containing non-nullable types, etc.

There are a lot of things to look into with non-nullables, and Walter 
doesn't have the time.
May 10 2009
parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Christopher Wright wrote:


 About the null references, most people seem to agree that the right way
 to fix that is with some sort of "non-nullable". But there's a lot of
 disagreement on exactly how non-nullables should work.


 
 And whether they *can* work. D2 has struct constructors, so structs can
 have non-nullable fields, but you can't have an array of non-nullable
 elements (you can set the length, and suddenly your non-nullable-element
 array has a bunch of nulls in it). Similarly, no arrays of structs
 containing non-nullable types, etc.


The point of non-nullables would be to detect improper usage at
compile-time, right? Then I don't believe this problem has an elegant
solution until compilers can do a rigorous control-flow analysis.
Specifying default pointer values other than null doesn't seem very nice.

Nonetheless, a good step forward would be to recognize the distinction
between `null' and `uninitialized'. Reading a variable that's uninitialized
is an error. Reading a null pointer is fine, but dereferencing it is an
error.

This effectively solves your non-nullable problems, but you'd basically be
replacing them with another problem. In general, you can only know if a
variable is initialized at run-time. And then only if you reserve memory
for the `uninitialized' state.

So effectively, what's the difference between that and the original null
reference problem? You'd basically get the runtime error when you read the
pointer, but before you dereference it.

Until compilers are smart enough.

-- 
Michiel Helvensteijn
May 10 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Michiel Helvensteijn wrote:

 ...
 
 The point of non-nullables would be to detect improper usage at
 compile-time, right? Then I don't believe this problem has an elegant
 solution until compilers can do a rigorous control-flow analysis.
 Specifying default pointer values other than null doesn't seem very nice.


You don't need control-flow analysis.  You just need a type system which
supports nullables like D2's supports const.


 Nonetheless, a good step forward would be to recognize the distinction
 between `null' and `uninitialized'. Reading a variable that's uninitialized
 is an error. Reading a null pointer is fine, but dereferencing it is an
 error.


Uninitialised variables is only a symptom.  The larger issue is that it
doesn't make sense for most functions to accept null object arguments.
It's quite rare, at least in my code, to have a function that can do
anything sensible with "nothing" other than HCF [1].


 This effectively solves your non-nullable problems, but you'd basically be
 replacing them with another problem.


No, it doesn't.


 ...
 
 So effectively, what's the difference between that and the original null
 reference problem? You'd basically get the runtime error when you read the
 pointer, but before you dereference it.
 
 Until compilers are smart enough.


The whole point of having non-nullable types is so that you can't even
STORE a null in the first place.  We already have a runtime check, and
it's not good enough.  The major issue is that it notifies us of a
problem at a time when we generally do not have any useful information
on how to solve it.

The problem isn't dereferencing nulls.  It's when they get STORED that's
the problem.

  -- Daniel


[1] HCF - Halt and Catch Fire; old instruction on the PDP machines. :P
May 10 2009
parent Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
It seems I didn't explain myself very clearly.

Daniel Keep wrote:


 The point of non-nullables would be to detect improper usage at
 compile-time, right? Then I don't believe this problem has an elegant
 solution until compilers can do a rigorous control-flow analysis.
 Specifying default pointer values other than null doesn't seem very nice.


 
 You don't need control-flow analysis.  You just need a type system which
 supports nullables like D2's supports const.


You need control-flow analysis to know at compile-time if:
* an uninitialized value is read, or
* a null pointer is dereferenced.


 Nonetheless, a good step forward would be to recognize the distinction
 between `null' and `uninitialized'. Reading a variable that's
 uninitialized is an error. Reading a null pointer is fine, but
 dereferencing it is an error.


 
 Uninitialised variables is only a symptom.  The larger issue is that it
 doesn't make sense for most functions to accept null object arguments.
 It's quite rare, at least in my code, to have a function that can do
 anything sensible with "nothing" other than HCF [1].


I understand the issue. In my idea, there are non-nullable pointers. In
fact, they would probably be the default kind of pointer. But Christopher
explained those kinds of pointers have their own problems. How to
initialize an array of non-nullables? Or a struct?

So formally introduce the notion of `uninitialized' variables, or in
particular, pointers. No need to initialize (even non-nullables) right
away. Just initialize anytime. I believe in D you specify this with =void.

But don't you see, you've replaced your null-dereference problem with a
uninitialized-reading problem. That's basically the same deal.


 We already have a runtime check, and
 it's not good enough.  The major issue is that it notifies us of a
 problem at a time when we generally do not have any useful information
 on how to solve it.


Exactly. This brings me back to the need for rigorous control-flow analysis.
Without it, you can't get your info at compile-time in the general case.

-- 
Michiel Helvensteijn
May 10 2009
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Sun, May 10, 2009 at 12:05 AM, mpt <mpt ikikiki.fi> wrote:

 I keep making 2 mistakes in my D programs, and fixing them feels
 troublesome.

 1. Null references. I get a segfault and gdb is useless (ldc thing maybe).


Useless how? Generally LDC debug info should be decent. If not, we'd
be glad to look into why that is!


 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
 the real cause of error.

 Shouldn't there be an automatic null check for references and stack
 traces? Sometimes I think I'm using the wrong tool as others have
 solutions for these.
May 09 2009
parent mpt <mpt ikikiki.fi> writes:
Tomas Lindquist Olsen wrote:

 On Sun, May 10, 2009 at 12:05 AM, mpt <mpt ikikiki.fi> wrote:

 I keep making 2 mistakes in my D programs, and fixing them feels
 troublesome.

 1. Null references. I get a segfault and gdb is useless (ldc thing maybe).


 
 Useless how? Generally LDC debug info should be decent. If not, we'd
 be glad to look into why that is!


I had a problem in the past where gdb would only output a bunch of ???'s
like it does for stripped or optimized executables. This seems no longer
to be the case. I stand corrected.
May 10 2009
prev sibling parent reply torhu <no spam.invalid> writes:
On 10.05.2009 00:05, mpt wrote:

 I keep making 2 mistakes in my D programs, and fixing them feels
 troublesome.

 1. Null references. I get a segfault and gdb is useless (ldc thing maybe).
 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
 the real cause of error.

 Shouldn't there be an automatic null check for references and stack
 traces? Sometimes I think I'm using the wrong tool as others have
 solutions for these.


Tango trunk has stacktrace functionality for both Windows and linux I 
think.  There's also a Phobos backtrace patch.
May 09 2009
parent Christopher Wright <dhasenan gmail.com> writes:
torhu wrote:

 On 10.05.2009 00:05, mpt wrote:

 I keep making 2 mistakes in my D programs, and fixing them feels
 troublesome.

 1. Null references. I get a segfault and gdb is useless (ldc thing 
 maybe).
 2. Exceptions. It prints the msg nicely, but it's unhelpful in tracing
 the real cause of error.

 Shouldn't there be an automatic null check for references and stack
 traces? Sometimes I think I'm using the wrong tool as others have
 solutions for these.


 
 Tango trunk has stacktrace functionality for both Windows and linux I 
 think.  There's also a Phobos backtrace patch.


Though the Linux one just prints out the addresses and not the line 
numbers. Licensing issues with linking to libbfd to extract that 
information.
May 10 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:


I think this is another problem with D, version naming is really confusing and
lame. You can't know anything from a D version number.<


Yes, improving such small things is positive.
So I suggest to start using a "language.version.releaseStatus" numbering scheme
for D2 (and maybe for D2 too).

So the current D2 becomes:
2.0.30alpha

and the current D1 becomes:
1.0.45

Once D2 gets out of alpha it may become:
2.1.0

Bye,
bearophile
May 15 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
bearophile wrote:

 Leandro Lucarella:
 

 I think this is another problem with D, version naming is really confusing and
lame. You can't know anything from a D version number.<


 
 Yes, improving such small things is positive.
 So I suggest to start using a "language.version.releaseStatus" numbering
scheme for D2 (and maybe for D2 too).
 
 So the current D2 becomes:
 2.0.30alpha
 
 and the current D1 becomes:
 1.0.45
 
 Once D2 gets out of alpha it may become:
 2.1.0
 
 Bye,
 bearophile


I don't think this is sufficient.  What we really need is to treat each
part of the version as a complex number.

In this way, non-stable releases can have imaginary components to
distinguish them from release versions.

So the current series of D 2.x compilers would become D 2i.x.  Release
candidates would be D 2i.xi.  And of course, a stable release which has
unreleased modifications could be D 1.x+yi

So much more intuitive than the current system plus a big, red label
reading "WARNING: not stable, do not use."

  -- Daniel
May 16 2009
parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sat, May 16, 2009 at 11:07 PM, Daniel Keep
<daniel.keep.lists gmail.com> wrote:

 I don't think this is sufficient. =A0What we really need is to treat each
 part of the version as a complex number.

 In this way, non-stable releases can have imaginary components to
 distinguish them from release versions.

 So the current series of D 2.x compilers would become D 2i.x. =A0Release
 candidates would be D 2i.xi. =A0And of course, a stable release which has
 unreleased modifications could be D 1.x+yi


Why restrict yourself to a two-dimensional complex plane when we have
quaternions and octonions?
May 16 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


As far as I can tell, nobody cared about array ops.<



So that leaves contract inheritance. I find it hard to see how not having it is
a showstopper for using D1. Contracts in D haven't been the big win I thought
they might be at first. They aren't use much at all. There are a lot of other
issues that do make a big difference, and those are the issues that get
attention.<


This is interesting.

Some features are a failure because they need to be tried and tested before
knowing they are not good, because you can't tell everything from theory. Once
you know they aren't good you can remove them.

Other features are good, but in practice they aren't much used. Such low usage
may come from various sources:
- They aren't part of the culture of most D programmers (I am thinking about
useful things like typedef, nested functions and closures). This can be
partially solved adding the D site tutorial pages about the usefulness &
purposes & several usage examples of typedef, nested functions and closures.
- They are clumsy to use, maybe because their syntax is long, ugly or not easy
to understand. This can be solved with a better design, like asking the
community to design the syntax of a feature before implementing it. And before
that, asking people what features they want/need more in the first place. We'll
have to create another thread of the most wanted things.
- They aren't well integrated with other features of the D language, so such
features become like islands, so they can't become much useful, and in the D
body such feature-transplant has a reject. In a language like Chapel array
operations are natural, and in a language like Eiffel contracts are natural,
because in both language such features are well integrated with other features
of the language. This can be solved adding more bridges from such features to
other parts of the language and making the syntax of the new features better
merged with the other parts of the language.

I have never used array ops yet, but for example I'd like to have array
comprehensions (lazy too), they are something I'd use every day in D (Walter is
currently focused in adding features that allow to write big programs with D.
But it's good to also improve the language to make it fitter for small things
too. It's the difference between scaling up and scaling down. Both directions
are useful, because big programs are written of small chunks of code. And an
array comprehension allows you to write smaller class methods/functions,
reducing the overall line count of the program).

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

Few more mixed things that I'd like to see done regarding D:
- A simpler, cleaner and easier to use site. The current site is a mess. I am
able to list where I think it needs to be improved.
- Having dmd source code online on Git.
- Remove some things that are less useful from D2.
- To give more attention to what D programmers want and ask for. From what I
have seen the community here is quite smart, so it's often better to implement
what many of them ask for, instead of other things few/none ask for. Often
smart people are right in asking for faster horses instead of a car.
- Having an official D front-end written in D is something good, but now it's
too much early, I think.
- Reducing the number of D newsgroups, and renaming few of them can be good.

Bye,
bearophile
May 15 2009