Go ahead and break code, but give us the tools to fix it. (Was Re: Dicebot on leaving D: It is anarchy driven development in all its glory.)

[John Carter]

On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote:

> If I fix the bug, I break existing code, and apparently a 
> substantial amount of existing code. What's your advice on how 
> to proceed with this?

https://forum.dlang.org/post/ioiglnwckjsdrukpxbvn@forum.dlang.org

I've been updating some pre-C++11 code to C++14 and above.

It's actually been pretty trivial, because gcc has nice warnings 
that tell me exactly which file and line I need to fix, and I can 
turn them on one by one and clean up all warnings in the code 
base and on to the next.

If you look at my delta's 99% of them are deletions rather than 
modifications, and quite a few of them could have been automated 
(if it wasn't for the horrible complexity of the preprocessor).

I have also been shifting a bunch of ruby 1.8.6 era code to 2.3 
and beyond, a lot of the fixes I could let rubocop autofix for 
me, review for peace of mind sake, run unit tests, done. Yes 
autofix. Sounds very scary...but it has been amazingly rock solid 
so far.

Language development needs to leave behind the notion that it's 
an API fixed for all eternity.

Rather the assumption must be, a language processor eats source, 
it can (re)write source as well.

To evolve, a language processor must learn to evolve the code 
base it supports.