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). 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. On Sunday, 16 February 2014 19:50:06 UTC+1, Mike Innes wrote: > > We've published a project ideas list for GSoC here: > > http://julialang.org/gsoc/2014/ > > We'd like our ideas page to be as healthy and diverse as possible, so > please do make your suggestions. Projects can include things like new > packages, specific language/package features, or something more > experimental; really, there's scope for any kind of coding project here, > but those which fit roughly three months of work and have a clear, tangible > benefit are best. > > If you maintain or use a package which is missing key features, now would > be a great time to ask for them! > > You're welcome to add project descriptions via github, but if you want to > suggest something more informally you can do so here - I'll continue to > write up as many as I can. > > Thanks, > Mike > >
