

Scala: A Postfunctional Language - davidblair
http://www.scala-lang.org/node/4960

======
jerf
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.

~~~
sreque
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" :).

~~~
gnosis
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).

~~~
sreque
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-...](http://stackoverflow.com/questions/535481/classic-singleton-
implementation-in-ocaml) 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.

------
ekiru
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.

~~~
sreque
" 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!

~~~
rntz
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.

~~~
iman
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...](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.

------
timwang
For me, scala is too complicated.... now I am reading "programming clojure"
and it is more fun so far

