features for es that would make it a perfect intermediate compiler target
Comments inline.
On 21 Mar 2009, at 22:16, Luke Kenneth Casson Leighton wrote:
- lack of integers.
i noted this - 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.
- 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?
- 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: 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 Berlin wrote:
On 21 Mar 2009, at 22:16, Luke Kenneth Casson Leighton wrote:
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.
I don't see that Luke's argument is at all dependent on whether it is an implementation of JS embedded in a browser that is being used as a compilation target. His post has numerous technical errors (which I'll address separately), but this isn't one of them.
On Sun, Mar 22, 2009 at 12:36 AM, Ash Berlin <ash_es4 at firemirror.com> wrote:
Comments inline.
thanks :)
- 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?
take following python - execute it:
x = 5 print x print y
you get NameError: name 'y' is not defined
take following javascript, in a web browser - execute it:
x = 5 alert(x) alert(y)
you get two popups: one saying "5" and the other "undefined".
question: how does a compiler translate code from python into javascript which is capable of dealing with this?
answer: with some absolute nightmare code, testing every single variable before use, resulting in approximately doubling the size of the compiled code:
if typeof x == undefined { throw NameErrorException("x is undefined"); } x = 5; if typeof x == undefined { throw NameErrorException("x is undefined"); } alert(x); if typeof y == undefined { throw NameErrorException("y is undefined"); } alert(y);
because the ECMA specification never insisted on an exception being raised, no browser ever implemented it.
See, the problem here is (I think) your are equating ECMAScript to ECMAScript running in a browser.
well, i'm not, but may have given the impression that i am, for which i apologise.
i am dealing with one on a daily basis (browser), such that the issues that pyjamas faces are foremost in my mind.
but i would also like to see ECMAScript extended to be able to take over from the python-psyco JIT compiler by being a suitable intermediate compiler target, by being able to run under google V8 engine, spidermonkey and other javascript interpreters.
the JIT psyco compiler can only deal with and accelerate python on 32-bit x86 platforms, whereas V8 can do 32-bit x86 and ARM assembler, and /usr/bin/smjs will run on absolutely anything.
so once pyjs was good enough, and once someone else did an experimental combination of python and google v8, i started the pyv8+pyjs experiment, but instantly ran into problems - like lack of support for integers.
This is not the same thing. Thats like saying the ECMAScript should mandate the DOM access.
nehh, the DOM is just an object that's dumped into the global namespace of an emcascript engine. well - at least two: one object named "document" and another named "window". some browsers dump the objects in those two into the top-level namespace as well. ( i mention this to let you know that i have an understanding about it - you're no doubt already aware of how it works )
several other things are thrown into the global namespace as well, such as setTimeout and clearTimeout.
what isn't added - because when the original browser engineers came up with it they didn't remotely consider it a possibility that people would try to use javascript for "serious" programming inside web browsers - is threading, mutexes and semaphores.
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.
hmm.... good point.... or.... well... you say that... but is it? you specify base functionality of objects, functions - strings, numbers, arrays, dictionaries (good addition!) etc.
why not have a section "if certain functionality is to be defined e.g. threads e.g. mutexes e.g. semaphores it must be defined this, this and this way"?
thus definining a common standard for interoperability, which both browsers and command-line interpreters would have to sit up and go "hmmm" over.
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.
for that to happen, you are going to need to define a common set of functionality such as how to import scripts, how to handle stdin, stdout, stderr, what exceptions to raise, how to interface to external libraries (in c, c++ or other languages), how to implement threads, semaphors, mutexes and much much more.
what happens when scripts are imported: do they have their own separate and distinct variable scoping (like in python), or are all variables imported directly into the global namespace (like in browsers)? is the script executed on import? what happens if you have threads and you do an import in both threads? is loading of a script to be done in both threads, or is the load to be treated as a "singleton", like modules are in python?
all of these things and many more need to be addressed to make ECMAscript a serious contender. the "pyv8 + pyjs" experiment, which gave literally a 10-times performance increase over standard python shows that there are real exciting possibilities, but you can't leave it up to chance: implementors will invent their own way of doing things, and that will cause as much of an interoperability headache as is present with browsers at the moment.
l.
folks, hi, i have some great news: i'm completely wrong about the "undefined" thing not being caught (in browsers) - it's only if you don't have an exception try { } block around your (entire) app that the variable gets set to "undefined". this is great. well, i say great: firefox raises ReferenceError, IE raises TypeError, but that's ok - i can deal with that. so that's one serious bugbear crossed off the list, and you didn't have to do a thing :) l.
On Mar 22, 2009, at 5:35 AM, Luke Kenneth Casson Leighton wrote:
- it's only if you don't have an exception try { } block around your (entire) app that the variable gets set to "undefined".
No, that's still incorrect.
this is great. well, i say great: firefox raises ReferenceError, IE raises TypeError, but that's ok - i can deal with that. so that's one serious bugbear crossed off the list, and you didn't have to do a thing :) l.
Measure twice, post once, next time. The list needs better signal-to- noise to prevent the unsubscribe tide from rising (as it is).
folks, hi,
i'm the lead developer on a project called pyjamas - pyjs.org - which is a python-to-javascript compiler intended to help web developers write ajax apps in the high level language which they are more familiar (python). it's a port of GWT, which is for java web developers, and there's also another port called RubyJS (see rubyforge.org). this helps web developers but there is an interesting thing happening when you combine e.g. a <highlevellanguage>-to-javascript compiler with something like the JIT
javascript compiler e.g. google's V8: you get a whopping tenfold performance increase over the use of the standard interpreter (e.g. /usr/bin/python).
unfortunately, there are some absolutely horrible things in emcascript that put it out of contention as a serious possibility for use as an intermediate compiler target, and these i thought it would be ... perhaps a good idea to raise with you.
as you're probably aware, python is actually a stunningly good fit for javascript, as things like this demonstrate: code.google.com/p/browsersync/source/browse/trunk/client/lib/lang.js?r=5 it gives a simple demonstration of how python-like language features can be emulated in javascript, BUT - there are some absolutely awful things that mean that javascript cannot in any way be taken seriously, until these are fixed:
i noted this - proposals:numbers
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.
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".
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?
well, they want multiple execution paths and in particular they want a main application to wait whilst some background asynchronous HTTP task goes off and fetches some script, or some CSS, or whatever.
in the pyjamas compiled code, the emulation of the module "import" capability should synchronously perform the load of the module, but the only cross-browser method which is successful is to add a < script > node to the DOM model of browsers.
the only way to "cope" with the asynchronous nature of dynamic script loading in browsers, thanks to the lack of proper threading semantics, is - get this: to emulate a function execution stack i.e. to begin to emulate features of real CPUs - in javascript! i mean, that's just ... insane - but it's the only way. by emulating a function stack, storing all local variables being used by the current function, it would be possible to temporarily suspend "execution" of the current application at the right point, wait for the asynchronous < script >
load to complete, and then tell the "emulator" to carry on where it left off. and, because all of the execution would be taking place on an emulated function-call stack, rather than a real javascript function-call stack, this would be feasible.
i don't even want to imagine the nastiness involved in fitting python exception handling into that. again, surprisingly, "standard" javascript exception handling provides just enough to emulate standard python exception handling, correctly, but... on top of a function execution stack, i'm not so sure.
see "bind" and "partial" in: 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?]
l.
folks, hi, i'm the lead developer on a project called pyjamas - http://pyjs.org - which is a python-to-javascript compiler intended to help web developers write ajax apps in the high level language which they are more familiar (python). it's a port of GWT, which is for java web developers, and there's also another port called RubyJS (see rubyforge.org). this helps _web_ developers but there is an interesting thing happening when you combine e.g. a <highlevellanguage>-to-javascript compiler with something like the JIT javascript compiler e.g. google's V8: you get a whopping _tenfold_ performance increase over the use of the standard interpreter (e.g. /usr/bin/python). unfortunately, there are some absolutely horrible things in emcascript that put it out of contention as a serious possibility for use as an intermediate compiler target, and these i thought it would be ... perhaps a good idea to raise with you. as you're probably aware, python is actually a stunningly good fit for javascript, as things like this demonstrate: http://code.google.com/p/browsersync/source/browse/trunk/client/lib/lang.js?r=5 it gives a simple demonstration of how python-like language features can be emulated in javascript, BUT - there are some absolutely _awful_ things that mean that javascript cannot in any way be taken seriously, until these are fixed: 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_". 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? well, they want multiple execution paths and in particular they want a main application to wait whilst some background asynchronous HTTP task goes off and fetches some script, or some CSS, or whatever. in the pyjamas compiled code, the emulation of the module "import" capability should _synchronously_ perform the load of the module, but the only cross-browser method which is successful is to add a < script > node to the DOM model of browsers. the only way to "cope" with the asynchronous nature of dynamic script loading in browsers, thanks to the lack of proper threading semantics, is - get this: to emulate a function execution stack i.e. to begin to emulate features of _real_ CPUs - in javascript! i mean, that's just ... _insane_ - but it's the only way. by emulating a function stack, storing all local variables being used by the current function, it would be possible to temporarily suspend "execution" of the current application at the right point, wait for the asynchronous < script > load to complete, and then tell the "emulator" to carry on where it left off. and, because all of the execution would be taking place on an emulated function-call stack, rather than a _real_ javascript function-call stack, this would be feasible. i don't even want to imagine the nastiness involved in fitting python exception handling into that. again, surprisingly, "standard" javascript exception handling provides just enough to emulate standard python exception handling, correctly, but... on top of a function execution stack, i'm not so sure. * 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?] l.