4 ms·

Seeing as the vast majority of statements while coding aren't multiline, I wish there was a symbol to indicate that instead of a symbol to represent the end of

Seeing as the vast majority of statements while coding aren't multiline, I wish there was a symbol to indicate that instead of a symbol to represent the end of a single line statement. I think Python has things right with the significant whitespace as well as it seriously reduces annoying errors caused by misbalanced brackets/braces. Going further with this, I wish languages would be more copy/paste friendly. For example, in JavaScript I'll sometimes change code along the lines of a.x = 1; a.y = 2; to a = { x: 1, y: 2 };" If you eliminate the commas, semicolons and changed the colons/equals to the same thing, you could copy/paste it with much less hassle.

Terr_ 9y ago
> Seeing as the vast majority of statements while coding aren't multiline, I wish there was a symbol to indicate that I dunno, that kind of exists in some bash/scripting contexts (using a backslash) and I've never enjoyed it.
- seanwilson 9y ago
  Bash has horrific syntax but a huge amount of coding time is wasted because of unbalanced brackets/braces and forgotten end of line statements that result in unhelpful and confusing error messages so I like things that reduce this. Bash also has the quirk where variable assignments are of the form "var=1" but their usage is "$var" which always trips me up. I just like syntax that is easy to get right first time and is copy/paste friendly.
yorwba 9y ago
I vaguely recall some PL research that used the dot as a scoping operator, you could write object.(expression) and all fields of the object were automatically in scope within the expression. Your example would look like a.( x = 1; y = 2; )
coldtea 9y ago
>I think Python has things right with the significant whitespace as well as it seriously reduces annoying errors caused by misbalanced brackets/braces. You still get errors caused by mis-indented statements which are almost just as hard to check (if the indent continues for 10-15 lines and is nested etc). And because of allowing to mix tabs and spaces, you also get other issues. I think go had the best idea in this with gofmt: all code should be auto-formatted absolutely the same -- then it becomes trivial to read.
- seanwilson 9y ago
  > You still get errors caused by mis-indented statements which are almost just as hard to check (if the indent continues for 10-15 lines and is nested etc). I find wrong indents miles easier to see than unbalanced brackets/braces though. A single bracket/brace is only one symbol so it's hard to spot but it completely changes the semantics (see Apple's goto fail error). > I think go had the best idea in this with gofmt: all code should be auto-formatted absolutely the same -- then it becomes trivial to read. Yes, I like this. There's so many pointless arguments about things to do with naming conventions and tabs vs spaces...just make it part of the language so people can argue about more important topics.
  - krapp 9y ago
    goto fail was caused by a failure to use braces at all - ironically, it seems, for the same aesthetic reasons that significant whitespace is used, because it seems "cleaner." Had braces been used, the error might have been easier to spot or might not have happened at all.
    - seanwilson 9y ago
      Significant whitespace forces the look of the code and the meaning of the code together to prevent mistakes like that though. It's really silly that indenting code within a condition is a universal code formatting convention but it's not enforced by the compiler. I can't think of any exceptions where you wouldn't want to indent code like that and it's obvious badly indented code can be misleading so I don't see why a compiler shouldn't pick that up for you.
      - krapp 9y ago
        The conventions around whitespace and code formatting are not universal, and the problem is once the compiler has to care about whitespace, it's no longer whitespace, it's code. Code has to be correct in ways whitespace doesn't. Some people use tabs, some people use spaces. Some people even use both. In terms of whitespace, it doesn't really matter. But, if your language cares which of the visually indistinguishable but otherwise incompatible kinds of non-printing characters you're formatting your code with, then it can still fail while visually communicating the correct information to the reader.

Terr_ 9y ago

> Seeing as the vast majority of statements while coding aren't multiline, I wish there was a symbol to indicate that I dunno, that kind of exists in some bash/scripting contexts (using a backslash) and I've never enjoyed it.

seanwilson 9y ago
Bash has horrific syntax but a huge amount of coding time is wasted because of unbalanced brackets/braces and forgotten end of line statements that result in unhelpful and confusing error messages so I like things that reduce this. Bash also has the quirk where variable assignments are of the form "var=1" but their usage is "$var" which always trips me up. I just like syntax that is easy to get right first time and is copy/paste friendly.

yorwba 9y ago

I vaguely recall some PL research that used the dot as a scoping operator, you could write object.(expression) and all fields of the object were automatically in scope within the expression. Your example would look like a.( x = 1; y = 2; )

coldtea 9y ago

>I think Python has things right with the significant whitespace as well as it seriously reduces annoying errors caused by misbalanced brackets/braces. You still get errors caused by mis-indented statements which are almost just as hard to check (if the indent continues for 10-15 lines and is nested etc). And because of allowing to mix tabs and spaces, you also get other issues. I think go had the best idea in this with gofmt: all code should be auto-formatted absolutely the same -- then it becomes trivial to read.

seanwilson 9y ago
> You still get errors caused by mis-indented statements which are almost just as hard to check (if the indent continues for 10-15 lines and is nested etc). I find wrong indents miles easier to see than unbalanced brackets/braces though. A single bracket/brace is only one symbol so it's hard to spot but it completely changes the semantics (see Apple's goto fail error). > I think go had the best idea in this with gofmt: all code should be auto-formatted absolutely the same -- then it becomes trivial to read. Yes, I like this. There's so many pointless arguments about things to do with naming conventions and tabs vs spaces...just make it part of the language so people can argue about more important topics.
- krapp 9y ago
  goto fail was caused by a failure to use braces at all - ironically, it seems, for the same aesthetic reasons that significant whitespace is used, because it seems "cleaner." Had braces been used, the error might have been easier to spot or might not have happened at all.
  - seanwilson 9y ago
    Significant whitespace forces the look of the code and the meaning of the code together to prevent mistakes like that though. It's really silly that indenting code within a condition is a universal code formatting convention but it's not enforced by the compiler. I can't think of any exceptions where you wouldn't want to indent code like that and it's obvious badly indented code can be misleading so I don't see why a compiler shouldn't pick that up for you.
    - krapp 9y ago
      The conventions around whitespace and code formatting are not universal, and the problem is once the compiler has to care about whitespace, it's no longer whitespace, it's code. Code has to be correct in ways whitespace doesn't. Some people use tabs, some people use spaces. Some people even use both. In terms of whitespace, it doesn't really matter. But, if your language cares which of the visually indistinguishable but otherwise incompatible kinds of non-printing characters you're formatting your code with, then it can still fail while visually communicating the correct information to the reader.