<br><br><div class="gmail_quote">On Mon, Apr 18, 2011 at 7:09 PM, Steve Davis <span dir="ltr"><<a href="mailto:steven.charles.davis@gmail.com" target="_blank">steven.charles.davis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Interesting response. Actually, I find myself in disagreement here. Let<br>
me explain further.<br>
<br>
There's two precepts at the heart of my personal Erlang journey and<br>
experience that are somewhat in opposition to your statements (and<br>
appear to me to be in direct opposition!):<br>
<br>
1) Let it crash!<br>
2) Checks are only required at the boundary of the system.<br>
<br>
For "type safety" I find pattern matching and guards quite adequate,<br>
even as a codebase grows. Also, the BEAM VM seems pretty good at<br>
optimizing such dynamic checks.<br>
<br>
Of the other approaches in Erlang that attempt to enhance type checking,<br>
the only one that appeared _to me_ to have any true elegance was UBF<br>
Contracts.<br>
<br>
I rather suspect that the lack of further static type checking in Erlang<br>
wasn't because the creators didn't have time, but rather that, given the<br>
precepts above, it wasn't considered *useful* or necessary. ...that's my<br>
take on things of course, and I'd be interested in how far that is true.<br>
Perhaps Joe or Robert may weigh in with a comment on that.<br></blockquote><div><br><br>
Erlang evolved from Prolog. The first Erlang was just a meta-interpreter written in Prolog<br>
to add processes and message passing to Prolog.<br>
<br>
Prolog had dynamic types therefore Erlang had dynamic types - no thinking was involved.<br>
Nothing to do with lack of time. As the language evolved we were more interested in<br>
things like error recovery than static type checking.<br>
<br>
The stuff that we really thought long and hard about was not type checking but<br>
error checking. The link mechanism, for example, is something that I think is unique to Erlang.<br>
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<br>
check errors caused by out-of-band behavior (exceptions). Exceptions propagate over<br>
links and are handled elsewhere.<br>
<br>
The exception mechanism works just like a traditional try-catch where exceptions<br>
are thrown up the call stack to an enclosing catch, but if there is no enclosing catch<br>
the exception propagates out of the processes and is sent as a single to any linked processes.<br>
<br>
The particuar combinations of links/spawn_link/process_flag(trap_exit, ...) etc<br>
were arrived at after much though, discussion and experimentation. These are the<br>
sort of questions we were worrying about - not type systems. Why these problems?<br>
Easy - because we wanted to build real-world fault tolerant systems. Getting this<br>
right was essential. Systems we built using these techniques have been operational for<br>
many years now, switching millions to billions of users sessions/day.<br>
<br>
When people say "language X has Erlang like semantics" they virtually always mean<br>
"language X has processes, mailboxes and message passing" and non of the fun stuff<br>
(links, exit signals, linked process groups).<br>
<br>
Erlang is pretty good at what it was designed to be good at - namely building fault tolerant<br>
systems. It was not designed with static type checking in mind.<br>
<br>
/Joe<br>
<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
Also, I'm wondering whether your (amazing!) work with erjang and the JVM<br>
hasn't influenced your response, here. Especially with regard to the<br>
apparent "richness" and efficiency? Contrarily, I have found dynamic<br>
typing a blessed relief from the verbosity that occludes the value of<br>
languages with greater levels of static type-checking.<br>
<br>
With the greatest respect, if Erlang (+OTP) had taken the path you<br>
suggest, I suspect I would find it far less attractive as a platform.<br>
<br>
Best regards,<br><font color="#888888">
/s</font><div><div></div><div><br>
<br>
On 4/18/2011 5:58 AM, Jesper Louis Andersen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Apr 18, 2011 at 01:07, Steve Davis<br>
<<a href="mailto:steven.charles.davis@gmail.com" target="_blank">steven.charles.davis@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
IMHO, a focus on type-safety can lose you a truly *massive* amount of<br>
time that could be spent doing something useful.<br>
</blockquote>
<br>
There are many intricate dependencies which you can't simply resolve<br>
in a few moments of thought on that one. The point of type safety is<br>
to trade a short-term added specification for a long-term benefit. You<br>
write down a precise expression of intent with the type, and being<br>
precise takes more time. But it is extremely helpful over the course<br>
of larger programs, provides (checkable!) documentation, yields more<br>
effective execution trivially and so on.<br>
<br>
The initial ignorance of static types in Erlang is understandable.<br>
Other things were more important to get right and history was such<br>
that we did not understand certain parts of the intermingling of types<br>
with distribution etc.. But today, I feel there is no excuse. Should I<br>
design a modern Erlang, I would start with a statically typed world in<br>
which communicaiton use polymorphic variants. Essentially: An internal<br>
process is statically typed, but communicate in a dynamically typed<br>
setting. Thus, I have lost *nothing* compared to Erlang, but I can<br>
compile processes to be an order of magnitude faster, trivially. From<br>
there, I can probably define a channel-primitive between processes<br>
with static type constraint such that processes can intercommunicate<br>
in a type-safe way. Perhaps even with a shared-persistent-heap<br>
semantics.<br>
<br>
Remember, dynamic typing is a straitjacket, in which you cannot fully<br>
express yourself, whereas static typing give you a rich language for<br>
doing so.<br>
<br>
<br>
</blockquote>
<br></div></div><div><div></div><div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>