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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
