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

Reply via email to