Python vs. Lisp -- please explain

[Chris Mellon]

On 21 Feb 2006 08:30:04 -0800, Paul Boddie <paul at boddie.org.uk> wrote:
> Chris Mellon wrote:
> >
> > You're correct as far as it goes, but can you provide a reasonable
> > definition for "interpreted" that matches the common usage? Most
> > people can't.
>
> I thought Torsten's definition was good enough: if the instructions
> typically produced when preparing your programs for execution can be
> handled directly by the CPU then let's call it a "compiled language";
> otherwise, let's call it an "interpreted language". I think we all know
> about the subtleties of different levels of virtual machines, but if
> you want an arbitrary definition that lots of people feel is intuitive
> then that's the one to go for.
>
> > When asked to name some interpreted (or scripting) languages, they'll
> > name some off - perl, python, ruby, javascript, basic...
>
> Right: compiled Perl and Python instructions typically aren't executed
> directly by the hardware; Ruby visits the parse tree when executing
> programs (see [1] for some casual usage of "interpreted" and "compiled"
> terms in this context), although other virtual machines exist [2];
> JavaScript varies substantially, but I'd imagine that a lot of the
> implementations also do some kind of parse tree walking (or that the
> developers don't feel like documenting their bytecodes), although you
> can also compile JavaScript to Java class files [3]; BASIC varies too
> much for any kind of useful summary here, but I'd imagine that early
> implementations have tainted the language's "compiled" reputation
> substantially.
>
> > They won't say Java. Ask them why Python is interpreted and Java isn't
> > and you'll have a hard time getting a decent technical answer, because
> > Python isn't all that different from Java in that regard, especially
> > pre-JIT versions of Java.
>
> That's why I put Java and Python in the same category elsewhere in this
> thread. Bear in mind, though, that Java's just-in-time compilation
> features were hyped extensively, and I imagine that many or most
> implementations have some kind of native code generation support,
> either just-in-time or ahead-of-time.
>

Early Java versions did not, and many versions still don't, at least
in any meaningful way. There are ways of compiling "native" Java, but
they work more like py2exe than GCC. "Native code generation" is a
fairly imprecise term in and of itself - Psyco works almost exactly
the same way as Java JIT does,

> > Probably the most accurate definition of "interpreted" as it is used
> > in the wild is "one of these languages: perl, python, perl, ruby,
> > etc". That is, you're essentially claiming that Python is interpreted
> > because everyone thinks of it that way, technical correctness be
> > damned.
>
> Well, I think Torsten's definition was more objective and yet arrives
> at the same result. Whether we're happy with that result, I have my
> doubts. ;-)

I don't think it does, though. Firstly, as a definition it relies on
the environment the application will be running under and therefore
can't be considered to describe just a language. Secondly, by that
definition Java is an interpreted language which is at odds with the
common definition.

I've encountered a C scripting environment that works by using GCC to
compile each line as it is encountered, doing some magic to keep a
working compilation environment around.

Interpreted? Compiled?

>
> > There is an obvious difference between Python and C. Nobody would deny
> > that. But it's a fairly hard thing to *quantify*, which is why people
> > make sloppy categorizations. That's not a problem as long as there
> > isn't prejudice associated with the categorization, which there is.
>
> I refer you again to Torsten's definition.
>

Torstens definition isn't useful for quantifying a difference between
interpeted and compiled - it's a rough sort of feel-test. It's like
how much of a naked body you can expose before before it changes from
art to pornography - it's not something that is easily quantified.

> > I wonder how "interpreted" people would think Python is if the
> > automagic compilation to .pyc was removed and you had to call
> > "pythonc" first.
>
> Well, such things might have a psychological impact, but consider
> removing Python's interactive mode in order to enhance Python's
> non-interpreted reputation, and then consider Perl (an interpreted
> language according to the now-overly-referenced definition) which
> doesn't have an interactive mode (according to [4] - I don't keep up
> with Perl matters, myself), but which allows expression evaluation at
> run-time. No-one would put Perl together with C in a compiled vs.
> interpreted categorisation. Removing the automatic compilation support
> might strengthen the compiled feel of the both languages further, but
> with knowledge of the technologies employed, both languages (at least
> in their mainstream forms) are still on the other side of the fence
> from C.
>
> Paul
>
> [1] http://www.rubygarden.org/faq/entry/show/126
> [2] http://www.atdot.net/yarv/
> [3] http://www.mozilla.org/rhino/doc.html
> [4] http://dev.perl.org/perl6/rfc/184.html
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>