www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Tuples, C#, Java, language design

reply bearophile <bearophileHUGS lycos.com> writes:
C# will probably not follow the route of stagnation of Java for some more time,
thanks to Mono too. I don't like that string interpolation syntax because it
looks unsafe, and that design of tuples can be improved, but they are listening
to programmes (even if they risk creating a mudball language):
http://www.infoq.com/news/2009/12/Mono-CSharp-Ex

More on those tuples:
http://tirania.org/blog/archive/2009/Dec-23.html

Eventually it will be quite useful to have some very well designed multi-return
support in D (like those tuples, but better).

Bye,
bearophile
Dec 28 2009
parent reply justme <justme somewhere.net> writes:
bearophile Wrote:

 C# will probably not follow the route of stagnation of Java for some more
time, thanks to Mono too. I don't like that string interpolation syntax because
it looks unsafe, and that design of tuples can be improved, but they are
listening to programmes (even if they risk creating a mudball language):
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex
 
 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html
 
 Eventually it will be quite useful to have some very well designed
multi-return support in D (like those tuples, but better).

Doesn't D2 already have tuples in Phobos. D has the comma operator which C# doesn't so such syntax is not possible in D, me thinks.
Dec 29 2009
next sibling parent reply grauzone <none example.net> writes:
justme wrote:
 bearophile Wrote:
 
 C# will probably not follow the route of stagnation of Java for some more
time, thanks to Mono too. I don't like that string interpolation syntax because
it looks unsafe, and that design of tuples can be improved, but they are
listening to programmes (even if they risk creating a mudball language):
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex

 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html

 Eventually it will be quite useful to have some very well designed
multi-return support in D (like those tuples, but better).

Doesn't D2 already have tuples in Phobos. D has the comma operator which C# doesn't so such syntax is not possible in D, me thinks.

But tuples in D really suck. Compared to other languages, D tuples feel inflexible, stiff, and complicated.
Dec 29 2009
parent reply justme <justme somewhere.net> writes:
grauzone Wrote:

 justme wrote:
 bearophile Wrote:
 
 C# will probably not follow the route of stagnation of Java for some more
time, thanks to Mono too. I don't like that string interpolation syntax because
it looks unsafe, and that design of tuples can be improved, but they are
listening to programmes (even if they risk creating a mudball language):
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex

 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html

 Eventually it will be quite useful to have some very well designed
multi-return support in D (like those tuples, but better).

Doesn't D2 already have tuples in Phobos. D has the comma operator which C# doesn't so such syntax is not possible in D, me thinks.

But tuples in D really suck. Compared to other languages, D tuples feel inflexible, stiff, and complicated.

The burden of proving your claims is still there. Isn't D meritocracy - nobody listens your opinions unless you post compiler / stdlib patches. I believe the Phobos tuple classes are sufficient until a better system arrives in D3 or D4. D2 book is almost finished so you need to write your patches against D3 now.
Dec 29 2009
parent reply grauzone <none example.net> writes:
justme wrote:
 grauzone Wrote:
 
 justme wrote:
 bearophile Wrote:

 C# will probably not follow the route of stagnation of Java for some more
time, thanks to Mono too. I don't like that string interpolation syntax because
it looks unsafe, and that design of tuples can be improved, but they are
listening to programmes (even if they risk creating a mudball language):
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex

 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html

 Eventually it will be quite useful to have some very well designed
multi-return support in D (like those tuples, but better).


inflexible, stiff, and complicated.

The burden of proving your claims is still there. Isn't D meritocracy - nobody listens your opinions unless you post compiler / stdlib patches. I believe the Phobos tuple classes are sufficient until a better system arrives in D3 or D4. D2 book is almost finished so you need to write your patches against D3 now.

My experience with patches is, that they're mostly either ignored or rejected. I guess the chance of an unrequested patch changing a core language feature in crucial ways is 200%. Walter doesn't listen to anyone anyway *g*. The downsides of D tuples has been often mentioned, e.g. here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=98953 (Sorry, I'm not as eloquent as language_fan to write it up myself, plus nobody would read it.)
Dec 29 2009
parent grauzone <none example.net> writes:
grauzone wrote:
 justme wrote:
 grauzone Wrote:

 justme wrote:
 bearophile Wrote:

 C# will probably not follow the route of stagnation of Java for 
 some more time, thanks to Mono too. I don't like that string 
 interpolation syntax because it looks unsafe, and that design of 
 tuples can be improved, but they are listening to programmes (even 
 if they risk creating a mudball language):
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex

 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html

 Eventually it will be quite useful to have some very well designed 
 multi-return support in D (like those tuples, but better).

which C# doesn't so such syntax is not possible in D, me thinks.

feel inflexible, stiff, and complicated.

The burden of proving your claims is still there. Isn't D meritocracy - nobody listens your opinions unless you post compiler / stdlib patches. I believe the Phobos tuple classes are sufficient until a better system arrives in D3 or D4. D2 book is almost finished so you need to write your patches against D3 now.

My experience with patches is, that they're mostly either ignored or rejected. I guess the chance of an unrequested patch changing a core language feature in crucial ways is 200%. Walter doesn't listen to anyone anyway *g*. The downsides of D tuples has been often mentioned, e.g. here: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmar .D&article_id=98953

That was incomplete. You have to compare the code examples with the D version: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=98947
 (Sorry, I'm not as eloquent as language_fan to write it up myself, plus 
 nobody would read it.)

Dec 29 2009
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello justme,

 bearophile Wrote:
 
 C# will probably not follow the route of stagnation of Java for some
 more time, thanks to Mono too. I don't like that string interpolation
 syntax because it looks unsafe, and that design of tuples can be
 improved, but they are listening to programmes (even if they risk
 creating a mudball language):
 
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex
 
 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html
 Eventually it will be quite useful to have some very well designed
 multi-return support in D (like those tuples, but better).
 

which C# doesn't so such syntax is not possible in D, me thinks.

A though on the comma operator: if the comma operator were defined to give a tuple type and be implicitly castable to any suffix of it's self, then you could get both the comma expression usage that Walter wants as well as all the fun things that tuple expressions give. int i = 1, j = 2; (i, j) = (j, i); // swap i = (j+= i, i*2 + j); // first expression gets evaluated and dropped. Thoughts?
Dec 29 2009
next sibling parent reply grauzone <none example.net> writes:
BCS wrote:
 Hello justme,
 
 bearophile Wrote:

 C# will probably not follow the route of stagnation of Java for some
 more time, thanks to Mono too. I don't like that string interpolation
 syntax because it looks unsafe, and that design of tuples can be
 improved, but they are listening to programmes (even if they risk
 creating a mudball language):

 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex

 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html
 Eventually it will be quite useful to have some very well designed
 multi-return support in D (like those tuples, but better).

which C# doesn't so such syntax is not possible in D, me thinks.

A though on the comma operator: if the comma operator were defined to give a tuple type and be implicitly castable to any suffix of it's self, then you could get both the comma expression usage that Walter wants as well as all the fun things that tuple expressions give. int i = 1, j = 2; (i, j) = (j, i); // swap i = (j+= i, i*2 + j); // first expression gets evaluated and dropped. Thoughts?

Why not make the programmer write tuple[$-1] instead? i = (j += i, i*2 + j)[$-1]; There's no reason to keep the current comma operator.
 

Dec 29 2009
next sibling parent reply BCS <none anon.com> writes:
Hello grauzone,

 BCS wrote:
 
 Hello justme,
 
 bearophile Wrote:
 
 C# will probably not follow the route of stagnation of Java for
 some more time, thanks to Mono too. I don't like that string
 interpolation syntax because it looks unsafe, and that design of
 tuples can be improved, but they are listening to programmes (even
 if they risk creating a mudball language):
 
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex
 
 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html
 Eventually it will be quite useful to have some very well designed
 multi-return support in D (like those tuples, but better).

which C# doesn't so such syntax is not possible in D, me thinks.

give a tuple type and be implicitly castable to any suffix of it's self, then you could get both the comma expression usage that Walter wants as well as all the fun things that tuple expressions give. int i = 1, j = 2; (i, j) = (j, i); // swap i = (j+= i, i*2 + j); // first expression gets evaluated and dropped. Thoughts?

i = (j += i, i*2 + j)[$-1]; There's no reason to keep the current comma operator.

Frankly, while I have no problem with it, I'd also be fine with dumping the comma operator all together, even making the [$-1] thing illegal ("code has no effect" and all that) but Walter has time and again shot down anything that does away with the comma operator so I was looking at it as a way to have my cake and eat it to.
Dec 29 2009
parent "Joel C. Salomon" <joelcsalomon gmail.com> writes:
On 12/30/2009 12:38 AM, BCS wrote:
 Hello grauzone,
 Why not make the programmer write tuple[$-1] instead?

 i = (j += i, i*2 + j)[$-1];

 There's no reason to keep the current comma operator.

Frankly, while I have no problem with it, I'd also be fine with dumping the comma operator all together, even making the [$-1] thing illegal ("code has no effect" and all that) but Walter has time and again shot down anything that does away with the comma operator so I was looking at it as a way to have my cake and eat it to.

Can the comma operator be given a different symbol to use? How about, e.g., a double comma: auto i = 1, 2; // tuple auto j = 1,,2; // sequence operator —Joel
Dec 30 2009
prev sibling parent retard <re tard.com.invalid> writes:
Wed, 30 Dec 2009 21:30:14 -0500, Joel C. Salomon wrote:

 On 12/30/2009 12:38 AM, BCS wrote:
 Hello grauzone,
 Why not make the programmer write tuple[$-1] instead?

 i = (j += i, i*2 + j)[$-1];

 There's no reason to keep the current comma operator.

Frankly, while I have no problem with it, I'd also be fine with dumping the comma operator all together, even making the [$-1] thing illegal ("code has no effect" and all that) but Walter has time and again shot down anything that does away with the comma operator so I was looking at it as a way to have my cake and eat it to.

Can the comma operator be given a different symbol to use? How about, e.g., a double comma: auto i = 1, 2; // tuple auto j = 1,,2; // sequence operator

Wouldn't that break the C compatibility?
Dec 31 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
BCS:
 A though on the comma operator: if the comma operator were defined to give 
 a tuple type and be implicitly castable to any suffix of it's self, then 
 you could get both the comma expression usage that Walter wants as well as 
 all the fun things that tuple expressions give.

D2 has enough warts now, so it's much better to not add some more. Languages must be tidy, when possible. It's often better to not have a feature that having a dirty one. Bye, bearophile
Dec 29 2009
parent reply grauzone <none example.net> writes:
bearophile wrote:
 BCS:
 A though on the comma operator: if the comma operator were defined to give 
 a tuple type and be implicitly castable to any suffix of it's self, then 
 you could get both the comma expression usage that Walter wants as well as 
 all the fun things that tuple expressions give.

D2 has enough warts now, so it's much better to not add some more. Languages must be tidy, when possible. It's often better to not have a feature that having a dirty one.

I think in this case, it's more about cleaning up and polishing, than adding "warts". The big danger is, that this may require incompatible language changes, which won't be possible anymore after D2. D3? Anyone who talks about D3 must be kidding.
 Bye,
 bearophile

Dec 30 2009
parent reply justme <justme somewhere.net> writes:
grauzone Wrote:

 bearophile wrote:
 BCS:
 A though on the comma operator: if the comma operator were defined to give 
 a tuple type and be implicitly castable to any suffix of it's self, then 
 you could get both the comma expression usage that Walter wants as well as 
 all the fun things that tuple expressions give.

D2 has enough warts now, so it's much better to not add some more. Languages must be tidy, when possible. It's often better to not have a feature that having a dirty one.

I think in this case, it's more about cleaning up and polishing, than adding "warts". The big danger is, that this may require incompatible language changes, which won't be possible anymore after D2. D3? Anyone who talks about D3 must be kidding.

So D3 won't ever appear? At least in many open source projects the final released is tagged one to two weeks before the final release. Distributions have then time to repackage the release. Meanwhile, the core developers are already enthusiastically implementing wild new features after a long feature freeze. It's similar kind of tick-tock as Intel has with their CPU line (1 smaller process -> 2 improved core -> goto 1). In successful software projects they have alpha/beta period, feature freeze, stabilization period, release, new alpha/beta period etc. Concurrently new bugfix releases come out just like with D. I haven't heard of new features lately so D2 must be stabilizing now.
Dec 30 2009
next sibling parent reply Don <nospam nospam.com> writes:
Denis Koroskin wrote:
 On Wed, 30 Dec 2009 15:41:58 +0300, justme <justme somewhere.net> wrote:
 
 grauzone Wrote:

 bearophile wrote:
 BCS:
 A though on the comma operator: if the comma operator were defined 


 a tuple type and be implicitly castable to any suffix of it's 


 you could get both the comma expression usage that Walter wants as 


 all the fun things that tuple expressions give.

D2 has enough warts now, so it's much better to not add some more.

a feature that having a dirty one. I think in this case, it's more about cleaning up and polishing, than adding "warts". The big danger is, that this may require incompatible language changes, which won't be possible anymore after D2. D3? Anyone who talks about D3 must be kidding.

So D3 won't ever appear? At least in many open source projects the final released is tagged one to two weeks before the final release. Distributions have then time to repackage the release. Meanwhile, the core developers are already enthusiastically implementing wild new features after a long feature freeze. It's similar kind of tick-tock as Intel has with their CPU line (1 smaller process -> 2 improved core -> goto 1). In successful software projects they have alpha/beta period, feature freeze, stabilization period, release, new alpha/beta period etc. Concurrently new bugfix releases come out just like with D. I haven't heard of new features lately so D2 must be stabilizing now.

According to development stages you provided, D2 is currently in alpha/beta period. Feature freeze will follow once TDPL is released (around March, 2010). Stabilization and release is even further, and D3 is sooo far away it's hardly imagineable we will see any signs of it in a foreseeable future :)

Yes, that's about right. Let's get an estimate about stablisation: There are 1400 open bugs (DMD+Phobos), which are currently being fixed at the rate of 50/month. Historically, new bugs have been found at the rate of 66/month. Since D2 began, 50% of the open bugs have been D2-only. So, 50% of the bugs have been related to new features. Which would suggest that even if the bug rate halves when after the feature freeze, it'll be about 5 years until the bug count drops to zero... :-( Actually, I don't think it's that bad, since some of the most important structural compiler bugs have been fixed, which should greatly reduce the rate that new bugs are found. Even so, I'd recommend at least two years of bug-fixes and library development (and toolchain issues), before we even think about more features.
Dec 30 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Don:
 I'd recommend at least two years of bug-fixes and library 
 development (and toolchain issues), before we even think about more 
 features.

There are two other important thing that can be done in that stabilizing period: 1) find where are the D2 design mistakes and invent better ways to design the same features. 2) Invent new ways to use D2 language (this has happened too all major languages, for example the introduction of the many lazy features of Python3 doesn't come after design of Python2, it comes from the slow invention of new ways to use Python, partially invented by R. Hettinger. Later some of such ideas are being moved from the std library (itertools) to the language itself (the built-in map and filter become lazy, etc)). Bye, bearophile
Dec 30 2009
prev sibling parent grauzone <none example.net> writes:
justme wrote:
 grauzone Wrote:
 
 bearophile wrote:
 BCS:
 A though on the comma operator: if the comma operator were
 defined to give a tuple type and be implicitly castable to any
 suffix of it's self, then you could get both the comma
 expression usage that Walter wants as well as all the fun
 things that tuple expressions give.

more. Languages must be tidy, when possible. It's often better to not have a feature that having a dirty one.

than adding "warts". The big danger is, that this may require incompatible language changes, which won't be possible anymore after D2. D3? Anyone who talks about D3 must be kidding.


On the other hand, one could introduce "fixed tuples" as a new feature, that doesn't touch the old tuples. It would be annoying, but allows for perfect backwards compatibility.
 So D3 won't ever appear? At least in many open source projects the
 final released is tagged one to two weeks before the final release.
 Distributions have then time to repackage the release. Meanwhile, the
 core developers are already enthusiastically implementing wild new
 features after a long feature freeze.

D3 would just mean "incompatible to D2". The "final" version of D1 (dmd 1.000) was released on Jan 2, 2007, and the first version of D2 (dmd 2.000) on Jun 17, 2007. Can't let that happen again. But adding features after finalization in a backward compatible way would be nice. Other languages can do it too, why not D?
 It's similar kind of tick-tock as Intel has with their CPU line (1
 smaller process -> 2 improved core -> goto 1). In successful software
 projects they have alpha/beta period, feature freeze, stabilization
 period, release, new alpha/beta period etc. Concurrently new bugfix
 releases come out just like with D. I haven't heard of new features
 lately so D2 must be stabilizing now.

That isn't the case. Have a look at the "New/Changed Features" section in the changelog: http://www.digitalmars.com/d/2.0/changelog.html
Dec 31 2009
prev sibling parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
BCS wrote:

 Hello justme,
 
 bearophile Wrote:
 
 C# will probably not follow the route of stagnation of Java for some
 more time, thanks to Mono too. I don't like that string interpolation
 syntax because it looks unsafe, and that design of tuples can be
 improved, but they are listening to programmes (even if they risk
 creating a mudball language):
 
 http://www.infoq.com/news/2009/12/Mono-CSharp-Ex
 
 More on those tuples:
 http://tirania.org/blog/archive/2009/Dec-23.html
 Eventually it will be quite useful to have some very well designed
 multi-return support in D (like those tuples, but better).
 

which C# doesn't so such syntax is not possible in D, me thinks.

A though on the comma operator: if the comma operator were defined to give a tuple type and be implicitly castable to any suffix of it's self, then you could get both the comma expression usage that Walter wants as well as all the fun things that tuple expressions give. int i = 1, j = 2; (i, j) = (j, i); // swap i = (j+= i, i*2 + j); // first expression gets evaluated and dropped. Thoughts?

I have had the same idea and thinking about it I have not found any problems with it. So I would get hapy if it was implementet. When tupples where first introduced in D the ovious problems with them was the auto flattening and lack of literal syntax, fixing that would probably make using tuoples much nicer. (Allowing things like multiple return value as used in matlab)
Dec 30 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 30 Dec 2009 15:41:58 +0300, justme <justme somewhere.net> wrote:

 grauzone Wrote:

 bearophile wrote:
 BCS:
 A though on the comma operator: if the comma operator were defined  


 a tuple type and be implicitly castable to any suffix of it's self,  


 you could get both the comma expression usage that Walter wants as  


 all the fun things that tuple expressions give.

D2 has enough warts now, so it's much better to not add some more.

feature that having a dirty one. I think in this case, it's more about cleaning up and polishing, than adding "warts". The big danger is, that this may require incompatible language changes, which won't be possible anymore after D2. D3? Anyone who talks about D3 must be kidding.

So D3 won't ever appear? At least in many open source projects the final released is tagged one to two weeks before the final release. Distributions have then time to repackage the release. Meanwhile, the core developers are already enthusiastically implementing wild new features after a long feature freeze. It's similar kind of tick-tock as Intel has with their CPU line (1 smaller process -> 2 improved core -> goto 1). In successful software projects they have alpha/beta period, feature freeze, stabilization period, release, new alpha/beta period etc. Concurrently new bugfix releases come out just like with D. I haven't heard of new features lately so D2 must be stabilizing now.

According to development stages you provided, D2 is currently in alpha/beta period. Feature freeze will follow once TDPL is released (around March, 2010). Stabilization and release is even further, and D3 is sooo far away it's hardly imagineable we will see any signs of it in a foreseeable future :)
Dec 30 2009