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 Wednesday, 28 November 2012 at 08:51:02 UTC, Dejan Lekic wrote:
> 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! :)

I fully agree.

This only works however, if the overhead is not too much and 
management is ok with it.

--
Paulo
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 11/28/12, SiegeLord <none@none.com> wrote:
> with 2.061 it is the dissalowance of rebindability
> of the this pointer.

We can still revert this pull since 2.061 was not officially released
yet. I think we've simply missed Walter's comment which you linked to:
http://d.puremagic.com/issues/show_bug.cgi?id=780#c3
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 28 November 2012 09:47, Paulo Pinto <pjmlp@progtools.org> wrote:

> 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.
>

If D stabilised on exactly the feature set it offers right now (or even 3
months ago), I wouldn't be interested. The lowest level is brittle, and the
high level is still missing a couple of little details (rvalues -> ref is
the key one for me).
D's fluidity is actually one of it's biggest selling points as far as I'm
concerned. D seems to accept that mistakes can be fixed and improvements
can be made, and it should embrace that to an extent, or you end up with
C++ long term.

I think the best approach is one that others have suggested, 2 branches,
'stable' which is maintained for 6-12 months, and only receives
non-breaking fixes after they've been tested for a while, and 'dev', which
users accept may receive breaking changes at any time. Those users will be
happy to adapt their code as the language moves forward, as I am.

You choose the branch that applies to your business, and then you have no
reason to complain. The current situation where one branch adopting either
policy (and seemingly changing which policy it subscribes to from day to
day) will alienate the other camp, and is obviously unworkable.
Under a 2 branch system, the stable crew will still have to update from
time to time, but they can do it in one lump far less often, and that
should cause a lot less trouble for them.

D should have 3 version digits:
D2.6.1, the second digit representing the last 'stable' codepoint.

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.
>

I feel this personally.
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On Wednesday, 28 November 2012 at 08:40:32 UTC, SiegeLord wrote:
> 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.

I have a different concession. I come here on a regular basis to 
see if the issues hampering some 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). I 
don't give a darn whether fixing the language and tools breaks 
other people's code. It is *their* code that is wrong and should 
be changed. We should not need to clutter ours with the ugliest 
of workarounds because people didn't care to think about what 
they were doing. If they can't or don't want to do the right 
thing, let them stick to the buggy compiler builds that work for 
them.

>
> 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
SiegeLord:

> With that kind of attitude D2 will never stabilize.

Currently in D there are unfinished parts like vector operations 
that are not finished, shared that maybe needs to be redesigned, 
foreach loops and switch statements that need some design fixes, 
but also its standard library has rebindable, emplace, Typedef, 
Nullable and Algebraic that are not good enough and need 
improvements or rethinking. Plus some missing collections and 
memory allocators. Plus there are several corner cases that must 
be addressed, I am following Bugzilla closely and if you want I 
can list you one hundred of significant bugs. Fixing some of 
those "bugs" will break user D2 code. Not fixing those bugs will 
be a worse fate.

D is a quite complex language, composed of many parts, and Walter 
is not just designing a language and developing a front-end, but 
he's also keeping its back-end, there is also the standard 
library, and the garbage collector. And the amount of work force 
is limited. So D develops and stabilize rather slowly. Developing 
D takes many years. I think there is no escape from this.

On the other hand I used to find a significant new bug every 
20-30 lines of my D2 code, this today happens much more rarely.

Bye,
bearophile
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 11/28/2012 7:40 PM, SiegeLord wrote:
> 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.

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.

D1 isn't going away - it isn't going to be removed from the servers, 
etc. It's just not going to be officially supported anymore.
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 2012-11-28 12:48, Manu wrote:


> I think the best approach is one that others have suggested, 2 branches,
> 'stable' which is maintained for 6-12 months, and only receives
> non-breaking fixes after they've been tested for a while, and 'dev',
> which users accept may receive breaking changes at any time. Those users
> will be happy to adapt their code as the language moves forward, as I am.

I completely agree, it's not rocket science.

-- 
/Jacob Carlborg
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 11/28/12 3:01 AM, Jacob Carlborg wrote:
> 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".

I disagree. Aside from a few details, the language described by TDPL is 
implementable. The problem becomes when TDPL gets in competition with 
incorrect code that currently compiles and runs although it shouldn't.

Andrei
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
On 11/28/2012 10:18 PM, Andrej Mitrovic wrote:
> On 11/28/12, SiegeLord <none@none.com> wrote:
>> with 2.061 it is the dissalowance of rebindability
>> of the this pointer.
>
> We can still revert this pull since 2.061 was not officially released
> yet. I think we've simply missed Walter's comment which you linked to:
> http://d.puremagic.com/issues/show_bug.cgi?id=780#c3
>

Yeah, it seems that the warning & deprecation stages were skipped. That 
was a mistake.
November 28, 2012
Re: Breaking D2 language/spec changes with D1 being discontinued in a month
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.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home