Drawing sparkles around the cursor ftw.

Nick Husher wrote:
>> So I guess Javascript allows you to do things like
>>
>>    var i = 5;
>>    var i = 10;     // no error here.
>>    console.log(i); // prints "10"
>>
>> Is that how it works? Is there any difference between the above and
>> something like
>>
>>    var i = 5;
>>    i = 10;
>>    console.log(i);  // prints "10" still, I would imagine.
> 
> 
> Yes. Attempting to redefine a variable with the var keyword within the 
> same scope is ignored. It's considered bad style to use the var keyword 
> more than once with a variable (and certain camps declare it's bad style 
> to use the var keyword more than once per scope), so represents a 
> significant vector for bugs.
> 
> I believe (although I don't know for certain) that the strict mode in 
> Javascript 3.1 (if it ever makes it off the ground) won't evaluate the 
> first code example. As I mentioned, its goal is to maintain syntax 
> compatibility while eliminating the major vectors for insecurity and bugs.
> 
>> Currently, different implementations of JS can be pretty darn fast; 
>> Granted. But the language does not lend itself well to real 
>> concurrency. If you try really hard, you can simulate pseudo threading 
>> by using setTimeout. In this respect, you can perform multiple 
>> function executions in what would seem to be a simultaneous fashion 
>> (even though you will not get the benefits of true threading by doing 
>> so). JavaScript is a good language but at this point I don't see it 
>> being a hugely popular, scalable language outside the realm of browsers.
> 
> The caveat of your above statement is that it's only in the context of a 
> browser. setTimeout isn't a part of the core ECMAScript specification 
> and there's no structural reason why a concurrency API couldn't be 
> written into an interpreter, just that nobody has. The places that 
> Javascript tends to end up (other than as a browser scripting language) 
> are strange and obscure,* but it's my estimation that this is because it 
> rarely gets treated as a serious language, due in large part to its 
> early uses in the web environment (drawing sparkles around the cursor, 
> etc).
> 
> I don't see any real reason why a well-thought-out API exposed to an 
> ECMAScript interpreter wouldn't be viable for creating large 
> applications. The primary concerns--a dangerous global namespace and 
> performance concerns--are manageable with tools like JSLint and a 
> reasonably powerful code profiler. On the plus side, it offers a lot of 
> features out-of-the-box that "real" application languages have to 
> contort themselves mightily to do. Java's UI event handling and ugly 
> attempts at aspect-oriented-programming would be far simpler in an 
> ECMAScript environment, for example.
> 
> Nick
> 
> 
> * You can use Javascript to perform image-editing tasks in Photoshop. No 
> joke.
> 
>