Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brendan Eich: The infernal semicolon

brendaneich.com

Post reply on HN
Print view View original

111–120 of 143 posts

Re: Brendan Eich: The infernal semicolon

#111

Post by alanh »

ricardobeat wrote: post #101
alanh wrote: post #74

Earlier quoted context omitted.

Simple. Look at the other comments, and it becomes apparent there are downsides to relying on / abusing ASI, and no advantages. (The only claimed advantage is that the lack of semicolons is visually appealing, but this is nullified by the fact the rules are sort of confusing and not apparent to all contributors.) Thus people are inferring this fat fellow is doing it only out of illogical, ego-based personal preferenc…

FIY the main claim is that it's a more reliable way to write js: programmer mistakes/missing semi-colons are more easily noticed, and much less common, since the rules are simpler. It's there in every debate about this.

I’m sorry, but I don’t know what “FIY” means, what your point is, or how your comment is a reply to mine. Consider re-phrasing?

Re: Brendan Eich: The infernal semicolon

#112

Post by [deleted] »

brown9-2 wrote: post #108
nhebb wrote: post #86

Earlier quoted context omitted.

The GitHub style guide recommends the opposite: "Do your best to never use a semicolon. This means avoiding them at line breaks and avoiding multi-statement lines. For more info, read Mislav's blog post [2]." FWIW, I agree with the Google style guide. Maybe I'm interpreting it wrong, but ASI struck me as a fail-safe to protect coders that forgot the occasional semicolon and was later mis-identified as a feature. Havi…

I find it odd that they (Github) don't really bother to justify their stance on this. The guide just says "don't use them", not why they find it in their interest to do so. It'd be interesting to get a better understanding of why they think this. Personally I don't see the point in omitting something that leads to known problems instead of including it and encountering zero problems.

[deleted]

Re: Brendan Eich: The infernal semicolon

#113

Post by BrendanEich »

nhebb wrote: post #86
cletus wrote: post #33

Heh, I was waiting for this post. Coming in the next 24 hours: - "Why I use minimal semi-colons in Javascript" - "ASI is broken but I like it" Honestly I'm shocked at the defense of this practice (of ASI "abusage"). It speaks loudly to Jacob's (fat@githib) ranking of ego-stroking and showboating over creating readable code, particularly for a library "Designed for everyone, everywhere" [1]. I'm confounded that such a…

The GitHub style guide recommends the opposite: "Do your best to never use a semicolon. This means avoiding them at line breaks and avoiding multi-statement lines. For more info, read Mislav's blog post [2]." FWIW, I agree with the Google style guide. Maybe I'm interpreting it wrong, but ASI struck me as a fail-safe to protect coders that forgot the occasional semicolon and was later mis-identified as a feature. Havi…

[2] has an inaccurate title. Semicolons are not optional, as is made clear by [2]'s final section that recommends putting ; before ( where ( starts a statement. Nothing optional in that case!

As I noted in my blog, it's not just (, either. ( is by far the likeliest source of trouble, but / + - [ all can serve as infix operators or prefix operators or (in the case of /) lexical delimiters.

Which is easier to remember, the rules in [2] plus the full "when you must use a semicolon because it is not optional" rule? Or the rules that people who know C, C++ and Java follow?

YMMV, but it's no slam dunk, and going "light" on semi-colons risks disastrous bugs. Going heavy tires out readers a bit with chicken-scratching but carries little risk of adding bugs (the worst case is if(C);T -- oops, and empty statement linting helps).

As usual with programming, there is no substitute for thinking and practicing, learning from the bottom up, and avoiding bad religion.

Re: Brendan Eich: The infernal semicolon

#114

Post by benatkin »

BrendanEich wrote: post #113
nhebb wrote: post #86

Earlier quoted context omitted.

The GitHub style guide recommends the opposite: "Do your best to never use a semicolon. This means avoiding them at line breaks and avoiding multi-statement lines. For more info, read Mislav's blog post [2]." FWIW, I agree with the Google style guide. Maybe I'm interpreting it wrong, but ASI struck me as a fail-safe to protect coders that forgot the occasional semicolon and was later mis-identified as a feature. Havi…

[2] has an inaccurate title. Semicolons are not optional, as is made clear by [2]'s final section that recommends putting ; before ( where ( starts a statement. Nothing optional in that case! As I noted in my blog, it's not just (, either. ( is by far the likeliest source of trouble, but / + - [ all can serve as infix operators or prefix operators or (in the case of /) lexical delimiters. Which is easier to remember,…

That's the exception to the rule. As long as the exception really is exceptional, it's OK to state the rule in the title.

Re: Brendan Eich: The infernal semicolon

#115

Post by mnutt »

drawkbox wrote: post #12

The eternal fires of high level bike shedding: semi-colons, whitespace and curly braces, no programming discussion or language can escape all three. Be liberal in what you accept and conservative in what you send (i.e. just use semi-colons) and your systems will work and play well with others being interoperable.

But it seems that the entire incident was caused by jsmin being overly conservative in what it accepted, thus breaking bootstrap's js.

While I use semicolons myself, it seems like jsmin should conform to the js spec as long as the spec allows the behavior.

Re: Brendan Eich: The infernal semicolon

#116

Post by BrendanEich »

benatkin wrote: post #114
BrendanEich wrote: post #113

Earlier quoted context omitted.

[2] has an inaccurate title. Semicolons are not optional, as is made clear by [2]'s final section that recommends putting ; before ( where ( starts a statement. Nothing optional in that case! As I noted in my blog, it's not just (, either. ( is by far the likeliest source of trouble, but / + - [ all can serve as infix operators or prefix operators or (in the case of /) lexical delimiters. Which is easier to remember,…

That's the exception to the rule. As long as the exception really is exceptional, it's OK to state the rule in the title.

No, "optional" means you can skip it, period, full stop.

False advertising plus module patterns plus concatenation equals big enough trouble for people to be outraged about the false advertising. Better to tell the truth, from the title down.

If you are using your brain fully, perhaps you can avoid firing the footgun. Is this the best use of your brain? I am not so sure.

Re: Brendan Eich: The infernal semicolon

#117

Post by mattbriggs »

BrendanEich wrote: post #116
benatkin wrote: post #114

Earlier quoted context omitted.

That's the exception to the rule. As long as the exception really is exceptional, it's OK to state the rule in the title.

No, "optional" means you can skip it, period, full stop. False advertising plus module patterns plus concatenation equals big enough trouble for people to be outraged about the false advertising. Better to tell the truth, from the title down. If you are using your brain fully, perhaps you can avoid firing the footgun. Is this the best use of your brain? I am not so sure.

How about this, I never lead a line with an infix operator, ever, and every other language I use does not require semicolons. Why would it be a bad thing to just pay attention to lines leading with (? Because js is the exception, it actually takes more brain power for me to remember it on every line then when I am leading with (, especially without a compiler complaining at me.

Would you admit that at least for me its a YMMV type of thing?

Re: Brendan Eich: The infernal semicolon

#118

Post by enneff »

ricardobeat wrote: post #102
enneff wrote: post #83

Earlier quoted context omitted.

This is not a good analogy. More like the superintendant will let you into a different apartment, or let you into your apartment and then punch you in the face. You just don't know. But you don't need analogies to understand why ASI is a bad idea. ASI means that when you leave out a semi-colon you get unexpected behavior instead of a syntax error. Failure is always better than the unknown. At least then there's a cha…

> This is not a good analogy Proceeds to offer an even worse analogy. Good one :)

I then went on to say that the analogy is unnecessary and offered an interpretation unaided by analogies. Did you think I was not aware of this?

Re: Brendan Eich: The infernal semicolon

#119

Post by mattbriggs »

bmelton wrote: post #75
tomjen3 wrote: post #71

Earlier quoted context omitted.

No. Sure it is the easier solution right now. But in the long run that would mean the Crockford would be able to dictate the style of Javascript to whatever the hell he wants. Given how important Javascript is now (and will be in the future) we cannot allow any one person to retard the entire future. Anyway use Googles closure compiler -- it can actually handle Javascript.

I think that's a visceral reaction based on his rudeness. So long as he keeps building tools and utilities that people rely on, and that people use, he is at least influencing the direction of Javascript and, knowing that, I'd think one might take heed when Crockford says "this will break in the future", as he happens to have more insight into the language than most. I understand that he wasn't polite, and I certainl…

we don't need to work on a better compiler then jsmin, because we have three -- uglifyjs, closure compiler, and yui compressor. They are all better then jsmin by any metric you choose, and they also don't break on automatic semicolon insertion.

Re: Brendan Eich: The infernal semicolon

#120

Post by kamaal »

enneff wrote: post #83
raganwald wrote: post #9

Earlier quoted context omitted.

"Here is your new apartment. You must use a key to enter it. If you forget your key, you can buzz the superintendent during business hours, and if the super is home, (s)he will open the door for you.” If you try to take your key with you at all times, the super will save your bacon once in a blue moon when you forget your key. On the other hand, if you think of the door as only needing a key when you wish to have it…

This is not a good analogy. More like the superintendant will let you into a different apartment, or let you into your apartment and then punch you in the face. You just don't know. But you don't need analogies to understand why ASI is a bad idea. ASI means that when you leave out a semi-colon you get unexpected behavior instead of a syntax error. Failure is always better than the unknown. At least then there's a cha…

Trusting artificial intelligence to make up for human stupidity doesn't look like a very good idea to me.

ASI is supposed to work in exceptional scenarios where you would have ended up making a mistake but wouldn't want to be reminded of. And that is supposed to be in rare scenarios.

Now if you make exception the norm and expect tools to make up for bad practices then its not going to help.

And this is why I think Python's forced indentation is in some way bad. Because it makes the code from a bad and good programmer both look same. And merely forcing code indentation won't magically transmogrify a bad programmer to a good programmer. There are many things to good programming and indentation is just one of them. Worse it will make both's code look the same.

Forgiving or masking or making bad practices look good doesn't help on the longer run. It only encourages such behavior. I am sure bad programmers can slip in easily into these communities than else where, because they are difficult to flush out and their mistakes are often forgiven or made look good.

Post reply on HN