On 13 January 2011 12:57, Reinier Zwitserloot <[email protected]> wrote:
> I'm a bit confused as to why Scala programmers have the gall to claim the > moral high ground in regards to multi-core programming. I wouldn't single out Scala programmers. Any language that makes data immutable by default, supports closures, and encourages functions free of side-effects is fair game here. If your objects are immutable, and your functions are free of side-effects, then you can be certain that your code will parallelize, it's that simple. Anyone working with Haskell, F#, Clojure, etc. can also claim the same benefits as Scala when it comes to this advantage. Certainly a language that is very good at letting you write code that runs > well on multiple cores will have a function-esque taste, but scala isn't it. > > For example, scala has enshrined foldLeft and foldRight forever more as > core language, by importing both of those by default as operators (i.e. > "/:", as a token, is a fold operator in scala unless you go out of your way > to unimport it). foldLeft is fundamentally *NOT* parallellizable! Its > accumulator based, and accumulator is a magic word. It means: "This code has > no hope whatsoever of ever running parallel". > Nobody every claimed that they're parallel (unless you get into the topic of AST manipulation, and rewriting folds as something else - but that's heading rapidly into experimental territory). Folds aren't "enshrined" either, they're just methods defined on a couple of traits in the standard library, and certainly not part of the language specification. They're convenient for a great many problems, and easy to implement, but certainly they're not being forced down anyone's throat. Scala supports a great many other things that don't work concurrently, many of them are there for Java interoperability. Then again, scala also offers alternatives that *do* scale well. Collections - for example - offer a `sum` method, this could be implemented using fork-join just as easily as with a fold. 2.9 is out soon, and the big new feature is parallel collections. If you want to see something that's truly enshrined in the language, then this is where you should be looking. I'd envision a language that truly takes this 'parallelize everywhere' > principle seriously to be extensively conc-list based. > > conc-lists are like lisp's cons-lists (1 head element and a tail list), but > instead have lists for both head and tail. A list is thus really a tree. If > this tree is reasonably well balanced, operations on it that are not > accumulation based can be aggressively parallelized. > So a bit like the Hash Tries that underlie a good 70-80% of Scala's current collection library then? By the way, conslists, mainstay of for example lisp, and very much > associated with functional languages, are another one of those things that > absolutely, positively, cannot be parallelized AT ALL. Looping through such > a list takes O(n), and no amount of parallelization can fix that. You can > kludge it by storing forward pointers in the list as an implementation > detail (i.e. hotspot would be doing that), so another core can jump right in > the middle of a list and start from there, but this is frightfully > complicated; far more complicated that for example updating the JVM hotspot > to recognize foreach loops, check if the code relies on sequential > execution, and if not, paralellizing it. (That's not a good idea, see my > earlier post, but it can be done). > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
