5 ms·

Yeah, whitespace sensitive languages are a great idea... Until you permanently lose user data because of a pull request that contained whitespace changes. Yes

by kod 9y ago

Yeah, whitespace sensitive languages are a great idea... Until you permanently lose user data because of a pull request that contained whitespace changes. Yes, I've seen this happen in production, yes it could have been prevented in other ways... but why invite disasters like that upon yourself?

mulmen 9y ago
Is that a problem with whitespace or your test/qa/release process? A curly brace language isn't any less likely to lose user data to a bug just because it has curly braces.
- kod 9y ago
  It is less likely to cause problems, because a removed curly brace won't parse correctly, and won't be hidden when someone excludes whitesoace from a diff.
  - pharrington 9y ago
    Your -if- clause sans curly braces definitely still parses.
    - jjnoakes 9y ago
      Depends on the language.
      - lgas 9y ago
        Technically true, but I mean c'mon... Java, JavaScript, C, C++, C#, PHP... You have to get down to into the Go/Swift neighborhood before you'll find mandatory braces.
  - JadeNB 9y ago
    > won't be hidden when someone excludes whitesoace from a diff. Surely it is good advice not to exclude whitespace from a diff when using a whitespace-sensitive language?
breck 9y ago
This is a great concern, and glad you brought it up. In ETNs (the new family of programming languages I'm talking about), there are no "whitespace changes", in the sense that all changes to the code affect actual nodes in the program. This is a really important property that embeds diffs with a whole lot more meaning. You can not only see the number of lines changed, but also the number of nodes changed. If you expected a change to only change content and not change any nodes, and you saw in a negative number in the nodes changed field, you would know immediately that something had gone wrong. This is one of the many new beneficial properties unique to these languages.
- kod 9y ago
  Unless your language is somehow changing the behavior of existing tools like diff -w or github ?w=1, you're just making semantic distinctions.
  - breck 9y ago
    Correct. We have new diff tools specifically for ETNs.
    - gnaritas 9y ago
      No, that's not changing the behavior of the existing tools everyone uses and aren't going to stop using. You can't say correct when you're not actually agreeing with his point.
      - breck 9y ago
        Perhaps I misunderstood the parent comment. It changes the behavior in the sense that there is no w=1 option. All whitespace is significant. The idea of ignoring whitespace would be like the idea of ignoring angle brackets in html. Whitespace is an essential part of TN and ETNs and is never ignored. Diff tools then can benefit by showing not only aggregate line diffs but aggregate node and word level diffs without knowing anything about the meaning of a program.
simonh 9y ago
Have you really never seen a bug in curly brace code due to a misplaced curly bracket hidden by incorrect indenting? Or code that was just really difficult to understand and modify accurately because it was indented inconsistently with the braces? And yes there are tools that can help with that, but... I worked on Quartz for a few tears, that's over 10 million lines of Python code and many thousands of commits per day. If concerns like that really were anything more than nitpicking, projects like that would know about it.
- kod 9y ago
  The point is with lisp you can automatically and unambiguously parse and format code regardless of whitespace. Giving that up in favor of whitespace sensitive languages has real world drawbacks, no matter how many "no true python programmer" arguments you make.
- kazinator 9y ago
  Discrepancy between actual code structure and indentation is susceptible to diagnosis by machine. That's the beauty of having a bit of redundancy in the representation. Recent GCC now has a warning for indentation that doesn't match code structure. (Had to recently patch a breakage in GNU Binutils in an embedded distro due to this being a -Werror).
- JadeNB 9y ago
  > I worked on Quartz for a few tears This lovely typo deserves to be noticed.
olavk 9y ago
Well, if you randomly delete parentheses in Lisp or curly braces in C you will also get problems. So...don't delete information at random.

by kod 9y ago

mulmen 9y ago

Is that a problem with whitespace or your test/qa/release process? A curly brace language isn't any less likely to lose user data to a bug just because it has curly braces.

kod 9y ago
It is less likely to cause problems, because a removed curly brace won't parse correctly, and won't be hidden when someone excludes whitesoace from a diff.
- pharrington 9y ago
  Your -if- clause sans curly braces definitely still parses.
  - jjnoakes 9y ago
    Depends on the language.
    - lgas 9y ago
      Technically true, but I mean c'mon... Java, JavaScript, C, C++, C#, PHP... You have to get down to into the Go/Swift neighborhood before you'll find mandatory braces.
- JadeNB 9y ago
  > won't be hidden when someone excludes whitesoace from a diff. Surely it is good advice not to exclude whitespace from a diff when using a whitespace-sensitive language?

breck 9y ago

This is a great concern, and glad you brought it up. In ETNs (the new family of programming languages I'm talking about), there are no "whitespace changes", in the sense that all changes to the code affect actual nodes in the program. This is a really important property that embeds diffs with a whole lot more meaning. You can not only see the number of lines changed, but also the number of nodes changed. If you expected a change to only change content and not change any nodes, and you saw in a negative number in the nodes changed field, you would know immediately that something had gone wrong. This is one of the many new beneficial properties unique to these languages.

kod 9y ago
Unless your language is somehow changing the behavior of existing tools like diff -w or github ?w=1, you're just making semantic distinctions.
- breck 9y ago
  Correct. We have new diff tools specifically for ETNs.
  - gnaritas 9y ago
    No, that's not changing the behavior of the existing tools everyone uses and aren't going to stop using. You can't say correct when you're not actually agreeing with his point.
    - breck 9y ago
      Perhaps I misunderstood the parent comment. It changes the behavior in the sense that there is no w=1 option. All whitespace is significant. The idea of ignoring whitespace would be like the idea of ignoring angle brackets in html. Whitespace is an essential part of TN and ETNs and is never ignored. Diff tools then can benefit by showing not only aggregate line diffs but aggregate node and word level diffs without knowing anything about the meaning of a program.

simonh 9y ago

Have you really never seen a bug in curly brace code due to a misplaced curly bracket hidden by incorrect indenting? Or code that was just really difficult to understand and modify accurately because it was indented inconsistently with the braces? And yes there are tools that can help with that, but... I worked on Quartz for a few tears, that's over 10 million lines of Python code and many thousands of commits per day. If concerns like that really were anything more than nitpicking, projects like that would know about it.

kod 9y ago
The point is with lisp you can automatically and unambiguously parse and format code regardless of whitespace. Giving that up in favor of whitespace sensitive languages has real world drawbacks, no matter how many "no true python programmer" arguments you make.
kazinator 9y ago
Discrepancy between actual code structure and indentation is susceptible to diagnosis by machine. That's the beauty of having a bit of redundancy in the representation. Recent GCC now has a warning for indentation that doesn't match code structure. (Had to recently patch a breakage in GNU Binutils in an embedded distro due to this being a -Werror).
JadeNB 9y ago
> I worked on Quartz for a few tears This lovely typo deserves to be noticed.

olavk 9y ago

Well, if you randomly delete parentheses in Lisp or curly braces in C you will also get problems. So...don't delete information at random.