[erlang-questions] Question about Erlang and Ada

[Martin]

Hi everyone, Martin here

Just want to say thanks to all of you for your good answers. :-) I should have written Ada Spark because that was what I meant. Think I get the picture now. I will use all three even if it's expensive. Maybe four... must be a way to squeeze in my beloved Prolog without making it unstable. The reasoning functions are so easy to program with that. Going to make it open source in the future. Maybe I can post a link here when it's in alpha?

Big thanks 

Martin 


________________________________________
Från: Richard A. O'Keefe <ok@REDACTED>
Skickat: den 14 december 2015 23:47
Till: Martin
Kopia: erlang-questions@REDACTED
Ämne: Re: [erlang-questions] Question about Erlang and Ada

On 12/12/2015, at 8:02 pm, Martin <skribent_har@REDACTED> wrote:
> I have a project in the field of robotics were I consider using Erlang and SWI Prolog for a real time system.

Erlang is described as "soft real-time".
SWI Prolog isn't real-time in any sense.  It has some rather strange
thread support, but then, so does C.

>  However since I am open for all kind of input, I wrote to a company that sells Ada solutions (since the language is made for critical systems) and asked them to make a case for Ada vs Erlang. They wrote back that they didn't know enough about Erlang to comment on the "let it crash" philosophy but they wrote that:
>
> Ada philosophy is "build is correct". That's achieved through an extensive specification language (including contract-based programming) together with dynamic and static verification techniques.

Well, kind of.  There was no contract-based programming in Ada 81,
Ada 83, or Ada 95.  Ada 2012 *does* support it.  But for years if
you wanted "an extensive specification language", SPARK was what
you had to go for, and SPARK doesn't include all of Ada.  (No
pointers and no exception handling, for example.  See
http://docs.adacore.com/spark2014-docs/html/ug/spark_2014.html
for details.)

> So my question is:
> Do you think that there are times when Adas philosophy is better then Erlang, in a real time system, or is  the Erlang model always better?

I think you are setting up a false dichotomy here.

One of the core features of Erlang is that processes
cannot touch each other's memory, so that processes
communicate by a form of message passing with a kind
of selective receive.  Erlang programs can be carved
up with processes running on different machines with
very little impact on the source code.

One of the core features of Ada was that tasks
cannot change each other's memory, so that tasks
communicate by a form of message passing with a kind
of selective receive.  Ada programs can be carved up
with tasks running on different machines with very
little impact on the source code.

Ada 95 added 'protected records' which are 'monitors'
in the traditional (not the Java) sense, but this doesn't
really change the basic model.

Since you mention robotics, let me mention Rodney Brooks.
Think of a robot architecture divided into layers, where
there are low level sensorimotor thingies and high level
goal satisfaction thingies.  The low level thingies are
concerned with hardware interfaces and issues like
reporting events and ensuring that the motors don't burn
out.  This is a perfect application for Ada and yes SPARK
and this is stuff where hard real-time applies.

The high level thingies are dealing with modelling the
world and planning.  Your goals may suddenly change from
"I'd like a chocolate bar" to "oh ---- oh ---- I'm going
to DIE what do I DO?" or something else may go wrong and
throwing away your current plans and replanning from the
current situation is often a good thing to do if you can
afford it.  Letting high level thingies crash and
restarting them makes sense.  Hello Erlang model.

Here's an analogy: going to sleep interrupts our scheming
but not our breathing.  You really don't want breathing
to "crash".

And then of course we come to economics.  Ada was intended
to be used in spacecraft, military aeroplanes, all sorts
of things where the cost of failure could be so enormous
that it pays to spend a *lot* of effort trying to make your
software reliable.  Spending $2000 of programmer time to
reduce the likelihood of a $1000 robot burning out a motor,
that doesn't make quite as much sense.

"Build is right" means that the implementation correctly
implements the specification.  But the specification
could be wrong, and the world could change.
"Let it crash" means that when the implementation doesn't
match the real world, don't try to patch your data structures,
because amongst other things, your ideas about *how* to patch
the data structures are based on the same ideas that have just
turned out to be wrong.
I really do not see any conflict between these two.

Note in particular that while Erlang's type system is nowhere
near as strong as Ada's, it now *has* a type system, which is
a poor man's specification language, and that Thomas Arts has
done work on verifying Erlang.