I'm definitely with you on the data structures. One of the BIG changes in scala 2.8 (the one that kicked it all off actually) is a total refactoring of the collections library. Partly this was to remove some of the duplication that had built up over time, but also to pave the way for future work. Parallel arrays and Hash Tries are already live in trunk builds, and even 2.7 already has some very nice fork-join support that will tie in well with these structures.
Other concurrency features, not necessarily from the FP world, are a built-in actors library and plus delimited continuations - which allow projects like the swarm library to push code to where the data is (instead of vice-versa). Again, paving the way for better concurrent behaviour. [swarm: http://www.scala-lang.org/node/3485] Having said all of that... the core concepts of immutable data and pure (1st class) functions are all going to prove invaluable in our parallel future. Structures are, at the end of the day, just libraries; and can be changed to meet whatever characteristics we demand of them. On 14 July 2010 16:53, Reinier Zwitserloot <[email protected]> wrote: > This is a bit of a slanted argument, isn't it? > > It's: The answer is 100% OO, vs. the answer is a mix. > > Of course the answer is a mix. That doesn't mean java is doomed, nor > that closures in java7 will be too little too late, nor even that > java6 is 100% OO. > > Some FP principles are most likely inevitable to work properly with > concurrency, but this doesn't mean that today's FP languages get > fantastic concurrency for free, either. > > Case in point: Lots of FP languages, even modern ones like scala, have > fold left and fold right baked pretty deeply into the core of the > language. For example, in scala: > > initialValue /: list > > is foldLeft, whereas: > > list :\ initialValue > > is foldRight. I'd call that deeply baked in. (For those not in the > know, fold takes for example a list of numbers, say: [1,2,3], an > initial value for the accumulator, say, 0, and a function, say, > arithmetic plus, and returns a single number, by repeatedly running > the function with the accumulator and the next entry in the list, and > using this value as the new value for the accumulator. In this > example, the accumulator would go through 0, then 1, then 3, then 6, > which is the return value you'd get). > > However, foldLeft and foldRight are completely UNparallelizable, > because of that accumulator concept. You can only calculate one > function at a time because they're all dependent on the accumulator, > which is dependent on all previous calculations. Text book definition > of purely sequential. > > Going even deeper, the vast majority of FP languages use a cons list > concept at the very heart of their language to represent lists, which > are very important in FP languages. cons lists work like this: any > list is defined by a head element, as well as a tail list, which is > itself a conslist. There's a unique global singleton list usually > named Nil which represents the empty list. Therefore, Arrays.asList(5, > 4, 3) in java is represented by a single array containing 3 ints, but > in e.g. lisp, such a construct is internally represented as: > > [5, [4, [3, Nil]]] > > The advantage is that any given list is immutable (which is good in FP > land for obvious reasons), but e.g. adding an item to a list doesn't > require copying every element in the list, you just create a new one > with the new element as head and the existing list as tail. > > However, cons lists are hostile to concurrency as well. Something as > simple as attempting to count the # of entries in one takes O(N) even > if you have 1000 cores to do it; you just can't parallelize it. > > There are variants to both fold and conslists that DO work well with > parallelization. For conslists, you need a somewhat complex concept > called a conclist, where both head and tail are themselves conclists, > and operations that run on conclists make sure that the lists remain > somewhat balanced (i.e. that for the conclist itself as well as any > sublist, the total number of elements on the left is roughly equal to > the total number of elements on the right), and for fold, you remove > the accumulator concept entirely and just define a combinator > operation, which can reduce any 2 elements to a single element, as > well as a set value to convert the empty conclist to. Such a 'fold' is > extremely parallelizable. Counting the number of elements in a well > balanced conclist given an infinite number of cores only takes O(log > N), which is in practice as good as O(1). For example, a well balanced > conclist with 65536 elements in it only takes 16 cycles to count, not > 65536 cycles like it would if that was a conslist. This feels almost > exactly like fold but its not quite the same, so you can't just > replace implementations of foldLeft with this highly parallelizable > scheme. > > It's true that conclists and parallelizable 'fold' is most likely a > lot easier to write and work with given some FP principles such as > blocks (often referred to as closures), but unless your name is > Clojure you'd have to redesign a lot of the core language features and > libraries. Even the universally hailed-as-future-java Scala is just > not set up for this stuff, which is one of the many reasons why I very > much doubt Scala will be the future of the java community. It'll be an > interesting stepping stone, is all. > > In summary, this argument is way more complicated, as they usually > are: > > 1. YES, some FP will most likely be needed in the future multicore > world, and > 2. Nevertheless this does not mean that existing FP languages are all > set; *ALL* languages will need to undergo major changes to adapt to > the future, FP or not. > > On Jul 14, 3:29 pm, Kevin Wright <[email protected]> wrote: > > In our recent, erm, "discussion" one oft-mentioned issue came up: > > > > Is Java's downfall foreshadowed by the lack of FP constructs, and will > > closures be "too little, too late" when they finally arrive? > > > > and, as so often happens in discussions of this nature, respondents > divided > > into the pro-FP and pro-OO camps > > (plus one who seemed to think that *any* abstraction was good, regardless > of > > paradigm, and that computers would be programming themselves in the near > > future anyhow...) > > > > A *few* posts later, the typical war-lines were drawn: > > > > "Future programming *will* be (at least partly) functional in nature, > the > > needs of concurrency demand it!" > > > > vs > > > > "Object-Orientation works, expanding Java like this just > > adds unnecessary complexity, and FP has never really left academia > anyway" > > > > It's very common for developers deeply embedded in the world of objects > to > > deride FP as being "complex", "academic", and "overly abstract", but what > > really caught my attention this time was that the pro-FP crowd were > giving > > very definite concrete examples of the benefits to be obtained, whereas > the > > pro-OO crowd seemed to be hard waving around nebulous principles - this > is > > definitely a role reversal when compared to the usual stereotypes. > > > > Chances are that I'm biased. After all, I'm very active in the scala > > community and a strong believer in the principles behind functional > > programming, though I'd like to think I can see the benefits (and flaws) > in > > both paradigms. > > > > I'd be interested to know the general opinion. Is functional programming > > still widely considered to be "abstract nonsense"? > > > > -- > > Kevin Wright > > > > mail/google talk: [email protected] > > wave: [email protected] > > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] 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.
