[webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

[Joe Mason]

> From: webkit-dev-bounces at lists.webkit.org 
> [webkit-dev-bounces at lists.webkit.org] on behalf of Filip Pizlo 
> [fpizlo at apple.com]
> Sent: Saturday, April 13, 2013 12:17 PM
> To: Ian Hickson
> Cc: dpranke at chromium.org; Benjamin Poulain; webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray 
> types
> 
> Same difference. I think this is overly harsh. Nobody will hold a gun to your 
> head and force you to use threads. The bumbling fools will probably ignore it.

Experience from desktop development tells me that bumbling fools absolutely love threads, and will probably start sticking things that are more appropriately done in other ways into threads as soon as threads are available.

Ok, let's use the less-loaded term of "unprepared novice": the primary characteristic of this type of developer is that they have a task they want to complete, they Google to find a tool for the job, and then they hack something together with the first tool they find without taking time to study it and learn its intricacies, or evaluate alternatives. Often they follow sample programs without understanding what the samples are doing.

Threads are complicated, and really should not be used without a thorough grounding in what can go wrong. Unfortunately there are lots of primers out there that give a very sketchy overview of how to use threads, and novice programmers are exactly the type to take a sketchy overview and think that's all they need to know to start coding.

Other approaches are also complicated, yes - we should evaluate each approach to see how complicated each is and how much guidance the structure of the API gives in how to use it correctly, on the assumption that novice programmers WILL be trying to write complex things using nothing more than a random one page blog post about the API for documentation. We can't assume that just because the API is complicated, novices will not find out about it - novices love to play with the new shiny things as much as anybody.

> The situation we have now is far worse actually: to get your scripts to do 
> useful thing you need to turn them inside-out using continuation passing 
> style. Much of it is because every interesting API is asynchronous. Are you 
> suggesting that continuation passing style with fully asynchronous APIa is 
> easier to understand than threads and synchronous APIs?  I suspect that they 
> can both be classified as hard, and both lead to people making terrible 
> mistakes. I also suspect that threads are the easier of the two - at least 
> that is my thinking based on memories of how hard it was for a professor to 
> explain CPS to people.

My experience is that threads and locks are roughly equivalent to goto: easy to explain how they work, but because they can be used in so many ways, harder to explain how to use them safely. While continuation passing, or message passing, or event driven styles are more like standard procedural flow control: more restrictive in how you structure your programs (which is the point!) but less conducive to creating spaghetti code.

I definitely think that asynchronous API's are much easier to reason about than traditional threads & locks, once you grok how asynchronous API's work. With threads & locks, even an advanced user has to do a lot of work to prove their design correct every time use of a lock is altered. They're extremely fragile compared to higher-level abstractions. The higher-level abstractions MAY be as difficult to learn (although my anecdotal experience is the opposite) but more of the work is up front in setting up to use them in the first place.

Joe
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.