Chris's Wiki :: blog/programming/GoWhyGofmtAccepted Commentshttps://utcc.utoronto.ca/~cks/space/blog/programming/GoWhyGofmtAccepted?atomcommentsDWiki2017-03-31T22:12:54ZRecent comments in Chris's Wiki :: blog/programming/GoWhyGofmtAccepted.By Michael Walker on /blog/programming/GoWhyGofmtAcceptedtag:CSpace:blog/programming/GoWhyGofmtAccepted:32b5ff6b0ae735a480bf6df863afce66dc728cfdMichael Walkerhttps://www.barrucadu.co.uk/<div class="wikitext"><p>The social vs technical aspect is a very good point that I hadn't considered, thanks for that insight.</p>
</div>2017-03-31T22:12:54ZBy tom westberg on /blog/programming/GoWhyGofmtAcceptedtag:CSpace:blog/programming/GoWhyGofmtAccepted:2dfedfb15bd8623c647ad4c49e62488ce1c776e3tom westberg<div class="wikitext"><p>While I agree that the social aspects are important, there's one other difference: in python two programmers can use indentation that looks the same, but isn't (tabs vs spaces). If all editors used only spaces for indentation, not an issue. If all shared tab sizes and usd tabs where possible, not an issue. As it is... it's an issue.</p>
</div>2017-03-30T14:19:05ZBy Ross McFarlane on /blog/programming/GoWhyGofmtAcceptedtag:CSpace:blog/programming/GoWhyGofmtAccepted:15adfcbf72f2d54dc428a36a20d201cdcbcc250bRoss McFarlane<div class="wikitext"><p>I think you're right about the difference between force and coercion, but I think the motivation might be slightly more subtle.</p>
<p>In python, formatting is something that the user can get wrong. It's a barrier to a working program. For new developers learning the language, this is a seemingly arbitrary decision that stands in the way of them getting something working.</p>
<p>gofmt solely exists to help the developer. Badly formatted programs are still valid. Once you have a working program, gofmt can improve it by making it readable.</p>
</div>2017-03-26T12:35:33ZBy Aneurin Price on /blog/programming/GoWhyGofmtAcceptedtag:CSpace:blog/programming/GoWhyGofmtAccepted:b34826e36578c9a99f4d24f6ab329b5bca4ea5c6Aneurin Price<div class="wikitext"><blockquote><p>In just about every other language, scopes are coded with an edge-triggered signal. Python chose a level-triggered coding instead. That was a mistake, plain and simple. It means the programmer must maintain the signal on a line-by-line basis instead of a scope-by-scope basis.</p>
</blockquote>
<p>I don't think I've ever seen this put so well, thanks.</p>
</div>2017-03-20T21:24:00ZBy Aristotle Pagaltzis on /blog/programming/GoWhyGofmtAcceptedtag:CSpace:blog/programming/GoWhyGofmtAccepted:cc90ecf94253166900d4d209b68dc779cb4f7aa1Aristotle Pagaltzishttp://plasmasturm.org/<div class="wikitext"><p>I don’t think petulance (to restate your thesis pointedly and concisely) is the reason. I think what you call a practical side-effect is actually the driver.</p>
<p>In just about every other language, scopes are coded with an edge-triggered signal. Python chose a level-triggered coding instead. That was a mistake, plain and simple. It means the programmer must maintain the signal on a line-by-line basis instead of a scope-by-scope basis.</p>
<p>This precludes tooling to maintain the level information – not just big guns of the <code>gofmt</code> variety, but even small things like reindent-this-region editor features. The level information must be hand-maintained, requiring a programmer’s diligence, humility, and patience, i.e. the opposite of every virtue.</p>
<p>The designers of Go chose to make their style choices the lazy and impatient option, requiring only humility. There is no great mystery to their success.</p>
</div>2017-03-20T17:50:08ZBy Goose on /blog/programming/GoWhyGofmtAcceptedtag:CSpace:blog/programming/GoWhyGofmtAccepted:b6af3308b3742d41e16d7510b16d853bfc816332Goosehttp://go.c800colon5.com<div class="wikitext"><p>another observation I've had about the rise of formatting tools (particularly in the Python world) is that, since the advent of Github, when I send patches to the maintainers of my third-party dependencies, they are much more likely to be applied verbatim to the code.</p>
<p>10 years ago, if I sent a diff, the maintainer would perhaps half the time apply the diff but then twiddle with the code a little before committing it to whatever SCM was in use. Although I was usually fairly careful about honoring whatever formatting style was in use, the maintainers tended to accept divergences as line noise and would fix them.</p>
<p>With the Pull Request model, the onus is shifted to the person making the request, but this presents a challenge: how does a project specify formally what their formatting standards are? Obviously, they can run the linter of their choice against the PR, but it would be nice if PR submitters could avoid that hassle.</p>
<p>The beauty of gofmt/pep8 for me is that, if I'm willing to sacrifice my personal style-cow, I can let the tool fix everything, and the chances of having my editor get all the style cases right is much improved. Also, I can tell users of anything I publish "just use gofmt" and the impedance mismatches go away.</p>
</div>2017-03-20T14:07:15Z