4 ms·

I think you've completely missed the point. CSP channels are in fact what are used for elegant parallelism on Clojure. The processes are backed by a thread-pool

I think you've completely missed the point. CSP channels are in fact what are used for elegant parallelism on Clojure. The processes are backed by a thread-pool and can be run concurrently. Whether or not it's backed by real threads or not is completely opaque.

neilellis 12y ago
Do you feel that: var ch = chan(); go(function() { var val; while((val = yield take(ch)) !== csp.CLOSED) { console.log(val); } }); go(function() { yield put(ch, 1); yield take(timeout(1000)); yield put(ch, 2); ch.close(); }); Is clean and easy to understand. That's the point I'm making is that this contorting around a problem. I don't want my code littered with all this annotation just so that it can be synchronous. Also I'm not picking on the one solution, I just want everyone to take a step back and see if we're really heading in the right direction here.
- jlongster 12y ago
  It's worth stepping back, and it's far easier than the alternatives for sure. (note that with macros you could even have nicer syntax). But yeah, if you're arguing for real threads, that's a different discussion. Even so, you'll have to do similar coordination between threads which will look similar.
- jerf 12y ago
  Unfortunately, trying to add true threading to the browser in Javascript is so, so far in the direction of "insane" that it's not an option, so we're sort of stuck in the browser. Note that I am deliberately referencing that whole set of qualifications: "true threading in the browser in Javascript". Drop any chunk of that and it becomes less insane; for instance, WebWorkers drops "true" and gives a very restricted version of threading. Threading JS in general wouldn't be any harder or easier than threading any other dynamic language in theory (though in general those sorts of languages have a really poor track record, but only in practice, not in theory [1]), but adding "in the browser" is a big problem. Maybe if Servo works properly it will be feasible, but until then it would just be a nightmare. But I would certainly agree that if you have a choice, such as on the backend server, and you choose Javascript for concurrency, you're making a very poor choice. It just isn't what the language was meant for. [1]: As near as I can tell, they all tried to retrofit threading onto themselves a very long ways into their development (many years if not decades after birth), and the result- vary from "failure" to "barely functional". However if one set out to create a new language in the dynamic family and made threading a concern from day 1 there's no reason I can see you couldn't succeed. Elixir would be a sort of existence proof. It's the retrofitting that failed moreso than the general idea.
- tracker1 12y ago
  not quite as much... though using "async" as the main method name, with the fat-arrow syntax for an anonymous function would be a little more clear... same for using let instead of var here. async(()=>{ ... }); It's a bit more terse, and implies that the method will be run asynchronously from the parent.

neilellis 12y ago

Do you feel that: var ch = chan(); go(function() { var val; while((val = yield take(ch)) !== csp.CLOSED) { console.log(val); } }); go(function() { yield put(ch, 1); yield take(timeout(1000)); yield put(ch, 2); ch.close(); }); Is clean and easy to understand. That's the point I'm making is that this contorting around a problem. I don't want my code littered with all this annotation just so that it can be synchronous. Also I'm not picking on the one solution, I just want everyone to take a step back and see if we're really heading in the right direction here.

jlongster 12y ago
It's worth stepping back, and it's far easier than the alternatives for sure. (note that with macros you could even have nicer syntax). But yeah, if you're arguing for real threads, that's a different discussion. Even so, you'll have to do similar coordination between threads which will look similar.
jerf 12y ago
Unfortunately, trying to add true threading to the browser in Javascript is so, so far in the direction of "insane" that it's not an option, so we're sort of stuck in the browser. Note that I am deliberately referencing that whole set of qualifications: "true threading in the browser in Javascript". Drop any chunk of that and it becomes less insane; for instance, WebWorkers drops "true" and gives a very restricted version of threading. Threading JS in general wouldn't be any harder or easier than threading any other dynamic language in theory (though in general those sorts of languages have a really poor track record, but only in practice, not in theory [1]), but adding "in the browser" is a big problem. Maybe if Servo works properly it will be feasible, but until then it would just be a nightmare. But I would certainly agree that if you have a choice, such as on the backend server, and you choose Javascript for concurrency, you're making a very poor choice. It just isn't what the language was meant for. [1]: As near as I can tell, they all tried to retrofit threading onto themselves a very long ways into their development (many years if not decades after birth), and the result- vary from "failure" to "barely functional". However if one set out to create a new language in the dynamic family and made threading a concern from day 1 there's no reason I can see you couldn't succeed. Elixir would be a sort of existence proof. It's the retrofitting that failed moreso than the general idea.
tracker1 12y ago
not quite as much... though using "async" as the main method name, with the fat-arrow syntax for an anonymous function would be a little more clear... same for using let instead of var here. async(()=>{ ... }); It's a bit more terse, and implies that the method will be run asynchronously from the parent.