View mode: basic / threaded / horizontal-split · Log in · Help
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 2012-11-28 13:41, Walter Bright wrote:

> On the other hand, many people were unhappy with my position of "no
> breaking changes at all outside of clear bug fixes" to D1, which also
> implied "no language enhancements". There were many enhancements to the
> code generation, new platforms, etc., and many CTFE improvements (which
> I more or less regarded as bug fixing). There were also no changes
> allowed that affected binary compatibility.

Please, please try and understand. It's not breaking changes in it self 
that is the problem. It's how they're handled.

Many people has also talked about something in between D1 and D2, D1.5 
or similar. Which would contain bug fixes and new backwards compilable 
changes.

-- 
/Jacob Carlborg
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 11/29/2012 12:15 AM, Jacob Carlborg wrote:
> Many people has also talked about something in between D1 and D2, D1.5
> or similar. Which would contain bug fixes and new backwards compilable
> changes.


The trouble with that is now I'd be maintaining 3 versions of the 
compiler rather than two.

Here's what happens nearly all the time. People create a pull request 
for a fix to D2. I don't just pull it, I review it and see if it is a 
fix that should be propagated to D1. If it is, I have to manually merge 
it into D1 (as the sources have substantially diverged by now). This 
gets fairly time consuming. Check the D1 commits labeled along the lines 
of "merge D2 pull #nnnn".

Only a relatively small handful of times has anyone submitted a 
corresponding pull request for D1.

Adding a 3rd compiler to do this to is a large time sink.

I can see creating a stable D2 and a forward D2 for 6 months at a time 
or so, as has been proposed here. I think that's a good idea. But only 
after D1 is no longer supported.
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Wednesday, 28 November 2012 at 13:36:01 UTC, Walter Bright 
wrote:
> On 11/29/2012 12:15 AM, Jacob Carlborg wrote:
>> Many people has also talked about something in between D1 and 
>> D2, D1.5
>> or similar. Which would contain bug fixes and new backwards 
>> compilable
>> changes.
>
>
> The trouble with that is now I'd be maintaining 3 versions of 
> the compiler rather than two.
>
> Here's what happens nearly all the time. People create a pull 
> request for a fix to D2. I don't just pull it, I review it and 
> see if it is a fix that should be propagated to D1. If it is, I 
> have to manually merge it into D1 (as the sources have 
> substantially diverged by now). This gets fairly time 
> consuming. Check the D1 commits labeled along the lines of 
> "merge D2 pull #nnnn".
>
> Only a relatively small handful of times has anyone submitted a 
> corresponding pull request for D1.
>
> Adding a 3rd compiler to do this to is a large time sink.
>
> I can see creating a stable D2 and a forward D2 for 6 months at 
> a time or so, as has been proposed here. I think that's a good 
> idea. But only after D1 is no longer supported.

Thanks for writing this: it explains something regarding slowness 
of pull merging.

Have you thought about adjusting D development model to D growth? 
Perhaps allowing permissive test branch or delegating parts of 
project to maintainers (like with linux)?

Regarding breaking changes vs. keeping cripple features - it is a 
trade-off and certainly somebody will be in a loss position. 
Probably there is need to set up a clear policy - currently there 
are only talks and guesses about each problematic feature.
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 2012-11-28 14:35, Walter Bright wrote:

> The trouble with that is now I'd be maintaining 3 versions of the
> compiler rather than two.

I don't know if there would be a point of having D1 if something like 
D1.5 existed. It would still be as backwards compatible as D1 currently is.

> Here's what happens nearly all the time. People create a pull request
> for a fix to D2. I don't just pull it, I review it and see if it is a
> fix that should be propagated to D1. If it is, I have to manually merge
> it into D1 (as the sources have substantially diverged by now). This
> gets fairly time consuming. Check the D1 commits labeled along the lines
> of "merge D2 pull #nnnn".
>
> Only a relatively small handful of times has anyone submitted a
> corresponding pull request for D1.
>
> Adding a 3rd compiler to do this to is a large time sink.

I understand that. It's not feasible for one man to maintain three 
compilers. You need to be able to delegate to other people. That is 
regardless if there were a third compiler or not. See Maxim's answer to 
your post.

> I can see creating a stable D2 and a forward D2 for 6 months at a time
> or so, as has been proposed here. I think that's a good idea. But only
> after D1 is no longer supported.

Since D1 will be discontinued at the end of this year, if nothing has 
changed. It might be a good idea to start to plan for creating a stable D2.

-- 
/Jacob Carlborg
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 11/28/12 8:35 AM, Walter Bright wrote:
> On 11/29/2012 12:15 AM, Jacob Carlborg wrote:
>> Many people has also talked about something in between D1 and D2, D1.5
>> or similar. Which would contain bug fixes and new backwards compilable
>> changes.
>
>
> The trouble with that is now I'd be maintaining 3 versions of the
> compiler rather than two.
>
> Here's what happens nearly all the time. People create a pull request
> for a fix to D2. I don't just pull it, I review it and see if it is a
> fix that should be propagated to D1. If it is, I have to manually merge
> it into D1 (as the sources have substantially diverged by now). This
> gets fairly time consuming. Check the D1 commits labeled along the lines
> of "merge D2 pull #nnnn".
>
> Only a relatively small handful of times has anyone submitted a
> corresponding pull request for D1.
>
> Adding a 3rd compiler to do this to is a large time sink.
>
> I can see creating a stable D2 and a forward D2 for 6 months at a time
> or so, as has been proposed here. I think that's a good idea. But only
> after D1 is no longer supported.

The problem with the above is the count of "I", which is too large. We 
need to switch from "I" to "we" so we can scale up.

Andrei
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Wednesday, 28 November 2012 at 13:15:26 UTC, Jacob Carlborg 
wrote:
> On 2012-11-28 13:41, Walter Bright wrote:
>
>> On the other hand, many people were unhappy with my position 
>> of "no
>> breaking changes at all outside of clear bug fixes" to D1, 
>> which also
>> implied "no language enhancements". There were many 
>> enhancements to the
>> code generation, new platforms, etc., and many CTFE 
>> improvements (which
>> I more or less regarded as bug fixing). There were also no 
>> changes
>> allowed that affected binary compatibility.
>
> Please, please try and understand. It's not breaking changes in 
> it self that is the problem. It's how they're handled.
>
> Many people has also talked about something in between D1 and 
> D2, D1.5 or similar. Which would contain bug fixes and new 
> backwards compilable changes.

For what it's worth, I agree.

I think that the current "core" developers of D are exceptional 
programmers, with a very astute eye as to what makes a good 
programming language and the skills to implement it.

That said, the management of D is relatively poor.

For any programming language to make headway in the real world 
(i.e. not in the language aficionado's playground) it HAS to have 
some form of stable branch *. The documentation MUST be up to 
date and complete for that stable branch, including all the 
things that are wrong with it!

A path I see

1. Redirect current efforts towards stability **, aiming to 
produce a major release of DMD+druntime+phobos with complete and 
__honest__ documentation (i.e. admitting that something doesn't 
quite work right, "use at your own risk"). Then, make an 
aggressive push to get that stable release into use in 
mainstream, large-scale projects, which given D's power, combined 
with stability, should be much easier than before.

2. Someone takes on a significant managerial/admin position, who 
has responsibility over the documentation and stable releases of 
D. This would be a pretty unexciting job, so it probably needs to 
be paid in order to get it done well. After part 1, finding some 
money shouldn't be so hard.


My fear is that if the D rocket doesn't lift off now, it never 
really will.


* Look at python for example. Effectively the entire language is 
branched every so often and stabilised, including the standard 
library. Major release numbers signify a particular "branch", 
which is then pushed towards it's most stable state, while new 
features and significant code-breaking changes go in the next 
version number.

** Please note that I do NOT mean making the language work 
perfectly, fixing every bug. I mean fixing a lot of the low 
hanging fruit and properly documenting the problems that remain.
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Wednesday, 28 November 2012 at 14:34:12 UTC, John Colvin wrote:
> On Wednesday, 28 November 2012 at 13:15:26 UTC, Jacob Carlborg 
> wrote:
>> On 2012-11-28 13:41, Walter Bright wrote:
>>
>>> On the other hand, many people were unhappy with my position 
>>> of "no
>>> breaking changes at all outside of clear bug fixes" to D1, 
>>> which also
>>> implied "no language enhancements". There were many 
>>> enhancements to the
>>> code generation, new platforms, etc., and many CTFE 
>>> improvements (which
>>> I more or less regarded as bug fixing). There were also no 
>>> changes
>>> allowed that affected binary compatibility.
>>
>> Please, please try and understand. It's not breaking changes 
>> in it self that is the problem. It's how they're handled.
>>
>> Many people has also talked about something in between D1 and 
>> D2, D1.5 or similar. Which would contain bug fixes and new 
>> backwards compilable changes.
>
> For what it's worth, I agree.
> blah blah blah

sorry, I mean to edit out the bit about D1.5 in Jacob's post, not 
sure I fully understand what that would mean enough to agree with 
it
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Wednesday, 28 November 2012 at 12:53:34 UTC, Walter Bright 
wrote:
> On 11/28/2012 11:34 P I come here on a regular basis to see if
> > the issues hampering soM, Max Samukha wrote:
>> I have a different concession.me long-overdue work that is 
>> important to me (and
>> arguably to the community) have been resolved. There has been 
>> great
>> progress thanks to Kenji Hara, Don and others but a couple of 
>> critical
>> issues still remain (like this one
>> http://d.puremagic.com/issues/show_bug.cgi?id=5380).
>
>
> That issue is marked as "normal", not critical. You can raise 
> it to critical, but if you do, please add an explanation why. 
> Ditto for any others you find critical.

From my and other people's experience, setting bug severity, 
voting for bugs etc. usually has no effect, so I stopped doing 
that long ago.

Raised the severity and added a rationale.
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
Walter Bright:

> I can see creating a stable D2 and a forward D2 for 6 months at 
> a time or so, as has been proposed here. I think that's a good 
> idea. But only after D1 is no longer supported.

I am OK with such ideas. Below there are some musings.

How do you want to call (release numbers) those two D2 versions 
(Stable-D and Development-D)? I prefer a simple Python-like 
numbering scheme, where the second digit denotes significant 
changes (every 6 months?) and the third digit (plus alpha, beta, 
rc1, rc2, rc3, ... suffixes) refers to bug fixes that don't break 
much code. I think such numbering scheme is also able to make D 
look a little more mature and a bit more "professional".

I also think it's a bad idea to create a "D3", at the moment. 
This means I suggest to eventually merge in the Stable-D all the 
changes of Development-D (unless testing of the Development 
version shows that it's better to abandon an idea in both D2 
branches).

I suggest to release Development-D quite often, like every 20-35 
days, if it's possible.

The presence of Development-D should allow for a more relaxed 
development, bug fixing and more. There are several things to 
fix. One of such possible changes is to remove the inliner from 
the D front-end (because ldc2 and gdc2 don't use it). Making the 
front-end a slimmer is good. There are other changes worth 
considering, like aligning D ABI and function calls (as other 
compilers refuse or can't do those things). LDC2 will be probably 
quite used on Windows64bit.

Patches for Development-D should work in both D2 versions, unless 
the changes are about features not yet present in Stable-D.

For simplicity I think the first thing to do to go toward the 
first Stable-D version should be strip away the D1 parts from the 
D2 Git sources, to clean and shorten the D2 code and make its 
updates simpler.

As others have said I think it's better to not keep a single 
Development-D trunk, but branch it when new features (or 
significant changes) are developed (like UDA).

Bye,
bearophile
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 2012-11-28 15:36, John Colvin wrote:

> sorry, I mean to edit out the bit about D1.5 in Jacob's post, not sure I
> fully understand what that would mean enough to agree with it

Just as with D1 now, it only receives bug fixes. But it would also 
receive new features which are backwards compatible. I.e. adding a 
completely new module to the standard library is backwards compatible 
change.

-- 
/Jacob Carlborg
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home