

The Erlang Challenge - tb
http://yarivsblog.com/articles/2008/02/08/the-erlang-challenge/

======
yariv
I must say that I am taken aback by the title you used to link to my article.
I did _not_ mean it as a snide response to the Arc challenge. I thought the
Arc challenge was pretty cool, and I replied to it with an Erlang
implementation -- you can see it here <http://arclanguage.org/item?id=722>. If
it come across as snide, then I didn't communicate it as I had intended. The
reason I said it's in the "spirit" of the Arc challenge is that the Arc
challenge highlights what Arc is good at, and the Erlang challenge highlights
what Erlang is good at.

~~~
neilk
Interesting. I thought you were making a sly joke too.

I guess this just proves people read their biases into whatever they
encounter. Like many, I thought the Arc challenge amounted to a test of how
much a language was like Arc (guess what, Arc wins). So I assumed your post
had to be satire.

And -- maybe the requirement of spawning a million threads doesn't seem like a
cruel joke to you, but it is to anyone who has to work in a language other
than Erlang.

~~~
yariv
Apparently, I should have been more sensitive to the way people would
interpret this challenge and picked my words differently.

A few other languages, including Scala and Stackless Python, have lightweight
concurrency capabilities. AFAIK those languages do allow you to spawn millions
of processes (or actors), but they don't handle garbage collection,
scheduling, IO, distributed programming and native code interfacing as well as
Erlang does.

~~~
neilk
I don't know if there's anything different you should have done.

If you discuss two different computer languages in any piece of writing on the
internet, a large majority of the readers will assume you are advocating one
over the other. I've seen this so many times already.

I'm just sad that I fell into the same trap.

------
mechanical_fish
I'm guessing that very few people here on news.yc are qualified to compose the
Cobol Challenge: the problem for which Cobol is uniquely qualified to provide
the elegant solution.

Of course, the budget and the legacy code will have to be a very explicit part
of that problem.

Meanwhile, this Erlang Challenge only tends to emphasize my impression --
which is just a stereotype, really -- that Erlang is _certainly not_ the
hundred-year language: it's a special-purpose language that is brilliant at a
narrow class of problem. I'm convinced that, if I have some process that I
want to spread across half a million processor cores, I should ask my
company's Erlang guru to work on it (because, come on, if you can afford half
a million processor cores you can afford at least one Erlang guru). What I'm
not yet convinced of is that a world with N programmers who work in general-
purpose languages needs more than (0.005)N Erlang gurus.

The challenge of the Erlang advocate is not to convince me, over and over,
that Erlang wins its class; the challenge is to convince me that Erlang's
class of problem is so important to my life that I should study Erlang rather
than vascular surgery, or television repair, or other obscure technical skills
that I don't know that much about.

~~~
yariv
Just because Erlang is very good at solving a certain class of problems,
doesn't mean it's inferior at solving general computing problems.

The Erlang challenge highlights what Erlang is good at, but it's not meant to
convince you that Erlang is good at everything. I've never claimed that this
challenge proves you should use Erlang to solve any problem that comes your
way.

~~~
mechanical_fish
Well, okay, it sounds like I have therefore interpreted the Erlang Challenge
correctly: it highlights what Erlang is good at. And that's fine. There's
nothing wrong with ass-kicking special-purpose programming languages, and I
look forward to the day when I will actually spend ten minutes learning Erlang
and be able to start _discussing_ it instead of just marveling at it from
afar.

The thing is, the Arc Challenges (I presume there will be others...) _are_
explicitly intended to convince us that Arc is an awesome language for solving
general computing problems. (Of course, they're also tools for designing Arc:
If Arc proves unconvincingly awesome at any point, the plan is to twiddle its
design knobs until the awesomeness returns. We will see how it goes.)

When you adopted the Arc Challenge's title and style, it left me wondering if
you were aiming at the same goal. If you were, I wanted to invite you to shoot
again, because you kinda missed. However, it seems that "convincing me that
Erlang is good at everything" was never your goal at all, so I'm sorry to have
interpreted it that way. (My interpretation may have been unduly influenced by
the original title of the submission...)

~~~
yariv
I guess that you and I had different interpretations of the Arc challenge. I
thought it was intended to demonstrate how easy it is to implement multi-page
flows in Arc by binding closures to links and forms. I didn't think it was
intended to convince people that Arc is a good general purpose language
because its scope was so narrow (if the challenge were to build a search
engine or an image editing tool, it would have been a different story).

By the way, although I didn't expect people to extrapolate from the Erlang
challenge that Erlang is a good general purpose too, I do think that it is, at
least for building backends for a wide range of applications. I wrote a
followup on my blog to the Erlang challenge where I listed some of them.

