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

91–100 of 125 posts

Re: Of parser-fetishists and semi-colons

#91

Post by benatkin »

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…

> @izs - I think you overreach by grouping him as anti-semi-colon [sic].

Those are your words, not mine. The "other side", as I put it, isn't necessarily anti-semicolon. To be on the other side of this particular argument, they merely have to disagree with the assertion that a semicolon at the end of the statement is a must, and not a style choice. And izs did choose that style for npm.

> Thomas Fuchs - heard of him, he's done lots of stuff JavaScript and PHP wise. I'll give you that one. He gave us Scriptaculous, and some decent PHP resources (like PHPatterns, IIRC). He's active in Rails.

There's Zepto.js too, and he was a longtime core member on the Prototype JavaScript framework. He's influential.

> The main reason the quality of JavaScript has increased dramatically in the last 6 or 7 years has been because of a coalescing towards a JavaScript best practice. This has mainly been led by Douglas Crockford and JavaScript developers at Yahoo.

I strongly disagree. The driving force was the increase in importance of the JavaScript language. He was part of that trend. He helped speed it up, but it would have happened regardless.

> JS Lint is the starting point for this improved use of JavaScript.

JS Lint is a starting point. There are other valid starting points.

> And I guess that's the real problem here. Not using JSLint before using JSMin.

But @fat isn't using jsmin. And there are great alternatives, so this is a valid choice!

> What would "JavaScript the Railified Parts" look like side-by-side with Crockford's The Good Parts, and Flanagan's Definitive Guide?

It would look like this: http://pragprog.com/book/tbcoffee/coffeescript

Re: Of parser-fetishists and semi-colons

#92

Post by ajross »

radicalbyte wrote: post #84
ajross wrote: post #82

Earlier quoted context omitted.

The && operator short circuits. It evaluates its second operand only if the first is true (becuase if the first is false, then the expression result is known to be false). It thus acts pretty much exactly like "if", but with an infix syntax. This trick is used pervasively in shell programming, where the native if syntax sucks.

Thanks, I get it now :) So the second operand can be a function / method, with any (or no) return type. > function bob () { alert("bob") }; true && bob(); Alerts "bob". Nice trick, though not something I'd personally ever us as it's not concise and isn't portable to C# (and I assume Java/C++). Plus using the IF statement is a better showing of intent.. and I don't really like relying on job security through obscurity…

It is concise. There are fewer tokens and bytes needed to write A && B than if ( A ) { B }. And the intent thing is, as I've tried to explain, very much situation-specific. There are many programmers out there very comfortable with this idiom. That it doesn't happen to be popular in the web development community doesn't mean it sucks or isn't worth learning.

Don't pass judgement on syntax you literally just learned, basically. Don't assume the world you know is the only one worth knowing. Good hackers know their tools.

Re: Of parser-fetishists and semi-colons

#93

Post by wpietri »

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 look at any standard that has evolved well over a period of years, you can see in the early days there was a lot left undefined. If the implementation is the spec, then nothing can be treated as open for change.

Re: Of parser-fetishists and semi-colons

#94

Post by jpk »

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 a pretty dramatized way of framing it, don't you think? I think the take-away is as simple as this: JavaScript is a dumpster-fire, and we should probably fix it so we can avoid more of this noise. Framing it as a soap opera conflict instead of a teachable moment makes it more productivity-draining than it already is.

Re: Of parser-fetishists and semi-colons

#95

Post by Natsu »

tptacek wrote: post #13

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

Maybe. But I barely spent any time reading all the arguments and more time reading through and learning about the syntax of JavaScript, so it was probably more interesting for me than most people simply because I tuned out most of the boring bits. Also, I learned that Closure linter's fixjsstyle can add semicolons for you, which is nice to know.

But that's what I always do: scan for the interesting bits or move on.

Re: Of parser-fetishists and semi-colons

#96

Post by batista »

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 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 I'd rather have on my team.

Re: Of parser-fetishists and semi-colons

#98

Post by Isofarro »

benatkin wrote: post #91
Isofarro wrote: post #70

Earlier quoted context omitted.

"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…

> @izs - I think you overreach by grouping him as anti-semi-colon [sic]. Those are your words, not mine. The "other side", as I put it, isn't necessarily anti-semicolon. To be on the other side of this particular argument, they merely have to disagree with the assertion that a semicolon at the end of the statement is a must, and not a style choice. And izs did choose that style for npm. > Thomas Fuchs - heard of him,…

"> What would "JavaScript the Railified Parts" look like side-by-side with Crockford's The Good Parts, and Flanagan's Definitive Guide? It would look like this: http://pragprog.com/book/tbcoffee/coffeescript

Err, that's CoffeeScript, not JavaScript. CoffeeScript gets cross-compiled into JavaScript. It isn't JavaScript in itself.

Re: Of parser-fetishists and semi-colons

#99

Post by fusiongyro »

slantyyz wrote: post #18
tptacek wrote: post #13

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

Agreed! It amazes me how much time people have spent arguing over this. When I see an open source library that's not coded in the way I like, I either customize it to my liking or look for alternatives. The only time I would really care about someone's programming style is when I work with them, otherwise live and let live.

It would be that way, but for the fact that this style breaks other tooling.

Re: Of parser-fetishists and semi-colons

#100

Post by dclowd9901 »

jpk wrote: post #94
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's a pretty dramatized way of framing it, don't you think? I think the take-away is as simple as this: JavaScript is a dumpster-fire, and we should probably fix it so we can avoid more of this noise. Framing it as a soap opera conflict instead of a teachable moment makes it more productivity-draining than it already is.

I'm only explaining what makes sense. I know, personally, I'm not going to change how I'm writing my code because of what two influential Javascript developers bitched about on a Github ticket, and I'm pretty sure I'm not alone in that sentiment.

I'm merely explaining why it's drawing so much attention, and what nerves this debate seems to be touching, because as a technical debate it is insanely boring. But that's clearly why it's not strictly a technical debate.

Post reply on HN