5 ms·

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

by Arnavion 10y ago

nickpsecurity 10y ago
It can even be source code: source-to-source compiler.
- cestith 10y ago
  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.
clusmore 10y ago
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.
- briansteffens 10y ago
  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.
- cestith 10y ago
  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.
taneq 10y ago
What, then, is the difference between a compiler and an interpreter? Just that the compiler saves its output rather than executing it?
- yoz-y 10y ago
  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.
  - nv-vn 10y ago
    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.
- Patient0 10y ago
  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.
  - taneq 10y ago
    So compilation is idempotent? That's pithy, I like it.
  - SixSigma 10y ago
    Until you get to the Forth family
    - bogomipz 10y ago
haberman 10y ago
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.
- bretthoerner 10y ago
  > 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.
  - z92 10y ago
    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.
  - haberman 10y ago
    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.html#jvms-6.2 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.
- dismantlethesun 10y ago

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

nickpsecurity 10y ago

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

cestith 10y ago
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.

clusmore 10y ago

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.

briansteffens 10y ago
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.
cestith 10y ago
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.

taneq 10y ago

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

yoz-y 10y ago
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.
- nv-vn 10y ago
  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.
Patient0 10y ago
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.
- taneq 10y ago
  So compilation is idempotent? That's pithy, I like it.
- SixSigma 10y ago
  Until you get to the Forth family
  - bogomipz 10y ago

haberman 10y ago

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.

bretthoerner 10y ago
> 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.
- z92 10y ago
  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.
- haberman 10y ago
  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.html#jvms-6.2 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.
dismantlethesun 10y ago