Scala: A Postfunctional Language
scala-lang.org
scala-lang.org
Lisp, Python, C++, Perl, it's a pretty well-populated space and nothing in that article leads me to believe that there's any particular innovation in the paradigm arena there. That is not to say the language itself is good or bad, just that this article is based on a really weird premise.
Another example is their rich collections library, which contains mutable and persistent immutable versions of the standard data structures, and exposes them all through very clean OO abstractions. None of the above languages except maybe clojure even has such a rich collections library built into its standard library, and clojure's dynamic typing allows it to ignore some of the issues that come with designing a clean collections interface.
Of all the languages I have used extensively, Scala has the most functional features by far, and it is in this sense that Scala can claim to be a leader in helping functional features become more mainstream and make up new terms like "post-functional" :).
I think the recent popularity of Scala and Clojure, vs other languages that mix the OO and functional paradigms, really come from one thing and one thing only: Scala and Clojure run on the JVM. Everything else is really secondary.
Well, there's that and some kind of successful marketing effort going on. Unfortunately, it's not easy to study exactly why "buzz" builds up around certain languages. Clearly Java and C# had whole corporations' marketing departments behind them, so that probably didn't hurt. Ruby and Python made "Perl sucks so you should program in us instead" in to a successful mantra (you know what they say about repeating a lie often enough..).
Clojure and Scala don't really have the same things going for them, but they are buzzword compliant, mixing OO, functional programming, and the JVM together. Programmers hear that and it sounds sexy, so they jump on board.
Now the question becomes more of whether that initial buzz can be converted in to long-term success for the language, which depends less on language features than on the language's community and on further marketing (which, of course, may depend on having "killer apps" and what companies, projects, and personalities they can get on board).
Scala is the first language I've seen where the OO and functional features are on an even plane and even play nicely together, and where the community is accepting of both styles of programming.
Clojure has a couple major things going for it. One is that, to me and at least a few other people, it feels like a well-designed tool. I constantly get the sense, when programming in Clojure that Rich Hickey understands what I want to do, and designed a tool to make it easier.
The other big advantage is its focus on concurrency and parallelism[0]. Clojure is built around constructs designed to make concurrent and parallel programming easy. All the data structures are immutable, but relatively efficient. The built-in constructs for coordinating state changes are very well thought out. These features could be added as libraries to most languages, but having them built means libraries will use them too, and the syntax is nicer.
[0] They're not the same thing: http://ghcmutterings.wordpress.com/2009/10/06/parallelism-co...
I didn't say there was no innovation. I said the idea of "post-functional" doesn't seem to make any sense when we already have a perfectly good word. Merely having a slightly different emphasis on which the of the multiple paradigms are dominant in which places and being arguably a better selection for some purposes for some people is hardly worth a new word.
Besides, "post" functional rather implies that functional has had its day and is now played out. Modern functional (immutable variables, very strong type systems, etc.) hasn't even had its day; at best it's currently at the "hitting snooze on the alarm" phase of penetration. It's about twelve metaphorical hours early to be babbling about "post-functional".
If you haven't seen any of the Rich Hickey videos on InfoQ, particularly "Are We There Yet," I can't recommend seeing them more. It sounds like you might be following a similar path to mine, and I can't recommend Clojure more highly.
In the meantime though, enjoy your Scala trip - I did! :)
Scala definitely has more expressive power than Java, but I'm not convinced it's better than other functional languages.
I'm still searching for the optimal language for web app development.
I think that above sentence could be translated to "I don't like that article X makes point Y. While the article is right and point Y is in fact true....".
I'm not a Haskell expert, by the way, but reading the article I felt it didn't demean the language in any way. Pure functional languages are really boring. They can't even print anything to the console!
This is, however, a fairly minor technical point. More importantly, I feel that the division the article's author makes between two definitions of functional programming is misleading. "Functional programming", just like "object orientation" and "imperative programming" and "logic programming" and "structured programming" and every other "paradigm", is not a term with one or even two well-understood clearly separated definitions; it is a term for a grab-bag of features, tendencies, and patterns of programming languages. The world of FP isn't divided into people who think that only absolutely pure languages should be used and people who think that any language with first-class functions is okay; it's a continuum. The author just happens to be further towards the "anything goes" end of the spectrum than the authors of the articles he is replying to.
Use of unsafePerformIO (or any other unsafe function) should rarely be needed in real world programs though.
1. In Haskell, the IO monad is a pure way to represent IO. It does not violate purity.
2. "unsafePerformIO" violates purity, type safety, and half a dozen other semantics as well. It is not part of the language standard, and requires special compiler flags and pragmas to use. Its use (except in FFI) is heavily discouraged, and often involves a proof of correctness to prevent its "unsafe-ness" from leaking.