Python vs. Lisp -- please explain

[63q2o4i02]

Hi, I've been thinking about Python vs. Lisp.  I've been learning
Python the past few months and like it very much.  A few years ago I
had an AI class where we had to use Lisp, and I absolutely hated it,
having learned C++ a few years prior.  They didn't teach Lisp at all
and instead expected us to learn on our own.  I wasn't aware I had to
uproot my thought process to "get" it and wound up feeling like a
moron.

In learning Python I've read more about Lisp than when I was actually
trying to learn it, and it seems that the two languages have lots of
similarities:

http://www.norvig.com/python-lisp.html

I'm wondering if someone can explain to me please what it is about
Python that is so different from Lisp that it can't be compiled into
something as fast as compiled Lisp?  From this above website and
others, I've learned that compiled Lisp can be nearly as fast as C/C++,
so I don't understand why Python can't also eventually be as efficient?
 Is there some *specific* basic reason it's tough?  Or is it that this
type of problem in general is tough, and Lisp has 40+ years vs Python's
~15 years?


Thanks
Michael

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[DH]

[EMAIL PROTECTED] wrote:
> A few years ago I
> had an AI class where we had to use Lisp, and I absolutely hated it,
> having learned C++ a few years prior.  They didn't teach Lisp at all
> and instead expected us to learn on our own.

CS classes haven't changed, I see.

> In learning Python I've read more about Lisp than when I was actually
> trying to learn it, and it seems that the two languages have lots of
> similarities:
> 
> http://www.norvig.com/python-lisp.html
> 
> I'm wondering if someone can explain to me please what it is about
> Python that is so different from Lisp that it can't be compiled into
> something as fast as compiled Lisp?  From this above website and
> others, I've learned that compiled Lisp can be nearly as fast as C/C++,
> so I don't understand why Python can't also eventually be as efficient?
>  Is there some *specific* basic reason it's tough?  Or is it that this
> type of problem in general is tough, and Lisp has 40+ years vs Python's
> ~15 years?

It is by design. Python is dynamically typed.  It is essentially an 
interpreted scripting language like javascript or ruby or perl, although 
python fans will be quick to tell you python is compiled to byte code. 
They'll also be quick to tell you:
-python has true closures (although nothing like ruby's blocks)
-is beginner friendly (despite being case sensitive and 3/4==0, for example)
-is not, in fact, slow at all (despite benchmarks as you noted showing 
otherwise).
Judge for yourself.

There are projects that combine static typing + the python syntax, which
result in dramatically faster code, but perhaps only 80% of python's
functionality and less flexibility you get from dynamic typing. 
Projects like shedskin.  But some python fans don't think 80% cuts it, 
even if you do get a 100 fold speed increase.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Terry Reedy]

<[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> In learning Python I've read more about Lisp than when I was actually
> trying to learn it, and it seems that the two languages have lots of
> similarities:
>
> http://www.norvig.com/python-lisp.html
>
> I'm wondering if someone can explain to me please what it is about
> Python that is so different from Lisp that it can't be compiled into
> something as fast as compiled Lisp?  From this above website and
> others, I've learned that compiled Lisp can be nearly as fast as C/C++,

In order to be that fast, some of the dynamism of intepreted Lisp must be 
given up.  In particular object code is not list data.  Python with 
type-dynamism eliminated can also be translated to decent C/C++ and then 
compiled.  See PyRex and Weave.  There is also Psyco, which I believe 
translates directly to machine code.

> so I don't understand why Python can't also eventually be as efficient?
> Is there some *specific* basic reason it's tough?  Or is it that this
> type of problem in general is tough, and Lisp has 40+ years vs Python's
> ~15 years?

Yes, *much* more work has gone into Lisp than Python.  (At least 10x, I am 
sure. and maybe up to 100x)  During the 1980s, there was a Lisp/AI 
boom/bust something like the dot.com boom/bust of the last 1990s with 
perhaps a billion invested in Lisp/AI companies.  I presume some of that 
went into Lisp itself (as opposed to AI applications thereof).

Terry Jan Reedy



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[gene tani]

[EMAIL PROTECTED] wrote:

>
> I'm wondering if someone can explain to me please what it is about
> Python that is so different from Lisp that it can't be compiled into
> something as fast as compiled Lisp?  From this above website and
> others, I've learned that compiled Lisp can be nearly as fast as C/C++,
> so I don't understand why Python can't also eventually be as efficient?
>  Is there some *specific* basic reason it's tough?  Or is it that this
> type of problem in general is tough, and Lisp has 40+ years vs Python's
> ~15 years?
>
>

i'm not sure it'll answer question, but Brett cannon's thesis is good
background

http://www.ocf.berkeley.edu/~bac/thesis.pdf

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Steven D'Aprano]

On Sat, 18 Feb 2006 23:35:27 -0600, DH wrote:

> > I'm wondering if someone can explain to me please what it is about
> > Python that is so different from Lisp that it can't be compiled into
> > something as fast as compiled Lisp?  From this above website and
> > others, I've learned that compiled Lisp can be nearly as fast as
> > C/C++, so I don't understand why Python can't also eventually be as
> > efficient? Is there some *specific* basic reason it's tough?  Or is it
> > that this type of problem in general is tough, and Lisp has 40+ years
> > vs Python's ~15 years?
>
> It is by design. 

You make it sound like Guido sat down to design a language and
deliberately put "Slow" first on his list of desired attributes. Why such
a negative tone to your post?

Python is not slow by design. Python is dynamically typed by design, and
relative slowness is the trade-off that has to be made to give dynamic
types.

The Python developers have also done marvels at speeding up Python since
the early days, with the ultimate aim of the PyPy project to make Python
as fast as C, if not faster. In the meantime, the question people should
be asking isn't "Is Python fast?" but "Is Python fast enough?".

> Python is dynamically typed.  It is essentially an 
> interpreted scripting language like javascript or ruby or perl, although 
> python fans will be quick to tell you python is compiled to byte code. 

You make it sound like Python fans are bending the truth. That Python
compiles to byte-code is an objective fact which can be learnt by anyone,
not just "Python fans". In that regard, Python is closer to Java than Perl
or Javascript. Only without the slow startup time of the JRE.


> They'll also be quick to tell you:
> -python has true closures (although nothing like ruby's blocks)

They're also nothing like Pascal's with statements either. Why make the
comparison with Ruby's blocks when the original poster is comparing Python
to Lisp?


> -is beginner friendly (despite being case sensitive and 3/4==0, for
> example)

Case sensitivity isn't beginner unfriendly. It is sloppy thinker
unfriendly. Whether you have been programming for thirty days or thirty
years, if you don't know the difference between foo and FOO you have a
serious problem. As they say, case is the difference between "I helped my
Uncle Jack off a horse" and "I helped my uncle jack off a horse."

As for the difference between integer division and true division, yes,
that was an unfortunate design decision. Fortunately it is being rectified
in the least painful way possible.


> -is not, in fact, slow at all (despite benchmarks as you noted showing
> otherwise).

I've asked this question before, but obviously there is a particular
mindset that just doesn't get it. Slow compared to what? Slow to do what?

For those who don't understand the difference between "faster" and "fast
enough", perhaps a simple analogy will bring enlightenment. For most
people, under most circumstances, an ordinary car (top speed around 75
mph or so) is fast enough, more convenient, and much better value for
money than the significantly faster F-15 fighter plane (top speed around
1850 mph).

On modern hardware, for the vast majority of applications, the execution
speed of the language is not the limiting factor. I/O or the algorithm is
usually the limiting factor. "Change your algorithm" is often better
advice than "change your language". 

That's not to say that Python isn't objectively SLOWER (note the
relative term, not absolute) than some languages. But execution speed is
rarely the most important factor in choice of a language.

For those tasks that language speed is a limiting factor (say, writing
devise drivers, operating systems, and similar), Python may not be fast
enough. But they are the exception rather than the rule, and there are no
shortage of ways around that: Psycho, C extensions, or even "choose
another language". 



-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Robert J. Hansen]

> what [is it] about Python that is so different from Lisp that it
> can't be compiled into something as fast as compiled Lisp?

IMO, it's the lack of competing implementations.

LISP has a very well-defined ANSI specification.  Lots of different
people have written LISPs, from Franz to Steel Bank to GNU to... etc.
Each of these competes with the others on different grounds; some are
purely interpreted (ala CLISP), some are compiled (CMUCL), some are...
etc.  They all implement substantially the same language, but the
plethora of different implementations has been a tremendous boon for
the development of efficient compilers, interpreters and garbage
collectors.

By comparison, Python lacks anywhere near as many competing
implementations.

In some respects the lack of competing implementations is a Good Thing.
 In some respects it's a Bad Thing.  On balance it's just a thing.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[bearophileHUGS]

The question about the speed is interesting. Generally the more dynamic
and flexible your language is, the slower are the programs it produces.
Lisp is almost unique in such matters (and in this regard it's maybe
better than CPython) because it allows the programmer to mix and blend
different levels of how much dynamism and how much optimized a part of
the program has to be. When you want to speed up a part of a Lisp
program (often developed starting from a slow but flexible code) you
start to use more specific functions, unboxed variables, simple arrays
of unboxed data, statically typed variables, etc. It's not easy, but if
you have some experience, often than one year, in that way you can
write programs only 20% or 50% slower than ones written in C, so for
most purposes they become fast enough. On the other hand you can
develop the program using an interactive shell and a dynamically typed
language, that speeds you a lot the prototyping, etc. You can have the
best of both things.
Python allows to mix various blends too (Psyco, Pyrex, ShedSkin, Weave,
SWIG, glues for Fortran and C/C++, etc), but in Lisp such blending
seems much more natural, finer grained, integrated in the language.
I think this isn't a limit of the language itself, because with enough
work two tools like Psyco and ShedSkin can become integrated in the
language itself (I think Psyco and SS are enough for 98% or purposes)
producing something not far from the "optimization flexibility" of
Lisp. Psyco compiles just in time some code, ShedSkin is more
aggressive, but if it becomes developed enough it can produce programs
fast as C/C++ ones with the same syntax of Python (some things aren't
supported). So then you can develop a program like in Lisp, where some
parts aren't optimized, some parts are compiled just in time, and other
critical parts are type inferenced and statically compiled for the max
speed (this requires to join ShedSkin with something like Swig, to
allow a natural, fully automatic and pythonic joining of .PYDs produced
by SS and CPython programs). PyPy can probably solve such problems in
similar ways or better, we'll see.

Bye,
bearophile

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Roy Smith]

DH <[EMAIL PROTECTED]> wrote:
> -python has true closures (although nothing like ruby's blocks)

What is a "true closure"?  Or, maybe what I'm asking is what kind of 
closure wouldn't be a true closure?  Is there some kind of ersatz closure 
other language try to pass off, in violation of truth in closure laws?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Roy Smith]

"Robert J. Hansen" <[EMAIL PROTECTED]> wrote:
> LISP has a very well-defined ANSI specification.  Lots of different
> people have written LISPs, from Franz to Steel Bank to GNU to... etc.
> Each of these competes with the others on different grounds; some are
> purely interpreted (ala CLISP), some are compiled (CMUCL), some are...
> etc.  They all implement substantially the same language, but the
> plethora of different implementations has been a tremendous boon for
> the development of efficient compilers, interpreters and garbage
> collectors.

It's been a while since I've dabbled in lisp, but my recollection is that 
the plethora of different implementations has also meant that portability 
is a fantasy.

I dread the day that competing Python implementations spring up.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Torsten Bronger]

Hallöchen!

Roy Smith <[EMAIL PROTECTED]> writes:

> [...]
>
> It's been a while since I've dabbled in lisp, but my recollection
> is that the plethora of different implementations has also meant
> that portability is a fantasy.
>
> I dread the day that competing Python implementations spring up.

Even worse: In one of them Microsoft is involved.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Fredrik Lundh]

Roy Smith wrote:

> I dread the day that competing Python implementations spring up.

where were you in 1997?

http://www.python.org/workshops/1997-10/proceedings/hugunin.html





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Luis M. González]

>IMO, it's the lack of competing implementations.

I beg to differ in this point.
There are other implementations, but they are not called "python" and
they are not a 100% python in syntax and features.
For example, Boo is 95% python syntax wise, but statically typed.
This fundamental difference makes it as fast as C# or any other .NET
(or mono) language.
Being statically typed doesn't mean that you have to declare types
everywhere, like in C. It uses type inference, so you can declare a
variable x= 5 and the compiler will know that x is an integer of value
5.
Pyrex is statically typed too, but it's used mainly as an extension
language for Cpython.

Now talking specifically about python, there are projects aimed at
speeding it up substantially:

Pypy is a project that relies heavily in type inference (for
translation to lower level code) and dynamic optimization. It's based
mainly on psyco, which has already probed that it can massively speed
up python code.

Shed-Skin: it's a pyton-to-c++ compiler. It won't support the most
dynamic features of python, and requires the programmer to restric a
little bit his coding style in order to allow static compilation, but
so far it looks great (only one developer though..).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[bearophileHUGS]

Luis M. González>[Shed-Skin] ... but so far it looks great (only one
developer though..).<

Two developers, I am there too :-)

I think people aren't much interested so far because there aren't good
ways to link/join/use SSPython compied code from CPython code. A good
solution is probably to:
- Develop code in CPython
- find if there are slow spots that Psyco can't improve enough
- in this situation move the parts in a module and do some tweaks to
adapt the code (if necessary)
- compile the .py module (to a .pyd, etc) with SS (a single click can
be enough on some operating systems), and then import it as before.

To do this it SS requires to know the types of the input data of the
functions/classes in the module. There are solutions to this, the
simpler one to me seems to infer such types from the code below the if
__name__ == "__main__":
That part can contain tests of all the functions/classes, so such parts
can be used to infer types of the whole module.
To do this automatically SS has to use something like SWIG.

Other developers can probably help with such things, otherwise SS will
probably be dead in a year from now... this is not good for me.

Bye,
bearophile

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Terry Reedy" <[EMAIL PROTECTED]> writes:

> <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> > In learning Python I've read more about Lisp than when I was actually
> > trying to learn it, and it seems that the two languages have lots of
> > similarities:
> >
> > http://www.norvig.com/python-lisp.html
> >
> > I'm wondering if someone can explain to me please what it is about
> > Python that is so different from Lisp that it can't be compiled into
> > something as fast as compiled Lisp?  From this above website and
> > others, I've learned that compiled Lisp can be nearly as fast as C/C++,
> 
> In order to be that fast, some of the dynamism of intepreted Lisp must be 
> given up.  In particular object code is not list data.  

I'm not entirely sure what you are talking about, but you're almost certainly
very confused about something. Not all common lisp implementations even have
an interpreter (which doesn't tend to be visible to the user).

'as

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Cameron Laird]

In article <[EMAIL PROTECTED]>,
Roy Smith  <[EMAIL PROTECTED]> wrote:
>DH <[EMAIL PROTECTED]> wrote:
>> -python has true closures (although nothing like ruby's blocks)
>
>What is a "true closure"?  Or, maybe what I'm asking is what kind of 
>closure wouldn't be a true closure?  Is there some kind of ersatz closure 
>other language try to pass off, in violation of truth in closure laws?

It's an apt question.

What's a "true closure"?  That's the easiest part, in some ways:  
Wikipedia, for example, tells that it's "a function that refers
to free variables in its lexical context" http://en.wikipedia.org/wiki/Closure_%28computer_science%29 >,
that is the context of the domain of the function's definition.

Some languages--Lisp, but also many others--definitely have it.
Basic definitely didn't.  Tcl ... well, after weeks of discussion
http://wiki.tcl.tk/closures >, the conclusion was that Tcl
almost has as much as it can, given that "lexical context" just
doesn't have much standing in Tclonia.  So, yes, George Mikan and
Allen Iverson both definitely played basketball, and well, but,
at the same time, it's useful to distinguish the things they do
with a ball.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Kay Schluehr]

Roy Smith wrote:
> DH <[EMAIL PROTECTED]> wrote:
> > -python has true closures (although nothing like ruby's blocks)
>
> What is a "true closure"?  Or, maybe what I'm asking is what kind of
> closure wouldn't be a true closure?  Is there some kind of ersatz closure
> other language try to pass off, in violation of truth in closure laws?

A "true closure" is what Python doesn't have ;)

If you enclose variables in a certain functional context in which they
are not defined they are turned into something immutable in Python.
Assigning a value to the same name creates a new object instead of
rebinding the old name. This "readonly" semantics confuses many
programmers coming from other languages at least all Lispers/Schemers
I've talked to. Python does not provide a rebinding operator for free
variables by BDFL decision.

Kay

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Terry Hancock]

On Sun, 19 Feb 2006 00:54:22 -0500
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
> In order to be that fast, some of the dynamism of
> intepreted Lisp must be  given up.  In particular object
> code is not list data.  Python with  type-dynamism
> eliminated can also be translated to decent C/C++ and then
> compiled.  See PyRex and Weave.  There is also Psyco,
> which I believe  translates directly to machine code.

I thought it was just "Pyrex" as in "Still as clear as
glass, but can really take the heat.".  ;-)

Now it's a small snake / dog chimera.  Eeeww. You've ruined
it for me.

> > so I don't understand why Python can't also eventually
> > be as efficient? Is there some *specific* basic reason
> > it's tough?  Or is it that this type of problem in
> > general is tough, and Lisp has 40+ years vs Python's ~15
> > years?

Otherwise, I think this has been well-answered -- if you
give up the same features, you can get the same speed. But
who cares?

Those things only matter in a very limited domain, and real
programs can use Python for logic and Python extension
modules for things that truly need optimization. If you use
Pyrex, you can even still pretend you're programming in
Python when you write those extensions. I'm sure that's why
some 3D libraries have opted to write the fast code in Pyrex
instead of C (even though either is possible).

 -- 
Terry Hancock ([EMAIL PROTECTED])
Anansi Spaceworks http://www.AnansiSpaceworks.com

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

[EMAIL PROTECTED] writes:

> Hi, I've been thinking about Python vs. Lisp.  I've been learning
> Python the past few months and like it very much.  A few years ago I
> had an AI class where we had to use Lisp, and I absolutely hated it,
> having learned C++ a few years prior.  They didn't teach Lisp at all
> and instead expected us to learn on our own.  I wasn't aware I had to
> uproot my thought process to "get" it and wound up feeling like a
> moron.
> 
> In learning Python I've read more about Lisp than when I was actually
> trying to learn it, and it seems that the two languages have lots of
> similarities:
> 
> http://www.norvig.com/python-lisp.html
> 
> I'm wondering if someone can explain to me please what it is about
> Python that is so different from Lisp that it can't be compiled into
> something as fast as compiled Lisp?  

Nothing. Given a sufficiently smart implementation any language can be as fast
as any other -- it might just be a billion times harder to write that
implementation for language A than for language B.

> From this above website and others, I've learned that compiled Lisp can be
> nearly as fast as C/C++, so I don't understand why Python can't also
> eventually be as efficient? Is there some *specific* basic reason it's
> tough? Or is it that this type of problem in general is tough, and Lisp has
> 40+ years vs Python's ~15 years?

I think if you're looking for one single reason, it is presumably that (IIRC)
python was designed on the erronous assumption that dynamically typed
languages have to be slow (and are unsuitable for real applications anyway)
wheras common lisp wasn't. Furthermore the people involved in common lisp were
much more knowledgeable and experienced in things like compiler design and had
a long history of similar languages and various implementations to build upon.

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). But both these
languages have been designed with compiler writers and the generation of fast
code in mind, so they made design decisions to ease writing fast lisp
compilers and programs.

For example:

- python classes (and to some extent modules) are essentially dictionaries
  that you can modify and customize more or less at will at run-time and that
  behave interchangeably in many respects. I'm sure that presents several
  optimization headaches.

  By contrast if the common lisp compiler sees the symbol CL:LIST (usually
  written just LIST, because the CL package is imported by default) it can
  safely assume that it refers to the builtin LIST function, because you're
  not allowed to rebind the function value of functions in the CL package.
  Python can assume no such thing if it comes across ``list`` -- for all it
  knows it might as well be the number 42. Also the package and class system
  are completely separate and although common lisp's OO system is rather more
  powerful than python's it has been designed to be implementable efficiently.

- in python almost everything has to happen at run-time, whereas in common
  lisp you can do things at compile time, load time or run-time e.g:

- common lisp has a mechanism for making compiler declarations (so you can
  tell the compiler to inline a function, or the type of a variable, or to
  optimize something for speed and not for space etc.)

- common lisp has macros (proper ones, not C style) which allow you to build
  efficient abstractions

- common lisp has compiler macros. This sort of means that you can write 
your
  own compiler optimizations for your functions (i.e. if you know that your
  expensive FOO function is indempotent you could arrange for all calls of 
the
  form (FOO (FOO A)) to be replaced with simply A, in a similar way as an
  optimizing compiler might replace (a+b+c+d)*0 with 0).

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 produc

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

Bruno Desthuilliers <[EMAIL PROTECTED]> writes:

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

Of course it is. What do you think happens to the bytecode? And if python
isn't a scripting language, then what on earth is? 

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.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[63q2o4i02]

Cool, thank you.  That's the answer I was looking for :)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Fredrik Lundh]

Alexander Schmolck wrote:

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





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[63q2o4i02]

Great, thanks for a very complete answer.
michael

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Fredrik Lundh]

Alexander Schmolck wrote:

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





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Bruno Desthuilliers]

Alexander Schmolck a écrit :
> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> 
> 
>>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.
> 
> 
> 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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Ed Jensen]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> 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."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[63q2o4i02]

Great, thank you and everyone for this nice discussion.

Michael

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Torsten Bronger]

Hallöchen!

Bruno Desthuilliers <[EMAIL PROTECTED]> writes:

> Alexander Schmolck a écrit :
>
>> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>> 
>>> [...]
>>>
>>> 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.

-- 
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Boddie]

Torsten Bronger wrote:
> Hallöchen!
>
> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> >
> > 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.

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Steven D'Aprano]

On Sun, 19 Feb 2006 19:26:20 +, Alexander Schmolck wrote:

> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> 
>> 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.
> 
> 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?


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Fredrik Lundh" <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> 
> > 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 ?

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Steven D'Aprano]

On Sun, 19 Feb 2006 13:02:16 -0800, Paul Boddie wrote:

> Torsten Bronger wrote:
>> Hallöchen!
>>
>> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>> >
>> > 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.
> 
> 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.



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

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


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

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. 


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Valentino Volonghi aka Dialtone]

Steven D'Aprano <[EMAIL PROTECTED]> wrote:

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

-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: http://vvolonghi.blogspot.com
New Pet: http://www.stiq.it
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Fredrik Lundh" <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> 
> > 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".

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[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





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Boddie]

Steven D'Aprano wrote:
> On Sun, 19 Feb 2006 13:02:16 -0800, Paul Boddie wrote:
>
> >> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> >> >
> >> > 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.
> >
> > 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.

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.

[...]

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

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alex Martelli]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:

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

OK, but then we should change ,
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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alex Martelli]

Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
   ...
> 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


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Fredrik Lundh]

Alexander Schmolck wrote:

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





-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Donn Cave]

Quoth Alexander Schmolck <[EMAIL PROTECTED]>:
| "Fredrik Lundh" <[EMAIL PROTECTED]> 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".

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, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Harald Armin Massa]

>>OK, but then we should change ,
>>which starts with "Python is an interpreted, interactive,
>>object-oriented programming language."

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Michele Simionato]

Alexander Schmolck wrote:
> 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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Jonathon Blake]

Steven wrote:

> And I'm just waiting for somebody to mention Forth,

Probably not the context you expected it to be mentioned in.

> > Yet one could potentially have that bytecode interpreter in hardware.
> Not potentially, in actuality. I know of only one example,

Shouldn't the Forth Chips from the late 70's and early 80's also get a
mention here?

xan

jonathon
--
Ethical conduct is a vice.
Corrupt conduct is a virtue.

Motto of Nacarima.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[bruno at modulix]

Torsten Bronger wrote:
> Hallöchen!
> 
> Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> 
> 
>>Alexander Schmolck a écrit :
>>
>>
>>>Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
>>>
>>>
[...]

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 desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[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 desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[bruno at modulix]

Harald Armin Massa wrote:
>>>OK, but then we should change ,
>>>which starts with "Python is an interpreted, interactive,
>>>object-oriented programming language."
> 
> 
> 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.



-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Torsten Bronger]

Hallöchen!

bruno at modulix <[EMAIL PROTECTED]> writes:

> Torsten Bronger wrote:
>
>> [...]
>>
>> 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.

-- 
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Boddie]

bruno at modulix wrote:
> 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".

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Boddie]

Fredrik Lundh wrote:
> Alexander Schmolck wrote:
>
> > 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.

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Carl Friedrich Bolz]

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.

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Torsten Bronger]

Hallöchen!

Carl Friedrich Bolz <[EMAIL PROTECTED]> writes:

> Torsten Bronger wrote:
>
>> [...]
>>
>> 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.

-- 
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Fredrik Lundh" <[EMAIL PROTECTED]> writes:

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

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




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


 
> (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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[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, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Cameron Laird]

In article <[EMAIL PROTECTED]>,
Alexander Schmolck  <[EMAIL PROTECTED]> wrote:
.
.
.
>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?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

Bruno Desthuilliers <[EMAIL PROTECTED]> writes:

> Alexander Schmolck a écrit :
> > Bruno Desthuilliers <[EMAIL PROTECTED]> writes:
> >
> 
> >>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.
> > Of course it is. What do you think happens to the bytecode?
> 
> 
> 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.

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

Python is also a scripting language for *n*x systems and various 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.

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

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Donn Cave" <[EMAIL PROTECTED]> writes:

> Quoth Alexander Schmolck <[EMAIL PROTECTED]>:
> | "Fredrik Lundh" <[EMAIL PROTECTED]> 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".

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Donn Cave]

Quoth Alexander Schmolck <[EMAIL PROTECTED]>:
| Bruno Desthuilliers <[EMAIL PROTECTED]> 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 "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, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Cameron Laird]

In article <[EMAIL PROTECTED]>, I wondered:
>In article <[EMAIL PROTECTED]>,
>Alexander Schmolck  <[EMAIL PROTECTED]> wrote:
>   .
>   .
>   .
>>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?

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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Steven D'Aprano]

On Mon, 20 Feb 2006 05:18:39 -0800, Kay Schluehr wrote:

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

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.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[El Loco]

Kay Schluehr wrote:
> 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?

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Torsten Bronger]

Hallöchen!

[EMAIL PROTECTED] (Cameron Laird) writes:

> In article <[EMAIL PROTECTED]>, I wondered:
>
>> [...]  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.

I was rather stunned, too, when I read his line of thought.
Nevertheless, I think it's not pointless, albeit formulated in an
awkward way.  Of course, Python has not been deliberately slowed
down.

I don't know how strong the effect is that a language design which
doesn't allow for (easy to implement) fast execution speed makes you
write cleaner code, however, I must say that I feel so, too.  When I
came from C++ to Python I had to find my Pythonic style, and part of
it was that I threw away those ubiquitous little optimisations and
concentrated on formulating my idea in a clear and expressive way.

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.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Kay Schluehr]

Steven D'Aprano wrote:
> On Mon, 20 Feb 2006 05:18:39 -0800, Kay Schluehr wrote:
>
> >> 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?
>
> 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*

Osama? Who is Osama? A media effect, a CNN invention.

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

Alexanders hypothesis is completely absurd. It turned out over the
years that capabilities of Python optimization are lower than those of
Lisp and Smalltalk. But its a system effect and epiphenomenon of
certain design decisions. This might change with PyPy - who knows? The
Lisp/Smalltalk design is ingenious, radical and original and both
languages were considered too slow for many real-world-applications
over decades. But no one has ever claimed that Alan Kay intentionally
created a slow language in order to hold the herd together - and it
accidentally turned out to be reasonably fast with JIT technology in
the late 90s.

Smalltalk was killed by Java while Lisp was killed by the paradigm
shift to OO in the early 90s. The IT world has absolutely no interest
in the hobby horses of computer scientists or language lovers (like
me). It consolidates in direction of a small set of Algol successors
namely C,C++,Java and C# and some dynamically typechecked languages
like Perl, Python and Ruby that play nice with the bold mainstream
languages as their more flexible addition. A conspiracy like theory
used to explain what's going on is needless.

Kay

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Steven D'Aprano]

On Mon, 20 Feb 2006 16:54:34 +, Donn Cave wrote:

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

Python programs (.py files) don't contain an interpreter. Some of those
files are *really* small, you can't hide a full blown Python interpreter
in just half a dozen lines.

What you mean is that Python programs are only executable on a platform
which contains the Python interpreter, and if it is not already installed,
you have to install it yourself.

So how exactly is that different from the fact that my compiled C program
is only executable on a platform that already contains the correct machine
code interpreter, and if that interpreter is not already installed, I have
to install a machine code interpreter (either the correct CPU or a
software emulator) for it?

Moving compiled C programs from one system to another one with a different
CPU also changes the performance (and sometimes even the semantics!) of
the program. It is easier for the average user to change the version of
Python than it is to change the CPU.

Nobody denies that Python code running with no optimization tricks is
(currently) slower than compiled C code. That's a matter of objective
fact. Nobody denies that Python can be easily run in interactive mode.
Nobody denies that *at some level* Python code has to be interpreted.

But ALL code is interpreted at some level or another. And it is equally
true that at another level Python code is compiled. Why should one take
precedence over the other?

The current state of the art is that the Python virtual machine is slower
than the typical machine code virtual machine built into your CPU. That
speed difference is only going to shrink, possibly disappear completely.

But whatever happens in the future, it doesn't change two essential facts:

- Python code must be compiled to execute;
- machine code must be interpreted to execute.

Far from being indefensible, philosophically there is no difference
between the two. Python and C are both Turing Complete languages, and both
are compiled, and both are interpreted (just at different places).

Of course, the difference between theory and practice is that in theory
there is no difference between theory and practice, but in practice there
is. I've already allowed that in practice Python is slower than machine
code. But Python is faster than purely interpreted languages like bash.

Consider that Forth code can be as fast (and sometimes faster) than the
equivalent machine code despite being interpreted. I remember a
Apple/Texas Instruments collaborative PC back in the mid to late 1980s
with a Lisp chip. Much to their chagrin, Lisp code interpreted on a
vanilla Macintosh ran faster than compiled Lisp code running on their
expensive Lisp machine. Funnily enough, the Apple/TI Lisp machine sank
like a stone.

So speed in and of itself tells you nothing about whether a language is
interpreted or compiled. A fast interpreter beats a slow interpreter,
that's all, even when the slow interpreter is in hardware.

Describing C (or Lisp) as "compiled" and Python as "interpreted" 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?


-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

Torsten Bronger <[EMAIL PROTECTED]> writes:

> I was rather stunned, too, when I read his line of thought.
> Nevertheless, I think it's not pointless, albeit formulated in an
> awkward way.  Of course, Python has not been deliberately slowed
> down.

Indeed -- and I'm really not sure what defect in someone's reading skills or
my writing skills would make anyone think I suggested this.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Boddie]

Torsten Bronger wrote:
>
> 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.

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.

Paul

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Kay Schluehr" <[EMAIL PROTECTED]> writes:

> Alexanders hypothesis is completely absurd. 

You're currently not in the best position to make this claim, since you
evidently misunderstood what I wrote (I certainly did not mean to suggest that
Guido *deliberately* chose to make python slow; quite the opposite in fact).

Maybe I wasn't sufficiently clear, so if rereading my original post doesn't
bring about enlightenment, I'll try a restatement.

> It turned out over the years that capabilities of Python optimization are
> lower than those of Lisp and Smalltalk. But its a system effect and
> epiphenomenon of certain design decisions. 

The point is that the design decisions, certainly for Common Lisp, scheme and
particularly for dylan where also informed by what could be done
*efficiently*, because the people who designed these languages knew a lot
about advanced compiler implementation strategies for dynamic languages and
thought that they could achieve high levels of expressiveness whilst retaining
the possibility of very fast implementations (IIRC dylan specifically was
meant to be something like within 90% of C performance). CL and dylan were
also specifically designed for building very large and sophisticated systems,
whereas it seems Guido originally thought that python would scale to about 500
LOC.

> This might change with PyPy - who knows? The Lisp/Smalltalk design is
> ingenious, radical and original and both languages were considered too slow
> for many real-world-applications over decades. But no one has ever claimed
> that Alan Kay intentionally created a slow language in order to hold the
> herd together - and it accidentally turned out to be reasonably fast with
> JIT technology in the late 90s.

I'm pretty sure this is wrong. Smalltalk and Lisp were both quite fast and
capable before JIT technology in the 90ies came along -- just not necessarily
on hardware optimized for C-like languages, partly because no one anticipated
that the x86 and co. would become so dominant (I also roughly remember Alan
Kay expressing his frustration not to long ago over the fact that despite a
5 fold increase in processing speed, current hardware would only run early
smalltalk 100x faster than the lisa -- I almost certainly misremember the
details but you get the picture).

> A conspiracy like theory used to explain what's going on is needless.

Indeed.

'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Rubin]

[EMAIL PROTECTED] writes:
> I'm wondering if someone can explain to me please what it is about
> Python that is so different from Lisp that it can't be compiled into
> something as fast as compiled Lisp?  From this above website and
> others, I've learned that compiled Lisp can be nearly as fast as C/C++,
> so I don't understand why Python can't also eventually be as efficient?
>  Is there some *specific* basic reason it's tough?

The issues of compiling Python and compiling Lisp are similar.  Lisp
implementers tend to care about performance more, so Lisp tends to be
compiled.  There's a Python compiler called Psyco which can be used
with CPython and which will be part of PyPy.  I'd expect its output
code to be comparable to compiled Lisp code.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Rubin]

Steven D'Aprano <[EMAIL PROTECTED]> writes:
> > > efficient? Is there some *specific* basic reason it's tough?  Or is it
> > > that this type of problem in general is tough, and Lisp has 40+ years
> > > vs Python's ~15 years?
> >
> > It is by design. 
> Python is not slow by design. Python is dynamically typed by design, and
> relative slowness is the trade-off that has to be made to give dynamic
> types.

I think both of you are missing the point of the question, which is
that Lisp is dynamically typed exactly the way Python is and maps to
Python almost directly; yet good Lisp implementations are much faster
than CPython.  

> The Python developers have also done marvels at speeding up Python since
> the early days, with the ultimate aim of the PyPy project to make Python
> as fast as C, if not faster. In the meantime, the question people should
> be asking isn't "Is Python fast?" but "Is Python fast enough?".

That is the real answer: CPython doesn't reach performance parity with
good Lisp implementations, but is still fast enough for lots of
purposes.  Psyco and PyPy are ongoing efforts to close the performance
gap and which are showing promise of success.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Alexander Schmolck]

"Michele Simionato" <[EMAIL PROTECTED]> writes:

> Alexander Schmolck wrote:
> > 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?

Sure (I'm assuming that by lisp you mean common lisp):

- development model

  - by default the development model is highly interactive and you can
redefine all sorts of stuff (functions, methods, classes even the syntax)
without having to start over from scratch (you can also save the current
state of affairs as an image). By contrast changing modules or classes in
interactive python sessions is rather tricky to do without screwing things
up, and it doesn't support images, so sessions tend to be much more
short-lived.

Emacs+slime also offers more powerful functionality than emacs+python mode
(autocompletion, jumping to definitions, various parallel sessions or
remotely connecting to running applications via sockets etc.)

- hot-patching
   
  - partly as a consequence of the above, you can also arrange to hot-patch
some running application without too much trouble (IIRC Graham claims in
one of his essays that one of his favorite pranks was fixing a bug in the
application whilst on the phone to the customer as she reported it and
then telling her that everything in fact seemed to work fine and to try
again)

- error handling:

  - by default you end up in the debugger if something goes wrong and in many
cases you can correct it in place and just continue execution (if you've
ever had some long numerical computation die on plotting the results
because of a underflow as you exponentiate to plot in transformed
coordinates, you'd appreciate being able to just return 0 and continue)

  - Apart from "usual" exception handling CL has much more powerful resumable
exceptions that offer far more fine grained error handling possibiliies.

For more info let me recommend the chapter from Peter Seibel's excellent
"practical common lisp" (available in print, and also freely online):




(The whole book is a great ressource for people who want to have quick
play with common lisp and see how it's features can be leveraged for real
applications (such as html creation, or writing an mp3 server or id3
parser). Peter also makes an easy to install, preconfigured "lispbox"
bundle of Emacs+a free lisp implementation available on his web-page).

- OO: 

  - You know this already, but I'd argue that multimethods and method
combinations give you more dynamism then class-centric OO.

  - Also, if you change the definition of a class all existing instances will
be updated automatically. You can get a similar effect in python by
laboriously mutating the class, provided it doesn't use __slots__ etc, but
that is more brittle and also more limited -- for example, in CL you can 
specify what
happens to instances when the class is updated.

- chameleon like nature:

  It's much easier to make CL look like something completely different (say 
prolog
  or some indentation based, class-centric language like python) than it would
  be with python. In particular:

  - there are no reserved keywords

  - you can e.g. implement new syntax like python style """-strings easily
(I've done so in fact) with reader macros. Indentation based syntax should
also be possible along the same lines, although I haven't tried.

  - you can introduce pretty much any sort of control structure you might
fancy and you can carry out very sophisticated code transformations behind
the scenes.

- finally, with Lispmachines there at least used to be whole operating systems
  written all the way down in lisp and according to all the testimony you
  could interactively modify quite basic system behaviour. The only extant
  systems that come even remotely close would be smalltalks, but even squeak
  which is incredibly malleable and a cross-platform mini-OS in its own right
  uses the host OS for many basic tasks.


'as
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Donn Cave]

Quoth Steven D'Aprano <[EMAIL PROTECTED]>:
...
| Nobody denies that Python code running with no optimization tricks is
| (currently) slower than compiled C code. That's a matter of objective
| fact. Nobody denies that Python can be easily run in interactive mode.
| Nobody denies that *at some level* Python code has to be interpreted.
|
| But ALL code is interpreted at some level or another. And it is equally
| true that at another level Python code is compiled. Why should one take
| precedence over the other?

I have no idea, what precedence?  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.  If you
give me a Python program, you have 3 choices:  cross your fingers and
hope that I have the required Python interpreter version, slip in a
25Mb Python interpreter install and hope I won't notice, or come clean
and tell me that your program needs an interpreter and I should check to
see that I have it.

Donn Cave, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Python vs. Lisp -- please explain

[Delaney, Timothy (Tim)]

Donn Cave wrote:

> for very long.  If you give me a Python program, you have 3 choices: 
> cross your fingers and hope that I have the required Python
> interpreter version, slip in a 25Mb Python interpreter install and
> hope I won't notice, or come clean and tell me that your program
> needs an interpreter and I should check to see that I have it.

Or use the correct term - a Python Virtual Machine.

The the compiler is built into the VM as opposed to a separate tool
(like Java) is just an implementation issue. There's nothing stopping
you from compiling Python source offline and just distributing the
bytecode (and this is commonly done) - although in that case you are
usually tied to a specific PVM major version.

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Boddie]

Delaney, Timothy (Tim) wrote:
> Donn Cave wrote:
>
> > for very long.  If you give me a Python program, you have 3 choices:
> > cross your fingers and hope that I have the required Python
> > interpreter version, slip in a 25Mb Python interpreter install and
> > hope I won't notice, or come clean and tell me that your program
> > needs an interpreter and I should check to see that I have it.
>
> Or use the correct term - a Python Virtual Machine.

Well, yes, I suppose you could have something just interpreting
bytecodes and with no support for parsing and compiling Python the
language - I suppose PyMite [1, 2] and other similar works are like
that.

> The the compiler is built into the VM as opposed to a separate tool
> (like Java) is just an implementation issue. There's nothing stopping
> you from compiling Python source offline and just distributing the
> bytecode (and this is commonly done) - although in that case you are
> usually tied to a specific PVM major version.

Yes, but you can run something like gcj on Java programs and get an
executable which, if I'm not mistaken, doesn't contain any Java VM
whatsoever. There are packagers and other tools for Python which
produce executables, but most of them bundle some kind of bytecode
interpreter, with the possible exception of things like "Python to C"
and, if you're not actually writing Python, Pyrex. However, I believe
that jythonc also produces Java class files with no dependencies on an
embedded VM.

Paul

[1] http://www.python.org/pycon/papers/pymite/
[2] http://wiki.python.org/moin/PyMite

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Steven D'Aprano]

Donn Cave wrote:

> Quoth Steven D'Aprano <[EMAIL PROTECTED]>:
> ...
> | Nobody denies that Python code running with no optimization tricks is
> | (currently) slower than compiled C code. That's a matter of objective
> | fact. Nobody denies that Python can be easily run in interactive mode.
> | Nobody denies that *at some level* Python code has to be interpreted.
> |
> | But ALL code is interpreted at some level or another. And it is equally
> | true that at another level Python code is compiled. Why should one take
> | precedence over the other?
> 
> I have no idea, what precedence?  

There seem to be two positions in this argument:

The "Python is interpreted and not compiled" camp, who 
appear to my eyes to dismiss Python's compilation stage 
as a meaningless technicality.

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.


 > All I'm saying is that Python matches
> what people think of as an interpreted language.

Most people in IT I know of still think of 
"interpreted" as meaning that every line of source code 
is parsed repeatedly every time the code is executed. 
Even when they intellectually know this isn't the case, 
old habits die hard -- they still think of 
"interpreted" as second class.

If you think that Python has to parse the line "print 
x" one hundred times in "for i in range(100): print x" 
then you are deeply, deeply mistaken.

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. 
Consequently nobody thinks of Java source having to be 
parsed, and parsed, and parsed, and parsed again.


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

Pot, meet kettle.

A simple question for you: does Python compile your 
source code before executing it? If you need a hint, 
perhaps you should reflect on what the "c" stands for 
in .pyc files.


 > If you
> give me a Python program, you have 3 choices:  cross your fingers and
> hope that I have the required Python interpreter version, slip in a
> 25Mb Python interpreter install and hope I won't notice, or come clean
> and tell me that your program needs an interpreter and I should check to
> see that I have it.

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.



-- 
Steven.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Ben Sizer]

Steven D'Aprano wrote:
> 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.
> Consequently nobody thinks of Java source having to be
> parsed, and parsed, and parsed, and parsed again.

They also described it that way to help marketing, and I don't think
that should be overlooked. They would have known full well that calling
their language "interpreted" would have affected public perceptions.

It's interesting to see how culture affects things. You talked of 'IT
people' in your post and hold up Java of an example of how byte-code
doesn't mean slow, the implication being that Python uses the same
mechanisms as Java and therefore is good enough. In the general IT
world, Java is quite popular (to make a bit of an understatement) and
it would often be used as some sort of benchmark.

On the other hand, the backgrounds I have familiarity with are computer
game development and embedded development. In these areas, we would
point to Java as evidence that 'interpreted' bytecode is too slow and
that anything using a similar technology is likely to be a problem.

I'm not saying you're wrong, just highlighting that comparisons
themselves always sit in some wider context which can make the
comparison unimportant.

I think it's also important to note that 'interpreted' doesn't
necessarily mean 'parsed repeatedly'. Many older machines which came
with BASIC installed would store their statements in a tokenised form -
arguably bytecode with a large instruction set, if you look at it a
certain way. This isn't necessarily so far from what Python does, yet
few people would argue that those old forms of BASIC weren't
interpreted.

-- 
Ben Sizer

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Kay Schluehr]

Alexander Schmolck wrote:
> "Kay Schluehr" <[EMAIL PROTECTED]> writes:
>
> > Alexanders hypothesis is completely absurd.
>
> You're currently not in the best position to make this claim, since you
> evidently misunderstood what I wrote (I certainly did not mean to suggest that
> Guido *deliberately* chose to make python slow; quite the opposite in fact).

Like everyone else. It's sometimes hard extract the intended meaning in
particular if it's opposed to the published one. I apologize if I
overreacted.

>
> Maybe I wasn't sufficiently clear, so if rereading my original post doesn't
> bring about enlightenment, I'll try a restatement.
>
> > It turned out over the years that capabilities of Python optimization are
> > lower than those of Lisp and Smalltalk. But its a system effect and
> > epiphenomenon of certain design decisions.
>
> The point is that the design decisions, certainly for Common Lisp, scheme and
> particularly for dylan where also informed by what could be done
> *efficiently*, because the people who designed these languages knew a lot
> about advanced compiler implementation strategies for dynamic languages and
> thought that they could achieve high levels of expressiveness whilst retaining
> the possibility of very fast implementations (IIRC dylan specifically was
> meant to be something like within 90% of C performance). CL and dylan were
> also specifically designed for building very large and sophisticated systems,
> whereas it seems Guido originally thought that python would scale to about 500
> LOC.

O.K. To repeat it in an accurate manner. Python was originally designed
by Guido to be a scripting language for a new OS as a more complete
version of a shell scripting language. Unlike those its design was
strongly influenced by the usability ideas of the ABC development team.
Therefore speed considerations were not the primary concern but an open
model that was easily extendable both on the C-API level and the
language level. So a VM architecture was chosen to achieve this. Adding
new opcodes should have been as simple as interfacing with the C-API.
After growing strongly in the late 90s large scale projects emerged
such as Zope and many users started to request more Python performance
since they wanted to escape from the dual-language model. Writing
C-code was not self evident for a new programmers generation grewn up
with Java and the ffi turned out to be a hurdle. After remodeling the
object core ( "new style classes" ) progressive optimizations came to
hold. In 2002 a new genius programmer entered the scene, namely Armin
Rigo, who came up with Psyco and launched the PyPy project together
with a few other Python hackers in order to aggressively optimize
Python using Pythons introspective capabilities. That's were we still
are.

Remembering the historical context we might draw some parallels to
other contexts and language design intentions. We might also figure out
parallels and differences between motives of language designers and
leading persons who drive language evolution. Python is not just Guido
although his signature is quite pervasive. In his latest musings he
comes back to his central idea of language design as a kind of user
interface design. It's probably this shift in perspective that can be
attributed as original to him and which goes beyond making things just
"simple" or "powerfull" or "efficient" ( at least he made this shift
public and visible ). It is also the most controversial aspect of the
language because it is still inseparable from technical decisions (
non-true closures, explicit self, statement-expression distinction,
anonymous function as an expression with limited abilities etc. )

Kay

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Chris Mellon]

On 2/20/06, Donn Cave <[EMAIL PROTECTED]> wrote:
> Quoth Steven D'Aprano <[EMAIL PROTECTED]>:
> ...
> | Nobody denies that Python code running with no optimization tricks is
> | (currently) slower than compiled C code. That's a matter of objective
> | fact. Nobody denies that Python can be easily run in interactive mode.
> | Nobody denies that *at some level* Python code has to be interpreted.
> |
> | But ALL code is interpreted at some level or another. And it is equally
> | true that at another level Python code is compiled. Why should one take
> | precedence over the other?
>
> I have no idea, what precedence?  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.  If you
> give me a Python program, you have 3 choices:  cross your fingers and
> hope that I have the required Python interpreter version, slip in a
> 25Mb Python interpreter install and hope I won't notice, or come clean
> and tell me that your program needs an interpreter and I should check to
> see that I have it.


You're correct as far as it goes, but can you provide a reasonable
definition for "interpreted" that matches the common usage? Most
people can't.

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.

Probably the most accurate definition of "interpreted" as it is used
in the wild is "one of these languages: perl, python, perl, ruby,
etc". That is, you're essentially claiming that Python is interpreted
because everyone thinks of it that way, technical correctness be
damned.

There is an obvious difference between Python and C. Nobody would deny
that. But it's a fairly hard thing to *quantify*, which is why people
make sloppy categorizations. That's not a problem as long as there
isn't prejudice associated with the categorization, which there is.

I wonder how "interpreted" people would think Python is if the
automagic compilation to .pyc was removed and you had to call
"pythonc" first.

>
> Donn Cave, [EMAIL PROTECTED]
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Boddie]

Chris Mellon wrote:
>
> You're correct as far as it goes, but can you provide a reasonable
> definition for "interpreted" that matches the common usage? Most
> people can't.

I thought Torsten's definition was good enough: if the instructions
typically produced when preparing your programs for execution can be
handled directly by the CPU then let's call it a "compiled language";
otherwise, let's call it an "interpreted language". I think we all know
about the subtleties of different levels of virtual machines, but if
you want an arbitrary definition that lots of people feel is intuitive
then that's the one to go for.

> When asked to name some interpreted (or scripting) languages, they'll
> name some off - perl, python, ruby, javascript, basic...

Right: compiled Perl and Python instructions typically aren't executed
directly by the hardware; Ruby visits the parse tree when executing
programs (see [1] for some casual usage of "interpreted" and "compiled"
terms in this context), although other virtual machines exist [2];
JavaScript varies substantially, but I'd imagine that a lot of the
implementations also do some kind of parse tree walking (or that the
developers don't feel like documenting their bytecodes), although you
can also compile JavaScript to Java class files [3]; BASIC varies too
much for any kind of useful summary here, but I'd imagine that early
implementations have tainted the language's "compiled" reputation
substantially.

> They won't say Java. Ask them why Python is interpreted and Java isn't
> and you'll have a hard time getting a decent technical answer, because
> Python isn't all that different from Java in that regard, especially
> pre-JIT versions of Java.

That's why I put Java and Python in the same category elsewhere in this
thread. Bear in mind, though, that Java's just-in-time compilation
features were hyped extensively, and I imagine that many or most
implementations have some kind of native code generation support,
either just-in-time or ahead-of-time.

> Probably the most accurate definition of "interpreted" as it is used
> in the wild is "one of these languages: perl, python, perl, ruby,
> etc". That is, you're essentially claiming that Python is interpreted
> because everyone thinks of it that way, technical correctness be
> damned.

Well, I think Torsten's definition was more objective and yet arrives
at the same result. Whether we're happy with that result, I have my
doubts. ;-)

> There is an obvious difference between Python and C. Nobody would deny
> that. But it's a fairly hard thing to *quantify*, which is why people
> make sloppy categorizations. That's not a problem as long as there
> isn't prejudice associated with the categorization, which there is.

I refer you again to Torsten's definition.

> I wonder how "interpreted" people would think Python is if the
> automagic compilation to .pyc was removed and you had to call
> "pythonc" first.

Well, such things might have a psychological impact, but consider
removing Python's interactive mode in order to enhance Python's
non-interpreted reputation, and then consider Perl (an interpreted
language according to the now-overly-referenced definition) which
doesn't have an interactive mode (according to [4] - I don't keep up
with Perl matters, myself), but which allows expression evaluation at
run-time. No-one would put Perl together with C in a compiled vs.
interpreted categorisation. Removing the automatic compilation support
might strengthen the compiled feel of the both languages further, but
with knowledge of the technologies employed, both languages (at least
in their mainstream forms) are still on the other side of the fence
from C.

Paul

[1] http://www.rubygarden.org/faq/entry/show/126
[2] http://www.atdot.net/yarv/
[3] http://www.mozilla.org/rhino/doc.html
[4] http://dev.perl.org/perl6/rfc/184.html

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Dave Hansen]

On Tue, 21 Feb 2006 08:36:50 -0600 in comp.lang.python, "Chris Mellon"
<[EMAIL PROTECTED]> wrote:

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

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

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?

>
>Probably the most accurate definition of "interpreted" as it is used
>in the wild is "one of these languages: perl, python, perl, ruby,
>etc". That is, you're essentially claiming that Python is interpreted
>because everyone thinks of it that way, technical correctness be
>damned.

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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[D H]

Donn Cave wrote:
> I can say "Python can serve as a scripting language for some applications",
> but not "Python is a scripting language!"

bruno at modulix wrote:
 > as soon as you say "interpreted, scripting", peoples think "not
 > serious".

Cameron Laird wrote:
 > 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".

Fredrik Lundh wrote:
 > 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.

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

Donn Cave wrote:
 > 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.

Steven D'Aprano wrote:
 > Describing C (or Lisp) as "compiled" and Python as "interpreted" 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?

Paul Boddie wrote:
 > 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.

Torsten Bronger wrote:
 > 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.

Steven D'Aprano wrote:
 > 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.

Bruno Desthuilliers wrote:
 > It's not a "scripting" language, and it's not interpreted.


It will all be sorted out once and for all in Python 3000: The Reckoning
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Terry Reedy]

"Paul Boddie" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Well, yes, I suppose you could have something just interpreting
> bytecodes and with no support for parsing and compiling Python the
> language - I suppose PyMite [1, 2] and other similar works are like
> that.
>
>> The the compiler is built into the VM as opposed to a separate tool
>> (like Java) is just an implementation issue.

The presence of the exec statement and the eval function (which is used by 
the input statement) requires the runtime presence of the parser-compiler. 
Removing the latter disables the former features.  This is legitimite when 
not needed or when space is tight, but the result is no longer a full 
implementation.

Terry Jan Reedy



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Chris Mellon]

On 21 Feb 2006 08:30:04 -0800, Paul Boddie <[EMAIL PROTECTED]> wrote:
> Chris Mellon wrote:
> >
> > You're correct as far as it goes, but can you provide a reasonable
> > definition for "interpreted" that matches the common usage? Most
> > people can't.
>
> I thought Torsten's definition was good enough: if the instructions
> typically produced when preparing your programs for execution can be
> handled directly by the CPU then let's call it a "compiled language";
> otherwise, let's call it an "interpreted language". I think we all know
> about the subtleties of different levels of virtual machines, but if
> you want an arbitrary definition that lots of people feel is intuitive
> then that's the one to go for.
>
> > When asked to name some interpreted (or scripting) languages, they'll
> > name some off - perl, python, ruby, javascript, basic...
>
> Right: compiled Perl and Python instructions typically aren't executed
> directly by the hardware; Ruby visits the parse tree when executing
> programs (see [1] for some casual usage of "interpreted" and "compiled"
> terms in this context), although other virtual machines exist [2];
> JavaScript varies substantially, but I'd imagine that a lot of the
> implementations also do some kind of parse tree walking (or that the
> developers don't feel like documenting their bytecodes), although you
> can also compile JavaScript to Java class files [3]; BASIC varies too
> much for any kind of useful summary here, but I'd imagine that early
> implementations have tainted the language's "compiled" reputation
> substantially.
>
> > They won't say Java. Ask them why Python is interpreted and Java isn't
> > and you'll have a hard time getting a decent technical answer, because
> > Python isn't all that different from Java in that regard, especially
> > pre-JIT versions of Java.
>
> That's why I put Java and Python in the same category elsewhere in this
> thread. Bear in mind, though, that Java's just-in-time compilation
> features were hyped extensively, and I imagine that many or most
> implementations have some kind of native code generation support,
> either just-in-time or ahead-of-time.
>

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,

> > Probably the most accurate definition of "interpreted" as it is used
> > in the wild is "one of these languages: perl, python, perl, ruby,
> > etc". That is, you're essentially claiming that Python is interpreted
> > because everyone thinks of it that way, technical correctness be
> > damned.
>
> Well, I think Torsten's definition was more objective and yet arrives
> at the same result. Whether we're happy with that result, I have my
> doubts. ;-)

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?

>
> > There is an obvious difference between Python and C. Nobody would deny
> > that. But it's a fairly hard thing to *quantify*, which is why people
> > make sloppy categorizations. That's not a problem as long as there
> > isn't prejudice associated with the categorization, which there is.
>
> I refer you again to Torsten's definition.
>

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.

> > I wonder how "interpreted" people would think Python is if the
> > automagic compilation to .pyc was removed and you had to call
> > "pythonc" first.
>
> Well, such things might have a psychological impact, but consider
> removing Python's interactive mode in order to enhance Python's
> non-interpreted reputation, and then consider Perl (an interpreted
> language according to the now-overly-referenced definition) which
> doesn't have an interactive mode (according to [4] - I don't keep up
> with Perl matters, myself), but which allows expression evaluation at
> run-time. No-one would put Perl together with C in a compiled vs.
> interpreted categorisation. Removing the automatic compilation support
> might strengthen the compiled feel of the both languages further, but
> with knowledge of the technologies employed, both languages (at least
> in their mainstream forms) are still on the other side of the fence
> from C.
>
> Paul
>
> [1] http:/

Re: Python vs. Lisp -- please explain

[Donn Cave]

In article <[EMAIL PROTECTED]>,
 Steven D'Aprano <[EMAIL PROTECTED]> wrote:
...
> 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.

Sure, all this is true, except for the term "interpreter."
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, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Donn Cave]

In article <[EMAIL PROTECTED]>,
 "Chris Mellon" <[EMAIL PROTECTED]> wrote:
...
> 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.

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, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Steve Holden]

Chris Mellon wrote:
[...]
> 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.
> 
[...]

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/

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Pietro Campesato]

> As they say, case is the difference between "I helped my
> Uncle Jack off a horse" and "I helped my uncle jack off a horse."

Hahaha!... never heard of that though

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Steven D'Aprano]

On Tue, 21 Feb 2006 09:46:27 -0800, Donn Cave wrote:

> In article <[EMAIL PROTECTED]>,
>  Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> ...
>> 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.

[snip for brevity]

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

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

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

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


> We all know
> what native code compilation buys you and what it doesn't.

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

-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Python vs. Lisp -- please explain

[Delaney, Timothy (Tim)]

Terry Reedy wrote:

>>> The the compiler is built into the VM as opposed to a separate tool
>>> (like Java) is just an implementation issue.

That was me, not Paul - careful with the attributions. Otherwise Paul
might think you were trying to ascribe some awful, inaccurate statement
to him ;)

> The presence of the exec statement and the eval function (which is
> used by the input statement) requires the runtime presence of the
> parser-compiler. Removing the latter disables the former features. 
> This is legitimite when not needed or when space is tight, but the
> result is no longer a full implementation.

True - but there's no reason that exec and eval couldn't hand off to a
python compiler to do the work. Failure to distribute the compiler would
mean then that exec and eval wouldn't work - but everything else would.

It's similar to why some projects need the JDK rather than the JRE -
they have to be able to compile things on the fly.

Tim Delaney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Carl Friedrich Bolz]

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

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Peter Mayne]

Torsten Bronger wrote:
> 
> 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.

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
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Donn Cave]

Quoth Steven D'Aprano <[EMAIL PROTECTED]>:
...
| 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 "interpreted 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, [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Torsten Bronger]

Hallöchen!

Peter Mayne <[EMAIL PROTECTED]> writes:

> Torsten Bronger wrote:
>
>> 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.
>
> In a previous century, I used something called UCSD Pascal, which at
> the time was a typical implementation of Pascal.

Not "a" typical implementation but "its".

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

Only if you deliberately misunderstand me.

> Another example: is Java the bytecode, which is compiled from Java
> the language, interpreted or not? Even when the HotSpot JIT cuts
> in?

It is partly interpreted and partly compiled.  That's why it's
faster than Python.

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

I agree that the term "interpreted" 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 "interpreted", what do you
want to tell people asking why Python is so slow?  Because it is
dynamic?  ;-)

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Steven D'Aprano]

On Wed, 22 Feb 2006 10:15:21 +0100, Torsten Bronger wrote:

>> 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".
> 
> Only if you deliberately misunderstand me.

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.



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

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.



>> [...]
>>
>> 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.
> 
> I agree that the term "interpreted" 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.

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.


> The reason why Python is slower than C is because there is an
> interpreting layer that C doesn't have.

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. 


> 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 "interpreted", what do you want
> to tell people asking why Python is so slow?  Because it is dynamic? ;-)

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.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Kay Schluehr]

Steven D'Aprano wrote:

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

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

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Rubin]

"Kay Schluehr" <[EMAIL PROTECTED]> writes:
> 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. 

Sounds great but is that a whole lot different from pyrex?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Kay Schluehr]

Paul Rubin wrote:
> "Kay Schluehr" <[EMAIL PROTECTED]> writes:
> > 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.
>
> Sounds great but is that a whole lot different from pyrex?

RPython is Python code not a different language. In a sense RPython
consists of a set of rules usual Python has to conform to make complete
type-inference feasible. Here is an overview of those rules.

http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python

Kay

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Torsten Bronger]

Hallöchen!

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> On Wed, 22 Feb 2006 10:15:21 +0100, Torsten Bronger wrote:
>
>>> 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".
>> 
>> Only if you deliberately misunderstand me.
>
> 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.

To me it sounds like "Some hardware is harder than other".

>>> Another example: is Java the bytecode, which is compiled from
>>> Java the language, interpreted or not? Even when the HotSpot JIT
>>> cuts in?
>> 
>> It is partly interpreted and partly compiled.  That's why it's
>> faster than Python.
>
> But Python is partly interpreted and partly compiled too

It's byte-compiled for a VM, that's not the same, and you know it.
Sorry but I think we've exchanged all arguments that are important.
Any further comment from me would be redundant, so I leave it.

> [...]
>
>> [...]  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.  [...]
>
> Would you rather use a blindingly fast interpreted language, or a
> slow-as-continental drift compiled one?
>
> This isn't a rhetorical question. [example]
>
> I'm sure that's hardly the only example of a speedy interpreted
> language beating a glacial compiled one.

I agree that the distinction between interpreted and compiled
languages is not as clear as between positiv and negative numbers,
however, neither anybody has claimed that so far, nor it is
necessary.  It must be *practical*, i.e. a useful rule of thumb for
decision making.  If you really know all implications (pros and
cons) of interpreted languages, it's are very useful rule in my
opinion.

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

I don't think that "Python's developers don't focus primarily on
speed" sounds better than "Python is interpreted".  Both suggests
that you must circumvent problems with Python's execution speed (we
all know that this works and how) because you can't count on
language improvements.  Even worse, evading "interpreted" may sound
like an euphemism and as if you want to hide unloved implementation
features, depending on your audience.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Torsten Bronger]

Hallöchen!

Steven D'Aprano <[EMAIL PROTECTED]> writes:

> On Wed, 22 Feb 2006 10:15:21 +0100, Torsten Bronger wrote:
>
>>> 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".
>> 
>> Only if you deliberately misunderstand me.
>
> 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.

To me it sounds like "Some hardware is harder than other".

>>> Another example: is Java the bytecode, which is compiled from
>>> Java the language, interpreted or not? Even when the HotSpot JIT
>>> cuts in?
>> 
>> It is partly interpreted and partly compiled.  That's why it's
>> faster than Python.
>
> But Python is partly interpreted and partly compiled too

It's byte-compiled for a VM, that's not the same, and you know it.
Sorry but I think we've exchanged all arguments that are important.
Any further comment from me would be redundant, so I leave it.

> [...]
>
>> [...]  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.  [...]
>
> Would you rather use a blindingly fast interpreted language, or a
> slow-as-continental drift compiled one?
>
> This isn't a rhetorical question. [example]
>
> I'm sure that's hardly the only example of a speedy interpreted
> language beating a glacial compiled one.

I agree that the distinction between interpreted and compiled
languages is not as clear as between positiv and negative numbers,
however, neither anybody has claimed that so far, nor it is
necessary.  It must be *practical*, i.e. a useful rule of thumb for
decision making.  If you really know all implications (pros and
cons) of interpreted languages, it's are very useful rule in my
opinion.

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

I don't think that "Python's developers don't focus primarily on
speed" sounds better than "Python is interpreted".  Both suggests
that you must circumvent problems with Python's execution speed (we
all know that this works and how) because you can't count on
language improvements.  Even worse, evading "interpreted" may sound
like an euphemism and as if you want to hide unloved implementation
features, depending on your audience.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetusICQ 264-296-646
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Paul Boddie]

Kay Schluehr wrote:
> Paul Rubin wrote:
> > "Kay Schluehr" <[EMAIL PROTECTED]> writes:
> > > 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.
> >
> > Sounds great but is that a whole lot different from pyrex?

I've wondered that as well.

> RPython is Python code not a different language. In a sense RPython
> consists of a set of rules usual Python has to conform to make complete
> type-inference feasible. Here is an overview of those rules.
>
> http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python

But does that make it "proper Python"? Having, for example, only one
type associated with a name (they use the term "variable", though) at
any given time makes it more like various statically typed or
functional languages, although I can fully understand why you'd want
this restriction.

Paul

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python vs. Lisp -- please explain

[Carl Friedrich Bolz]

Paul Rubin wrote:
> "Kay Schluehr" <[EMAIL PROTECTED]> writes:
> 
>>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. 

Well. "... the PyPy team works on ..." is definitively much too strong. 
It is more like "... the PyPy team is thinking about ...". It is very 
unclear whether it will work on a technical level and whether the EU 
will allow us to allocate resources accordingly.

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

Indeed, there are similarities to pyrex. Of course in pyrex you have to 
give the types yourself, but since the type inference engine of PyPy can 
sometimes be hard to understand this is maybe not the worst trade-off. A 
nice advantage of the PyPy approach would be that you can test your 
RPython code by running it on top of CPython until it works and only 
then translating it into C. Plus it would be possible to use the same 
extension module for PyPy, CPython and potentially even Stackless or 
Jython (if somebody writes a Java backend).

But as I said, this is all pretty unclear at the moment (and getting 
really quite off-topic for this thread).

Cheers,

Carl Friedrich

-- 
http://mail.python.org/mailman/listinfo/python-list