... At the moment, Walter Bright's first priority is to finalize the 64-bit native compiler, after which he plans to focus on dynamic loading.

At first I was like :D



... There's no incompatible D3 in the foreseeable future ...

but then I bummed.



... Get this—I've seen beautiful PHP code...

What was it like?

On Wednesday, August 25, 2010 17:27:41 Ben White wrote:
> ... There's no incompatible D3 in the foreseeable future ...
> 
> but then I bummed.

We need D2 to completely and totally stable before we even consider anything like D3. If you don't properly stabilize what you have and let it mature, it's not likely to get used much. And as much as new features can be great, breaking backwards compatibility can suck too. Not to mention, I think that D2 needs to be used a lot more by a lot more people before we could really know what was done right and what was done wrong such that we would really know what to do with D3.

By the sounds of it, once D2 is more mature and stable, some backwards- compatible features may be added, but we don't really need D3 at this point. D2 is a huge gain over D1, and it was well worth breaking backwards compatability for it, but it's not like D1 hase ever all that much traction. There are definitely people who use it, but it has a relatively small user base. If D2's user base really increases like we'd like it to (and TDPL should help a lot with that), it's going to cost users a lot more when backwards compatability is broken.

There may very well be a D3 someday, but D2 is still pretty nascent. We need to get what we have properly mature before we look at doing a major language rewrite.

- Jonathan M Davis

Jonathan M Davis

> If D2's user base really increases like we'd like it to (and TDPL should help a lot with that), it's going to cost users a lot more when backwards compatability is broken.

This is why I don't like a lot the current work done for the 64 bit implementation. D2 has some design problems (I don't call them 'enhancement requests') that if you want to fix may require to break backward compatibility (they are things that can't just be added to the D2 language), few months ago I have listed about ten of them here (and I think Walter did just ignore them), and probably few more are present (and one or two of them in the meantime have officially become 'things to fix', like the syntax for array ops that I think now officially requires obligatory [], this was one of the things in my list of little breaking changes). I'd like those problems to be fixed (or specs to take them in account, even if the compiler implementation isn't yet up to date to them) before people start using D2 and breaking backwards compatibility becomes a pain. Otherwise they risk never being fixed.

Implementation matters come after design matters if you impose the constraint of keeping backwards compatibility.

Bye,
bearophile

On 26/08/10 10:55, bearophile wrote:
> Jonathan M Davis
>
>> If D2's user base really increases like we'd like it to (and TDPL should help a lot with
>> that), it's going to cost users a lot more when backwards compatability is
>> broken.
>
> This is why I don't like a lot the current work done for the 64 bit implementation. D2 has some design problems (I don't call them 'enhancement requests') that if you want to fix may require to break backward compatibility (they are things that can't just be added to the D2 language), few months ago I have listed about ten of them here (and I think Walter did just ignore them), and probably few more are present (and one or two of them in the meantime have officially become 'things to fix', like the syntax for array ops that I think now officially requires obligatory [], this was one of the things in my list of little breaking changes). I'd like those problems to be fixed (or specs to take them in account, even if the compiler implementation isn't yet up to date to them) before people start using D2 and breaking backwards compatibility becomes a pain. Otherwise they risk never being fixed.
>
> Implementation matters come after design matters if you impose the constraint of keeping backwards compatibility.
>
> Bye,
> bearophile

++vote

> Implementation matters come after design matters if you impose the constraint of keeping backwards compatibility.

But I agree that 64 bits is a quite important implementation matter, while those things I did list were very little design matters :-)

Bye,
bearophile

Justin Johansson:
> ++vote

But this time I was a pretty idealistic person. So in the end I respect Walter decision, because he may have taken in account more practical considerations.

Bye,
bearophile

On 26/08/10 11:26, bearophile wrote:
> Justin Johansson:
>> ++vote
>
> But this time I was a pretty idealistic person. So in the end I respect Walter decision, because he may have taken in account more practical considerations.
>
> Bye,
> bearophile

Yes, understand and obviously it's Walter's call.  In hindsight perhaps
I was a bit quick to "vote".  Though I did want to voice support for
fixing up language design issues, I didn't want to sound discouraging
about W working on 64-bit either.  A lot of people will be pleased to
see 64-bit D.

Cheers, Justin

Ben White schrieb:
> ... At the moment, Walter Bright's first priority is to finalize the 64-bit
> native compiler, after which he plans to focus on dynamic loading.
>
> At first I was like :D

Yeah, that's great news - I started a new project about 6 weeks ago still in D1, because D2 lacks AMD64 support (D1 has GDC).


What I found a bit misleading:
"All projects I mentioned [GDC, LDC] use the open-sourced reference front end to implement both D1 and D2, and trail behind the reference compiler by a few minor releases."

LDC hasn't done much within the last months (last source change 3 months ago, last change on D2 about a year ago if I understand the info in the SVN browser correctly) - they consider their D2 support "highly experimental (read: unusable)" - so I guess they're more than "a few minor releases" away from the current DMD D2 compiler.

GDC is actively worked on, since a few weeks ago they're heavily working on the D2 version again - but they're still working at version 2.020 (which had major changes, e.g. immutable and including druntime).
That's more than "a few minor releases behind". Much of the interesting stuff (std.algorithm and ranges etc in phobos, alias this in the language, thread local storage as default, etc) is still missing.
The GDC guys are doing a great job (as far as I can judge), but I guess it'll take some more time until they're at a fairly recent version comparable to DMD 2.048 (and thus containing the features described in TLDP).


Cheers,
- Daniel

On 8/25/10 20:09 PDT, Daniel Gibson wrote:
> Ben White schrieb:
>  > ... At the moment, Walter Bright's first priority is to finalize the
> 64-bit
>  > native compiler, after which he plans to focus on dynamic loading.
>  >
>  > At first I was like :D
>
> Yeah, that's great news - I started a new project about 6 weeks ago
> still in D1, because D2 lacks AMD64 support (D1 has GDC).
>
>
> What I found a bit misleading:
> "All projects I mentioned [GDC, LDC] use the open-sourced reference
> front end to implement both D1 and D2, and trail behind the reference
> compiler by a few minor releases."
>
> LDC hasn't done much within the last months (last source change 3 months
> ago, last change on D2 about a year ago if I understand the info in the
> SVN browser correctly) - they consider their D2 support "highly
> experimental (read: unusable)" - so I guess they're more than "a few
> minor releases" away from the current DMD D2 compiler.
>
> GDC is actively worked on, since a few weeks ago they're heavily working
> on the D2 version again - but they're still working at version 2.020
> (which had major changes, e.g. immutable and including druntime).
> That's more than "a few minor releases behind". Much of the interesting
> stuff (std.algorithm and ranges etc in phobos, alias this in the
> language, thread local storage as default, etc) is still missing.
> The GDC guys are doing a great job (as far as I can judge), but I guess
> it'll take some more time until they're at a fairly recent version
> comparable to DMD 2.048 (and thus containing the features described in
> TLDP).

In brief, I didn't do my homework and rightly got shafted. Yet another instance of an old lesson.

Andrei

bearophile wrote:
> This is why I don't like a lot the current work done for the 64 bit
> implementation.

A lot of groups cannot consider D unless it supports 64 bit compilation.


> D2 has some design problems (I don't call them 'enhancement
> requests') that if you want to fix may require to break backward
> compatibility (they are things that can't just be added to the D2 language),
> few months ago I have listed about ten of them here (and I think Walter did
> just ignore them),

71 bugzilla issues were resolved just in the last update. I don't think it's quite fair to characterize the ongoing development as ignoring the community. You list several things *per day*. I doubt any organization could keep up with the sheer volume of your output <g>. I'm not suggesting that you stop doing it, quite the contrary. I just hope you can be realistic about how much can be done about them in the short term.