6 ms·

I’m the creator of syntax suggest, the syntax error detection library that ships with Ruby 3.2 I’ve switched my perspectives on whitespace significance. It mak

I’m the creator of syntax suggest, the syntax error detection library that ships with Ruby 3.2 I’ve switched my perspectives on whitespace significance. It makes for shorter source code but comes with a signal to noise problem. If there’s a mistake in the indentation it’s harder to determine intent. Versus if you expect well formatted and indented code (I love auto formatters like cargo fmt), and syntax to declare intent, then your tools can make better guesses and suggestions than if you only have one signal. The other problem I’ve found working with Python is I often want to copy code and paste into my REPL but it’s usually inside of another context so I get an indentation error. While I like significant whitespace, I LOVE tooling that understands my intent and helps me fix it. I’ll trade slightly more verbosity if it means better tooling. Though obviously I’m quite biased.

pilaf 4y ago
Thank you for your hard work making my favorite programming language even better. I completely agree with all your points on significant whitespace for programming languages. Where I think it makes a lot more sense though is for structured static data. My quality of live would be worsened without the likes of Haml, Sass and YAML.
- schneems 4y ago
  Thanks for the note! I enjoy using slim in my views though prefer scss to sass. I think for many of those tools either misindentations raise an error (like failing a yaml schema validation) or result in incorrect but observable behavior (content isn’t in a div as expected). It really comes down to how the tool is supposed to be used and how failures are handled. In general I think that’s the difference between a good experience and a great one: when we can have beautiful failures that help us learn.
- still_grokking 4y ago
  > I completely agree with all your points on significant whitespace for programming languages. Where I think it makes a lot more sense though is for structured static data. This makes no sense. If the arguments against significant whitespace are valid for executable code they're also valid for markup. If it's fine to use significant whitespace for markup / data literals even the perceived drawbacks apply than it would be equally fine for executable code.
  - pilaf 4y ago
    You've got a point. I was mostly thinking about the "copy-pasting into the REPL" argument, which is a problem unique to executable code, at least in my experience.
wink 4y ago
Interestingly my main quality of life improvement when writing Rust is being able to leave the brackets around the test in an if statement empty (vs C/C++/PHP_), I don't care about the square brackets for the body as much.
- schneems 4y ago
  In Rust it’s clear when the logic of the “if” is over because it’s always followed by a curly and it’s pretty easy to detect if you missed the curly. Im not saying that more syntax is always better, but sometimes that extra bit that seems needless is helpful to clarify to the program “yep I meant what I wrote”
still_grokking 4y ago
This is imho a pure tooling problem. We still use a loosely representation (text) for a semantically very rich data format (code). When you look at this objectively that's madness. We should finally use proper editors for our semantically rich data format instead of "dumb" text editors. (Which are by now actually not so dumb, and which do again completely crazy things to re-extract the semantic information from a representation that inherently erased this information while we're used a loosely text representation). We should imho eventually switch to "binary source code" and start using proper tools to edit this data. What we do currently is like editing Excel sheets in a hex editor… Binary source code (or at least something in the ballpark of XML tech) would also solve a lot of other problems: For example the rendering of the data on screen would be independent form the actual data on disc. This means bitching around "code style" and even partly syntax could finally end. The stuff on screen could be rendered with the help of some "style sheets". Everybody would get the preferred look & feel for their code. (We do this already partly with syntax highlighting; we "just" need to extend this concept). Also things like version control, dependencies, and such, could be build in. Proper indices for searching (and refactoring code) could be also added (things that our editors today compute anyway, but in some ad hoc and very language specific way). Compilation of such code would be faster as all the parsing wouldn't be needed (as it would happen already in the editor; actually, also what is already done today, only that we than again throw away this information for no reason, so the compiler "may" regenerate it over and over on every run, instead that this stuff ends up in a kind of database which could be even part of the "binary source code" format). I guess some innovative editor features nobody even considered until now would be also enable this way. It's time for progress! (Most likely, as almost always, someone will come up with some references to very old systems that did already this because they were ahead of their time; let's see what new stuff I'm going to learn this time :-D).
- carapace 4y ago
  > references to very old systems that did already this Here's one: Alice Pascal > In a syntax directed editor, you edit a program, not a piece of text. The editor works directly on the program as a tree -- matching the syntax trees by which the language is structured. The units you work with are not lines and characters but terms, expressions, statements and blocks. https://www.templetons.com/brad/alice.html https://www.templetons.com/brad/alice.html
bmitc 4y ago
> If there’s a mistake in the indentation it’s harder to determine intent. If there's an indentation mistake in an indentation sensitive language, then there's a mistake. Why does intent matter? Intent is lost because there is a mistake.
- schneems 4y ago
  Write a program to show me where that mistake was made. > Intent is lost because there is a mistake. The signal is reduced but not gone. In a language like Ruby I can tell you plus or minus a few lines exactly where the problem is.

pilaf 4y ago

Thank you for your hard work making my favorite programming language even better. I completely agree with all your points on significant whitespace for programming languages. Where I think it makes a lot more sense though is for structured static data. My quality of live would be worsened without the likes of Haml, Sass and YAML.

schneems 4y ago
Thanks for the note! I enjoy using slim in my views though prefer scss to sass. I think for many of those tools either misindentations raise an error (like failing a yaml schema validation) or result in incorrect but observable behavior (content isn’t in a div as expected). It really comes down to how the tool is supposed to be used and how failures are handled. In general I think that’s the difference between a good experience and a great one: when we can have beautiful failures that help us learn.
still_grokking 4y ago
> I completely agree with all your points on significant whitespace for programming languages. Where I think it makes a lot more sense though is for structured static data. This makes no sense. If the arguments against significant whitespace are valid for executable code they're also valid for markup. If it's fine to use significant whitespace for markup / data literals even the perceived drawbacks apply than it would be equally fine for executable code.
- pilaf 4y ago
  You've got a point. I was mostly thinking about the "copy-pasting into the REPL" argument, which is a problem unique to executable code, at least in my experience.

wink 4y ago

Interestingly my main quality of life improvement when writing Rust is being able to leave the brackets around the test in an if statement empty (vs C/C++/PHP_), I don't care about the square brackets for the body as much.

schneems 4y ago
In Rust it’s clear when the logic of the “if” is over because it’s always followed by a curly and it’s pretty easy to detect if you missed the curly. Im not saying that more syntax is always better, but sometimes that extra bit that seems needless is helpful to clarify to the program “yep I meant what I wrote”

still_grokking 4y ago

This is imho a pure tooling problem. We still use a loosely representation (text) for a semantically very rich data format (code). When you look at this objectively that's madness. We should finally use proper editors for our semantically rich data format instead of "dumb" text editors. (Which are by now actually not so dumb, and which do again completely crazy things to re-extract the semantic information from a representation that inherently erased this information while we're used a loosely text representation). We should imho eventually switch to "binary source code" and start using proper tools to edit this data. What we do currently is like editing Excel sheets in a hex editor… Binary source code (or at least something in the ballpark of XML tech) would also solve a lot of other problems: For example the rendering of the data on screen would be independent form the actual data on disc. This means bitching around "code style" and even partly syntax could finally end. The stuff on screen could be rendered with the help of some "style sheets". Everybody would get the preferred look & feel for their code. (We do this already partly with syntax highlighting; we "just" need to extend this concept). Also things like version control, dependencies, and such, could be build in. Proper indices for searching (and refactoring code) could be also added (things that our editors today compute anyway, but in some ad hoc and very language specific way). Compilation of such code would be faster as all the parsing wouldn't be needed (as it would happen already in the editor; actually, also what is already done today, only that we than again throw away this information for no reason, so the compiler "may" regenerate it over and over on every run, instead that this stuff ends up in a kind of database which could be even part of the "binary source code" format). I guess some innovative editor features nobody even considered until now would be also enable this way. It's time for progress! (Most likely, as almost always, someone will come up with some references to very old systems that did already this because they were ahead of their time; let's see what new stuff I'm going to learn this time :-D).

carapace 4y ago
> references to very old systems that did already this Here's one: Alice Pascal > In a syntax directed editor, you edit a program, not a piece of text. The editor works directly on the program as a tree -- matching the syntax trees by which the language is structured. The units you work with are not lines and characters but terms, expressions, statements and blocks. https://www.templetons.com/brad/alice.html https://www.templetons.com/brad/alice.html

bmitc 4y ago

> If there’s a mistake in the indentation it’s harder to determine intent. If there's an indentation mistake in an indentation sensitive language, then there's a mistake. Why does intent matter? Intent is lost because there is a mistake.

schneems 4y ago
Write a program to show me where that mistake was made. > Intent is lost because there is a mistake. The signal is reduced but not gone. In a language like Ruby I can tell you plus or minus a few lines exactly where the problem is.