OTOH, dynamic languages are designed to interpret conditions as they occur at runtime. Up to this point, we really haven't been able to exploit this powerful capability to its fullest extent, but hardware is now cheap, and massive collections of hardware (like at Google's The Dalles plant) now exist to provide what is essentially a virtual environment that provides units of computing power as needed. Dynamic apps can adapt to take advantage of this. For example, modify an app in the REPL as it's running, or hot swap code in an Erlang app, or send lambdas wherever you want on a network running q/kdb+.

Now take that notion a step further. Why do humans have to initiate any of that day-to-day dynamism? The answer to that question is the future of computing and it's why we have to have interpreted languages for dynamic environments. Compiled apps (and OSes, IMO) are not part of the future. The next frontier after that will involve the hardware itself going dynamic.

For example, Common Lisp implementations often compile functions as they're entered at the interactive prompt. From your perspective, you see an "interpreter" that runs code on the order of 100 times faster than it should. I'm told popular OCaml and Haskell implementations work this way too.

If you're interested in portability, there are efficient Scheme compilers that target ANSI C, which gives you portability, good integration into just about any environment, and access to lots and lots of library code. My favorite of these is Chicken Scheme, which you can read about at http://www.call-with-current-continuation.org.

I seemed to think you'd have to have a Lisp interpreter (so that the macros would have to be interpreted) and optionally a compiler. So you can have the 'interpreter' just be a compiler which is followed by a call to the generated code?

Interpreters are easier to write because it is not as much work supporting different architectures compared to compiling the code. Also, interpreting small amounts of code that will only be run once is typically faster than compiling it and then optimizing and executing it.

Compiling however has much greater potential speedups. A compiler can make a decision at compile time once, and that decision never has to be made again. In an interpreted language that decision might have to be remade on every iteration of a loop.

As you move up from more powerful languages than C, the languages get harder and harder to compile because you know intrinsically less at compile time. In C for example, every variable is known at compile time, so every variable lookup can be translated into a read from some offset from the stack frame pointer, which is very fast. The C compiler will keep a hash table at compile time to keep track of these offsets, but at run time that information is no longer available. In Python, you don't know all the variables that are going to be looked up at compile time, so you have to do those expensive hash table lookups at run time.

In the end, naively generating code for a dynamic and reflective language won't yield that much of a speedup without some serious optimization passes, which was typically not very helpful because the higher level languages were used as glue code to high performance libraries or programs. As people become more interested in using these languages for more intensive work expect to see more effort at compiling then, although most will probably be compiled into a virtual machine bytecode and then compiled to native machine code by the JVM or CLR.

With the exception of some lisp work done a long time ago, no one has seriously worked on making dynamic languages fast.

Also, note that the majority of the optimizations that e.g., HotSpot does are as applicable to "dynamic" languages as they are to "static" languages.

Other than that, I can't think of much else: as others have said, it's no longer a discrete choice, it's become a continuum of choices with hybrid solutions that come very close to the ideals of both extremes. Except for that of the simplicity of an interpreter maybe. :)

Reflection is useful whenever you need any kind of dynamic features in your system. Even for rigidly static languages, compile-time reflection can be useful ("metaprogramming"), although there's a serious danger of constructing cathedrals. As it has been said before, compiled code doesn't exclude reflection. Reflection is just metadata that gets compiled in, plus a mechanism for accessing it.

Your comment is only arguably true for completely statically compiled languages which have very weak (or no) processing model that can be enforced (by e.g., the loaders).

In theory there is no reason for one model to be less powerful than the other. And as compiler/interpreter-writers get to be more knowledgeable this seems to hold up in the real world more and more.

Though interpreters are generally easier to write.

In terms of the hardcore, there's still a lingering fight between the static compilers and the dynamic compilers. Though, even that is starting to erode because the best static compilers only generate the best code by using profiles created during instrumented, previous runs of the application (which basically makes them poor-man's dynamic compilers). Dynamic compilers such as HotSpot and the best Lisp implementations generate pretty good code and yet still handle the realities of eval, dynamic-class-loading, etc. well.

Including YC: http://www.google.com/search?q=(compiled+AND+interpreted)+AND+(speed+OR+ease+OR+portability)+site%3Anews.ycombinator.com

it depends on the problem solves, and the trade between perfomance and RAD