[erlang-questions] Static type checking...

[Steve Davis]

Thanks, Jesper, for the considered answer... I fully agree and support that you recognize the importance of protocol.

And given the problem, the interesting part is defining a boundary (which defines state, not just types) beyond which you should be able to assume good data or blow up.

Defining that boundary at every possible library point is onerous. 

Static typing (compared to protocol contracts) does not account for state (which any process could potentially maintain)...

What to do? I wish I had the answer, i.e. an answer that was complete and beyond just an intent of solving that issue.

/s

On Apr 30, 2013, at 5:38 AM, Jesper Louis Andersen <jesper.louis.andersen@REDACTED> wrote:

> 
> 
> 
> On Apr 30, 2013, at 2:40 AM, Steve Davis <steven.charles.davis@REDACTED> wrote:
> 
>> It's my experience that attempts at static type checks ends up in "turtles all the way down" and enormously onerous code.
> 
> Static typing, preferably with inference of the types, is a really nice tool for finding and killing bugs early. But interestingly, there is not that much formality when it comes to checking the *protocol* between two processes. Since Erlang processes are often simple internally, it becomes way more interesting to have a formal protocol checker to verify adherence. I don't care what you are doing internally in your process. You could write it in any language you desired, as long as you adhere to the protocol we laid out on top.
> 
> There is a similarity to having a signature on a module specifying a skeleton of how that code will execute type-wise.
> 
> There are two things needed with a validation layer:
> 
> It has to be effective. It needs to catch bugs. It needs to remove bugs before they wreak havoc on the system.
> 
> It has to be simple. We can't afford the layer to take up considerable human resources to specify a protocol contract. Otherwise, we end up wasting time. If you are going to pay time up-front, you better know that you find errors later on in the process. Otherwise, that time was just wasted.
> 
> Jesper Louis Andersen
>  Erlang Solutions Ltd., Copenhagen
>