www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D2 Closure

reply Steve Teale <steve.teale britseyeview.com> writes:
Just a few days ago, Walter was talking about 'the final feature'. Andrei 
is going through the tedious and unpleasant process of finalizing TDPL 
with his publisher. In a minute it will be March, so to get anything 
finalized by the summer of 2010 is already looking like a stretch.

Now we have a whole new slew of suggestions for change.

I think that at some point the membership of digitalmars.D needs to 
accept that there is a deadline, and that further discussion of the ideal 
language refers to D3.

Another provocative way of thinking about this is that D2 is already 'E', 
unless the faithful users of D1 and Tango are to be unceremoniously 
dumped. In that case, the discussions that have suddenly flared up now 
are about 'F'.

Time to choose. Will D ever be a widely used programming language, or is 
it just a excellent vehicle for discussion of programming language 
features?

Steve
Feb 17 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steve Teale wrote:
 Just a few days ago, Walter was talking about 'the final feature'. Andrei 
 is going through the tedious and unpleasant process of finalizing TDPL 
 with his publisher. In a minute it will be March, so to get anything 
 finalized by the summer of 2010 is already looking like a stretch.
 
 Now we have a whole new slew of suggestions for change.
 
 I think that at some point the membership of digitalmars.D needs to 
 accept that there is a deadline, and that further discussion of the ideal 
 language refers to D3.
 
 Another provocative way of thinking about this is that D2 is already 'E', 
 unless the faithful users of D1 and Tango are to be unceremoniously 
 dumped. In that case, the discussions that have suddenly flared up now 
 are about 'F'.
 
 Time to choose. Will D ever be a widely used programming language, or is 
 it just a excellent vehicle for discussion of programming language 
 features?
 
 Steve

assert(cat !in bag); D2 has officially been frozen. There is no major breaking change we can make at this moment. Defining features that don't change the semantics of existing code is possible, but will be undocumented at least in the first print of TDPL. Andrei
Feb 17 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 D2 has officially been frozen.

Congratulations to Walter and you then :-)
 There is no major breaking change we can 
 make at this moment. Defining features that don't change the semantics 
 of existing code is possible, but will be undocumented at least in the 
 first print of TDPL.

There is a certain amount of features already partially implemented or partially broken than can be fixed and finished from now on. A little example: I think this doesn't compile yet (the compiler can't find std.math.sqrt): void main() { double x = 5 ^^ 0.5; } Bye, bearophile
Feb 17 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 D2 has officially been frozen.

Congratulations to Walter and you then :-)

Thanks much.
 There is no major breaking change we can 
 make at this moment. Defining features that don't change the semantics 
 of existing code is possible, but will be undocumented at least in the 
 first print of TDPL.

There is a certain amount of features already partially implemented or partially broken than can be fixed and finished from now on. A little example: I think this doesn't compile yet (the compiler can't find std.math.sqrt): void main() { double x = 5 ^^ 0.5; }

Please bugzillize. Generally this is the time to align the implementation with the book and also to put it in great shape. Walter and I needed to make a lot of microdecisions in the past weeks, which put pressure on the implementation. But I am happy to report that it generally feels that we're turning the right corners. Regarding the recent debate regarding signed and unsigned numbers, I have great faith in value range propagation. Andrei
Feb 17 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Recently I think Walter has said something about this, but then he was probably
too much busy: I'd like to read an article written by Walter that contains a
list of the things that D2 does wrong. (Among then I'd like to put that default
storage type is mutable instead of immutable, as I have written in a recent
post).

Such list can be divided in parts:
1) Some quite important missing things, that can be added later, in D2+ or D3.
2) Errors that somehow can be fixed, if necessary deprecating a feature that
we'll just stop using, so we'll use another feature that replaces it.
3) Little or larger errors that are not easy to fix in future, design mistakes
that we'll have to live with.

This list is useful for future D2 users to know how to use the language better,
for future designers of similar languages, and of course people here will try
to invent ways to move some items from the third list to the second list in D3
:-)

Bye,
bearophile
Feb 17 2010
parent reply Martin Franklin <martin246564 btinternet.com> writes:
retard Wrote:

 That sounds like heresy :) Would anyone in D community really switch to 
 some other language? I'm sure there's a strong emotional bond already. 
 Even badly designed features and bugs can be seen as a strength if your 
 opinion is heavily biased. Learning a language is an investment. If 
 you've invested lot of time and effort in a language, all kinds of 
 feelings such as bitterness and frustation come up.
 

Its time to dump C-like languages - I have the evidence. http://www.modulaware.com/mdlt28.htm
Feb 18 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-18 12:18:47 -0500, Martin Franklin 
<martin246564 btinternet.com> said:

 Its time to dump C-like languages - I have the evidence.
 
 http://www.modulaware.com/mdlt28.htm

Nice read... and it gives me a new feature idea for D! The article rants about default parameters not being very useful when you have more than one (something I agree with), then propose an improvement:
 Furthermore, they do not provide a great deal of convenience. If a 
 routine has five parameters, the last three of which are optional, and 
 caller wants to assume the defaults for parameters 3 and 4, but must 
 specify parameter 5, then all five parameters must be specified. A 
 better scheme would be to have a default keyword in function calls:
 
 f (a, b, default, default, e);

Would't that be nice to be able to use the 'default' keyword when you want to use the default value for a parameter? Should be pretty trivial to implement. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 18 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Michel Fortin wrote:

 Would't that be nice to be able to use the 'default' keyword when you
 want to use the default value for a parameter? Should be pretty trivial
 to implement.

Except that to some extent, that would defeat the purpose of default parameters. Part of the idea is that you don't have to worry about their existence unless you actually want to change them. If you're going to have to put the word default there, then in many cases, you might as well just put an actual value yourself. The one thing that word default would give you would be the ability to choose the the default value for parameters in the middle of the parameter list and still give values for parameters at the end. But that's just extra complication and likely wouldn't be worth the benefit. - Jonathan M Davis
Feb 18 2010
next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-02-18 16:11:39 -0500, Jonathan M Davis <jmdavisProg gmail.com> said:

 Michel Fortin wrote:
 
 Would't that be nice to be able to use the 'default' keyword when you
 want to use the default value for a parameter? Should be pretty trivial
 to implement.

Except that to some extent, that would defeat the purpose of default parameters. Part of the idea is that you don't have to worry about their existence unless you actually want to change them. If you're going to have to put the word default there, then in many cases, you might as well just put an actual value yourself. The one thing that word default would give you would be the ability to choose the the default value for parameters in the middle of the parameter list and still give values for parameters at the end. But that's just extra complication and likely wouldn't be worth the benefit.

I don't see the complication you talk about. It's no complication unless you use it, and if you feel the need to use it it's probably because there's a benefit. You can still call functions with default parameters by omitting the parameters if you want, I'm not trying to change that. void test(int a = 1, int b = 2); test(); // same as test(1, 2); test(8); // same as test(8, 2); test(default, 8); // same as test(1, 8); <- here it's useful -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Feb 18 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-02-18 22.11, Jonathan M Davis wrote:
 Michel Fortin wrote:

 Would't that be nice to be able to use the 'default' keyword when you
 want to use the default value for a parameter? Should be pretty trivial
 to implement.

Except that to some extent, that would defeat the purpose of default parameters. Part of the idea is that you don't have to worry about their existence unless you actually want to change them. If you're going to have to put the word default there, then in many cases, you might as well just put an actual value yourself. The one thing that word default would give you would be the ability to choose the the default value for parameters in the middle of the parameter list and still give values for parameters at the end. But that's just extra complication and likely wouldn't be worth the benefit. - Jonathan M Davis

That sounds like named parameters, which could be nice to have.
Feb 18 2010
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Michel Fortin wrote:
 On 2010-02-18 12:18:47 -0500, Martin Franklin 
 <martin246564 btinternet.com> said:
 
 Its time to dump C-like languages - I have the evidence.

 http://www.modulaware.com/mdlt28.htm

Nice read...

Very interesting indeed. It was written in 1992 and it's really fascinating to put this in historical perspective, considering what happened to the languages involved. As they say in chess - never ignore the whole for the beauty of the part. Andrei
Feb 18 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:hlk4le$13ht$1 digitalmars.com...
 On 2010-02-18 12:18:47 -0500, Martin Franklin 
 <martin246564 btinternet.com> said:

 Its time to dump C-like languages - I have the evidence.

 http://www.modulaware.com/mdlt28.htm

Nice read... and it gives me a new feature idea for D! The article rants about default parameters not being very useful when you have more than one (something I agree with), then propose an improvement:
 Furthermore, they do not provide a great deal of convenience. If a 
 routine has five parameters, the last three of which are optional, and 
 caller wants to assume the defaults for parameters 3 and 4, but must 
 specify parameter 5, then all five parameters must be specified. A better 
 scheme would be to have a default keyword in function calls:

 f (a, b, default, default, e);

Would't that be nice to be able to use the 'default' keyword when you want to use the default value for a parameter? Should be pretty trivial to implement.

VBScript (Or maybe it's just VB6. Not sure about VB.NET) allows the above by doing this: f (a, b, , , e) That's the one thing about VB that I actually kinda liked. Of coruse, it may not be a perfect approach, but at least you *can* leave middle params as default.
Feb 21 2010
next sibling parent Nathan Tuggy <bugzilla nathan.tuggycomputer.com> writes:
On 2010-02-21 21:50, Nick Sabalausky wrote:
 VBScript (Or maybe it's just VB6. Not sure about VB.NET) allows the above by
 doing this:

 f (a, b, , , e)

 That's the one thing about VB that I actually kinda liked. Of coruse, it may
 not be a perfect approach, but at least you *can* leave middle params as
 default.

Yeah, I like that feature too (I have to use VB a lot for work; I freely admit to being something of a "quiche-eating" programmer, with aspirations to D). Note that VB 4-6 (and probably earlier), VBScript, and VB.NET all allow that syntax. In fact, C# programmers apparently liked it as well; it's a feature that was recently added to C# 4, which is still in beta. -- ‖ Insert clever saying here… ‖ http://tagzilla.mozdev.org v0.066
Feb 21 2010
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 "Michel Fortin
 f (a, b, default, default, e);



The syntax with just commas is shorter but you can miss commas, so I prefer the version with the default keyword, because it's more syntactically visible by the programmer's eye. Here saving the 'default' keystrokes doesn't look like an improvement. I'd like to have named function arguments, even if partially implemented (there are cases with delegates/function pointers where you need to do more changes if you want to fully support named arguments, I've discussed this in the past. Such cases can be omitted in the first implementation of this feature), because in some situations they can increase code readability, and code readability can lower bug count and increase coding speed. (I don't know how the last C# has implemented this feature). Named arguments and that syntax to omit default arguments in the middle can be used for similar purposes: void foo(int a=1, int b=2, int c=3) {...} foo(5, , 3); foo(5, default, 3); foo(a=5, c=3); foo(5, c=3); But this feature can be added later, I think it's an additive change. What's instead more important to discuss first are features for D2 that can't be just be added later, because they aren't just additive changes because they need changes not backwards compatible with D1 (or with the precedent version of D2). This is how the list of changes in Python3 was chosen: the minimal number of changes that are not backwards compatible with Python2.x minus the additive changes. All the other things that can be just added were postponed to Python3.1 or later. This is a good design strategy that I have not seen explicitly expressed in this newsgroup :-( I am sorry for not thinking and writing this comments few months ago, because now it's not that useful. Bye, bearophile
Feb 22 2010