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