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

Of parser-fetishists and semi-colons

christianheilmann.com

Post reply on HN
Print view View original

111–120 of 125 posts

Re: Of parser-fetishists and semi-colons

#111

Post by stephencanon »

dclowd9901 wrote: post #71
tptacek wrote: post #13

Anyone else think this is by far the most boring technical debate ever to hit HN?

Because all you see it as is an argument about syntax. It's actually an argument between the old guard and the up-and-coming hotshots. Nobody really cares one way or another, and while it would take Twitter more time to append changes to their code than it would Crockford, my guess is the trouble for either would be negligible. That said, this is very obviously a pride war between those who stick to convention and th…

"Hotshots" have better things to do with their time than argue this nonsense.

Re: Of parser-fetishists and semi-colons

#112

Post by mattbriggs »

Isofarro wrote: post #70
benatkin wrote: post #46

The author is picking and choosing who he wants in this argument of his. He has Douglas Crockford and Brendan Eich on the pro-trailing-semicolon side. On the other side he has @fat. If he wanted to be fair he could have included someone like @izs or Thomas Fuchs. But if he referenced their viewpoints on it, it would make it harder to pretend that all code that doesn't include trailing semicolons after every statement…

"He has Douglas Crockford and Brendan Eich on the pro-trailing-semicolon side" Brendan Eich, the conceiver of the language. The best placed person in understanding why the JavaScript language does what it does, and what problem a feature was trying to solve. Douglas Crockford, the developer who took all of JavaScript and found within a clean elegant language. And then he pulled together what he considered the best bi…

I'm one of those weird npm style guys, the thing that breaks my brain is this isn't about writing clever code. it is about treating the (literally) single broken case (in the browser) as a broken case. It is about writing safe and maintainable code, by making it obvious that you are dealing with that one special case. I have written js both ways, and I find comma first/semi colon first I am hit by less syntax bugs. Thats why I do it, any other reason would be dumb.

As for crockford leading the way to sanity, the biggest problem I have with him is that instead of warning and educating he flat out forbids, and then heckles people who disagree. "with" is considered a "bad part", but it is used by literally every js template framework. He recommends closure based object construction, but in a big app that is a memory nightmare. And then there is stuff that basically treats js devs as mindless idiots. Like the "new" operator is discouraged, just in case someone forgets to use it when they want to instantiate something or the function keyword is discouraged, because it hoists.

All of those are opinions, and some are demonstrably terrible. But for some reason The Good Parts is still held up as gospel, while the community just chooses to ignore the parts of the book it doesn't like.

As for minifiers, JSMin is pretty obsolete at this point. If you are using it, as an incredibly easy win you can decrease your page load times by using uglify js, google closure compiler, or yui compressor. All of these support asi fully, but that is probably the least important reason to use them.

Re: Of parser-fetishists and semi-colons

#113

Post by mquander »

dclowd9901 wrote: post #71
tptacek wrote: post #13

Anyone else think this is by far the most boring technical debate ever to hit HN?

Because all you see it as is an argument about syntax. It's actually an argument between the old guard and the up-and-coming hotshots. Nobody really cares one way or another, and while it would take Twitter more time to append changes to their code than it would Crockford, my guess is the trouble for either would be negligible. That said, this is very obviously a pride war between those who stick to convention and th…

That's even less interesting. I give 2/10 of a crap about what the best way is for me to avoid missing-semicolon errors in Javascript, but I give 0/10 of a crap about who wins an ego battle between Crockford and some other dudes. Why on God's green earth is that on the front page of anywhere?

Re: Of parser-fetishists and semi-colons

#114

Post by burgerbrain »

tptacek wrote: post #30
sophacles wrote: post #22

Earlier quoted context omitted.

Of the sustained debates, I feel it is tied with the "my nosql is better than yours" debate. Both of them seem to boil down to "understand your tools, your use case may not map to the thing someone else is advocating for their use case".

This is so, so, so much more boring than NoSQL. I agree that Riak vs. Mongo has gotten pretty boring. But this is semicolons. For f's sake.

You seem to be pretty interested in being as bored as possible with this discussion.......

Re: Of parser-fetishists and semi-colons

#115

Post by tptacek »

chris_wot wrote: post #106
tptacek wrote: post #61

Earlier quoted context omitted.

Oh for fuck's sake.

I understand the frustration with this comment, but the clincher for me on the whole anti semi-colon crowd was at this article: http://www.wordsbyf.at/2011/10/31/i-dont-write-javascript/ He says he doesn't use semicolons, except that it caused issues for those who concatenation scripts so he adds a semicolon to the end of the js file. But, lo! This causes issues for those who use the following pattern: (function() {…

  (function() {
     // Le code
  })()

  !function() {
    // Le code
  }()
YOU'RE RIGHT. I'M HORRIFIED.

Re: Of parser-fetishists and semi-colons

#116

Post by frio »

jrockway wrote: post #85
LeafStorm wrote: post #43

I come from a Python background. However, thanks to work and school, I now program mostly in JavaScript, PHP, and Java (though I still use Python when I get a chance). Now, I could use underscore_names in Java and JavaScript, but I don't. Even though I personally prefer underscore_names to camelCaseNames, I also realize that those languages are designed with camelCaseNames in mind, that the community conventions are…

Incidentally, we use CamelCaseMethodNames in Python at Google, presumably to be consistent between languages. If you're one company that uses multiple languages, it may be beneficial to use the same style in each, even if that style is non-idiomatic.

Doesn't that lead to inconsistencies in style when you use external libraries though?

Re: Of parser-fetishists and semi-colons

#117

Post by blasdel »

batista wrote: post #96
dclowd9901 wrote: post #71

Earlier quoted context omitted.

Because all you see it as is an argument about syntax. It's actually an argument between the old guard and the up-and-coming hotshots. Nobody really cares one way or another, and while it would take Twitter more time to append changes to their code than it would Crockford, my guess is the trouble for either would be negligible. That said, this is very obviously a pride war between those who stick to convention and th…

>That said, this is very obviously a pride war between those who stick to convention and those who undermine it. I'd frame it as "a pride war between people wanting a sane codebase not based on fragile parser edge cases --include two that know the language inside out--, and the developer of some minor js code that thinks he's too clever for all that". That's no "undermining convention", that's juvenile bs. I know who…

It wasn't a "fragile edge case", it worked just fine with no ambiguity in every javascript implementation.

The problem is that jsmin is a naive pile of textual replacements (though not quite as abysmal as John Gruber's markdown.pl) instead of being a javascript implementation — something that actually parses javascript into an AST and compiles it to minified javascript.

He left out cases for several unary operators so it broke perfectly valid code. After bitching at them he came to his senses and fixed it: https://github.com/douglascrockford/JSMin/commit/5ca277ea452...

Unless for some reason you need your minifier to be trivial enough to be portable with no dependencies, you should really be using something along the lines of google's Closure Compiler, which produces far better output and even has stuff like tests!

Re: Of parser-fetishists and semi-colons

#118

Post by blasdel »

chris_wot wrote: post #107
philipjrose wrote: post #79

Earlier quoted context omitted.

That's correct. You could use: !isActive && ($parent.toggleClass('open'), do_something_else()) but I don't think anyone would advise it.

Actually, you are all missing Crockford's real point, which is that they are considering making ! a binding deference of function objects. If they do, then this: clearMenus() !isActive && $parent.toggleClass('open') Becomes this: clearMenus()!isActive && $parent.toggleClass('open'); And not this: clearMenus(); !isActive && $parent.toggleClass('open'); The no semi-colon crowd is ridiculous. There are no good arguments…

there are even fewer good arguments for changing the semantics of the fucking logical negation operator 17 years down the line in a dynamic language with billions of end users and no discrete versioning

Re: Of parser-fetishists and semi-colons

#119

Post by blasdel »

wpietri wrote: post #93
Ramone wrote: post #3

I think the argument that we shouldn't rely on the parser for certain language features is a bit silly (including interpreting end-of-statements). The language is precisely what the parser says it is, and nothing more or less. JSMin is free to not do what the parser does of course, but that won't be Javascript.

I'm not sure if you're making that argument yourself, but it's thoroughly wrong. First, there's no "the parser". There are a lot of parsers, some of which don't yet exist. Second, that means there's no way to distinguish between bugs and features. If the language is defined by parser behavior, then any parser bug is now part of the language. Third, you've eliminated the white space needed for future growth. If you lo…

javascript the language itself has a spec that everyone has pretty much always implemented consistently even in the worst throes of the browser wars (the runtime libraries, not so much)

the problem was that jsmin didn't just violate the spec — it's not a javascript implementation at all, but rather a pile of naive textual replacements

Re: Of parser-fetishists and semi-colons

#120

Post by chris_wot »

chris_wot wrote: post #107
philipjrose wrote: post #79

Earlier quoted context omitted.

That's correct. You could use: !isActive && ($parent.toggleClass('open'), do_something_else()) but I don't think anyone would advise it.

Actually, you are all missing Crockford's real point, which is that they are considering making ! a binding deference of function objects. If they do, then this: clearMenus() !isActive && $parent.toggleClass('open') Becomes this: clearMenus()!isActive && $parent.toggleClass('open'); And not this: clearMenus(); !isActive && $parent.toggleClass('open'); The no semi-colon crowd is ridiculous. There are no good arguments…

Why has this been downvoted? If you don't agree, try commenting - don't downvote! Sheesh?
Post reply on HN