Python vs. Lisp -- please explain

[Fredrik Lundh]

What's far more interesting to me, however, is that I think there a good
reasons to suspect python's slowness is more of a feature than a flaw: I'd not
be suprised if on the whole it greatly increases programmer productivity and
results in clearer and more uniform code.

So ironically, some share of python's success might actually be due to
ignorance on Guido's part

it didn't, for even a millisecond, strike you that maybe, just maybe, the
"make it as dynamic as we possibly can" choice was made on purpose ?

</F>

 

[Fredrik Lundh]

You might want to argue about whether scriping language is a meaningful and
useful concept, but it's really hard to see how you could talk about "scripting
languages" without including python.

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.

</F>

 

[63q2o4i02]

Great, thanks for a very complete answer.
michael

 

[Ed Jensen]

It's not a "scripting" language, and it's not interpreted.

http://www.python.org/doc/faq/general.html#what-is-python

"Python is an interpreted, interactive, object-oriented programming
language."

 

[63q2o4i02]

Great, thank you and everyone for this nice discussion.

Michael

 

[Torsten Bronger]

Hallöchen!

Alexander Schmolck a écrit :

[...]

It's not a "scripting" language, and it's not interpreted.

Of course it is. What do you think happens to the bytecode?

Ok, then what do you think happens to 'machine' code ?

"interpreted" usually means "no compilation, all parsing etc
redone at each execution", which is not the case with a
bytecode/vm based implementation.

That sounds like an implementation feature rather than a language
feature. Besides, it's not a very sensible distinction in my
opinion. Much better is to think about the structure of the
interpreting machine. I'm not a CS person (only a physicist) but if
you *need* a bytecode interpreter on top of the CPU interpretation,
it's an interpreted language to me.

I've had such a discussion about TeX already, and my personal
conclusion was that you can defend almost any opinion in that area.
However, one should ensure that the definitions make a pragmatic and
useful distinction.

Tschö,
Torsten.

 

[Paul Boddie]

Hallöchen!

Such criteria sound more like those which would distinguish interactive
languages from others.

That sounds like an implementation feature rather than a language
feature. Besides, it's not a very sensible distinction in my
opinion. Much better is to think about the structure of the
interpreting machine.

And it's even better to think about the nature of the machine...

I'm not a CS person (only a physicist) but if
you *need* a bytecode interpreter on top of the CPU interpretation,
it's an interpreted language to me.

Yet one could potentially have that bytecode interpreter in hardware.
What typically prevents this is the potential difficulty of realising
complicated software designs in reasonably priced hardware, thus
introducing the nature of the machine: how complicated the instructions
are, what additional support would be required for implementing those
instructions, and so on. Low-level or systems programming languages are
compilable to instructions which are convenient to implement in
hardware and require little additional support: concepts such as stacks
(for various purposes) are supported by machine instructions and
registers, for example, whereas more advanced memory management is left
to software running on top of the virtual machine (although I imagine
that various Lisp machines did some interesting things in this domain).

I've had such a discussion about TeX already, and my personal
conclusion was that you can defend almost any opinion in that area.
However, one should ensure that the definitions make a pragmatic and
useful distinction.

Agreed. The CPython virtual machine consists of "complicated"
instructions: that is, some of those instructions may involve
non-trivial amounts of work and may be integrated with other subsystems
that can realistically only be implemented in software. Even virtual
machines like that of the Java platform have moderately high-level
instructions, resulting in various "Java optimised" hardware
implementations not attempting to provide a complete coverage of all
the available instructions (as far as I am aware).

I'm not sure why people get all defensive about Python's
interpreted/scripting designation or about the details of the CPython
implementation, especially considering that the virtual machine
technology in use has been around for a decade and a half, and that
various projects have been experimenting with alternatives.

Paul

 

[Bruno Desthuilliers]

DH a écrit :
(snip)

It is by design. Python is dynamically typed. It is essentially an
interpreted scripting language like javascript or ruby or perl,

It's not a "scripting" language, and it's not interpreted.

although
python fans will be quick to tell you python is compiled to byte code.

CQFD.

 

[Steven D'Aprano]

Of course it is. What do you think happens to the bytecode?

By that logic, all languages are interpreted. What do you think happens to
the machinecode?

 

[Alexander Schmolck]

it didn't, for even a millisecond, strike you that maybe, just maybe, the
"make it as dynamic as we possibly can" choice was made on purpose ?

Python is far less dynamic than smalltalk, and presumably also self (last time
I checked there was no implementation for x86, so I have no practical
experience with self). Even common lisp could reasonably be called more
dynamic than python. And all these language communities did in fact still
manage to come up with efficient implementations.

Thus the "make it as dynamic as it possibly can" choice is hardly the cause
for python's slowness, so what's your point?

My point was that Guido probably (and fortunately!) was unaware of the extent
to which you can have both dynamism and speed and the extent to which very
dynamic languages are suitable for writing robust software. I'm pretty sure I
remember reading stuff by Guido himself in which he indicated that he
originally thought that a language with a similar level of dynamism as python
had to be slow anyway and I'm also pretty sure that I read some other stuff by
him which indicates that he thought a language like python would be only
suitable for relatively small scale development. If you don't doubt he wrote
that I'm not sure what we're disagreeing about (because clearly both
statements are wrong), if you do maybe I or someone else can find the right
reference, or maybe I really misremembered.

Anyayw, I'm pretty sure that Guido wouldn't have bothered to add things like
compiler macros to python, whatever his level of his technical expertise
concerning efficient implementations of highly dynamic languages might have
been.

However I don't find it at all implausible to assume that had Guido known all
the stuff that say, David Ungar and Guy Steele were aware of at the same time,
python would have come out not necessarily less dynamic but considerably
faster -- to its own detriment.

'as

 

[Bruno Desthuilliers]

Alexander Schmolck a écrit :

Of course it is. What do you think happens to the bytecode?

Ok, then what do you think happens to 'machine' code ?

"interpreted" usually means "no compilation, all parsing etc redone at
each execution", which is not the case with a bytecode/vm based
implementation.

And if python
isn't a scripting language, then what on earth is?

bash is a scripting language for *n*x systems. javascript is a scripting
language for web browsers. VBScript is a scripting language for MS
applications.

You might want to argue about whether scriping language is a meaningful and
useful concept,

A scripting languagee is a language whose main purpose is to be embbeded
in an application to provide the user a way of programmaticaly automate
some tedious tasks.

Now you could of course argue about what is an application...

but it's really hard to see how you could talk about "scripting
languages" without including python.

Ho, really ? How many applications using Python as scripting language ?
And how many applications written in Python ?

Python *can* be used as a scripting language (and is not too bad at it),
but it *is* not a scripting language.

 

[Steven D'Aprano]

Such criteria sound more like those which would distinguish interactive
languages from others.

How can that be? Python is interactive, and yet it has a bytecode/vm
implementation.

And I'm just waiting for somebody to mention Forth, which completely
breaks down the barriers between compilation and interpretation. In a
world of virtual machines, bytecode compilers, CPUs which emulate other
CPUs using embedded software, and Forth, I would have thought that it was
as obvious as the Sun in the sky that compiled versus interpreted is a
false dichotomy.

And it's even better to think about the nature of the machine...

Is it? Why? Do you particularly know what happens when your machine code
hits the CPU?

Yet one could potentially have that bytecode interpreter in hardware.

Not potentially, in actuality. I know of only one example, and it
wasn't commercially success, but in 1993 IBM developed a version of
the PowerPC RISC chip that had support for the Intel x86 instruction set.

What has been done once can be done again.

[snip]

I'm not sure why people get all defensive about Python's
interpreted/scripting designation or about the details of the CPython
implementation, especially considering that the virtual machine
technology in use has been around for a decade and a half, and that
various projects have been experimenting with alternatives.

I can't speak for others, but for me it is because generally the people
who are the quickest to insist that Python is interpreted appear to mean
it as a put-down. I never hear "Python has the rapid development and
flexibility that only an interpreted language can give", it is always "Of
course Python is slow, it is interpreted, what do you expect?".

Even if they themselves are perfectly aware of the subtle shades of
modern language design, and that interpretation does not mean that every
line of code is parsed repeatedly as it is run, it seems to me that very
often they don't mind one bit if others, less informed than them, come
away with that impression.

Let's be frank: "interpreted language" has negative connotations which may
have been valid in the 1960s and perhaps even the 1970s, but are no longer
automatically valid. Nevertheless, those connotations stick around,
generally amongst the less knowledgeable. That hurts Python's commercial
success, and Python's commercial success is vital for anyone who wishes to
get paid to program in Python.

 

[Valentino Volonghi aka Dialtone]

By that logic, all languages are interpreted. What do you think happens to
the machinecode?

Interpreted to transistors state by an internal mapping in the CPU
opcode ==> input configuration.

 

[Alexander Schmolck]

define "scripting language".

Pretty much any definition that isn't practically useless would do. I'd
personally opt for something like:

A language that doesn't make all common simple tasks difficult and painful.

If that sounds too wishy-washy, note that I specifically question whether
scripting language is a useful and meaningful concept to start with -- I just
find it silly to take issue with calling python a scripting language but not
with the term scripting language itself (especially given that even the python
tutorial talks about python scripts and that almost anyone who uses the term
would include python).

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.

Right. Which shows that by this definition scripting language is not a
meaningful and useful concept. No one will understand you correctly when you
refer to "scripting language" and mean only something like the above -- and
unless you spend a lot of your time talking about early tcl and early
javascript I doubt you'd need a word for it, either.

'as

 

[Terry Reedy]

Of course it is. What do you think happens to the bytecode?

Ok, then what do you think happens to 'machine' code ?

I believe that on modern CISC processors the human level 'machine code' is
interpreted by subroutines written in the actual machine code usually
called 'microcode'.

tjr

 

[Paul Boddie]

How can that be? Python is interactive, and yet it has a bytecode/vm
implementation.

The criteria were "no compilation, all parsing etc redone at each
execution": things which would possibly describe features of a language
where much use is made of an interactive mode, and where there wouldn't
be many advantages in generating instructions in another form for later
execution. Not that this applies to Python, since it does compile
source code to bytecode instructions as we all know, and the only
re-parsing occurs in well-defined circumstances, but there have been
other "dare I say scripting?" languages whose execution models have
apparently involved ASTs instead of virtual machine instruction sets.

[...]

Is it? Why? Do you particularly know what happens when your machine code
hits the CPU?

In general, yes: it's interpreted by a virtual machine implementation
in hardware. But this is where the nature of the machine is important,
as I originally wrote, since you don't want highly complicated
instructions implemented in hardware for a variety of well-understood
reasons.

[...]

Let's be frank: "interpreted language" has negative connotations which may
have been valid in the 1960s and perhaps even the 1970s, but are no longer
automatically valid. Nevertheless, those connotations stick around,
generally amongst the less knowledgeable. That hurts Python's commercial
success, and Python's commercial success is vital for anyone who wishes to
get paid to program in Python.

I think we're mostly in agreement here. My point was, as usual,
tangential: there is a certain class of instructions conveniently or
economically implementable in hardware; CPython's runtime also has
instructions more complicated than those. Consequently, when people
used to speculate about Python CPUs and other magical devices that
would make Python run much faster (see [1] for more recent material
which doesn't specifically do so, although I believe the speaker made
references to such devices; see [2] for an old mailing list thread),
one has to accept that there are certain constraints that have a severe
effect on whether such devices are viable or not. If some people want
to classify runtime environments on this basis then I don't have a
problem with that, provided that they are honest about it and put
things like the Java VM in the same category as CPython.

Paul

[1]
http://www.python-in-business.org/ep2005/talk.chtml?talk=2116&track=692
[2]
http://mail.python.org/pipermail/python-list/1999-June/thread.html#4543

 

[Alex Martelli]

DH a écrit :
(snip)

It's not a "scripting" language, and it's not interpreted.

OK, but then we should change <http://python.org/doc/Summary.html>,
which starts with "Python is an interpreted, interactive,
object-oriented programming language." -- if "it's not interpreted",
then why is this crucial page on Python's main site lying outright?


Alex

 

[Alex Martelli]

Ho, really ? How many applications using Python as scripting language ?

http://wiki.python.org/moin/AppsWithPythonScripting lists many, but it's
obviously woefully incomplete -- e.g., it's missing Civilization IV, a
very popular, major new game whose use of Python has been in the news a
lot. Besides, with ActiveScripting on Windows and Apple Events on the
Mac, all normal applications on both widespread platforms are "using
Python as scripting language", at least potentially -- that makes it
essentially a desperate task to try to count them all...:-(


Alex

 

[Fredrik Lundh]

My point was that Guido probably (and fortunately!) was unaware of the extent
to which you can have both dynamism and speed

any my point was that chosing to ignore something doesn't mean
that you're ignorant.

(but since you keep repeating this nonsense, it's clear that you're
pretty ignorant wrt. software design. too much CS exposure?).

</F>

 

[Donn Cave]

Quoth Alexander Schmolck <[email protected]>:
....
|> 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.
|
| Right. Which shows that by this definition scripting language is not a
| meaningful and useful concept. No one will understand you correctly when you
| refer to "scripting language" and mean only something like the above -- and
| unless you spend a lot of your time talking about early tcl and early
| javascript I doubt you'd need a word for it, either.

Oddly enough, that's what I understand it to mean, too, so you can't
strictly say "no one".

On the other hand, I think it's obvious that a language like Python could
be used for scripting, without having been specifically designed for it as
described above. There's an ambiguity in the phrase, out of context -
I can say "Python can serve as a scripting language for some applications",
but not "Python is a scripting language!", since its place in the taxonomy
of languages would be somewhere else.

Donn Cave, (e-mail address removed)