[plt-scheme] Why do folks implement *dynamically* typed languages?
Grant Rettke wrote:
> 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?
Ignoring the subtleties for a moment (caveats later), DLs are better at
prototyping. For example, when you're prototyping in a DL, writing a
stub procedure is trivial. Writing stubs in SLs requires that you work
out the type issues in advance, in far more detail than you might want
to at the time.
This kind of thing makes programming in SLs like having a boss who's
trying to micromanage you, and who doesn't quite understand what you're
doing. The SL won't let you do what *you* think is important until
you've done what *it* thinks is important.
That issue alone can make the argument for a language like Ruby, or
Scheme, in many cases. Languages that put you in control in the way
that DLs do have been called "freedom languages":
http://codecraft.info/index.php/archives/20/
Read the first four paragraphs on that page. Ruby is mentioned.
Here are some of the caveats about my point:
1. SLs can be good at a different kind of prototyping: designing types.
I sometimes use SML and, more recently, OCaml, just to design the
types for a program that I might be writing in Scheme. And once you've
designed the types, it can be quite useful to just let the language
guide you in telling you what you need to do next, even if that means
you have to do some things that aren't really important at the time.
2. What Carl wrote is a double-edged sword:
> [DLs] puts a lot of responsibility on me to get the system right,
> but I can live with that.
Individual programmers can usually live with this, and often prefer it,
but there are situations in which you might reasonably, as Matthias
suggested, want to pick a language like OCaml. In some commercial
environments, having the language act like a micromanaging boss may be
useful.
In a team situation, you can think of a typechecker as a member of the
team, a bit like the quality assurance or testing guy: very anal, often
raises issues you really don't think are important or high priority, but
you usually do what he says anyway because it's part of the discipline
of collaborating in a team working on a complex system.
Perhaps the solution to the problem Matthias raised, of filtering for
smart employees, is to hire people who *can* program in ML or Haskell,
but *want* to program in Scheme. Those are clearly the smartest. ;)
Anton