Anyone else think this is by far the most boring technical debate ever to hit HN?
I think it's so boring because it's a one-sided debate. One side chooses a style that they find aesthetically-pleasing even if it causes issues for some small subset of potential users. The other side is flabbergasted that someone would be so reckless and argues for the sensible, safe option, which requires simply terminating your lines of code with an extra character, making those few issues for a small subset of po…
Of parser-fetishists and semi-colons
61–70 of 125 posts
Re: Of parser-fetishists and semi-colons
#62Re: Of parser-fetishists and semi-colons
#63I 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…
Re: Of parser-fetishists and semi-colons
#64I have grown extremely weary at the level of discourse that this whole situation has provoked - the linked post is one ad hominem after another! What is this supposed to accomplish? Hopefully I can get the people I'm criticizing to change their ways by making them feel really bad about themselves? By telling them they aren't visionaries, they are semi-colons, they are arrogant, sloppy, lazy? It's destructive, self-in…
At least everyone acknowledged that the editor war was an inside joke, I would gladly have an editor thread every week on HN over this.
Re: Of parser-fetishists and semi-colons
#65Earlier 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…
When it comes to this particular case, I've heard a few different arguments for why the syntax they use is poor, including the following:
1. The syntax relies on parsing behavior that is expected to change in the future.
2. The syntax they use does not work in one of the major minifiers used throughout the community (the crux of the whole issue to begin with, but certainly a drawback in and of itself)
I have yet to hear any benefit to NOT including a semi-colon to resolve this issue beyond aesthetics, and aesthetics alone is just not a rationalization that I can get behind.
Re: Of parser-fetishists and semi-colons
#66Haven'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…
Re: Of parser-fetishists and semi-colons
#67Earlier quoted context omitted.
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…
Interesting point, and I do hope that no one ever takes one of my opinions as an objective truth. That said, I do feel strongly that if the only benefit you can name about writing code in one particular manner is that it is aesthetically pleasing to you, then that is hardly a benefit at all. When it comes to this particular case, I've heard a few different arguments for why the syntax they use is poor, including the…
Isn't that exactly what's happening here? A bunch of people piling on skipped semicolons and infix if's because they think they're "sloppy"? Refusing to support ASI (which is, in fact, precisely specified) in their transformation tools because it's "broken"? Why are some people's aesthetics more important than others?
Again: you use the language you have. You will never get the community on board your private yacht of your "sane subset" Javascript. It's been tried for decades. It doesn't work.
Re: Of parser-fetishists and semi-colons
#68So, if your code needs syntactical changing when it gets extended, to me you’ve optimized prematurely. Code will always change and making sure our maintainers have a hard time breaking it is a very simple and good idea.
In other words, a good programmer writes code for project maintainability, not to signal dominance by showing off knowledge of the parser. [+]
(Corollary: One's cleverness is always a finite resource. I'd rather work with someone who devotes that resource to what's good for the project, not his own fame and ego.)
[+] - Unfortunately, the way teaching CS sometimes works, students are rewarded for showing off clever and elite code every chance they get, to show the prof they're a "real" coder.
Re: Of parser-fetishists and semi-colons
#69I'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…
Re: Of parser-fetishists and semi-colons
#70The 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…
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 bits of the language and used that subset as a starting point. http://anongallery.org/220/javascript-the-good-parts
@fat - no idea who he is, apart from being an employee of Twitter and works on Twitter Bootcamp, which is a framework for other people to use to build websites.
@izs - I think you overreach by grouping him as anti-semi-colon. Isaac is a pragmatist, he uses what suits the group of people he works with. NPM is a standalone app, a non-expert JavaScript developer doesn't need to delve into npm for it's standard usecases. So he choses a syntax he believes suits the group of people working with him. And yet, he is now the lead developer of Node.js, and he's already on record saying he won't be spending time changing Node.js into his preferred comma prefixed approach - because the existing team is already used to post fixed commas. That's what I like about Isaac - he listens to a wide range of opinions, and uses what works best for the environment he's in.
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.
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.
JavaScript is too flexible and too bastardised a language, leaving lots of weird and broken features. Plus, well written code isn't about being clever, it's about writing code that can be supported and maintained. Douglas has taken the best bits of JavaScript and found that to be quite an effective and useful language. With that subset he, along with the people who later became the YUI library developers wrote code in that subset.
The reason for that subset is that the language is clearer, less ambiguous, and less likely to catch a developer out. Turns out using just a subset of JavaScript's syntactic capabilities improves the quality, reliability and maintainability of code.
JS Lint was build to help developers bring their code into line with this subset of usage, and disallow perfectly valid but potentially flawed code. It favours code that is readable and quickly understandable by the non-expert developer.
JS Lint is the starting point for this improved use of JavaScript. JS Min is built, as far as I understand, with the assumption that JSLint rules are in place, so yes, it works on a subset of the language. Actually the documentation http://www.crockford.com/javascript/jsmin.html is more specific: "It is suggested that JSLint be used before using JSMin."
And I guess that's the real problem here. Not using JSLint before using JSMin. And then this argument boils down to @fat saying something along the lines of not wanting to be constrained to JSLint's subset of JavaScript. That's a call he can make, and the users of Twitter Bootcamp can then choose accordingly whether to use the toolkit (since if you are in a JSLint / JSMin using environment, it's probably best to stay away from Twitter Bootcamp.)
Perhaps what would be worthwhile is a JSLint equivalent for whatever syntax and idioms the Rails-induced subset of JavaScript uses (not just a watered down version of JSLint that JSHint is, but something that encourages what they consider to be best practice rather than merely allow it), and a minified that respects those idioms. And something in plain English for those unfortunate developers who stumble into these idioms.
What would "JavaScript the Railified Parts" look like side-by-side with Crockford's The Good Parts, and Flanagan's Definitive Guide?