Python vs. Lisp -- please explain

[Paul Boddie]

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.

> 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. ;-)

> 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.

> 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