Comments on: Async I/O made “easy” using JavaScript

By: Felipe Contreras

Felipe Contreras — Sun, 28 Sep 2008 20:19:54 +0000

Also, continuations in C are doable:
http://felipec.wordpress.com/2008/09/28/continuations-in-c-easy-asynchronous-stuff/

By: Felipe Contreras

Felipe Contreras — Sun, 28 Sep 2008 19:33:38 +0000

In Ruby you have proper closures, so it’s much easier to do asynchronous stuff:
http://gist.github.com/13492

By: pstickne

pstickne — Sun, 28 Sep 2008 18:56:46 +0000

The problem with OO in JS is that everyone (okay, most people?) wants to pretend it follows the class/object design of Smalltalk, Python, Java, C++, Eiffel, etc… and then constructs various implementations in an attempt to fit that model.
It isn’t.
It’s a prototype OO system. Like Self or Io.
Leave Java in Java.
(I think this applies to a number of the other “proposals” as well; most seemed fueled by language-comfortably taint.)
Use Javascript as Javascript.

That being said, I’d like a cleanup and -minor expansion- of the language in general: removing object and non-object distinctions, removing ‘var’ in global context, possibly even promoting all local variables to local lexicals by default, making a consistent way to having more control over the prototype, adding a “lightweight” syntax of creating functions (make “blocks” seem more natural), add some form of name-spaces, expand the built-in operations on arrays and other primitive data-types (as standard extensions), create a way to write custom [] and []= methods (and provide alternative always-direct member access), etc.

Javascript really has almost everything that it needs there. Some is buried, some isn’t fully realized and the rest is suppressed.

Interesting article. It would be nice to see the specific Javascript version mentioned though as I’d argue “Javascript” is still ubiquitous with ECMA Script 3 (ECMA-262).

By: Rosie

Rosie — Mon, 22 Sep 2008 12:47:19 +0000

Aaah thanks a lot

By: alexl

alexl — Mon, 22 Sep 2008 10:50:17 +0000

Rosie;

Its a tiny wrapper around g_idle_add(). Its set up in gtk-js.c.

By: Rosie

Rosie — Mon, 22 Sep 2008 10:11:04 +0000

What is the add_idle() in the example implementation? Is it part of a JS Library? Thanks

By: sdsfsdf

sdsfsdf — Wed, 17 Sep 2008 11:34:31 +0000

“Its IMHO pretty easy to understand”

What!?

By: alexl

alexl — Wed, 17 Sep 2008 09:25:28 +0000

Martin:

Interesting. It would be nice to have async sleep and queue_idle availible too, so you could do things like that.

Yield is part of JS 1.7, which should be available in Safari 3.0 too. Maybe in chrome too? I don’t know what JS version V8 implements.

I don’t necessarily disagree with you that JS isn’t the nicest language about, but some of the things you mention can be fixed by standardizing the embedding bindings, and by “grounding” the base part of your app in C/C++. I don’t love JS, but I believe its effective for this kinds of use (as proven by e.g. firefox). I don’t know lua very well, but it seems like a similarly kind of weird language, but still people estimate that about 40% of adobe lightroom is written in that…

By: Martín Soto

Martín Soto — Wed, 17 Sep 2008 08:58:51 +0000

What you’re trying to do looks very similar to what Gustavo Carneiro’s GTasklets (http://www.gnome.org/~gjc/gtasklet/gtasklets.html) actually achieve for PyGTK applications. They are not only useful for asynchronous I/O, but for implementing bits and pieces of user interfaces. For example, in one application, I have a fullscreen mode that hides the cursor and a button bar after 10 seconds of mouse inactivity. The whole behavior is cleanly separated in a single tasklet procedure. Normally, this would require some additional attributes, as well as adding code to a few of the methods in the class controlling the fullscreen window, which is usually much less readable and maintainable because the code ends up being spread all over the place.

In a related note, I read your previous post about JavaScript being the quintessencial embedded language, but I really can’t buy into JavaScript as a language for writing serious applications. Even despite Mozilla’s efforts to improve the language in their Spidermonkey implementation (no one else supports yield statements in JavaScript as far as I know) the language has too many flaws to be taken seriously. I could start with variables being global by default (very dangerous!) and end with the lack of a standard class definition mechanism (e.g., everyone rolls out his own, specific, and incompatible class system) but discussing my complete list of pet peeves would require a dedicated website, I guess.

That said, I can believe that Spidermonkey is a lean, speedy interpreter, and that this characteristics make it very attractive for embedding. So bad, this doesn’t make the language it implements any better, though…

By: alexl

alexl — Wed, 17 Sep 2008 08:42:23 +0000

Jürg:

That would be very nice!