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$B!o(B 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
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 más probable que el tomate sea perita, a que la pera tomatito.
	-- Peperino Pómoro
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$B!o(B 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