It's just the way cycles work. Few years of over exaggerated OOP hype, then few years of over exaggerated functional hype.
Some people just like taking things to extremes and seeing things in completely polarized viewpoints - good vs evil - rather than recognizing that both are great in different circumstances.
It's a lot less tiring (and more productive) to use whatever tool fits the job best, rather than whatever tool is currently in fashion IMHO.
I think it's overloading (punning on static type of the same function, operator, or method name) that makes explicit type declarations more often necessary in Scala than in Haskell or ML.
I agree 100%. Despite Scala's hype and functional influences, it's most exciting to me simply as another option for the JVM, and another "tool in the toolbox."
Assuming you consider something JVM-based an eligible tool for a job, you have a wide variety of programming languages on a common platform to pick from. While it's probably not a good idea to apply them all in a project, it's nice to know that in the future the probability of you being able to reuse code in disparate languages increases.
Scala isn't really all that FP. Marginally more so than, say, Perl. It's more like: most of the advantages of Ruby, Java and Erlang in one place, with very extensible syntax.
You're not going to get "most of the advantages" of Erlang in a language that includes imperative OOP and runs on the JVM. The reliability of Erlang is built around features like:
* Upgrading code while it's running. In Erlang, this works because all program state is explicitly passed as parameters to a tail-recursive main loop, so there's a clear place where one version of the code can cleanly take over the state from a previous version. This won't work in a language with singletons, and mutable objects that mix code and data.
* Modularizing a program into tens or even thousands of lightweight shared-nothing processes. Erlang can do this efficiently because of key properties of the language and VM. For example, the entire language and all of its libraries use persistent or copy-on-write data structures, so that processes can share memory without sharing mutable state. This won't work in a language that's interoperating with Java libraries, and whose own data structures aren't 100% immutable.
That's my issue with Clojure as well. A language that provides and encourages use of a foundational feature X doesn't seem ideally coherent if it depends on usability provided from (Java) libraries which are unable to make use of that feature X.
Yes, but Scala is a less polished FPL than Haskell. If you're using Scala instead, it's because you love OO, want convenient global mutable state, aren't interested in the purity (read: B&D) of Haskell's effect system, or want to use Java libraries.
I like to think the shift is occurring, but at times I feel like my view comes from spending most of my time in an insular community that finds FP exciting. When I meet with other programmers I become less hopeful.
Or at least the parts of the world that doesn't bill by the hour/LOC..