41–50 of 143 posts
Earlier quoted context omitted.
Why not?
http://news.ycombinator.com/item?id=1893686 Mentioned in http://www.aminutewithbrendan.com/pages/20101122 . JS is becoming the compiler target "bytecode", without needing verifiers or new and complex standards to be adopted by multiple browser vendors. JS has gaps as a target language, for sure. We are working on filling them (e.g. 64-bit and other int types). These are easy bugs to fix compared to creating a new, po…
The fact that they return the controlling operand is quite useful. Consider a situation where you want to check the property of an object, but don't know if that object is null:
var foo = obj && obj.bar;
var foo = null;
if (obj) {
foo = obj.bar;
}
var foo = obj ? obj.bar : null;
function myFunc(foo, bar) {
foo = foo || {};
bar = bar || 'default_value';
}
Earlier quoted context omitted.
If javascript were any worse, it may have been sidelined entirely before it had a chance to improve, and we would be using proprietary application stacks like iOS even more heavily for client side development.
> If javascript were any worse, it may have been sidelined entirely before it had a chance to improve And we should keep using it in 2012, 17 years later?
Good luck displacing JS. I mean that sincerely, especially if you work in the open. Dart had a rough start but even ignoring that, I don't think it will succeed. We'll see.
Is it me, or did the author tack on a new topic regarding the use of && and ||? The fact that they return the controlling operand is quite useful. Consider a situation where you want to check the property of an object, but don't know if that object is null: var foo = obj && obj.bar; I find this much more readable than: var foo = null; if (obj) { foo = obj.bar; } You can accomplish the same thing with a ternary operat…
The issue is abusing && or || as the whole of an expression statement, instead of using if.
Moar downvotes! Can we reconsider using this thing as the assembler for the web? Can we come up with a sane, cross-platform bytecode standard?
Lars Bak, who leads chrome's v8 team and was tech lead for java's hotspot vm, argues that javascript is a competitive 'bytecode' even compared to java or CLI bytecode [1]. Among other things, Bak claims that javascript source is more compact than traditional bytecode. [1] about 3/4 into this interview: http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Erik-Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-M…
CoffeeScript is far from perfect--it has syntax quirks of its own--but it's more pleasant for me to write in, being used to Python and Ruby. (And, yes, I understand JavaScript too; I just don't like the syntax.)
Eventually transcompiler languages will evolve to take advantage of different JS engine improvements. So far, this isn't a goal of CoffeeScript, but other abstraction layers might already be doing that.
Earlier quoted context omitted.
Right. To avoid confusion, I updated the post so the sentence reads "ASI is (formally speaking) a syntactic error correction procedure."
Given that these are all formal languages, though, isn't that equivalent to saying that ASI is, formally speaking, part of the language's syntax? It's all just parsers! Apart from the social conventions around them, of course.
Yet the "expectation of ASI" or (I think more likely) "expectation of newline significance" makes people believe that they'll get a ; inserted by separating two things by one or more newlines.
Most languages do not specify error correction. HTML5 of course does; CSS too; among general programming languages it's much less common. The spec for ASI does not fit in the tried-and-true LR(1) formalism used by ECMA-262. Parsing is not all ad-hoc or equally well-formalized and proven.
In addition to ASI, ECMA-262 has to use lookahead restrictions and a bit of semantic checking to cope with what could be purely syntactic concerns (say, if it could use GLR instead of LR(1)).
Is it me, or did the author tack on a new topic regarding the use of && and ||? The fact that they return the controlling operand is quite useful. Consider a situation where you want to check the property of an object, but don't know if that object is null: var foo = obj && obj.bar; I find this much more readable than: var foo = null; if (obj) { foo = obj.bar; } You can accomplish the same thing with a ternary operat…
var foo = obj && obj.bar; // great
!isActive && $parent.toggleClass('open'); // smelly
if (!isActive) $parent.toggleClass('open'); // betterEarlier quoted context omitted.
Yes, he's acknowledged many times (including in this post) that it was a mistake. That was the intention, but it wasn't successful. It should have gone all in (no semicolons at all) or not have existed.
I think it was a reasonable decision at the time. The idea was that JavaScript was not going to be some language people wrote hundreds of thousands of lines of code in, and that the target audience would become frustrated if the language didn't "help" them. For example, if JavaScript truly were to always require semicolons at the end of lines then that means this would be a syntax error: ... > Error, missing semicolo…
Depends whether the semicolon is defined as a terminator or as a separator.
This would be valid code with statement separator semicolons.
Is it me, or did the author tack on a new topic regarding the use of && and ||? The fact that they return the controlling operand is quite useful. Consider a situation where you want to check the property of an object, but don't know if that object is null: var foo = obj && obj.bar; I find this much more readable than: var foo = null; if (obj) { foo = obj.bar; } You can accomplish the same thing with a ternary operat…
Earlier quoted context omitted.
Given that these are all formal languages, though, isn't that equivalent to saying that ASI is, formally speaking, part of the language's syntax? It's all just parsers! Apart from the social conventions around them, of course.
No, there's an important distinction. ASI does not even kick in without a syntax error. Yet the "expectation of ASI" or (I think more likely) "expectation of newline significance" makes people believe that they'll get a ; inserted by separating two things by one or more newlines. Most languages do not specify error correction. HTML5 of course does; CSS too; among general programming languages it's much less common. T…
The error-correction view seems to want to add a third category, strings that are in some sense "errors", but nonetheless get unambiguously mapped to an AST. Which is strange from a classical formal-languages view, because if a string gets mapped to an AST, it's in the language, and the procedure that mapped it constitutes the parser! That category seems more like "warnings" to me, i.e. you probably shouldn't do this, but it will produce a program if you do.