Hacker News Reader

Comment by Arnavion | Hacker News Reader

Nit: The output does not have to be machine code to be considered a compiler.

I think in everyday usage, the most common thing that distinguishes the two is that a compiler saves its output in some standard format that some other piece of software is expected to understand.

So for example, something like Babel for JS is considered a compiler, because its output is JavaScript, which is a standardized language.

On the other hand, Python is not usually considered a compiler, even though it writes .pyc files to disk, because its output is bytecode that only Python itself is expected to understand.

Even this is a little bit grey though, because we would say that Python contains a bytecode compiler as one of its components, but I don't think that most people would say that the Python binary is a compiler.

> Python is not usually considered a compiler, even though it writes .pyc files to disk, because its output is bytecode that only Python itself is expected to understand.

I'd disagree, simply because this is exactly what javac does too.

But javac doesn't run it. It's run by "java". Therefore javac is called the compiler.

If things were such that "java" runs all .java files and creates those .class files as bytecode cache, then java won't have been called a compiler.

And similarly, if python had two different programs, one to create *.pyc files and the other runs it, the former one would have been called a python compiler.

Java bytecode is standardized. So any JVM implementing the spec should be able to interpret the output of javac:

http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.htm...

Python bytecode on the other hand is not standardized: its bytecode is considered an implementation detail of CPython and can vary from version to version.

Your example reinforces my point.

Colloquial usage really diverges strongly from technical usage.

For example, CPython could be considered to technically be a virtual machine because it does garbage collection on dead objects since v 2.4 at least, rather than being pure reference counting.

Yet most people would call CPython a straight interpreter.

Memory management is an implementation detail, doesn't have anything to do with being an interpreter or virtual machine.

Yes, it took me a while to "realise" (or perhaps "accept") this as well. What is machine code? Code that a machine can execute natively? What if I built a machine that had primitive instructions for JavaScript? Then JavaScript would be machine code, and an X->JavaScript "transpiler" could be considered a "compiler".

Now what if before building such a machine, I wanted to simulate one? I could write a "virtual" machine, which is really just a program that acts like a physical machine with native JavaScript instructions. Also known as a JavaScript interpreter.

Yeah, plus even when you get down to machine code, those instructions can be implemented as microcode in the CPU. Then you have things like the lisp machines. Or V8 compiling bits of javascript to machine code while it "interprets". What exactly defines a compiler gets pretty fuzzy.

You could write something that compiles down to JavaScript opcodes then run them in your JavaScript virtual machine. This is actually pretty similar to what Perl5 does. You wouldn't have to do that to have an interpreter, though. So your implementation of your "interpreter" fuzzes the line moreso because it indeed technically contains a compiler.

What, then, is the difference between a compiler and an interpreter? Just that the compiler saves its output rather than executing it?

For me, the compiler takes input program in language A and spits out the same program in language B. An interpreter goes (more or less) line by line and executes what it reads.

In theory, compilation is reversible, execution is not.

Minor nit-pick: an interpreter need not work line-by-line, but rather (more commonly?) AST-node-by-AST-node. This isn't necessarily true for BASIC interpreters or something resembling assembly, but in general the code is represented as a tree of parsed values by the time the interpreter starts running your code.

I would define it as: when a compiler operates on its own source code, the resultant compiled compiler executes as fast as the original. When an interpreter evaluates its own source code, the resultant interpreted interpreter is an order of magnitude slower. This definition allows for things like "just in time" compilation, and rules out silly tricks like bundling an interpreter and some source code into an executable image.

So compilation is idempotent? That's pithy, I like it.

Until you get to the Forth family

Why does that change with going to Forth?

The speed differential. Your basically making a list of jumps into machine code and then jumping in a loop. The interpreter takes your input and turns it into a jump list which it pumps into the loop. You can reuse a jump list by defining it as a new word.

This is a pretty good blog post (based on a really good paper) that describes the fundamental differences between interpreters and compilers: http://blog.sigfpe.com/2009/05/three-projections-of-doctor-f...

An interpreter controls the entire state of its execution environment. A compiler generates code, passes it over the wall, and hopes for the best.

They have very different outputs. Compilers produce programs, while interpreters produce answers. More specifically, compilers produce programs in another language (stereotypically machine code), while interpreters run your program to get an answer.

If all you have are compilers, you can never run a program. All you can do is convert it between different languages. Fortunately your computer comes with an interpreter built in: you can think of your cpu as an interpreter for machine code, implemented in hardware.

So by this definition, an interpreter is a compiler plus a virtual machine, bundled together?

It can be but needn't be. You can evaluate straight from walking your AST. You can also transform from your AST into an output then run the output. Either one is commonly called an interpreter but the former is further to that end of a spectrum.

It can even be source code: source-to-source compiler.

That's technically true. Those are also known as translators, although they are technically no different from compilers.

Something that compiles to an executable format for your environment is most likely to be actually called a compiler. Some "interpreters" are actually compiling to opcodes for a virtual machine then running on the virtual machine.

Reply on news.ycombinator.com