The difference in tooling stories of DIY ecosystems like Python vs. batteries included ecosystems like Go is fascinating.
I've rarely thought of formatting in Go (occasionally wishing it would allow 1 line if statements). But this forgoes many possible optimizations. We don't get fun stories of 30x improvements! (And Go could be optimized a lot, the main compiler implementation foregoes most possible optimizations because the team prioritizes keeping it simple to enable long term refactoring.)
But then in Python I remember tab or space battles, in C you have endless formatting battles which they call coding styles etc. etc. I've never worked professionally in it but it seems like you get people using random build tools... Which are constantly improving! Yet the constant churn horrifies me, seems like it would take up a lot of mental space. Is that true in practice?
LISP (well, Scheme (well, Racket)) is a weird middle ground. Formatting e.g. seems like a solved problem, built into the IDEs with similar behavior since IDK when (I've never thought about it.) Overall, you sort of create tooling while programming. In Common Lisp, substantial tooling is also built into the professional IDEs. The compilers also do quite a lot.
FWIW the (seemingly?) complete lack of bikeshedding makes it a lot easier to approach Go over Python wrt. tooling. IME it feels impossible to make an informed decision without already being knee-deep in the ecosystem, and yet new developers are forced to decide as part of their IDE setup. It's just plain cruel.
I say every language should standardize on an extremely opinionated formatting tool, whatever those opinions happen to be. To the point where source code should be considered to have a canonical representation. Get rid of the sheds and bikes.
Unfortunately, there are often 14 competing standards...
If your team is full of adults, you just pick a formatter tool at the beginning of the project, add it to your pre-commit hook and then never think about it again.
I really don’t like how black formats list that ends with a comma differently from lists that don’t. I hope this either didn’t make it to ruff or can be turned off.
Either way, it looks like an interesting development!
veqq|2 years ago
I've rarely thought of formatting in Go (occasionally wishing it would allow 1 line if statements). But this forgoes many possible optimizations. We don't get fun stories of 30x improvements! (And Go could be optimized a lot, the main compiler implementation foregoes most possible optimizations because the team prioritizes keeping it simple to enable long term refactoring.)
But then in Python I remember tab or space battles, in C you have endless formatting battles which they call coding styles etc. etc. I've never worked professionally in it but it seems like you get people using random build tools... Which are constantly improving! Yet the constant churn horrifies me, seems like it would take up a lot of mental space. Is that true in practice?
LISP (well, Scheme (well, Racket)) is a weird middle ground. Formatting e.g. seems like a solved problem, built into the IDEs with similar behavior since IDK when (I've never thought about it.) Overall, you sort of create tooling while programming. In Common Lisp, substantial tooling is also built into the professional IDEs. The compilers also do quite a lot.
onetoo|2 years ago
I say every language should standardize on an extremely opinionated formatting tool, whatever those opinions happen to be. To the point where source code should be considered to have a canonical representation. Get rid of the sheds and bikes.
Unfortunately, there are often 14 competing standards...
david2ndaccount|2 years ago
wodenokoto|2 years ago
Either way, it looks like an interesting development!
zanie|2 years ago
freediver|2 years ago