There is a dilemma of having to choose between:
A) getting stuck with bad names / apis / language issues forever
B) making painful breaking changes that breaks existing code

See recent D threads for all the polemics this creates on (in)stability of D.

GO avoids this dilemma with the correct approach, IMO: automation of code transition.
See this article for details on gofix: http://blog.golang.org/2011/04/introducing-gofix.html

gofix operates on the AST of the code and performs AST manipulations (no fragile 'sed' / regex based bash scripts!), followed by printing them back to the source code. This is made possible by gofmt, which formats source code.

Here's a snippet from the article:

"Gofix has already made itself indispensable. In particular, the recent reflect changes would have been unpalatable without automated conversion, and the reflect API badly needed to be redone. Gofix gives us the ability to fix mistakes or completely rethink package APIs without worrying about the cost of converting existing code."

This is what we need for D if we want to avoid getting stuck in this dilemma.

Am 26.05.2013 08:32, schrieb timotheecour:
> There is a dilemma of having to choose between:
> A) getting stuck with bad names / apis / language issues forever
> B) making painful breaking changes that breaks existing code
>
> See recent D threads for all the polemics this creates on (in)stability
> of D.
>
> GO avoids this dilemma with the correct approach, IMO: automation of
> code transition.
> See this article for details on gofix:
> http://blog.golang.org/2011/04/introducing-gofix.html
>
> gofix operates on the AST of the code and performs AST manipulations (no
> fragile 'sed' / regex based bash scripts!), followed by printing them
> back to the source code. This is made possible by gofmt, which formats
> source code.
>
> Here's a snippet from the article:
>
> "Gofix has already made itself indispensable. In particular, the recent
> reflect changes would have been unpalatable without automated
> conversion, and the reflect API badly needed to be redone. Gofix gives
> us the ability to fix mistakes or completely rethink package APIs
> without worrying about the cost of converting existing code."
>
> This is what we need for D if we want to avoid getting stuck in this
> dilemma.

Before that, we need to have the compiler available as library, that is what Go guys kind of do.

--
Paulo

On 5/26/13, timotheecour <timothee.cour2@gmail.com> wrote:
> This is what we need for D if we want to avoid getting stuck in this dilemma.

It's good for fixing 99% of the cases. But don't forget we also have string mixins (and string imports), which can't easily be fixed. Because of that we shouldn't allow ourselves to be *too* open towards breaking code just because there would be a conversion tool available.

Also, if you have a list of dependencies and all of that code ends up breaking, you may end up having to wait for maintainers to update their code. For various reasons you may end up waiting for too long (e.g. maybe the only developer with commit rights to a dependency goes to a vacation). So this becomes another complication.

What I'm saying is, a conversion tool doesn't solve all problems. I'd rather we focus on not breaking code. The use of aliases and deprecation stages is nicer, it allows your codebase to be compilable with several versions of the compiler. With automatic code conversion you'd end up having to maintain several branches of your library just to make it compilable with different D releases.

As for *language* changes, we are likely getting closer to the point where there won't be any large breaking changes anymore.

Anyway, the tool isn't a bad idea at all, let's just not make it an excuse to break too much code too many times. :)