May 08, 2009
== 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
== 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
== 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
== 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
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
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
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
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
== 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
== 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?