View mode: basic / threaded / horizontal-split · Log in · Help
August 26, 2010
About Andrei's interview, part 3
... 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?
August 26, 2010
Re: About Andrei's interview, part 3
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
August 26, 2010
Re: About Andrei's interview, part 3
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
August 26, 2010
Re: About Andrei's interview, part 3
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
August 26, 2010
Re: About Andrei's interview, part 3
> 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
August 26, 2010
Re: About Andrei's interview, part 3
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
August 26, 2010
Re: About Andrei's interview, part 3
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
August 26, 2010
Re: About Andrei's interview, part 3
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
August 26, 2010
Re: About Andrei's interview, part 3
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
August 26, 2010
Re: About Andrei's interview, part 3
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.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home