I'm sure is such a formatting tool existed and it worked well, the community would get behind it. That said, a standard formatting guide enforcable through community pressure would be a good first step. I feel creating something like this is great use case for benevolent dictatorial powers.
Jake On Monday, February 17, 2014 11:56:39 AM UTC-5, Stefan Karpinski wrote: > > On Mon, Feb 17, 2014 at 11:09 AM, Job van der Zwan > <j.l.van...@gmail.com<javascript:> > > 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. >
