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.

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.

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/

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.

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.

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

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.

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...

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 :-)

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