[erlang-questions] Runtime checking for types

[Joe Armstrong]

On Mon, Apr 18, 2011 at 7:09 PM, Steve Davis <steven.charles.davis@REDACTED
> wrote:

> Interesting response. Actually, I find myself in disagreement here. Let
> me explain further.
>
> There's two precepts at the heart of my personal Erlang journey and
> experience that are somewhat in opposition to your statements (and
> appear to me to be in direct opposition!):
>
> 1) Let it crash!
> 2) Checks are only required at the boundary of the system.
>
> For "type safety" I find pattern matching and guards quite adequate,
> even as a codebase grows. Also, the BEAM VM seems pretty good at
> optimizing such dynamic checks.
>
> Of the other approaches in Erlang that attempt to enhance type checking,
> the only one that appeared _to me_ to have any true elegance was UBF
> Contracts.
>
> I rather suspect that the lack of further static type checking in Erlang
> wasn't because the creators didn't have time, but rather that, given the
> precepts above, it wasn't considered *useful* or necessary. ...that's my
> take on things of course, and I'd be interested in how far that is true.
> Perhaps Joe or Robert may weigh in with a comment on that.
>


Erlang evolved from Prolog. The first Erlang was just a meta-interpreter
written in Prolog
to add processes and message passing to Prolog.

Prolog had dynamic types therefore Erlang had dynamic types - no thinking
was involved.
Nothing to do with lack of time. As the language evolved we were more
interested in
things like error recovery than static type checking.

The stuff that we really thought long and hard about was not type checking
but
error checking. The link mechanism, for example, is something that I think
is unique to Erlang.
Processes communicate errors "out of band" this means you can write your
regular inter-process message passing using regular RPCs and the RPC like
code does not need to
check errors caused by out-of-band behavior (exceptions). Exceptions
propagate over
links and are handled elsewhere.

The exception mechanism works just like a traditional try-catch where
exceptions
are thrown up the call stack to an enclosing catch, but if there is no
enclosing catch
the exception propagates out of the processes and is sent as a single to any
linked processes.

The particuar combinations of links/spawn_link/process_flag(trap_exit, ...)
etc
were arrived at after much though, discussion and experimentation. These are
the
sort of questions we were worrying about - not type systems. Why these
problems?
Easy - because we wanted to build real-world fault tolerant systems. Getting
this
right was essential. Systems we built using these techniques have been
operational for
many years now, switching millions to billions of users sessions/day.

When people say "language X has Erlang like semantics" they virtually always
mean
"language X has processes, mailboxes and message passing" and non of the fun
stuff
(links, exit signals, linked process groups).

Erlang is pretty good at what it was designed to be good at - namely
building fault tolerant
systems. It was not designed with static type checking in mind.

/Joe



>
> Also, I'm wondering whether your (amazing!) work with erjang and the JVM
> hasn't influenced your response, here. Especially with regard to the
> apparent "richness" and efficiency? Contrarily, I have found dynamic
> typing a blessed relief from the verbosity that occludes the value of
> languages with greater levels of static type-checking.
>
> With the greatest respect, if Erlang (+OTP) had taken the path you
> suggest, I suspect I would find it far less attractive as a platform.
>
> Best regards,
> /s
>
>
> On 4/18/2011 5:58 AM, Jesper Louis Andersen wrote:
>
>> On Mon, Apr 18, 2011 at 01:07, Steve Davis
>> <steven.charles.davis@REDACTED>  wrote:
>>
>>> IMHO, a focus on type-safety can lose you a truly *massive* amount of
>>> time that could be spent doing something useful.
>>>
>>
>> There are many intricate dependencies which you can't simply resolve
>> in a few moments of thought on that one. The point of type safety is
>> to trade a short-term added specification for a long-term benefit. You
>> write down a precise expression of intent with the type, and being
>> precise takes more time. But it is extremely helpful over the course
>> of larger programs, provides (checkable!) documentation, yields more
>> effective execution trivially and so on.
>>
>> The initial ignorance of static types in Erlang is understandable.
>> Other things were more important to get right and history was such
>> that we did not understand certain parts of the intermingling of types
>> with distribution etc.. But today, I feel there is no excuse. Should I
>> design a modern Erlang, I would start with a statically typed world in
>> which communicaiton use polymorphic variants. Essentially: An internal
>> process is statically typed, but communicate in a dynamically typed
>> setting. Thus, I have lost *nothing* compared to Erlang, but I can
>> compile processes to be an order of magnitude faster, trivially. From
>> there, I can probably define a channel-primitive between processes
>> with static type constraint such that processes can intercommunicate
>> in a type-safe way. Perhaps even with a shared-persistent-heap
>> semantics.
>>
>> Remember, dynamic typing is a straitjacket, in which you cannot fully
>> express yourself, whereas static typing give you a rich language for
>> doing so.
>>
>>
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110418/170acbe6/attachment.htm>