View mode: basic / threaded / horizontal-split · Log in · Help
March 26, 2009
Re: State of Play
== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Tomas Lindquist Olsen wrote:
> > On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright
> > <newshound1@digitalmars.com> wrote:
> >> Denis Koroskin wrote:
> >>> One of the breaking changes that I recall was that you made Posix
> >>> identifier built-in and thus any custom Posix versioning became an
> >>> error. Not sure if it was introduced in 1.041, though, but it is
> >>> still a breaking change.
> >> It was more of a build system change, but I get your point. It shows that
> >> even trivial changes are a bad idea for D1.
> >>
> >
> > Everyone certainly does not think it was a bad idea. If trivial things
> > like this sets people off, they should at least look at the problem
> > (and comment those few lines) before complaining.
> >
> > All my humble opinion of course.
> To me, it illustrates a fundamental disconnect. One cannot have both a
> 100% stable language and yet introduce improvements to it.
> As for the does one develop stable code targeting D1 and D2, I would
> suggest targeting D1 but be careful to use the string alias for all the
> char[]'s, and treat strings as if they were immutable. This will cover
> 90% of any source code changes between D1 and D2, perhaps even more than
> 90%. It's also very possible to write D1 code using the immutability
> style, in fact, I advocated it long before D2 (see all the old threads
> discussing Copy On Write). If code follows the COW principle, it should
> port from D1 to D2 with little more than a few cosmetic changes.

One minor thing in druntime that may help is that opEquals() returns
an equals_t, which evaluates to bool in D2.  It would probably be worth
changing the declaration in D1 to have a similar alias that evaluates to
int.  That should help address another minor inconsistency between D1
and D2.
March 26, 2009
Re: State of Play
On Thu, 26 Mar 2009 15:50:22 -0400, Brad Roberts <braddr@puremagic.com>  
wrote:

> Steven Schveighoffer wrote:
>> On Thu, 26 Mar 2009 07:42:01 -0400, Mike James <foo@bar.com> wrote:
>>
>>> Is Tango for D2.0 at a level of D1.0 and can be used now?
>>
>> No.  It is being worked on.  I don't forsee Tango for D2 being ready
>> until at least September, perhaps later.
>>
>> -Steve
>
> Would you mind outlining / documenting what needs to be done?  I'd
> expect that there are a number of people who would be interested in
> volunteering to help.

what needs to be done:

1. Make Tango build on top of druntime.  I just merged from trunk  
yesterday, which was about 300 files, so most likely there will be compile  
issues ;)
2. Const-ify everything.  Some parts are already done.
3. Make all opApply's scoped properly.

Not sure what happens after that, but step 2 alone is a ton of work.  In  
addition, there are some blocker bugs in DMD (1645 and 2524 right now)  
that prevent a complete port.

When the shared/unshared paradigm is released, there's probably another  
ton of work to do :)

And of course, there's the possibility of redesigns.  A lot of code can  
probably make use of __traits and there are the new range constructs to  
consider.  Of course, these are all probably things that would be severely  
different from the D1 version, so they probably won't happen for a while.

Note that the September or later date is based on the amount of time I  
spend on it (which isn't a lot).  Someone who wanted to do nothing but  
porting Tango to D2 could probably get it done in a month or two.  Note  
also that I don't consider the port done until all the "cast to get it to  
compile" hacks are removed.  In some cases, this requires design changes,  
and in some of those, tough decisions.

-Steve
March 26, 2009
Re: State of Play
On Thu, Mar 26, 2009 at 9:02 PM, Walter Bright
<newshound1@digitalmars.com> wrote:
> Tomas Lindquist Olsen wrote:
>>
>> On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>>
>>> Denis Koroskin wrote:
>>>>
>>>> One of the breaking changes that I recall was that you made Posix
>>>> identifier built-in and thus any custom Posix versioning became an
>>>> error. Not sure if it was introduced in 1.041, though, but it is
>>>> still a breaking change.
>>>
>>> It was more of a build system change, but I get your point. It shows that
>>> even trivial changes are a bad idea for D1.
>>>
>>
>> Everyone certainly does not think it was a bad idea. If trivial things
>> like this sets people off, they should at least look at the problem
>> (and comment those few lines) before complaining.
>>
>> All my humble opinion of course.
>
> To me, it illustrates a fundamental disconnect. One cannot have both a 100%
> stable language and yet introduce improvements to it.
>

I don't necessarily want a 100% stable language. In fact I don't. But
obviously asking for both is just silly.
The only thing I'm not happy about is if code that used to work, still
compiles, but no longer works. This is where the real problem is and
I've seen it several times. MinWin, APaGeD and probably others.
March 26, 2009
Re: State of Play
On Thu, Mar 26, 2009 at 9:25 PM, Tomas Lindquist Olsen
<tomas.l.olsen@gmail.com> wrote:
> On Thu, Mar 26, 2009 at 9:02 PM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> Tomas Lindquist Olsen wrote:
>>>
>>> On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright
>>> <newshound1@digitalmars.com> wrote:
>>>>
>>>> Denis Koroskin wrote:
>>>>>
>>>>> One of the breaking changes that I recall was that you made Posix
>>>>> identifier built-in and thus any custom Posix versioning became an
>>>>> error. Not sure if it was introduced in 1.041, though, but it is
>>>>> still a breaking change.
>>>>
>>>> It was more of a build system change, but I get your point. It shows that
>>>> even trivial changes are a bad idea for D1.
>>>>
>>>
>>> Everyone certainly does not think it was a bad idea. If trivial things
>>> like this sets people off, they should at least look at the problem
>>> (and comment those few lines) before complaining.
>>>
>>> All my humble opinion of course.
>>
>> To me, it illustrates a fundamental disconnect. One cannot have both a 100%
>> stable language and yet introduce improvements to it.
>>
>
> I don't necessarily want a 100% stable language. In fact I don't. But
> obviously asking for both is just silly.
> The only thing I'm not happy about is if code that used to work, still
> compiles, but no longer works. This is where the real problem is and
> I've seen it several times. MinWin, APaGeD and probably others.
>

Which leads me to: If I was to help with a D 1.1 implementation, only
features that would not change any semantics of valid D1 code would go
in.
March 26, 2009
Re: State of Play
Tomas Lindquist Olsen wrote:
> On Thu, Mar 26, 2009 at 9:25 PM, Tomas Lindquist Olsen
> <tomas.l.olsen@gmail.com> wrote:
>> On Thu, Mar 26, 2009 at 9:02 PM, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>> Tomas Lindquist Olsen wrote:
>>>> On Thu, Mar 26, 2009 at 8:17 PM, Walter Bright
>>>> <newshound1@digitalmars.com> wrote:
>>>>> Denis Koroskin wrote:
>>>>>> One of the breaking changes that I recall was that you made Posix
>>>>>> identifier built-in and thus any custom Posix versioning became an
>>>>>> error. Not sure if it was introduced in 1.041, though, but it is
>>>>>> still a breaking change.
>>>>> It was more of a build system change, but I get your point. It shows that
>>>>> even trivial changes are a bad idea for D1.
>>>>>
>>>> Everyone certainly does not think it was a bad idea. If trivial things
>>>> like this sets people off, they should at least look at the problem
>>>> (and comment those few lines) before complaining.
>>>>
>>>> All my humble opinion of course.
>>> To me, it illustrates a fundamental disconnect. One cannot have both a 100%
>>> stable language and yet introduce improvements to it.
>>>
>> I don't necessarily want a 100% stable language. In fact I don't. But
>> obviously asking for both is just silly.
>> The only thing I'm not happy about is if code that used to work, still
>> compiles, but no longer works. This is where the real problem is and
>> I've seen it several times. MinWin, APaGeD and probably others.
>>
> 
> Which leads me to: If I was to help with a D 1.1 implementation, only
> features that would not change any semantics of valid D1 code would go
> in.

Isn't this the point of the whole "D 1.1" idea?
March 26, 2009
Re: State of Play
Tomas Lindquist Olsen wrote:
> Which leads me to: If I was to help with a D 1.1 implementation, only
> features that would not change any semantics of valid D1 code would go
> in.

But they always do. Many of the complaints about D1 breaking things is 
the result of bug fixes to D1 inadvertently breaking something unexpected.
March 26, 2009
Re: State of Play
Tomas Lindquist Olsen wrote:
> I don't necessarily want a 100% stable language. In fact I don't. But
> obviously asking for both is just silly.
> The only thing I'm not happy about is if code that used to work, still
> compiles, but no longer works. This is where the real problem is and
> I've seen it several times. MinWin, APaGeD and probably others.

What do you suggest?

It's why there's a "last stable version" of D1 on the website. With any 
software package, if you always download the latest version but another 
package was only tested with a different version, it's likely to have 
problems.
March 26, 2009
Re: State of Play
Tomas Lindquist Olsen wrote:
> D1 does have some missing features that are in D2, and could be
> backported to D1 without breaking any code.
> This isn't going to happen for the sake of stability. But if I want to
> use some of the new features, I have to get all the cruft that made me
> look into D in the first place as well. A major reason I started with
> D was because of simple syntax, GC and lack of the const hell.
> 
> D2 is no longer a simple language, you have to know all kinds of shit
> to be able to use it correctly.
> 
> All my projects at the moment are in C++. And TBH I don't see that
> changing any time soon. The stuff I did in D no longer works, and I
> don't have time to debug the entire thing to figure out how/where the
> compiler changed.

I've worked with C/C++ for decades, and it's a miracle if code that 
compiled 10 years ago compiles today without changes. Code never works 
without changes when porting to a different compiler. Code targeted at 
VC tends to target specific versions of VC. "Portable" libraries like 
Boost, STL, and Hans Boehm GC are full of #ifdef's.

The only real difference from D is that:
1. The evolution of C++ is about 10 times slower than D.
2. We're all so used to working around these problems in C++, we don't 
notice it.

I understand your frustrations with the changes, just not why that means 
using C++ <g>.

> And yes, the Phobos vs. Tango (which in turn keeps breaking) situation
> of course isn't making things better.
March 26, 2009
Re: State of Play
Steven Schveighoffer wrote:
> what needs to be done:
> 
> 1. Make Tango build on top of druntime.  I just merged from trunk 
> yesterday, which was about 300 files, so most likely there will be 
> compile issues ;)
> 2. Const-ify everything.  Some parts are already done.
> 3. Make all opApply's scoped properly.
> 
> Not sure what happens after that, but step 2 alone is a ton of work.  In 
> addition, there are some blocker bugs in DMD (1645 and 2524 right now) 
> that prevent a complete port.
> 
> When the shared/unshared paradigm is released, there's probably another 
> ton of work to do :)

You can already used shared/unshared. The semantics aren't implemented, 
but the type system support for it is.

> 
> And of course, there's the possibility of redesigns.  A lot of code can 
> probably make use of __traits and there are the new range constructs to 
> consider.  Of course, these are all probably things that would be 
> severely different from the D1 version, so they probably won't happen 
> for a while.
> 
> Note that the September or later date is based on the amount of time I 
> spend on it (which isn't a lot).  Someone who wanted to do nothing but 
> porting Tango to D2 could probably get it done in a month or two.  Note 
> also that I don't consider the port done until all the "cast to get it 
> to compile" hacks are removed.  In some cases, this requires design 
> changes, and in some of those, tough decisions.
> 
> -Steve
March 26, 2009
Re: State of Play
On Thu, Mar 26, 2009 at 9:45 PM, grauzone <none@example.net> wrote:
> Tomas Lindquist Olsen wrote:
>>
>> Which leads me to: If I was to help with a D 1.1 implementation, only
>> features that would not change any semantics of valid D1 code would go
>> in.
>
> Isn't this the point of the whole "D 1.1" idea?
>

People seem to have different ideas of what D 1.1 should be.
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home