> Significant whitespace pushes a tooling problem (correct indentation) into the human domain. It might have made sense before autoformatters that run on save, but I agree with you that in today's languages, it's a net negative.
Sorry, I don't follow. There's nothing preventing a tool from re-indenting code when it's pasted (i.e.: considering indentation within the pasted text relative to its first line, and then applying an indentation offset according to where it's pasted), and many already do. It's the same kind of logic that's used to auto-format code in braced languages; arguably simpler unless it's also validating the existing indentation of the pasted text.
And actually, who even is relying on "autoformatters that run on save"? I want the code to look right as I'm writing it, not after. The tools you describe are, to me, about maintaining project standards when multiple people are involved, but fundamentally each person is still making the code look locally, personally right before saving (or committing, since these things are also often done with pre-commit hooks). I can't imagine just typing out whatever slop is syntactically correct and waiting to save the file to fix it. Not when I have a proper text editor that facilitates typing it out the way I want it, taking advantage of awareness of the language syntax.
> none of the new languages that have seen success in the last ten years (Go, Rust, Swift, Dart, Kotlin) rely on the author to format code correctly - instead, they do it for you.
Languages do not and cannot format code. Text editors (including the ones built into IDEs) do. If I type a } and the text changes position, it's not the programming language that did this.
And this is also not better in braced languages. Just as I can input a } on a new line in Vim in a braced language and have it dedent, if I want to write more code in Python that's outside the block, I just press the backspace key and it removes an entire level of indentation. And then I start typing that code, and I don't have to input a newline because I'm already on the line where I want the code to be, because I'm not expected to have a } on a separate line from everything else.
> Sorry, I don't follow. There's nothing preventing a tool from re-indenting code when it's pasted (i.e.: considering indentation within the pasted text relative to its first line, and then applying an indentation offset according to where it's pasted), and many already do. It's the same kind of logic that's used to auto-format code in braced languages; arguably simpler unless it's also validating the existing indentation of the pasted text.
I have not had this work reliably for me - my relatively stock VSCode does not indent the pasted code correctly - but I will freely admit that it could, and that this is a point in favour of good tooling.
> And actually, who even is relying on "autoformatters that run on save"? I want the code to look right as I'm writing it, not after. The tools you describe are, to me, about maintaining project standards when multiple people are involved, but fundamentally each person is still making the code look locally, personally right before saving (or committing, since these things are also often done with pre-commit hooks). I can't imagine just typing out whatever slop is syntactically correct and waiting to save the file to fix it. Not when I have a proper text editor that facilitates typing it out the way I want it, taking advantage of awareness of the language syntax.
Most people who write code in these languages rely on them! Format-on-save is one of the first things one sets up in an ecosystem with high-quality formatters. You can write code that is sloppily formatted but conveys your intent, then save and have it auto-format. It completely reformats formatting as a concern. As they say in Go land: "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
> Languages do not and cannot format code. Text editors (including the ones built into IDEs) do. If I type a } and the text changes position, it's not the programming language that did this.
These languages ship with first-class robust and performant formatters that encode the language's preferred style; much effort has gone into developing these formatters [0]. For all intents and purposes, they are part of the language, and users of these languages will be expected to use them.
> And this is also not better in braced languages. Just as I can input a } on a new line in Vim in a braced language and have it dedent, if I want to write more code in Python that's outside the block, I just press the backspace key and it removes an entire level of indentation. And then I start typing that code, and I don't have to input a newline because I'm already on the line where I want the code to be, because I'm not expected to have a } on a separate line from everything else.
I just don't think about it. I write my code in whatever way is easiest to type - including letting the editor auto-insert closing braces - and then hit save to format.
In general, you are freed from formatting as a matter of concern. It's just not something you have to think about, and that's liberating in its own way; it makes bashing some code out, or pasting some code in, trivial.
> Most people who write code in these languages rely on them!
I find that a little hard to believe. There is a universe of programmers out there who are basically invisible to you.
> I just don't think about it. I write my code in whatever way is easiest to type - including letting the editor auto-insert closing braces - and then hit save to format.
Don't you want to see neatly formatted code while you're writing it?
For Go, they have a statistic from a few years back that suggests about 98% of a cross section of real-world Go projects are formatted according to gofmt. (https://jmoiron.net/blog/fmty-dmpty) I can believe Rustfmt and other tools not having quite the same reach, but I would guess that the proportion is still pretty high.
These tools are very standard and very widely used.
> Don't you want to see neatly formatted code while you're writing it?
Every time I pause, I press ctrl-S or an equivalent. So I really am seeing neatly formatted code while I'm writing it. I would guess that 90% of the time, if my code is syntactically valid, it's also neatly formatted. And even if it's not valid code, it's probably very close to being neatly formatted.
Sorry, I don't follow. There's nothing preventing a tool from re-indenting code when it's pasted (i.e.: considering indentation within the pasted text relative to its first line, and then applying an indentation offset according to where it's pasted), and many already do. It's the same kind of logic that's used to auto-format code in braced languages; arguably simpler unless it's also validating the existing indentation of the pasted text.
And actually, who even is relying on "autoformatters that run on save"? I want the code to look right as I'm writing it, not after. The tools you describe are, to me, about maintaining project standards when multiple people are involved, but fundamentally each person is still making the code look locally, personally right before saving (or committing, since these things are also often done with pre-commit hooks). I can't imagine just typing out whatever slop is syntactically correct and waiting to save the file to fix it. Not when I have a proper text editor that facilitates typing it out the way I want it, taking advantage of awareness of the language syntax.
> none of the new languages that have seen success in the last ten years (Go, Rust, Swift, Dart, Kotlin) rely on the author to format code correctly - instead, they do it for you.
Languages do not and cannot format code. Text editors (including the ones built into IDEs) do. If I type a } and the text changes position, it's not the programming language that did this.
And this is also not better in braced languages. Just as I can input a } on a new line in Vim in a braced language and have it dedent, if I want to write more code in Python that's outside the block, I just press the backspace key and it removes an entire level of indentation. And then I start typing that code, and I don't have to input a newline because I'm already on the line where I want the code to be, because I'm not expected to have a } on a separate line from everything else.