Subj : Re: ECMAScript standards committee
To   : netscape.public.mozilla.jseng
From : =?ISO-8859-1?Q?Georg_Maa=DF?=
Date : Sat Oct 16 2004 05:02 pm

zwetan wrote:
> what make Java or C# sexy in comparison to C++ is the ease of use,
> the GC mecanism etc.

No, the GC does not make them sexy. This makes them unpredictionable.

> and ho well ...just compare how many people use C++, Java, C#, JavaScript...
> if there is 1 using C++
> there is 100 using Java/C#
> and there is 1000 using JavaScript

I do not believe that Java + C# together has as many programmers as C++ 
allone. But Browser based JavaScript authors might be 1000 or more times 
more than C++ programmers. But do they realy write serious applications 
using JavaScript?

> but the ease of use does not mean less power to the developper.

Ease of use is limited to trivial scripting. If you go into the depth 
then there is no longer ease of use. Then you must know very much about 
not obvious implementation details.

> ECMAScript being prototype-based allow a lot of powerfull features
> by default in the language, which need complex implementation in other
> "serious" languages.

Yes, and this must not be thrown away. This is a big lack of C, C++, C# 
and Java. But this does not mean, that C++ does not provide a lot of 
language features, which would be useful also in JavaScript.

Especially in Webserver applications I would appreciate a language which 
is the result of merging C++ and JavaScript 1.x. JavaScript 2.0 is a 
very small step into this direction.

> -> solve the DOM war

The DOM war is not a language war (JScript versus JavaScript). It was 
the war document versus XML and dynamic language versus static language. 
The result (W3C DOM) is dictated by the XML hype and the Java hype. This 
DOM has lost the idea of a document and focuses just in tag biting. 
Accessing document contents in that DOM is very unsuitable, because it 
forces static language methodology to be used in dynamic languages like 
JavaScript. The W3C DOM in a JavaScript environment is just raping 
JavaScript with Java thinking.

> right now the only easy way to produce an exe with JS
> is to use JScript.NET (yep even in classic mode, /fast-).

If you use the dynamic object generation of JavaScript, then you are 
limited to hashmaps (and similiar collections) to access them in a 
simple implementation as binary executable without interpreter. But this 
is also unclear whether this is realy faster than an byte code 
interpreter. There may be situations where hash mapping is faster than a 
byte code interpreter, especially when elements are created and deleted 
much more often than just accessed. But when creation and deletion are 
not used as much as simply accessing then a byte code interpreter like 
the SpiderMonkey engine becomes faster than hashmapping. For a machine 
executable to get the flexibility and speed of SpiderMonkey in such 
situations dynamic recompilation at runtime with execution continuation 
is necessary. This is a language feature which none of the other C 
language family members provides. But JavaScript provides this. It does 
not make any noice about that, but this is what happens, if you use eval 
to change the meaning of a symbol defined in your script. The argument 
of eval is compiled an replaces the old implementation of that symbol.

Without a spidermonkey inside your executable it is very hard to 
implement such a behaviour.
-- 
Georg Maaß   -   bioshop.de    D-76227 Karlsruhe, Westmarkstraße 82
HTML, XML / JavaScript, C++, Java, PHP, VB / CGI, JSP, ASP, ASP.net
   - The ultimate DHTML engine: http://gml-modul.sourceforge.net -
                       http://sourceforge.net/projects/gml-modul

.