

Ask HN: Why do we use interpreters instead of compilers? - ggonweb

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?
======
LocalMan
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.

~~~
mbrodersen
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).

------
JackK
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.

~~~
mbrodersen
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.

------
manidoraisamy
Productivity. Interpreters load code changes during development without any
issue. Compilers usually create incompatible versions of the same class, throw
errors and hamper productivity.

~~~
rdc12
Plenty of compilers allow for on the fly changes

~~~
manidoraisamy
Classloaders usually reject incompatible versions of the same class when you
do that. Plus they don't come with default SDK.

~~~
mbrodersen
Java does not represent the limits of what is doable when compiling.

~~~
manidoraisamy
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.

------
SamReidHughes
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.

------
zhte415
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').

------
brudgers
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?

~~~
JoeAltmaier
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.

------
mbrodersen
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.

------
Someone1234
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).

~~~
ggonweb
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.

~~~
rdc12
Most current javascript engines use JIT compilers now. Since you have no idea
what platform a client is on AOT would be problematic.

------
easytiger
Sometimes you don't need to be fast.

