I agree.
Especially things that will/could break backward compability should be considered now. (Later these things are of course harder to change: 1) it cannot be done, 2) it'll break backward compability (e.g. 1.0 code doesn't compile with 1.1), and 3) old syntax (marked as obsolete) exists parallel with the new one.)

On Mon, 04 Sep 2006 00:01:27 +0300, Chad J <gamerChad@_spamIsBad_gmail.com> wrote:
> Walter Bright wrote:
>> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.
>
> Firstly, I don't think things like fancy delegates with functional programming are very important for 1.0.  They are cool, but can wait.
>
> I see some things that should be implemented before RC1 for backwards compatibility reasons, like auto and constness.  There is a way around that for the most part though:
>
> I would like to see an experimental branch before seeing an RC, sort of like Gregor suggested.  Not a branch of the compiler, but a branch of the spec.  Features that are not stable or not implemented yet would fall into this experimental branch.  There would be a singular DMD that conforms to this spec, with the realization that any feature from the experimental part of the spec my change in the next release.
>
> Here are some things I'd expect to see in the experimental spec:
> - Lazy delegates // very new stuff
> - auto // due to auto auto, this will get changed sometime right?
> - array operators // not implemented yet
> - common func ptr/delegate syntax // not implemented yet
> - IFTI // not fully implemented
> - mixins // I've read complaints about the usability of mixins
> and so on...
>
> It may even be nice to have a couple phases of experimental spec, like an alpha spec and a beta spec.  The alpha spec contains things that will most likely change, and the beta spec contains fairly stable features that are yet to be time-tested.
>
> This would allow 1.0 to roll out without some of those things I've listed being addressed.  I don't think those features I've mentioned as experimental spec candidates are super important.  The only reason we worry about some of these, like auto auto, are for backwards compatibility.  But with an experimental system, coders are prewarned, and backwards compatibility isn't too worrisome.  Still, something like constness still bugs me even with experimental spec, since it could change very basic things about the language.
>
>
> If 1.0 isn't a publicity thing, then disregard the below.  These assume that many new programmers will be trying D when a 1.0 release happens, and will need impressing.
>
> Another big problem I see with RC1 - Access violation.  If there is going to be a mob of people trying D at 1.0, then the compiler should behave nicely, and not produce programs that produce 'access violation'.   This seems very tacky to me.  It turns a 30 second code correction into a 10+ minute debugging session, ouch!  At least put line numbers on those things.  Bonus points for decent descriptions of what went wrong.
>
> Also related to mobs of people trying D at 1.0 - the spec needs going over with a fine tooth comb.  This seems to be going on already, which is good.  The spec's coolness would go up a few notches if there was a spec-only keyword search option.  Do this *before* 1.0.
>
> Phobos.  Maybe this can wait, but perhaps we should at least do some work to phobos' interface?  Make sure the naming is consistent with the D style guidelines.  It needs a *simple* way to read input from the console, and not some std.c.crap.  Also, 'atoi' (in std.string) is a horrible name for a function that turns a string into an integer, and we have overloading now, unlike C back in the day, so make it 'toInt' (which exists in std.conv, so why the dupe?).  This shouldn't be a big effort to expand phobos' functionality, just a time where we break everyone's code and deal with it so that future D programmers don't have to.  Adopting another library like Ares as standard and tweaking on it should work too, though I see that as harder to pull off.

Walter Bright wrote:
> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.

I vote for fixing the current D language specification as "1.0," barring the discovery of some horrible ambiguity or logical inconsistency. Future changes should still be considered, but I think we need to go through a few rounds of clean up and bug fixing before we start mutating again.  The language is still not as mature as C++ or Java, and it is only natural that it will need further revisions.

That said, the compilers need to catch up.  GDC is always bit behind, and DMD has several outstanding problems on Linux.  Letting things cook for a few releases would settle this out and improve overall confidence.

Also, this would put more attention on library development within the community, which is desperately needed.  Phobos is still missing several key components such as a GUI and templated containers.  What remains is not very trustworthy.  The only two modules I feel comfortable using right now are std.stdio and std.math.  The rest are highly suspect, especially std.thread.

There needs to be much more critical attention toward the library and runtime, and less pointless bickering over what new features to include.  In other words, it is time to stop worrying about what D should do, and time to discover what it can do.

Walter Bright wrote:
> Bruno Medeiros wrote:
<snip>
>> Something I've been wondering: "but nothing about calling it 1.0 will prevent that from happening." But then what is the point of calling a 1.0 , will there be a branch or some other effect? Or it's just marketing?
> 
> It's simply a stake in the ground. I want to get past the "it's not usable because it's not 1.0" first impressions people sometimes write.

Then make some effort to debunk these impressions.  Don't try to work around them.

Moreover, just think about what will happen when people see 1.0 and expect to see a well-defined language specification, and maybe even to be ready to write a D compiler themselves.  When they find themselves disappointed, just how bad will the negative image be, and how much work will it take to get rid of it?  Moreover, how will compiler writers, and software houses wanting to adopt D, know when it's OK to come back?

Yet another criterion to consider is that the language lives up to its claims.  One of your claims is to make it likely that multiple, correct implementations will be available.  This is impossible as long as the spec still has a number of ill-defined bits.

OTOH, how many people have you counted who have dismissed D just because it isn't at 1.0?  Did any of these people tell you that they would come back at 1.0 no matter what condition 1.0 is in?  I'd be surprised.

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Walter Bright wrote:
>> Bruno Medeiros wrote:
> <snip>
>>> Something I've been wondering: "but nothing about calling it 1.0 will prevent that from happening." But then what is the point of calling a 1.0 , will there be a branch or some other effect? Or it's just marketing?
>>
>> It's simply a stake in the ground. I want to get past the "it's not usable because it's not 1.0" first impressions people sometimes write.
> 
> Then make some effort to debunk these impressions.  Don't try to work around them.

I learned long ago that it is far easier to swim with the current than upstream, especially if one has very limited resources.

> Moreover, just think about what will happen when people see 1.0 and expect to see a well-defined language specification, and maybe even to be ready to write a D compiler themselves.  When they find themselves disappointed, just how bad will the negative image be, and how much work will it take to get rid of it?  Moreover, how will compiler writers, and software houses wanting to adopt D, know when it's OK to come back?

The language spec doesn't need to be at the level of precision of the ISO specs (which took many years and the efforts of a couple dozen people) to produce. People have written compilers for languages with far less. The existence of a stable, reference compiler makes the difference, and these days, having an open source one is key.

> Yet another criterion to consider is that the language lives up to its claims.  One of your claims is to make it likely that multiple, correct implementations will be available.  This is impossible as long as the spec still has a number of ill-defined bits.

No, it's not impossible at all. Heck, I've implemented many compilers for ill-defined languages (including C and C++). I agree the spec is far from perfect, but is it bad enough that it impedes the reasonable learning of D? I don't think so, as the D users do not seem to be having an unreasonable time learning it.


> OTOH, how many people have you counted who have dismissed D just because it isn't at 1.0?

A lot. I don't have a count.

> Did any of these people tell you that they would come back at 1.0 no matter what condition 1.0 is in?  I'd be surprised.

D is probably the most powerful language that ever was at 1.0.

Walter Bright wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.

Provided that the future plans for new syntax don't involve breaking lots of existing code, then I would say yes. I'm not yet convinced that this is true for the future RAII syntax (but I'm not convinced that it isn't true, either).
>>
>> Something I've been wondering: "but nothing about calling it 1.0 will prevent that from happening." But then what is the point of calling a 1.0 , will there be a branch or some other effect? Or it's just marketing?
> 
> It's simply a stake in the ground. I want to get past the "it's not usable because it's not 1.0" first impressions people sometimes write.

It's a lot more than that. It means "this release is officially blessed for building libraries". Right now there are libraries which only work for (say) DMD 0.153 - 0.162, and others which only work for 0.148-0.155.
1.0 is an announcement that all existing libraries need to be updated, and that in the future, they won't be built against completely arbitrary versions.

Walter Bright wrote:
> Bruno Medeiros wrote:
>> Walter Bright wrote:
>>> Any compelling reason why not? I know that everyone (including me) wants more features, more improvements, etc., but nothing about calling it 1.0 will prevent that from happening.
>>
>> Something I've been wondering: "but nothing about calling it 1.0 will prevent that from happening." But then what is the point of calling a 1.0 , will there be a branch or some other effect? Or it's just marketing?
> 
> It's simply a stake in the ground. I want to get past the "it's not usable because it's not 1.0" first impressions people sometimes write.

This is almost OT, but for several Java coders I know, not being able to type

new int[3][4][5]

and

new int[][] {
   { bibi(), bubu() },
   { a+b, c+d }
}

made a _far_ worse first impression than the version number (as in, quote, "you're kidding, right?"). And it seems so simple to implement.. If you ask me, you really need to add those before going 1.0 (it's bad enough for Javans that Interface[] is not Object[] ;)


xs0

xs0 wrote:
> This is almost OT, but for several Java coders I know, not being able to type
> 
> new int[3][4][5]
> 
> and
> 
> new int[][] {
>    { bibi(), bubu() },
>    { a+b, c+d }
> }
> 
> made a _far_ worse first impression than the version number (as in, quote, "you're kidding, right?"). And it seems so simple to implement.. If you ask me, you really need to add those before going 1.0 (it's bad enough for Javans that Interface[] is not Object[] ;)

My experiences with people who won't use D because it doesn't have specific feature X is that they won't use it when feature X is implemented, or when Y, Z, A, B and C are implemented. They're used to the language they currently use, and will never change.

We can easily get sucked into a rat race trying to please people who haven't the slightest inclination to use D (or any language other than the one they currently use).

I'd much rather work on the features the people who have *already* switched to D need to do outrageously cool things.

You mean Java doesn't have free functions? No out parameters? No nested functions? No templates? No versioning? No operator overloading? No lazy evaluation? No 80 bit floats? No stack allocation? No structs? No array slicing? No direct access to C? You're kidding, right? <g>

Walter Bright wrote:
> xs0 wrote:
>> This is almost OT, but for several Java coders I know, not being able to type
>>
>> new int[3][4][5]
>>
>> and
>>
>> new int[][] {
>>    { bibi(), bubu() },
>>    { a+b, c+d }
>> }
>>
>> made a _far_ worse first impression than the version number (as in, quote, "you're kidding, right?"). And it seems so simple to implement.. If you ask me, you really need to add those before going 1.0 (it's bad enough for Javans that Interface[] is not Object[] ;)
> 
> My experiences with people who won't use D because it doesn't have specific feature X is that they won't use it when feature X is implemented, or when Y, Z, A, B and C are implemented. They're used to the language they currently use, and will never change.

Oh no, not the same old story.

> 
> We can easily get sucked into a rat race trying to please people who haven't the slightest inclination to use D (or any language other than the one they currently use).

This sure wouldn't be a good thing, but...

> 
> I'd much rather work on the features the people who have *already* switched to D need to do outrageously cool things.

I have been programming in D for years and I love it. It is just great how D does arrays. Well, most of the time.

We have such a great language that can do so many cool things with arrays. Yes but to be able to do something with an array you first have to create an array. And this task is incredibly difficult for such a basic thing in such a high level language.

Creating arrays and filling them with data sucks in D (I am saying that as someone who is programming in D (although not as much as I would like to)). I didn't just switch to D and start complaining that this and that is missing, my complaints (and of other long time users) comes from actually *using* D.


> 
> You mean Java doesn't have free functions? No out parameters? No nested functions? No templates? No versioning? No operator overloading? No lazy evaluation? No 80 bit floats? No stack allocation? No structs? No array slicing? No direct access to C? You're kidding, right? <g>

D has dynamically resizable arrays, you can slice them, pass them around without no problems, add extension methods to them, but you can't initialize them? Who is kidding here? <g>

Walter Bright wrote:
> xs0 wrote:
>> This is almost OT, but for several Java coders I know, not being able to type
>>
>> new int[3][4][5]
>>
>> and
>>
>> new int[][] {
>>    { bibi(), bubu() },
>>    { a+b, c+d }
>> }
>>
>> made a _far_ worse first impression than the version number (as in, quote, "you're kidding, right?"). And it seems so simple to implement.. If you ask me, you really need to add those before going 1.0 (it's bad enough for Javans that Interface[] is not Object[] ;)
> 
> My experiences with people who won't use D because it doesn't have specific feature X is that they won't use it when feature X is implemented, or when Y, Z, A, B and C are implemented. They're used to the language they currently use, and will never change.
> 
> We can easily get sucked into a rat race trying to please people who haven't the slightest inclination to use D (or any language other than the one they currently use).

Well, I somewhat disagree. My company is more or less strictly Java, but when I made a internal presentation on D, a surprising number of people showed up and most of them seemed genuinely interested/fascinated. So, I don't think it's the case that they don't have the slightest inclination to use something else.

> I'd much rather work on the features the people who have *already* switched to D need to do outrageously cool things.

> You mean Java doesn't have free functions? No out parameters? No nested functions? No templates? No versioning? No operator overloading? No lazy evaluation? No 80 bit floats? No stack allocation? No structs? No array slicing? No direct access to C? You're kidding, right? <g>

I 100% agree Java is lacking in many ways (and to be fair, it has some advantages, too), but if you're aiming for a good first impression, you also need to care of the basic stuff. The two things I mentioned seem so basic for a language with dynamic arrays, that I totally fail to understand why you're so reluctant to implement them; considering the unofficial wish list, I'm not the only one. Would you care for any language that (regardless of other features) made you type "return a+b" like this:

accumulator foo;
foo.add(a);
foo.add(b);
return foo.result;

Now, consider the remarkable similarity between that case and "auto foo = new int[3][4][5]" versus

int[][][] foo;
foo.length = 3;
for (int a=0; a<3; a++) {
    foo[a].length = 4;
    for (int b=0; b<4; b++)
        foo[a][b].length = 5;
}


xs0

xs0 wrote:
> Walter Bright wrote:
>> xs0 wrote:
>>> This is almost OT, but for several Java coders I know, not being able to type
>>>
>>> new int[3][4][5]
>>>
>>> and
>>>
>>> new int[][] {
>>>    { bibi(), bubu() },
>>>    { a+b, c+d }
>>> }
>>>
>>> made a _far_ worse first impression than the version number (as in, quote, "you're kidding, right?"). And it seems so simple to implement.. If you ask me, you really need to add those before going 1.0 (it's bad enough for Javans that Interface[] is not Object[] ;)
>>
>> My experiences with people who won't use D because it doesn't have specific feature X is that they won't use it when feature X is implemented, or when Y, Z, A, B and C are implemented. They're used to the language they currently use, and will never change.
>>
>> We can easily get sucked into a rat race trying to please people who haven't the slightest inclination to use D (or any language other than the one they currently use).
> 
> Well, I somewhat disagree. My company is more or less strictly Java, but when I made a internal presentation on D, a surprising number of people showed up and most of them seemed genuinely interested/fascinated. So, I don't think it's the case that they don't have the slightest inclination to use something else.
> 
>> I'd much rather work on the features the people who have *already* switched to D need to do outrageously cool things.
> 
>> You mean Java doesn't have free functions? No out parameters? No nested functions? No templates? No versioning? No operator overloading? No lazy evaluation? No 80 bit floats? No stack allocation? No structs? No array slicing? No direct access to C? You're kidding, right? <g>
> 
> I 100% agree Java is lacking in many ways (and to be fair, it has some advantages, too), but if you're aiming for a good first impression, you also need to care of the basic stuff. The two things I mentioned seem so basic for a language with dynamic arrays, that I totally fail to understand why you're so reluctant to implement them; considering the unofficial wish list, I'm not the only one. Would you care for any language that (regardless of other features) made you type "return a+b" like this:
> 
> accumulator foo;
> foo.add(a);
> foo.add(b);
> return foo.result;
> 
> Now, consider the remarkable similarity between that case and "auto foo = new int[3][4][5]" versus

Actually this works. But foo cannot be initialized with an initializer.