Python vs. Lisp -- please explain

[Torsten Bronger]

Re: Python vs. Lisp -- please explain

Hallöchen!

bruno at modulix <onurb@xiludom. gro> writes:
[color=blue]
> Torsten Bronger wrote:
>[color=green]
>> [...]
>>
>> 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.[/color]
>
> 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.[/color]

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.

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

[Paul Boddie]

Re: Python vs. Lisp -- please explain

bruno at modulix wrote:[color=blue]
> Paul Boddie wrote:
> (snip)
>[color=green]
> > I'm not sure why people get all defensive about Python's
> > interpreted/scripting designation[/color]
>
> 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 "interprete d, scripting", peoples think "not serious".[/color]

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]

Re: Python vs. Lisp -- please explain

Fredrik Lundh wrote:[color=blue]
> Alexander Schmolck wrote:
>[color=green]
> > My point was that Guido probably (and fortunately!) was unaware of the extent
> > to which you can have both dynamism and speed[/color]
>
> any my point was that chosing to ignore something doesn't mean
> that you're ignorant.[/color]

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.
[color=blue]
> (but since you keep repeating this nonsense, it's clear that you're
> pretty ignorant wrt. software design. too much CS exposure?).[/color]

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]

Re: Python vs. Lisp -- please explain

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

Well, if we take any modern Intel/AMD chip (which could be described as
"typical), a C++ program would fit the "interprete d" 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 "interprete d" and "compiled"
(whatever both means) is really just not sensible at all.

Cheers,

Carl Friedrich

[Kay Schluehr]

Re: Python vs. Lisp -- please explain

> What's far more interesting to me, however, is that I think there a good[color=blue]
> 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.[/color]

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]

Re: Python vs. Lisp -- please explain

Hallöchen!

Carl Friedrich Bolz <cfbolz@gmx.d e> 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]
>
> Well, if we take any modern Intel/AMD chip (which could be
> described as "typical), a C++ program would fit the "interprete d"
> 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.[/color]

This is an interpreting layer within the hardware, not necessary for
it.
[color=blue]
> Another problem with the definition: what would you call a C++
> program that is running on top of an emulator?[/color]

Compiled. I said "necessary for typical hardware".
[color=blue]
> [...] I think that the disctinction between "interprete d" and
> "compiled" (whatever both means) is really just not sensible at
> all.[/color]

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.

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

[Alexander Schmolck]

Re: Python vs. Lisp -- please explain

"Fredrik Lundh" <fredrik@python ware.com> writes:
[color=blue]
> Alexander Schmolck wrote:
>[color=green]
> > My point was that Guido probably (and fortunately!) was unaware of the extent
> > to which you can have both dynamism and speed[/color][/color]

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."
[color=blue]
> any my point was that chosing to ignore something doesn't mean
> that you're ignorant.[/color]

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>

[color=blue]
> (but since you keep repeating this nonsense, it's clear that you're
> pretty ignorant wrt. software design. too much CS exposure?).[/color]

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

'as

[Donn Cave]

Re: Python vs. Lisp -- please explain

Quoth Carl Friedrich Bolz <cfbolz@gmx.de> :
| 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 "interprete d" 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, donn@drizzle.co m

[Cameron Laird]

Re: Python vs. Lisp -- please explain

In article <yfsbqx3ov29.fs f@oc.ex.ac.uk>,
Alexander Schmolck <a.schmolck@gma il.com> wrote:

[Alexander Schmolck]

Re: Python vs. Lisp -- please explain

Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.fr> writes:
[color=blue]
> Alexander Schmolck a écrit :[color=green]
> > Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.fr> writes:
> >[/color]
>[color=green][color=darkred]
> >>DH a écrit :
> >>(snip)
> >>
> >>>It is by design. Python is dynamically typed. It is essentially an
> >>>interprete d scripting language like javascript or ruby or perl,
> >>
> >>
> >>It's not a "scripting" language, and it's not interpreted.[/color]
> > Of course it is. What do you think happens to the bytecode?[/color]
>
>
> Ok, then what do you think happens to 'machine' code ?[/color]

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.

[color=blue]
> "interprete d" usually means "no compilation, all parsing etc redone at each
> execution", which is not the case with a bytecode/vm based implementation.[/color]

When people (including the python website maintainers) talk about interpreted
languages they often include all languages that don't compile to machine code.
"Interprete d 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.
[color=blue][color=green]
> > And if python
> > isn't a scripting language, then what on earth is?[/color]
>
>
> 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.[/color]

Python is also a scripting language for *n*x systems and various applications.
[color=blue][color=green]
> > You might want to argue about whether scriping language is a meaningful and
> > useful concept,[/color]
>
> 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.[/color]

A few lines ago bash was also a scripting language but I can't personally
recall ever seeing bash embedded in some application.
[color=blue]
> Now you could of course argue about what is an application...
>[color=green]
> > but it's really hard to see how you could talk about "scripting
> > languages" without including python.[/color]
>
> Ho, really ? How many applications using Python as scripting language ?[/color]

I'd guess dozens. Several Gnome and Kde programs, some scientific software, a
number of games and other commercial software such as UML editors.
[color=blue]
> And how many applications written in Python ?[/color]

No idea. My guess would be that there are far fewer high-profile end user
applications written in python than embedding python, though.
[color=blue]
> Python *can* be used as a scripting language (and is not too bad at it), but
> it *is* not a scripting language.[/color]


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 "interprete d" 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]

Re: Python vs. Lisp -- please explain

"Donn Cave" <donn@drizzle.c om> writes:
[color=blue]
> Quoth Alexander Schmolck <a.schmolck@gma il.com>:
> | "Fredrik Lundh" <fredrik@python ware.com> writes:
> ...
> |> 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".[/color]

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 "applicatio n (specific) scripting
language" -- but what would you use to refer to "perl, python, ruby et al"?
[color=blue]
> 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.[/color]


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

[color=blue]
> 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.[/color]

I definitely agree that scripting language is rather ambiguous.

'as

[Donn Cave]

Re: Python vs. Lisp -- please explain

Quoth Alexander Schmolck <a.schmolck@gma il.com>:
| Bruno Desthuilliers <bdesth.quelque chose@free.quel quepart.fr> writes:
....
|> 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 "interprete d 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, donn@drizzle.co m

[Cameron Laird]

Re: Python vs. Lisp -- please explain

In article <eq7pc3-ml5.ln1@lairds. us>, I wondered:[color=blue]
>In article <yfsbqx3ov29.fs f@oc.ex.ac.uk>,
>Alexander Schmolck <a.schmolck@gma il.com> wrote:
> .
> .
> .[color=green]
>>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[/color]
>
>
>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?[/color]

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]

Re: Python vs. Lisp -- please explain

On Mon, 20 Feb 2006 05:18:39 -0800, Kay Schluehr wrote:
[color=blue][color=green]
>> 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.[/color]
>
> 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?[/color]

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.



--
Steven.

[El Loco]

Re: Python vs. Lisp -- please explain

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. 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?[/color]

Actually, it was created by Bruce Lee, which is not dead but working
undercover for the Hong Kong police to fight against the chinese
triads. At this point you might guess what does Bruce Lee have to do
with Al Qaida? Well my friend, if you don't understand this, you don't
get it at all! (Hint: he's a c++ hacker who wanted to build a tracking
system for terrorists in middle east, but the project got halted when
Guido Van Rossum, who's real name is Abdul Al Wazari, convinced him to
use python). Now the system is so so slow that Ben Laden never gets
caught!

El Loco