4 ms·

Why does it seem hipster to use a language feature? Is it hipster to use null coalesce as well? The article linked above explains the reasons to omit semi-colo

by marrs 13y ago

Why does it seem hipster to use a language feature? Is it hipster to use null coalesce as well? The article linked above explains the reasons to omit semi-colons very well. I would personally prefer if JS forced you to terminate all statements with a semi-colon to avoid any ambiguity, but there you go. Speaking of ambiguity caused by whitespace, Coffeescript is a 1st degree offender for this. All you have to do is indent the wrong block of code, and you completely change the scope of a nested function, and you have no visual indication of your mistake whatsoever.

mradmin 13y ago
It's hipster because it goes against the accepted standard way of writing Javascript. See https://news.ycombinator.com/item?id=1547647&utm_source=twitterfeed&utm_medium=twitter https://news.ycombinator.com/item?id=1547647&utm_source=twit...
- marrs 13y ago
  My interpretation of "hipster" is being different because you think it's cool to be different. Being different because you think it's a better approach is called "making progress", either because you'll be proven right or proven wrong. I've thought about the de-facto standard way a lot and I think that it does nothing to avoid bugs while potentially misleading a coder about the language. Therefore I think it's worse. The only reason I follow the de-facto standard is because the time spent arguing about it with my peers is better spent getting work done.
  - andypants 13y ago
    Nobody has any good reasons that apply to most people, both for and against semicolons. There really isn't a huge difference in either style except in rare cases. > The only reason I follow the de-facto standard is because the time spent arguing about it with my peers is better spent getting work done. Which is why that is an excellent reason. Standards are useful, so if there is one, stick to it. If there is no reason to go against the standard, then don't. > I think that it does nothing to avoid bugs while potentially misleading a coder about the language. Therefore I think it's worse. Not seeing any semicolons can also potentially mislead about the language. It is not worse, they are both misleading until you realise ASI exists. Omitting semicolons also does nothing to avoid bugs, and introduces a different (additional?) set of edge cases where bugs may appear.
    - webXL 13y ago
      Please let us know of one equivalent using semicolons for this semicolon-less bug: a = b + c (d + e).print() Which is evaluated as a = b + c(d + e).print(); Taken straight out of http://mislav.uniqpath.com/2010/05/semicolons/ http://mislav.uniqpath.com/2010/05/semicolons/ > Standards are useful, so if there is one, stick to it. If there is no reason to go against the standard, then don't. Bingo. I think this is another reason to stick with the standard.
tlrobinson 13y ago
CoffeeScript certainly has its syntax quirks, but after some forced time using it I've found I can't go back to happily writing plain old JavaScript. The first week or two you'll regularly need to peek at the compiled source to be sure it's doing what you want, but you'll quickly get a feel for it. Also, a lot of the weird ambiguous cases are disambiguated by including parenthesis, so if you're unsure just include the parens and you should be ok.
- derefr 13y ago
  Oddly, > Also, a lot of the weird ambiguous cases are disambiguated by including parenthesis, so if you're unsure just include the parens and you should be ok. this is exactly the parallel I was going to make to the discussion we're currently having here. People who want semicolons on every line, even when they don't matter, are the same people who want to parenthesize every infix operation, even when the natural precedence the expression has without parentheses is already correct. I'm not sure I understand it in either case--are you afraid that someone might edit the code without understanding the "implicit defaults" of the language's syntax? Why are you letting that person near your codebase?
  - lmm 13y ago
    Some programmers are good at remembering large numbers of arbitrary rules. Others aren't, and I've worked with good and bad programmers of both kinds. So yes, I'm worried that a colleague might read the code and not know what the precedence is, and they will have to waste their time looking it up (thankfully some IDEs now have an command to add parentheses quickly, but it's still a distraction from their actual task). Pretty much all languages have some features that are more confusing than helpful, and good codebases avoid using those features (whether via formal policy or not). IMO most precedence rules fall into that category; it would be better if e.g. "a && b || c" were a syntax error until bracketed properly.
    - derefr 13y ago
      Why would they be looking up the precedence? If the code currently works, then they can read it, and infer that whatever precedence the operators have is the correct one for producing the result the code produces. If "a + b * c" is producing 17 where (a=2,b=3,c=5), then you know that your language makes multiplication precede addition. If the code doesn't currently work, then they'll have to figure out via some external method (looking up the original formula used in the code, say) what the precedence needs to be, in order to parenthesize to make it work. On a separate note, > it would be better if e.g. "a && b || c" were a syntax error until bracketed properly. this reminds me of the horribly-confusing practice of using "a && b || c" to mean "a ? b : c" in shell-scripting. It almost works, too... unless (a=true,b=false), in which case you unintentionally get the side-effects of c.

by marrs 13y ago

mradmin 13y ago

It's hipster because it goes against the accepted standard way of writing Javascript. See https://news.ycombinator.com/item?id=1547647&utm_source=twitterfeed&utm_medium=twitter https://news.ycombinator.com/item?id=1547647&utm_source=twit...

marrs 13y ago
My interpretation of "hipster" is being different because you think it's cool to be different. Being different because you think it's a better approach is called "making progress", either because you'll be proven right or proven wrong. I've thought about the de-facto standard way a lot and I think that it does nothing to avoid bugs while potentially misleading a coder about the language. Therefore I think it's worse. The only reason I follow the de-facto standard is because the time spent arguing about it with my peers is better spent getting work done.
- andypants 13y ago
  Nobody has any good reasons that apply to most people, both for and against semicolons. There really isn't a huge difference in either style except in rare cases. > The only reason I follow the de-facto standard is because the time spent arguing about it with my peers is better spent getting work done. Which is why that is an excellent reason. Standards are useful, so if there is one, stick to it. If there is no reason to go against the standard, then don't. > I think that it does nothing to avoid bugs while potentially misleading a coder about the language. Therefore I think it's worse. Not seeing any semicolons can also potentially mislead about the language. It is not worse, they are both misleading until you realise ASI exists. Omitting semicolons also does nothing to avoid bugs, and introduces a different (additional?) set of edge cases where bugs may appear.
  - webXL 13y ago
    Please let us know of one equivalent using semicolons for this semicolon-less bug: a = b + c (d + e).print() Which is evaluated as a = b + c(d + e).print(); Taken straight out of http://mislav.uniqpath.com/2010/05/semicolons/ http://mislav.uniqpath.com/2010/05/semicolons/ > Standards are useful, so if there is one, stick to it. If there is no reason to go against the standard, then don't. Bingo. I think this is another reason to stick with the standard.

tlrobinson 13y ago

CoffeeScript certainly has its syntax quirks, but after some forced time using it I've found I can't go back to happily writing plain old JavaScript. The first week or two you'll regularly need to peek at the compiled source to be sure it's doing what you want, but you'll quickly get a feel for it. Also, a lot of the weird ambiguous cases are disambiguated by including parenthesis, so if you're unsure just include the parens and you should be ok.

derefr 13y ago
Oddly, > Also, a lot of the weird ambiguous cases are disambiguated by including parenthesis, so if you're unsure just include the parens and you should be ok. this is exactly the parallel I was going to make to the discussion we're currently having here. People who want semicolons on every line, even when they don't matter, are the same people who want to parenthesize every infix operation, even when the natural precedence the expression has without parentheses is already correct. I'm not sure I understand it in either case--are you afraid that someone might edit the code without understanding the "implicit defaults" of the language's syntax? Why are you letting that person near your codebase?
- lmm 13y ago
  Some programmers are good at remembering large numbers of arbitrary rules. Others aren't, and I've worked with good and bad programmers of both kinds. So yes, I'm worried that a colleague might read the code and not know what the precedence is, and they will have to waste their time looking it up (thankfully some IDEs now have an command to add parentheses quickly, but it's still a distraction from their actual task). Pretty much all languages have some features that are more confusing than helpful, and good codebases avoid using those features (whether via formal policy or not). IMO most precedence rules fall into that category; it would be better if e.g. "a && b || c" were a syntax error until bracketed properly.
  - derefr 13y ago
    Why would they be looking up the precedence? If the code currently works, then they can read it, and infer that whatever precedence the operators have is the correct one for producing the result the code produces. If "a + b * c" is producing 17 where (a=2,b=3,c=5), then you know that your language makes multiplication precede addition. If the code doesn't currently work, then they'll have to figure out via some external method (looking up the original formula used in the code, say) what the precedence needs to be, in order to parenthesize to make it work. On a separate note, > it would be better if e.g. "a && b || c" were a syntax error until bracketed properly. this reminds me of the horribly-confusing practice of using "a && b || c" to mean "a ? b : c" in shell-scripting. It almost works, too... unless (a=true,b=false), in which case you unintentionally get the side-effects of c.