1.0?

Does that imply a simultaneous 1.0 for D and DMD??

Suppose they were decoupled. Then we might decide on D 1.0 (say in December) and from there go on with fixing library issues, *installing* issues (especially on Linux), and even try to create a package that strives to be as good as Shrink-Wrap, i.e. simply work out of the box, and be somewhat usable regarding GUI development. Say, in March.

In the meantime we could polish DMD, interact with the GDC guys to get the two exactly alike, and then maybe even write some example code with more user value than the current printf-Hello-World style examples.

---

I recently talked with a CIO (who was somewhat familiar with D), who said that "short of taking a snapshot of D and sticking with it, there's no way we're gonna start using a moving target as our base, no matter if it's ten times as good as the next language." And he didn't seem likely to go the snapshot way.

The implication being that 1.0 or not, what a company needs is stability. Stability in code, tools, programmer knowledge (as in hiring and firing folks), a developer community specifically knowledgeable with the problems of the _current_ version, a community developing and maintaining up to date libraries targeted _precisely_ at the current release, and of course a conviction that the current state of affairs will continue for a reasonable amount of time (i.e. a belief in everything not becoming obsolete in three months, be it due to a super cool new version or simply code-breaking upgrades).

So,,, we need to create an _illusion_ of stability. This might be by publishing 1.0, and at the same time separating the newsgroups into two distinct areas:

 - faq
 - learn
 - issues
 - general
 - howto

and otoh:

 - future.general
 - future.issues
 - future.brainstorm
 - future.roadmap
 - future.implementation   ( = down-to-earth view on new things)

Or some such, anyway.

We might also promise to not publish a new (stable) version within 12 months of 1.0. (This may really be a more important promise for the customers and prospective developers and consultants than we here realize just off-hand.)

>Georg Wrede wrote:
>1.0?
>
> Does that imply a simultaneous 1.0 for D and DMD??
>
> Suppose they were decoupled. Then we might decide on D 1.0 (say in
> December) and from there go on with fixing library issues,
> *installing* issues (especially on Linux), and even try to create a
> package that strives to be as good as Shrink-Wrap, i.e. simply work
> out of the box, and be somewhat usable regarding GUI development. Say,
> in March.
>

I have always thought that it should be done that way. DMD is not D.

Actually, I think it should be D v1.0 RC1. I don't think that it should be carved in stone until someone other than Walter writes a complete reimplementation of the compiler. Not to belittle Walter (who is doing a great job) and DMD (which is a great program), but as it stands everything depends on one code base. The DMD frontend. A second independent implementation would remove another unknown from the future of D. Furthermore, doing a complete reimplementation, would provide an opportunity to make sure that the spec consistent and is up to date with the language. It would also likely find some more of the bugs in DMD.

<rant>
I know it is to much to ask but, if it were up to me, even more should be reimplemented before everything is set in stone. I wouldn't allow whoever is reimplementing D to look at how DMD works any more than they need to to write the new compiler (which would be written in D of course). This would include forbidding them to see how the stuff is done "under the hood". The hope would be that they might come up with a better way of making things work.
</rant>


> In the meantime we could polish DMD, interact with the GDC guys to get
> the two exactly alike, and then maybe even write some example code
> with more user value than the current printf-Hello-World style
> examples.
>

votes++;

[...]
>
> We might also promise to not publish a new (stable) version within 12
> months of 1.0. (This may really be a more important promise for the
> customers and prospective developers and consultants than we here
> realize just off-hand.)

I hope you mean no new versions of D. I would hope that Walter would still attack the DMD bug list with the same kind of aggressiveness that he has shown in the past.

As to an un-stable versions of D, maybe an excremental compiler could be made. For example I have been working on a D compiler (after several months of off and on work I'm not quite done with the *lexer*, so don't go getting all excited) that is intended to be as easy as possible to modify. The idea being that it can be a test bed for new features. To begin with I plan to  implement the official D feature set. After that, new features would be added with versions statements so that people would be able to try working with and without whatever features they want.

 As I have no plans to make it fast or put in any optimization what so ever, I don't think that there will be any risk of anyone using it for any major work.

Georg Wrede wrote:
> 1.0?
> 
> Does that imply a simultaneous 1.0 for D and DMD??
> 
> Suppose they were decoupled. Then we might decide on D 1.0 (say in December) and from there go on with fixing library issues, *installing* issues (especially on Linux), and even try to create a package that strives to be as good as Shrink-Wrap, i.e. simply work out of the box, and be somewhat usable regarding GUI development. Say, in March.

I think that's an excellent idea. If, as Walter has said, "1.0" is an arbitrary line in the sand, tying it to a particular date gives a rationale for associating a name to a particular release. If we can say "a DMD 1.0 release will exist on January 1, 2007" (or at least, 1.0 RC 1), we'd gain a lot of focus.

I thought we were really close to a 1.0 release at 0.166, but starting with the array literals in 0.167, a stable release suddenly seems a very long way off.
On the positive side, I think that array literals and variadic templates were the two major 2.0 features which were likely to render a lot of library code obselete.

We should choose a date and stick to it. Remove the angst.

Georg Wrede wrote:

> 1.0?
> 
> Does that imply a simultaneous 1.0 for D and DMD??

In general it should not, although DMD for D is useful to test if the spec actually works. Now, the spec is "unstable" enough, especially regarding mixins, variadic templates and more, for D 1.0 not to be ready (IMO). That DMD goes 1.0, I wouldn't care too much about. What will be important is that once the D spec is said to be stable, consistent and correctly written, there needs to be a way to compile a program according to that spec.

That is, if only one DMD branch is kept, it needs to be able to do -std=D1.0 and -std=exp (or similar).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

I'd love to see this happen, both the separation of DMD and D and a 1.0.
I also think the sooner than better, as these things usually take longer than expected.


Georg Wrede wrote:
> 1.0?
> 
> Does that imply a simultaneous 1.0 for D and DMD??
> 
> Suppose they were decoupled. Then we might decide on D 1.0 (say in December) and from there go on with fixing library issues, *installing* issues (especially on Linux), and even try to create a package that strives to be as good as Shrink-Wrap, i.e. simply work out of the box, and be somewhat usable regarding GUI development. Say, in March.
> 
> In the meantime we could polish DMD, interact with the GDC guys to get the two exactly alike, and then maybe even write some example code with more user value than the current printf-Hello-World style examples.
> 
> ---
> 
> I recently talked with a CIO (who was somewhat familiar with D), who said that "short of taking a snapshot of D and sticking with it, there's no way we're gonna start using a moving target as our base, no matter if it's ten times as good as the next language." And he didn't seem likely to go the snapshot way.
> 
> The implication being that 1.0 or not, what a company needs is stability. Stability in code, tools, programmer knowledge (as in hiring and firing folks), a developer community specifically knowledgeable with the problems of the _current_ version, a community developing and maintaining up to date libraries targeted _precisely_ at the current release, and of course a conviction that the current state of affairs will continue for a reasonable amount of time (i.e. a belief in everything not becoming obsolete in three months, be it due to a super cool new version or simply code-breaking upgrades).
> 
> So,,, we need to create an _illusion_ of stability. This might be by publishing 1.0, and at the same time separating the newsgroups into two distinct areas:
> 
>  - faq
>  - learn
>  - issues
>  - general
>  - howto
> 
> and otoh:
> 
>  - future.general
>  - future.issues
>  - future.brainstorm
>  - future.roadmap
>  - future.implementation   ( = down-to-earth view on new things)
> 
> Or some such, anyway.
> 
> We might also promise to not publish a new (stable) version within 12 months of 1.0. (This may really be a more important promise for the customers and prospective developers and consultants than we here realize just off-hand.)

Excremental :) ?  Freudian slip or spell check gone awry ?

> As to an un-stable versions of D, maybe an excremental compiler could be
> made.



BCS wrote:
>  >Georg Wrede wrote:
>  >1.0?
>  >
>  > Does that imply a simultaneous 1.0 for D and DMD??
>  >
>  > Suppose they were decoupled. Then we might decide on D 1.0 (say in
>  > December) and from there go on with fixing library issues,
>  > *installing* issues (especially on Linux), and even try to create a
>  > package that strives to be as good as Shrink-Wrap, i.e. simply work
>  > out of the box, and be somewhat usable regarding GUI development. Say,
>  > in March.
>  >
> 
> I have always thought that it should be done that way. DMD is not D.
> 
> Actually, I think it should be D v1.0 RC1. I don't think that it should be carved in stone until someone other than Walter writes a complete reimplementation of the compiler. Not to belittle Walter (who is doing a great job) and DMD (which is a great program), but as it stands everything depends on one code base. The DMD frontend. A second independent implementation would remove another unknown from the future of D. Furthermore, doing a complete reimplementation, would provide an opportunity to make sure that the spec consistent and is up to date with the language. It would also likely find some more of the bugs in DMD.
> 
> <rant>
> I know it is to much to ask but, if it were up to me, even more should be reimplemented before everything is set in stone. I wouldn't allow whoever is reimplementing D to look at how DMD works any more than they need to to write the new compiler (which would be written in D of course). This would include forbidding them to see how the stuff is done "under the hood". The hope would be that they might come up with a better way of making things work.
> </rant>
> 
> 
>  > In the meantime we could polish DMD, interact with the GDC guys to get
>  > the two exactly alike, and then maybe even write some example code
>  > with more user value than the current printf-Hello-World style
>  > examples.
>  >
> 
> votes++;
> 
> [...]
>  >
>  > We might also promise to not publish a new (stable) version within 12
>  > months of 1.0. (This may really be a more important promise for the
>  > customers and prospective developers and consultants than we here
>  > realize just off-hand.)
> 
> I hope you mean no new versions of D. I would hope that Walter would still attack the DMD bug list with the same kind of aggressiveness that he has shown in the past.
> 
> As to an un-stable versions of D, maybe an excremental compiler could be made. For example I have been working on a D compiler (after several months of off and on work I'm not quite done with the *lexer*, so don't go getting all excited) that is intended to be as easy as possible to modify. The idea being that it can be a test bed for new features. To begin with I plan to  implement the official D feature set. After that, new features would be added with versions statements so that people would be able to try working with and without whatever features they want.
> 
>  As I have no plans to make it fast or put in any optimization what so ever, I don't think that there will be any risk of anyone using it for any major work.

== Quote from Charlie (charlies@nowhere.com)'s article

Spell check :P

> Excremental :) ?  Freudian slip or spell check gone awry ?
>  > As to an un-stable versions of D, maybe an excremental compiler
>  > could be made.
> BCS wrote:
[...]

P.S. you forgot "bad/failed joke"

Georg Wrede wrote:
> 1.0?
> 
> Does that imply a simultaneous 1.0 for D and DMD??
> 
> Suppose they were decoupled. Then we might decide on D 1.0 (say in December) and from there go on with fixing library issues, *installing* issues (especially on Linux), and even try to create a package that strives to be as good as Shrink-Wrap, i.e. simply work out of the box, and be somewhat usable regarding GUI development. Say, in March.
> 
> In the meantime we could polish DMD, interact with the GDC guys to get the two exactly alike, and then maybe even write some example code with more user value than the current printf-Hello-World style examples.
> 
> ---
> 
> I recently talked with a CIO (who was somewhat familiar with D), who said that "short of taking a snapshot of D and sticking with it, there's no way we're gonna start using a moving target as our base, no matter if it's ten times as good as the next language." And he didn't seem likely to go the snapshot way.
> 
> The implication being that 1.0 or not, what a company needs is stability. Stability in code, tools, programmer knowledge (as in hiring and firing folks), a developer community specifically knowledgeable with the problems of the _current_ version, a community developing and maintaining up to date libraries targeted _precisely_ at the current release, and of course a conviction that the current state of affairs will continue for a reasonable amount of time (i.e. a belief in everything not becoming obsolete in three months, be it due to a super cool new version or simply code-breaking upgrades).
> 
> So,,, we need to create an _illusion_ of stability. This might be by publishing 1.0, and at the same time separating the newsgroups into two distinct areas:
> 
>  - faq
>  - learn
>  - issues
>  - general
>  - howto
> 
> and otoh:
> 
>  - future.general
>  - future.issues
>  - future.brainstorm
>  - future.roadmap
>  - future.implementation   ( = down-to-earth view on new things)
> 
> Or some such, anyway.
> 
> We might also promise to not publish a new (stable) version within 12 months of 1.0. (This may really be a more important promise for the customers and prospective developers and consultants than we here realize just off-hand.)

Yarr, me hearties, we should be releasin' soon. Arrr. Get 'em bugs squarshed.

== Quote from Georg Wrede (georg.wrede@nospam.org)'s article
> We might also promise to not publish a new (stable) version within 12 months of 1.0. (This may really be a more important promise for the customers and prospective developers and consultants than we here realize just off-hand.)


I wouldn't want to hear a promise like that.  To me, it makes it sound like there's definately not going to be any new improvements\features for at least the next year.

I think you would be better off not making any statement about the "next" version... period.

If you really want to promise anything, something along the lines of "All updates\versions\releases will be backwards compatible with 1.0 for the next 12 months (or until 2.0), except for unintended 'features' caused by bugs." would be plenty to imply a stable platform.

Just my opinion of course.

BCS wrote:
> Actually, I think it should be D v1.0 RC1. I don't think that it should be carved in stone until someone other than Walter writes a complete reimplementation of the compiler. Not to belittle Walter (who is doing a great job) and DMD (which is a great program), but as it stands everything depends on one code base. The DMD frontend. A second independent implementation would remove another unknown from the future of D. Furthermore, doing a complete reimplementation, would provide an opportunity to make sure that the spec consistent and is up to date with the language. It would also likely find some more of the bugs in DMD.

While an independent implementation of D would be worthwhile for many reasons, there are many very successful languages for which only one implementation exists - such as Perl, Ruby, etc., so it is not a requirement.

What I think is critical for the success of a single implementation language is it being open source, which D is.