Interpreters and Dynamically Typed Languages

Question

Why are programs that have dynamically typed languages usually interpreted rather than compiled?

Deutsch

What languages do you have in mind? – Honebein

@TomasxK: How about: Erlang, Lisp, Lua, Prolog, Ruby, and others that have interpreters. – Deutsch

They aren't necessarily; many Common Lisp systems compile to native code. Also, what's your definition of "interpreted" vs. "compiled"? Where do Python and Java fall on that? – Meletius

@caveman: I carefully worded my question to say "usually." I am well aware that they can be compiled, but dynamic typing and interpreters is the preferred combination, no? – Deutsch

Preferred by whom, and for what? Many widely used languages are dynamically typed and only compiled down to some sort of bytecode, but that's as far as it goes. – Meletius

Answer 1

In short: They go together like peas and carrots.

Compiling vs. interpreting and language typing are fundamentally separate concerns in that you can have all possible permutations. On the other hand, the "reason" for picking compiling and not picking dynamic typing for a language design are usually the same: performance. The "reason" for picking dynamic typing and interpretation are also somewhat related.

It's not a hard and fast rule. You can always mix 'em up. You can compile Perl and Lisp for example and interpret C.

Polyethylene

The Haskell and ML crowd loves static typing not only mainly for performance (although sometimes being as fast as C is quite cool), but for the safety it can provide. That being said, static FP typesystems are ten times as powerful and expressive as your average OOP language's type system. – Scoff

I totally agree. It's really a reason for not picking dynamic typing. – Polyethylene

Most modern "interpreted" languages actually go through a "compilation phase" of sorts -- CPython goes to an intermediate byte-code (cached in pyc) files and clojure will actually compile to Java Byte-code. The issues "compiling" (going from source-code to an intermediate, weather it is "machine code" -- which is interpreted by a CPU -- or some byte-code such as JBC, which is interpreted by a JVM) and "dynamic typing" are somewhat orthogonal. – Lien

Answer 2

You are observing a non-causal correlation:

• Dynamic typing and interpretation correlate because both are easy to implement.
• Static typing and compilation correlate because both are conducive of predictably-good performance.

Compilers are usually retrofitted onto dynamically-typed languages in an attempt to improve performance (because performance is often very poor). For example, here's how long some major dynamically-typed languages were interpreted for before their first compiler was written: Lisp (1958-1962), Mathematica (1988-2004), Lua (1993-2004), Python (1991-2002) and Javascript (1995-2009). In contrast, languages like OCaml (1996) and F# (2001) were released first as compilers.

Bromoform

Answer 3

As noted by others, languages are neither compiled or interpreted. They're just rules that need translating and most have interpreted and compiled implementations. Even then, it's hard to talk about interpretation versus compilation when many "interpreters" are jitting all over the place and some "compilers" are happy to compile-on-demand if a source file changes.

Maybe it's better to categorize implementations as fully pre-compiled or compiled-on-demand. If we use these categories, the one thing that breaks full pre-compilation is an eval function. This probably has more of an effect on the implementation than dynamic types. If you have an eval function, you're required to support compile-on-demand.

Markettamarkey

Answer 4

Common Lisp code is mostly compiled. The Common Lisp programming language has been described in an ANSI standard with support for compilation. The ANSI standard describes functions that compile code, describes various aspects of optimizations, describes aspects of the compilation process and more.

Interpreters for Common Lisp exist, but are less often used.

Common Lisp implementations often can mix different execution modes freely. Almost all have a compiler. A few only have a compiler.

Compilation in almost all implementations has an incremental mode, so that it can be used interactively. All can compile files. Some have 'block compilation' modes to compile groups of files.

Actualize

Answer 5

Per the definition of dynamically typed languages...

A programming language is said to be dynamically typed when the majority of its type checking is performed at run-time as opposed to at compile-time. In dynamic typing, values have types but variables do not; that is, a variable can refer to a value of any type.

That said, it becomes hard to know what to compile the program down to since it could change at runtime. Another excerpt here from Wikipedia...

Dynamic typing allows constructs that some static type checking would reject as illegal. For example, eval functions, which execute arbitrary data as code, become possible. Furthermore, dynamic typing better accommodates transitional code and prototyping, such as allowing a placeholder data structure (mock object) to be transparently used in place of a full-fledged data structure (usually for the purposes of experimentation and testing).

I feel this answer is still incomplete but I hope it points you in the right direction. Perhaps others here can expand on this.

Foreworn

Some dynamically typed languages are compiled to native code, although you seem to think that impossible. – Meletius

I am not going to say you're wrong but I can't think of an example of a fully dynamic typed language that is compiled. – Foreworn

Many Common Lisp implementations are fully compiled. It is possible to specify types statically if you want to, but that's an optimization. – Meletius

Forth! A bit tongue in cheek, but true. – Polyethylene

Ok, I changed the impossible to hard though I think the two examples given, Common Lisp and Forth kinda "cheat" in that they are carry around the code to compile more code on-the-fly which is kinda fuzzy in regards to Interpreters vs Compilers. I will concede the point though. – Foreworn

-1 Both of your definitions are wrong. "majority of its type checking". Static type systems reject at compile time programs that have type errors. Nothing to do with "majority". "eval functions, which execute arbitrary data as code, become possible". Several statically-typed languages have eval. MetaOCaml even provides statically type checked eval! – Bromoform

@JonHarrop: these are not my definitions, they are from Wikipedia. The case about evals was an example not an absolute. – Foreworn

@AndrewWhite: I appreciate they are from Wikipedia but the definitions and the example are incorrect. – Bromoform

Answer 6

Checking types once is actually what makes a "compiler" (~ a type checker).

You can't "compile" (check types once) when types are "dynamic".

Honebein

This is an, um, really non-standard definition of "compiler". Most of us use the word to refer to a program that translates a computer language to a more basic one. – Meletius

A type checker is not a compiler, but rather a part of one (or step of a compilation pipeline). – Missi

No, even worse: It's can be part of a compiler, but it's totally optional. Even if you (wrongly) only count the compilers that compile to "real" target languages like x86 machine code as compilers, e.g. Lisp is dynamically-typed and there are many native compilers for Scheme and CL. – Scoff