Re: Sync API for workers

Le 01/09/2012 22:30, Rick Waldron a écrit :
> On Saturday, September 1, 2012 at 4:02 PM, Glenn Maynard wrote:
>> On Sat, Sep 1, 2012 at 11:49 AM, David Bruant <bruant.d@gmail.com
>> <mailto:bruant.d@gmail.com>> wrote:
>>> # Discussion 2
>>> ## Joshua Bell [5]
>>> "This can be done today using bidirectional postMessage, but of course
>>> this requires the Worker to then be coded in now common asynchronous
>>> JavaScript fashion, with either a tangled mess of callbacks or some sort
>>> of Promises/Futures library, which removes some of the benefits of
>>> introducing sync APIs to Workers in the first place."
>>> => What are these benefits?
>>
>> The benefit of being able to write linear code.  I don't think anyone
>> who's written complex algorithms in JavaScript can seriously dispute
>> this as anything but a huge win.
>
> I can seriously dispute this, as someone who involved in research and
> development of JavaScript programming for hardware. Processing high
> volume serialport IO is relatively simple with streams and data
> events. It's just a matter of thinking differently about the program.
I dispute it too. It's been 8 months I work with Node.js and have
written algorithms with IO. I've used promises and I'm very happy with
it when it comes to readability. The code is very close to being linear.
JavaScript, because of its syntax imposes some noise (especially the
"function" keyword and the Q library imposes a .then/.fail), but I'm
confident a language that compiles to JS could have sugar to eliminate
this issue.
I recommand taking a look at Roy for that inspiration on that topic
(start at ~8'00'') http://blip.tv/jsconf/jsconf2012-brian-mckenna-6145371
(it doesn't use promises, but adds sugar to get out of the callback hell)

David