6 ms·

> 2. Python is interpreted rather than compiled. Can we stop saying things like this? Virtually all Python is compiled, as part of the interpretation process.

> 2. Python is interpreted rather than compiled. Can we stop saying things like this? Virtually all Python is compiled, as part of the interpretation process. There is a valid point here, of course. The point is that the top Python compilers do not compile to native code. So say that. Words have meanings. Use them correctly. <grumble, grumble>

bunderbunder 12y ago
Might want to start by asking the core Python community. Check out the first sentence on wiki.python.org. Nowadays it's the norm for interpreted languages to be JIT-compiled. They still universally call themselves interpreted languages because the jitter is an implementation detail, and the use of one does nothing to negate the characteristics they're trying to advertise when describing themselves as interpreted languages. Think of it this way: Can I take a text file containing source code in the language and execute it anywhere that has a special program for executing files written in that language (commonly known as an interpreter)? Or do I have to manually perform an intermediate step of converting the program to some binary representation using a special program for doing that (commonly known as a compiler), and then execute the output that program produces?
- lispm 12y ago
  There are several compiler-only Lisp implementations which can execute source from text. Nobody there would call them interpreter because of that. In Lisp we call them interpreter, when the implementation traverses the source code during execution. If it compiles the source to some byte-code or machine code, we call in Compiler. The incremental nature of a compiler, then does not make it that we would call it an Interpreter. We would call it an incremental compiler. That's a compiler, which can compile all expression, regardless of the size of the expression, not just 'whole programs'.
  - ggchappell 12y ago
    > There are several compiler-only Lisp implementations which can execute source from text. Why not? I would.
    - ggchappell 12y ago
      Oops. My "Why not?" above is in reference to this: > Nobody there would call them interpreter because of that.
      - lispm 12y ago
        Why would you call an 'compiler' an 'interpreter'? The following is Clozure Common Lisp. Every single input is compiled directly to machine code. Feed it source text and everything is compiled. Each and every expression. Why should I call a direct native code compiler an 'Interpreter'? Makes no sense. ? (let ((f (lambda (a) (+ 1 a)))) (disassemble f) (funcall f 2)) ;;; (lambda (a) (+ 1 a)) L0 (leaq (@ (:^ L0) (% rip)) (% fn)) ; [0] (cmpl ($ 8) (% nargs)) ; [7] (jne L57) ; [10] (pushq (% rbp)) ; [12] (movq (% rsp) (% rbp)) ; [13] (pushq (% arg_z)) ; [16] ;;; (+ 1 a) (leaveq) ; [17] (testb ($ 7) (% arg_z.b)) ; [18] (jne L39) ; [22] (addq ($ 8) (% arg_z)) ; [24] (jo L32) ; [28] (repz) (retq) ; [30] L32 (jmpq (@ .SPFIX-OVERFLOW)) ; [32] L39 (movl ($ 8) (% arg_y.l)) ; [39] (jmpq (@ .SPBUILTIN-PLUS)) ; [44] ;;; #<no source text> L57 (uuo-error-wrong-number-of-args) ; [57] 3 ; result
        ggchappell 12y ago
        An interpreter is a box that takes code in some programming language and executes it. A compiler is a box that takes code is some programming language and translates it into another programming language. Traditionally, the twain ne'er did meet. However, many (most?) modern interpreters include a compiler as part of their implementation. Using a compiler in this manner is "Just in Time" (JIT) compilation. So a box that takes Clozure Common Lisp and converts it to machine code is a compiler. A box that takes Clozure Common Lisp, feeds it into this compiler to obtain machine code, and executes this machine code immediately, is an interpreter, using JIT compilation to do its interpretation.
jeffreyrogers 12y ago
There are three primary methods of running code: interpretation, compilation to object code, and running on a VM/JIT. Obviously python is interpreted by any meaningful definition of interpretation and thus it is not compiled in the typically sense of the word (at least not in the implementation everyone uses). The reason human language is so expressive is because we can leave out a lot of context and formalism that is required in mathematics and programming languages because the listener/reader will be able to infer it. It's pedantic to expect a writer to hedge against every possible interpretation, when their focus should be on communicating clearly in the first place.
- andreyf 12y ago
  FWIW, wikipedia says "The main Python implementation, named CPython, [...] compiles Python programs into intermediate bytecode, which is executed by the virtual machine." I'm not sure why people call Python's VM an interpreter, but it's definitely interpreting byte code, not the source directly. This is very different from Perl, where a line of code isn't parseable until you know the values of the variables, e.g. whatever / 25 ; # / ; die "this dies!";
  - haberman 12y ago
    > This is very different from Perl, where a line of code isn't parseable until you know the values of the variables Perl is crazy, but I don't think it's that crazy. From perlcompile(http://perldoc.perl.org/5.8.9/perlcompile.html http://perldoc.perl.org/5.8.9/perlcompile.html) Perl has always had a compiler: your source is compiled into an internal form (a parse tree) which is then optimized before being run. If what you say is true, it would not be possible to produce a parse tree prior to running the program. I could not get your code sample to die based on the type/value of "whatever" -- can you?
    - scott_s 12y ago
      Apparently, Perl is that crazy. See https://news.ycombinator.com/item?id=5770531 https://news.ycombinator.com/item?id=5770531 Basically, you can't always parse a Perl program without running it. There is a subset that you can, not not everything.

bunderbunder 12y ago

Might want to start by asking the core Python community. Check out the first sentence on wiki.python.org. Nowadays it's the norm for interpreted languages to be JIT-compiled. They still universally call themselves interpreted languages because the jitter is an implementation detail, and the use of one does nothing to negate the characteristics they're trying to advertise when describing themselves as interpreted languages. Think of it this way: Can I take a text file containing source code in the language and execute it anywhere that has a special program for executing files written in that language (commonly known as an interpreter)? Or do I have to manually perform an intermediate step of converting the program to some binary representation using a special program for doing that (commonly known as a compiler), and then execute the output that program produces?

lispm 12y ago
There are several compiler-only Lisp implementations which can execute source from text. Nobody there would call them interpreter because of that. In Lisp we call them interpreter, when the implementation traverses the source code during execution. If it compiles the source to some byte-code or machine code, we call in Compiler. The incremental nature of a compiler, then does not make it that we would call it an Interpreter. We would call it an incremental compiler. That's a compiler, which can compile all expression, regardless of the size of the expression, not just 'whole programs'.
- ggchappell 12y ago
  > There are several compiler-only Lisp implementations which can execute source from text. Why not? I would.
  - ggchappell 12y ago
    Oops. My "Why not?" above is in reference to this: > Nobody there would call them interpreter because of that.
    - lispm 12y ago
      Why would you call an 'compiler' an 'interpreter'? The following is Clozure Common Lisp. Every single input is compiled directly to machine code. Feed it source text and everything is compiled. Each and every expression. Why should I call a direct native code compiler an 'Interpreter'? Makes no sense. ? (let ((f (lambda (a) (+ 1 a)))) (disassemble f) (funcall f 2)) ;;; (lambda (a) (+ 1 a)) L0 (leaq (@ (:^ L0) (% rip)) (% fn)) ; [0] (cmpl ($ 8) (% nargs)) ; [7] (jne L57) ; [10] (pushq (% rbp)) ; [12] (movq (% rsp) (% rbp)) ; [13] (pushq (% arg_z)) ; [16] ;;; (+ 1 a) (leaveq) ; [17] (testb ($ 7) (% arg_z.b)) ; [18] (jne L39) ; [22] (addq ($ 8) (% arg_z)) ; [24] (jo L32) ; [28] (repz) (retq) ; [30] L32 (jmpq (@ .SPFIX-OVERFLOW)) ; [32] L39 (movl ($ 8) (% arg_y.l)) ; [39] (jmpq (@ .SPBUILTIN-PLUS)) ; [44] ;;; #<no source text> L57 (uuo-error-wrong-number-of-args) ; [57] 3 ; result
      - ggchappell 12y ago
        An interpreter is a box that takes code in some programming language and executes it. A compiler is a box that takes code is some programming language and translates it into another programming language. Traditionally, the twain ne'er did meet. However, many (most?) modern interpreters include a compiler as part of their implementation. Using a compiler in this manner is "Just in Time" (JIT) compilation. So a box that takes Clozure Common Lisp and converts it to machine code is a compiler. A box that takes Clozure Common Lisp, feeds it into this compiler to obtain machine code, and executes this machine code immediately, is an interpreter, using JIT compilation to do its interpretation.

jeffreyrogers 12y ago

There are three primary methods of running code: interpretation, compilation to object code, and running on a VM/JIT. Obviously python is interpreted by any meaningful definition of interpretation and thus it is not compiled in the typically sense of the word (at least not in the implementation everyone uses). The reason human language is so expressive is because we can leave out a lot of context and formalism that is required in mathematics and programming languages because the listener/reader will be able to infer it. It's pedantic to expect a writer to hedge against every possible interpretation, when their focus should be on communicating clearly in the first place.

andreyf 12y ago
FWIW, wikipedia says "The main Python implementation, named CPython, [...] compiles Python programs into intermediate bytecode, which is executed by the virtual machine." I'm not sure why people call Python's VM an interpreter, but it's definitely interpreting byte code, not the source directly. This is very different from Perl, where a line of code isn't parseable until you know the values of the variables, e.g. whatever / 25 ; # / ; die "this dies!";
- haberman 12y ago
  > This is very different from Perl, where a line of code isn't parseable until you know the values of the variables Perl is crazy, but I don't think it's that crazy. From perlcompile(http://perldoc.perl.org/5.8.9/perlcompile.html http://perldoc.perl.org/5.8.9/perlcompile.html) Perl has always had a compiler: your source is compiled into an internal form (a parse tree) which is then optimized before being run. If what you say is true, it would not be possible to produce a parse tree prior to running the program. I could not get your code sample to die based on the type/value of "whatever" -- can you?
  - scott_s 12y ago
    Apparently, Perl is that crazy. See https://news.ycombinator.com/item?id=5770531 https://news.ycombinator.com/item?id=5770531 Basically, you can't always parse a Perl program without running it. There is a subset that you can, not not everything.