Others like Clojure and Scala have more support at the standard library level.
I don't understand how. The only difference I see is whether the interprocess communication parts are coded into the language itself or whether they're coded into a library. It could theoretically make the problem more difficult to put it in the language itself. Instead of only affecting the programs that use that library, now your concurrency features could potentially affect any program written in your language.
Could you give me an example of a concurrency feature that really, truly benefits from being in the language and not the standard library? I simply can't think of any examples.
A bit further discussion: http://news.ycombinator.com/item?id=939364
Not to detract from anything you said (which I agree with), but when Guy Steele gave a guest lecture at my university on Fortress a few months ago, he said that the work splitting algorithm still needed work, in particular the part that decided the right amount of granularity for the given task (i.e. when to stop splitting the task into smaller subtasks).
Clojure has deep language support for concurrency - from syntactical constructs to it's core performant immutable data structures.
The only exception is the deref reader macro "@", since Clojure doesn't allow user-defined reader macros by default.
And a whole pile of others.
Did you use a parallel programming language?
We've gotten comfortable enough with our concurrency model, that we felt it deserved to be in the language.
As an aside, some features that benefit parallelism can be tricky to add retroactively, although possible (like an N:M threading model).
Does Spin address this issue?
For example - there does not exist a practical language (or design) where you can implement the LZ compression (ZLIB, others) in parallel, so that it gives the same results as the sequential "c" version.
It's just that certain algorithms, hence protocols, data structures, standards are not suited for parallel processing that well.
Okay, in the first case, maybe you can split the incoming data by 128kb and process each other individually ... but that's not the same - you can't reuse the LZ window.
Really the problem is the 13 dwarfs that university folks have identified - 13 stereotypical problems that relate to 99% of what's being done with a programming language - some of the dwarfs are just speedy parallel gnomes, some of them are old slow stubborn, like Gimli from LOTR.
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-18...
Hasn't there been a few parallel implementations of bzip2?
http://bzip2smp.sourceforge.net/
I understand that parallelism isn't suited for a lot of algorithms but from what I can tell, there's been heaps of successful work in compression. Could you give us some more information?
It would really help me out - I'm doing an undergraduate class where I have to manually make an open-source project parallel. I've been looking into compression algorithms because I thought they were well suited. Please help me out if I'm going down the wrong path!
The trick is to start at the largest chunk possible and go down until you find where they have left in some, uh, non-dependencies - like bzip2 which has independent x*100KB blocks, and video which (usually) has independent frames. You should be able to get 2-4 separate tasks out of that, which is good enough for CPUs.
Let's not underestimate the help that a language can provide; writing interpreters for languages is almost trivial on a lisp because you can reuse pretty much every piece of machinery on a lisp for your ends. Similarly, there is an entire class of problems that is nearly trivial on prolog that is pretty difficult to get right on other languages simply because prolog makes it easy to express rules and specifications that need to be met. Just look at an implementation of a sudoku solver in prolog and compare it with some other language.
I feel that a language designed with concurrency in mind would make it much simpler to write an entire class of problems. These languages are just gaining traction, so we are yet to see bigger and more significant examples. However, the "ants.clj" demo that Rich Hickey has written in Clojure, and some of the erlang demos in Joe Armstrong's book have made me a believer.
Sure, but for problems that can be parallelized you want a language to be able to express that parallelism. That may sound obvious, but many popular languages cannot do it. Let's not just give up on parallelism because it can't be used everywhere.
1. built-in distribution (i.e. Erlang distributed RPC)
2. bit-syntax
3. light-weight processes
4. pattern-matching
I'm sharing one of the lessons we learned building our own programming language. I love how many language designers there are on HN!
We're working on an invite system, so everyone can benefit from Skynet! Skynet is better when you use it with others, so the invites will work for groups of friends.
