On 2013-11-11 00:08, Nick wrote:

> I'd definitely vote for a fix-up tool. I think it's fair on developers
> to make a change for consistency of the language whilst providing a
> mostly automated means to do a one-off fix. It'd be a small onus on a
> tiny subset of developers to sort out any extraordinary edge cases.

Apple has created several fix-up tools, either built-in to Xcode or Clang. It's mostly for moving code to using a more modern style Objective-C, that is ARC, new syntax for arrays, dictionaries and so on.

-- 
/Jacob Carlborg

You're right.

Also the D have a deprecation-notice-period that adds stability in comparison to just-in-repo changes.

I don't disagree with what you are saying, however I think it is healthy to always question the status quo and continue to try and find innovative ways to destroy established thinking that otherwise limits what can and cannot be done.

Currently, the most acceptable methods discussed in here of moving forward and getting rid of old inadequate concepts, seems to be through very carefully considered deprecation and the implementing of automated methods for updating old code to conform to newer and better standards.

We do have deprecation, but so far I have not seen methods of automated updates so maybe that's something worth considering down the road.

I do have some experience with automating updates of old code. Certain databases I've worked on required updates, and the only foolproof method of doing it was to automate the process as much as possible, and I've had very good success doing it that way. Manually updating code is very stressful and error prone, no one wants to do it, but if you can click on a button and have the code updated for you without concern that it will fail miserably or cause weird side effects, upgrades become a good thing instead of a bad thing.

--rt

On Monday, 11 November 2013 at 00:13:34 UTC, Jonathan M Davis wrote:
> On Monday, November 11, 2013 00:39:04 Rob T wrote:
>> On Sunday, 10 November 2013 at 23:08:11 UTC, Nick wrote:
>> > The alternative is to slowly build up a menagerie of quirks
>> > that put us on the same path as C++.
>> 
>> It seems that a buildup of quirks is underway as is evidenced by
>> this discussion. The other solution is to at some point place a
>> freeze on D2 with bug support only and move on to D3 with at
>> least the worse of the known baggage removed. There are of course
>> disadvantages and dangers with doing that, but it is an option.
>> 
>> Ultimately if we try and keep everyone happy, at some point no
>> one will be happy, so I think it's worth trying to find good
>> solutions to enable the language to evolve in ways that can leave
>> baggage from the past behind.
>
> I think that it's naive to think that any serious language will avoid building
> up quirks and rough corners over time. You never get a language completely
> right (assuming that's even possible), and you only have so long after you
> create it to tweak stuff before it has to be more or less set in stone for it
> to be useable in the real world. Some stuff can be tweaked over time even after
> you're "stable," but you have to be very careful about it in order to minimize
> if not outright eliminate breakage. And the longer that a language is around,
> the more unwieldy it's going to get. Either it doesn't innovate at all and
> avoids building up more quirks, or it innovates and ends up with quirks as it
> adds and adjusts stuff after the fact.
>
> Eventually, the baggage from those quirks will be big enough that if you want
> to get rid of them, you'll be forced to either create a new language or to
> create a new version of the language which breaks backwards compatiibiity,
> which tends to be little different from just creating a new language. I really
> don't think that there's any way around that. D doesn't have all of the
> baggage of C and C++, because it's a new language which breaks compatibility
> with them, but it's building up its own quirks and mistakes and will continue
> to do so. We should do our best to minimize that, but I really don't think
> that there's any way avoid it completely.
>
> Languages _need_ to be more or less set in stone in order to be useable in the
> real world, and if you set them in stone, then you're going to end up with
> quirks and baggage when you add onto them later. That's just the way it is,
> and I think that anyone who thinks that D can avoid the same fate as C++ in
> that regard is being naive. Some day, there will be a D++, or a D3, or an E,
> or whatever for the same reason that we created D instead of continuing to use
> C++ and for the same reason that the python developers created python 3. But
> that's a _long_ way off. First, we have to make D2 work, and part of that means
> living with at least some of the mistakes that we've made and quirks that the
> language has acquired. And honestly, many of those are tradeoffs that I don't
> think that anyone has a good solution for at this point anyway. So, even if
> someone went and created D3 right now, I don't think that it would be
> appreciably better than D2 (in some regards maybe, but not enough to be worth
> the split that that would cause to the code and to the community).
>
> - Jonathan M Davis