[erlang-questions] Runtime checking for types

[Steve Davis]

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.

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.
>
>