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

From: Anton van Straaten (anton at appsolutions.com)
Date: Wed May 30 21:06:53 EDT 2007

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":


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 

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.  ;)


Posted on the users mailing list.