View mode: basic / threaded / horizontal-split · Log in · Help
November 28, 2012
Re: Help!
On Tuesday, 27 November 2012 at 21:26:47 UTC, Walter Bright wrote:
> On 11/28/2012 8:23 AM, Walter Bright wrote:
>> It is unbelievably frustrating for people to have their code 
>> break with
>> each new release, have older projects all invalidated, with 
>> few willing
>> to do the maintenance work to bring them back on line.
>
>
> Note the thread next to this one: "Errors compiling DSSS", and 
> the advice to abandon it.

It looks I am living in a parallel reality. In my world, DSSS has 
been abandoned for 4(!) years already! The author quit long 
before D2 feature-freeze was announced. There are a couple of 
forks but they do not seem to be maintained either. Why would 
anyone expect an unmaintained project like that to compile with 
new versions of an evolving language?

Most open source projects die. Students get jobs. That happens. 
Even the "stable" dmd1 is unlikely to compile any abandoned 
project at dsource. dsource itself is down more often than not. 
Should we keep them on life support?
November 28, 2012
Re: Help!
On 11/28/12 2:38 AM, Jacob Carlborg wrote:
> On 2012-11-28 02:40, deadalnix wrote:
>
>> Don't you think that this whole situation is due to adding feature after
>> feature in an unstabilized mess ?
>
> It is, that's the major problem with D. Not the actual code breakage,
> rather how those are introduced.

I agree. We must drop this mom-and-pop-shop attitude like a bad habit.

Andrei
November 28, 2012
Re: Help!
On 11/28/12 2:55 AM, Jacob Carlborg wrote:
> This is mostly a problem about how the project is run and managed. No
> road map, a poor release process, committing new features directly to
> the master branch. Unstable features added, added even before they're
> can be considered finished. I mean, "const" was one of the first things
> added to D2, it still has problems and druntime/Phobos is still not
> const correct.

Totally agreed. One issue now is that Walter has converged briskly on 
the simplistic conclusion "no more steenking breakages" instead of 
learning git and designing a useful process around it. That way the 
process remains broken instead of being identified as the main issue and 
fixed. I have advocated privately in much stronger terms than I could 
afford publicly that we must fix the process and exercise good judgment 
about changing the language - all to no avail. "No more breakages" is 
like taking an aspirin for the fever caused by gangrene.

I think with dread about what's coming when completing shared will be on 
the table. We'll be looking at not breaking code that was by definition 
broken.


Andrei
November 28, 2012
Re: Help!
On 11/28/12 4:26 AM, Jacob Carlborg wrote:
> On 2012-11-27 22:23, Walter Bright wrote:
>
>> I understand what you're saying, but the counterpoint is we lost half
>> the D community when D2 broke D1 code. We still have at least one major
>> D1 user that still finds it impractical to upgrade to D2.
>>
>> It is unbelievably frustrating for people to have their code break with
>> each new release, have older projects all invalidated, with few willing
>> to do the maintenance work to bring them back on line.
>
> In the keynote for the latest Ruby on Rails conference. The original
> creator of Ruby on Rails goes out and say: Yes, Rails 4 will break
> existing code. He also says that progress is good and one should keep a
> young mind.
>
> I can assure you that Ruby on Rails has vastly more commercial
> developers than D has.
>
> What I mean is that that process of improving the language most not stop
> and should always continue. It's just the process how that is made that
> makes the big difference.

Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060 
code :o).

Andrei
November 28, 2012
Re: Help!
On 2012-11-28 13:43, Andrei Alexandrescu wrote:

> Totally agreed. One issue now is that Walter has converged briskly on
> the simplistic conclusion "no more steenking breakages" instead of
> learning git and designing a useful process around it. That way the
> process remains broken instead of being identified as the main issue and
> fixed. I have advocated privately in much stronger terms than I could
> afford publicly that we must fix the process and exercise good judgment
> about changing the language - all to no avail. "No more breakages" is
> like taking an aspirin for the fever caused by gangrene.
>
> I think with dread about what's coming when completing shared will be on
> the table. We'll be looking at not breaking code that was by definition
> broken.

Thanks again for acknowledging these problems. I do really hope what we 
can see some changes in this area.

-- 
/Jacob Carlborg
November 28, 2012
Re: Help!
On 2012-11-28 13:46, Andrei Alexandrescu wrote:

> Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060
> code :o).

I've talked about that before. D doesn't have a versioning scheme that 
makes any sense. It's just a number that gets incremented without any 
meaning. Except that a greater number indicates a later version. Also 
changes to the language, compiler, runtime and standard library always 
happen in the same release.

-- 
/Jacob Carlborg
November 28, 2012
Re: Help!
On 11/28/2012 07:31 AM, Jacob Carlborg wrote:
> On 2012-11-28 13:46, Andrei Alexandrescu wrote:
>
>> Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060
>> code :o).
>
> I've talked about that before. D doesn't have a versioning scheme that
> makes any sense. It's just a number that gets incremented without any
> meaning. Except that a greater number indicates a later version. Also
> changes to the language, compiler, runtime and standard library always
> happen in the same release.
>

I must admit that I'm surprised that no one has simply forked the 
project in order to apply their own versioning scheme to it.
November 28, 2012
Re: Help!
On Wednesday, 28 November 2012 at 13:31:36 UTC, Jacob Carlborg 
wrote:
> On 2012-11-28 13:46, Andrei Alexandrescu wrote:
>
>> Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 
>> 3.060
>> code :o).
>
> I've talked about that before. D doesn't have a versioning 
> scheme that makes any sense. It's just a number that gets 
> incremented without any meaning. Except that a greater number 
> indicates a later version. Also changes to the language, 
> compiler, runtime and standard library always happen in the 
> same release.

When people refer to D1, D2, D3, and eventually D4, etc, what 
they should be referring to is a major version upgrade that will 
purposefully contain breaking changes, and will inevitably 
introduce a whole new set of bugs.

Usually increments to a minor version mean increasing stability, 
not decreasing stability or unknown stability!

Major version increments means that breaking changes may be 
introduced on purpose for a good reason, and it may mean new bugs 
will be introduced as well.

The major/minor versioning system has been in use for ages. Many 
people rely on it, including myself. I use different packages, 
that I purposely keep at a certain major revision number, and I 
always happily update to the next minor version, because it 
introduces bug fixes, not breaking changes. I only migrate to the 
next major revision only after it has matured over a few minor 
increments.

Again, sometimes I jump on the next breaking major revision, 
because it's for non-critical work, or for a new feature that I 
really need today. The point is that I can identify what is 
breaking and what is not just by looking at the version number, 
and I can pick and choose which version I think fits the 
stability model for my situation.

In any case, I did suggest re-thinking how a language can be made 
to change in significant ways over time. The major.minor version 
concept may be too simplistic for this, but holy crap, it's at 
least a good start since we don't even have that!

Something has to change, and it has to change quickly.

--rt
November 28, 2012
Re: Help!
On Wednesday, 28 November 2012 at 17:19:48 UTC, 1100110 wrote:
> On 11/28/2012 07:31 AM, Jacob Carlborg wrote:
>> On 2012-11-28 13:46, Andrei Alexandrescu wrote:
>>
>>> Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks 
>>> Rails 3.060
>>> code :o).
>>
>> I've talked about that before. D doesn't have a versioning 
>> scheme that
>> makes any sense. It's just a number that gets incremented 
>> without any
>> meaning. Except that a greater number indicates a later 
>> version. Also
>> changes to the language, compiler, runtime and standard 
>> library always
>> happen in the same release.
>>
>
> I must admit that I'm surprised that no one has simply forked 
> the project in order to apply their own versioning scheme to it.

Well, D has been forked in the past (tango vs phobos) but it 
tended to make things even worse.
November 28, 2012
Re: Help!
On 11/28/2012 11:49 AM, deadalnix wrote:
> On Wednesday, 28 November 2012 at 17:19:48 UTC, 1100110 wrote:
>> On 11/28/2012 07:31 AM, Jacob Carlborg wrote:
>>> On 2012-11-28 13:46, Andrei Alexandrescu wrote:
>>>
>>>> Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060
>>>> code :o).
>>>
>>> I've talked about that before. D doesn't have a versioning scheme that
>>> makes any sense. It's just a number that gets incremented without any
>>> meaning. Except that a greater number indicates a later version. Also
>>> changes to the language, compiler, runtime and standard library always
>>> happen in the same release.
>>>
>>
>> I must admit that I'm surprised that no one has simply forked the
>> project in order to apply their own versioning scheme to it.
>
> Well, D has been forked in the past (tango vs phobos) but it tended to
> make things even worse.

Well I was thinking more along the lines of prevent breaking changes but 
I suppose you are right.

And now that you mention it, I suppose I've forked the GC as well...
2 3 4 5 6 7
Top | Discussion index | About this forum | D home