Ask HN: Why do we use interpreters instead of compilers?
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?
9 comments
Interpreted languages are put together for ease and speed of programming, so the programmer gets stuff done quicker.
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.
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.
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.
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.
Ease of use has nothing to do with interpreting/compiling. It has to do with surface syntax and familiarity. You can interpret or compile any language. You can (say) interpret code written in C. And you can compile Ruby to machine code if you want (with JIT compilation for eval).
To add to the first point, servers are generally cheaper than programmers, especially for things like web softwrae.
Processor time is increasingly fast enough to allow us the once-upon-a-time luxury of considering the programmer's time.
Interpreters make the inner loop of the programmer's life faster, making program development faster.
Once the program works, a profiler can be applied, and only the very slowest things recoded in lower-level language.
For many projects, optimization is not necessary at all.
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.
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.
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.
Interpreters make the inner loop of the programmer's life faster, making program development faster.
Once the program works, a profiler can be applied, and only the very slowest things recoded in lower-level language.
For many projects, optimization is not necessary at all.
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.
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.
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.
Readability of the syntax of a language has nothing to do with whether it is interpreted or compiled. For example: Javascript used to be interpreted in browsers. Now it is typically JIT compiled. It hasn't changed the readability of Javascript the language at all.
Productivity. Interpreters load code changes during development without any issue. Compilers usually create incompatible versions of the same class, throw errors and hamper productivity.
There is nothing stopping a compiled language from dynamically loading new code. That is what .so and .dll's are used for all the time.
Plenty of compilers allow for on the fly changes
Classloaders usually reject incompatible versions of the same class when you do that. Plus they don't come with default SDK.
Java does not represent the limits of what is doable when compiling.
I used java classloader as a canonical example. In general, compilers outputs object code during development and the runtime doesn't expect syntax errors. Compiler like JIT are meant for runtime optimization and not to handle the development workflow like syntax parsing. That's why errors in development workflow compilers (like JSP compiler) are incomprehensible, when you start writing code inside it.
On the other hand, dynamic language interpreters already handle both syntax parsing and execution at runtime. Therefore loading changes during development is not a big deal for them.
On the other hand, dynamic language interpreters already handle both syntax parsing and execution at runtime. Therefore loading changes during development is not a big deal for them.
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
Before LLVM, statically typed, compiled languages got bogged down in a lot of stuff that wasn't language design. They still do though.
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:
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').
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?
And it wasn't a bug or homework assignment or something involving NP?
And it wasn't a bug or homework assignment or something involving NP?
Every day, all day. The mouse hangs; the web page is stuck; dialog buttons don't work; the screen update paints in pieces.
Not all of that is cpu-shortage but some of it is.
Not all of that is cpu-shortage but some of it is.
All the time. GUI's and other applications are slow. I am constantly waiting for apps to refresh. They shouldn't be. In comparison, I recently wrote a web server in Haskell (a compiled language) that handles 35000 web transactions per second. Try that with Ruby.
Because it is much 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?
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).
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).
looking at all the recent popular languages they all interpreted languages, (javascript, Java, python ...etc).
Is it because of platform independent, security, availability of interpreters, dynamic nature of syntax...? what makes them more popular.
Most current javascript engines use JIT compilers now. Since you have no idea what platform a client is on AOT would be problematic.
Sometimes you don't need to be fast.