View mode: basic / threaded / horizontal-split · Log in · Help
July 16, 2012
Re: D versionning
On 7/15/2012 5:36 PM, Jonathan M Davis wrote:
> Arguably, we've been adding too many new features (e.g. new lambda syntax and
> SIMD support), given that we're supposed to be making everything that we
> already  have work properly, but those features haven't been breaking changes,
> and presumably forcing Walter to just fix bugs wouldn't be all that pleasant
> for him.

SIMD support is critical for D's mission as a systems programming language, and 
has been important in attracting some significant adoption of D.
July 16, 2012
Re: D versionning
On 7/15/2012 5:45 PM, Adam Wilson wrote:
> I think the problem is that in the real world, that state is somewhat unlikely.
> For example, Walter is currently working on COFF support, this is arguably a new
> feature (we already can make programs work on Windows). Programmers aren't
> machines and fixing bugs all day is boring, we want to do the fun stuff, in this
> case, new features. It just so happens that it's the fun stuff that makes fixing
> bugs bearable. I don't think it's fair of us to demand that Walter only fix
> bugs, besides, COFF support is a HIGHLY requested new feature, he is just
> supposed to ignore them?

Supporting Win64 is absolutely critical for the future of D, and the sooner we 
get it, the better. The COFF route is the shortest route to doing it, and the 
most practical for attracting devs, which is why it's the way we're going.

32 bit code is dead on OSX, is dying rapidly on Linux and Windows.
July 16, 2012
Re: D versionning
On Sun, 15 Jul 2012 23:00:01 -0700, Walter Bright  
<newshound2@digitalmars.com> wrote:

> On 7/15/2012 5:45 PM, Adam Wilson wrote:
>> I think the problem is that in the real world, that state is somewhat  
>> unlikely.
>> For example, Walter is currently working on COFF support, this is  
>> arguably a new
>> feature (we already can make programs work on Windows). Programmers  
>> aren't
>> machines and fixing bugs all day is boring, we want to do the fun  
>> stuff, in this
>> case, new features. It just so happens that it's the fun stuff that  
>> makes fixing
>> bugs bearable. I don't think it's fair of us to demand that Walter only  
>> fix
>> bugs, besides, COFF support is a HIGHLY requested new feature, he is  
>> just
>> supposed to ignore them?
>
> Supporting Win64 is absolutely critical for the future of D, and the  
> sooner we get it, the better. The COFF route is the shortest route to  
> doing it, and the most practical for attracting devs, which is why it's  
> the way we're going.
>
> 32 bit code is dead on OSX, is dying rapidly on Linux and Windows.

I absolutely agree with this, but you already know that. I've been  
lobbying for COFF ever since I first showed up here. :-)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 16, 2012
Re: D versionning
On 7/15/2012 4:34 PM, Jonathan M Davis wrote:
>> It needs to stop completely.
>
> Most of the renaming of functions which has gone on has been because Phobos
> has been inconsistent with its naming, which makes it harder to use and learn.
> As that's sorted out (as has mostly been done), those changes will stop. But
> do you honestly expect that everything in the standard library is going to be
> frozen at some point? Is that what you're suggesting?

I've had a lot of my own working D code break because of name changes in Phobos. 
This is extremely annoying. I can fully understand that it drives people away. 
It's got to stop.

We could bikeshed forever about what exact spelling and casing a name should 
have. That's fine for new names. Old names should stay.

Breaking things should have a very high bar. Merely a name change is not good 
enough.
July 16, 2012
Re: D versionning
On 7/15/2012 4:53 PM, deadalnix wrote:
> On 16/07/2012 01:07, Walter Bright wrote:
>> It needs to stop completely.
>>
>
> No. It hasn't been made for no reasons.
>
> But yes, some code is broken in the process. This is exactly why we need a more
> sophisticated versionning process (note the recurring pattern in my posts :D ).
>
> The fact that some people have legacy code shouldn't stop D progress. But with
> the current system, D must either break code or make no progress.

Changing names is minute progress, and is too costly in terms of annoying 
existing users and breaking their code.
July 16, 2012
Re: D versionning
On Sunday, July 15, 2012 22:55:40 Walter Bright wrote:
> On 7/15/2012 5:36 PM, Jonathan M Davis wrote:
> > Arguably, we've been adding too many new features (e.g. new lambda syntax
> > and SIMD support), given that we're supposed to be making everything that
> > we already  have work properly, but those features haven't been breaking
> > changes, and presumably forcing Walter to just fix bugs wouldn't be all
> > that pleasant for him.
> 
> SIMD support is critical for D's mission as a systems programming language,
> and has been important in attracting some significant adoption of D.

Oh, I'm not saying that the feature isn't valuable. I'm just pointing out that 
it's adding something new rather than actually finishing all of the features 
that we're already supposed to have, and in theory, after TDPL's release, we 
were supposed to be avoiding adding new features which we didn't need to make 
all of the existing features work until we'd finished all of the features 
outlined in TDPL. And maybe it _was_ worth adding SIMD support now rather than 
later, but it goes against what we said we were doing.

- Jonathan M Davis
July 16, 2012
Re: D versionning
On 7/15/2012 11:06 PM, Jonathan M Davis wrote:
> And maybe it _was_ worth adding SIMD support now rather than
> later, but it goes against what we said we were doing.

It was a leap of faith on my part, but I think events have shown that it was 
indeed worth it.
July 16, 2012
Re: D versionning
On Monday, 16 July 2012 at 06:07:21 UTC, Walter Bright wrote:

> Changing names is minute progress, and is too costly in terms 
> of annoying existing users and breaking their code.

Cost can be lowered - by introducing (semi-)automatic 
refactoring/upgrade mode.

dmd -upgrade zzz.d

Compiler can do renames (clear() -> destroy()), insert
workarounds (if needed), and so on. Easy, fast, no risk of human
error.

Of course, in certain cituations no automatic upgrade is
possible...
July 16, 2012
Re: D versionning
On 7/15/2012 11:48 PM, RivenTheMage wrote:
> On Monday, 16 July 2012 at 06:07:21 UTC, Walter Bright wrote:
>
>> Changing names is minute progress, and is too costly in terms of annoying
>> existing users and breaking their code.
>
> Cost can be lowered - by introducing (semi-)automatic refactoring/upgrade mode.
>
> dmd -upgrade zzz.d
>
> Compiler can do renames (clear() -> destroy()), insert
> workarounds (if needed), and so on. Easy, fast, no risk of human
> error.
>
> Of course, in certain cituations no automatic upgrade is
> possible...

It is a good idea, but I'd be nervous myself about allowing the compiler to edit 
my code :-)
July 16, 2012
Re: D versionning
On Sunday, July 15, 2012 23:05:39 Walter Bright wrote:
> On 7/15/2012 4:34 PM, Jonathan M Davis wrote:
> >> It needs to stop completely.
> > 
> > Most of the renaming of functions which has gone on has been because
> > Phobos
> > has been inconsistent with its naming, which makes it harder to use and
> > learn. As that's sorted out (as has mostly been done), those changes will
> > stop. But do you honestly expect that everything in the standard library
> > is going to be frozen at some point? Is that what you're suggesting?
> 
> I've had a lot of my own working D code break because of name changes in
> Phobos. This is extremely annoying. I can fully understand that it drives
> people away. It's got to stop.
> 
> We could bikeshed forever about what exact spelling and casing a name should
> have. That's fine for new names. Old names should stay.
> 
> Breaking things should have a very high bar. Merely a name change is not
> good enough.

Which is precisely why I was trying to get all of the name changes out of the 
way early and quickly so that we'd get the names fixed and then not having any 
more of that kind of breakage. At this point, in almost all cases (maybe even 
in all cases), when a name gets changed, it's because the function is being 
replaced by a better function. And even that kind of change is happening less 
and should eventually become quite rare. While there are a number of symbols 
currently going through the deprecation process in Phobos, not much is being 
scheduled for deprecation anymore, and most of the stuff on the deprecation 
path has already been deprecated and is approaching the point when it will be 
removed.

I understand your annoyance with the name changes, but when it was discussed, 
almost everyone in the newsgroup thought that it was worth it to make those 
changes in order to make the library more consistent. Having done that, we are 
now far more stringent about changing names.

- Jonathan M Davis
6 7 8 9 10 11 12 13 14
Top | Discussion index | About this forum | D home