www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - back port opDot to D 1.0?

reply u <some where.com> writes:
I like this feature so much.

Is it possible to back port opDot to D 1.0?
Oct 10 2008
next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sat, Oct 11, 2008 at 3:33 AM, u <some where.com> wrote:
 I like this feature so much.

 Is it possible to back port opDot to D 1.0?
Neeever gonna happen. Sorry.
Oct 10 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 11, 2008 at 1:04 PM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:
 On Sat, Oct 11, 2008 at 3:33 AM, u <some where.com> wrote:
 I like this feature so much.

 Is it possible to back port opDot to D 1.0?
Neeever gonna happen. Sorry.
Not in DMD, at least. And not likely to happen anywhere else. --bb
Oct 10 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
u wrote:
 I like this feature so much.
 Is it possible to back port opDot to D 1.0?
The problem is for every last feature in D 2.0, there's someone who wants that and only that ported to 1.0. If I moved over opDot, what am I going to say to everyone else? I move over their features too, and then D 1.0 becomes 2.0 anyway. I suggest instead just moving to 2.0 <g>.
Oct 10 2008
next sibling parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
Walter Bright wrote:
 u wrote:
 I like this feature so much.
 Is it possible to back port opDot to D 1.0?
The problem is for every last feature in D 2.0, there's someone who wants that and only that ported to 1.0. If I moved over opDot, what am I going to say to everyone else? I move over their features too, and then D 1.0 becomes 2.0 anyway. I suggest instead just moving to 2.0 <g>.
What about porting only nonbreaking features to D1? Like token strings, partial IFTI, foreach range, template constraints, ...?
Oct 11 2008
next sibling parent reply "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
Really, it doesn't make any sense to mutate 1.0 into 2.0. There are separate 
language specifications and implementations. As Walter writes, use D 2.0 - 
or make do with D 1.0 until D 2.0 is baked and implemented. I would imagine 
his time would better spent actually making D 2.0 than injecting D 2.0 into 
"D 1.0".

- Bent


"Christian Kamm" <kamm-incasoftware removethis.de> skrev i meddelelsen 
news:gcpjk0$19cf$1 digitalmars.com...
 Walter Bright wrote:
 u wrote:
 I like this feature so much.
 Is it possible to back port opDot to D 1.0?
The problem is for every last feature in D 2.0, there's someone who wants that and only that ported to 1.0. If I moved over opDot, what am I going to say to everyone else? I move over their features too, and then D 1.0 becomes 2.0 anyway. I suggest instead just moving to 2.0 <g>.
What about porting only nonbreaking features to D1? Like token strings, partial IFTI, foreach range, template constraints, ...?
Oct 11 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 11, 2008 at 4:44 PM, Bent Rasmussen
<IncredibleShrinkingSphere gmail.com> wrote:
 Really, it doesn't make any sense to mutate 1.0 into 2.0. There are separate
 language specifications and implementations. As Walter writes, use D 2.0 -
 or make do with D 1.0 until D 2.0 is baked and implemented. I would imagine
 his time would better spent actually making D 2.0 than injecting D 2.0 into
 "D 1.0".
Walter has said before when this topic came up that it would be trivial for him to back-port such features to D 1.0. I also thought that the time required was the real blocker, but he said no. According to him the desire to make D 1.0 stable is the reason for not porting them. Porting proven, non-breaking D2.0 features to D1.0 would *not* mutate D1.0 into D2.0. Const stuff would never be ported to D1.0, for instance because there's really no way to do it without breaking existing D1 code. And since we're talking about porting proven, backwards-compatible features, it still means D1.0 is significantly more stable than D2. For me, D2 is too wild-west (the talk recently has been especially so -- getting rid of "new" and "delete"!), but D1 is way too stagnant. The cut-off for what became D1 was really arbitrary. It wasn't like the last big "todo" on some list got checked off and D 1.0 was "done". No, it was more like, "we should call it 1.0 at some point here so we can make a big announcement and get some new users with the slashvertisement that results". Ok maybe it wasn't so blatant, but the point was definitely made that some people will refuse to use a language with a version less than 1.0, so we should label it 1.0 to get those people to give it a look. I think there was some hope that making a really stable D1.0 would somehow make D1.0 an attractive choice for companies. But come on. It was a stretch when D1 was just a niche language. Now it's a niche language that's also obsolete. What company would want to jump on that ship? (Ok, I'm sure the answer is non-zero, but I just don't think it's anywhere near as significant as the number of companies or users who would like to see new non-breaking features in D1. If they're going to use D at all it's because they believe that productivity gains or fun of using D outweigh the disadvantages of lack of libraries, lack of tools, lack of programmers.) That's my 2¥ anyway. --bb
Oct 11 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 I think there was some hope that making a really stable D1.0 would
 somehow make D1.0 an attractive choice for companies.  But come on.
 It was a stretch when D1 was just a niche language.  Now it's a niche
 language that's also obsolete.
People made it clear they were not going to use a language for production if it got new features every month. D 1.0 is a complete and very usable language, with the goal of being stable and bug free. You can't have it both ways - you cannot have a stable language while constantly adding features.
Oct 11 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 11, 2008 at 6:47 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 I think there was some hope that making a really stable D1.0 would
 somehow make D1.0 an attractive choice for companies.  But come on.
 It was a stretch when D1 was just a niche language.  Now it's a niche
 language that's also obsolete.
People made it clear they were not going to use a language for production if it got new features every month. D 1.0 is a complete and very usable language, with the goal of being stable and bug free. You can't have it both ways - you cannot have a stable language while constantly adding features.
I recall a wise man who once said you shouldn't give much weight to what people use as excuses for not using your language. They probably aren't going to use it anyway. --bb
Oct 11 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 I recall a wise man who once said you shouldn't give much weight to
 what people use as excuses for not using your language.  They probably
 aren't going to use it anyway.
The people using it wanted a stable version.
Oct 11 2008
parent reply "Aziz K." <aziz.kerim gmail.com> writes:
On Sat, 11 Oct 2008 21:42:27 +0200, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Bill Baxter wrote:
 I recall a wise man who once said you shouldn't give much weight to
 what people use as excuses for not using your language.  They probably
 aren't going to use it anyway.
The people using it wanted a stable version.
I got an idea, what if you backported some stuff from D2 to D1 (obviously not the const system) and made those features only available when a switch on the command-line was turned on, for example -v1.1? Ought to satisfy both camps, the conservatives and the reformers. Whaddaya say?
Oct 11 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Aziz K. wrote:
 I got an idea, what if you backported some stuff from D2 to D1 
 (obviously not the const system) and made those features only available 
 when a switch on the command-line was turned on, for example -v1.1? 
 Ought to satisfy both camps, the conservatives and the reformers. 
 Whaddaya say?
I've dealt with that on C/C++ compilers for years, and it's an unending testing and configuration nuisance.
Oct 11 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Oct 12, 2008 at 10:56 AM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Aziz K. wrote:
 I got an idea, what if you backported some stuff from D2 to D1 (obviously
 not the const system) and made those features only available when a switch
 on the command-line was turned on, for example -v1.1? Ought to satisfy both
 camps, the conservatives and the reformers. Whaddaya say?
I've dealt with that on C/C++ compilers for years, and it's an unending testing and configuration nuisance.
Python's strategy of introducing new features is the best I've seen by far. And with that they have made big changes in the language without ever creating any major split in the user base, as far as I can tell. --bb
Oct 11 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 Python's strategy of introducing new features is the best I've seen by far.
 And with that they have made big changes in the language without ever
 creating any major split in the user base, as far as I can tell.
Most of the split in the user base is a result of Tango being D1 only (which I hope will be resolved shortly).
Oct 11 2008
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sun, Oct 12, 2008 at 4:48 AM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 Python's strategy of introducing new features is the best I've seen by
 far.
 And with that they have made big changes in the language without ever
 creating any major split in the user base, as far as I can tell.
Most of the split in the user base is a result of Tango being D1 only (which I hope will be resolved shortly).
Then address the issues of stack vs. heap delegates.
Oct 11 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Jarrett Billingsley wrote:
 On Sun, Oct 12, 2008 at 4:48 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 Python's strategy of introducing new features is the best I've seen by
 far.
 And with that they have made big changes in the language without ever
 creating any major split in the user base, as far as I can tell.
Most of the split in the user base is a result of Tango being D1 only (which I hope will be resolved shortly).
Then address the issues of stack vs. heap delegates.
That is not required for Tango to function properly with D2. It's a performance optimization only. A significant one, but no more.
Oct 11 2008
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Christopher Wright schrieb:
 Jarrett Billingsley wrote:
 Then address the issues of stack vs. heap delegates.
That is not required for Tango to function properly with D2. It's a performance optimization only. A significant one, but no more.
I disagree here. If you use lambdas for filters in inner loops, that is a main performance hit. It is more than just "optimization", it is a reason to change the design. It is a reason not to use D2. It is a D2 show-stopper. Even worse, no error message is showing you the problematic places, D2 just makes your heap explode. int findMyTypeXYZ( MyType[] a, int criteria ){ int match = convCrit( criteria ); return tango.core.Array.findIf( a, delegate bool(T e){ return e.attrib is match; }); } First this run without allocation, now it does allocate. Image how this behave if called very often :( And even worse, there is no way to manually delete the allocated stack frames. So there is no way around the GC runs. Finally I would end up in rewriting that code, not using a delegate based design. But IMHO this is one of the important D features.
Oct 12 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Frank Benoit wrote:
 Christopher Wright schrieb:
 Jarrett Billingsley wrote:
 Then address the issues of stack vs. heap delegates.
That is not required for Tango to function properly with D2. It's a performance optimization only. A significant one, but no more.
I disagree here. If you use lambdas for filters in inner loops, that is a main performance hit. It is more than just "optimization", it is a reason to change the design. It is a reason not to use D2. It is a D2 show-stopper. Even worse, no error message is showing you the problematic places, D2 just makes your heap explode. int findMyTypeXYZ( MyType[] a, int criteria ){ int match = convCrit( criteria ); return tango.core.Array.findIf( a, delegate bool(T e){ return e.attrib is match; }); } First this run without allocation, now it does allocate. Image how this behave if called very often :( And even worse, there is no way to manually delete the allocated stack frames. So there is no way around the GC runs. Finally I would end up in rewriting that code, not using a delegate based design. But IMHO this is one of the important D features.
Well, how much of a performance hit is it? If the average application will run half as fast, then this is a significant issue that should be addressed soon. But it will not prevent me from using Tango with D2 in the interim. If it's a 100x performance hit, then I wouldn't expect a port of Tango yet. But I suspect that it's more like a 10-15% performance hit at most. (I am talking about a typical application. I'm sure you could get a benchmark that runs much slower by choosing library calls that make extensive use of delegates and using those constantly.) I don't know; nobody has given any ballpark figures, much less benchmarks. I'm going to try porting some of my code to D2/Tango. I'll post the results.
Oct 12 2008
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Christopher Wright schrieb:
 Frank Benoit wrote:
 Christopher Wright schrieb:
 Jarrett Billingsley wrote:
 Then address the issues of stack vs. heap delegates.
That is not required for Tango to function properly with D2. It's a performance optimization only. A significant one, but no more.
I disagree here. If you use lambdas for filters in inner loops, that is a main performance hit. It is more than just "optimization", it is a reason to change the design. It is a reason not to use D2. It is a D2 show-stopper. Even worse, no error message is showing you the problematic places, D2 just makes your heap explode. int findMyTypeXYZ( MyType[] a, int criteria ){ int match = convCrit( criteria ); return tango.core.Array.findIf( a, delegate bool(T e){ return e.attrib is match; }); } First this run without allocation, now it does allocate. Image how this behave if called very often :( And even worse, there is no way to manually delete the allocated stack frames. So there is no way around the GC runs. Finally I would end up in rewriting that code, not using a delegate based design. But IMHO this is one of the important D features.
Well, how much of a performance hit is it? If the average application will run half as fast, then this is a significant issue that should be addressed soon. But it will not prevent me from using Tango with D2 in the interim. If it's a 100x performance hit, then I wouldn't expect a port of Tango yet. But I suspect that it's more like a 10-15% performance hit at most. (I am talking about a typical application. I'm sure you could get a benchmark that runs much slower by choosing library calls that make extensive use of delegates and using those constantly.) I don't know; nobody has given any ballpark figures, much less benchmarks. I'm going to try porting some of my code to D2/Tango. I'll post the results.
How can you guess anything here? Old behavior == just the direct call, no extra cost New behavior == same direct call plus a heap allocation with unbound cost There is nothing like a typical application. There is nothing like a typical calling rate to full closures. Either you use them or you don't. It depends on your code. So even if you port some code and do some tests, there is no significant result for my code. There _can_ be 100x performance hit. Code that was allocation free is now no more. That is super bad.
Oct 12 2008
parent reply Christopher Wright <dhasenan gmail.com> writes:
Frank Benoit wrote:
 How can you guess anything here?

 Old behavior == just the direct call, no extra cost
 New behavior == same direct call plus a heap allocation
                 with unbound cost
There are plenty of randomized algorithms with potentially unbounded cost that are still used. In practice, potentially unbounded things work in a reasonable amount of time or get replaced. The major reason that a heap allocation incurs a potentially unbounded cost is that allocation can trigger a collection. And a collection is potentially unbounded in duration because of user-defined destructors. If you write no destructors, then the cost of garbage collection is bounded by the amount of allocated memory. If your destructors complete in constant time, same thing. It's like saying "The cost of invoking a method is unbounded." Technically, this is true; but if you're trying to benchmark the runtime or the language, that truth isn't the one in which you are interested.
 There is nothing like a typical application.
This argument is a bit solipsist, and not remotely useful. You simply lack the appropriate data to determine which library types and functions are used with what frequency.
 There is nothing like a
 typical calling rate to full closures. Either you use them or you don't.
Again, you simply lack sufficient data. If an application uses closures, it might create one every minute or one every second or a thousand per second, on average. You can track this.
 It depends on your code. So even if you port some code and do some
 tests, there is no significant result for my code.

 There _can_ be 100x performance hit. Code that was allocation free is
 now no more. That is super bad.
Well then, how about a microbenchmark? I tried creating a delegate in a tight loop and executing it -- 10 million iterations took 0.506 seconds using d1. Using closures in d2, it took 3.958 seconds. This is doing nothing but allocating and using closures. Using more local variables would result in more allocation, but with 5 integers instead of 1, the time only increased to 5.484 seconds. That's still 1.8 million delegate allocations per second. (If you have a very large struct on the stack, though, this cost can increase significantly, but that's a potential performance issue in itself.) Considering these results, if overzealous heap activity due to delegates is the main issue you have to worry about, your application must use a very large number of closures. While this does violate Tango's contracts about heap allocation, once scope delegates are available, it won't take much work to replace "delegate" with "scope delegate" everywhere in Tango. The benchmarks: --- // d1 int count = 0; void foo (void delegate(int) dg) { dg (1); dg (2); } void main () { uint max = 10_000_000; for (int j = 0; j < max; j++) { foo (makeDelegate); } } int x = 2; void delegate(int) makeDelegate () { return (int i) { count += i; count += x; }; } --- --- // d2 int count = 0; void foo (void delegate(int) dg) { dg (1); dg (2); } void main () { uint max = 10_000_000; for (int j = 0; j < max; j++) { foo (makeDelegate); } } void delegate(int) makeDelegate () { int x = 2; /* // Uncomment to see the effects of additional local variables. int a = 2 * x; int b = 2 + a; int c = (2 - 6 * a) + b; int d = x * (3 + c); */ return (int i) { count += i; count += x; /* count += a; count += b; count += c; count += d; */ }; } --- The test machine: Dell Optiplex GX110 Processor: Pentium III clocked at 1GHz (997.473 MHz according to /proc/cpuinfo) Memory: 128MB; unknown type
Oct 12 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
On a Core Duo, 2 GHz, lot of RAM:

Timigs, best of 3:
  n = 10_000_000:
    D1: 0.14 s  (5.9 X)
    D2: 0.83 s  (1.0 X)
  n = 100_000_000:
    D1: 1.18 s  (6.8 X)  (~1.0 MB RAM)
    D2: 8.04 s  (1.0 X)  (~2.0 MB RAM)

Exe sizes:
  D1: 167.964 bytes
  D2: 165.404 bytes

Bye,
bearophile
Oct 12 2008
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
Christopher Wright schrieb:
 Frank Benoit wrote:
 How can you guess anything here?
 
 Old behavior == just the direct call, no extra cost New behavior ==
  same direct call plus a heap allocation with unbound cost
There are plenty of randomized algorithms with potentially unbounded cost that are still used. In practice, potentially unbounded things work in a reasonable amount of time or get replaced.
You said it is just a thing of optimization. That would be true if the runtime would have been increased by a defined value, like double runtime. But it has changed from deterministic behavior to undeterministic behavior. => that means you can no longer use that in code that is made for high data rate or low latency. And optimizations will not change that. There is also no sense in doing benchmarks, because you are measuring the GC performance, nothing more. And I already know, that I need the guarantee for no heap allocation. My point is, the delegate are a D1 tool that can be used in high performance code. Shortly after the full closure feature was announced (Nov 07), it was shown that this brakes D1 runtime behavior. Still this is not fixed.
 While this does violate Tango's contracts about heap allocation, once
  scope delegates are available, it won't take much work to replace 
 "delegate" with "scope delegate" everywhere in Tango.
I understand this as a confirmation, that with actual D2 you cannot port tango and expect it to work as it does with D1. Even an optimization cannot help. IMO the only two possible solutions are 1. Redesign the code -or- 2. Wait for scoped delegate
Oct 12 2008
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 12 Oct 2008 23:32:15 +0400, Frank Benoit  
<keinfarbton googlemail.com> wrote:

 Christopher Wright schrieb:
 Frank Benoit wrote:
 How can you guess anything here?

 Old behavior == just the direct call, no extra cost New behavior ==
  same direct call plus a heap allocation with unbound cost
There are plenty of randomized algorithms with potentially unbounded cost that are still used. In practice, potentially unbounded things work in a reasonable amount of time or get replaced.
You said it is just a thing of optimization. That would be true if the runtime would have been increased by a defined value, like double runtime. But it has changed from deterministic behavior to undeterministic behavior. => that means you can no longer use that in code that is made for high data rate or low latency. And optimizations will not change that. There is also no sense in doing benchmarks, because you are measuring the GC performance, nothing more. And I already know, that I need the guarantee for no heap allocation. My point is, the delegate are a D1 tool that can be used in high performance code. Shortly after the full closure feature was announced (Nov 07), it was shown that this brakes D1 runtime behavior. Still this is not fixed.
 While this does violate Tango's contracts about heap allocation, once
  scope delegates are available, it won't take much work to replace
 "delegate" with "scope delegate" everywhere in Tango.
I understand this as a confirmation, that with actual D2 you cannot port tango and expect it to work as it does with D1. Even an optimization cannot help. IMO the only two possible solutions are 1. Redesign the code -or- 2. Wait for scoped delegate
Scoped delegates hopefully will be implemented some day, so I'd stick with #2 in a long run.
Oct 12 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Frank Benoit wrote:
 Christopher Wright schrieb:
 Frank Benoit wrote:
 How can you guess anything here?

 Old behavior == just the direct call, no extra cost New behavior ==
  same direct call plus a heap allocation with unbound cost
There are plenty of randomized algorithms with potentially unbounded cost that are still used. In practice, potentially unbounded things work in a reasonable amount of time or get replaced.
You said it is just a thing of optimization. That would be true if the runtime would have been increased by a defined value, like double runtime. But it has changed from deterministic behavior to undeterministic behavior. => that means you can no longer use that in code that is made for high data rate or low latency. And optimizations will not change that. There is also no sense in doing benchmarks, because you are measuring the GC performance, nothing more. And I already know, that I need the guarantee for no heap allocation. My point is, the delegate are a D1 tool that can be used in high performance code. Shortly after the full closure feature was announced (Nov 07), it was shown that this brakes D1 runtime behavior. Still this is not fixed.
 While this does violate Tango's contracts about heap allocation, once
  scope delegates are available, it won't take much work to replace 
 "delegate" with "scope delegate" everywhere in Tango.
I understand this as a confirmation, that with actual D2 you cannot port tango and expect it to work as it does with D1. Even an optimization cannot help. IMO the only two possible solutions are 1. Redesign the code -or- 2. Wait for scoped delegate
Okay, and for the 98% of people who don't mind having some extra heap allocation, we have to wait. Though this isn't terribly relevant -- I think that, if D2 were less of a moving target, Tango would already have been ported and released for D2.
Oct 12 2008
prev sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Christopher Wright wrote:
 Jarrett Billingsley wrote:
 On Sun, Oct 12, 2008 at 4:48 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 Python's strategy of introducing new features is the best I've seen by
 far.
 And with that they have made big changes in the language without ever
 creating any major split in the user base, as far as I can tell.
Most of the split in the user base is a result of Tango being D1 only (which I hope will be resolved shortly).
Then address the issues of stack vs. heap delegates.
That is not required for Tango to function properly with D2. It's a performance optimization only. A significant one, but no more.
That's not entirely true. Tango makes some promises about heap allocations, suddenly the code has to be rewritten for these still to hold true. That's more than just an optimization. IIRC there's also other issues (with const). Might be wrong here, I have little interest in the whole D2 thing, a D1.5 variant is much more appealing to me.
Oct 12 2008
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 11 de octubre a las 02:47 me escribiste:
 Bill Baxter wrote:
 I think there was some hope that making a really stable D1.0 would
 somehow make D1.0 an attractive choice for companies.  But come on.
 It was a stretch when D1 was just a niche language.  Now it's a niche
 language that's also obsolete.
People made it clear they were not going to use a language for production if it got new features every month. D 1.0 is a complete and very usable language, with the goal of being stable and bug free. You can't have it both ways - you cannot have a stable language while constantly adding features.
Yes you can. Please, take a look to Python development model =) -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Es ms probable que el tomate sea perita, a que la pera tomatito. -- Peperino Pmoro
Oct 13 2008
prev sibling next sibling parent "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
D 1 obsolete? I don't get it. Walter has a point, it's about everybody's 
personal wish-list.

Of course you do have a point that there's probably a couple of features 
that would make D 1 more homogeneous and complete, but no language is ever 
really complete, except for, say - brainfuck.

- Bent


"Bill Baxter" <wbaxter gmail.com> skrev i meddelelsen 
news:mailman.77.1223717588.3087.digitalmars-d puremagic.com...
 On Sat, Oct 11, 2008 at 4:44 PM, Bent Rasmussen
 <IncredibleShrinkingSphere gmail.com> wrote:
 Really, it doesn't make any sense to mutate 1.0 into 2.0. There are 
 separate
 language specifications and implementations. As Walter writes, use D 
 2.0 -
 or make do with D 1.0 until D 2.0 is baked and implemented. I would 
 imagine
 his time would better spent actually making D 2.0 than injecting D 2.0 
 into
 "D 1.0".
Walter has said before when this topic came up that it would be trivial for him to back-port such features to D 1.0. I also thought that the time required was the real blocker, but he said no. According to him the desire to make D 1.0 stable is the reason for not porting them. Porting proven, non-breaking D2.0 features to D1.0 would *not* mutate D1.0 into D2.0. Const stuff would never be ported to D1.0, for instance because there's really no way to do it without breaking existing D1 code. And since we're talking about porting proven, backwards-compatible features, it still means D1.0 is significantly more stable than D2. For me, D2 is too wild-west (the talk recently has been especially so -- getting rid of "new" and "delete"!), but D1 is way too stagnant. The cut-off for what became D1 was really arbitrary. It wasn't like the last big "todo" on some list got checked off and D 1.0 was "done". No, it was more like, "we should call it 1.0 at some point here so we can make a big announcement and get some new users with the slashvertisement that results". Ok maybe it wasn't so blatant, but the point was definitely made that some people will refuse to use a language with a version less than 1.0, so we should label it 1.0 to get those people to give it a look. I think there was some hope that making a really stable D1.0 would somehow make D1.0 an attractive choice for companies. But come on. It was a stretch when D1 was just a niche language. Now it's a niche language that's also obsolete. What company would want to jump on that ship? (Ok, I'm sure the answer is non-zero, but I just don't think it's anywhere near as significant as the number of companies or users who would like to see new non-breaking features in D1. If they're going to use D at all it's because they believe that productivity gains or fun of using D outweigh the disadvantages of lack of libraries, lack of tools, lack of programmers.) That's my 2¥ anyway. --bb
Oct 11 2008
prev sibling parent Christian Kamm <kamm-incasoftware removethis.de> writes:
Bill Baxter wrote:
 Porting proven, non-breaking D2.0 features to D1.0 would *not* mutate
 D1.0 into D2.0.  Const stuff would never be ported to D1.0, for
 instance because there's really no way to do it without breaking
 existing D1 code.  And since we're talking about porting proven,
 backwards-compatible features, it still means D1.0 is significantly
 more stable than D2.
I agree and would like to see the choice for not moving proven, backwards-compatible features from the D2-playground into D1-stable reconsidered. The big, conceptual changes like const/invariant, pure, shared, closures, ... could not be moved to D1 without breaking existing code, but a lot of small things could. There should be much less complaints about getting new features every month if these features are fully backwards-compatibly and have been tested in D2 for a while. This is particularly true for things like the partial IFTI improvements that could be considered bugs in D1. I think some fixes to D1 bugs will prove to be much more troublesome. We recently applied the patch to 313/314 in LDC and that *did* break some existing code (by exposing bugs, but still...).
Oct 11 2008
prev sibling parent reply bobef <bobef nospam-abv.bg> writes:
Walter Bright Wrote:

 Bill Baxter wrote:
 I think there was some hope that making a really stable D1.0 would
 somehow make D1.0 an attractive choice for companies.  But come on.
 It was a stretch when D1 was just a niche language.  Now it's a niche
 language that's also obsolete.
People made it clear they were not going to use a language for production if it got new features every month. D 1.0 is a complete and very usable language, with the goal of being stable and bug free.
Are they going to use the language if it is practically dead? No new features added, D2 too experimental and practically another language. D2 goes so far away from D1 that the task to port a big project seems very unappealing. Plus it is a different language. I come from C++ and like D because it fixes the stupidness of C++ while remaining fast and not too high level. D2 becomes too high level for me... So what is the point to develop for D1? To be honest what I read recently about D2 drives me off. I love D1 and I'd love to have some of the D2 features, but not D2. Now I hope for something like LLVMDC that will keep D1 alive and maybe developing. I brought this up before, but unfortunately Walter didn't respond (http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars. &article_id=76149). I fully support Bill Baxter's post.
Oct 11 2008
next sibling parent Mike Parker <aldacron gmail.com> writes:
bobef wrote:
 Walter Bright Wrote:
 
 Bill Baxter wrote:
 I think there was some hope that making a really stable D1.0 would
 somehow make D1.0 an attractive choice for companies.  But come on.
 It was a stretch when D1 was just a niche language.  Now it's a niche
 language that's also obsolete.
People made it clear they were not going to use a language for production if it got new features every month. D 1.0 is a complete and very usable language, with the goal of being stable and bug free.
Are they going to use the language if it is practically dead? No new features added, D2 too experimental and practically another language. D2 goes so far away from D1 that the task to port a big project seems very unappealing. Plus it is a different language. I come from C++ and like D because it fixes the stupidness of C++ while remaining fast and not too high level. D2 becomes too high level for me... So what is the point to develop for D1? To be honest what I read recently about D2 drives me off. I love D1 and I'd love to have some of the D2 features, but not D2. Now I hope for something like LLVMDC that will keep D1 alive and maybe developing. I brought this up before, but unfortunately Walter didn't respond (http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars. &article_id=76149). I fully support Bill Baxter's post.
I have a growing, evolving code base that I plan to use for a long time. Initially, I was developing it in D1. I've since moved to Java. My reasoning follows what is expressed here. D2 is so far gone from D1 that I have no interest in porting. Nor do I have any desire to use a language that seems obsoleted. Maybe that's just perception, but the dearth of mature development tools (considering the amount of time D1 has been stable -- since well before D 1.0 was released) certainly does little to dispel it. I've not given up on D altogether. I'm actively (albeit slowly) working on one project with D1 while maintaining another, and have a couple in the pipe waiting for D2 to finalize (and for the D Runtime project to mature and for Tango to support D2). But all of that is on the side and doesn't put food on the table. As far as my meat and potatoes work, I feel like D missed the boat. All of the attention on D2 just turned me off. It's rather frustrating sometimes working with D1 code and pining for a feature that is already in/coming to D2.
Oct 11 2008
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
bobef wrote:
 Walter Bright Wrote:
 
 Bill Baxter wrote:
 I think there was some hope that making a really stable D1.0 would
 somehow make D1.0 an attractive choice for companies.  But come on.
 It was a stretch when D1 was just a niche language.  Now it's a niche
 language that's also obsolete.
People made it clear they were not going to use a language for production if it got new features every month. D 1.0 is a complete and very usable language, with the goal of being stable and bug free.
Are they going to use the language if it is practically dead? No new features added, D2 too experimental and practically another language. D2 goes so far away from D1 that the task to port a big project seems very unappealing. Plus it is a different language. I come from C++ and like D because it fixes the stupidness of C++ while remaining fast and not too high level. D2 becomes too high level for me... So what is the point to develop for D1? To be honest what I read recently about D2 drives me off. I love D1 and I'd love to have some of the D2 features, but not D2. Now I hope for something like LLVMDC that will keep D1 alive and maybe developing. I brought this up before, but unfortunately Walter didn't respond (http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars. &article_id=76149). I fully support Bill Baxter's post.
The issue isn't the lack of new features, so much as bugs being labeled enhancements and not being fixed in D1. If you want the new features, you can switch to D2, so I don't see that as a problem. (I want the new features, but I'm waiting for Tango support.)
Oct 11 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 11, 2008 at 11:07 PM, Christopher Wright <dhasenan gmail.com> wrote:
 bobef wrote:
 Walter Bright Wrote:

 Bill Baxter wrote:
 I think there was some hope that making a really stable D1.0 would
 somehow make D1.0 an attractive choice for companies.  But come on.
 It was a stretch when D1 was just a niche language.  Now it's a niche
 language that's also obsolete.
People made it clear they were not going to use a language for production if it got new features every month. D 1.0 is a complete and very usable language, with the goal of being stable and bug free.
Are they going to use the language if it is practically dead? No new features added, D2 too experimental and practically another language. D2 goes so far away from D1 that the task to port a big project seems very unappealing. Plus it is a different language. I come from C++ and like D because it fixes the stupidness of C++ while remaining fast and not too high level. D2 becomes too high level for me... So what is the point to develop for D1? To be honest what I read recently about D2 drives me off. I love D1 and I'd love to have some of the D2 features, but not D2. Now I hope for something like LLVMDC that will keep D1 alive and maybe developing. I brought this up before, but unfortunately Walter didn't respond (http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=76149). I fully support Bill Baxter's post.
The issue isn't the lack of new features, so much as bugs being labeled enhancements and not being fixed in D1.
Is there anything in that category other than the partial IFTI stuff? I was thinking there were very few such cases, actually.
 If you want the new features, you can switch to D2, so I don't see that as a
 problem. (I want the new features, but I'm waiting for Tango support.)
I see three potential categories of D users: 1) bleeding edgers who want the latest and greatest -- don't care if it breaks everything 2) want the latest stuff -- but don't want it to break my code 3) want only bug fixes -- also don't want it to break my code Right now we have editions of D to satisfy groups 1 and 3. But I really just can't understand the logic of someone who would be in group 3. Let's face it: deciding to use D at all is a huge risk. But it's worth the risk to some of us because of the *features* D offers over the alternatives. If you were willing to take the big risk to use D, why then would you not want benefit fully from all the Goodness D has to offer, if it only costs you a negligible bit of additional risk? I can totally understand not wanting to take the full risk of D2, having been through many rounds of breakages in D0 compilers myself, when that was the only game in town. But features that have been tested in D2 and which are backwards compatible with D1? Why would anyone be against those? Sure some percentage of them are going to have gotchas. But then again some percentage of current D1 compilers have gotchas. When that happens you just wait out a release or two. No major loss since D has new releases almost every month. --bb
Oct 11 2008
next sibling parent reply bobef <bobef nospam-abv.bg> writes:
Bill Baxter Wrote:

 
 I see three potential categories of D users:
 1) bleeding edgers who want the latest and greatest -- don't care if
 it breaks everything
 2) want the latest stuff  -- but don't want it to break my code
 3) want only bug fixes -- also don't want it to break my code
 
4) bleeding edgers who want to use Tango - sorry you lose 5) people who actually like D1 and don't want it to become new language - losers 2) and 3) actually lose too because D2 will break their code very hard and category 3) will be forced to break their code because once D2 is declared stable D1 will probably be declared deprecated
Oct 11 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Oct 11 2008
parent reply Derek Parnell <derek psych.ward> writes:
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. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Oct 11 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sun, Oct 12, 2008 at 9:00 AM, Derek Parnell <derek psych.ward> 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.
So you're saying you'd be interested in a D1 with non-breaking backports? Or are you looking for something even closer to D2, just without the whirlwind? --bb
Oct 11 2008
parent Derek Parnell <derek psych.ward> writes:
On Sun, 12 Oct 2008 09:22:12 +0900, Bill Baxter wrote:

 I'm no longer using D at all. I've lost interest in D1 as D2 looks to be
 much, much better.
 So you're saying you'd be interested in a D1 with non-breaking
 backports?  Or are you looking for something even closer to D2, just
 without the whirlwind?
No, not really. I'm quite happy with the idea that D1 is 'stable' and that D2 is really an enhanced D1, and is still in prototype mode. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Oct 11 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 I tried coding in D2 but a lot of that code is going to need
 significant rework when the cabal have finalized their deliberations,
I doubt that it would be significant. The time I've invested in converting D1 to D2 code has been trivial.
Oct 11 2008
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Derek Parnell wrote:
 I tried coding in D2 but a lot of that code is going to need
 significant rework when the cabal have finalized their deliberations,
I doubt that it would be significant. The time I've invested in converting D1 to D2 code has been trivial.
What, then, do you see as the reason why others have found porting D1 to D2 less trivial? Do you have any advice that might make it easier for others? This is pretty important because I think it's pretty obvious to everyone here that a major reason for the rift between D1 and D2 is Tango, or lack thereof on D2. If everyone found porting D1 to D2 trivial, I assume the Tango port would have been done long ago.
Oct 11 2008
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Sun, Oct 12, 2008 at 4:49 AM, dsimcha <dsimcha yahoo.com> wrote:

 What, then, do you see as the reason why others have found porting D1 to D2
less
 trivial?  Do you have any advice that might make it easier for others?  This is
 pretty important because I think it's pretty obvious to everyone here that a
major
 reason for the rift between D1 and D2 is Tango, or lack thereof on D2.  If
 everyone found porting D1 to D2 trivial, I assume the Tango port would have
been
 done long ago.
A lot of the things I've seen is people having issues making codebases compatible with both D1 and D2, which really _is_ a royal pain.
Oct 11 2008
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtsKacmtsdW5k?= <afb algonet.se> writes:
Jarrett Billingsley wrote:

 A lot of the things I've seen is people having issues making codebases
 compatible with both D1 and D2, which really _is_ a royal pain.
I tried keeping the same codebase compatible with D1 and D2, Phobos and Tango, GDC and DMD, and still remain portable too. (without changing or generating the code with a preprocessor, and without copying / pasting and replacing "version(linux)") I don't think I will try that again :-) --anders
Oct 12 2008
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 11 Oct 2008 18:21:38 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 I tried coding in D2 but a lot of that code is going to need
 significant rework when the cabal have finalized their deliberations,
I doubt that it would be significant. The time I've invested in converting D1 to D2 code has been trivial.
Ok, that's fine but my experience differs. Converting D1 code to D2 was a very tedious exercise. The main problem, which was to be expected really, was that D2 specification kept changing. So now I'm waiting for a stable D2 before doing anything more. Another problem was trying to have the same codebase support both D1 and D2 - that makes it filled with the silly string mixin workaround, which is plain butt ugly. version(D_Version2) { mixin( `<<some D2 specific code>>` ); } else { <<some D1 equivalent>> } -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Oct 11 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 Another problem was trying to have the same codebase support both D1 and D2
 - that makes it filled with the silly string mixin workaround, which is
 plain butt ugly.
I understand that's a problem. I don't think that solving it is compatible with the goal of separate lexing, parsing, and semantic analysis passes. That leaves a couple of options: 1. What I do is have two separate code bases for D1 and D2 code, and use the unix program "meld" to manually do a merge now and then. meld makes this quick and easy. I also use meld to help keep the compiler sources in sync. 2. Use an external text processing facility to generate the two source code versions. This is what I do with the D documentation - they use Ddoc macros to generate each custom version.
Oct 11 2008
parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 11 Oct 2008 23:00:05 -0700, Walter Bright wrote:


 2. Use an external text processing facility to generate the two source 
 code versions.
Yes, this is the path I've now chosen too. Text macro processing is not dead yet :-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Oct 12 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 On Sat, 11 Oct 2008 23:00:05 -0700, Walter Bright wrote:
 
 
 2. Use an external text processing facility to generate the two source 
 code versions.
Yes, this is the path I've now chosen too. Text macro processing is not dead yet :-)
Actually, if you could produce a simple page on how to do this, we can standardize on it.
Oct 12 2008
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 Derek Parnell wrote:
 I tried coding in D2 but a lot of that code is going to need
 significant rework when the cabal have finalized their deliberations,
I doubt that it would be significant. The time I've invested in converting D1 to D2 code has been trivial.
But is your code really representative? As far as Tango goes, it is several times more code in addition to apparently using a wider range of the language. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Oct 12 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Oct 11 2008
next sibling parent Derek Parnell <derek psych.ward> writes:
On Sat, 11 Oct 2008 19:55:01 -0500, Andrei Alexandrescu wrote:

 D2  ... look like being at least 12 months away.
 One way or another D2 will have to be done around April, when TDPL comes 
 along.
Unless TDPL is delayed ;-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Oct 11 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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) -- Bruno Medeiros - Software Developer, MSc. in CS/E graduate http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 16 2008
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
 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
Sorry for the stupid question, but I'm really, really curious. What the heck is TDPL and why is it relevant to D2?
Oct 16 2008
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 16 Oct 2008 21:12:57 +0400, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
 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
Sorry for the stupid question, but I'm really, really curious. What the heck is TDPL and why is it relevant to D2?
*LOL* That's "The D Programming Language" book in works by Andrei Alexandrescu (and co?). Due to ship in April, make sure you book that one! D2 should become stable by then. Note to Andrei: it was previously stated on your site that TDPL ships around October'08. Now it's better but not too much: it's Aprin'09.
Oct 16 2008
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 Note to Andrei: it was previously stated on your site that TDPL ships 
 around October'08. Now it's better but not too much: it's Aprin'09.
Doubly thank you, (re)fixed. Andrei
Oct 16 2008
prev sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtsKacmtsdW5k?= <afb algonet.se> writes:
Denis Koroskin wrote:

 Sorry for the stupid question, but I'm really, really curious.  What 
 the heck is
 TDPL and why is it relevant to D2?
*LOL* That's "The D Programming Language" book in works by Andrei Alexandrescu (and co?). Due to ship in April, make sure you book that one! D2 should become stable by then.
Shouldn't it be the TD2PL then ? --anders
Oct 16 2008
prev sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Thu, Oct 16, 2008 at 1:12 PM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
 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
Sorry for the stupid question, but I'm really, really curious. What the heck is TDPL and why is it relevant to D2?
The D Programming Language, a book Andrei and Walter are apparently working on, and Andrei wants the language to be fixed by the time it comes out so the book doesn't become outdated before it's published.
Oct 16 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Jarrett Billingsley:
 and Andrei wants the language to be fixed by the time it
 comes out so the book doesn't become outdated before it's published.
Is a book about a language becoming more important than the language itself now? Ah ah, this is very funny :o) I'm seeing stranger and stranger things in this newsgroup :-) Bye, bearophile
Oct 16 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Jarrett Billingsley:
 and Andrei wants the language to be fixed by the time it comes out
 so the book doesn't become outdated before it's published.
Is a book about a language becoming more important than the language itself now? Ah ah, this is very funny :o) I'm seeing stranger and stranger things in this newsgroup :-)
I find it hard to not take this as malice. It's uncalled for, really. The point is that a publisher deadline is pretty hard. Missing one makes unhappy a lot of people who've done the logistics and marketing legwork in anticipation for the deadline. So the book describing the language will have to be out on a schedule, and we'd of course like it to describe the language accurately, in particular not talk about features that aren't yet implemented. The book is important maybe even in disproportion because we haven't published pretty much anything about a large body of work we've done, some of which is quite novel. David Wagner's citation of my slides is the first time I ever saw that a serious paper ever cited a slide deck. It's a testament to both the quality of our work and the lack of publications of it. I suggest people with an interest in writing to try their hand at writing articles on what they find noteworthy in D. Andrei
Oct 16 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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 suggest people with an interest in writing to try 
 their hand at writing articles on what they find noteworthy in D.
I've written probably 30+ blog articles, plus three articles, about D and related matters, and I'll keep doing it, I have introduced D to several people in my nation, including my bioinformatics laboratory, where we now use D where Python doesn't cut it. Bye, bearophile
Oct 16 2008
parent Benji Smith <dlanguage benjismith.net> writes:
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
Oct 17 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 I find it hard to not take this as malice. It's uncalled for, really.
Anyway, I am sorry for laughing. I'll try to keep a more rational stance next time. I assume your books are good, and I'll probably buy your D book when it's finished. I like books, and if you need proof readers before the publishing I (and probably others here) may help. When Alex Martelli has written the Python cookbook books has asked for similar help to us, to me too. Bye, bearophile
Oct 16 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Oct 16 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Oct 17 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Oct 11 2008
parent reply Leandro Lucarella <llucax gmail.com> writes:
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? Again, did you ever saw how Python evolves? Really, it's really good. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- they wrap me up in the back of the trunk packed with foam and blind drunk they won't ever take me alive cause they all drive killer cars
Oct 16 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
 Again, did you ever saw how Python evolves? Really, it's really good.
No, I haven't looked at it.
Oct 16 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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... Bye, bearophile
Oct 16 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Oct 16 2008
parent bearophile <bearophileHUGS lycos.com> writes:
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
Oct 16 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Thu, Oct 16, 2008 at 5:37 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 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.
*looks around* You might not have a hired one, but I'm sure there'd be some interest in third parties maintaining it.
Oct 16 2008
prev sibling next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 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.
Certainly understandable. I wonder if someone could take GDC or LDC and the D1 and D2 front end sources, if they really wanted to, and create an unofficial D1.1 out of these? If there's enough demand, this project, and a similar one for D2.1 to bridge D2 -> D3, might be worthwhile. Note that I am *not* lobbying for a D1.1, and I personally am enjoying the bleeding edge with D2 since most the code I write is just for internal use anyhow. I'm just suggesting how D1.1 could be done *if* it is done at all, rather than implying that I think it's a particularly good idea.
Oct 16 2008
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
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
Oct 16 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Bill Baxter wrote:
 On Sat, Oct 11, 2008 at 11:07 PM, Christopher Wright <dhasenan gmail.com>
wrote:
 The issue isn't the lack of new features, so much as bugs being labeled
 enhancements and not being fixed in D1.
Is there anything in that category other than the partial IFTI stuff? I was thinking there were very few such cases, actually.
Hm. I recall complaints relating to that, but no actual instances. My apologies for perpetuating this without substantiating it.
 If you want the new features, you can switch to D2, so I don't see that as a
 problem. (I want the new features, but I'm waiting for Tango support.)
I see three potential categories of D users: 1) bleeding edgers who want the latest and greatest -- don't care if it breaks everything 2) want the latest stuff -- but don't want it to break my code 3) want only bug fixes -- also don't want it to break my code
4) I want the latest stuff -- but if there are no advertised changes except bugfixes, I want my code to continue working between releases. I used to use D2 with lots of CTFE and __traits, but I found that a lot of what I was trying to write couldn't be evaluated at compile time. Then there would be a new release, and the stuff I finally managed to get working would all fail. I didn't really care about backwards compatibility other than that.
Oct 11 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bobef wrote:
 To be honest what I read
 recently about D2 drives me off. I love D1 and I'd love to have some
 of the D2 features, but not D2.
I don't get it.
Oct 11 2008
parent Alix Pexton <alixD.TpextonNO SPAMgmailD.Tcom> writes:
Walter Bright wrote:
 bobef wrote:
 To be honest what I read
 recently about D2 drives me off. I love D1 and I'd love to have some
 of the D2 features, but not D2.
I don't get it.
"If I had asked my customers what they wanted, they would have asked for a faster horse." - Henry Ford A...
Oct 11 2008
prev sibling parent Don Clugston <nospam nospam.com> writes:
Walter Bright wrote:
 u wrote:
 I like this feature so much.
 Is it possible to back port opDot to D 1.0?
The problem is for every last feature in D 2.0, there's someone who wants that and only that ported to 1.0. If I moved over opDot, what am I going to say to everyone else? I move over their features too, and then D 1.0 becomes 2.0 anyway. I suggest instead just moving to 2.0 <g>.
I think that some consideration should be given to those features which make it easier to migrate code from D1 to D2. Especially things which make version(D2) {...} impossible in D1 code.
Oct 11 2008