6 ms·

I have decided that meaningful whitespace is an anachronism. 20 years ago, I liked it a lot. Today, after the invention and normalization of opinionated autof

I have decided that meaningful whitespace is an anachronism. 20 years ago, I liked it a lot. Today, after the invention and normalization of opinionated autoformatters, it means that the autoformatter can't figure out for me how my code should be indented. Which means that, assuming I am using an autoformatter, it creates one more thing that I have to do manually, because the editor can't accurately do it for me. And, since the whitespace is significant, it ends up being one more potential source of bugs. I also don't love love love that (at least with the keys I know well) significant whitespace is more awkward to edit with vanilla vim than curly braces and parens are.

boardwaalk 5y ago
Some counterpoints: Your auto formatter can’t figure out where you missed braces either. Missing brackets in languages where they are optional for single statements (C) has been a source of serious bugs. Also, in Vim, indenting/dedenting a block is just highlighting the lines and using > or <.
- GoblinSlayer 5y ago
  A botched merge conflict resolution can repeat a block statement just fine, it will have the same effect. And repeating a statement inside a block isn't necessarily better.
- bobbylarrybobby 5y ago
  Practically speaking, it’s almost impossible to miss braces. If you’re copying and pasting, you can place your cursor anywhere inside the desired pair of braces, paste, and the autoformatter will figure it out. Ideally an autoformatter would also add braces around a one-line if statement as well.
  - je42 5y ago
    it is very possible... I often paste parts of some code into a lambda and missing a brace here and there.
- ImprobableTruth 5y ago
  >Your auto formatter can’t figure out where you missed braces either. I mean, it kinda does? You get a result that's wrongly indented if you miss a brace.
  - aEverr 5y ago
    well yeah, then what? where would the missing brace be? you can't really tell since now the formatter clobbered your indentation, unless you remember, of course
    - fanf2 5y ago
      When this happens to me with `cargo fmt` I don’t need to remember, I can just revert the formatting changes using undo in Emacs.
- mumblemumble 5y ago
  > Missing brackets in languages where they are optional for single statements (C) has been a source of serious bugs. This is why, in languages where they are optional, a good autoformatter will automatically insert them. If you've got it set to run every time you save the file or run tests, it's likely to do so long before you have a chance to produce the next Heartbleed. It's not perfect, of course, but it's as good a protection against this sort of thing as I've ever seen. > Also, in Vim, indenting/dedenting a block is just highlighting the lines and using > or <. But, excluding plugins (which aren't available/consistent across all the editors where I use a vim editing mode), I don't know of a quick vim command that lets me quickly select, delete, replace, yank, or change the full contents of a scope in a whitespace-sensitive language. Or quickly jump to the beginning or end of the current scope. Stuff like that. Versus, with curly brace languages, vanilla vim gives me an experience that approaches the ease of paredit.
  - hadem 5y ago
    > I don't know of a quick vim command that lets me quickly select, delete, replace, yank, or change the full contents of a scope in a whitespace-sensitive language. I'm sure there are better ways, but you could v9G$ to select from the current line to the end of line nine. Or v9j select the next nine lines, v9k previous nine, etc.
    - mumblemumble 5y ago
      But compare the ergonomics of: 1. yi{ To: 1. Find line number of start of scope. 2. Decide on easiest way to get there, and either: - kk - 5k - 37G 3. Find the end of the scope. 4. Decide how to grab it. Then: - y9G$ - y3j - V, jjj, y I hope maybe I've made my case that it's more awkward, right? That is not to say that I don't know how to do it. It's just that, in the one case, I can do the job in one thoughtless action that lives so deeply in my muscle memory that I barely even consciously remember what the actual keystrokes involved are. By contrast, in the other, it takes several steps, some of which are likely to be small pauses to decide how to do the next step.
      - 5y ago
- TheCoelacanth 5y ago
  > Your auto formatter can’t figure out where you missed braces either. Correct, but I will notice the braces are wrong when the auto-formatter indents things differently than I expect.
  - xigoi 5y ago
    And I'll notice the indentation is wrong when the indentation is different than I expect.
- secondcoming 5y ago
  How does significant whitespace save you from bugs? if expr: doA() doB() Is doB at the correct level? Having text that's invisible change the flow of your program is crazy IMO.
  - feffe 5y ago
    I don't care that much in my own side projects but when working with others and resolving merge conflicts your example is my nightmare. It's so much easier to have brackets denote scope as you don't have to get the indentation right when actually resolving merge conflicts. It's easy to fix it up afterwards by automatic indentation in the editor. Significant white space is a mistake IMHO :-)
  - akubera 5y ago
    The bugs being referred to are from optional brackets in C: void foo() { ... if (expr) doA(); doB(); ... } which is unambiguous to the compiler, but could (and I expect would, especially when glancing through a lot of code) cause misinterpretation by a human reader. We can more easily hallucinate the brackets than the indentation. I disagree with the idea that indentation spaces are invisible; rather they are much more visible than a pair of brackets. This actually becomes a problem when you embed/indent too much and 70% of the line is spaces. It's all you see!
    - secondcoming 5y ago
      Yes, but pretty much every coding standard I've seen mandates the use of braces always. You do it without even thinking. Your example wouldn't pass code review.
  - xigoi 5y ago
    if (expr) { doA() doB() } Is doB at the correct level? It's the same thing.
otherme123 5y ago
I get what you say, and agree with you that autoformatter+braces are a cool thing. Problem with that is a lot of people don't use any formatter: not an autoformatter, not a format guide. They just "know" what is best, which usually end up in horrifying (R in my field) code. Sometimes they even feel _smart_ when chaining call after call after call to pull off some kind of one-liner with the help of braces, pipes and semicolons, and then twit the monstrosity with great pride. Python, and others, had the wisdom to put a corset on those people with whitespace and indentation.
ASalazarMX 5y ago
> Today, after the invention and normalization of opinionated autoformatters, it means that the autoformatter can't figure out for me how my code should be indented This is precisely why I prefer significant space: it forces you to write tidy code. Sloppily written code that depends on the autoformatter to be properly indented makes me suspect the logic could be sloppily written too. Besides, any humble plain text editor understands autoindenting, so there's no sensible reason to not indent properly.
rapind 5y ago
I don't personally run into either of these issues at all working with Elm code (significant whitespace language) in vim. Having your indentation wrong is basically the same as ending your parens in the wrong place isn't it? Not sure an autoformatter can fix it if you throw a close bracket in before you should? For formatting, elm-format is opinionated (I don't love the 4 space indentation though) and pretty much everyone uses it. No issues with indentation that I can recall. Not sure if nim has it's own formatter (I haven't played w/ nim in a few years), but I believe python does? The biggest win of significant whitespace to me is readability. Subjective of course, but I just find it easier to read and less noisy than C / JS syntax. Probably about the same effort to write. I also like bracket soup lisp languages though (w/ rainbow parens) so maybe I'm just weird. /shrug
hajile 5y ago
If I don't add a brace, I'll get an immediate error that something doesn't add up. If I mess up indentation, the program will carry on as if nothing had happened.
- b3morales 5y ago
  This is not really true in practice. It is the same thing as accidentally moving a line across a brace in a brace-delimited language. The incorrectly-indented line will generally blow up at runtime or fail to compile, because it's in the wrong scope.
- xigoi 5y ago
  If you misplace a brace (which is the true equivalent of messing up indentation), the program will also carry on.
dbrueck 5y ago
Definitely some subjectivity to this question, but I'm the opposite: to me the curly braces are the anachronism, a relic of a time when the programmer had to do lots of extra stuff to help the language parser/compiler. For awhile it was awkward because it was up to the programmer to keep the redundant block delimiters in sync - the braces (for the computer) and the whitespace (for the human). The fact that modern editors and IDEs for those languages now do the housekeeping on behalf of the human is great, but it seems odd that it's needed at all, and it always feels especially cumbersome when returning to those languages that still require it if I've been away for awhile.

boardwaalk 5y ago

Some counterpoints: Your auto formatter can’t figure out where you missed braces either. Missing brackets in languages where they are optional for single statements (C) has been a source of serious bugs. Also, in Vim, indenting/dedenting a block is just highlighting the lines and using > or <.

GoblinSlayer 5y ago
A botched merge conflict resolution can repeat a block statement just fine, it will have the same effect. And repeating a statement inside a block isn't necessarily better.
bobbylarrybobby 5y ago
Practically speaking, it’s almost impossible to miss braces. If you’re copying and pasting, you can place your cursor anywhere inside the desired pair of braces, paste, and the autoformatter will figure it out. Ideally an autoformatter would also add braces around a one-line if statement as well.
- je42 5y ago
  it is very possible... I often paste parts of some code into a lambda and missing a brace here and there.
ImprobableTruth 5y ago
>Your auto formatter can’t figure out where you missed braces either. I mean, it kinda does? You get a result that's wrongly indented if you miss a brace.
- aEverr 5y ago
  well yeah, then what? where would the missing brace be? you can't really tell since now the formatter clobbered your indentation, unless you remember, of course
  - fanf2 5y ago
    When this happens to me with `cargo fmt` I don’t need to remember, I can just revert the formatting changes using undo in Emacs.
mumblemumble 5y ago
> Missing brackets in languages where they are optional for single statements (C) has been a source of serious bugs. This is why, in languages where they are optional, a good autoformatter will automatically insert them. If you've got it set to run every time you save the file or run tests, it's likely to do so long before you have a chance to produce the next Heartbleed. It's not perfect, of course, but it's as good a protection against this sort of thing as I've ever seen. > Also, in Vim, indenting/dedenting a block is just highlighting the lines and using > or <. But, excluding plugins (which aren't available/consistent across all the editors where I use a vim editing mode), I don't know of a quick vim command that lets me quickly select, delete, replace, yank, or change the full contents of a scope in a whitespace-sensitive language. Or quickly jump to the beginning or end of the current scope. Stuff like that. Versus, with curly brace languages, vanilla vim gives me an experience that approaches the ease of paredit.
- hadem 5y ago
  > I don't know of a quick vim command that lets me quickly select, delete, replace, yank, or change the full contents of a scope in a whitespace-sensitive language. I'm sure there are better ways, but you could v9G$ to select from the current line to the end of line nine. Or v9j select the next nine lines, v9k previous nine, etc.
  - mumblemumble 5y ago
    But compare the ergonomics of: 1. yi{ To: 1. Find line number of start of scope. 2. Decide on easiest way to get there, and either: - kk - 5k - 37G 3. Find the end of the scope. 4. Decide how to grab it. Then: - y9G$ - y3j - V, jjj, y I hope maybe I've made my case that it's more awkward, right? That is not to say that I don't know how to do it. It's just that, in the one case, I can do the job in one thoughtless action that lives so deeply in my muscle memory that I barely even consciously remember what the actual keystrokes involved are. By contrast, in the other, it takes several steps, some of which are likely to be small pauses to decide how to do the next step.
    - 5y ago
TheCoelacanth 5y ago
> Your auto formatter can’t figure out where you missed braces either. Correct, but I will notice the braces are wrong when the auto-formatter indents things differently than I expect.
- xigoi 5y ago
  And I'll notice the indentation is wrong when the indentation is different than I expect.
secondcoming 5y ago
How does significant whitespace save you from bugs? if expr: doA() doB() Is doB at the correct level? Having text that's invisible change the flow of your program is crazy IMO.
- feffe 5y ago
  I don't care that much in my own side projects but when working with others and resolving merge conflicts your example is my nightmare. It's so much easier to have brackets denote scope as you don't have to get the indentation right when actually resolving merge conflicts. It's easy to fix it up afterwards by automatic indentation in the editor. Significant white space is a mistake IMHO :-)
- akubera 5y ago
  The bugs being referred to are from optional brackets in C: void foo() { ... if (expr) doA(); doB(); ... } which is unambiguous to the compiler, but could (and I expect would, especially when glancing through a lot of code) cause misinterpretation by a human reader. We can more easily hallucinate the brackets than the indentation. I disagree with the idea that indentation spaces are invisible; rather they are much more visible than a pair of brackets. This actually becomes a problem when you embed/indent too much and 70% of the line is spaces. It's all you see!
  - secondcoming 5y ago
    Yes, but pretty much every coding standard I've seen mandates the use of braces always. You do it without even thinking. Your example wouldn't pass code review.
- xigoi 5y ago
  if (expr) { doA() doB() } Is doB at the correct level? It's the same thing.

otherme123 5y ago

I get what you say, and agree with you that autoformatter+braces are a cool thing. Problem with that is a lot of people don't use any formatter: not an autoformatter, not a format guide. They just "know" what is best, which usually end up in horrifying (R in my field) code. Sometimes they even feel _smart_ when chaining call after call after call to pull off some kind of one-liner with the help of braces, pipes and semicolons, and then twit the monstrosity with great pride. Python, and others, had the wisdom to put a corset on those people with whitespace and indentation.

ASalazarMX 5y ago

> Today, after the invention and normalization of opinionated autoformatters, it means that the autoformatter can't figure out for me how my code should be indented This is precisely why I prefer significant space: it forces you to write tidy code. Sloppily written code that depends on the autoformatter to be properly indented makes me suspect the logic could be sloppily written too. Besides, any humble plain text editor understands autoindenting, so there's no sensible reason to not indent properly.

rapind 5y ago

I don't personally run into either of these issues at all working with Elm code (significant whitespace language) in vim. Having your indentation wrong is basically the same as ending your parens in the wrong place isn't it? Not sure an autoformatter can fix it if you throw a close bracket in before you should? For formatting, elm-format is opinionated (I don't love the 4 space indentation though) and pretty much everyone uses it. No issues with indentation that I can recall. Not sure if nim has it's own formatter (I haven't played w/ nim in a few years), but I believe python does? The biggest win of significant whitespace to me is readability. Subjective of course, but I just find it easier to read and less noisy than C / JS syntax. Probably about the same effort to write. I also like bracket soup lisp languages though (w/ rainbow parens) so maybe I'm just weird. /shrug

hajile 5y ago

If I don't add a brace, I'll get an immediate error that something doesn't add up. If I mess up indentation, the program will carry on as if nothing had happened.

b3morales 5y ago
This is not really true in practice. It is the same thing as accidentally moving a line across a brace in a brace-delimited language. The incorrectly-indented line will generally blow up at runtime or fail to compile, because it's in the wrong scope.
xigoi 5y ago
If you misplace a brace (which is the true equivalent of messing up indentation), the program will also carry on.

dbrueck 5y ago

Definitely some subjectivity to this question, but I'm the opposite: to me the curly braces are the anachronism, a relic of a time when the programmer had to do lots of extra stuff to help the language parser/compiler. For awhile it was awkward because it was up to the programmer to keep the redundant block delimiters in sync - the braces (for the computer) and the whitespace (for the human). The fact that modern editors and IDEs for those languages now do the housekeeping on behalf of the human is great, but it seems odd that it's needed at all, and it always feels especially cumbersome when returning to those languages that still require it if I've been away for awhile.