A (un)stable idea?

[Jonathan M Davis]

On Monday 03 January 2011 21:11:27 Guilherme Vieira wrote:
> On Tue, Jan 4, 2011 at 3:07 AM, Heywood Floyd <soul8o8 at gmail.com> wrote:
> > Hi D!
> > 
> > 
> > I'm quite new to D (been here for maybe half a year?) and I'm not sure if
> > what I'm about to say is called for, so please forgive me if I'm crossing
> > some line here. I just had a thought and I wanted to share it:
> > 
> > 
> > I've noticed, during my time here, that D seems to suffer from quite a
> > lot of frustration. This frustration in turn seems to stem from
> > periodical annoying bugs and regressions etc. There are stories of
> > dedicated developers abandoning the ship and things like that. I'm not
> > really in a position to say if this is normal or not, but I think at
> > least it's fair to say a lot of poeple are frustrated with D(?).
> > 
> > At the same time, what's interesting is that these kinds of bugs can
> > hardly be unique to D -- in fact, it would be really weird if these
> > kinds of issues was not present in D! (I think so, at least.) Software
> > is complex, and we all know bugs are part of the normal course of
> > things. I'd go so far to say bugs are a natural part of software.
> > 
> > So why all the frustration?
> > 
> > This lead me to a thought: maybe, just maybe, one thing that causes so
> > much frustration, is the fact that D doesn't really seem to have any
> > testing / stable branches. Seems to me, and please correct me if I'm
> > wrong, changes made to the trunk are released about once every month?
> > And that's it. That's the latest version of D.
> > 
> > This is very agressive. Isn't it? Seems to me, many people hold off the
> > latest version of D, because it's so agressive.
> > 
> > I think most non-trivial software projects keep one branch that is the
> > "sand box"-branch where new features are tried out, and one branch where
> > special care is taken to keep it stable. Now, this setup doesn't mean
> > that the software will be bug free. The _key_ here is, that once you
> > label a piece of software as "testing" or "experimental", bugs are ok!
> > In fact, bugs are to be expected! No one can complain! (And if they do,
> > you say "hey, chillax dude, it's experimental!")
> > 
> > Also, most developers will be in different phases in their projects --
> > some are building on some project that is years old and the last thing
> > they want is some new experimental feauture. Others are just playing
> > around and don't mind getting all the latest bells and whistles.
> > Testing/stable solves all that, while still allowing the software to
> > evolve.
> > 
> > Then of course, you have to actually keep the stable branch stable. I
> > realize that simply dividing D(2) into two branches wouldn't achieve
> > that. So I don't know. I guess this is more an idea for future version
> > of D?
> > 
> > That's it. I'm not quite going to finish my reasoning, because, yeah I
> > don't know. Maybe this has been up before? Sorry in that case. I just
> > wanted to give this idea some air: How about maybe having a
> > testing/stable branch for D at some point in the future? I for one would
> > like that, anyhow.
> > 
> > 
> > (Fun thought experiment: Imagine Debian Linux abandoning their testing
> > branch and just making all changes to trunk. Imagine _that_ mailing list.
> > You can feel the frustration, can't you? :)
> > 
> > 
> > Kind Regards
> > /HF
> > 
> > 
> > PS. I've too experienced some frustrating bugs with D, but it's still the
> > only compiled language I can stand! *bow*
> 
> Shouldn't TDPL have set the safe subset of the language to use? Maybe it
> only happens much when you cross that line?

Safe and stable are two different things. D has the concept of SafeD which 
restricts unsafe features. @safe functions can only call trusted functions, 
whereas @trusted are safe functions which encapsulate unsafe stuff, and @system 
is the unsafe stuff.

That being said, dmd is not up-to-date with TDPL. TDPL is ahead of it. At this 
point, the language definition really isn't the problem. TDPL more or less froze 
that. Changes to the language will be made pretty much only as is proven 
necessary. The spec is no longer under heavy development. However, while the 
spec may no longer be in flux, the implementation is. dmd has plenty of bugs, and 
it has yet to fully implement everything that's in TDPL. It continues to get 
closer to that point, but it isn't there yet. And separate from TDPL and the 
state of dmd, you have Phobos, which is very much in flux. Some of it is quite 
stable, but a fair bit of it still under heavy development. So, bugs aren't 
uncommon.

I do expect that we will eventually have to have Phobos with major and minor 
releases, with the minor releases only being bug fixes, and the major releases 
actually having feature changes and the like. However, I think that it's too 
early in its development for that to really make sense yet. As the language spec 
is essentially frozen, pretty much all changes to dmd are bug fixes (or the 
implementation of features which in the spec but not yet implemented, which are 
arguably bugs since then dmd doesn't match the spec). So, dmd shouldn't have the 
same issues.

I do think that we need to better deal with stable vs development code at some 
point, but I'm not sure if we're far enough along for that to make sense yet. 
Too much focus on that would likely stagnate Phobos development. Once it's more 
mature, then that sort of thing would make sense, but not now.

- Jonathan M Davis