features for es that would make it a perfect intermediate compiler target

Ash Berlin ash_es4 at firemirror.com
Sat Mar 21 17:36:22 PDT 2009


Comments inline.

On 21 Mar 2009, at 22:16, Luke Kenneth Casson Leighton wrote:

>
> 1) lack of integers.
>
> i noted this - http://wiki.ecmascript.org/doku.php? 
> id=proposals:numbers
> - and went "thank _god_ for that".  hooray.  python "Long" can be
> emulated by an object, but the lack of integers makes for _serious_
> performance problems.  implementing integers as an object, and having
> to add mul, add, sub, div etc. and then use Round() on _every_ input
> parameter and _every_ return result?  hello? knock-knock, lights on,
> nobody home? :)
>
> btw - do give serious consideration to adding 64-bit int to the new
> standard: if you're going to add 32-bit, why not throw in 64-bit int
> and uint while you're at it: this _is_ 2009, and this standard will
> have to be around for another... what... 10-20 years, and only 32-bit
> is going to look _really_ foolish in 10 years time.
>
> 2) undefined.
>
> specifically, the lack of exception raising when an undefined variable
> is encountered.  that is _such_ a disaster it's unreal.  think about
> how a compiler of a dynamic language such as scheme, ruby and python
> has to emulate that, by checking _every_ single variable in _every_
> single instance where it is used (and raise an exception), and you
> start to realise "oh my god - that's... _awful_".


I don't even get what you mean here. Can you provide an example please?


>
> 3) lack of threading / asynchronous primitives
>
> the threading doesn't even have to be "proper threads" - but you _do_
> have to have the ability to create multiple simultaneous execution
> streams and allow blocking (mutex, semaphore), even if the
> specification says that implementors can (or even _must_) make the
> threads effectively "emulated" by a single process, so that there can
> never be any race-condition issues.
>
> asynchronous timers are _not_, on their own, sufficient.
>
> the issue is best illustrated as follows: if you try searching for
> "javascript sleep" you will find some absolutely _dreadful_ ways in
> which people are endeavouring to create synchronous "sleep" functions.
> one person came up with the idea of executing a hidden modal dialog
> box, using window.open("javascript:function { createTimer(...) }")
> which does actually work, if you are using IE only.  everyone else
> puts the browser into a tight 100%cpu hogging while loop with a timer
> on the outside, to break the loop.
>
> why are people _doing_ this to themselves?

See, the problem here is (I think) your are equating ECMAScript to  
ECMAScript running in a browser. This is not the same thing. Thats  
like saying the ECMAScript should mandate the DOM access. And unless  
I'm very much mistaken, thats not in the spec. That's not to say that  
I don't think there's a need for this sort of common functions/objects  
in a browser, but I'm not sure that ES-3.1/Harmony is the place for  
such a spec.

>
> [snip]
>
> * occasional loss of bindings of objects with their functions.
>
> see "bind" and "partial" in:
> http://code.google.com/p/browsersync/source/browse/trunk/client/lib/lang.js
>
> the issue is that simply returning a pointer to a function does not
> implicitly carry over the context - the object - with which that
> function is associated, so what people do is return _wrapper_
> functions that "apply" the arguments to the object.  but the thing
> is... people do this _everywhere_!!!  not just once, but countless
> thousands of times.
>
> from what i gather, this has been addressed with the new "class"
> system?  if you declare a class, and pass around a pointer to a
> function of an instance of that class, the object goes with it,
> automatically, yes?
>
>
> anyway - those are the major things.  in order of priority, i'd put
> them as "undefined" is _absolute_ paramount importance: javascript is
> literally a total failure without concrete support from the language
> itself for exception-raising on undefined variables; "integer" is
> next; the asynchronicity / threading and lack of mutex and semaphores
> is next (or tied 3rd-equal with integer); and the binding issue is
> last on the priorities, as it _can_ be dealt with (just).
>
> i'd be interested to hear how these issues can be addressed, using the
> new language features, so that javascript can become a language that
> can be taken seriously instead of being treated as something that
> people avoid at all costs [silverlight, anyone?]

Also a lot of your concerns only address javascript as a language  
running inside a browser - I for one think it has a future as a stand  
alone language.

-ash


More information about the Es-discuss mailing list