Python vs. Lisp -- please explain

[Dave Hansen]

Re: Python vs. Lisp -- please explain

On Tue, 21 Feb 2006 08:36:50 -0600 in comp.lang.pytho n, "Chris Mellon"
<arkanes@gmail. com> wrote:

[...][color=blue]
>
>When asked to name some interpreted (or scripting) languages, they'll
>name some off - perl, python, ruby, javascript, basic...
>
>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.[/color]

IMHO, it's marketing. Soon after (as soon as?) Sun introduced Java,
they announced microprocessors that would implement the JVM natively.
Thus on those machines, Java would not be "interprete d."

AIUI, the reason native Java chips never took off is 1) limited
utility (who wants a chip that can only run Java programs?), and 2)
performance on native chips wasn't even better than JVMs running on
commodity microprocessors , so what's the point?
[color=blue]
>
>Probably the most accurate definition of "interprete d" 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.[/color]

I think another reason "perl, Python etc." are known to be interpreted
and Java is not is the interactivity afforded by former group. This
is also why, e.g., lisp and Forth are thought of as interpreted (at
least by those with only a passing familiarity with the languages),
though native compilers for both languages are readily available.

Regards,
-=Dave

--
Change is inevitable, progress is not.

[D H]

Re: Python vs. Lisp -- please explain

Donn Cave wrote:[color=blue]
> I can say "Python can serve as a scripting language for some applications",
> but not "Python is a scripting language!"[/color]

bruno at modulix wrote:[color=blue]
> as soon as you say "interprete d, scripting", peoples think "not
> serious".[/color]

Cameron Laird wrote:[color=blue]
> I *think* you're proposing that,
> were Guido more knowledgeable, he would have created a Python
> language that's roughly as we know now, implemented it with
> FASTER software ... and "to its own detriment".[/color]

Fredrik Lundh wrote:[color=blue]
> define "scripting language".
>
> the only even remotely formal definition I've ever seen is "language
> with designed to script an existing application, with limited support
> for handling
> its own state". Early Tcl and JavaScript are scripting languages,
> Python is not.[/color]

Kay Schluehr wrote:[color=blue]
> Yes, it's Guidos master-plan to lock programmers into a slow language
> in order to dominate them for decades.[/color]

Donn Cave wrote:[color=blue]
> All I'm saying is that Python matches
> what people think of as an interpreted language. You can deny it, but
> but it's going to look like you're playing games with words, and to no
> real end, since no one could possibly be deceived for very long.[/color]

Steven D'Aprano wrote:[color=blue]
> Describing C (or Lisp) as "compiled" and Python as "interprete d" is to
> paint with an extremely broad brush, both ignoring what actually
> happens in fact, and giving a false impression about Python. It is
> absolutely true to say that Python does not compile to machine code.
> (At least not yet.) But it is also absolutely true that Python is
> compiled. Why emphasise the interpreter, and therefore Python's
> similarity to bash, rather than the compiler and Python's similarity
> to (say) Java or Lisp?[/color]

Paul Boddie wrote:[color=blue]
> Yes, I think that with optional static typing, it's quite likely that
> we would see lots of unnecessary declarations and less reusable code
> ("ints everywhere, everyone!"), so I think the point about not
> providing people with certain features is a very interesting one,
> since
> people have had to make additional and not insignificant effort to
> optimise for speed. One potential benefit is that should better tools
> than optional static typing be considered and evaluated, the "ints
> everywhere!" line of thinking could prove to be something of a dead
> end
> in all but the most specialised applications. Consequently, the Python
> platform could end up better off, providing superior tools for
> optimising performance whilst not compromising the feel of the
> language
> and environment.[/color]

Torsten Bronger wrote:[color=blue]
> By the way, this is my main concern about optional static typing: It
> may change the target group, i.e. it may move Python closer to those
> applications where speed really matters, which again would have an
> effect on what will be considered Pythonic.[/color]

Steven D'Aprano wrote:[color=blue]
> The "Python is both interpreted and compiled" camp, who
> believe that both steps are equally important, and to
> raise one over the other in importance is misleading.
> That's why Sun doesn't describe Java as interpreted,
> but as byte-code compiled. They did that before they
> had JIT compilers to compile to machine code.[/color]

Bruno Desthuilliers wrote:[color=blue]
> It's not a "scripting" language, and it's not interpreted.[/color]


It will all be sorted out once and for all in Python 3000: The Reckoning

[Donn Cave]

Re: Python vs. Lisp -- please explain

In article <43FAD2C2.70809 08@REMOVEMEcybe r.com.au>,
Steven D'Aprano <steve@REMOVEME cyber.com.au> wrote:
....[color=blue]
> Hey Donn, here is a compiled program for the PowerPC,
> or an ARM processor, or one of IBM's Big Iron
> mainframes. Or even a Commodore 64. What do you think
> the chances are that you can execute it on your
> x86-compatible PC? It's compiled, it should just
> work!!! Right?
>
> No of course not. If your CPU can't interpret the
> machine code correctly, the fact that the code is
> compiled makes NO difference at all.
>
> In other words, I have three choices:
>
> - cross my fingers and hope that you have the required
> interpreter (CPU);
>
> - slip in an interpreter install (perhaps an emulator)
> and hope you won't notice;
>
> - or come clean and tell you that my program needs an
> interpreter ("Hey Donn, do you have a Mac you can run
> this on?") and you should check to see that you have it.[/color]

Sure, all this is true, except for the term "interprete r."
You would surely not use the word that way, unless you
just didn't want to communicate.

Your paragraph above that starts with "No of course not",
even omits a point that everyone understands, you can in
fact expect a .py file will work independent of machine
architecture - like any interpreted language. We all know
what native code compilation buys you and what it doesn't.

Donn Cave, donn@u.washingt on.edu

[Chris Mellon]

Re: Python vs. Lisp -- please explain

On 21 Feb 2006 08:30:04 -0800, Paul Boddie <paul@boddie.or g.uk> wrote:[color=blue]
> Chris Mellon wrote:[color=green]
> >
> > You're correct as far as it goes, but can you provide a reasonable
> > definition for "interprete d" that matches the common usage? Most
> > people can't.[/color]
>
> 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 "interprete d 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.
>[color=green]
> > When asked to name some interpreted (or scripting) languages, they'll
> > name some off - perl, python, ruby, javascript, basic...[/color]
>
> 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 "interprete d" 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.
>[color=green]
> > 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.[/color]
>
> 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.
>[/color]

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,
[color=blue][color=green]
> > Probably the most accurate definition of "interprete d" 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.[/color]
>
> 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. ;-)[/color]

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?
[color=blue]
>[color=green]
> > 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.[/color]
>
> I refer you again to Torsten's definition.
>[/color]

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.
[color=blue][color=green]
> > I wonder how "interprete d" people would think Python is if the
> > automagic compilation to .pyc was removed and you had to call
> > "pythonc" first.[/color]
>
> 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
>[/color]

[Donn Cave]

Re: Python vs. Lisp -- please explain

In article <mailman.2231.1 140532613.27775 .python-list@python.org >,
"Chris Mellon" <arkanes@gmail. com> wrote:
....[color=blue]
> 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.[/color]

For me that would be partly because I don't know that
much about Java, honestly. Just searching at random
for something about the subject, I cam across this -

http://www-128.ibm.com/developerworks/java/library/j-native.html?loc=j

- which seems like it might be of some interest here.

My impression from reading this is that Java actually
can be compiled to native code, though in 2002 this
was relatively new.

Donn Cave, donn@u.washingt on.edu

[Steve Holden]

Re: Python vs. Lisp -- please explain

Chris Mellon wrote:
[...][color=blue]
> 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.
>[/color]
[...]

Possibly, but if your aim is exposing as much flesh as possible without
being labeled pornography I think I'd conclude you were in the
pornography business from the start, albeit masquerading as an "art dealer".

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Pietro Campesato]

Re: Python vs. Lisp -- please explain

> As they say, case is the difference between "I helped my[color=blue]
> Uncle Jack off a horse" and "I helped my uncle jack off a horse."[/color]

Hahaha!... never heard of that though

[Steven D'Aprano]

Re: Python vs. Lisp -- please explain

On Tue, 21 Feb 2006 09:46:27 -0800, Donn Cave wrote:
[color=blue]
> In article <43FAD2C2.70809 08@REMOVEMEcybe r.com.au>,
> Steven D'Aprano <steve@REMOVEME cyber.com.au> wrote:
> ...[color=green]
>> Hey Donn, here is a compiled program for the PowerPC,
>> or an ARM processor, or one of IBM's Big Iron
>> mainframes. Or even a Commodore 64. What do you think
>> the chances are that you can execute it on your
>> x86-compatible PC? It's compiled, it should just
>> work!!! Right?
>>
>> No of course not. If your CPU can't interpret the
>> machine code correctly, the fact that the code is
>> compiled makes NO difference at all.[/color][/color]

[snip for brevity]
[color=blue]
> Sure, all this is true, except for the term "interprete r."
> You would surely not use the word that way, unless you
> just didn't want to communicate.[/color]

Do you honestly believe that the CPU doesn't have to interpret the machine
code, or are you just deliberately playing silly buggers with language?

In modern CPUs, there is an intermediate layer of micro-code between the
machine code your C compiler generates and the actual instructions
executed in hardware. But even if we limit ourselves to obsolete hardware
without micro-code, I ask you think about what an interpreter does, and
what the CPU does, in the most general way possible.

Both take a stream of instructions. Both have to take each instruction,
and execute it. In both cases the link between the instruction and the
effect is indirect: for example, the machine code 00000101 on the
Zilog Z80 processor causes the CPU to decrement the B processor register.
In assembly language this would be written as DEC B. There is absolutely
nothing fundamental about the byte value 5 that inherently means
"decrement B processor register".

In other words, machine language is a language, just like it says, and
like all languages, it must be interpreted.
[color=blue]
> Your paragraph above that starts with "No of course not",
> even omits a point that everyone understands, you can in
> fact expect a .py file will work independent of machine
> architecture - like any interpreted language.[/color]

Amazing. In your previous post you were telling everybody how the
*disadvantage* of interpreted programs is that they won't run unless the
interpreter is present, and in this post you are telling us that
interpreted languages will just work. What happened to the requirement for
an interpreter?

Let's see you run that Python program on a Zilog Z80 without a Python
interpreter. Can't be done. No interpreter, whether in hardware or
software, and the program won't run, whether in source code or byte code
or machine code.

If I allow that the machines have an interpreter, perhaps you'll return
the favour and install an interpreter for machine language (often called
an emulator). Now your compiled C or Lisp code also will run independent
of machine architecture.

In order to force "interprete d language" and "compiled language" into two
distinct categories, rather than just two overlapping extremes of a single
unified category, you have to ignore reality. You ignore interpreted
languages that are compiled, you ignore the reality of how machine code is
used in the CPU, you ignore the existence of emulators, and you ignore
virtual machines.

[color=blue]
> We all know
> what native code compilation buys you and what it doesn't.[/color]

Did you fail to learn *anything* from my parable of interpreted Lisp on a
Macintosh II running faster than compiled Lisp running on a Mac II fitted
with a Lisp processor?


--
Steven

[Carl Friedrich Bolz]

Re: Python vs. Lisp -- please explain

Chris Mellon wrote:
[snip][color=blue]
> 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?
>[/color]

There is also the wonderful C interpreter cint:

http://root.cern.ch/root/Cint.html

so obviously C must be an interpreted language :-)

Cheers,

Carl Friedrich Bolz

[Peter Mayne]

Re: Python vs. Lisp -- please explain

Torsten Bronger wrote:[color=blue]
>
> My definiton would be that an interpreted language has in its
> typical implementation an interpreting layer necessary for typical
> hardware. Of couse, now we could discuss what is "typical",
> however, in practice one would know it, I think. In case of Python:
> CPython and all important modern processors.[/color]

In a previous century, I used something called UCSD Pascal, which at the
time was a typical implementation of Pascal. It ran on (amongst other
things) an Apple ][, which at the time was typical hardware. It worked
by compiling Pascal source to bytecode (called p-code), and interpreting
the p-code. So, in practice, one would know that Pascal was an
interpreted language.

Later on, I used a typical implementation called VAX Pascal: a compiler
reduced Pascal source to VAX object code. In practice, Pascal was not an
interpreted language. Of course, more than one of the VAXen we had did
not implement the entire VAX instruction set, and some instructions were
emulated, or interpreted, if you will, by other VAX instructions. So, in
practice, some of the Pascal was interpreted.

And, as someone in this thread has pointed out, it is likely that your
important modern (x86) processor is not natively executing your x86
code, and indeed meets your definition of having "in its typical
implementation an interpreting layer necessary for typical hardware".

Another example: is Java the bytecode, which is compiled from Java the
language, interpreted or not? Even when the HotSpot JIT cuts in? Or when
a native Java processor is used? Or when your Java program is compiled
with GCJ (if GCJ does what I think it does)? Does this make Java an
interpreted language or not?

Personally, in practice I don't care, so don't ask me. Ponder on getting
angels to dance on the head of a pin before you worry about whether the
dance can be interpreted or not.

PJDM

[Donn Cave]

Re: Python vs. Lisp -- please explain

Quoth Steven D'Aprano <steve@REMOVETH IScyber.com.au> :
....
| Do you honestly believe that the CPU doesn't have to interpret the machine
| code, or are you just deliberately playing silly buggers with language?

I don't care whether the CPU has to interpret machine code. Are
you suggesting that we might in normal conversation wish to use
the term interpreter to mean CPU, like "what kind of interpreter
does your computer have?", that kind of thing?

| > Your paragraph above that starts with "No of course not",
| > even omits a point that everyone understands, you can in
| > fact expect a .py file will work independent of machine
| > architecture - like any interpreted language.
|
| Amazing. In your previous post you were telling everybody how the
| *disadvantage* of interpreted programs is that they won't run unless the
| interpreter is present, and in this post you are telling us that
| interpreted languages will just work. What happened to the requirement for
| an interpreter?

Look, this is my last post on this matter, because you have evidently
reached a point where every statement has to be spelled out in excruciating
detail to avoid absurd interpretations . "will work independent of machine
architecture" does not declare that it is absolutely guaranteed to work -
after all, it may have some other flaw that will prevent it from working
anywhere. It just says that if it doesn't work, it isn't because it
tried to execute on the wrong machine architecture - the file is machine
architecture independent. You know that, you know I know that. What
is the fucking problem?

| In order to force "interprete d language" and "compiled language" into two
| distinct categories, rather than just two overlapping extremes of a single
| unified category, you have to ignore reality. You ignore interpreted
| languages that are compiled, you ignore the reality of how machine code is
| used in the CPU, you ignore the existence of emulators, and you ignore
| virtual machines.

Anyone with an interest in computer programming is likely to know what
microcode means, that there are emulators, virtual machines, etc. You
might find the UCSD Pascal system interesting, to harken back to the
early days of my experience with computers, a fascinating twist on the
interpreted/compiled story. Interesting as perspective, but it wouldn't
change the way we apply these words to Python.

Donn Cave, donn@drizzle.co m

[Torsten Bronger]

Re: Python vs. Lisp -- please explain

Hallöchen!

Peter Mayne <Peter.Mayne@hp .com> writes:
[color=blue]
> Torsten Bronger wrote:
>[color=green]
>> My definiton would be that an interpreted language has in its
>> typical implementation an interpreting layer necessary for typical
>> hardware. Of couse, now we could discuss what is "typical",
>> however, in practice one would know it, I think. In case of Python:
>> CPython and all important modern processors.[/color]
>
> In a previous century, I used something called UCSD Pascal, which at
> the time was a typical implementation of Pascal.[/color]

Not "a" typical implementation but "its".
[color=blue]
> [...]
>
> And, as someone in this thread has pointed out, it is likely that
> your important modern (x86) processor is not natively executing
> your x86 code, and indeed meets your definition of having "in its
> typical implementation an interpreting layer necessary for typical
> hardware".[/color]

Only if you deliberately misunderstand me.
[color=blue]
> Another example: is Java the bytecode, which is compiled from Java
> the language, interpreted or not? Even when the HotSpot JIT cuts
> in?[/color]

It is partly interpreted and partly compiled. That's why it's
faster than Python.
[color=blue]
> [...]
>
> Personally, in practice I don't care, so don't ask me. Ponder on
> getting angels to dance on the head of a pin before you worry
> about whether the dance can be interpreted or not.[/color]

I agree that the term "interprete d" is bad Python advocacy because
its implications are often misunderstood. However, I think that
it's fair to make a distiction between compiled and interpreted
languages because it may affect one's decision for one or the other.
Although I'm surely not ingenious, I can make this distinction.

The reason why Python is slower than C is because there is an
interpreting layer that C doesn't have. And the reason for this is
that Python's nature is incompatible with today's CPUs (which was a
deliberate and advantageous design decision). I'm sure that a
willing CS person could define this more clearly.

Anyway, if we drop "scripting" and drop "interprete d", what do you
want to tell people asking why Python is so slow? Because it is
dynamic? ;-)

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Steven D'Aprano]

Re: Python vs. Lisp -- please explain

On Wed, 22 Feb 2006 10:15:21 +0100, Torsten Bronger wrote:
[color=blue][color=green]
>> And, as someone in this thread has pointed out, it is likely that
>> your important modern (x86) processor is not natively executing
>> your x86 code, and indeed meets your definition of having "in its
>> typical implementation an interpreting layer necessary for typical
>> hardware".[/color]
>
> Only if you deliberately misunderstand me.[/color]

If the words you choose to use have implications which you failed to
realise before saying them, don't blame the reader for spotting those
implications.


[color=blue][color=green]
>> Another example: is Java the bytecode, which is compiled from Java the
>> language, interpreted or not? Even when the HotSpot JIT cuts in?[/color]
>
> It is partly interpreted and partly compiled. That's why it's faster
> than Python.[/color]

But Python is partly interpreted and partly compiled too, so that can't be
the answer.

I think we all know what the answer is. The Python interpreter isn't as
fast as the Java interpreter, or most machine code interpreters built into
hardware.

On the other hand, I'm pretty sure that interpreted Python runs faster on
my current PC than compiled code runs on the 20 year old Macintosh in my
cupboard. So "compiled" isn't a magic wand that makes code run faster.


[color=blue][color=green]
>> [...]
>>
>> Personally, in practice I don't care, so don't ask me. Ponder on
>> getting angels to dance on the head of a pin before you worry about
>> whether the dance can be interpreted or not.[/color]
>
> I agree that the term "interprete d" is bad Python advocacy because its
> implications are often misunderstood. However, I think that it's fair
> to make a distiction between compiled and interpreted languages because
> it may affect one's decision for one or the other. Although I'm surely
> not ingenious, I can make this distinction.[/color]

Would you rather use a blindingly fast interpreted language, or a
slow-as-continental drift compiled one?

This isn't a rhetorical question. In the mid-80s, Apple and Texas
Instruments collaborated on a Macintosh II computer with a Lisp
coprocessor. The problem was, according to benchmarks at the time, Lisp
compiled and run natively on the coprocessor was actually slower than Lisp
interpreted on a standard Macintosh II.

I'm sure that's hardly the only example of a speedy interpreted language
beating a glacial compiled one.

[color=blue]
> The reason why Python is slower than C is because there is an
> interpreting layer that C doesn't have.[/color]

The primary reason Python is slower than C is because C compilers have
been optimized to create fast code, while Python has been created to
optimize programmer productivity instead. That means that a simple
instruction like x + y does a lot more work in Python than it does in C.

There are other languages that, like Python, are dynamic, interpreted,
interactive and the rest, and they execute faster than Python. (By the
same token, there are also some that execute slower than Python.) Let's be
honest here: it isn't that Python can't be as fast as C, it is that the
Python Dev team have had other priorities.

But over time, as PyPy, Psycho, and other technologies bear fruit, Python
will speed up, even though it will remain interpreted.

[color=blue]
> And the reason for this is that
> Python's nature is incompatible with today's CPUs (which was a
> deliberate and advantageous design decision). I'm sure that a willing
> CS person could define this more clearly.
>
> Anyway, if we drop "scripting" and drop "interprete d", what do you want
> to tell people asking why Python is so slow? Because it is dynamic? ;-)[/color]

Who says Python is so slow? I've just got Python to count from 0 up to
100,000, and it only took 7 milliseconds. That's at least 12 milliseconds
faster than I can count on my fingers.

But seriously... why not tell them the truth? Python is slower than some
other languages because optimization for execution speed has not been the
primary focus of Python's development. If you tell them that Python is
slow because it is interpreted, they will believe that Python will always
be slow. If you tell them that Python is slow because speed has not been
the priority, they will believe that some day it will become the priority,
and then Python will get faster. And they will be right. That is the aim
of PyPy after all.




--
Steven.

[Kay Schluehr]

Re: Python vs. Lisp -- please explain


Steven D'Aprano wrote:
[color=blue]
> But over time, as PyPy, Psycho, and other technologies bear fruit, Python
> will speed up, even though it will remain interpreted.[/color]

I talked to Richard Emslie recently and he told me that the PyPy team
works on a mechanism to create CPython-extension modules written in
RPython i.e. a statically translateable subset of Python. So even
without dynamic code specialization there will be an optimization path
based on the PyPy toolchain that is amazing.

Kay

[Paul Rubin]

Re: Python vs. Lisp -- please explain

"Kay Schluehr" <kay.schluehr@g mx.net> writes:[color=blue]
> I talked to Richard Emslie recently and he told me that the PyPy team
> works on a mechanism to create CPython-extension modules written in
> RPython i.e. a statically translateable subset of Python. So even
> without dynamic code specialization there will be an optimization path
> based on the PyPy toolchain that is amazing.[/color]

Sounds great but is that a whole lot different from pyrex?