

Functional languages will rule (but not this year) - harryh
http://goodstuff.im/functional-languages-will-rule-but-not-this-y

======
Homunculiheaded
It's somewhat funny that this article seems to miss the very practical rise of
functional programming style in JavaScript, especially with the rise of
libraries like underscore.js

Of course JavaScript has some pretty severe limitations as far as functional
programming goes, the biggest being really cumbersome lambdas, and a lack of
implicit return. If you try to program in a functional style in JavaScript
you'll be fighting the language more than you'd like. However both of these
issues are remedied in CoffeeScript.

As someone who was a lisper before getting into web development I'm really
surprised to see lambdas, closures, pattern matching/de-structuring bind, let
statement equivalents and more be part of a language that is not even talked
about too much as being lisp-like or functional. Also important is that
CoffeeScript's main selling point is that it's practical and more sane then
JavaScript, not that it's functional or lisp-like. At the same time
CoffeeScript is probably the closest thing I've seen to a (potentially)
successful lisp-without-parens

Functional languages will gain serious traction, but I think it will be when
their users find their features convenient and helpful (coffeeScript) rather
than interesting/mind-blowing/etc (scala, haskell, erlang..)

~~~
mb21
I think I'm currently in the "I just don't get it camp" when a significant
deficit of a language is the lack of implicit returns. Is typing return that
bad? I quite like the readability. Is it that you can only return once per
function? I already do that, but recognize that some developers don't. If
that's part of it then a lot about these languages is to keep the riff-raff
out? If that's true then I think we can probably all agree they will never be
mainstream since in most cases mainstream == rif-raff.

~~~
silentbicycle
It's not about readability or "keeping the riff-raff out". Needing to type
"return" itself is a minor detail, but explicit returns are a strong sign of
having statement-oriented semantics, rather than expression-oriented
semantics.

In languages based around statements, things are done for their side-effects.
Returning a value is itself a kind of side-effect, hence an explicit return
statement.

In languages based around expressions (Lisp, ML & Haskell, APL, etc.), the
_language itself_ gently encourages side-effect-free programming. In Scheme,
for example, you usually use a _begin_ block when you need to do things for
their side-effects. While it doesn't prevent side-effects entirely, it does
make them stand out, and adds a subtle pressure against their overuse.

~~~
mb21
I don't think I'm quite there yet. Are you saying having to type return vs. it
being implicit encourages side-effects in programming? How does this relate to
the begin block?

~~~
silentbicycle
Mostly, yes. "return" isn't the cause, though. Just a sign that the language's
_primary concern_ is the side-effect of running statements, not their values
(in which case, _having_ a result value would be expected, not a special
case). A sign of different priorities in the language design: functional-by-
default or imperative-by-default.

The begin block is how one indicates "do this, ignore its value (just do it
for its side-effect), then do that and return _its_ value" in Scheme. Some
forms have implicit begins, however.

I may just be repeating myself, but I hope phrasing it slightly differently
helped. What made it clear to me was learning Scheme and (especially) OCaml,
then going back to Python and programming in a functional/expression-oriented
style, seeing the subtle ways in which the design of the language resists it.
Lua is more friendly to functional programming than Python (it has tail-call
optimization, for starters), but those explicit returns still show it isn't a
perfect fit.

------
ankrgyl
His arguments about the existing functional languages can be roughly split
into two categories: 1.) Languages refuse to make compromises and therefore
are obscure (Haskell, Erlang) 2.) Languages are crippled by making too many
compromises (F#, Scala).

He presents good arguments about why both types of languages can't currently
break into the mainstream, but it unfortunately seems like these options form
a partition of the possibilities (i.e. a functional language must fall into
one of the two). If this assumption is correct, then by his analysis _no_
functional language can break into the mainstream.

I'd love to see a discussion over whether or not that assumption is valid, but
for now let's assume it's true. I don't think the languages are the problem.
Instead, I think it's the general momentum and consensus of the community.
Without books like Learn You a Haskell (<http://learnyouahaskell.com/>),
Haskell would be an order of magnitude more difficult to begin learning. I'm
still trying to figure it out, and there are a lot of examples of topics where
a similarly good tutorial would ease my learning. Eventually, as the language
gains popularity, more and more such work will exist. Furthermore, if popular
companies demonstrates that it's a great choice, more people will want to pick
it up. If all this stuff happens, our intuitions will grow and adapt to make
such a language a natural choice. In summary, the future of functional
languages depends _more_ on our understanding and promoting them as a
community, as opposed to the languages themselves.

~~~
evangineer
You make an excellent point about the primacy of the community. I can't
remember where I first came across the idea that languages are communities,
possibly Richard Gabriel's Patterns of Software.

As someone about to embark on the Standard ML learning curve (motivated
primarily by Ur/Web - Ur is a ML-like language), it is striking that the SML
community is fragmented to the point of non-existence (not even a Planet SML,
the sml-list is dead, & the SML subreddit is pretty lifeless).

Looking at Alice ML which has significant advancements over both Objective and
Standard ML, it has great features, but no momentum which isn't helped by the
fact that there hasn't been a release since 2007.

~~~
ankrgyl
I learned a lot of SML in college, and it is really a great language. In my
opinion it has the best syntax and REPL of any language I've used.

But Haskell has a much better chance of becoming main stream. The type classes
allow things like drop-in, easy-to-use hash maps and a simple, type-safe print
statement (SML's requires explicit string conversions). Furthermore, GHC
consistently pushes modern features; my current favorites are the _extremely_
performant userspace threads (managed by epoll). From what I can tell, the SML
folks are more focused on PL research projects than trying to implement a
standard library, which is completely fine.

If everything goes well and we as a community build intuitions for strong,
static typing, one of these good languages (IMO probably Haskell) could end up
as the next Python.

BTW, if you're looking for resources on learning SML, I'd look at Bob Harper's
books (<http://www.cs.cmu.edu/~rwh/>)

~~~
evangineer
Thanks, I had already downloaded the latest version of Harper's Programming in
Standard ML.

I think you're right about the SML folks' focus on PL research.

------
cageface
This is a refreshingly honest analysis from someone that has a lot of skin in
the game. I completely agree on both points. First, the functional paradigm
_is_ important and a step forward for most problem domains. Second, none of
the current crop of functional languages is going to truly break into the
mainstream.

I think it's more likely that we'll see more and more functional techniques
trickle down into mainstream languages than it is that we'll see a pure
functional language adopted as-is. C++ just picked up lambdas, after all. I do
regret somewhat my dalliance with FP over the last decade though. If I'd
invested that time in mastering DSP or graphics programming instead I'd be
better off overall.

~~~
evangineer
There is a definite functional trickledown effect going on with mainstream
languages.

I have the suspicion that the breakthrough functional language will be like
CoffeeScript in that it compiles down to Javascript taking advantage of the
high performance Javascript runtimes and the functional core of Javascript.

------
hugh4life
One language he left out was Nemerle... I like it more than Scala...

<http://nemerle.org/About/>

F# 3.0 will have type providers which provide functionality similar to Gosu's
open type system.

The Future of F#: Data and Services at your Finger Tips

<http://channel9.msdn.com/Events/PDC/PDC10/FT12>

<http://i51.tinypic.com/300chly.jpg>

Not new, but Websharper for writing Javascript in F# is pretty cool...

<http://websharper.com/samples/WebGL> <http://websharper.com/samples/Canvas>

~~~
evangineer
Nemerle's been around for years and I don't see it getting any traction,
especially in the shadows of both C# which has been cherry picking functional
features & F# which has the backing of Microsoft.

------
T_S_
Is the Haskell Singularity approaching?

[http://www.reddit.com/r/haskell/comments/hezgk/haskell_singu...](http://www.reddit.com/r/haskell/comments/hezgk/haskell_singularity_approaching/)

------
kumarshantanu
Mention about Clojure (which is more functional than Scala) is curiously
absent from the blog post.

------
kjksf
The article contradicts its own title.

The author claims, in the title, that functional languages will rule, some
day.

Then he does a tour describing each would-be-ruler functional language
(erlang, haskell, ocaml, F#, scala) and explicitly says that all of them will
remain niche languages i.e. will not rule.

~~~
harryh
His thesis is that none of the current crop of functional languages will rule,
but that some new functional language not yet invented (or widely known) will.

~~~
gaius
A language can't come out of nowhere, because it won't have the critical mass
of people, libraries, etc to be usable for "real work". IF a functional
language is going to be mainstream in only 5 years, then there are a
significant number of people using it today, and it will be generally known in
the FP community.

Even F# was a) in beta for years b) solved the library problem by piggybacking
on C# and c) had a critical mass of OCaml users who could jump straight into
it.

------
gar1t
A power and persuasive essay on the essential merits of functional languages.

Erlang is ugly

Haskell is beautiful, like Karate

OCaml is impenetrably unexciting

F# is polished. And mainstream

Scala is a tour de force of concepts. Tiobe Top 20

~~~
evangineer
I wonder if the author would feel the same way about OCaml if he had come
across it before Scala.

I suspect not somehow.

~~~
fhars
I came to scala because it is in fact an acceptable ocaml that runs on the
JVM.

~~~
evangineer
Kind of my point. I think he's meh on Ocaml because Scala has the same
features & runs on the JVM, seeing it after using Scala wouldn't be very
exciting. However Ocaml was around years before Scala.

------
patfla
All the machinery of functional programming languages that's creeping into
non-FP languages is great. I actually think that FP one-liners are usually
_more_ transparent than the corresponding non-FP loop.

However if I'm not mistaken an important point of FPLs was to eliminate side-
effects and that the ultimate goal was program verification (not validation).
I.e. you could prove a program correct in the mathematical sense. That seems
still a long way off.

~~~
evangineer
The trend I'm seeing isn't towards verification by proof but leveraging the
type system to ensure that the compiled program is correct and secure. Both
Opa and Ur/Web take this line.

------
smackay
So how does the tooling problem get solved? This would seem to be the limiting
factor presented in the article not necessarily how opinionated the language
is.

~~~
evangineer
TypeSafe have money in the bank and a serious commitment to fixing the Scala
tooling for Eclipse.

~~~
lurker19
Maybe 3rd time will be the charm.

