Benefits of moving from Python to Common Lisp?
Morten W. Petersen
I'm currently doing some research, to see if it could be an advantage to
use Common Lisp instead of Python (currently Python and Zope [1] are used
to build web applications).
While doing this, Google has provided two interesting documents (search
for 'lisp vs python'):
http://www.strout.net/python/pythonvslisp.html
http://www.norvig.com/python-lisp.html
First off, to save everyone some time, I'm wondering if there are more
papers documenting the difference between the two; if there aren't any,
I'd like to continue the discussion and summarize the findings in a paper
accessible on the net.
Regards,
Morten
Marco Antoniotti
"Morten W. Petersen" <mor...@thingamy.net> writes:
> Hello,
>
> I'm currently doing some research, to see if it could be an advantage to
> use Common Lisp instead of Python (currently Python and Zope [1] are used
> to build web applications).
>
> While doing this, Google has provided two interesting documents (search
> for 'lisp vs python'):
>
> http://www.strout.net/python/pythonvslisp.html
The author of this page has obviously not much experience of Common
Lisp, as the article contains several factual errors.
It is a page that must be discarded. I had an exchange with the
person, trying to point out to him the various mistakes. He stopped
replying when I noted that
* (defvar x "qwerty")
X
* (setf (subseq x 2 4) "ZX")
"ZX"
* x
"qwZXty"
is perfectly legal CL.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Paul Rubin
Norvig's article is pretty good; the Strout article is about a
specific CL implementation and contains a number of errors and
misleading statements, generally favoring Python. For example, he
says MCL isn't free--however he doesn't mention that there are
numerous free CL implementations. And he compares Python exceptions
favorably to using catch/throw to simulate exceptions in CL, but he
doesn't mention the Condition system that's been part of CL since
1989, that's more powerful (but more complicated) than Python exceptions.
My own quick comparison: CL is a much more complete system. Writing
Python code is often an exercise in figuring out how to combine Python
features in some clever way that nobody has done before, to accomplish
your task. In CL, you more often get the impression that the
designers had anticipated your needs.
On the other hand, CL contains several decades worth of accumulated
junk. Just about every feature in Python is present in some form in
CL, but Python has a cohesive, smooth design, while in CL the features
feel somewhat bolted on. Someone once said "APL is like a perfect
crytal--if you add anything to it, it becomes flawed. Lisp is like a
ball of mud--you can throw anything you want into it, and it's still
Lisp".
Many very large applications have been written in CL. Zope is one of
the biggest Python applications; by CL standards, it's medium sized (I
think around 150K lines of code). There are few other Python programs
that come close to being the size of Zope.
Serious CL implementations have real native-code compilers that produce
machine code that runs orders of magnitude faster than Python code.
Someone might add a compiler like that to Python someday, of course.
CL, however, doesn't seem to have changed much in the past decade or
so. There's no standardization of runtime libraries for doing stuff
like internet programming. CL feels hopelessly old-fashioned in some
ways. And to program effectively in CL, you must absorb a lot of Lisp
culture and idioms, almost like learning to speak a foreign human
language. Programmers experienced in languages like C++ or Perl can
generally read the Python docs and become productive immediately. Not
many programmers are taking up Lisp these days. The experienced Lisp
programmers have generally been around for a long time, and there are
getting to be fewer and fewer of them. As Python matures, I think it
will become more like CL in its capabilities and CL's current
advantages will dimish even more.
To sum up, if you're writing a web application, it's worth considering
CL if the app will be very large or if Python will cause a big
performance problem. Otherwise, Python is probably a better choice
these days.
You might like reading some of Richard Gabriel's essays on CL at
www.dreamsongs.com. There's also a Java-to-Lisp comparison somewhere
that you've probably seen. May of the things it says about Lisp can
probably be applied to Python.
Kenny Tilton
First, the whole idea of arbitrarily picking assessment categories and
then arbitrarily picking numbers 0 to 10 and then arbitrarily assigning
weight...fuggedaboutit.
Second, looks like the assessment was done by someone trying to justify
a switch to Python.
Third, no mention of performance, and "OO is outside the scope of this
evaluation"?!
fourth, Python syntax wins by 10 to 2 on syntax,producing half the
difference in the numeric ranking? Puh-leaze.
fifth, 30 points for open source? hello, CMUCL?
Python wins on expressiveness? Without macros?
I would go with the Norvig piece.
kenny
clinisys
Thomas F. Burdick
> Hello,
>
> I'm currently doing some research, to see if it could be an advantage to
> use Common Lisp instead of Python (currently Python and Zope [1] are used
> to build web applications).
>
> While doing this, Google has provided two interesting documents (search
> for 'lisp vs python'):
>
> http://www.strout.net/python/pythonvslisp.html
The very top of the page says:
The relative merits of the two languages are compared in 11
categories. In an attempt to make a more quantitative comparison, each
language is assigned a score from 0 to 10 in each category. These
scores are then combined, with appropriate weighting factors, to
produce a total score. Each score was assigned as independently as
possible, before weighting factors were decided; and weighting factors
were chosen without examining the scores. In this way, the final
scores are made as objective as possible.
From reading this alone, it is obvious that the author has an agenda,
and is about to embark on a completely biased, subjective comparison,
who's results he has already decided. Plus, he's wrapping it all up
in pseudo-scientific mumbo-jumbo, which is unforgivable.
After the first page, I was going to pick the page apart, or at least
try to address some its more serious flaws, but there's major,
misleading flaws at least one to a paragraph. I don't know if it was
meant to be misleading, or just biased, but looking at Marco
Antoniotti's reply, I'd guess it's intentionally misleading.
I'd try to forget you ever saw it. Not because it favors Python over
Lisp, but because it does so dishonestly. On the other hand, I think
I'm glad that guy doesn't use Lisp :)
> http://www.norvig.com/python-lisp.html
I'd read this before, and found it interesting. Not the least because
it's by Norvig, whose opinion I respect. It convinced me that if I'm
in a situation where I would use CLISP (a bytecode implementation of
CL), but can't, that Python is something I should consider. It seems
like an underpowered Lisp pretender, but then, there are a lot of
worse things to be.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Bruce Hoult
<phr-n...@nightsong.com> wrote:
> My own quick comparison: CL is a much more complete system. Writing
> Python code is often an exercise in figuring out how to combine Python
> features in some clever way that nobody has done before, to accomplish
> your task. In CL, you more often get the impression that the
> designers had anticipated your needs.
>
> On the other hand, CL contains several decades worth of accumulated
> junk. Just about every feature in Python is present in some form in
> CL, but Python has a cohesive, smooth design, while in CL the features
> feel somewhat bolted on.
Dylan has most of the advantages over Python that CL does. In a lot of
ways it's a more cohesive and smooth redesign of CL -- or at least
that's what its designers (many of whom were genuine CL gurus) intended.
The Dylan language is more mature than Python, and has better compilers
(it *has* compilers!), but Python has had more work put into libraries
thus far.
-- Bruce
Daniel Barlow
> Not
> many programmers are taking up Lisp these days. The experienced Lisp
> programmers have generally been around for a long time, and there are
> getting to be fewer and fewer of them.
Though the rest of your post was quite reasonable (this is, generally,
unusual for articles crossposted between c.l.l and c.l.anything-else)
I am wondering what leads you to the opinion you express above
From my point of view, the CL community has picked up noticeably in
the last few years. A draft blurb mentioning some of the
recently-noted lifesigns in the subset of it that deals in
Free-as-in-Open-Source software can be found at
http://ww.telent.net/cliki/Community
Over a slightly shorter timescale (the last 3 months) you might want
to check out http://ww.telent.net/cliki/Free_The_X3J_Thirteen
(again, this is exclusively the Open Source stuff)
And Open Source/Free stuff is just part of the overall community, I
should make clear. There's more stuff going on in other projects,
other companies, and at the commercial vendors, but I don't have the
time to track that too. I'm sure other people can chime in with
examples. For example, if you're looking for something to replace Zope
you might want to evaluate CL-HTTP - I don't know how closely they
match on features, but they're definitely both working in the same
general problem area.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Kent M Pitman
[My comments are not related to the context of this remark, which I didn't
research.]
> I had an exchange with the
> person, trying to point out to him the various mistakes. He stopped
> replying when I noted that
>
> * (defvar x "qwerty")
> X
> * (setf (subseq x 2 4) "ZX")
> "ZX"
> * x
> "qwZXty"
>
> is perfectly legal CL.
Although DEFVAR'ing X is an *extraordinarily* bad idea.
*X* would be a better varname.
I've worked in a system where X was globally special and we were forever
finding random closures not "closing" when we forgot. Bad news.
Tim Bradshaw
> CL, however, doesn't seem to have changed much in the past decade or
> so. There's no standardization of runtime libraries for doing stuff
> like internet programming
This is kind of tangential, and it's a point I've made before, but it
bears repeating I think.
It's important to understand the difference between languages and
implementations here and what it means for standardisation. A
language is a class, and an implementation is an instance of that
class. Languages such as Perl and (I think) Python are *single
instance* classes - there is only one implementation, and the language
is defined implicitly by that implementation.
CL is *not* a single-instance class - there are many CL
implementations - I guess there are O(10) implementations, not
counting variants.
`Standardising a library' for a single-implementation language is a
near-trivial task: you write the library and declare it a standard.
Standardising a library for a multiple-implementation language is
*not* trivial - in fact its very difficult indeed. It costs a lot of
money to do it - the kind of money that is probably just not available
outside the C++/Java/XML camps, where huge amounts of money has been
spent on standardisation. Even this huge amount of money has often
resulted in very poor standards. The CL community has a very *good*
standard, and lacks the kind of huge money needed to generate other
standards, let alone other standards of comparable quality.
I suspect that a lot of CL people (myself included) get rather annoyed
by this repeated comparison between apples (perl, python) and oranges
(CL). We get especially annoyed because if what you want is
perl-style `standardisation' then you can have that - simply pick a CL
implementation and write to its interfaces. You get exactly the same
chance of your programs running on other implementations as you do
with perl or python. Of course you also have the same near-certainty
of getting screwed by the implementor (I live in terror of perl
upgrades, and in fact I stopped doing them a couple of years ago
because every time the version changed some obscure thing broke in
some huge script that I somehow rely on, resulting in a million pages
of hex every time I wanted to print landscape PS or something.
Someday I will have to upgrade I guess, but I think I'll wait until
perl 7.)
--tim
Andrew Dalke
> Languages such as Perl and (I think) Python are *single instance*
> classes - there is only one implementation, and the language
> is defined implicitly by that implementation.
As a minor clarification, there are several distinct implementations
of Python (or a Python-like language). The ones I know of are:
Python in C -- "the" Python, www.python.org
Python in Java -- www.jython.org
Python in C# -- http://www.activestate.com/Initiatives/NET/Research.html
Python in OCaml -- http://vyper.sourceforge.net/
Python bytecode compiler, in C --
http://homepages.ulb.ac.be/~arigo/psyco/
Andrew
da...@dalkescientific.com
Michael Hudson
> Tim Bradshaw:
> > Languages such as Perl and (I think) Python are *single instance*
> > classes - there is only one implementation, and the language
> > is defined implicitly by that implementation.
>
> As a minor clarification, there are several distinct implementations
> of Python (or a Python-like language). The ones I know of are:
[snip]
But they very much take their lead from CPython, so Tim's points all
remain valid. Well, except for vyper, but that doesn't have enough
influence to count (perhaps unfortunately).
Cheers,
M.
--
That one is easily explained away as massively intricate
conspiracy, though. -- Chris Klein, alt.sysadmin.recovery
Andrew Dalke
>But they very much take their lead from CPython, so Tim's points all
>remain valid. Well, except for vyper, but that doesn't have enough
>influence to count (perhaps unfortunately).
I recall some of the conversation when (then) JPython was being
developed, on making sure the documentation didn't require
implementation-specific functionality. So there is *some*
standard-like documentation.
What's needed to call something a standard?
I don't know of a C++ compiler which fully meets the C++ standard.
(They all seem to have bits of 'oh, we don't do that yet'.)
So I figured three different implementations (C, Java and OCaml)
with no shared run-time environment was enough to disprove Tim's
statement:
] there is only one implementation, and the language
] is defined implicitly by that implementation
For Python, would it be better to say
there are several implementations, and the language is mostly
defined by the documentation, but the other implementations
defer to the C implementation, distribution, and developers in
matters of interpretation.
?
Tim's point was that standardizing a library is a complicated and
expensive process. My point is that the Python library
(standardized or not) works with quite different runtimes. Why
aren't there similarly widely used though non-standard libraries
for CL for "doing stuff like internet programming"? [Paul Rubin]
For example, back in the Perl4 days when CGI programming first
became hot, just about everyone used cgi-lib.pl even though it
wasn't part of the standard Perl library, and this was pre-CPAN.
Andrew
da...@dalkescientific.com
Cameron Laird
Andrew Dalke <da...@dalkescientific.com> wrote:
>Tim Bradshaw:
>> Languages such as Perl and (I think) Python are *single instance*
>> classes - there is only one implementation, and the language
>> is defined implicitly by that implementation.
>
>As a minor clarification, there are several distinct implementations
>of Python (or a Python-like language). The ones I know of are:
.
.
<URL: http://starbase.neosoft.com/~claird/comp.lang/python/python_varieties.html
attempts to index them.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Erik Max Francis
> <URL: http://starbase.neosoft.com/~claird/comp.lang/python/python_varieties.html
> attempts to index them.
You meant
http://starbase.neosoft.com/~claird/comp.lang.python/python_varieties.html
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Laws are silent in time of war.
\__/ Cicero
Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
An Esperanto reference for English speakers.
Chris Ryland
> Hello,
>
> I'm currently doing some research, to see if it could be an advantage to
> use Common Lisp instead of Python (currently Python and Zope [1] are used
> to build web applications).
You have to see <www.paulgraham.com/articles.html>, particularly the
"Beating the Averages" and "The Other Road Ahead".
I went back and forth with Paul a few times re: Lisp vs. Python, and
in the end the only really serious differences we could come up with
were (a) Lisp's universal (i.e., non-) syntax makes it easy to write
little languages and to use macros, and (b) Lisp compilers exist today
which produce quite a bit more efficient code than Python's
interpreter can do. [Forgive me, Paul, if I'm mis-remembering.]
(a) could be tackled, if someone were seriously inclined, by getting
the Python folks to agree on an intermediate Lisp-like syntax (lists),
and letting people use either the normal Python syntax or the
lower-level syntax, which would then admit of macros and "easy little
languages".
(b) is only a matter of time & will.
Of course, nothing is that simple, and there are huge reservoirs of
expertise in the Lisp community that the Python folks haven't tapped
into, and vice versa (though clearly less versa, since Python has only
been around for 10-ish years, and hasn't had the academic/research
following that Lisp has).
Just some random thoughts.
--Chris Ryland, Em Software
Skip Montanaro
url="http://starbase.neosoft.com/~claird/comp.lang/python/python_varieties.html"
url = url.replace("lang/python", "lang.python")
;-)
Skip
Paolo Amoroso
On 13 Nov 2001 21:37:37 -0800, c...@emsoftware.com (Chris Ryland) wrote:
> I went back and forth with Paul a few times re: Lisp vs. Python, and
> in the end the only really serious differences we could come up with
Does Python provide something similar to CLOS?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Bob Bane
>
> I went back and forth with Paul a few times re: Lisp vs. Python, and
> in the end the only really serious differences we could come up with
> were (a) Lisp's universal (i.e., non-) syntax makes it easy to write
> little languages and to use macros, and (b) Lisp compilers exist today
> which produce quite a bit more efficient code than Python's
> interpreter can do. [Forgive me, Paul, if I'm mis-remembering.]
>
>
> (b) is only a matter of time & will.
>
It's also a matter of having a non-moving target to aim at. When Python
has a specification stronger than N portable implementations and a test
suite, compiler writers will have a target worth expending effort to
hit.
--
Remove obvious stuff to e-mail me.
Bob Bane
Paul Rubin
> > (b) is only a matter of time & will.
> >
>
> It's also a matter of having a non-moving target to aim at. When Python
> has a specification stronger than N portable implementations and a test
> suite, compiler writers will have a target worth expending effort to hit.
Well, Lisp compilers have been developed for specific dialects plenty
of times.
However, most Lisp compilers have depended on type declaration pragmas
to generate good code, AFAIK. Python would need a language extension
to support something like that.
Marco Antoniotti
c...@emsoftware.com (Chris Ryland) writes:
> "Morten W. Petersen" <mor...@thingamy.net> wrote in message news:<Pine.LNX.4.21.01111...@bcryachts.atsat.com>...
> > Hello,
> >
> > I'm currently doing some research, to see if it could be an advantage to
> > use Common Lisp instead of Python (currently Python and Zope [1] are used
> > to build web applications).
>
> You have to see <www.paulgraham.com/articles.html>, particularly the
> "Beating the Averages" and "The Other Road Ahead".
>
> I went back and forth with Paul a few times re: Lisp vs. Python, and
> in the end the only really serious differences we could come up with
> were (a) Lisp's universal (i.e., non-) syntax makes it easy to write
> little languages and to use macros, and (b) Lisp compilers exist today
> which produce quite a bit more efficient code than Python's
> interpreter can do. [Forgive me, Paul, if I'm mis-remembering.]
>
> (a) could be tackled, if someone were seriously inclined, by getting
> the Python folks to agree on an intermediate Lisp-like syntax (lists),
> and letting people use either the normal Python syntax or the
> lower-level syntax, which would then admit of macros and "easy little
> languages".
Why not drop the fixed indentation rule and adopt S-exprs instead?
That would be an improvement. Apart from that there are several other
problems with Python the language.
def f(x = [])
x.append(0)
f()
f()
is an example of how convoluted is the language semantics. (Try to run
the above to see the effects; the solution involves a special idiom
involving 'None').
> (b) is only a matter of time & will.
Why wait? (compile 'your-function) and go.
> Of course, nothing is that simple, and there are huge reservoirs of
> expertise in the Lisp community that the Python folks haven't tapped
> into, and vice versa (though clearly less versa, since Python has only
> been around for 10-ish years, and hasn't had the academic/research
> following that Lisp has).
>
> Just some random thoughts.
One more random thought: why spend energy on Python when you could
spend it on Common Lisp? Note that the opposite is not a valid
argument.
Gareth McCaughan
> [Followup posted to comp.lang.lisp only - Paolo]
>
> On 13 Nov 2001 21:37:37 -0800, c...@emsoftware.com (Chris Ryland) wrote:
>
> > I went back and forth with Paul a few times re: Lisp vs. Python, and
> > in the end the only really serious differences we could come up with
>
> Does Python provide something similar to CLOS?
Yes, if a simple object system with multiple inheritance
and lots of dynamism is "like CLOS". No, if wondrous things
like CHANGE-CLASS and DEFINE-METHOD-COMBINATION are necessary
for being "like CLOS". Python's object system is quite
flexible, but I wouldn't want to be responsible for making
it behave like CLOS...
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Marco Antoniotti
Gareth.M...@pobox.com (Gareth McCaughan) writes:
Python Object System does not support multiple dispatch. I also
believe (I can be disproved on this) that it messes up multiple
inheritance of slots with the same name. I.e. you need to manually
disambiguate your slot references, unlike CLOS.
Alain Picard
> Why not drop the fixed indentation rule and adopt S-exprs instead?
Well, because the indentation rules are obviously a design goal
of Python, viewed as desirable by its designers and essentially
all of the Python community.
> One more random thought: why spend energy on Python when you could
> spend it on Common Lisp? Note that the opposite is not a valid
> argument.
Well, I certainly don't see any prima facie evidence of this
statement, so, if you've got some magic secret that all the Python
programmers aren't privy to, I'd like to hear it.
Personally, I haven't used Python, but looked into it as a possible
technology pretty seriously, and found that it would be adequate
for doing real work, and it was in fact the only serious contender
to CL I found out there, once you take into considerations things
like platforms, availability of programmers, libraries, etc etc.
This is a Lisp group, but dissing Python without so much as a reason
behind it seems going a bit far.
--ap
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
Tim Bradshaw
> Tim's point was that standardizing a library is a complicated and
> expensive process. My point is that the Python library
> (standardized or not) works with quite different runtimes. Why
> aren't there similarly widely used though non-standard libraries
> for CL for "doing stuff like internet programming"? [Paul Rubin]
>
I think the answer has to do with how the compatibility is ensured.
My guess is that for Python it works something like this: there is a
canonical implementation. Libraries work in that implementation.
Other implementators work to make sure that the libraries work in
their implementations too. Maybe there is some common documentation,
but it probably ultimately comes down to what the canonical
implementation does. This is just like Unix in the early days or C,
or pretty much anything really. It works pretty well as far as it
goes. It means that it's really easy to do stuff like sockets or
something, because you just do what the canonical implementation does.
Now imagine the canonical implementation is owned by Microsoft.
Suddenly it has been changed so it's really hard to make it work on
any platform other than Windows. Oh, and they've hired 58 people,
doubled the size of the language and specified a couple of APIs as
part of it with 4000 ill-defined entrypoints each.
There is now only one realistic implementation, because no-one else
can keep up. 2 years later they quietly drop the language in favour
of visual basic.
Perhaps what you want at this point is a really carefully defined,
implementor-neutral standard.
> For example, back in the Perl4 days when CGI programming first
> became hot, just about everyone used cgi-lib.pl even though it
> wasn't part of the standard Perl library, and this was pre-CPAN.
This is a completely different thing. Perl is single-implementation,
standards are not relevent.
--tim
Tim Bradshaw
>
> However, most Lisp compilers have depended on type declaration pragmas
> to generate good code, AFAIK. Python would need a language extension
> to support something like that.
I don't think this is really true for many interesting programs. It
is very definitely true for *some* kinds of programs, for instance
things that do heavy numerical work, and almost all of the trivial,
stupid, non-benchmarks that people use to decide that `language x is
faster than language y' so they can flame on inappropriate newsgroups
(cll readers will be familiar with this).
However a lot of programs spend a lot of time doing stuff where the
typechecking overhead seems to be in the noise. Anything that's
building and manipulating large complex data structures is probably
spending a lot of its time chasing pointers and worrying much more
about cache misses and so on than exact details of types.
As an example, I have a system (in Lisp) which parses structures from
a stream, amd then does various manipulations on them. It has
bnasically no declarations in it. I spent a little time profiling it,
and someone else did some more work. He found a few places where type
declarations help some - mostly declarations that things are
better-sorts-of-arrays so array ndexing can do better (the parser
reads into buffers which are arrays because a lot of what it generates
is strings). We got between 1 and 5% speedup. We might not have
found the big problems of course, but really, it looks like type
declarations don't help here much at all.
--tim
Will Deakin
> However a lot of programs spend a lot of time doing stuff where
> the typechecking overhead seems to be in the noise. Anything
> that's building and manipulating large complex data structures
is > probably spending a lot of its time chasing pointers and
worrying > much more about cache misses and so on than exact details
of > types.
I would agree and make the general point that the lack of enforced
static-typing, in any project that is a worth doing, is a *boon*.
The enforced micro-optimisation and related bugs, security holes and
so on of *forcing* type declaration makes wonder about the need for
static typing[1].
The Graham quote along the lines of how lisp is two languages: a
language for writing programs quickly and quick language for writing
programs[2], springs to mind.
> ...We might not have found the big problems of course, but
really, > it looks like type declarations don't help
here much at all...
...if type declarations is not helping at this point then either you
live with it, or you need a new algorithm ;)
:)w
[1] although subject to change at moments whim.
[2] since this is c.l.l. I'm sure that somebody will correct me ;)
Michael Hudson
> Gareth.M...@pobox.com (Gareth McCaughan) writes:
>
> > Paolo Amoroso wrote:
> > > Does Python provide something similar to CLOS?
> >
> > Yes, if a simple object system with multiple inheritance
> > and lots of dynamism is "like CLOS". No, if wondrous things
> > like CHANGE-CLASS and DEFINE-METHOD-COMBINATION are necessary
> > for being "like CLOS". Python's object system is quite
> > flexible, but I wouldn't want to be responsible for making
> > it behave like CLOS...
>
> Python Object System does not support multiple dispatch.
This is true, and occasionally really aggravating.
> I also believe (I can be disproved on this) that it messes up
> multiple inheritance of slots with the same name. I.e. you need to
> manually disambiguate your slot references, unlike CLOS.
I think this will be better in 2.2 (so long as you use "new-style
classes"), but to be honest I've never looked into the issues that
deeply.
I've been meaning to see if the new stuff in 2.2 will let you do
method combinations. I think so, but haven't actually done it yet.
Cheers,
M.
--
A.D. 1517: Martin Luther nails his 95 Theses to the church door and
is promptly moderated down to (-1, Flamebait).
-- http://slashdot.org/comments.pl?sid=01/02/09/1815221&cid=52
(although I've seen it before)
Erno Kuusela
tfb+g...@tfeb.org (Tim Bradshaw) writes:
| Now imagine the canonical implementation is owned by Microsoft.
| Suddenly it has been changed so it's really hard to make it work on
| any platform other than Windows. Oh, and they've hired 58 people,
| doubled the size of the language and specified a couple of APIs as
| part of it with 4000 ill-defined entrypoints each.
| There is now only one realistic implementation, because no-one else
| can keep up. 2 years later they quietly drop the language in favour
| of visual basic.
sounds a lot like java (except the dropping 2 years later part).
-- erno
Marco Antoniotti
Michael Hudson <m...@python.net> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Gareth.M...@pobox.com (Gareth McCaughan) writes:
> >
> > > Paolo Amoroso wrote:
> > > > Does Python provide something similar to CLOS?
> > >
> > > Yes, if a simple object system with multiple inheritance
> > > and lots of dynamism is "like CLOS". No, if wondrous things
> > > like CHANGE-CLASS and DEFINE-METHOD-COMBINATION are necessary
> > > for being "like CLOS". Python's object system is quite
> > > flexible, but I wouldn't want to be responsible for making
> > > it behave like CLOS...
> >
> > Python Object System does not support multiple dispatch.
>
> This is true, and occasionally really aggravating.
Just re-implemented the "Visitor Pattern" recently? :)
> > I also believe (I can be disproved on this) that it messes up
> > multiple inheritance of slots with the same name. I.e. you need to
> > manually disambiguate your slot references, unlike CLOS.
>
> I think this will be better in 2.2 (so long as you use "new-style
> classes"), but to be honest I've never looked into the issues that
> deeply.
>
> I've been meaning to see if the new stuff in 2.2 will let you do
> method combinations. I think so, but haven't actually done it yet.
Maybe it will. It is not on the "New" list in the 2.2.* Python
advertisement. Remember however, that when we talk about "method
combinations", we do not simply talk about :before, :after and :around
methods. We talk about *programmable* method combinations. Things
that allow you to write things like
(defmethod zut :before :last ((x complex) (y matrix)) ...)
(A little thing I wrote experimenting a few things in Aspect Oriented
Programming, cfr. http://www.aspectj.org).
Hence the question stands: why don't you use CL instead?
Marco Antoniotti
Alain Picard <api...@optushome.com.au> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Why not drop the fixed indentation rule and adopt S-exprs instead?
>
> Well, because the indentation rules are obviously a design goal
> of Python, viewed as desirable by its designers and essentially
> all of the Python community.
>
> > One more random thought: why spend energy on Python when you could
> > spend it on Common Lisp? Note that the opposite is not a valid
> > argument.
>
> Well, I certainly don't see any prima facie evidence of this
> statement, so, if you've got some magic secret that all the Python
> programmers aren't privy to, I'd like to hear it.
Mine is a rethorical argument. Apart from the (admittedly pointed and
gratuitous) sarcasm :) it is my opinion that (a) a lot of people are
pouring energy and money into Python (this is a fact), and (b) the
foundation provided by CL is - still - superior for a pragmatic number
of reasons (compilers, language usability and extensibility).
To give the same weight to the reverse of my sentence, I have to be
convinced that (b) is not right. (b) may or may not right be to some
degree or another, but that is the way I see things. :) (Add as many
smiley as you like). Hence the question I pose to the Python
enthusiast (*)
> Personally, I haven't used Python, but looked into it as a possible
> technology pretty seriously, and found that it would be adequate
> for doing real work, and it was in fact the only serious contender
> to CL I found out there, once you take into considerations things
> like platforms, availability of programmers, libraries, etc etc.
>
> This is a Lisp group, but dissing Python without so much as a reason
> behind it seems going a bit far.
Maybe it is. I agree and I should probably restrain myself. However,
I had a couple of discussions with local (*) who were showing me the
latest and greatest Python feature and that, while being totally
ignorant of CL (or better, knowing a subset of Scheme) and while
showed evidence that the same feature (usually better thought out) was
in CL since 1984, insisted in their "enthusiasm". :)
So, maybe this attitude of mine is just an old geezer's annoyance
with younger guys. Just remember it when I write this stuff and keep
a grin on your face, as I keep on mine.
Michael Hudson
> Michael Hudson <m...@python.net> writes:
>
> > Marco Antoniotti <mar...@cs.nyu.edu> writes:
[...]
> > > Python Object System does not support multiple dispatch.
> >
> > This is true, and occasionally really aggravating.
>
> Just re-implemented the "Visitor Pattern" recently? :)
Not for a while...
> > > I also believe (I can be disproved on this) that it messes up
> > > multiple inheritance of slots with the same name. I.e. you need to
> > > manually disambiguate your slot references, unlike CLOS.
> >
> > I think this will be better in 2.2 (so long as you use "new-style
> > classes"), but to be honest I've never looked into the issues that
> > deeply.
> >
> > I've been meaning to see if the new stuff in 2.2 will let you do
> > method combinations. I think so, but haven't actually done it yet.
>
> Maybe it will. It is not on the "New" list in the 2.2.* Python
> advertisement. Remember however, that when we talk about "method
> combinations", we do not simply talk about :before, :after and :around
> methods. We talk about *programmable* method combinations.
Yes, I know...
Certainly the new stuff wasn't written to make method combinations
possible, but I think it may be flexible enough to let you do it
anyway. Actually, I think it's been possible for a while but it would
been a deeply unpleasant hack. It may still be.
[...]
> Hence the question stands: why don't you use CL instead?
This is all just a hobby for me; I should really be doing a maths PhD.
So maybe Python's more fun to work on because it's less perfect?
Cheers,
M.
--
If I had wanted your website to make noise I would have licked
my finger and rubbed it across the monitor.
-- signature of "istartedi" on slashdot.org
Marco Antoniotti
Michael Hudson <m...@python.net> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
> [...]
> > Hence the question stands: why don't you use CL instead?
>
> This is all just a hobby for me; I should really be doing a maths PhD.
> So maybe Python's more fun to work on because it's less perfect?
Or maybe because you have not found out yet how much more fun it can
be to program in CL? :)
Thom Goodsell
>
> Hence the question stands: why don't you use CL instead?
I realize this may have been rhetorical, but I thought I'd answer it
anyway. I'm a Lisp devotee who does more Python programming than Lisp
programming (at work, anyway). Here's my list of reasons why. Some
(many? all?) of these may be ignorance on my part--I'd love to have
people correct me on these issues.
I should also clarify that my current Python use is primarily for
quick prototyping and personal utilities. The company is way too
C++/Java heavy to get away with using CL (or Python) as a final
implementation language, at this point.
1. Available libraries. I was going to count all the entries on the
"Python Library Reference" page [1], but it's way too big. The
point is, all this stuff is there, installed when I installed the
base package. In addition, 10 minutes of work installed the Python
Imaging Library [2] and the wxPython toolkit [3]. I now have decent
libraries to do the stuff I need most--image and data loading,
manipulation, and display. In addition, if I suddenly decide to
write a mail reader (for example) I've already got ready-to-use
POP, IMAP, SMTP, MIME, and RFC822 libraries.
Sure, some of this stuff exists in Lisp, but I've never found, for
example, image loading libraries for Lisp. Furthermore, good,
well-documented GUIs are only with the commercial versions, and the
likelihood of successfully getting a commercial CL environment
approved for purchase is pretty slim. Yes, I could also write a lot
of this stuff, but with Python it's right there, ready to use. For
those sorts of quick, short-term tasks for which I'm using Python,
that time is better spent building the tool.
2. Cross-platform. While Lisp is far and away a better cross-platform
tool than, say, C++, Python has pretty much all the libraries from
#1 on all the platforms that matter at this company (Unix, Windows,
Mac).
3. Cost. Yes, I know there are free CL implementations; I use CMUCL,
personally. But for Lisp to beat Python on 1 and 2, I need to buy
ACL or LispWorks for Unix; ACL, LispWorks, or CormanLisp for
Windows; and MCL for Macs. At rough calculation, that comes to at
least $1,500 (w/o worrying about possible runtime fees). That's not
much money, in corporate terms, but it's a lot of money just to
support one "irrational" developer who prefers dynamic,
introspective languages.
Please understand that this is not the stereotypical free software
rant. I think commercial software is great, but I don't write the
checks around here.
4. Politics. I actually have a lot more success spreading my
"subversive" views with younger developers. (The ones who only know
C++ and Java, if even that.) The developers over 25 all have
prefashioned ideas about Lisp that are hard to combat. I keep
trying on this issue, and I haven't given up yet, but it's
definitely a factor.
4b. Syntax. Personally, I think that significant indentation is a
stunningly lame idea, and I litter my Python code with 'return' and
'pass' statements so that Emacs will autmatically indent it
correctly. The fact that the syntax looks a lot like Java/C++ is a
political boon. (That's why this is 4b, instead of 5.) That is,
people understand the code more quickly and are, therfore, more
likely to use it, comment on it, improve it, or adapt it.
Whew! So, there are the reasons. I'm nervous, having written this,
that I'm going to get flamed for being to lazy to use Lisp, or
something. I'm trying to change these things: I'm whittling away at
the political obstacles; I'm writing my own CL image manipulation code
is my free time; I'm investigating the CL gtk bindings and FreeCLIM,
and I've tried (and failed) to get Garnet running; I'm even
considering just forking out some of my own cash for a LispWorks
license. I'm not holding my breath, though, and for now I'm using
Python.
Just thought I'd let you know.
Thom
[1] http://www.python.org/doc/current/lib/lib.html
[2] http://www.pythonware.com/products/pil/
[3] http://www.wxPython.org/
--
Thom Goodsell tgoo...@cra.com
Scientist (617) 491-3474 x574
Charles River Analytics http://www.cra.com/
Daniel Lakeland
Bradshaw" <tfb+g...@tfeb.org> wrote:
On a similar type of program I worked on in CMUCL it would run plenty fast
at home on my 233 MHz PII and then when I took it to work and ran it on a
400 Mhz Sparq or something like that, it would be a dog.
Turned out that consing was a big problem, and the x86 had a generational
collector, whereas the Sparq had a mark-sweep.
changing some functions to be non-consing, and changing the interval
between GCs to be about equal to the expected image size made it MUCH
faster. (I was GC'ing every 2MB on an image that had about 25-30 MB of
static in-RAM data, Every 10 seconds or so I'd cons up about 100 MB, so
GCing every 30 MB makes consing amortized to O(n) instead of O(n^2).
With the generational collector, consing was already O(n).
--
Daniel Lakeland
dlak...@endpointcomputing.com
http://www.endpointcomputing.com
Rahul Jain
> b) Modify the Python 'compiler' so instead of compiling to byte codes it
> compiles to CL code.
But the python compiler already compiles CL code to machine code! :)
Honestly, I don't think this will work too well because you'd need to
implement the ideosyncracies of the python classscope system first,
and then you'd need to find some way of mapping the socket
interfaces. Doable, but I don't see the benefit, really. Then again, I
don't program in python, so I wouldn't see any benefit in it. ;)
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:rahul...@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
Marco Antoniotti
Well, after having read your posting I honestly cannot say that your
points are well taken.
I just strongly believe that it is amazing how much waste can be
generated by any human endeavour :)
Having said so, I'll shut my mouth and either go hang myself of write
some code.
Thom Goodsell
>
> >something. I'm trying to change these things: I'm whittling away at
> >the political obstacles; I'm writing my own CL image manipulation code
> >is my free time; I'm investigating the CL gtk bindings and FreeCLIM,
>
>
> a) Modify SWIG to generate CL foreign function call, and make many of those
> libraries available to CL too.
I'd considered this. Is anyone else working on this and interested in
combining efforts?
Thom
John Markus Bjorndalen
> > Why not invest your free time in:
> >
> > a) Modify SWIG to generate CL foreign function call, and make many of those
> > libraries available to CL too.
>
> I'd considered this. Is anyone else working on this and interested in
> combining efforts?
There is another option as well: ffigen[1]. It can generate lisp (or
lispish) forms which can be parsed by a lisp program to generate the
actual ffi forms. It could be easier than modifying SWIG.
I'm not sure excactly how good the C compiler/parser part of LCC (upon
which ffigen is built) is though. You might want to check that out
if the rest sounds interesting.
1. http://www.zipcon.net/~briand/ffigen.html
--
// John Markus Bjørndalen
Paul Rubin
> On a similar type of program I worked on in CMUCL it would run plenty fast
> at home on my 233 MHz PII and then when I took it to work and ran it on a
> 400 Mhz Sparq or something like that, it would be a dog.
>
> Turned out that consing was a big problem, and the x86 had a generational
> collector, whereas the Sparq had a mark-sweep.
CMUCL uses different GC's on different platforms? Or do you mean you
were using CMUCL on one box and a different CL on the other?
cbbr...@acm.org
This misses another option: ILU.
ILU is further interesting in that it subsumes "something somewhat
interoperable with CORBA" into the mix.
--
(concatenate 'string "chris" "@cbbrowne.com")
http://www.cbbrowne.com/info/
When sign makers go on strike, is anything written on their signs?
Daniel Lakeland
<phr-n...@nightsong.com> wrote:
Yes CMUCL uses (or used in Feb 2000) different GC's on different
platforms.
Alain Picard
> Mine is a rethorical argument. Apart from the (admittedly pointed and
> gratuitous) sarcasm :) it is my opinion that (a) a lot of people are
> pouring energy and money into Python (this is a fact), and (b) the
> foundation provided by CL is - still - superior for a pragmatic number
> of reasons (compilers, language usability and extensibility).
Ah, I see. FWIW, I agree with (b).
It's just that a choice of language is so often based on many
more factors that its purely technical merit. Community, for
example, is extremely important. Why, Perl, a truly barfulous
language if one was ever created, probably has the best user
community ever seen in the programming world.
> So, maybe this attitude of mine is just an old geezer's annoyance
> with younger guys. Just remember it when I write this stuff and keep
> a grin on your face, as I keep on mine.
Oh, definitely! But the _real_ way to win over the young 'uns is to say,
"Why, yes, that [Python feature X] is really cool! And did you know that lisp can do
all that AND has this neat thing called MACROS, AND has this totally
kick-ass condition/restart system, and, and ..."
Raymond Toy
Daniel> In article <7xhervy...@ruckus.brouhaha.com>, "Paul Rubin"
Daniel> <phr-n...@nightsong.com> wrote:
>> "Daniel Lakeland" <dlak...@sil-no.spam-con.com> writes:
>>> On a similar type of program I worked on in CMUCL it would run plenty
>>> fast at home on my 233 MHz PII and then when I took it to work and ran
>>> it on a 400 Mhz Sparq or something like that, it would be a dog.
>>>
>>> Turned out that consing was a big problem, and the x86 had a
>>> generational collector, whereas the Sparq had a mark-sweep.
>>
>> CMUCL uses different GC's on different platforms? Or do you mean you
>> were using CMUCL on one box and a different CL on the other?
Daniel> Yes CMUCL uses (or used in Feb 2000) different GC's on different
Daniel> platforms.
That is still true today and for the foreseeable future as well.
Ray
Marco Antoniotti
CORRECTION
Marco Antoniotti <mar...@cs.nyu.edu> writes:
> Well, after having read your posting I honestly cannot say that your
> points are well taken.
The above should read:
Well, after having read your posting I honestly cannot say that your
points are not well taken.
Pierre R. Mai
To give slightly more details for the reasons:
CMU CL (nee Spice Lisp) was originally developed on (RISC)
workstations. In order to allow the direct operation on
unboxed/untagged data, it partitions the register set of the
underlying processor into tagged and untagged register subsets (and
corresponding stacks), so that garbage collection can occur at
(nearly) any point in time, without having to worry about untagged
values being mistaken for lisp pointers, etc.
When CMU CL was ported to x86 in the 90s, keeping up this partitioning
scheme would have resulted in very bad performance, given the relative
scarcity of general purpose registers on x86 machines, and the
resulting register pressure. For that reason CMU CL on x86 needed a
conservative GC, that could deal with unboxed/untagged values in
normal registers and the stack. That is where the divergence started.
Since most development on certain areas of CMU CL happened on x86
during the 90s, CMU CL on x86 currently has a number of features that
haven't been (fully) ported to the other platforms, like e.g.
multi-processing and the generational aspects of the conservative GC
on x86.
Regs, Pierre.
F'up to comp.lang.lisp set, since I don't think that further
discussion is that interesting to those that use Python the language
(and not Python the CMU CL compiler). Feel free to ignore it, if I'm
mistaken...
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Thom Goodsell
> CORRECTION
>
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Well, after having read your posting I honestly cannot say that your
> > points are well taken.
>
> The above should read:
>
> Well, after having read your posting I honestly cannot say that your
> points are not well taken.
something.
I'll try to contribute as much as possible back to the community as I
find time to address these issues. Thanks all for the suggestions so far.
Thom
Marco Antoniotti
Thom Goodsell <tgoo...@cra.com> writes:
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
> > CORRECTION
> >
> > Marco Antoniotti <mar...@cs.nyu.edu> writes:
> >
> > > Well, after having read your posting I honestly cannot say that your
> > > points are well taken.
> >
> > The above should read:
> >
> > Well, after having read your posting I honestly cannot say that your
> > points are not well taken.
>
> Thanks for clarifying; I was wondering if I had totally missed
> something.
>
> I'll try to contribute as much as possible back to the community as I
> find time to address these issues. Thanks all for the suggestions so far.
You are welcome. I was just too hasty.
cbbr...@acm.org
> When CMU CL was ported to x86 in the 90s, keeping up this partitioning
> scheme would have resulted in very bad performance, given the relative
> scarcity of general purpose registers on x86 machines, and the
> resulting register pressure. For that reason CMU CL on x86 needed a
> conservative GC, that could deal with unboxed/untagged values in
> normal registers and the stack. That is where the divergence started.
> Since most development on certain areas of CMU CL happened on x86
> during the 90s, CMU CL on x86 currently has a number of features that
> haven't been (fully) ported to the other platforms, like e.g.
> multi-processing and the generational aspects of the conservative GC
> on x86.
Interesting, and certainly not something one would _expect_ to see
happen.
> F'up to comp.lang.lisp set, since I don't think that further
> discussion is that interesting to those that use Python the language
> (and not Python the CMU CL compiler). Feel free to ignore it, if
> I'm mistaken...
Well, to use Python, the CMU CL compiler, as a compiler for Python,
the language, would represent a strangely interesting application, and
one I'd think tremendously likely _not_ to happen.
That's probably regrettable; it would be very nice to see some of the
developments in "Python, the compiler" applied more widely. And for
the application to be "Python, the language" would be almost
Pythonesque. (To take a third meaning :-).)
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://www.cbbrowne.com/info/languages.html
:FATAL ERROR -- ATTEMPT TO USE CANADIAN COINS
Paul Rubin
> Well, to use Python, the CMU CL compiler, as a compiler for Python,
> the language, would represent a strangely interesting application, and
> one I'd think tremendously likely _not_ to happen.
Why do you say that?
Erik Naggum
| When CMU CL was ported to x86 in the 90s, keeping up this partitioning
| scheme would have resulted in very bad performance, given the relative
| scarcity of general purpose registers on x86 machines, and the
| resulting register pressure.
However, this performance issue is largely gone in more modern members of
the IA32 family. Good scheduling of stack-to-register operations will
result in no worse performance than if you have many more registers. It
is amazing what Intel has managed to do with the 8080 instruction set. :)
Most, if not all, of the register starvation issues, which were very real
only a few years ago, are now _only_ an issue if you do poor instruction
scheduling, as when you generate code for the old members of the family,
where such operations would not have been pipelined and the memory waits
were much, much longer. Generating code for a (80)686 is very different
from generating code for an 80386, if you want optimal performance. In
effect, you have to generate code for the underlying machine and then
figure out how to express this in the relatively high-level instruction
set, which only accidentally runs old 386 code fairly fast. Really good
performance on modern members of the IA32 family will produce really poor
performance on old members. I suspect that it costs a hell of a lot of
money to keep up with this and that much old-style optimization is going
on in less than fully supported compilers.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
Gareth McCaughan
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
> >
> > Hence the question stands: why don't you use CL instead?
>
> I realize this may have been rhetorical, but I thought I'd answer it
> anyway. I'm a Lisp devotee who does more Python programming than Lisp
> programming (at work, anyway). Here's my list of reasons why. Some
> (many? all?) of these may be ignorance on my part--I'd love to have
> people correct me on these issues.
As someone else in a similar position, here are a few more
advantages of Python over CL. There are of course many,
many more advantages of CL over Python. I post about some
of *those* over on c.l.python from time to time. :-)
- Python's generic collection lookup functions are neater
than CL's. In CL you have NTH for lists, AREF and its
variants for arrays, GETHASH for hash tables; ELT works
for lists and vectors, but nothing else; any user-defined
collection needs to use something else again. In Python,
it goes like this:
a[3] element 3 in a list (i.e., adjustable vector)
d["foo"] an element of a dictionary (i.e., hash table)
x[1,2,"blah"] an element of a user-defined collection
Of course there's nothing stopping you imitating this
in CL. Define a generic function (REF, say) that does
the right thing with lists, vectors, arrays, hash tables;
define (SETF REF) too; and you're done. (Unless you want
to go further and hack the readtable too.)
- The fact that Python's library is mostly partitioned into
modules makes it less likely that a name you want to define
will already be taken. (On the other hand, Python's impoverished
notion of what counts as an identifier means that its namespace
is smaller to begin with. I still find that names I want are
reserved more often in CL than in Python.)
- More of Python's library can adapt and work with user-defined
types than of CL's. Most of CL's sequence functions work
with lists, or vectors, or lists-or-vectors. If you build
some new collection object and want to be able to iterate
over it, you have to define your own ways to do it. (Or
convert to a list or vector first.) All Python's sequence
functions will work even if what you hand them is some
completely new kind of sequence you've just made up.
- Python's syntax leans more than CL's in the direction of
"optimizing the common case". Of course, what's common
varies a lot, but (mumble self-fulfilling prophecy mumble)
the operations Python's syntax makes especially painless
are ones I use a lot in Python. For instance:
- "foo"+"bar"+"baz" versus (concatenate 'string "foo" "bar" "baz")
- things[:-2] versus (subseq thing 0 (- (len things) 2))
- {"foo":1, "bar":2} versus
(let ((d (make-hash-table :key #'equal)))
(setf (gethash "foo" d) 1
(gethash "bar" d) 2)
d)
As with the first point above, there's no difficulty
making CL say these things concisely. Note, though, the
usual argument against heavy use of macros for things
like this: you end up with a private dialect of Lisp
which is much less comprehensible to others. I'm not
convinced this is a big deal, but in Python the issue
doesn't even arise.
Some of Thom's other reasons are reasons for me too:
- Handy libraries for Python that have no equivalent for CL,
or no equivalent of similar or better quality.
- Python is much easier politically. It's a shame that this
matters.
Let me emphasize that none of this is meant to imply that
Python is "better" than CL. Only that it has some genuine
advantages, as well as its glaring disadvantages, compared
to CL. The advantages are mostly "shallower" than the
disadvantages. That's why I think CL is a much better
language.
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Thomas F. Burdick
> As someone else in a similar position, here are a few more
> advantages of Python over CL. There are of course many,
> many more advantages of CL over Python. I post about some
> of *those* over on c.l.python from time to time. :-)
[...]
> - The fact that Python's library is mostly partitioned into
> modules makes it less likely that a name you want to define
> will already be taken. (On the other hand, Python's impoverished
> notion of what counts as an identifier means that its namespace
> is smaller to begin with. I still find that names I want are
> reserved more often in CL than in Python.)
But a Common Lisp image is partitioned into packages. The identifiers
(or their symbol-names, anyway, which is what you're complaining
about) *aren't* reserved. You can't change cl:lambda, but there's
nothing special about any other symbol named lambda. There is a
slight overhead in having to do (:shadow ...) in your package
definition, but that's it. Then you just refer to the CL symbol by
typing cl:lambda, which is about as lightweight as I can imagine for
referring to a symbol in another package.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Tim Bradshaw
> sounds a lot like java (except the dropping 2 years later part).
Yes, with the significant difference that Sun are not a monopolist,
and so don't have the option of behaving so abusively. Sun realise
that their interests and `community interest' are fairly (obviously,
not completely) well aligned for the time being.
--tim
cbbr...@acm.org
It's pretty CL-specific; attaching it to Python would pretty much
mandate redefining Python in terms of CL.
There probably are much worse ideas in this big 'ol world of ours; I
also doubt that there's enough cross-over of those "vastly interested
in Python implementation" and also "vastly interested in Common Lisp
implementation," as you would need to have a pretty good feel for both
to make use of the Python compiler.
It would be very _interesting_ to see it happen; it would be very nice
to see there be a compiler back end other than GCC being used for
multi-language work. But I sort of doubt the likelihood...
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://www.cbbrowne.com/info/x.html
"Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"
Marco Antoniotti
cbbr...@acm.org writes:
> Paul Rubin <phr-n...@nightsong.com> writes:
> > cbbr...@acm.org writes:
> > > Well, to use Python, the CMU CL compiler, as a compiler for Python,
> > > the language, would represent a strangely interesting application, and
> > > one I'd think tremendously likely _not_ to happen.
> >
> > Why do you say that?
>
> It's pretty CL-specific; attaching it to Python would pretty much
> mandate redefining Python in terms of CL.
Isn't that the asymptotic curve being followed by Python (not our
beloved compiler) anyway? :)
Espen Vestre
> Isn't that the asymptotic curve being followed by Python (not our
> beloved compiler) anyway? :)
Both Python and Perl seem to be aiming at becoming distinguishable from
CL only by their _looks_ ;-)
--
(espen)
Marco Antoniotti
Kent M Pitman
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > Isn't that the asymptotic curve being followed by Python (not our
> > beloved compiler) anyway? :)
>
> Both Python and Perl seem to be aiming at becoming distinguishable from
> CL only by their _looks_ ;-)
[I've not been doing more than just glancing in periodically in this thread,
so I'm taking this remark out of any possible context and responding to it
on its face. Apologies in advance if that makes any of my remarks out of
place.]
If this were true, it would be a useful result.
There are certainly some administrative issues in cross-calling, but
to me the real core barrier is always data interchange. The felicity
of not having to marshall and unmarshall data, the convenience of having
shared conceptual paradigms, etc. The static languages like C and Pascal,
for example, learned to interoperate because their libraries were linkable
and their data types could be viewed as of similar essential nature, so
an application could be constructed of both. It would be nice to see a
similar comradery evolve among the dynamic languages, where the language
provided syntax and expressive capability rather than capability.
My sense has generally been that Lisp hasn't really resisted adding useful
data types and operations that other languages have, but that other languages
have resisted adding Lisp's data types and operations, so that there was
forever a conceptual wall. If, for example, you don't have heterogeneous
lists, symbols (even symbols with packages), and arbitrary-precision integers,
then you can't really translate the majority of conventionally expressed
data naturally to other languages, and Lisp is forever in a kind of data
ghetto other than callout for limited services or use of language-independent
reps like XML...
Choice of language ought, I think, be a personal matter. It is made not
personal by the contact points. If I had it to do over, I sometimes think
I'd have been better off working on data compatibility/interchange standards
than on language standards.
I once had the opportunity to go to the library in Massachusetts to find out
what the "meaning" of a "red light" was in traffic, for a friend who had
run a "solid red and yellow" light. Part of the law was just painful case
law, more obscure and painful to read than you could imagine. But part of it
was specified in a very thoughtful way. There is a document called "the
manual of uniform traffic control devices" which defines the canonical meaning
of traffic devices throughout the US. A city can pick and choose which devices
to use by merely saying, in so many words, "we implement the flashing white
walk sign" and you can go to that manual and find out what that means. There's
even a template for cities to use to instantiate a full set of traffic laws,
so that the work of spawning this part of a city's laws is trivial. It's quite
a cool piece of design. And I often think language design should be this way.
One should just make whatever syntactic choices they want and then select from
standard data and control flow operations to implement them. Then it would
be transparent what language you used. Instead, because we make data type
idiosyncratic to a language, we make language interchange hard. What
makes people fight over languages is not the fact that party A wants to
restrict what party B does, but rather that the choices made by A infringe
B and vice versa. Were that not so, the problem would be reduced to coping
with those few neurotics who are worried that somewhere, someone is having
fun in the privacy of their own home and they can't keep it from happening;
you'll never get rid of that, but you can at least learn to treat it for
the unwarranted neurosis that it would then clearly be.
Vebjorn Ljosa
|
| I once had the opportunity to go to the library in Massachusetts to
| find out what the "meaning" of a "red light" was in traffic, for a
| friend who had run a "solid red and yellow" light. Part of the law
| was just painful case law, more obscure and painful to read than you
| could imagine. But part of it was specified in a very thoughtful
| way. There is a document called "the manual of uniform traffic
| control devices" which defines the canonical meaning of traffic
| devices throughout the US.
It's available on the web: <URL:http://mutcd.fhwa.dot.gov/>.
--
Vebjorn Ljosa
Paolo Amoroso
wrote:
> personal by the contact points. If I had it to do over, I sometimes think
> I'd have been better off working on data compatibility/interchange standards
> than on language standards.
In a way, you already have: in Lisp, code is data :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Thom Goodsell
This is fast spinning off-topic, but your comment about the MUTCD
brought back some memories. While the MUTCD is, indeed, a great idea,
some people just fail to get it. Witness, for example, my town (in
Massachusetts, coincidentally):
http://www.schlichtman.org/badsign.html
Addressing the original topic, I'm sure that no matter how elegant the
mythical common data architecture was, some well meaning but ignorant
language designers would hijack the data and use it
inappropriately. If any of those languages became popular (and they
might, if they exploited the data correctly), then the whole point of
the architecture is lost.
Håkon Alstadheim
[snip]
> One should just make whatever syntactic choices they want and then
> select from standard data and control flow operations to implement
> them. Then it would be transparent what language you used.
Microsoft .NET anyone ? Pity the VM/datatypes are a bit lisp-hostile
from what I hear.
--
Håkon Alstadheim, Montreal, Quebec, Canada
Thomas F. Burdick
> Kent M Pitman <pit...@world.std.com> writes:
> [snip]
> > One should just make whatever syntactic choices they want and then
> > select from standard data and control flow operations to implement
> > them. Then it would be transparent what language you used.
> [snip]
>
> Microsoft .NET anyone ? Pity the VM/datatypes are a bit lisp-hostile
> from what I hear.
.NET is language-neutral if your language is very much like Java.
Which isn't very neutral sort of neutrality. I mean, it's even
hostile to SmallTalk!
Pierre R. Mai
> * "Pierre R. Mai" <pm...@acm.org>
> | When CMU CL was ported to x86 in the 90s, keeping up this partitioning
> | scheme would have resulted in very bad performance, given the relative
> | scarcity of general purpose registers on x86 machines, and the
> | resulting register pressure.
>
> However, this performance issue is largely gone in more modern members of
> the IA32 family. Good scheduling of stack-to-register operations will
> result in no worse performance than if you have many more registers. It
> is amazing what Intel has managed to do with the 8080 instruction set. :)
That is most certainly true. Similarly for AMD's Athlon chips. I'm
especially impressed by the speed of modern FPUs, while still keeping
up the pretense that you're working with an 8087.
> Most, if not all, of the register starvation issues, which were very real
> only a few years ago, are now _only_ an issue if you do poor instruction
> scheduling, as when you generate code for the old members of the family,
> where such operations would not have been pipelined and the memory waits
> were much, much longer. Generating code for a (80)686 is very different
> from generating code for an 80386, if you want optimal performance. In
> effect, you have to generate code for the underlying machine and then
> figure out how to express this in the relatively high-level instruction
> set, which only accidentally runs old 386 code fairly fast. Really good
> performance on modern members of the IA32 family will produce really poor
> performance on old members. I suspect that it costs a hell of a lot of
> money to keep up with this and that much old-style optimization is going
> on in less than fully supported compilers.
Indeed. Actually Python profits somewhat from the fact that (other
than the decision to remove the segregation of registers) Python never
was optimized that much for the 386, or even the original Pentium,
which now sometimes pays off in a sort of round-about way.
But lack of developer resources means that many interesting things
w.r.t. Python development will not happen.
For any student reading here: Creating a Python backend for the iA64
might be an interesting project, especially since the frontend/backend
boundary of Python is pretty maleable, which might prove advantageous
for efficient code generation for iA64.
Depending on the success of AMD's 64bit architecture, a more classical
port of CMU CL to that might be a stepping stone to a 64bit CMU CL
implementation.
Regs, Pierre.
Xah Lee
I'm amazed that even a lisp website maintainer would echo such crap.
i'm amazed at the world of ignorant living zombies that is just about
everyone, walking and driveling in daylight unassuming and carefree.
Dear Paolo Amoroso, please save me the breath and voluntarily come forward
to explain yourself in public why what you said before as i quoted is utter,
senseless crap.
"Even with the utterly lost, to whom life and death are equally jests, there
are matters of which no jest can be made."
-- Edgar Allan Poe, The Masque of the Red Death (1842)
Xah
x...@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
Eric Marsden
kmp> There are certainly some administrative issues in
kmp> cross-calling, but to me the real core barrier is always data
kmp> interchange. The felicity of not having to marshall and
kmp> unmarshall data, the convenience of having shared conceptual
kmp> paradigms, etc. The static languages like C and Pascal, for
kmp> example, learned to interoperate because their libraries were
kmp> linkable and their data types could be viewed as of similar
kmp> essential nature, so an application could be constructed of
kmp> both. It would be nice to see a similar comradery evolve among
kmp> the dynamic languages, where the language provided syntax and
kmp> expressive capability rather than capability.
this sounds like one of the motivations for the Poplog project, whose
virtual machine supports Pop-11, Prolog, CL and SML.
,---- http://www.poplog.org/about/faq-list.html
| Poplog is a multi-language Artificial Intelligence development
| environment, in which Pop-11 is the core language and Prolog, Common
| Lisp, and Standard ML are also supported in any combination.
|
| The implementation of Pop-11 and all the other language is based on
| pop-11 tools for developing incremental compilers that can also be
| used to implement other languages which will then run wherever Poplog
| does.
|
| Poplog provides a high level language-independent and machine-
| independent virtual machine (the Poplog Virtual Machine) which is rich
| enough to support a wide range of languages. There are Pop-11
| procedures for planting instructions for this virtual machine. When
| the instructions reach the end of a procedure definition, the high
| level PVM instructions are compined in a machine independent fashion
| to a low level Poplog Implementation Machine. The instructions at that
| level are then compiled incrementally (a procedure at a time) using a
| machine dependent "back end" compiler to instructions for the current
| machine. This two level incremental compiler is used by all the Poplog
| languages.
|
| Poplog compiled procedurs are data-structures in the heap and can be
| garbage collected, unlike compiled procedures in some other AI
| languages.
|
| During system development and porting to a new machine a different
| back end is used which produces files of assembler for the target
| machine (and other information required during the linking phase).
|
| Because of all this most of the core of the poplog system is
| implemented in Pop-11 (in a special dialect with some C-like
| extensions to provide more efficient low level mechanism.) Building a
| new version therefore always requires access to a running Poplog. The
| advantage of using Pop-11 as the main implementation language rather
| than C or C++ is that Pop-11 (like Lisp) is a higher level language
| making system development much easier and more reliable. Also new
| features can be developed as Pop-11 code in libraries available to
| users, and then after thorough testing can later be incorporated into
| the system.
`----
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Kragen Sitaker
> I went back and forth with Paul a few times re: Lisp vs. Python, and
> in the end the only really serious differences we could come up with
> were
> (a) Lisp's universal (i.e., non-) syntax makes it easy to write
> little languages and to use macros, and
> (b) Lisp compilers exist today
> which produce quite a bit more efficient code than Python's
> interpreter can do. [Forgive me, Paul, if I'm mis-remembering.]
>
> (a) could be tackled, if someone were seriously inclined, by getting
> the Python folks to agree on an intermediate Lisp-like syntax (lists),
We have ASTs and bytecode, and, in fact, there's already a working
macro system in bytecodehacks. But I don't think it will have the
same effect, even if the macro system is incorporated into Python so
you don't have to invoke it explicitly.
> (b) is only a matter of time & will.
I emphatically disagree. Every feature that is added to Python that
is not written in Python is a step backwards for alternative
implementations. And Python seems to be adding new features at a
blistering pace: __slots__, listcomps, augmented assignment operators,
metaclasses, class methods, __get__ and __set__, generators, nested
scopes, types being more like classes, iterators --- the list goes on
and on.
(b) will never happen if features continue accreting at this rate, no
matter how much time and will we put into it; the Python compiler
project will remain as experimental and useless as WINE. Implementing
cool language features in a high-performance compiler is just
inherently more difficult than implementing them in an interpreter.
I wish there were a fast Python compiler, but I don't expect one.
Fredrik Lundh
> I emphatically disagree. Every feature that is added to Python
> that is not written in Python is a step backwards for alternative
> implementations.
it sure is a pain in the ass.
</F>
Morten W. Petersen
> First off, to save everyone some time, I'm wondering if there are more
> papers documenting the difference between the two; if there aren't any,
> I'd like to continue the discussion and summarize the findings in a paper
> accessible on the net.
Ok, there's been lots of good feedback. I don't have time to make a document
documenting the differences right now, but plan to do so, probably at the start
of next year.
Thanks everyone for constructive feedback! :-)
Regards,
Morten