<div> <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't understand. It is so seemingly obvious that it is better to have Sl, yet, the latest hot language that everyone wants to know and love is Ruby, which is a DL. Is it mass hysteria or what is happening?</blockquote><div> Lovely discussion, and a confusing thread. 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's say "dynamically typed language", 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. 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. 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. "try and infer the type of a name as much as possible, defer the rest of the type checking to run-time". If I'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. I'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't given it any serious time, but at least on an overview level it seems correct(ish), I'm sure there could be exceptions. 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 'real run time'. I might be getting all of the above quite wrong, so please correct me.  </div> </div>