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

101–110 of 143 posts

Re: Brendan Eich: The infernal semicolon

#101

Post by ricardobeat »

alanh wrote: post #74
tree_of_item wrote: post #63

Earlier quoted context omitted.

I really don't understand how a particular usage of semicolons and logical operators is indicative of ego-stroking, showboating, and "hipster", as if the word hipster even means anything at all. If fat _said_ something to make you use those words then that would make sense, but as it is I'm very confused.

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.

Re: Brendan Eich: The infernal semicolon

#102

Post by ricardobeat »

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…

> This is not a good analogy

Proceeds to offer an even worse analogy. Good one :)

Re: Brendan Eich: The infernal semicolon

#104

Post by sjwright »

The purpose of the semicolon in javascript is to eliminate ambiguity. Choosing not to avail yourself is like driving without a seatbelt -- of course it's possible, but I always thought the job of a programmer was to be as unambiguous as possible.

You're not the only person reading your code. Your code isn't just being parsed by five wholly different javascript engines, it's also being parsed by the brains of every programmer who chooses to read your code.

Expecting others to learn a few stupid rules and lame syntax hacks in order to understand and match your style seems moronic. And defending the decision by noting that "the spec permits it" is doubly so.

Re: Brendan Eich: The infernal semicolon

#105

Post by ahoge »

tzs wrote: post #96
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…

> Honestly I'm shocked at the defense of this practice (of ASI "abusage") Devil's advocate here: could one argue that taking advantage of ASI everywhere can make it safer, because it forces you to be fully aware of ASI? Suppose you always put in semicolons. You can STILL get bitten by ASI. The classic example is return { ...stuff... }; ASI is going to put a semicolon right after the return and break your code. Someon…

There will be no issues if you follow JSLint's/Crockford's suggestions. Furthermore, it simplifies the language drastically.

I really don't want to deal with this kind of stuff:

https://github.com/twitter/bootstrap/issues/3057#issuecommen...

(Just like I don't want to deal with those massive ==/!= tables.)

Re: Brendan Eich: The infernal semicolon

#106

Post by [deleted] »

Lewisham wrote: post #88
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…

What surprises me is not that Fat is a bit of a jerk (note, I "get" it, but I don't respect it), but that Twitter lets him keep being a jerk and actively hostile while acting as a representative of the company. If he wrote Bootstrap by himself, he's free to call every single user an idiot if he wishes, but when it's being released as a Twitter product, one would think Twitter would demand some modicum of respect to b…

[deleted]

Re: Brendan Eich: The infernal semicolon

#107

Post by vorg »

jrockway wrote: post #98
Lewisham wrote: post #88

Earlier quoted context omitted.

What surprises me is not that Fat is a bit of a jerk (note, I "get" it, but I don't respect it), but that Twitter lets him keep being a jerk and actively hostile while acting as a representative of the company. If he wrote Bootstrap by himself, he's free to call every single user an idiot if he wishes, but when it's being released as a Twitter product, one would think Twitter would demand some modicum of respect to b…

What surprises me is not that Fat is a bit of a jerk (note, I "get" it, but I don't respect it), but that Twitter lets him keep being a jerk and actively hostile while acting as a representative of the company. My observation of open-source community dynamics tells me that being hostile is an effective way to lead a large community. I've noticed that contributors act more carefully around someone who is mean to peopl…

Then there's the open source project "leaders" who're nice and smiley to people publicly, but snide and nasty through anonymous backchannels.

Re: Brendan Eich: The infernal semicolon

#108

Post by brown9-2 »

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…

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.

Re: Brendan Eich: The infernal semicolon

#109

Post by showell30 »

gruseom wrote: post #57
showell30 wrote: post #45

Earlier quoted context omitted.

I'm personally in favor of leaving JS mostly alone, especially at the syntax layer, and then let transcompiler solutions like CoffeeScript evolve to relieve the syntax burden and add semantic improvements. CoffeeScript is far from perfect--it has syntax quirks of its own--but it's more pleasant for me to write in, being used to Python and Ruby. (And, yes, I understand JavaScript too; I just don't like the syntax.) Ev…

Eventually transcompiler languages will evolve to take advantage of different JS engine improvements. I wonder what opportunities there are here that haven't been exploited yet and that don't require replacing JS with a new language. For example, could JS implementors define a more-easily-optimizable subset of JS? Then transpilers seeking performance could target just that subset.

It's an interesting idea. My assumption is that stronger JS engines already do a good job of optimizing simply-written JS, whether the JS is hand written or produced by a transcompiler.

Transcompilers that were target-specific could probably target server-side JS at first. e.g. If you're just building a node.js app, there's no reason for the polyfill language to make any concessions to IE, for example. So one "optimization" is simply avoiding legacy cruft in the generated output. But I could also see exploiting specific features of cutting-edge JS engines.

Re: Brendan Eich: The infernal semicolon

#110

Post by gruseom »

showell30 wrote: post #109
gruseom wrote: post #57

Earlier quoted context omitted.

Eventually transcompiler languages will evolve to take advantage of different JS engine improvements. I wonder what opportunities there are here that haven't been exploited yet and that don't require replacing JS with a new language. For example, could JS implementors define a more-easily-optimizable subset of JS? Then transpilers seeking performance could target just that subset.

It's an interesting idea. My assumption is that stronger JS engines already do a good job of optimizing simply-written JS, whether the JS is hand written or produced by a transcompiler. Transcompilers that were target-specific could probably target server-side JS at first. e.g. If you're just building a node.js app, there's no reason for the polyfill language to make any concessions to IE, for example. So one "optimi…

One of the stated reasons for Dart is that the V8 team was hitting a wall with making JS fast, beyond which a language with cleaner and more optimizable semantics is needed. I wonder, though, whether the nature of that wall has been clearly written up anywhere. I'd like to know if there are tricks in the category of "This would be annoying to write by hand in JS, but would be easy for a compiler targeting JS" that could be used to get around it.

Transcompilers that were target-specific could probably target server-side JS

I had an idea recently that (to me at least) is super exciting: someone should make a good language that compiles (à la Coffeescript/Parenscript) to JS but also to Lua. JS and Lua are close semantically, so it might not be so hard. (If it did turn out hard, it probably wouldn't be worth doing.) That would be a really interesting server-side alternative to both Dart (whose philosophy appears to be "run our VM on the server and compile to JS for the client") and Node.js.

Post reply on HN