Question

In my reading on dynamic and static typing, I keep coming up against the assumption that statically typed languages are compiled, while dynamically typed languages are interpreted. I know that in general this is true, but I’m interested in the exceptions.

I’d really like someone to not only give some examples of these exceptions, but try to explain why it was decided that these languages should work in this way.

Answer 1

Here’s a list of a few interesting systems. It is not exhaustive!

Dynamically typed and compiled

1. The Gambit Scheme compiler, Chez Scheme, Will Clinger’s Larceny Scheme compiler, the Bigloo Scheme compiler, and probably many others.

   Why?

   Lots of people really like Scheme. Programs as data, good macro system, 35 years of development, big community. But they want performance. Hence, a number of good native-code compilers—Chez Scheme is even a successful commercial product (interpreted bytecodes are free; native codes you pay for).

2. The LuaJIT just-in-time compiler for Lua.

   Why?

   To show it could be done. And then, people started to like getting 3x speedup on their Lua programs. Lua is in a lot of games, where performance matters, plus it’s creeping into other products too. 70% of the code in Adobe Lightroom is Lua.

3. The iconc Icon-to-C compiler.

   Why?

   The fifty people who used it loved Icon. Totally unusual evaluation model, the most innovative (and in my opinion, best) string-processing system ever designed. But that evaluation model was really expensive, especially on late-1980s computers. By compiling Icon to C, the Icon Project made it possible for big Icon programs to run in fewer hours.

Conclusion: people first develop an attachment to a dynamically typed language, and probably a significant code base. Eventually, the community spits out a native-code compiler so that you can get better performance and solve bigger problems.

Statically Typed and Interpreted

This category is less common, but…

1. Objective Caml. Dialect of ML, vehicle for lots of innovative experiments in language design.

   Why?

   Very portable system and very fast compilation times. People like both properties, so the new language-design ideas are desseminated widely.

2. Moscow ML. Standard ML with a few extra features of the modules system.

   Why?

   Portable, fast compilation times, easy to make an interactive read/eval/print loop. Became a popular teaching compiler.

3. C-Terp. An old product, I think maybe from Gimpel Software. Saber C—a product I don’t think you can buy any more.

   Why?

   Debugging. Especially, debugging on 1980s hardware under MS-DOS. For very little resources, you could get really good help debugging C code on very limited hardware (think: 4.77MHz processor with an 8-bit bus, 640K of RAM fully loaded). Nearly impossible to get a good visual debugger for native-compiled code, but with the interpreter, fairly easy.

4. UCSD Pascal—the system that made “P-code” a household word.

   Why?

   Teachers liked Niklaus Wirth’s language design, and the compiler could run on very small machines. Wirth’s clean design and the UCSD P-system made an unbeatable combination, and Pascal was the standard teaching language of the 1970s. Younger people may find it hard to appreciate that in the 1970s there was no debate over what language to teach in the first course. Today I know of programs using C, C++, Haskell, Java, ML, and Scheme. In the 1970s it was always Pascal, and the UCSD P-system was a big reason way.

   In case you are wondering, P stood for portable.

Summary: Interpreting a statically typed language is a great way to get an implementation into everybody’s hands quickly. (It also had advantages for debugging on Bronze Age hardware.)