[plt-scheme] Why do folks implement *dynamically* typed languages?

From: Vladimir Zlatanov (vlado at dikini.net)
Date: Thu May 31 09:07:09 EDT 2007

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


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
http://www.ccs.neu.edu/home/dherman/research/publications/tfp07-gradual-typing.pdfpaper
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070531/4e37e424/attachment.html>

Posted on the users mailing list.