On Mon, Feb 17, 2014 at 11:09 AM, Job van der Zwan <[email protected] > wrote:
> Developing an autoformatting tool? Like I said earlier in another > discussion, I really miss gofmt when not programming in Go these days. But > there's more to it than simple convenience. > > To quote Andrew Gerrand's > arguments<http://blog.golang.org/go-fmt-your-code>in favour of having one > standard tool for this (he was discussing gofmt): > >> >> - easier to *write*: never worry about minor formatting concerns >> while hacking away, >> - easier to *read*: when all code looks the same you need not >> mentally convert others' formatting style into something you can >> understand. >> - easier to *maintain*: mechanical changes to the source don't cause >> unrelated changes to the file's formatting; diffs show only the real >> changes. >> - *uncontroversial*: never have a debate about spacing or brace >> position ever again! >> >> Regarding that last point: when I brought up autoformatting tools last > time, one argument against making one now was that there is no consensus > yet on a best stye for writing Julia. However, I think this thinking is the > wrong way round. > > Some formatting decisions are inherently arbitrary. It is more important > that *a* choice is made. That's either a majority-vote or top-down > decision. Making an autoformatting tool will drive these decisions, rather > than wait for them to happen on their own (some time after the heat death > of the universe, if other languages are any indication). > I'm actually quite sympathetic to this idea. I suspect that Jeff thinks it's a bit of a waste of time but might be fine with using one as long as he didn't have to put effort into creating it. My guess is that Viral doesn't really care, and Alan is actively waging a war against spaces, so he might be miffed to have them automatically inserted everywhere ;-) Also highly relevant to a language still in its infancy is that a tool like > this makes certain breaking changes to the language or standard library > less painful. See the GoFix tool used in the Go language before it > stabilised into version 1.0: > > Gofix <http://goneat.org/cmd/gofix/> is a new tool that reduces the >> amount of effort it takes to update existing code. It reads a program from >> a source file, looks for uses of old APIs, rewrites them to use the current >> API, and writes the program back to the file. Not all API changes preserve >> all the functionality of an old API, so gofix cannot always do a perfect >> job. When gofix cannot rewrite a use of an old API, it prints a warning >> giving the file name and line number of the use, so that a developer can >> examine and rewrite the code. Gofix takes care of the easy, repetitive, >> tedious changes, so that a developer can focus on the ones that truly merit >> attention. Each time we make a significant API change we’ll add code to >> gofix to take care of the conversion, as much as mechanically possible. >> When you update to a new Go release and your code no longer builds, just >> run gofix on your source directory. >> > http://blog.golang.org/introducing-gofix > > Having a tool like that would surely help with the adoption of Julia, as > it would reduce fears of code breaking all the time. Also, it would let the > developers of the language make more drastic changes for a longer time, as > they would not have to worry as much about breaking existing code out there. > This is actually less relevant to Julia than you might think. Julia's syntax is pretty simple and quite stable. We've made almost no breaking syntax changes since version 0.1 – I literally can't think of a single one. The backwards incompatible changes have been API changes rather than syntax changes. Thanks to multiple dispatch, API changes can be easily handled via deprecation. On the other hand, since dynamic languages like Julia are inherently hard to statically analyze, we can't handle really API changes at the level of AST transformations like Go can – because you can't in general statically resolve what function a call actually invokes.
