Compiled code would run faster, and would be good for the processor cache, why do we still use a lot of interpreted programs at servers and in web world.
Yes JIT compilers are available, but still why are interpreters more popular?
Interpreted languages are put together for ease and speed of programming, so the programmer gets stuff done quicker.<p>Compiled languages are put together to let the programmer work harder to create programs that have some kind of high performance. So the end product can be quicker, even if it more expensive to produce.<p>Only a few languages try to bridge the gap. Most notably Go. Go is compiled but is also set up to be easy to use. The result is a nice mixture of good performance and ease of programming. See golang.org.
Processor time is increasingly fast enough to allow us the once-upon-a-time luxury of considering the programmer's time.<p>Interpreters make the inner loop of the programmer's life faster, making program development faster.<p>Once the program works, a profiler can be applied, and only the very slowest things recoded in lower-level language.<p>For many projects, optimization is not necessary at all.<p>Even in Donald Knuth's time, "Premature optimization is the root of all evil," was a common caution. Modern hardware makes this even more true today.<p>Not to say that you should go out of your way to code clumsily, but that shaving a cycle here and there anywhere but the innermost of loops is likely to be a waste of the only time that is really precious any more... your own time writing the code.<p>Given the amount of time code spends in maintenance, taking the time to write clear code will save the maintainer (possibly you!) time, so readability should be prized over raw execution speed in almost all cases. In six months, you won't remember how that tricky one-liner really works, and will waste reading time in minutes to hours that saved microseconds in execution.
Productivity. Interpreters load code changes during development without any issue. Compilers usually create incompatible versions of the same class, throw errors and hamper productivity.
The reason (yes, "the" reason, hah!) is because the interpreted languages could be more rapidly developed and, because they were dynamically typed, were able to expand their feature set into something practical and flexible that statically typed languages are still catching up on. It's just much harder to design a good statically typed language without sacrificing features or convenience or hacks that you can get from free-wheeling interpreted languages<p>Before LLVM, statically typed, compiled languages got bogged down in a lot of stuff that wasn't language design. They still do though.
Answering your question slightly different from interpreted vs compiled:<p>There are lot of things on the web today that are compilers: Jekyll and multiple static site generators compile static pages. A cache like Varnish works as the end-point of a process that results in a compiled result, to the same interpretation doesn't need to be done ('compiled').
When was the last time your computer was CPU bound long enough for you to notice?<p>And it wasn't a bug or homework assignment or something involving NP?
Because it is <i>much</i> easier to implement an interpreter than a compiler. And if your code is IO bound anyway (most websites) then it doesn't matter that it runs 10 to 100 times slower.
What specifically are you referring to?<p>Both Java and C# are compiled (JIT or AOT depending on environment). PHP is often interpreted for development but pretty regularly compiled for production (see Facebook et al).