Live data from Hacker News

Of parser-fetishists and semi-colons

christianheilmann.com

121–125 of 125 posts

Re: Of parser-fetishists and semi-colons

#121

Earlier quoted context omitted.

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

About as logical as using the logical negation operator for a purpose other than logical negation. :-)

So, how would you implement this dereferencing feature? given that this wouldn't be an issue if you added a semicolon, not sure why you are so hetup there...

Re: Of parser-fetishists and semi-colons

#122
post #96

Earlier quoted context omitted.

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

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

Yes, it worked according to how the parser was designed.

But it depended on a frowned-upon parser feature (AST), that can lead to ambiguous or faulty results in similar cases, and for no good reason. When the creator of the language and its biggest guru disagree with your code style, well, there's no much room for an argument, even if all known implementations work fine with your code.

He also did an idiotic ?: operator abuse instead of a clear "if" in the same exact line. He probably likes silly "succinct code" tricks, which even C people wouldn't touch with a large pole...

Re: Of parser-fetishists and semi-colons

#123
post #89

Every programmer should have had a professor who was really, inordinately fond of Ada, so much so that at least one assignment required coding in, or basic knowledge of, the language. Ada is strict as balls, but unlike its wannabe-successor, C++, its strictness is for the sake of clairty and the compiler usually actively helps you bring your code into compliance. (Rather than, say, complaining randomly because the sy…

I had a professor like that, he also was a signatory to the original ECMAscript standard. He also claims he came up with that name. Since they were spending too much time debating the name, he figured they'd call it that for now, and since it was such an awful name they would be sure to go back and change it.

Re: Of parser-fetishists and semi-colons

#124
post #116

Earlier quoted context omitted.

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?

It's even inconsistent with the Python core. I'm not going to defend the practice, but it's ended up being a lot less terrible than I thought it was when I first started writing Python here. I've used Twisted before, with its own weird style, and the weird style doesn't really distract much from the rest of the program. It's bad when everyone uses their own style, but if you only have 1.5 styles, it's probably OK. (But again, I would never write a style guide that said methods in Python must start with a capital letter and contain no underscores. That convention is for classes.)

Re: Of parser-fetishists and semi-colons

#125

Earlier quoted context omitted.

In JavaScript, && does not evaluate to a boolean. It evaluates to the thing on the left if that thing is false (in which case the right hand side is not evaluated at all), otherwise to the thing on the right. So in said JavaScript console, "asdas" && "da" evaluates to "da" and "" && "da" evaluates to "". So in an assignment context |r = a && b| would need to be replaced by: if (a) { r = a } else { r = b }, which may…

Nitpick: you mean `if (!a) {r = a} else {r = b}` (or switched blocks).

Er, yes. Of course I do. ;)
Post reply on HN