[The competition is] notable for two things: the fiendish complexity of the problem and the absence of functional programming languages in the final results. Top place went to a C++ program, with a Perl team right behind in second. In third place was "Team Celestial Badger" using OCaml and C++. In all there were 81 teams using C++, 67 using C, 66 using Haskell, 64 using Python, 52 using OCaml, 48 with Java, and 35 with Perl. Only 4 tried Erlang (the same number as used Delphi).
According to the report from the competition:
...As far as functional programming is concerned, we must conclude that functional languages didn’t fare too well this year (although in the Top 15 there were five users of OCaml and three of Haskell). Better luck next year!
There were 421 teams, of which 122 used functional languages -- about 29% (which ought to be much higher than their rate of adoption by the industry). Still, over 50% of the top 15 places were won by the teams that used functional languages. It looks like good performance to me.
It says to me that we're still in the early days of widespread adoption of functional programming.
I don't think this is what it says. Functional programming languages are obviously less popular than imperative ones. Maybe functional languages will never be as widespread as imperative languages. However, this competition is just a competition. I doubt it says much about language adoption by the industry now or in the future. (By the way, has anyone heard of Ruby? :) ) If anything, this competition suggests that functional programming languages are quite widespread, given their high rate of adoption by the contestants.
Like Ruby, which had tiny uptake until Rails and 37 Signals boosted it into the stratosphere, functional programming languages lack a reason to use them.
If Ruby lacked a reason to be used before 37 Signals, why did DHH use it to create Rails? He could have stuck with PHP. The reason to use Ruby did exist, even if fewer people knew about it.
"Functional programming languages lack a reason to use them." I don't think that great concurrency, scalability, fault tolerance, distributed programming, hot code swapping, Mnesia, Yaws, and the rest are useless.
(In fact, Amazon has made Erlang much less useless today by announcing the new 4-core and 8-core options for EC2 instance. I can't wait to get my hands on those :) )
Even those who advocate them [functional languages] aren't comfortable enough with them to push on with them in the face of hard problems.
The teams that were comfortable with functional languages did push on them in the face of hard problems: those teams used functional languages in the contest. They took 8 of the top 15 places, too.
I must say that I disagree with the conclusions of the article.
I'll end this posting with a relevant message from the Erlang-questions mailing list yesterday:
> Hi.
> Recently, I have been trying to learn a language other than Java.
> Erlang seems to be ready for the prime time (used in the commercial world).
> On the other side, OCaml seems to be a cool and capable language.
> I want to learn something useful and fun.
> Tell what do you think ?
> (if you are Erlang die-hard, please put this aside ;))
>
When I was evaluating Python alternatives for building the core
technology behind MochiAds I tried out a bunch of languages and Erlang
was the only one that was easy for me to learn and had the right
balance of features, performance, and reliability. A year later we
have about 16 machines running 80 Erlang nodes powering about 16
different "components" of our infrastructure and 4 people working on
it at the moment (originally it was just me). It worked out so well
that we rewrote the server component of our MochiBot service in Erlang
and we've been using it to build lots of internal tools such as our
monitoring software, our single sign-on service, etc. as well. None of
us had previous Erlang experience, but we're all very comfortable with
it now.
After about a year with Erlang, I'm not sure I could part with hot
code loading, light-weight processes, and multiplexed socket IO for
writing servers. Also, Mnesia has been really useful to us to
temporarily store "real-time" data (ram_copies) so that we don't have
to make users wait for it to get batched into the SQL databases. The
distribution stuff mostly Just Works once you figure out how to set it
up (though we did have one bad experience with a network partition due
to a switch acting up, it was recoverable manually).
O'Caml is a useful language too, but for writing a network app I can't
really imagine going with anything but Erlang if you're looking for
redundancy and scale. Unless you want to write your own half-baked
Erlang-like system before even trying to solve something a little
closer to your actual problem domain.
-bob
It looks like functional programming must be good for something.
9 comments:
Hi Yariv.
Here is Mr. Joe Armstrong to me:
-----
Erlang/OCaml/Haskell belong to the same language family - if you learn
any one
of them then learning the next one in the family will be a lot easier
than starting from scratch.
These language differ - but have the same core concepts - the idea of
immutable
state - programming with immutable state is the thing that you need to
learn.
The details of how you do this vary from language to language (you can
use processes
with tail recursion to model state in Erlang, or monads in haskell,
etc.).
I'd start with the language that most suits your problem domain - a
rough guess might
be to think of these languages as follows:
OCaml - use as a replacement for C - good for implementing virtual
machine emulators
tightly coded non-distributed applications.
Erlang - use as a replacement for Java - good for programming
distributed fault-tolerant
applications - good support for multicores/concurrency. Good as a glue
language to
glue together components co-ordinate activities on different machines
etc.
Haskell - use for implementing domain specific languages, symbolic
computations etc.
Asking which is best is like asking which is best out of C++/java/C#
or perl/python/ruby
Languages come in 3-packs - learn any one then learning the others is
easy - similar ideas
different packaging.
/Joe Armstrong
------
Very insightful.
Actually, I decided to go with Erlang.
BTW, thanks for ErlyWeb ;)
It’s an increasingly common misconception that functional languages are innately better at concurrency (ala Erlang).
While Erlang is very good as what it does, this in no way implies functional programming is inherently better for distributed-concurrency. (Of course it doesn’t imply its worse either.)
Smalltalk and others were using messages to handle concurrency for years before anyone had even heard of Erlang. That its designers chose a functional core for Erlang has nothing to do with this.
Frankly I’m getting annoyed that obviously uninformed people keep repeating this rubric.
I don’t mean to offend, just getting tired of hearing and correcting it.
I read the Torkington article differently. His point was that many functional programmers abandon their favorite language too easily. He didn't question functional programming. Rather he observerd that many programmers question functional programming when they shouldn't. He wrote that we need someone like DHH to give the masses the confidence to choose a functional programming language.
The above is just my interpretation of the original article, not my opinion. This however is me:
I don't think you can draw any conclusions from a programming contest named after a functional programming conference. Both the preferred language and the skill distribution of the contestants are heavily skewed.
* Sorry, I meant my last comment to go into the "Questioning Functional Programming" post. Not this one.
I assume you missed this. I found it rather interesting/revealing.
"... considering it's a competition organized by the International Conference on Functional Programming, perhaps the fact that most participants are using C++ is notable... " - Daniel Larsson, a comment on 'Questioning Functional Programming'
That only 122 out of 421 teams participating in a competition hosted by the International Conference on Functional Programming, is bizarre. Its been noted.
Given that the conclusion might not be too far off, though I don't agree with it completely.
I wonder if there is some reverse psychology going on. For example if it were called the "International Perl Sucks Conference" then I'm sure that 99% of the entries would be written in Perl by people aiming to prove that Perl doesn't suck.
I really wasn't sure how to take the linked article, honestly. Read one way, it looks like he's just knocking Erlang & funtional programming. Read another way, it looks like he's saying the only thing holding Erlang & FP back is a strong leader.
And, of course, seeing both of these in parallel makes me wonder if he's just trying to throw some FUD around to get blog hits. ;)
I see you noticed the EC2 announcement as well. How long, do you think, before we see a demo Erlyweb app load-balanced across some EC2 nodes? You know that extra-large configuration looks like an Mnesia-user's dream!
I think one of the things that's missing from both the original article and your article is a treatment of the actually workings of the contest and the appropriateness of specific programming languages. I participated in last year's (9th) ICFP contest but not this year's (and I haven't even looked to see what the problem was).
Speaking for last year's, the first step in the problem required implementing a virtual machine that was intentionally designed to be inefficient and thrash memory. My team started out in our favorite functional language but soon discovered that the lack of support for direct bit manipulation in our language of choice was causing our implementations (because we tried to fake bit manipulation in several different ways) to be so slow as to be completely useless. We then rewrote the vm in C and quickly moved on to the rest of the contest.
It turned out that implementing that vm was only a very small portion of the entire contest and netted you only a few points. However, actually completed that single task meant you were in the top 250 entries because so many people were unable to get it to work.
If I recall correctly, the contest creators eventually admitted that they wanted people to realize that sometimes functional languages are not always the best tool for the job. If we had realized that sooner we would have completed more of the contest but instead we were stubborn and were only able to complete 2-3 more tasks. After (and a little during) the real contest there was a informal competition of virtual machine speed on a benchmark created by the contest creators. I believe the fastest implementations ranked by language were C/C++, OCaml, Haskell although perl may have also been in the running as well.
Does anyone know what this year's ICFP contest was about? Most functional languages tend to be fairly high level, often at the expense of allowing experienced programmers to choose when they actually need really tight control on things like memory allocation. Perhaps this year's contest did not play to the strengths of most functional programming languages. There really isn't just one single tool for every job (even if you lump a whole class of languages together as "one" tool).
@Mark I wasn't aware that Smalltalk is as good at concurrency as Erlang. I haven't used Smalltalk, but from what I know of it it's a minimalistic, dynamically typed pure OO language with late-binding semantics. Most people I've met who have used Smalltalk, love it. However, I've never heard anyone tout its concurrent programming capabilities. I would be happy to learn more about it.
@Antii I guess we read the article's meaning differently. I agree we can't draw any meaningful conclusions about the merits of FP from this contest.
@Mark I think that the title of the competition doesn't mean much if it's open to any programming language. Plus, C++ is functional -- have you looked at Boost Lamba? :)
@Bryan I think his saying "functional languages lack a reason to use them" is a bit stronger than saying "they are great but they need a DHH." Whatever he meant, though, the EC2 announcement came at a fortuitous timing, because it gave everyone a great reason to use functional languages: 4-8 core instances at $0.40 - $0.80/hour :) I'm kind of busy these days, but I think it would be great if someone created an EC2 image with Yaws + ErlyWeb + MySQL preinstalled, and with Tsung to give them a serious stress test.
@Rob I agree that functional languages aren't always the best tools -- especially if you're doing low level coding or if you need to use libraries that aren't available for them. And it's true that functional (and non-functional) languages excel in different areas. Haskell and O'Caml are good for computational/algorithmic tasks, whereas Erlang is strong at concurrency, scalability, etc.
So 29% of the programmers used functional languages and 53% of the successful programmers used functional languages. What can this mean?
Post a Comment