bearophile wrote:
> Walter Bright:
>> Nothing except I don't have a staff of hundreds to test and
>> maintain 3 versions of D.
> 
> Developing a compiler is hard, but maybe here there are people able
> and willing to do that. You may try asking...

I'd rather the compiler inclined guys here work on things like GDC, LLVM, and CLR back ends. That'll do much more to help D.

Also, if there were 3 D versions, that puts undue burdens on library developers. I don't think the community is big enough yet to absorb that burden.

Walter Bright:
> Also, if there were 3 D versions, that puts undue burdens on library developers. I don't think the community is big enough yet to absorb that burden.

Like most of the others, I too agree that having 3 D versions is bad. The purpose of my note was mostly to remind you that while it's true you don't have hundred programmers hired, you aren't alone either, because probably there are some people willing to help :-)

Bye and thank you,
bearophile

Walter Bright, el 16 de octubre a las 14:37 me escribiste:
> Leandro Lucarella wrote:
> >Walter Bright, el 11 de octubre a las 12:51 me escribiste:
> >>Bill Baxter wrote:
> >>>But features that have
> >>>been tested in D2 and which are backwards compatible with D1?  Why
> >>>would anyone be against those?
> >>Because then you lose the definition of what is D 1.0. I believe there is considerable value not only in a stable compiler, but a stable language definition.
> >What's wrong with calling this new language D 1.1 for example?
> 
> Nothing except I don't have a staff of hundreds to test and maintain 3 versions of D.

First, the timeline you have to maintain 3 version should be small. In little time D 1.0 should be freezed and only 1.1 should be supported (until 1.2 is released at least ;)

Second, you shouldn't have to maintain it yourself. I know this is a big issue when your backend is closed source. If the "reference" implementation of D would be opensource, I'm sure you will not have this issue.

Again, see Python for example, it evolves really fast and is very stable. I think they only maintain the latest version, except for secutiry fixes.

> >Again, did you ever saw how Python evolves? Really, it's really good.
> 
> No, I haven't looked at it.

Please do.

I'm not an expert on it, but here is a short (an maybe inacurate) resume:

Python major versions are very rarely released (2.0 was released arround 2001 and 3.0 will be released this year). This is because minor versions are allowed to make small incremental backward incompatible changes, so major versions are only done when the internal Python interpreter changes drastically.

They way Python introduces new feature (even backward incompatible ones)
into a "stable" version (minor version is changed in this cases) is by
using a "future compatiblity" scheme.

For example, when the 'with'[1] statement were introduced (this was
a backward incopatible change because 'with' became a reserved word, so
old programs that used 'with' as a symbol had to be updated), you only
could use it throw a "future" statement:
from __future__ import with_statement

This was introduced in Python 2.5. So any program that worked on Python 2.4, works on Python 2.5 without modifications, even when Python 2.5 have a new *backward incompatible* feature. Programs authors have a chance to test the new feature and update their programs for a full minor version timeline (minor versions are release every 2 years aprox., so you have about 2 years to update and test your program).

Even more, in Python 2.5, programs using "with" as a symbol will get
a warning from the interpreter, so it's very hard to "forget" tu update
your program.

In Python 2.6 the 'with' statement is enabled by default.

All this extensions are managed through PEPs (Python Enhancement Proposals), which are made and discussed by the comunity and developers.


This model works *extremely* well.

[1] http://www.python.org/dev/peps/pep-0343/

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Forgive your enemies, but never forget their names

bearophile wrote:
> Andrei Alexandrescu:
>> I find it hard to not take this as malice. It's uncalled for, really.
> 
> I know that having books on a language is a quite important mean to spread it. But the D2 language has to be finished when it's finished, and judging from the current discussions it may take one or more years. Speeding up its development process just for a book is wrong.

I don't see anything wrong with that. Deliverable deadlines are a common phenomenon in the software world.

I've often tried to tell my employers "it'll be done when it's done".

They hate that.

--benji

Andrei Alexandrescu wrote:
> Bruno Medeiros wrote:
>> Andrei Alexandrescu wrote:
>>> Derek Parnell wrote:
>>>> On Sat, 11 Oct 2008 12:54:47 -0700, Walter Bright wrote:
>>>>
>>>>> bobef wrote:
>>>>>> category 3) will be forced to break their code because
>>>>>> once D2 is declared stable D1 will probably be declared deprecated
>>>>> No, I intend to support D1 as long as there is interest in it.
>>>>
>>>> I'm no longer using D at all. I've lost interest in D1 as D2 looks to be
>>>> much, much better. However D2 is a currently whirlwind of uncertainty. I'd
>>>> love to use some parts of Tango but not D1. I like Phobos (but admit it
>>>> still has too many warts and omissions) but D2 is just not worth my time
>>>> yet. I tried coding in D2 but a lot of that code is going to need
>>>> significant rework when the cabal have finalized their deliberations, which
>>>> look like being at least 12 months away.
>>>
>>> One way or another D2 will have to be done around April, when TDPL comes along.
>>>
>>> Andrei
>>
>> Do you expect the concurrency features to be ready by then? (By ready I mean something that is usable and well though-out, not just the first and experimental iterations of a design)
> 
> In the words of a car mechanic: we'll be done in six months, even if we had to work on it for a year.
> 
> Andrei
> 

I asked this because it doesn't even feel like *the const system* is finished (ready for practical, large-scale usage), in a worthwhile sense. For example, without a mechanism like the equivariant-functions/scoped-const/romaybe or something similar, there are lot of cases where using const correctly will be tedious and annoying.
And if that is the case for the const system, how about concurrency and all such features that aren't even released yet?.. The book and it's deadline is your responsibility of course, and in any case I wish things get finished on time, but if they don't, I just hope that that won't adversely affect D's development itself.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D