<div><span class="gmail_quote"><br></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">That is what I don&#39;t understand. It is so seemingly obvious that it is
<br>better to have Sl, yet, the latest hot language that everyone wants to<br>know and love is Ruby, which is a DL. Is it mass hysteria or what is<br>happening?</blockquote><div><br>Lovely discussion, and a confusing thread.
<br><br>Some time ago I
stopped unconditionally trusting labels like static vs dynamic, strict
vs non-strict typing. They are not wrong, they just too black and
white, while the real needs are not even grayscale, they are quite
colourful. The label mess becomes really bad, when you find that people
abbreviate, let&#39;s say &quot;dynamically typed language&quot;, with dynamic
language, and through citation and reuse the terminology becomes
muddled. In order to type less, most of the following patchy writeup
talks about strictly typed languages.
<br><br>As I understand it statically typed languages, like Haskell
force you to have proven consistency in types, names and values at
compile time. Dynamically typed ones, like scheme or lua, do type
checking at runtime. Upside - flexibility. Downside, runtime errors,
generally type inference for complex types by hand, but nothing stops
you from implementing a prover.
<br><br>Some languages lie somewhere in between. Ok, not precise, but
the bird eye view of how dylan deals with generic functions shows an
outline of one of the approaches. &quot;try and infer the type of a name as
much as possible, defer the rest of the type checking to run-time&quot;. If
I&#39;m not mistaken, PLT scheme does something like that, I might be wrong
though. It seems like there is a tendency towards this kind of type
inference. It does make sense. Especially in the context of using
modules/libraries and languages, like scheme, which give you the tools
to alter the grammar of the language. You can construct your own,
modular, application specific, tower of type rules, which with the
right compiler should be able to produce, at least in theory, code with
similar efficiency to the one of a strictly typed language. In this
context I find the <a href="http://www.ccs.neu.edu/home/dherman/research/publications/tfp07-gradual-typing.pdf" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.ccs.neu.edu/home/dherman/research/publications/tfp07-gradual-typing.pdf
</a> paper enlightening.<br><br>I&#39;m
not sure if it is right to speak about strictly typed languages
associating types to names and values and dynamically typed ones just
to values. I haven&#39;t given it any serious time, but at least on an
overview level it seems correct(ish), I&#39;m sure there could be
exceptions.
<br><br>Actually one of the reasons for things like unit test is a
consequence of dynamic types - make sure that you pick type errors in
tests, not &#39;real run time&#39;.<br><br>I might be getting all of the above quite wrong, so please correct me.
<br>&nbsp;</div><br></div>