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 above page contains several factual errors about Common Lisp. It
is not a good summary and it is misleading, especially about Common
Lisp. As such it must be disregarded.
> http://www.norvig.com/python-lisp.html
This is a very good document, by a person with a very good reputation
and who knows what he is talking about.
> 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.
There are a number of (maybe obscure) advantages to Common Lisp
w.r.t. Python.
Apart from the existence of very good native compilers, there are a
number of nice features - all standard - that allow you to use Common
Lisp as a "language kit": something very few other language are good at.
Take for example one of the latest additions to Python: list
comprehension.
This is essentially incorporating regular set-theoretic notation in
the language. I.e. to have notation that allows you to say things like
{x | even(x) /\ x >= 0 /\ x <= 100}
(the set of "numbers" between 0 and 100 - assuming integers or rational,
this is a finite, enumerable set).
To get this kind of notation into Python (alas a similar one), AFAIU,
the (1) parser had to be modified, and (2) the interpreter had to be
modified as well. This are not things that (AFAIK) where done in
Python itself.
In Common Lisp you just changed the "readtable" to recognize the
special nature of the characters #\{, #\}, #\[, and #\] (think of
Emacs and what it does with characters) and you write a couple of
macros. The code is all written in CL and the above example may be
rendered as
{x / x in (range 0 100) / (evenp x)}
This effectively constructs a list of the even integers. All of this is
all CL and it is all compiled down to native code. (The above expression
"expands" into a LOOP, which is happily compiled by the CL system. The
code runs on all CL implementations and it can be used to shorten your
programs.
Here is a better example of legal CL code constructing a list of the
prime numbers from 3 up to `max'.
(defun primes (max)
[n in (range 3 max 2)
/ (not (exist m in (range 3 (min (1- n) (+ 2 (sqrt n))) 2)
/ (= (mod n m) 0)))])
(Note the optional indentation! Of course you can use the INFIX
package to write the customary 2 + sqrt(n), but that is just another
trick you can do with Common Lisp).
Again the above is legal CL (once you load the appropriate 300 lines
of code) and it gets compiled to native code.
Of course the underlying data structure for "set" is naive, but that
is a different problem. Given time you could implement spme
hash-indexed B-tree representation for sets and replace with that the
guts of the notation rendering. All of that can easily be done in 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
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
Manoj Plakal
I'm curious (I haven't done much programming in Lisp).
Doesn't this make CL programs harder to read? I can see
why a programmer would love it since it allows you to
define your own little language that fits your way
of thinking and a problem domain. I've heard of Lisp
programmers going gaga over the macro facility.
But isn't it going to be difficult for someone other
than the original programmer to come along and try to
figure out what's going on? They're going to have to absorb
the macro definitions before trying to read even
a small part of the code that uses these macros.
A similar thing happens when
people go nuts with the C preprocessor or C++
operator overloading. You get either innocent-looking
code that actually has very different semantics
than what you thought, or completely baroque code
which can only be understood by reading a whole
lot of other code that is defining macros and stuff.
How much of a problem is this in practice for CL?
Manoj
Marco Antoniotti
Manoj Plakal <pla...@cs.wisc.edu> writes:
> I'm curious (I haven't done much programming in Lisp).
>
> Doesn't this make CL programs harder to read? I can see
> why a programmer would love it since it allows you to
> define your own little language that fits your way
> of thinking and a problem domain. I've heard of Lisp
> programmers going gaga over the macro facility.
>
> But isn't it going to be difficult for someone other
> than the original programmer to come along and try to
> figure out what's going on? They're going to have to absorb
> the macro definitions before trying to read even
> a small part of the code that uses these macros.
I believe you make a very good point w.r.t. the "SetL" package for
CL. That is, the extension to CL I wrote to use set theoretic
notation within CL programs. When using it, you are writing in a "non
traditional" CL/Lisp notation, hence, your programs may not be
"readable" by people who are not familiar with the notation.
The "SetL" package was written to illustrate a capability of CL
systems and to provide a package for people who want to use it. If
you want to use it, you'd better advertise that you are using it and
point to the relevant documentation (which I guiltily did not provide :) ).
In a more "traditional" setting, writing macros in CL is a useful
thing, because "regular" macros do not - in my experience - deviate
much from "traditional" CL code.
Let's take the (standard) macro `defclass'. You write
(defclass my-class (super-class-1 super-class-2)
((slot1 :accessor slot1 :initarg :s1)
(slot1 :accessor slot1 :initarg :s1)))
this is usually defined as a macro and its syntax is "traditionally"
CL. A different macro is
(defsystem bio-l
:source-pathname "BIOL:"
:components ((:file "biol-package")
(:module "sequences"
:components ("seq" "alignments"))))
`defsystem' is another macro (in the publicily available "MAKE"
package).
All in all when you see a `def*' form in a CL program, you know that
(most likely) you are looking at a macro. Hence you have a visual
clue.
Other "traditional" macros are of the form `with-*'. THe typical
example is `with-open-file'
(with-open-file (f "the-file")
(read f))
This effectively expands into something like
(let ((f (open "the-file"
:direction :input :if-does-not-exist :error)))
(unwind-protect
(read f)
(close f))))
I.e. the macro is used to ensure that some "cleanup" form is
effectively used.
In my experience, the most common forms of macros fall three
cathegories: defining macros, with-* style macros and "efficiency"
macros.
Of course, you have other forms of macros. Large packages give you
several macros that you must understand before you use them. But in
these cases (I am thinking, e.g. of the SERIES package), you know that
you need to learn how to use them.
> A similar thing happens when
> people go nuts with the C preprocessor or C++
> operator overloading. You get either innocent-looking
> code that actually has very different semantics
> than what you thought, or completely baroque code
> which can only be understood by reading a whole
> lot of other code that is defining macros and stuff.
>
> How much of a problem is this in practice for CL?
As I said before, macro use in CL is extremely powerful, but it is
also used in some "patterns". This helps.
Operator overloading in C++ has been the source of misunderstandings.
I think this is because of the initial confluence of "namespace" and
"classes". In CL classes are not used for namespace purposes. CL
packages are like (well, almost) Ada packages and newer C++
namespaces. Moreover, to "overload" a function you must either design
it to be like that from scratch or go against the standard. Let's
take an example. Writing a "Matlab-like" math package, requires you
to redefine '*' to take matrix operands.
From the point of view of the programmer this requires to state at the
package level that you are "shadowing" the standard '*' operator.
==============================================================================
(defpackage "MATRIX" (:use "COMMON-LISP")
(:shadow cl:*) ; Note the explicit reference to the standard '+' operator
(:export "*")
)
==============================================================================
Then you need to write *in the MATRIX package* the "overloaded" version.
==============================================================================
(in-package "MATRIX")
(defmethod * ((n1 number) (n2 number)) ; This '*' is really matrix:*
(cl:* n1 n2)) ; Explicit reference to the standard '*'.
(defmethod * ((n number) (m matrix))
;; code for scalar product
)
(defmethod * ((n complex) (m matrix))
;; code for scalar product, specialized on complex scalar.
)
(defmethod * ((m matrix) (n number))
;; code for scalar product; commutative version
)
(defmethod * ((m1 matrix) (m2 matrix))
;; code for matrix product
)
...
==============================================================================
Now, this allows you to "overload" the '*' operator.
From the "user" point of view, he needs to know what s/he can use. If
s/he decides to work in the MATRIX package, s/he will have to know
that '*' has been "extended". IMHO, in cases like this, CL offers
more control over what you see. Add to this the tendency of CL
programmers to use very-long-and-explicative-names-for-their-functions
and you see how the problems are tamer that they may seem.
Of course your mileage may vary, and "RTFM" is the commandament you
must follow :)
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
Marco Antoniotti
tfb+g...@tfeb.org (Tim Bradshaw) writes:
...
> `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.
These are very good points.
Let's take an example of what may illustrate the difficulties the CL
community faces w.r.t. the "single-implementation/single-standard"
language communities.
The ANSI standard does not specify a function for "splitting"
strings. Maybe an historical oversight, yet that is the way things
are.
It turns out that it is very easy to write such a function (not only:
it is easy to write it in such a way that it operates on every CL
`sequence'). The signature may look like:
(defun split-sequence (sequence
&key
(separators (list #\Space))
(start 0)
(end nil)
(test #'eql)
(from-end nil))
...)
Now: to get this into the "standard" is out of the question.
To get this to run in every implementation (some commercial,
some DFSG compliant, some public domain) is easier.
To ensure that upon fring up you CL you can do
your-cl-prompt> (split-sequence "I am a string")
("I" "am" "a" "string")
your-cl-prompt> (split-sequence (vector 1 2 3 0 5 6 7 0 9)
:separators '(0)
:test #'=
:start 4)
(#(1 2 3 0) #(5 6 7) #(9))
is an entirely different community issue.
Of course you may judge this state of affairs severely or not. It is
just the ways things are.
William Tanksley
[macros]
> I'm curious (I haven't done much programming in Lisp).
> Doesn't this make CL programs harder to read?
No.
In the hands of a bad programmer, macro-laden source is a true horror, but
this doesn't change anything: a bad programmer's source is a horror
whether he uses macros or not. In the hands of a good programmer, though,
macro allow you to grow the language closer to the solution domain, so
that your solution can look natural and clear to people who understand the
problem.
So there's a lot to gain, and not much to lose.
> Manoj
--
-William "Billy" Tanksley
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
Marco Antoniotti
Historical cruft? The evolution of the languages have been different.
The presence of strong vendors in the CL camp does (IMHO) work as a
disincentive to community wide standardization.
On top of that add the dwindling support for CL as a whole,
irrespective of the technical merits of the language itself.
Things are changing, yet slowly. This is just the way things are.
As for "widely used though non-standard libraries for CL for "doing
stuff like internet programming", you can check the CLOCC
(http://sourceforge.net/projects/clocc). Not much, but it is there.
Andrew Dalke
>Historical cruft? The evolution of the languages have been different.
>The presence of strong vendors in the CL camp does (IMHO) work as a
>disincentive to community wide standardization.
Interesting. So by *not* having a strong advocacy for Python,
there isn't the urge to have multiple competing implementations,
so Python can keep developing new 'standard' libraries?
I like that approach -- less arguments and more code :)
[Seeing that you didn't cross-post to c.l.lisp ..]
I always seemed to me too easy to make new Lisps, and many of the
people doing Lisp argue for esthetic purity, which leads to the
large number of variations in the language. Python has always
felt more pragmatic, and pragmatically speaking it's easier to have
one standard, reference platform from which other implementations
derive, rather than through a language spec.
>As for "widely used though non-standard libraries for CL for "doing
>stuff like internet programming", you can check the CLOCC
>(http://sourceforge.net/projects/clocc). Not much, but it is there.
I know little about CL systems, which is why I quoted the original
statement from someone else.
Andrew
da...@dalkescientific.com
Marco Antoniotti
"Andrew Dalke" <da...@dalkescientific.com> writes:
> Marco Antoniotti:
> >Historical cruft? The evolution of the languages have been different.
> >The presence of strong vendors in the CL camp does (IMHO) work as a
> >disincentive to community wide standardization.
>
> Interesting. So by *not* having a strong advocacy for Python,
> there isn't the urge to have multiple competing implementations,
> so Python can keep developing new 'standard' libraries?
>
> I like that approach -- less arguments and more code :)
I guess :}
>
> [Seeing that you didn't cross-post to c.l.lisp ..]
>
I try never to cross post. I believe it makes it difficult to follow
a discussion and it augments the noise.
> I always seemed to me too easy to make new Lisps, and many of the
> people doing Lisp argue for esthetic purity, which leads to the
> large number of variations in the language.
THis argument was true until the early nineties. Now people make
(because it is relatively easy) new Scheme's, all slightly
incompatible. Common Lisp is remarkably stable and with a large set
of primitives.
> Python has always felt more pragmatic, and pragmatically speaking
> it's easier to have one standard, reference platform from which
> other implementations derive, rather than through a language spec.
This is true of Python and Perl and other languages (INTERCAL
included :) ). Common Lisp did simply not evolve like this. In the
early eighties there was a lot of money being poured into "Lisp", and
vendors appeared very early in the process. Once you have people with
a lot at the stake and you get committed to a stadardization process
you slow down.
The ANSI CL standard (not very usable as a tutorial, but very good
indeed) provides a sound and very flexible foundation upon which to
build various systems. Unfortunately, whatever is not in the
standard, makes it relatively difficult to write "very" (note the
quotes) portable code.
Take the case of C/C++ interfaces. Every CL implementation allows you
to interface to - at least - C. This means that you could always link
in C code into your application. However, in CMUCL you do it in one
way, while in ACL you do it differently. And, up to this point there
has not been any incentive or energy to come up with either a
"reference implementation" for a C interface (a Foreign Function
Interface), or a specification document accepted by all the people
with a stake in CL.
> >As for "widely used though non-standard libraries for CL for "doing
> >stuff like internet programming", you can check the CLOCC
> >(http://sourceforge.net/projects/clocc). Not much, but it is there.
>
> I know little about CL systems, which is why I quoted the original
> statement from someone else.
Maybe it's time to have a better look at CL?!? :)
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
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.
Alex
...
>(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".
Wouldn't that be great? Sort of Dylan with a meta-programming emphasis...
We're also not that far from the land of Parrot, and should be proposing
that Parrot use a syntax-tree intermediate language (like Forth) instead of
bytecode (like .NET and Java),
There was some discussion of these approaches for Scheme implementations -
see c.l.scheme subject "bytecode v. syntax tree" from last August. One
pointer from there was to work by Anton Ertl on compiler back-ends:
http://www.complang.tuwien.ac.at/projects/backends.html
Now that would be *different*....
cheers
alex
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 ;)
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
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
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?
Daniel Lakeland
<phr-n...@nightsong.com> wrote:
Yes CMUCL uses (or used in Feb 2000) different GC's on different
platforms.
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
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
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?
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
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