[erlang-questions] Re: Benchmarks

[Joe Armstrong]

Every hour spend arguing for Erlang is an hour wasted - so I must have
wasted several years :-)

Assume X and Y are different programming languages.

I rarely benchmark X against Y to see if X or Y is better
I usually *know* which is better before I start.

So I'd never benchmarch C against Erlang for doing FFTs since I know
that C would win.

How do I know? - Gut feeling. Even without running the code I could
make a reasonable guess that visual basic is good at making GUIs in
windows and that Erlang is not.

I *do* benchmark program one in X again program two in X to see which
is faster - but this is just engineering.

So is this thread about benchmarking or why you choose languages?

I'll digress and throw in a couple of arguments.

In any *system* the totality of things that must be done to make the
system work is the same (this is the problem).

Now you can either do these things "in our language" or "somewhere else".

C has no memory management and processes (ie no GC) - Erlang has.

In C you have to do the memory management yourself (tricky, horrible code)
and processes - well C doesn't do processes so we'll pass these over to the
OS and hope that it can cope.

The C will be super fast - after all it's not doing any processes stuff
the OS is doing that - and it's not doing memory management.

Problem - the OS self-destructs if we have too many processes --- ooooohhhh.

So in our problem - the C bit runs very fast - but the processes are not
so good (because we shoved them over to the OS) and we can't do dynamic code
upgrade - because neither C nor the OS support this.

Now Erlang - the code is slow (compared to C) - every function call is
through a pointer (why? - so we can change the code on the fly !)  and
we emulate processes (why? - so we can have lots of them and do code
replacement on the fly, and ...)

So In Erlang yes we are slower than in C - but in C we haven't done all
the things we need to do to solve our problem. We've pushed some of
the tricky things into the OS (like processes) or ignored them
altogether (like hot code replacement).

So to solve our problem we must do all these things - if you can't do
them in one place you must do them somewhere else.

Erlang was designed to provide an off-the-shelf solution to all the
things we needed to do to build a fault-tolerant, soft real-time
distributed telephone switch control software with hot code replacement.

Erlang was not designed to be as fast as C at doing things that C is good
at.

Erlang was designed to make the things that are extremely difficult to do
in C but which need doing anyway *possible* to do at all. Not easy to
do but *possible*.

So if you want "all the goodies" - like hot code replacement - fancy
error handling etc. - and you want to do it in C (or some other
language) then good luck - if you start now then we'll be 15 years
ahead of you

Let's change track ...

For years I used to argue why Erlang was (technically) great - but
the problem is you can *never* win an argument. You cannot convince me
of anything - I'm the only person who can convince me.

If you totally outargue somebody, they will feel pissed-off and do the
opposite of what you had argued for ..

Strangely, winning a technical argument, though long careful arguments
rarely had the desired results, other forces are at play. So let's
look at the most important of these ...

Hypothesis:

  Choice of language has nothing to do with "technical stuff" (ie
  benchmarks etc), but has to do with "non technical stuff".

Arguments for Erlang should be aimed at the "not technical stuff".

Programmers *love* the technical arguments - but this leads to an
escalation in tech. arguments. Increase the pressure and the
resistance will also increase.

No movement in an argument (ie away or towards being in favor of
Erlang) means you have reached equilibrium.

Equilibrium means:

     Pressure to use Erlang == Resistance to use Erlang

     (ie is exactly equal to - this is why there is no movement
      towards or away from Erlang, ie no decision)


Increasing the pressure to use Erlang just increases the reasons why
you should not use Erlang - the technical arguments just get more and
more intense, and you're still in equilibrium.

To convince anybody to use Erlang you have to break the equilibrium.

Instead of increasing the pressure try reducing the resistance.

In my experience most resistance is due to non-spoken non-technical
reasons.  The primary reason is usually fear of failure (FOF). FOF is
a very strong motivating force.

One excellent method of reducing FOF is tell "success stories" - tell
'em about the successful Erlang projects - how quickly they wrote the
code how quickly they crushed the opposition, the great amounts of
money they made (:-)). Tell them about the failures that using *some
other language* had in similar circumstances.

Perhapse the project will fail if they do not use Erlang, and
what if the opposition does it in Erlang before us and we're bankrupt ...
there's a thought ...

People like stories, so tell then stories of Erlang successes - this
will reduce FOF.

/Joe



On Wed, Jan 13, 2010 at 4:08 AM, Bob Ippolito <bob@REDACTED> wrote:
> It's much lower if you have to spend hours justifying why Erlang is a
> better choice than X.
>
> On Wed, Jan 13, 2010 at 9:48 AM, Henning Diedrich <hd2010@REDACTED> wrote:
>> Accepted on account of today's news.
>>
>> What's the number then, Bob?
>>
>> Henning
>>
>> Steve Davis wrote:
>>>
>>> I'd like to offer another benchmark:
>>>
>>> Net income in dollars generated by the application / hours of
>>> development and maintenance time.
>>>
>>> /s
>>>
>>> ________________________________________________________________
>>> erlang-questions mailing list. See http://www.erlang.org/faq.html
>>> erlang-questions (at) erlang.org
>>>
>>>
>>>
>>
>>
>> ________________________________________________________________
>> erlang-questions mailing list. See http://www.erlang.org/faq.html
>> erlang-questions (at) erlang.org
>>
>>
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>