Languages like scala are ideal for business applications in my experience at least. Unfortunately, I cannot show you these real world business examples

Same old tired stuff. “Your example code doesn’t solve my business problem so it’s worthless.”

>I find it rather amusing that most functional examples are not about a business domain but about … functions. And people deduce from there that functional languages are better suited to express functions. Doh! Who would have guessed.

What business domain does not have lists and sets of things? What business never needs to search, sort, sum, fold, spindle, and mutilate those collections? If nothing else functional programming already brings a nice win for this important bit. But hey, if most of your business domain is better modeled with OO style objects and imperative code, no problem – Common Lisp, OCaml, and Scala can do that too.

>Functional programming is not additive, it is subtractive. It removes operations ,

In the impure sense of the word functional it’s additive. It adds functional composition, closures, etc. You mention ML, lisp, and Scala in your post – all of these languages allow mutable state and IO side effects. Scala in particular makes it just as trivially easy to do as Java. Some lisps do, too.

>IHowever, invariably the C implementation is real quicksort, whereas the fp implementation is *mergesort*

Factually incorrect. The functional sort you are seeing is the non-in place form of quicksort. It has the same time complexity as in-place quicksort – O(n^2) worst case – but a different space complexity. Mergesort, on the other hand, has the better worst case time complexity – O(n log n). And, believe it or not, there’s an imperative form of mergesort on linked lists with O(1) additional space complexity.

> Also, while quicksort is not *asymptotically* worse than mergesort

Absolutely it is asymptotically worse. See above about O(n^2) vs O(n log n). Quicksort has many advantages, though, so for most reasonably sized, somewhat randomly ordered data sets in mutable arrays, quicksort is in practice faster. But I will say this again, if you are about asymptotic time analysis then quicksort is worse.

>Really the nice things about scala, ml, lisp, etc are features that can and probably *will* be implemented in more mainstream languages.

How ’bout a general expression orientation as opposed to a statement orientation? Why do we need both “if” and the ternary operator in all the C offspring? Will that kind of thinking come in a mainstream language? Yup – when a mainstream language is functional (even if impurely so).

> C already has always had first class functions.

C’s functions are not first class unless by “first class” you mean “distinctly second class.” Function pointers mean that top-level functions can be treated as values, true, but, unlike truly first class types of values like integers, you cannot create a new C function at runtime by say combining two other functions.

> What makes a FP language an FP language is that it makes writing procedural code either impossible, or in the case of an *impure* functional language, just really difficult,

Not so. Where is it written that an impure functional language must make its imperative side more difficult? A functional language does make writing side effect free code easy – but that doesn’t mean side effecting code need be any harder. Again, check out Scala. The syntax for doing side effecting stuff is pretty similar to Java’s – e.g incrementing x by 100 is just “x = x + 100″ or even “x += 100″.

Also, imperative programming languages only have native support for one kind of side effect (destructively changing the state of the world) whereas a bit of monadic sugar allows a language like Scala or Haskell to cleanly deal with things that a imperative programmer wouldn’t even understand as side effects. But that’s a discussion for another time and place.

This will not create the intermediate array, but will calculate the mapped element when needed (if I understand it correctly). Of course there are tradeoffs for both versions.

println(”sum = ” + args.foldLeft(0)(_ + _.toInt))

It is a lot more concise, and I thought about doing it this way, but I wanted to use the map(…) function, something which has taken almost as much flack as fold.

You could do:

println(“sum = ” + args.foldLeft(0)(_.toInt + _.toInt))

Is there a way to lazily map the toInt over the array to prevent repeating the call to toInt above?

Functional programming is not additive, it is subtractive. It removes operations , i.e. operations with side effects. In practice all nontrivial programs really *do* need side effects and *very often* this means that almost all functional languages aren’t *really* functional languages, they just make manipulating state more *annoying*, not impossible.

In a real functional language, you *could not* implement a quick sort. I’ve seen quite a few FP advocates claim to write quicksort, and compare it to a C implementation of quicksort. However, invariably the C implementation is real quicksort, whereas the fp implementation is *mergesort*. Quicksort requires a mutable vector to get its performance boost. I would *assume* that everyone can tell the difference between two totally different sorting algorithms with different complexity, but the examples stay out there for some reason anyway…

Also, while quicksort is not *asymptotically* worse than mergesort (quite the opposite, just quicker for the common in memory and cache case), there are plenty of algorithms where a pure functional implementation is necessarily some higher order polynomial running time than the case possible with mutable state (think dynamic programming). I think everyone can agree that’s the sort of performance decrease that isn’t acceptable just to get a nicer looking language.

Really the nice things about scala, ml, lisp, etc are features that can and probably *will* be implemented in more mainstream languages. C already has always had first class functions. Closures are planned for c++ sometime in 2009. However, those things are not functional programming. What makes a FP language an FP language is that it makes writing procedural code either impossible, or in the case of an *impure* functional language, just really difficult, like how Ocaml supports procedural and OO programming, but makes the syntax ugly intentionally.

I recently started learning Scala to and have started my first project with it, a visual interpreter that uses a Swing based interface instead of the command line (http://code.google.com/p/scalide/). I agree with what you are saying when I first started I would use a lot of while and for loops. Now I find myself thinking about how to write a combination of calls to filter / map / fold etc… and find them easier to read than imperative loops in several cases.

The pattern matching, actors library, type inference, and drive to keep data immutable are really nice too.

Ben

Google is in the business domain, they produced MapReduce for a real business problem, and they are now reaping huge benefit. MapReduce *is* functional thinking. The issue isn’t whether an imperative or functional implementation of quicksort is better; it’s whether you can employ critical thinking to help solve real problems. I enjoy learning and thinking in different programming paradigms. The best way to think outside the box is to never climb in.

Paul