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

71–80 of 125 posts

Re: Of parser-fetishists and semi-colons

#71

Post by dclowd9901 »

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 those who undermine it. The question isn't "should we use semicolons", it's "who is going to start dictating the direction Javascript goes from here on out?"

Clearly, both of these individuals want that spot, but if there's anything I've learned in my short time of coding, convention always wins out.

Re: Of parser-fetishists and semi-colons

#72

Post by stcredzero »

ajross wrote: post #11

I've been shocked at the level of disrespect for language standards here. Yes: adding semicolons is probably good practice because it avoids the chance of stumbling over bugs like this. And yes: the ASI feature in Javascript is in hindsight a terrible mistake. That said: you go to war with the language you have, not the one you might want or wish to have. ECMAScript is ECMAScript. Arguing that your transformation too…

That said: you go to war with the language you have, not the one you might want or wish to have.

That's taking the quote out of context, which is saying a lot because it's a oft-quoted example of Donald Rumsfeld's tap-dancing. I doubt Mr. Rumsfeld was advocating driving around in Humvees as if they had armor. I'm sure he would laud the attempts of soldiers to improvise and mitigate the risks inherent in their equipment as much as possible.

And decades of experience in the "code convention hell" world of enterprise programming has taught us nothing if not that this sort of pedantry helps no one.

Over a decade of experience consulting in that world has shown me that adherence to code conventions has tremendous benefits. In shops where there was strict adherence to code conventions, I could be 10X or 100X more productive when refactoring using automated tools.

If you want to use Javascript, you have to take the whole language -- warts and all.

You need to justify this. This strikes me as a silly and counterproductive notion. Even in a tiny language like Smalltalk, you don't want to use, "the whole language -- warts and all," every chance you get. Hacky tricks have a cost. Just because you can implement an entire parsing system using doesNotUnderstand handlers, doesn't mean you really want to. (And yes, I've seen this happen in real life -- you really Do Not Want!)

Re: Of parser-fetishists and semi-colons

#73

Post by stcredzero »

stonemetal wrote: post #42
raverbashing wrote: post #14

Add the semicolon "but but but" add the semicolon There's so much FOR it, it's unbelievable. Yes, it's good to 'break the rules' now and then. Add the semicolon This is not about if JS allows it or not. It's important, but mostly irrelevant. You can also not add 'var' to JS variables unless needed. That's going to be a lot of fun when it goes wrong. But here are the million dollar questions: 1 - How much time is spen…

As a devils advocate. 1. How many times are we going to have to debug and rewrite code to work around this defect? If it were just this once sure add the the ';', unfortunately it is never just this once. 2. How much time will be saved by using a minifier that actually supports the javascript language. What other language features will break because someone didn't feel like supporting javascript in their javascript m…

How much time will be saved by using a minifier that actually supports the javascript language.

How much time would be saved by widespread use of "The Good Parts" of Javascript? This is likely to be much larger than the time you propose.

How much mental effort is needed to support half a dozen different minifiers that all support a different subset of the language

Who says you have to? If the community as a whole started omitting the hairy parts of the language, they would tend to converge on the same core. A superset of the 5 or 6 most popular subsets is still going to be a lot cleaner than the whole hairball. In practice, this is about the coverage that just about any language gets from tools like compilers and code transformers -- after all, the serious tools pretty much all have bugs. A superset of the 5 or 6 most popular language subsets is all anyone gets in practice.

Re: Of parser-fetishists and semi-colons

#74

Post by luser001 »

miahi wrote: post #53
h2s wrote: post #20

Haven't yet seen anyone point out what unpleasantly quirky code this was in the first place: !isActive && $parent.toggleClass('open') It should have been written like this: if (!isActive) { $parent.toggleClass('open'); } What if somebody needs to add a second bit of code to be executed if isActive is false? In the first case, they'd have to refactor the code into an if statement before adding it. It should have been…

You can always continue with !isActive && ($parent.toggleClass('open') || do_something_else()) but this is write-only code. This actually reminds me of some cool hacks with structure pointers and functions in the Linux kernel.

Unless I'm mistaken 'do_something_else()' won't get executed if toggleClass() returns a value that evaluates to true. Because of short-circuit boolean evaluation.

Re: Of parser-fetishists and semi-colons

#75

Post by jeltz »

stonemetal wrote: post #42
raverbashing wrote: post #14

Add the semicolon "but but but" add the semicolon There's so much FOR it, it's unbelievable. Yes, it's good to 'break the rules' now and then. Add the semicolon This is not about if JS allows it or not. It's important, but mostly irrelevant. You can also not add 'var' to JS variables unless needed. That's going to be a lot of fun when it goes wrong. But here are the million dollar questions: 1 - How much time is spen…

As a devils advocate. 1. How many times are we going to have to debug and rewrite code to work around this defect? If it were just this once sure add the the ';', unfortunately it is never just this once. 2. How much time will be saved by using a minifier that actually supports the javascript language. What other language features will break because someone didn't feel like supporting javascript in their javascript m…

Another advantage of the minifiers with a correct understanding of JavaScript is that they can do way more advanced minifications like shortening variable names.

Re: Of parser-fetishists and semi-colons

#76

Post by LeafStorm »

wahnfrieden wrote: post #63
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…

As a counterpoint, we decided to with underscored_names for our JS since we work with a lot of serialized Python data structures via JSON and using the same naming convention on server as client means our JS doesn't have a mix of camelCase and under_scores for things received via JSON and things defined in the JS. We're not writing reusable libraries for other projects to use, and we don't use a heavy amount of 3rd p…

You bring up a good point. There may be times when technical constraints mean you have to go against the prevailing style -- in your case, interoperability with existing code. (I know that a lot of this works in the other direction when dealing with "foreign" API's in Python.)

However, fat and co. aren't avoiding semicolons because there are technical constraints that require them to avoid them. They just seem to not like semicolons.

Re: Of parser-fetishists and semi-colons

#77

Post by stcredzero »

ktizo wrote: post #32
EvilTerran wrote: post #12

Earlier quoted context omitted.

Surely the language is precisely what the spec says it is? "The parser is the spec" is a nasty design smell, IMO.

Surely the environment is the spec. If he wants his code to work with this particular minifier, he should include the semicolon, nothing more, nothing less. Is a bit like trying to speak in official french. It might be correct according to the officials charged with protecting the french language, but you will sound extremely odd to most french people.

I've heard that in Korea, there's one national standard exam for English that's always been graded incorrectly, so everyone learns the incorrect answer when studying for the test.

Re: Of parser-fetishists and semi-colons

#78

Post by Agathos »

ajross wrote: post #26
courtewing wrote: post #21

Earlier quoted context omitted.

I agree with you to a certain extent, but I do think it is important to distinguish between those that think that they should just use a semi-colon and those that seek to disrespect a standard. In my case, and I've seen this sentiment expressed repeatedly by others on HN, I think it is odd that a minification script would actively choose not to support a syntax that is standards compliant. On the other hand, I think…

But "no noticeable benefit" is your aesthetic decision, not an objective truth. Not everyone feels the same. Pythonistas, for example, might quibble with you about that, because they skip semis when typing all the time and will experience editor friction when using Javascript. And even if you think it's "crazy" to skip the semicolons, you might not think it's crazy to write something like "test && result" as a simple…

As a Pythonista, I beg you to leave me out of this. I love Python's syntax but I can see Javascript's semicolon insertion is awful.

Re: Of parser-fetishists and semi-colons

#79

Post by philipjrose »

luser001 wrote: post #74
miahi wrote: post #53

Earlier quoted context omitted.

You can always continue with !isActive && ($parent.toggleClass('open') || do_something_else()) but this is write-only code. This actually reminds me of some cool hacks with structure pointers and functions in the Linux kernel.

Unless I'm mistaken 'do_something_else()' won't get executed if toggleClass() returns a value that evaluates to true. Because of short-circuit boolean evaluation.

That's correct. You could use:

  !isActive && ($parent.toggleClass('open'), do_something_else())
but I don't think anyone would advise it.

Re: Of parser-fetishists and semi-colons

#80

Post by radicalbyte »

tlogan wrote: post #25
ajross wrote: post #11

I've been shocked at the level of disrespect for language standards here. Yes: adding semicolons is probably good practice because it avoids the chance of stumbling over bugs like this. And yes: the ASI feature in Javascript is in hindsight a terrible mistake. That said: you go to war with the language you have, not the one you might want or wish to have. ECMAScript is ECMAScript. Arguing that your transformation too…

I think you missed the point. This is not really about whether semicolons are required or not. The point is that in order to ensure maintainability of code you should try to use language (and framework) in a way which ensures better maintainability, supportability, and portability of your code. Look, the statement like "a && b" is 100% valid in many languages but in order to increase maintainability, supportability,…

Okay, I'm going to bite.

&& is logical AND, and it operates on boolean expressions (or types).

So "a && b" evaluates to true if both a and b are true.

How can that be replaced by "if(a){b;}"?

Is it "r = a && b" being replaced by "if(a){r=b}"?

Using Chrome's javascript console:

> a = "asdas"; b="da"; a == b; false

> a = "asdas"; b="da"; if(a) { b }; "da"

Could you (or some other javascript expert) explain it to me?

Post reply on HN