6 ms·

The things I hate most about CoffeeScript are the dash rockets and white-space significance. These are just opinions though. There are things I like about CS as

The things I hate most about CoffeeScript are the dash rockets and white-space significance. These are just opinions though. There are things I like about CS as well, like destructuring assignment and splats. Sometimes when I'm writing JS, I miss is, unless, etc... That said, I'd put my money on ES6 in the long run, though it doesn't really matter. People should use whatever makes them (and their team) happy and productive.

tiglionabbit 12y ago
Significant indentation is a good thing. Haskell and Python do it too. It's much easier to read indentation than it is to match up pairs of brackets in your head. In other languages, if the indentation doesn't match the brackets, you'll naturally read the indentation first and get the wrong impression of what the code does. In those languages, the indentation is supposed to match the brackets anyway. Why be redundant like that?
- sangnoir 12y ago
  I like the indentation + braces redundancy because indentations are for humans, brackets are for the interpreter. Logic blocks are more explicit with brackets I encountered a non-obvious Python bug that was caused by mixed spaces-and-tabs: to my human eyes, the indentation looked fine - the same as previous line, but the interpreter saw a different level of indentation.
  - vertex-four 12y ago
    > I encountered a non-obvious Python bug that was caused by mixed spaces-and-tabs This is why PEP8 exists and people are supposed to follow it. Additionally, mixed spaces-and-tabs is a bug that causes poor readability - there's plenty of people who have their editors set to have tabstops as 2 or 3 spaces rather than 4, and your code will look wrong in their editors. If you think there's any issues with mixed tabs and spaces in your codebase, Python provides a tool to find out - tabnanny. Additionally, any context-aware code editor will display a warning. (If you're using Sublime Text, the plugin to use is SublimeLinter - I assume there's similar tools for vim and emacs.) You can even set spaces and tabs to display differently in many editors!
    - tiglionabbit 12y ago
      Just installed SublimeLinter. Thanks! It puts some icons in the margins, but I can't figure out how to get an explanation of those icons. I see a bunch of !s next to my import statements.
  - nothrabannosir 12y ago
    True, agreed. Python has the -tt flag but, UI mistake, it should have been on by default. Or at least -t.
- tomp 12y ago
  It's not just significant indentation. CS parses "f + g" differently from "f +g" (the former is an addition, the latter is a function call with "+g" as the first argument).
  - tiglionabbit 12y ago
    Yeah, the unary operators can cause gotchas. Also, here's a gotcha I've run into where `a(b)` is considered different from `a (b)` x a(b), c # => x(a(b), c); x a (b), c # => x(a(b, c));
- greggman 12y ago
  I'm sure this has been argued to death but the counter argument is invisible formatting changing behavior is a bad thing. Sure if you get your entire team to use spaces or the same tabs great but passing open source code around to lots of programmers some of which use tabs and some of which use spaces ends up leading to wasted debugging time when someone used a tab where they should have used a space or visa versa. On top of that I find it invaluable to be able to space out debugging code. Example void SomeFunc() { int x = doSomething1(1, 2, 3, 4); int y = doSomething1(4, 5, 6, 8); int z = doSomething1(5, 6, 7, 9); printf("xyz=%d,%d,%d", x, y, z); int a = doSomething1(0, 2, 3, 4); int b = doSomething1(1, 5, 6, 8); int c = doSomething1(2, 6, 7, 9); printf("abc=%d,%d,%d", a, b, c); int d = doSomething1(6, 2, 3, 4); int e = doSomething1(5, 5, 6, 8); int f = doSomething1(7, 6, 7, 9); printf("def=%d,%d,%d", d, e, f); return x * y * z + a * b * c + d * e * f; } vs void SomeFunc() { int x = doSomething1(1, 2, 3, 4); int y = doSomething1(4, 5, 6, 8); int z = doSomething1(5, 6, 7, 9); printf("xyz=%d,%d,%d", x, y, z); int a = doSomething1(0, 2, 3, 4); int b = doSomething1(1, 5, 6, 8); int c = doSomething1(2, 6, 7, 9); printf("abc=%d,%d,%d", a, b, c); int d = doSomething1(6, 2, 3, 4); int e = doSomething1(5, 5, 6, 8); int f = doSomething1(7, 6, 7, 9); printf("def=%d,%d,%d", d, e, f); return x * y * z + a * b * c + d * e * f; } On a long functions I find it much easier to see/find/delete the debug print lines by indenting them separate from the real logic but I can't do that on any language that enforces code blocks by indentation. Commenting out also because an issue void SomeFunc(int v) { bool doit = v > 5; if (doit) { DoSomething(); DoSomethingElse(); DoSomethingOther(); } } For testing I often want to comment out the if void SomeFunc(int v) { bool doit = v > 5; //if (doit) { DoSomething(); DoSomethingElse(); DoSomethingOther(); } } If I was in python I can't do that def SomeFunc(v): doit = v > 5 #if doit DoSomething() DoSomethingElse() DoSomethingOther() Error! I have to format the whole function just to comment out a line for testing. Yes in this case I could put `if true` (then requiring two changes instead of one) but there are plenty of other cases where code blocks by indent make it really annoying to work with my code. So no, significant indentation is not a good thing.
  - 12y ago
- vidarh 12y ago
  Significant indentation is enough for me to avoid Python. It just doesn't have enough to offer vs. the available alternatives without significant indentation. It's much easier to read indentation than unindented/badly indented pairs of brackets, but you're setting up a strawman - it's not either or - and then you tear down the strawman yourself by pointing out we match the indentation anyway. My code generally is properly indented and has start/end markers (though I mostly write Ruby, so rarely brackets), but what makes me stay away from significant indentation is that in the 30+ years I've been coding, I've never gone long without coming across situations where indentation has broken "in transit" e.g. with cut and paste between systems in annoying ways, or someone loading the code into an editor that butchers the indentation with tabs using "non-standard" tab settings. When that happens, I'd rather "get the wrong impression" than have the code be broken. That's one reason I want redundancy. My tools can trivially and automatically fix the result of breaking indentation when the indentation can be derived from the code. Additionally, I want the visual redundancy, much like I find it far more comfortable to read syntax highlighted code even though it conveys no additional information.
  - ralmidani 12y ago
    An easy solution to the tab problem is to use spaces instead. A good text editor will even let you use the tab key to insert a set number of spaces.
  - tiglionabbit 12y ago
    I'm not setting up a straw man. I'm saying that it makes more sense if computers and humans are looking for the same things. Since humans read the indentation, computers should read the indentation too. The way things are in bracketed languages, humans and computers read different things, and you just have to hope that they always match up. Sometimes they don't, and the human and computer will have a misunderstanding. To make it a real linguistic redundancy, like in Spanish, the compiler should read both and issue a warning if the indentation is incorrect or misleading. As it is, you and the computer are actually speaking different languages.
- marcosdumay 12y ago
  Python's lambda semantics are limited due to the syntatic limitations created by Python's significant identation. That's not an universal problem of significant identation, but Python's syntax has it. I don't know, CS, so I don't know if it creates any such limitation. Also, computers don't deal well with it. It's a smaller problem than people don't dealing well with it (the alternative), but it's still a problem. Anyway, this is much more relevant to scripts that run inside a browser.
  - dragonwriter 12y ago
    > Python's lambda semantics are limited due to the syntatic limitations created by Python's significant identation. (nitpick: you seem to consistently use "identation" in place of "indentation".) I'm pretty sure that plenty of proposals consistent with Python's significant indentation have been proposed; python's lambda syntax is limited due to the BDFL not being convinced of the utility of more capable lambdas over using named functions enough to want to make Python's syntax more complicated to achieve it. > Also, computers don't deal well with it. Computers deal fine with it.
    - marcosdumay 12y ago
      > nitpick: you seem to consistently use "identation" in place of "indentation". Consequence of English not being my first language, and "indentation" being way too similar in it. I just can't spot the change. I've seen a couple of proposals, yes they'd work, but they seem to be always ugly. But the problem is not that significant indentation makes it hard to create lambdas (Haskell's ones, for example are fine), but that it's hard to think about rules that won't create some kind of problem. On Python it's lambdas, on Haskell it's that they are often actually harder to write than explicit blocks (good thing Haskell has explicit blocks too). And no, computers don't deal fine with it. To minimise some Python code you need almost an entire Python parser. Assembling Python code from small pieces (something that is really important for Javascript) is a frightening problem.
      - dragonwriter 12y ago
acjohnson55 12y ago
I want to love whitespace significance, but after hitting refactoring pain points many times in Python, Coffeescript, and Sass/Less/Stylus, at this point I believe the brackets are worth their redundancy.
deleted 12y ago
[deleted]

tiglionabbit 12y ago

Significant indentation is a good thing. Haskell and Python do it too. It's much easier to read indentation than it is to match up pairs of brackets in your head. In other languages, if the indentation doesn't match the brackets, you'll naturally read the indentation first and get the wrong impression of what the code does. In those languages, the indentation is supposed to match the brackets anyway. Why be redundant like that?

sangnoir 12y ago
I like the indentation + braces redundancy because indentations are for humans, brackets are for the interpreter. Logic blocks are more explicit with brackets I encountered a non-obvious Python bug that was caused by mixed spaces-and-tabs: to my human eyes, the indentation looked fine - the same as previous line, but the interpreter saw a different level of indentation.
- vertex-four 12y ago
  > I encountered a non-obvious Python bug that was caused by mixed spaces-and-tabs This is why PEP8 exists and people are supposed to follow it. Additionally, mixed spaces-and-tabs is a bug that causes poor readability - there's plenty of people who have their editors set to have tabstops as 2 or 3 spaces rather than 4, and your code will look wrong in their editors. If you think there's any issues with mixed tabs and spaces in your codebase, Python provides a tool to find out - tabnanny. Additionally, any context-aware code editor will display a warning. (If you're using Sublime Text, the plugin to use is SublimeLinter - I assume there's similar tools for vim and emacs.) You can even set spaces and tabs to display differently in many editors!
  - tiglionabbit 12y ago
    Just installed SublimeLinter. Thanks! It puts some icons in the margins, but I can't figure out how to get an explanation of those icons. I see a bunch of !s next to my import statements.
- nothrabannosir 12y ago
  True, agreed. Python has the -tt flag but, UI mistake, it should have been on by default. Or at least -t.
tomp 12y ago
It's not just significant indentation. CS parses "f + g" differently from "f +g" (the former is an addition, the latter is a function call with "+g" as the first argument).
- tiglionabbit 12y ago
  Yeah, the unary operators can cause gotchas. Also, here's a gotcha I've run into where `a(b)` is considered different from `a (b)` x a(b), c # => x(a(b), c); x a (b), c # => x(a(b, c));
greggman 12y ago
I'm sure this has been argued to death but the counter argument is invisible formatting changing behavior is a bad thing. Sure if you get your entire team to use spaces or the same tabs great but passing open source code around to lots of programmers some of which use tabs and some of which use spaces ends up leading to wasted debugging time when someone used a tab where they should have used a space or visa versa. On top of that I find it invaluable to be able to space out debugging code. Example void SomeFunc() { int x = doSomething1(1, 2, 3, 4); int y = doSomething1(4, 5, 6, 8); int z = doSomething1(5, 6, 7, 9); printf("xyz=%d,%d,%d", x, y, z); int a = doSomething1(0, 2, 3, 4); int b = doSomething1(1, 5, 6, 8); int c = doSomething1(2, 6, 7, 9); printf("abc=%d,%d,%d", a, b, c); int d = doSomething1(6, 2, 3, 4); int e = doSomething1(5, 5, 6, 8); int f = doSomething1(7, 6, 7, 9); printf("def=%d,%d,%d", d, e, f); return x * y * z + a * b * c + d * e * f; } vs void SomeFunc() { int x = doSomething1(1, 2, 3, 4); int y = doSomething1(4, 5, 6, 8); int z = doSomething1(5, 6, 7, 9); printf("xyz=%d,%d,%d", x, y, z); int a = doSomething1(0, 2, 3, 4); int b = doSomething1(1, 5, 6, 8); int c = doSomething1(2, 6, 7, 9); printf("abc=%d,%d,%d", a, b, c); int d = doSomething1(6, 2, 3, 4); int e = doSomething1(5, 5, 6, 8); int f = doSomething1(7, 6, 7, 9); printf("def=%d,%d,%d", d, e, f); return x * y * z + a * b * c + d * e * f; } On a long functions I find it much easier to see/find/delete the debug print lines by indenting them separate from the real logic but I can't do that on any language that enforces code blocks by indentation. Commenting out also because an issue void SomeFunc(int v) { bool doit = v > 5; if (doit) { DoSomething(); DoSomethingElse(); DoSomethingOther(); } } For testing I often want to comment out the if void SomeFunc(int v) { bool doit = v > 5; //if (doit) { DoSomething(); DoSomethingElse(); DoSomethingOther(); } } If I was in python I can't do that def SomeFunc(v): doit = v > 5 #if doit DoSomething() DoSomethingElse() DoSomethingOther() Error! I have to format the whole function just to comment out a line for testing. Yes in this case I could put `if true` (then requiring two changes instead of one) but there are plenty of other cases where code blocks by indent make it really annoying to work with my code. So no, significant indentation is not a good thing.
- 12y ago
vidarh 12y ago
Significant indentation is enough for me to avoid Python. It just doesn't have enough to offer vs. the available alternatives without significant indentation. It's much easier to read indentation than unindented/badly indented pairs of brackets, but you're setting up a strawman - it's not either or - and then you tear down the strawman yourself by pointing out we match the indentation anyway. My code generally is properly indented and has start/end markers (though I mostly write Ruby, so rarely brackets), but what makes me stay away from significant indentation is that in the 30+ years I've been coding, I've never gone long without coming across situations where indentation has broken "in transit" e.g. with cut and paste between systems in annoying ways, or someone loading the code into an editor that butchers the indentation with tabs using "non-standard" tab settings. When that happens, I'd rather "get the wrong impression" than have the code be broken. That's one reason I want redundancy. My tools can trivially and automatically fix the result of breaking indentation when the indentation can be derived from the code. Additionally, I want the visual redundancy, much like I find it far more comfortable to read syntax highlighted code even though it conveys no additional information.
- ralmidani 12y ago
  An easy solution to the tab problem is to use spaces instead. A good text editor will even let you use the tab key to insert a set number of spaces.
- tiglionabbit 12y ago
  I'm not setting up a straw man. I'm saying that it makes more sense if computers and humans are looking for the same things. Since humans read the indentation, computers should read the indentation too. The way things are in bracketed languages, humans and computers read different things, and you just have to hope that they always match up. Sometimes they don't, and the human and computer will have a misunderstanding. To make it a real linguistic redundancy, like in Spanish, the compiler should read both and issue a warning if the indentation is incorrect or misleading. As it is, you and the computer are actually speaking different languages.
marcosdumay 12y ago
Python's lambda semantics are limited due to the syntatic limitations created by Python's significant identation. That's not an universal problem of significant identation, but Python's syntax has it. I don't know, CS, so I don't know if it creates any such limitation. Also, computers don't deal well with it. It's a smaller problem than people don't dealing well with it (the alternative), but it's still a problem. Anyway, this is much more relevant to scripts that run inside a browser.
- dragonwriter 12y ago
  > Python's lambda semantics are limited due to the syntatic limitations created by Python's significant identation. (nitpick: you seem to consistently use "identation" in place of "indentation".) I'm pretty sure that plenty of proposals consistent with Python's significant indentation have been proposed; python's lambda syntax is limited due to the BDFL not being convinced of the utility of more capable lambdas over using named functions enough to want to make Python's syntax more complicated to achieve it. > Also, computers don't deal well with it. Computers deal fine with it.
  - marcosdumay 12y ago
    > nitpick: you seem to consistently use "identation" in place of "indentation". Consequence of English not being my first language, and "indentation" being way too similar in it. I just can't spot the change. I've seen a couple of proposals, yes they'd work, but they seem to be always ugly. But the problem is not that significant indentation makes it hard to create lambdas (Haskell's ones, for example are fine), but that it's hard to think about rules that won't create some kind of problem. On Python it's lambdas, on Haskell it's that they are often actually harder to write than explicit blocks (good thing Haskell has explicit blocks too). And no, computers don't deal fine with it. To minimise some Python code you need almost an entire Python parser. Assembling Python code from small pieces (something that is really important for Javascript) is a frightening problem.
    - dragonwriter 12y ago

acjohnson55 12y ago

I want to love whitespace significance, but after hitting refactoring pain points many times in Python, Coffeescript, and Sass/Less/Stylus, at this point I believe the brackets are worth their redundancy.

deleted 12y ago

[deleted]