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

81–90 of 125 posts

Re: Of parser-fetishists and semi-colons

#81

Post by quanticle »

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…

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

Couldn't that almost be viewed as a feature, rather than a bug? I mean, this way you can instantly tell if a particular variable was received from the server via JSON or was defined in the client code itself. I would consider a naming distinction like to be a benefit, rather than a harm.

Re: Of parser-fetishists and semi-colons

#82

Post by ajross »

radicalbyte wrote: post #80
tlogan wrote: post #25

Earlier quoted context omitted.

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?

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.

Re: Of parser-fetishists and semi-colons

#83

Post by web_chops »

sophacles wrote: post #59
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…

Your comment makes me wonder if this is localized issue, or a more general anti-pattern in polyglot programming. The pattern being: "push my favorite language into the other ones I use". It may or may not be covered by "you can write FORTRAN in any language", or some sort of corollary to Greenspun's 10th law.

Actually, this is one of the reasons why some of the new languages pick a popular older language's syntax and coding style. Example, most static typed languages follow C syntax (C++,Java, C#) because most of them expect the programmers to migrate from the older language. This makes the migration much smoother. And when the syntax does differ, programmers tend to overestimate the complexity of the newer language (most C++ programmers complain a lot about Objective-C's syntax initially).

Re: Of parser-fetishists and semi-colons

#84

Post by radicalbyte »

ajross wrote: post #82
radicalbyte wrote: post #80

Earlier quoted context omitted.

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?

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..

Re: Of parser-fetishists and semi-colons

#85

Post by jrockway »

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.

Re: Of parser-fetishists and semi-colons

#86

Post by dasil003 »

sophacles wrote: post #47
tptacek wrote: post #30

Earlier quoted context omitted.

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.

I dunno... semi-colons have practical implications for everyone, but "my use case requires speed and persistence isn't an issue, therefore mongo is better" vs "i need persistence and didn't read the docs, who cares if it's a little slower - riak is better" gets pretty tiresome, particularly when my use case is "i need easy graph traversal, neo4j w/ gremlin is the wave of the future". :P hahaha - I feel the best use o…

Of course it's more boring than NoSQL debates, but it's also potentially so much more important. The reason people care is because you have two great projects which they might want to use for many reasons, but which are fundamentally incompatible because of a semicolon. It's not the philosophical divides between database technology where you have many subtleties to analyze and choose between, instead it's just a fucking semicolon forcing you take sides between two orthogonal projects which you might have good reason to use jointly.

Re: Of parser-fetishists and semi-colons

#87

Post by [deleted] »

tptacek wrote: post #61
brown9-2 wrote: post #60

Earlier quoted context omitted.

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…

Oh for fuck's sake.

[deleted]

Re: Of parser-fetishists and semi-colons

#88

Post by ScottBurson »

tptacek wrote: post #13

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

It interests me as yet another example of why DWIM in programming languages is a bad idea.

Maybe the next time a language designer contemplates including such a feature as ASI, he/she will remember this furore and reconsider.

Re: Of parser-fetishists and semi-colons

#89

Post by bitwize »

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 syntax for template instantiations changed this week, or punishing you for pronouncing the word "const" with the improper intonation.)

With a bit of exposure to Ada, programmers might understand better why languages are so finicky about syntax details, and that just because a language is lenient, doesn't mean you should take advantage of that leniency. And that, in cases like JavaScript with its bloody semicolons, perhaps leniency is a disadvantage.

Re: Of parser-fetishists and semi-colons

#90

Post by bzbarsky »

radicalbyte wrote: post #80
tlogan wrote: post #25

Earlier quoted context omitted.

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?

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 or may not be more confusing than the original statement with &&. But in a statement context, where the result of && is not being assigned to anything at all, "a && b" is exactly the same as "if (a) b;" except harder to understand.

Post reply on HN