[erlang-questions] Erlang and/or MPI

[Richard A. O'Keefe]

On 28/06/2013, at 11:13 PM, Yvan Godin wrote:

> Hello,
> you could also give  a try to Racket-lang

There are several things to say about Racket.
First, I was a happy PLT-Scheme user for several years.
There's something for everyone in Racket.

Second, when it comes to concurrency, the model it
offers is the same old same old shared memory with
threads and synchronisation model depressingly familiar
from C, _without_ the safety features of languages like
Concurrent Pascal, Occam, or Ada.

Third, there's some fine print in the guide:
"threads never run truly in parallel, even if the hardware
and operating system support parallelism."
(Section 18.12, about half way down
http://docs.racket-lang.org/guide/performance.html#%28part._effective-futures%29
)
There is a _different_ mechanism for things that can happen
at the same time, and the guide says of that:
"Futures run in parallel as long as they can do so safely,
but the notion of “future safe” is inherently tied to the
implementation. The distinction between “future safe” and
“future unsafe” operations may be far from apparent at the
level of a Racket program."

I spent several hours on Saturday trying to debug the
Complex class in my Smalltalk.  The basics had been
tested long ago, but not the trig and hyperbolic
functions.  The third complete rewrite of the inverse
functions finally did the trick. Here, for example, is
inverse hyperbolic tangent:

    arcTanh
      "This has a pole at (-1,0)."
      ↑Complex
         re: ((4 * re) / (im squared + (1 - re) squared) + 1) ln / 4
         im: (-2 * im arcTan: 1 - im squared - re squared) / (-2)

That's not the actual code; I've cleaned it up a bit.
I wonder if I broke anything?  The number of trivial changes that
leave the code syntactically correct and would satisfy the pickiest
type checker is dizzying.  Even amongst things that usually compute
the right values, apparently tiny changes can make big differences
to the branch cuts.  And this code certainly doesn't take any care
at all with IEEE special values...  I've seen C code for this one
function that ran to a couple of hundred lines, mostly comments
explaining with extreme care every little detail of why the code
was the way it was.

The last round of changes broke certain tests.  For example,
	1 cosh asComplex arcCos closeTo: (0 i: 1)
broke because the answer was coming out as (0 i: -1).  Thing
is, (0 i: 1) cos and (0 i: -1) cos are equal and both are
indeed equal to (1 cosh).  Branch cuts!

*That* is numeric code.

The support or lack of it for 80-bit floats (not normally part of the
64-bit model) is not really relevant.  In the initial stages, the
speed of the generated code is not really relevant.

What matters is HOW MANY DAYS IT TAKES TO GET THE CODE WORKING.

Three things matter here.

(1) How hard is it to *accurately* transcribe a correct description
    of an algorithm into the language in question?

    Here Ada, Fortran, Haskell, and Ada shine.
    Smalltalk and Scheme, for all their other virtues, stink.
    Erlang is somewhere in the middle.

(2) How much do the language & compiler help to *prevent* errors?

    There are all sorts of errors.  The way that Ada and Haskell can
    let you create new distinct types isomorphic to old ones with
    zero-cost conversion between old and new doesn't help for arcTanh
    but can help a _lot_ with array code.  The way Haskell and Erlang
    don't let you smash variables also helps a lot.

(3) How much support is there for *testing*?  

    (Does anyone have a mutation testing tool for Erlang?)