You said about FP in Scala and show examples with currying, matching… But show they as syntax-forms embedded in language (Ocaml). Where you have funcs, you have currying. Benefits of pattern matching are very controversial. It’s very weak and uncertain attempt to repeat Prolog (even _ is used!). But in Prolog this is the principal other feature: due its bi-direction (absolutely another computation model of Prolog). In FP pattern matching looks naive and inappropriate. And it’s easy to be implemented as equals()/__eq__() overloading and done with “if … else if…”/”switch…” blocks – more control, more readable and the same number of lines IN ANY language! :)So, Scala has all real FP features instead of syntax tricks of them. What is the OOP? Paradigm or the way of code organization (structuring)? And what is the FP? Paradigm? Or code organization (with syntax sugar, tricks, like matching which is not real matching)?In OOP code organization ideas and paradigm are very confused and close (we want to have state – so record, we want to have functions manipulated this state (and avoid names with structure’s name prefix) – so methods, we want to reuse code – so inheritance. Or this is the paradigm?:) ) Cut TYPES SYSTEM from FP and you’ll get all what you have in any another modern language. Well Scala is FP :) Look, closures are bounded state of args, and programmer doesn’t know where is this state, how to change it… But this is the delegates – state is the class fields, method pointer is the delegate – closure. Where is the border? What model is the better? OOP, IMHO is more readable and controlable (and longer as code lines). You want pure FP? No problems! Write in C/C++ in pure FP mannier! In D you can add “pure” modificator to funcs even! You want lazyness, you have them in Scala, D, Tcl even! So, today, border between OOP and FP is thin. Principally we have 3 paradigms only: declarative (predicate calculation), applicative (Lisp – code is transformable data, code is explicit AST) and imperative (FP, OOP…). And todays many-many language has features of FP, FP languages has OOP features and both are different only for compiler creators. So, is the Scala FP?

The corresponding code in Scala would be def x(a:Int) = (b:Int) =< a + b
def y = x(1)
y(2) // 3

Well, I think the problem with the original article was that:

a) The author didn’t really knew Scala and wrote really ugly Scala code (instead of code as clean as his OCaml examples) and based his whole claims on it. He didn’t make any effort to correct his examples.

b) The author thought that “curried-by-default” == “more functional”, although there are exist just as many undisputed functional languages which are not curried-by-default. OCaml, Haskell chose curried-by-default; SML, Scala chose uncurried-by-default, so this is a non-sequitur.

c) The author had the misconception that OO and FP was somehow mutually exclusive. Now, in 2011, it is broadly established that this isn’t the case, Scala was just the first language where the language designer had invested some deeper thoughts on how to do the integration OO-FP integration right.
No one ever claimed that Scala is less OO because it is also functional; why should it be the other way around?

There might be other valid reasons, like better Java interop, which might make Scala code not as succinct as Haskell code, but sadly this point hasn’t played a role in the following debate.

val foo_fun = (a:Int)=>(b:Int)=>a+1
// > foo_fun : Function1[Int, Function1[Int, Int]]
val bar_fun = (a:Int, b:Int)=>a+b
// > bar_fun : Function2[Int, Int, Int]

is roughly equivalent to Haskell’s:

foo_fun a b = a+b
bar_fun (a,b) = a + b

Also, Scala actually has a very clean currying syntax.

val baz = foo_fun(3, _)
print(baz(2))
val quux = foo_fun(_, 3)
print(quux(4))

main :: IO ()
main = do
  let baz = foo_fun 3 in print baz 2
  let quux = \a -> foo_fun a 3 -- Scala wins in this case.
    in print quux 4