View mode: basic / threaded / horizontal-split · Log in · Help
November 28, 2012
Breaking D2 language/spec changes with D1 being discontinued in a month
Another DMD alpha, another set of previously valid code that no 
longer compiles. With 2.060 it was the TypeInfo constness changes 
in druntime, with 2.061 it is the dissalowance of rebindability 
of the this pointer. The latter did make it into the spec half a 
year ago, but recently it was actually dissallowed in the beta. 
Unlike many other features of the sort (e.g. octal literals) 
there is no warning or deprecation errors... code that use to 
compile simply does not anymore.

In this last case, in principle, we were lucky... the spec was 
changed. What about things like this: 
http://dlang.org/attribute.html#inout . Are those undocumented 
features liable to change at any time? What warning will there be 
when somebody decides to submit an inout bug and somebody else 
fixes it in a way that breaks existing code?

D1 is scheduled to be discontinued in a month, and every new 
version of DMD keeps changing D2 in code breaking ways (or worse, 
with backwards incompatible spec changes). I think that unless 
people responsible for these things get their act together and 
stabilize D2 against these issues, D1 support should be extended 
until that happens.
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
SiegeLord:

> I think that unless people responsible for these things get 
> their act together and stabilize D2 against these issues, D1 
> support should be extended until that happens.

It will take some more years to see D2 "stabilized" like that. 
The decision to discontinue D1 has some disadvantages, but 
keeping D1 updated uses some work time that could be (better) 
spent improving D2.

Bye,
bearophile
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Wednesday, 28 November 2012 at 02:29:12 UTC, bearophile wrote:

> It will take some more years to see D2 "stabilized" like that. 
> The decision to discontinue D1 has some disadvantages, but 
> keeping D1 updated uses some work time that could be (better) 
> spent improving D2.

With that kind of attitude D2 will never stabilize.

I remember two years ago I was told that once TDPL was published, 
the language would become stable. Two years later everything is 
just as in flux as it was back then. The welcome fixation of bugs 
is befouled with deliberate code breakage left and right. There 
is absolutely no guarantee of backwards compatibility between DMD 
versions. This situation is simply unheard of. Vast majority of 
respectable software inititives provide a stable version that 
guarantees source and possibly binary compatibility, and an 
unstable version that does not. They use versioning schemes where 
a match of some part of the version number assures compatibility.

Is there absolutely no concern for D users's code? It certainly 
seems like it. Maybe it would have made sense a decade ago when D 
was just starting... but D has been around for over 11 years now. 
To have screwed up so badly that after 11 years you still don't 
have a stable platform to write code for (well, you do with D1, 
but in a month there will not be that excuse) is mind boggling.
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Wednesday, 28 November 2012 at 02:29:12 UTC, bearophile wrote:
> SiegeLord:
>
>> I think that unless people responsible for these things get 
>> their act together and stabilize D2 against these issues, D1 
>> support should be extended until that happens.
>
> It will take some more years to see D2 "stabilized" like that. 
> The decision to discontinue D1 has some disadvantages, but 
> keeping D1 updated uses some work time that could be (better) 
> spent improving D2.
>
> Bye,
> bearophile

The problem we have with this situation is that language users 
will just run away to more stable languages.

Many people need upper management agreement for the set of 
languages they use, if suggesting D might cause them to risk 
their job, they won't do it.

--
Paulo
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
> Is there absolutely no concern for D users's code? It certainly 
> seems like it. Maybe it would have made sense a decade ago when D 
> was just starting... but D has been around for over 11 years now. 
> To have screwed up so badly that after 11 years you still don't 
> have a stable platform to write code for (well, you do with D1, 
> but in a month there will not be that excuse) is mind boggling.

I tend to disagree a bit. First D is a very, very powerful language
written by just a few people, with no commercial background, so I think
it is quite reasonable that it takes more time to stabilize than much
simpler languages, let's say python.

I also in general think, that fixing things is a good idea, even if
breaking code, but it is really annoying if your code breaks, especially
if you can not easily find the reason.

For this reason and others (more testing) I would also very much
appreciate (I already suggested this before) to have a stable branch,
that really only receives bug fixes and a new major version release
every half a year or so (given D's speed of development). It should not
be too frequent, because it will be a lot of work:

1. Document precisely any breaking changes for the new version + a
recommend way of updating (which was tested).
2. Provide tools that fix your code automatically. Wherever reasonable &
possible.

Because I think, the least you can do is to have a thorough discussion
somewhere of what breaks and how to fix it. I would be very much less
pissed by breaking changes, if I could at least look them up quickly and
get a solution for it.

For point 2, we would start with some easy tools like search and replace
(for name changes and such) and improve them over time to parse
context, ... (e.g. like http://coccinelle.lip6.fr/sp.php  )
-> The easier and automated the upgrade path, the better.

Old version could be supported until the major version after the next
one comes out. Encourage people to upgrade early and make it as easy as
possible for them.

Are breaking changes of any kind documented somewhere at the moment?

The release model I have in mind:
1. Every few months a new minor release for both the unstable and the
stable version. (To get early and good testing for the unstable version
& to find out any unexpected breakings)
2. Every six/eight/twelve months: The current unstable will become the
new stable with all breakings perfectly documented & uprade scripts
written.

If it is too much work to support two stable versions, we could drop
updates as soon as a new version comes out.

Breaking changes should still be avoided of course, but if needed they
should be possible.

Best regards,

Robert
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 2012-11-28 02:38, SiegeLord wrote:
> Another DMD alpha, another set of previously valid code that no longer
> compiles. With 2.060 it was the TypeInfo constness changes in druntime,
> with 2.061 it is the dissalowance of rebindability of the this pointer.
> The latter did make it into the spec half a year ago, but recently it
> was actually dissallowed in the beta. Unlike many other features of the
> sort (e.g. octal literals) there is no warning or deprecation errors...
> code that use to compile simply does not anymore.
>
> In this last case, in principle, we were lucky... the spec was changed.
> What about things like this: http://dlang.org/attribute.html#inout . Are
> those undocumented features liable to change at any time? What warning
> will there be when somebody decides to submit an inout bug and somebody
> else fixes it in a way that breaks existing code?
>
> D1 is scheduled to be discontinued in a month, and every new version of
> DMD keeps changing D2 in code breaking ways (or worse, with backwards
> incompatible spec changes). I think that unless people responsible for
> these things get their act together and stabilize D2 against these
> issues, D1 support should be extended until that happens.

Welcome do D.

-- 
/Jacob Carlborg
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 2012-11-28 08:17, SiegeLord wrote:

> With that kind of attitude D2 will never stabilize.
>
> I remember two years ago I was told that once TDPL was published, the
> language would become stable. Two years later everything is just as in
> flux as it was back then.

TDPL was release way, way too soon. It was written before many of the 
features were even implemented. Then at a later stage "Whoops, this 
apparently doesn't work, we need to break TDPL".

The welcome fixation of bugs is befouled with
> deliberate code breakage left and right. There is absolutely no
> guarantee of backwards compatibility between DMD versions. This
> situation is simply unheard of. Vast majority of respectable software
> inititives provide a stable version that guarantees source and possibly
> binary compatibility, and an unstable version that does not. They use
> versioning schemes where a match of some part of the version number
> assures compatibility.

I think all this is mostly a project management issue. I don't think the 
breaking changes in them self is the biggest problem. See my post in 
another thread:

http://forum.dlang.org/thread/mailman.2250.1353947827.5162.digitalmars-d@puremagic.com?page=5#post-k94g19:2427kh:241:40digitalmars.com

-- 
/Jacob Carlborg
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Wednesday, 28 November 2012 at 07:52:54 UTC, Robert wrote:
>> Is there absolutely no concern for D users's code? It 
>> certainly seems like it. Maybe it would have made sense a 
>> decade ago when D was just starting... but D has been around 
>> for over 11 years now. To have screwed up so badly that after 
>> 11 years you still don't have a stable platform to write code 
>> for (well, you do with D1, but in a month there will not be 
>> that excuse) is mind boggling.
>
> I tend to disagree a bit. First D is a very, very powerful 
> language
> written by just a few people, with no commercial background, so 
> I think
> it is quite reasonable that it takes more time to stabilize 
> than much
> simpler languages, let's say python.
>

Actually, this is true that D have little resources, and the work
done is really incredible. To be fair, D community is one of the
most technically competent I know of.

That being said, the problem isn't the amount of work, but how it
is managed. Thinking that D is not stable because of resource is
just avoiding to look at the truth.
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Wednesday, 28 November 2012 at 08:01:02 UTC, Jacob Carlborg 
wrote:

> I think all this is mostly a project management issue. I don't 
> think the breaking changes in them self is the biggest problem.

After years of using D1 and D2, I've lowered my expectations 
about what can be changed for the better with D as long as the 
current captains are at the helm. You can change the language, 
but you can't change the person. Yes, ultimately if the project 
was managed better the code breaking issue would be mitigated for 
free, but that's not happening. Bad management is one of the 
invariants of D's history.

Given that invariant, I just want a tiny concession... I want my 
code not to break with every new version of DMD. If some breaking 
change must be introduced, I want ample warning, preferrably in 
the form of a compillation warning or a deprecation message, so I 
don't have to scamper to fix my code in a few weeks/days after 
each DMD release, but have the leisure to do it over a release 
cycle.

A quick aside about D1... it in fact has amazing stability. I 
recently compiled Kenta Cho's D games which were written before D 
1.0... I only had to make a few changes here and there for it to 
compile with the most recent DMD1. Far less than the amount of 
changes I had to make when upgrading from 2.059 to 2.060 with the 
D2 codebase I maintain (Tango D2 and my personal projects). With 
D1 being discontinued, it is clear where the priorities lie... 
definitely not on stability of people's code.

And before people come and say that they have thousands of D2 
commercial code that they don't mind breaking every release... 
let me suggest that perhaps for every 1 of you, there are 99 
others who don't care for such nonsense?
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Wednesday, 28 November 2012 at 01:38:38 UTC, SiegeLord wrote:
> Another DMD alpha, another set of previously valid code that no 
> longer compiles. With 2.060 it was the TypeInfo constness 
> changes in druntime, with 2.061 it is the dissalowance of 
> rebindability of the this pointer. The latter did make it into 
> the spec half a year ago, but recently it was actually 
> dissallowed in the beta. Unlike many other features of the sort 
> (e.g. octal literals) there is no warning or deprecation 
> errors... code that use to compile simply does not anymore.
>
> In this last case, in principle, we were lucky... the spec was 
> changed. What about things like this: 
> http://dlang.org/attribute.html#inout . Are those undocumented 
> features liable to change at any time? What warning will there 
> be when somebody decides to submit an inout bug and somebody 
> else fixes it in a way that breaks existing code?
>
> D1 is scheduled to be discontinued in a month, and every new 
> version of DMD keeps changing D2 in code breaking ways (or 
> worse, with backwards incompatible spec changes). I think that 
> unless people responsible for these things get their act 
> together and stabilize D2 against these issues, D1 support 
> should be extended until that happens.

Now you understand why I stick to Java at work, and use D only 
for non mission-critical (small) projects. If I know that the 
project is going to have large code-base I *do not* use D (by D I 
always mean D2).

However, If I *had to* use D for a large-scale project I would do 
the following:

1) Make my own fork of DMD, Druntime and Phobos, and maintain 
them myself. Ie. merge only changes from the upstream that do not 
break my own project.
2) Use these forked projects to build my project.
3) Periodically, when time permits, I "jump" to the latest 
release of DMD, Druntime and Phobos. Naturally that would be a 
big job, to fix my broken projects code. But as I said, I have 
reserved a lot of time for this so I am fine with this.

This is how it is done in real world mostly. I know I did it in 
the past. I used an experimental branch of a certain C++ GUI 
toolkit in a large project. I did exactly what I explained above, 
and it was all right! :)
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home