Explain Interpreted Programming Languages Like I'm Five

This is a subject I could use a much better understanding of. I look forward to reading the answers.

Comments

[edA‑qa mort‑ora‑y]

In the spirit on ELI5...

Imagine a new kid, Tommy, comes to kindergarten. He doesn't speak a language you know, but your friend Sam happens to speak his language. If you want to say something to Tommy, you tell Sam, who rewords it and says it to Tommy in his native language. Tommy says something back and Sam interprets it again and says it to you.

You have no idea how to talk to Tommy actually, nor do you know what he says. But your interperete Sam is making it seems as though you do. Your words, in your language, seem to be getting heard by Tommy. What Tommy says back is understood by you (via Sam).

Sam does this job for each sentence, back and forth. He's your interpreter.

Your uncle Rich is a master of robotics. He's keen on having everybody understand each other. He thinks translaters, while good, end up losing some meaning, and limiting what people can say to each other, as well as being slightly slower.

So Rich has a way of putting little nanobots (tiny robots) in your head. When you wish to tal to Tommy you find yourself magically talking directly to him, in his language, and understanding his language in turn. You think really hard while this is happening, but your own language is nowhere to be found in your head. You're truly thinking, speaking, and hearing in Tommy's language -- you can even access idioms (phrases and sentences) that you'd have no idea how to express in your own language.

We're going to call Uncle Rich a compiler. He's gone now, but you've been permanently converted to talk with Tommy, no need for Sam at all!

---

Sorry, that's about the best I can do in ELI5 form. It's a tricky topic as the lines between interpreted and compiled are not clear.

You can read my article Abstract Machines, Interpreters and Compilers or refer to minor details in how a language affects the resources it uses, as the answer includes relevant information to interpreting.

[Nick Polyderopoulos]

Hello,
I found a very good answer on stackoverflow.

From my understanding an interpreted programming language is executed line by line (or statement by statement) on the target machine.

This means that the program will get translated to machine code at the runtime and statement by statement whereas with compiled languages the code is already translated as a whole before it can run.

Sorry if my answer didn't help you just trying to get better with my answers :)

[edA‑qa mort‑ora‑y]

Interpreters don't tend to translate source code into machine code. They run at a higher level converting parsed constructs into dispatchable runtime constructs in their own code. The interpreter is a virtual machine and source code is kept away from the underlying platform.

If the code is converted to target machine code on the fly we tend to call this just-in-time compilation. The key point is that it is compilation, and the code is no longer being interpreted.

It gets fuzzy though since few interpreters work in the source language. They create their own IR (intermediate language) and have an interpreter for that (though some interpreters do directly work off a high-level syntax tree). This creates a fuzzy spectrum between intrepreted languages, virtual machines, and machine code.

[Jason Walzak]

This is really good. When I read the question I realized I couldn't answer it, I only had a slight understanding. That interpreted languages didn't need to be compiled.

Thank you.

[Evan Wilde]

This answer is not for a 5-year-old, but it's something I've been visiting as a mental exercise lately so I want to do a mind-dump. So.. this should probably be rated PG13, so proceed with caution. (It is totally safe for work though, just some weird concepts.)

So I've actually been re-pondering this topic with my supervisor a lot lately. I actually sent an email to Dan Grossman asking what the difference between a compiled and interpreted language. He is strongly of the belief that there is no such thing as an "interpreted language" or "compiled language", only an implementation decision.

So, the basic spoon-fed definition of an interpreted language would be one that has a program that executes the code, doing the translation and interpretation of the language at runtime. Okay, fine. That works for an old version of, say, python. But... even with modern python, it's partially compiled. Java is another example of where things get messy. So, people used to tell me that Java was essentially an interpreted language because, even though it's converted to an intermediate representation that is then run on the JVM. Okay great, sounds like the JVM is an interpreter (which yes, might have a JIT compiler). Great. But wait a second, there are actually a few hardware implementations of the JVM. Okay... now what? So we have a hardware implementation of an interpreter. Technically, all CPUs are hardware-based interpreters of their underlying instructions. So... that means that in order to determine if Java is interpreted or is compiled depends on knowing what hardware it is running on. Sounds like it really isn't the language anymore. More, the implementation of that language.

So, we can't use the old definition of an interpreted language anymore. I have kind of internalized a new definition of an interpreted language. It comes down to the need to re-access the AST (either full or partially) of the higher-level code at runtime. So far, none of the language features that I can think of inherently require accessing the AST again except for one. The eval function. With eval, you can take any input and execute it. Take python eval(input()), it's a bad idea, yes, but this is really the only situation that cannot be pre-compiled since the thing it is compiling will only be supplied at runtime. This is where Dr. Grossman's argument and mine separate. He argues that there is no issue with simply including the compiler in the binary executable, but I feel like that is cheating. With my updated definition, this technique would still list it as an interpreted language though since part of the AST (the part that is being supplied by the user) is being handled at runtime.

If we're going with my new definition, then the only difference between the two is a language that includes an eval function is an interpreted language, as enforced by the language, and languages that don't include this function are free to be implemented with an interpreter or with a compiler. Different language properties definitely lend themselves to be implemented on one or the other more easily, but it doesn't appear to be a requirement of the language.

As a little side note, I've seen C interpreters. It's weird because of our own predisposition to believe that C is a compiled language since it usually is, but no feature of the language itself requires it to be compiled, and I didn't see anything that specifically states that it MUST be compiled either. So, technically, it's still just C.

In summary, there are no such thing as a "compiled language" or an "interpreted language", only the implementation of the language. There is the one caveat to that, if you change your definition of an interpreted language as being a language that must re-evaluate part of the AST, then a language that requires an 'eval' function is strictly an interpreted language.

[Ben Halpern]

This timely and wonderful post from today goes a long way for me, but I'd still love any other descriptions or metaphors folks might have to describe "interpreted languages" in contexts we use them.

[Lorenzo Pasqualis]

A scripting language is interpreted at run-time. A compiled language is interpreted at compile time. When you run a script on a machine, the CPU spends a great amount of its processing power reading and understanding your code. When you run a compiled program, the CPU executes it directly without wasting any time.

That's why C and Go are fast and Ruby is slow.

Then, there is Java. In that case, there is still an interpreter involved, but the interpreter is much simpler and executes virtualized bytecode. Java is in between an interpreted language and a purely compiled language.