Python vs. Lisp -- please explain

[Dennis Lee Bieber]

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.

I was spoiled by the CBM Amiga... If anything earned the name
"scripting language", it was the Amiga version of REXX
--

 

[Harald Armin Massa]

I second this motion. Even tried to persuade the site maintainer
before. We should really, really change it. The perceived speed of
Python will at least triple on dropping that "interpreted" - and I am
NOT joking.

Harald

 

[Michele Simionato]

As common lisp and scheme demonstrate you can have high level of dynamism (and
in a number of things both are more dynamic than python) and still get very
good performance (in some cases close to or better than C).

Just for personal enlightment, where do you think Lisp is more dynamic
of Python?
Can you new name a few features?

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.

If you know the language to be dog slow any way, you're much less likely to
waste your time (and that of future maintainers) on the pointless
microoptimizations that geeks so love. Also, since only builtins have
reasonable performance there's added motiviation to become very familiar with
the available builtins (and standard libarary) and far less temptation to roll
one's own version of say dict.setdefault (even if it it sucks). The fact that
non-standard library code is inherently somewhat inferior (because it will
either be written in python and slow or written in C and a pain to install)
adds further incentive to attempt community wide standardization.

I think it's not unreasonable to speculate that all this decreases production,
maintenance and reuse costs of python code considerably, so much in fact that
python's very slowness represents part of its competetive edge over languages
that are in some ways better engineered and more capable.

I think you have a very good point here. +1000!

Michele Simionato

 

[bruno at modulix]

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.

It is, of course. When we say that 'this language is
[interpreted|bytecompiled|compiled|runs on clay tablets|whatnot], we're
of course talking about the standard or reference implementation(s).

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.

So there are only interpreted languages nowadays.

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.

The only pragmatic and useful distinction I can see here is between
languages that have to re-parse the whole source for each and every
executions ('interpreted') and languages that don't.

 

[bruno at modulix]

Paul Boddie wrote:
(snip)

I'm not sure why people get all defensive about Python's
interpreted/scripting designation

Because it carries a negative connotation of "slow toy language not
suitable for 'serious' tasks". Dynamicity apart, CPython's
implementation is much closer to Java than to bash scripts - but still,
as soon as you say "interpreted, scripting", peoples think "not serious".

 

[bruno at modulix]

I second this motion. Even tried to persuade the site maintainer
before. We should really, really change it. The perceived speed of
Python will at least triple on dropping that "interpreted" - and I am
NOT joking.

+1 on this.

 

[Torsten Bronger]

Hallöchen!

[...]

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.

The only pragmatic and useful distinction I can see here is
between languages that have to re-parse the whole source for each
and every executions ('interpreted') and languages that don't.

Well, I think that it's fair to say that there are by principle deep
run time differences between CPython and, say, a typical
C++-compiled program. Your definition would not reproduce that. I
think it's also fair to say that these differences should be known
if somebody tries to find the best tool for a job. After all, they
include advantages, too.

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.

Tschö,
Torsten.

 

[Paul Boddie]

Paul Boddie wrote:
(snip)


Because it carries a negative connotation of "slow toy language not
suitable for 'serious' tasks". Dynamicity apart, CPython's
implementation is much closer to Java than to bash scripts - but still,
as soon as you say "interpreted, scripting", peoples think "not serious".

Perhaps we should blame the main man for this confusing label, then
[1]:

"From one perspective you can say Python is a very high-level scripting
language."

Interestingly, with regard to my remark about various criteria being
more appropriate when distinguishing between interactive and
non-interactive languages, we also learn the following:

"From another perspective you can say it's a high-level programming
language that happens to be implemented in a way that emphasizes
interactivity. Python shares some characteristics with scripting
languages, but also shares some characteristics with more traditional
programming languages."

Of course, we've all had this debate before, or rather everyone else
has had this debate before and I've mostly ignored whether people call
Python a scripting language, an interactive language, an agile
language, a dynamic language, an applications programming language, or
whatever. Personally, I rather think that whichever labels one chooses
to attach to a language or platform generally come about from the
success stories one can show people in relation to that language or
platform.

But there are always going to be people who contrast something like
CPython's runtime with the Java virtual machine and ask whether CPython
has, for example as one distinguishing factor, just-in-time compilation
as a generally supported feature, and such people will be genuinely
interested in why such things typically lie outside the principal
runtime development process. People like to find distinctions between
things - sometimes arbitrary ones - and make classifications that allow
them to arrange such things conveniently in their mind. What I find
quite worrying is that while in previous years people have responded to
such discussions with a critical analysis of where Python (or rather
CPython) can be improved, it's now the fashion to just trot out some
response or other which excuses rather than explains the way things
are.

Paul

[1] http://www.artima.com/intv/python.html

 

[Paul Boddie]

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

I think it's more charitable (or rather, it possibly expresses the
intent behind the quoted text more accurately or objectively) to
rephrase "ignorance on Guido's part" and "Guido... was unaware of" with
"Guido's deliberate design decisions upon considering previous work on
dynamic language runtime implementation" and "Guido chose to disregard
strategies illustrating" respectively. Not that I actually profess to
know what Guido's knowledge of the field was in the late 1980s or what
he actually knows right now beyond what he has said in various articles
and interviews.

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

Unfortunate choices of words notwithstanding, I think the contributor
in question raises interesting issues at a level way above this kind of
response. Not that I actually profess to know what his level of "CS
exposure" is beyond a brief perusal of his Google Groups profile, but I
don't see how that really comes into play here, apart from as a
convenient put-down label.

Paul

 

[Carl Friedrich Bolz]

Well, I think that it's fair to say that there are by principle deep
run time differences between CPython and, say, a typical
C++-compiled program. Your definition would not reproduce that. I
think it's also fair to say that these differences should be known
if somebody tries to find the best tool for a job. After all, they
include advantages, too.

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.

Well, if we take any modern Intel/AMD chip (which could be described as
"typical), a C++ program would fit the "interpreted" definition, since
the processor does not execute the machine code directly but rather
breaks it down into smaller microcode instruction -- a process that
could be described as intepretation.

Another problem with the definition: what would you call a C++ program
that is running on top of an emulator? Does a language become
interpreted just by running the program on top of an emulator? Why is
the python interpreter different from an emulator in this respect? I
think that the disctinction between "interpreted" and "compiled"
(whatever both means) is really just not sensible at all.

Cheers,

Carl Friedrich

 

[Kay Schluehr]

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.

Yes, it's Guidos master-plan to lock programmers into a slow language
in order to dominate them for decades. Do you also believe that Al
Quaida is a phantom organization of the CIA founded by neocons in the
early '90s who planned to invade Iraq?

Kay

 

[Torsten Bronger]

Hallöchen!

[...]

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.

Well, if we take any modern Intel/AMD chip (which could be
described as "typical), a C++ program would fit the "interpreted"
definition, since the processor does not execute the machine code
directly but rather breaks it down into smaller microcode
instruction -- a process that could be described as intepretation.

This is an interpreting layer within the hardware, not necessary for
it.

Another problem with the definition: what would you call a C++
program that is running on top of an emulator?

Compiled. I said "necessary for typical hardware".

[...] I think that the disctinction between "interpreted" and
"compiled" (whatever both means) is really just not sensible at
all.

The question is whether such features have to be considered when
choosing the right tool for a task. I think, yes. Whereas C is
very close to the fastest code you can get because it works very
closely to how the machine itself works, Python can well be one or
one and a half orders of magnitude farther away. No problem since
you can get the best of both worlds but: You must be aware of it.

Tschö,
Torsten.

 

[Alexander Schmolck]

For the convenience of other readers, allow me to restore the snipped second
half of that sentence: "... and the extent to which very
dynamic languages are suitable for writing robust software."

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

Interviewer: "You said originally you thought 500 lines would be a big
Python program."
Guido van Rossum: "That was just my lack of imagination."

<http://www.artima.com/intv/pyscale3.html>


Guido van Rossum: "Another thing, much farther in the future, is
compilation to C or machine code. I used to think that this was impossible
and (perhaps because of that) uninteresting, but recent experiments (like
Armin Rigo's Psyco and Greg Ewing's Pyrex) suggest that this will
eventually be possible. It should provide Python with an incredible
performance boost and remove many of the reasons why many people are still
reluctant to switch to Python."

<http://www.onlamp.com/pub/a/python/2002/06/04/guido.html?page=1>

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

Indeed. Your amazing reading comprehesion and lucid argumentation would
obviously be lost on my posts.

'as

 

[Donn Cave]

Quoth Carl Friedrich Bolz <[email protected]>:
| Torsten Bronger wrote:
|> Well, I think that it's fair to say that there are by principle deep
|> run time differences between CPython and, say, a typical
|> C++-compiled program. Your definition would not reproduce that. I
|> think it's also fair to say that these differences should be known
|> if somebody tries to find the best tool for a job. After all, they
|> include advantages, too.
|>
|> 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.
|
| Well, if we take any modern Intel/AMD chip (which could be described as
| "typical), a C++ program would fit the "interpreted" definition, since
| the processor does not execute the machine code directly but rather
| breaks it down into smaller microcode instruction -- a process that
| could be described as intepretation.

That's irrelevant, though. Note, "has in its typical implementation".
Your processor didn't come along with your C++ compiler, it's not part
of its implementation or even necessarily relevant to it - maybe some
potential for optimization, but the only hard and fast requirement is
that the processor must execute its instruction set as documented.

The reason this isn't just an abstruse philosophical argument where it
makes sense for us to obtusely cling to some indefensible point of view,
is that as the man points out, there are differences that we can't hide
forever from potential Python users. The most obvious to me is that
your Python program essential includes its interpreter - can't go anywhere
without it, and any change to the interpreter is a change to the program.
There are various strategies to address this, but pretending that Python
isn't interpreted is not one of them.

Donn Cave, (e-mail address removed)

 

[Cameron Laird]

.
.
.

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

Alexander, you've lost me. 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". Do you truly
believe that fewer people would use Python if its execution
were faster?

 

[Alexander Schmolck]

Alexander Schmolck a écrit :


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

It gets interpreted (by a CPU, for example) -- your point being? If it is that
my definition of interpreted language would be overly inclusive, note that the
difference between interpreting byte code is a task that at least arguably
still belongs to the python language proper (and there even is a public
bytecode interface) whereas interpreting machine code typically falls outside
the tasks and specifications of the language that generated it. In any event,
I didn't make any claims that some particular language is *not* interpreted.

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

When people (including the python website maintainers) talk about interpreted
languages they often include all languages that don't compile to machine code.
"Interpreted language" is not a terribly well defined concept and the usage of
words also changes to reflect general trends. Since pretty much no language of
any significance today is still interpreted in the sense you hold to be
canonical, when people talk about interpreted languages nowadays they (IMHO)
typically mean something else. This is just Grice in action.

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.

Python is also a scripting language for *n*x systems and various applications.

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.

A few lines ago bash was also a scripting language but I can't personally
recall ever seeing bash embedded in some application.

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


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

I'd guess dozens. Several Gnome and Kde programs, some scientific software, a
number of games and other commercial software such as UML editors.

And how many applications written in Python ?

No idea. My guess would be that there are far fewer high-profile end user
applications written in python than embedding python, though.

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

Interviewer: "Why did you create Python in the first place?"

Guido: "We wanted Amoeba to be as useful as Unix for our daily work, but it was
lacking a scripting language. So I set out to design my own."

Summary of my position: it's futile pedantry trying to correct someone who
claims that python is an interpreted scripting language, since neither of
these terms are terribly well defined and your definitions don't even seem to
be internally fully consistent and certainly have the appearance of
disagreeing with those of the creator of the language.

If you dislike people refering to python as "interpreted" you can always add
that it compiles to bytecode. But the poster you corrected was already aware
of that and mentioned it himself.

'as

 

[Alexander Schmolck]

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

Really? If someone talked about scripting languages without further
qualifications and much context would you automatically take that to exclude
modern Javascript, modern Tcl and python, perl, ruby etc.?

Or would you just think to yourself 'Ah, probably again someone who uses
"scripting language" imprecisely or incorectly'?

In pretty much any case I can think of all somewhat prominent languages even
those that started out purely in the context of scripting one particular
application (such as arguably javascript, although that sense of scripting is
definitely again distinct from the sense "providing application customization
and extension by users") by now have ursurped other tasks and don't fall
strictly under the given definition anymore. So my impression is that since
"scripting languages" as above would only refer to a very obscure set of
programming languages, almost no one uses the term strictly in that way.

This meaning can always be expressed by "application (specific) scripting
language" -- but what would you use to refer to "perl, python, ruby et al"?

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.

Interviewer: "Why did you create Python in the first place?"

Guido: "We wanted Amoeba to be as useful as Unix for our daily work, but it was
lacking a scripting language. So I set out to design my own."

So Guido certainly designed it as a "scripting language", but since the term
is so vague, he might

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.

I definitely agree that scripting language is rather ambiguous.

'as

 

[Donn Cave]

Quoth Alexander Schmolck <[email protected]>:
....
|> 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.
|
| Python is also a scripting language for *n*x systems and various applications.
|
|> 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.
|
| A few lines ago bash was also a scripting language but I can't personally
| recall ever seeing bash embedded in some application.

UNIX! The Bourne shell is exactly what M Desthuillers describes, for
the UNIX operating system. Python isn't at all - not that you can't
rename a file, change working directory, execute some processes and do
all that stuff from pure Python, but there's a clear difference in focus.
Those things the shell does rather well, at anything else it's pathetic.

Of course, scripting is naturally the domain of interpreted languages,
and most scripts are trivial in size and complexity. I guess this is
why for some people, "scripting language" just means "interpreted and
suited to writing trivial programs." It's hard to believe they're
thinking very hard about what they're saying, but so what's new?

Donn Cave, (e-mail address removed)

 

[Cameron Laird]

.
.
.


Alexander, you've lost me. 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". Do you truly
believe that fewer people would use Python if its execution
were faster?

I think I can answer my own question: yes. Since posting, I came
across a different follow-up where Alexander explains that he sees
healthy elements of the Python ethos--focus on a reliable, widely-
used library, willingness to make Python-C partnerships, and so
on--as results at least in part of early acceptance of Python as
intrinsically slow. That's too interesting an argument for me to
respond without more thought.

 

[Steven D'Aprano]

Yes, it's Guidos master-plan to lock programmers into a slow language
in order to dominate them for decades. Do you also believe that Al
Quaida is a phantom organization of the CIA founded by neocons in the
early '90s who planned to invade Iraq?

Of course not. The alternative, that Osama has been able to lug his
dialysis machine all over the Pakistan and Afghan mountains without being
detected for four years is *much* more believable. *wink*

I don't think it was the poster's implication that Guido deliberately
created a slow language for the sake of slowness. I think the implication
was more that Guido made certain design choices that increased
productivity and code clarity. (That much is uncontroversial.) Where the
poster has ruffled some feathers is his suggestion that if Guido had only
known more about the cutting edge of language design from CS, Python would
have been much faster, but also much less productive, clear and popular.

I guess the feather ruffling is because of the suggestion that Guido
merely _didn't_know_ about language features that would have increased
Python's speed at the cost of productivity, rather than deliberately
choose to emphasis productivity at the expense of some speed.