www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D3 is potentially damaging

reply "ixid" <nuaccount gmail.com> writes:
The idea of D3 is a worrying one- it suggests a number of things 
that would not be good for the success and adoption of the 
language. That the language is experimental and more of a pet 
project, that D2 has a shelf-life and will be abandoned. I can 
see D going in two directions: it can gradually grow and 
progressively gain areas where it's the standard choice or it 
will be a fairly small community of fans of an eternal language 
project. Python 2 and 3 has been a very messy split, while 
languages with a greater sense of continuity do better for it in 
my view, having one standard version of that language. Breaking 
changes may be desirable but I don't think labelling that as 
v2/v3 is a good idea, make it one thing with one suggested 
version.

What are the aims of D3 that aren't aims of D2? What could be 
done then that can't be done now? Wouldn't it be better to make 
breaking changes sooner rather than later?
May 01 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 02-05-2012 03:08, ixid wrote:
 The idea of D3 is a worrying one- it suggests a number of things that
 would not be good for the success and adoption of the language. That the
 language is experimental and more of a pet project, that D2 has a
 shelf-life and will be abandoned. I can see D going in two directions:
 it can gradually grow and progressively gain areas where it's the
 standard choice or it will be a fairly small community of fans of an
 eternal language project. Python 2 and 3 has been a very messy split,
 while languages with a greater sense of continuity do better for it in
 my view, having one standard version of that language. Breaking changes
 may be desirable but I don't think labelling that as v2/v3 is a good
 idea, make it one thing with one suggested version.
I agree wholeheartedly. This whole "D3" excuse for not fixing design issues in the language is going to hurt us in the long run.
 What are the aims of D3 that aren't aims of D2? What could be done then
 that can't be done now? Wouldn't it be better to make breaking changes
 sooner rather than later?
Yes and no. In theory, it's good to stabilize the language now and make a new version of it later which has breaking changes. In practice, that's annoying as hell. We've already seen how slow the transition from D1 to D2 is (not was; it's still happening!). D2 to D3 is going to be even slower (see in particular your Python 2 vs 3 example) simply because more and more people are going to be using D2 and therefore can't afford to port their applications to D3. -- - Alex
May 01 2012
next sibling parent reply "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Wednesday, 2 May 2012 at 01:11:52 UTC, Alex Rønne Petersen 
wrote:

 Yes and no. In theory, it's good to stabilize the language now 
 and make a new version of it later which has breaking changes. 
 In practice, that's annoying as hell. We've already seen how 
 slow the transition from D1 to D2 is (not was; it's still 
 happening!). D2 to D3 is going to be even slower (see in 
 particular your Python 2 vs 3 example) simply because more and 
 more people are going to be using D2 and therefore can't afford 
 to port their applications to D3.
Hmmm. I'd Hope it isn't going to happen for a while. But IF there is a D3 coming then it would be absolutely necessary that the D2 and D3 code could call each other seamlessly. D3 if/when it comes hopefully would be seen as the next step towards the ideal language which we would want and go to: This includes style, standard library, functionality, syntax, and perhaps collective experience of dozens or hundreds or programmers. Likely D3 will adjust features; adding/removing that would break D2 code as it stands now; but at the same time not far from where we came from. With how clean and workable the syntax is right now with D2 and the signatures alone you could plug into the D2 code/interfaces without problems (Assuming D3 uses the same signature system (which most of it I don't see a changing)), then there shouldn't be a problem. But still I don't see that happening just yet. We will have to watch and wait to see what happens. In the meantime, I don't want to ever do any real C++ if I can help it...
May 01 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, May 02, 2012 at 03:31:34AM +0200, Era Scarecrow wrote:
[...]
 But IF there is a D3 coming then it would be absolutely necessary
 that the D2 and D3 code could call each other seamlessly. D3 if/when
 it comes hopefully would be seen as the next step towards the ideal
 language which we would want and go to: This includes style,
 standard library, functionality, syntax, and perhaps collective
 experience of dozens or hundreds or programmers.
Hey, actually, that's an excellent idea. If there is ever a D3, it should be binary-compatible with D2 code. At the very least, they should be able to call each other seamlessly. In fact, dmd v3 should have a compatibility option that supports compiling D2 code. This will ease the D2->D3 transition a lot, and not alienate existing users (they can continue using D2 for existing projects, and start new projects / components with D3). [...]
  We will have to watch and wait to see what happens. In the
 meantime, I don't want to ever do any real C++ if I can help it...
Same here. For all its current warts, D is still superior to C++, and by a long shot. I just can't bear the thought of writing any more C++ code, especially for my own projects. T -- All men are mortal. Socrates is mortal. Therefore all men are Socrates.
May 01 2012
parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 02-05-2012 06:22, H. S. Teoh wrote:
 On Wed, May 02, 2012 at 03:31:34AM +0200, Era Scarecrow wrote:
 [...]
 But IF there is a D3 coming then it would be absolutely necessary
 that the D2 and D3 code could call each other seamlessly. D3 if/when
 it comes hopefully would be seen as the next step towards the ideal
 language which we would want and go to: This includes style,
 standard library, functionality, syntax, and perhaps collective
 experience of dozens or hundreds or programmers.
Hey, actually, that's an excellent idea. If there is ever a D3, it should be binary-compatible with D2 code. At the very least, they should be able to call each other seamlessly. In fact, dmd v3 should have a compatibility option that supports compiling D2 code. This will ease the D2->D3 transition a lot, and not alienate existing users (they can continue using D2 for existing projects, and start new projects / components with D3).
Or just, you know, call it dmd3 like DMD for D2 should have been called dmd2.
 [...]
   We will have to watch and wait to see what happens. In the
 meantime, I don't want to ever do any real C++ if I can help it...
Same here. For all its current warts, D is still superior to C++, and by a long shot. I just can't bear the thought of writing any more C++ code, especially for my own projects. T
-- - Alex
May 01 2012
prev sibling next sibling parent reply "James Miller" <james aatch.net> writes:
On Wednesday, 2 May 2012 at 01:11:52 UTC, Alex Rønne Petersen 
wrote:
 On 02-05-2012 03:08, ixid wrote:
 The idea of D3 is a worrying one- it suggests a number of 
 things that
 would not be good for the success and adoption of the 
 language. That the
 language is experimental and more of a pet project, that D2 
 has a
 shelf-life and will be abandoned. I can see D going in two 
 directions:
 it can gradually grow and progressively gain areas where it's 
 the
 standard choice or it will be a fairly small community of fans 
 of an
 eternal language project. Python 2 and 3 has been a very messy 
 split,
 while languages with a greater sense of continuity do better 
 for it in
 my view, having one standard version of that language. 
 Breaking changes
 may be desirable but I don't think labelling that as v2/v3 is 
 a good
 idea, make it one thing with one suggested version.
I agree wholeheartedly. This whole "D3" excuse for not fixing design issues in the language is going to hurt us in the long run.
 What are the aims of D3 that aren't aims of D2? What could be 
 done then
 that can't be done now? Wouldn't it be better to make breaking 
 changes
 sooner rather than later?
Yes and no. In theory, it's good to stabilize the language now and make a new version of it later which has breaking changes. In practice, that's annoying as hell. We've already seen how slow the transition from D1 to D2 is (not was; it's still happening!). D2 to D3 is going to be even slower (see in particular your Python 2 vs 3 example) simply because more and more people are going to be using D2 and therefore can't afford to port their applications to D3.
Honestly I think that the big problem going from D1 -> D2 was the issues with Tango. Hell, Tango in general seemed to just cause problems, what with the incompatible runtime and all. D3 would be fine, iff it was easy to port D2 across and easy to continue using D2 code. A big problem with Python2 -> Python3 is the fact that it is a nightmare to have both running side-by-side. I don't really think that D3 is a good idea, it would probably be better to gradually deprecate code going forward and replace the broken syntax and non backwards-compatible code. Another useful could be to have a pragma(version, 2) so the compiler compiles with version 2 rules, no porting needed, just a single line near the top. -- James Miller
May 03 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 03, 2012 at 10:22:16AM +0200, James Miller wrote:
[...]
 D3 would be fine, iff it was easy to port D2 across and easy to
 continue using D2 code. A big problem with Python2 -> Python3 is the
 fact that it is a nightmare to have both running side-by-side.
 
 I don't really think that D3 is a good idea, it would probably be
 better to gradually deprecate code going forward and replace the
 broken syntax and non backwards-compatible code.
 
 Another useful could be to have a pragma(version, 2) so the compiler
 compiles with version 2 rules, no porting needed, just a single line
 near the top.
[...] +1 to the pragma. If there ever will be a D3, this will be indispensible to not lose the majority of existing users. OTOH, it will make the compiler much harder to maintain. T -- Once bitten, twice cry...
May 03 2012
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 02/05/2012 03:11, Alex Rønne Petersen a écrit :
 Yes and no. In theory, it's good to stabilize the language now and make
 a new version of it later which has breaking changes. In practice,
 that's annoying as hell. We've already seen how slow the transition from
 D1 to D2 is (not was; it's still happening!). D2 to D3 is going to be
 even slower (see in particular your Python 2 vs 3 example) simply
 because more and more people are going to be using D2 and therefore
 can't afford to port their applications to D3.
PHP does a good job with that. I include supporting several versions of the language at a given moment.
May 06 2012
parent reply Russel Winder <russel winder.org.uk> writes:
On Sun, 2012-05-06 at 15:18 +0200, deadalnix wrote:
[...]
 PHP does a good job with that. I include supporting several versions of=
=20
 the language at a given moment.
I have to say I thought reacting to the idea of D2->D3 with "there must not be a D3, it would be a disaster" is just wrong. Clearly there can be a D3 if that proves to be a good thing. Then possibly a D4. It is all about evolution, marketing and expectation management. Saying there will never be a D3 is as off-putting as having a D3 too soon. For lessons in what to do and what not to do I offer Java. The 1.2 -> 1.4.2 sequence was handled reasonably well. Up to 5 and thence to 7 were handled very badly. The revised JCP EC have forced a much better process and I see 8 onwards being handled at least reasonably well. Of course there are still people using 1.3 which is outrageous. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 06 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 6 May 2012 at 14:43:45 UTC, Russel Winder wrote:
 [...]

 Of course there are still people using 1.3 which is outrageous.
The consulting company I work for, still gets requests for proposals using 1.4, which is not any better. Actually, last year was the first time I took part on a project where 1.6 was allowed. And before that, we did a migration to 1.5 in another project. Product deployment in the enterprise world is a pain. -- Paulo
May 06 2012
parent reply Russel Winder <russel winder.org.uk> writes:
On Sun, 2012-05-06 at 19:41 +0200, Paulo Pinto wrote:
 On Sunday, 6 May 2012 at 14:43:45 UTC, Russel Winder wrote:
 [...]

 Of course there are still people using 1.3 which is outrageous.
=20 The consulting company I work for, still gets requests for proposals using 1.4, which is not any better.
I know of no comprehensible reason why any new Java project is not using Java 7, other than incompetence somewhere in the decision making.
 Actually, last year was the first time I took part on a project
 where
 1.6 was allowed. And before that, we did a migration to 1.5 in
 another
 project.
Migrating from pre Java 5 to Java 5 seems like a very bad decision given Java 5 died a long time ago. Any migration has to be to Java 7.
 Product deployment in the enterprise world is a pain.
Only because of bad planning or decision making. The analogies for D are clear. The conclusion is that we need to find resource to ensure the GDC and LDC folks are supporting the same version of D that DMD is supporting at any time. Currently DMD is at 2.059 whilst GDC is at 2.057. Not a planning problem as far as I am aware, just a resource problem: i.e. not enough people paid, directly or indirectly to work on these compilers. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 06 2012
parent "Paulo Pinto" <pjmlp progtools.org> writes:
Usually those decisions have to do with different deppartments have a
say on the matter and certification processes.

If a project to extend an existing system is done on the current development
system, then only the new project needs to be tested.

On the other hand if the system needs to be migrated to a  newer version, 
then
usually a costly certification process has to take place.

This is nothing new.  I also endured this scenario with C, C++ and Delphi 
deployments.

Typicall enterprise scenarion where the company does not want to pay for 
newer compiler
versions, or go through the internal certification process just to allow 
some developers to use a few nicer
compiler features without any business value (a very common argument).

--
Paulo

"Russel Winder"  wrote in message 
news:mailman.374.1336371599.24740.digitalmars-d puremagic.com...
On Sun, 2012-05-06 at 19:41 +0200, Paulo Pinto wrote:
 On Sunday, 6 May 2012 at 14:43:45 UTC, Russel Winder wrote:
 [...]

 Of course there are still people using 1.3 which is outrageous.
The consulting company I work for, still gets requests for proposals using 1.4, which is not any better.
I know of no comprehensible reason why any new Java project is not using Java 7, other than incompetence somewhere in the decision making.
 Actually, last year was the first time I took part on a project
 where
 1.6 was allowed. And before that, we did a migration to 1.5 in
 another
 project.
Migrating from pre Java 5 to Java 5 seems like a very bad decision given Java 5 died a long time ago. Any migration has to be to Java 7.
 Product deployment in the enterprise world is a pain.
Only because of bad planning or decision making. The analogies for D are clear. The conclusion is that we need to find resource to ensure the GDC and LDC folks are supporting the same version of D that DMD is supporting at any time. Currently DMD is at 2.059 whilst GDC is at 2.057. Not a planning problem as far as I am aware, just a resource problem: i.e. not enough people paid, directly or indirectly to work on these compilers. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
May 07 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, May 02, 2012 03:08:32 ixid wrote:
 The idea of D3 is a worrying one- it suggests a number of things
 that would not be good for the success and adoption of the
 language. That the language is experimental and more of a pet
 project, that D2 has a shelf-life and will be abandoned. I can
 see D going in two directions: it can gradually grow and
 progressively gain areas where it's the standard choice or it
 will be a fairly small community of fans of an eternal language
 project. Python 2 and 3 has been a very messy split, while
 languages with a greater sense of continuity do better for it in
 my view, having one standard version of that language. Breaking
 changes may be desirable but I don't think labelling that as
 v2/v3 is a good idea, make it one thing with one suggested
 version.
 
 What are the aims of D3 that aren't aims of D2? What could be
 done then that can't be done now? Wouldn't it be better to make
 breaking changes sooner rather than later?
There are not currently any plans for a D3. If and when we decide that it's time that we want to introduce breaking changes into the language, then we will look at creating a D3. What that will or won't entail will be determined then. It could easily be 10 years off, if it will even happen at all. We don't necessarily want to be slaves to backwards compatibility (C++ has shown how that can be both good and bad), but how that will be addressed is an open issue which doesn't matter until we actually start looking into creating D3, and that's years off from now. D2 is stabilizing. We do not intend to add major features or breaking changes to the language at this point except where necessary to finish stabilizing it. In the future, new, backwards-compatible features may be added, but what happens with that remains to be seen. If at some point, we decide that it's worth adding features which break backwards compatibility, _then_ is when we'd look at creating D3. People keep bringing up D3 at least in part, because there are features or other changes that they want in D which will never make it into D2. _If_ they ever happen, it'll be in D3, but precisely because D3 is so far off - if it ever happens at all - there's no reason to worry about it at this point. - Jonathan M Davis
May 01 2012
prev sibling parent FeepingCreature <default_357-line yahoo.de> writes:

May 06 2012