This isn't describing "post-functional", it's just plain old "multiparadigm". Multiparadigm languages generally have a "base" language type that is at least slightly preferred or possibly what everything else compiles down to, with the tradeoff that anything you can't get without being "pure" in some paradigm won't be available to you. In practice this is often a good choice.
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.
I think you give Scala a disservice by saying there is no innovation in it. I have programmed in Perl, PHP, Python, Ruby, C/C++, Java, C#, and even a tiny bit of Scheme and Clojure, but Scala is the first language I have seen to so successfully merge the ideas of OOP and functional programming. For instance, someone at EFPL did their PHD thesis on how to combine the features of functional pattern matching with the OOP concepts of encapsulation and information hiding, which you can read at http://biblion.epfl.ch/EPFL/theses/2007/3899/EPFL_TH3899.pdf.
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" :).
There are many other multi-paradigm languages around... even ones that combine the OO and functional paradigm: OCaml and Mozart/Oz spring to mind.
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).
I don't know about Mozart, but everything I've read about OCaml suggests that the O in OCaml is second class. I've even heard it quoted that the creator of OCaml doesn't use any of the OO features in OCaml and that most people view them as a failed experiment on the language. Pages like http://stackoverflow.com/questions/535481/classic-singleton-... are very telling of the attitude of the OCaml community about its OO features.
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 doesn't really mix OO and functional styles. The only real OO bits in Clojure are for interoperation with Java libraries; I've never seen them used for anything else.
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.
You could write that same comment about most of the languages you listed with only a bit of modification, really. All of them are better at something than the other ones are. None of them are "post-"anything.
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".
I too had done diverse programming until Scala, and the language introduced me to the functional paradigms which I now hold very dear. That being said, I was completely - and unprecedentedly - blown away by Clojure, as, in the Perlis-quote tradition, it completely changed the way I think about programming in ways that Scala did not. I've since decided that if I was going to master a JVM lang, it would be Clojure, and I've had the most fun programming Clojure since my Commodore Basic days.
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! :)
I love that Scala has more expressive power than Java. I did not love the esoteric bits of the language that seem to come from limitations imposed by being JVM based.
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'm a little disappointed that the article suggests that the IO monad makes Haskell impure. While it is certainly true that unsafePerformIO violates purity(and type safety, as well), without it, IO is perfectly pure. It's just that if an IO a value happens to end up in main or something referenced from main, input and output happen. From the language's perspective, the IO monad functions could all be perfectly pure and have no relation to input or output(putStrLn could be a no-op, input functions could always return the same thing). It would be utterly useless for its intended purpose, but there would be no difference in terms of its purity.
"
I'm a little disappointed that the article suggests that the IO monad makes Haskell impure. While it is certainly true that unsafePerformIO violates purity..."
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!
Point Y is in fact, not true. unsafePerformIO is not part of Haskell, the language. It is an additional feature provided by GHC. (Similarly, the typeof keyword and statement-exprs are not part of C, but extensions provided by GCC.) Interesting Haskell programs can and usually are written entirely without use of unsafePerformIO.
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.
unsafePerformIO is part of the the Haskell 98 Foreign Function Interface, which is "An Addendum to the Haskell 98 Report". (See chapter 5 Marshalling <http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise5.html...) All haskell compilers support the foreign function interface, and it will be a required part of the next haskell standard.
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.
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.