Le 04/09/2012 17:03, Glenn Maynard a écrit :
On Tue, Sep 4, 2012 at 4:23 AM, David Bruant <[email protected]
<mailto:[email protected]>> wrote:
The proposed solution here throws away all benefits of async code
to reduce the complexity of writing async code by... writing sync
code.
I wish we'd explore more solutions to make async more workable
rather than throwing away async.
It seems like you're thinking of asynchronous code as fundamentally
better than synchronous code. It's not; it has a set of
advantages--ones that the Web needs badly for the UI thread, in order
for scripts and the browser to coexist. It also has a set of serious
disadvantages.
Cognitive load is the only one mentioned so far. It is a serious issue
since for the foreseeable future, only human beings will be writing
code. However, as said, there are solutions to reduce this load.
I wish to share an experience.
Back in April, I gave a JavaScript/jQuery training to people who knew
programming, but didn't know JavaScript. I made the decision to teach
promises right away (jQuery has them built-in, so that's easy). It seems
that it helped a lot understanding async programming.
The cognitive load has its solutions.
We're not throwing away async; we're bringing sync back into the game
where it's appropriate.
True. I was exagerating a bit here :-)
The problem with blocking workers is that it may create a culture
of creating always more and more blocking workers (like Apache
creates more and more threads to handle more blocking connections).
You're not talking about this particular API here, you're talking
about every sync API in workers. Having sync APIs in workers and
performing blocking tasks in workers isn't something new.
This is one of the big reasons that we have workers at all.
I had never heard this argument before the topic of sync messaging
API for workers. Where does it come from?
When I read the worker API, I see a way to create a new
computation unit and to send messages back and forth, nothing
about writing sync code.
Regardless of goal, do people actually write more sync code with
workers?
The very first example in the spec is doing work synchronously.
http://www.whatwg.org/specs/web-apps/current-work/#a-background-number-crunching-worker
This is a very interesting example and I realize that I have used
"blocking" and "sync" interchangeably by mistake. I'm against blocking,
but not sync.
What I'm fundamentally (to answer what you said above) against is the
idea of blocking a computation unit (like a worker) that does nothing
but idly waits (for IO or a message for instance). It seems that
proposals so far make the worker wait for a message and do nothing
meanwhile and that's a pure waste of resources. A worker has been paid
for (memory, init time...) and it's waiting while it could be doing
other things.
The current JS event loop run-to-completion model prevents that waste by
design.
Taras Glek seems to think that the local storage API (which is
sync) is not a good fit for workers [3]:
"We could expose this API to workers, but then we run into an
ethical question of bringing crappy APIs to new environments."
(the article mentions that the localStorage API is synchronous as
part of the "crappy" aspect of it)
(The synchronous part is bad for the UI thread, but not a problem in
workers, so this isn't a very good argument, at least as summarized here.)
Many times such code relies on APIs or libraries which contain
blocking calls.
Do you have an example of that? I haven't seen one so far, but
that's an interesting point.
Specifically, I can't recall having seen any C/C++->JS example
that were doing IO (maybe files, but not network),
I believe that was his point--it's very hard to programmatically
convert synchronous code to asynchronous code.
True, but I mean, we could have read intentions or blog posts of people
saying "it's way too hard"
Technically it might be possible to automatically rewrite such
code to use asynchronous
coding patterns, but so far I don't think anyone has managed to do
that.
Naively, I would say, that once we've paid the price to compile
code from one language to another, you're not that far off from
compiling to a given coding pattern. Especially compiling from
LLVM bytecode.
Regardless, has anyone tried at all? Has anyone tried to compile
to JS+Promises or JS+task.js?
All of the compile-to-the-web movement started recently. Only now
do we start seeing what it can do. it's just the beginning.
Also, I wish the demand came from the people who do work on
Emscripten or Mandreel, that they came to standards mailing-list
saying "it took us a billion hours to compile I/O to JS correctly,
we tried promises, task.js and it didn't help. It would have taken
10 seconds if we had a sync API". But I can't recall having read
such a message yet. Compile-to-the-web is a complicated field and
I wish we didn't try to guess for them what they need before they ask.
I don't want to use a heavily layered environment that compiles to
JavaScript in order to write linear code.
I didn't recommend that in the part you're answering to. I was still
talking about Emscripten and Mandreel and such.
If I had a recommendation, it'd be to use promises.
I want the Web platform to be robust on its own, without complicated
systems piled up on top of it. Expecting that to be a solution is
just throwing in the hat and giving up. It's the "you don't need a
native API for that, just use a library" argument notched up several
orders of magnitude.
Eventually good library ideas get into standards. See querySelectorAll
or DOM4's .remove.
ECMAScript has a strawman to standardize promises. It won't make it to
ES6, but I have high hopes it will make it eventually.
David
