Lisp in Python
synthespian
Lisp in Python. Interesting.
Comments from lispers would be an interesting read too :-)
http://www.ibiblio.org/obp/py4fun/lisp/lisp.html
Cheers
Henry
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
Espen Vestre
> Lisp in Python. Interesting.
A Common Lisp implementation of Python would be more interesting,
especially if the python code compiled to efficient CL code.
--
(espen)
Kenny Tilton
will ask themselves, "Why the Hell don't we just use Lisp?!"
:)
kenny
clinisys
Dave Bakhash
> I'm thinking pretty soon the light bulb has to go on and the
> Pythonians will ask themselves, "Why the Hell don't we just use
> Lisp?!"
I think the answer to this question is obvious. Python has many
advantages over CL:
o it's totally free (including the versions that are analogous to what
in the CL community are considered commercial-grade.
o it interfaces very cleanly with Java (note: I'm talking about Jython
here, really...not Python per se). This allows developers to
leverage the substantial amount of work out there that's been done by
the Java community.
o It's a fine language, with some of the same benefits that CL has
(first class functions, runs interpreted or compiled, etc.)
o it's good for both scripting and for large-scale programs
o it runs on just about every platform...probably even more portable
than CLISP (it basically runs wherever there's a working gcc).
It's also more accepted. There's significant momentum behind
Python/Jython that is undeniable. Many websites are switching over to
Python/Jython. The Jython ones often take advantage of J2EE libraries
as well.
CL has a strong case as well...but if CL ever had a rival, it would be
Jython.
Oh...and in about 3/4 of a meg, you can download a simple Java library
(plugin) that implements a complete Jython interpreter right into the
browser. Additional libraries are delivered on-demand. That is my
current understanding, and it is a brilliant design. I don't love
Python syntax, but many people do...and considering that many people
also don't like Lisp's sexp's, it's not something to argue over.
bottom line: there is a very strong argument that Jython has several
important advantages over CL. While I think that the overall idea
expressed in the link Lisp-in-Python paper was not that useful or
interesting, I do see parallels in Python and CL already, and also
places where Jython took the more pragmatic route.
dave
Pascal Costanza
Yes, if Python is really so close to Common Lisp on the semantic level
as some people say, a good Python-2-CL compiler could convince some
people to take a closer look at Common Lisp. The performance would play
an important part here - as far as I remember Python's performance is
not that good, right?
Pascal
Jim Bushnell
news:kw8z1sd...@merced.netfonds.no...
I understand that there is a person associated with FSF who is currently
working on a Python->Guile (the FSF version of Scheme) translator. No reason
why it couldn't be done to CL instead.
Jim Bushnell
Kenny Tilton
Dave Bakhash wrote:
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>
>>I'm thinking pretty soon the light bulb has to go on and the
>>Pythonians will ask themselves, "Why the Hell don't we just use
>>Lisp?!"
>
>
> I think the answer to this question is obvious. Python has many
> advantages over CL:
>
> o it's totally free (including the versions that are analogous to what
...
> o it interfaces very cleanly with Java (note: I'm talking about Jython
...
> o It's a fine language, with some of the same benefits that CL has
...
> o it's good for both scripting and for large-scale programs
...
> o it runs on just about every platform...probably even more portable
> than CLISP (it basically runs wherever there's a working gcc).
>
....
All that is nice (and I mean that), but what i meant was, all these
people working on Python could instead be working on a free CL
implementation, saving themselves the effort of defining a new language.
They would even have CMUCL to start from, a pretty decent head start.
I remember poking around the Python site and discovering a very long
list of "stuff we need to get around to". What a waste for those items
that boiled down to finishing/extending the language per se.
kenny
clinisys
synthespian
Yeah.
But those batteries included are nice.
Knut Arild Erstad
:
: All that is nice (and I mean that), but what i meant was, all these
: implementation, saving themselves the effort of defining a new language.
: They would even have CMUCL to start from, a pretty decent head start.
The CMUCL compiler is actually called Python. I tend to think this would
cause some serious confusion. :-)
--
Knut Arild Erstad
Don't try to solve serious matters in the middle of the night.
-- Philip K. Dick
Stephen J. Bevan
> o it's totally free (including the versions that are analogous to what
> in the CL community are considered commercial-grade.
>
> o it interfaces very cleanly with Java (note: I'm talking about Jython
> here, really...not Python per se). This allows developers to
> leverage the substantial amount of work out there that's been done by
> the Java community.
>
> o It's a fine language, with some of the same benefits that CL has
> (first class functions, runs interpreted or compiled, etc.)
>
> o it's good for both scripting and for large-scale programs
>
> o it runs on just about every platform...probably even more portable
> than CLISP (it basically runs wherever there's a working gcc).
If you use the Java features of Jython then the code doesn't run on
(the C implementation of) Python and hence it doesn't run on just
about every platform, just the ones you have a JVM for. On the other
hand if one programs for the (C implementation of) Python that runs on
just about every platform then one cannot use the Java features of
Jython. Therefore it seems to me that you are comparing Common Lisp
to two languages with two orthogonal features (the ability to use Java
libraries and the ability to run anywhere there is a gcc) not one
which has all features.
> Oh...and in about 3/4 of a meg, you can download a simple Java library
> (plugin) that implements a complete Jython interpreter right into the
> browser. Additional libraries are delivered on-demand. That is my
> current understanding, and it is a brilliant design.
One can do something similar with Kawa or SISC which are based on
Scheme, which while not Common Lisp is perhaps closer than [JP]ython.
John Williams
My experience is that there is a very big gap between the performance
of Python and CL (CMUCL compiler). Indeed it is because of the
performance issues that I moved away from using Python for Web
applications - it was fine for the simple interface stuff but as soon
as I wanted to have more complex calculations such as using Bayesian
networks or automatic crosslinking it ran out of steam. With the
current application (an on-line peer-review system for graduate
students) the difference was about 40-50 fold and it was necessary to
improve the speed to give a satisfactory user experience. Additionally
learning Lisp has been interesting and the expressiveness of the
language has opened my eyes to more elegant algorithms for solving the
problems which gives additional benefits.
>>>>> "Pascal" == Pascal Costanza <cost...@web.de> writes:
Pascal> Espen Vestre wrote:
>> synthespian <synth...@debian-rs.org> writes:
>>
>>> Lisp in Python. Interesting.
>> A Common Lisp implementation of Python would be more
>> interesting, especially if the python code compiled to
>> efficient CL code.
Pascal> Yes, if Python is really so close to Common Lisp on the
Pascal> semantic level as some people say, a good Python-2-CL
Pascal> compiler could convince some people to take a closer look
Pascal> at Common Lisp. The performance would play an important
Pascal> part here - as far as I remember Python's performance is
Pascal> not that good, right?
Pascal> Pascal
--
John
Marco Antoniotti
"Jim Bushnell" <jcbus...@comcast.net> writes:
Exactly. No reason. So why start doing the Guile one? (And AFAIK,
Guile performance is also not that good). :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th 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'.
Daniel Barlow
> : All that is nice (and I mean that), but what i meant was, all these
> : people working on Python could instead be working on a free CL
[...]
> The CMUCL compiler is actually called Python. I tend to think this would
> cause some serious confusion. :-)
Yup. As an SBCL hacker, the thought of having "all these people
working on Python" is very appealing ;-)
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Thomas F. Burdick
> "Jim Bushnell" <jcbus...@comcast.net> writes:
>
> > "Espen Vestre" <espen@*do-not-spam-me*.vestre.net> wrote in message
> > news:kw8z1sd...@merced.netfonds.no...
> > > synthespian <synth...@debian-rs.org> writes:
> > >
> > > > Lisp in Python. Interesting.
> > >
> > > A Common Lisp implementation of Python would be more interesting,
> > > especially if the python code compiled to efficient CL code.
> > >
> > > --
> > > (espen)
> >
> > I understand that there is a person associated with FSF who is currently
> > working on a Python->Guile (the FSF version of Scheme) translator. No reason
> > why it couldn't be done to CL instead.
>
> Exactly. No reason. So why start doing the Guile one? (And AFAIK,
> Guile performance is also not that good). :)
You'd think they'd at least pick one of the fast Schemes to target.
Then again, it might just be vaporware to placate those who would
spend all their time bitching about it, if there wasn't a development
effort "happening".
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
sv0f
<ca...@alum.mit.edu> wrote:
>I think the answer to this question is obvious. Python has many
>advantages over CL:
>
> o it's totally free (including the versions that are analogous to what
> in the CL community are considered commercial-grade.
But of course there are many definitions of the word free. Common
Lisp is "free enough" for many.
Or: In Common Lisp, white space is free. Python, from what I understand,
is "compiler free".
> o It's a fine language, with some of the same benefits that CL has
> (first class functions, runs interpreted or compiled, etc.)
As you know Dave, it lacks other key features (e.g., macros).
> o it's good for both scripting and for large-scale programs
Does the lack of (a) compile(r) hinder Python's effectiveness
for large-scale programs?
>CL has a strong case as well...but if CL ever had a rival, it would be
>Jython.
>
>Oh...and in about 3/4 of a meg, you can download a simple Java library
>(plugin) that implements a complete Jython interpreter right into the
>browser. Additional libraries are delivered on-demand. That is my
>current understanding, and it is a brilliant design. I don't love
>Python syntax, but many people do...and considering that many people
>also don't like Lisp's sexp's, it's not something to argue over.
>
>bottom line: there is a very strong argument that Jython has several
>important advantages over CL. While I think that the overall idea
>expressed in the link Lisp-in-Python paper was not that useful or
>interesting, I do see parallels in Python and CL already, and also
>places where Jython took the more pragmatic route.
If you go the Jython route, does this mean you get a compiler?
Friedrich Dominicus
>
> Exactly. No reason. So why start doing the Guile one? (And AFAIK,
> Guile performance is also not that good). :)
Well you probably know better than me what Guile is for RMS. It's his
favorite lisp-like language. You even could read some years ago that
there will be an Guile based emacs, that even there are people working
on it...
I suggest asking RMS why they do not use Common Lisp. Might be an
interesting reply (well getting none, says enough too)
Happy Lisping
Friedrich
Carl Shapiro
> I suggest asking RMS why they do not use Common Lisp. Might be an
> interesting reply (well getting none, says enough too)
About six months ago I had a brief discussion with Richard Stallman
where I asked him a question similar to yours. His reply was that,
"Common Lisp is eeeeeenormous!".
While there are plenty of perfectly valid reasons to choose some
language other than Common Lisp as a future replacement for Emacs
Lisp, this just isn't one of them.
I've got this feeling that RMS is basically out-of-the-loop these
days.
Paul Dietz
> About six months ago I had a brief discussion with Richard Stallman
> where I asked him a question similar to yours. His reply was that,
> "Common Lisp is eeeeeenormous!".
When I bring up a commercial CL on my system, I get a process that
is about the same size as the one I get when I start emacs.
Conclusion: emacs is eeeeeenormous! :)
Will we be seeing RMS switch to vi?
Paul
laotseu
of knowing the inner 'language' (means : interpreter and/or compiler)
mechanism and writing the appropriate algorithme.
But it's a fact that outstanding execution speed is not the first strength of
Python. Still, the question is : is it fast enough for your needs ?
Laotseu
Basile STARYNKEVITCH
Paul> Carl Shapiro wrote:
>> About six months ago I had a brief discussion with Richard
>> Stallman where I asked him a question similar to yours. His
>> reply was that, "Common Lisp is eeeeeenormous!".
Paul> When I bring up a commercial CL on my system, I get a
Paul> process that is about the same size as the one I get when I
Paul> start emacs.
Paul> Conclusion: emacs is eeeeeenormous! :)
I believe that RMS talked about the CommonLisp language specification,
which is indeed a big stuff. I'm not sure he talked only of process
sizes. And CommonLisp requires not only the core language but also a
very rich standard library. Learning CommonLisp is a very significant
task!
PS: 1 beware of antispam device in my reply email
2 I just changed hosting company, so my DNS is upgrading, and
neither email nor webpage is working till tomorrow.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net
alias: basile<at>tunes<dot>org
8, rue de la Faïencerie, 92340 Bourg La Reine, France
Bulent Murtezaoglu
[...]
BS> I believe that RMS talked about the CommonLisp language
BS> specification, which is indeed a big stuff.
Yes the spec is not minimalist, neither is the language. Compared to
C+libc, C++ + libc + stl, scheme+SRFI's+additional libraries etc. it
is not that huge and certainly not gratuitously so. Is there anything
by RMS that one can read on this? I do remember "don't use tcl wait
for us to complete guile" postings. Anything else?
BS> I'm not sure he
BS> talked only of process sizes. And CommonLisp requires not only
BS> the core language but also a very rich standard
BS> library. Learning CommonLisp is a very significant task!
Learning is a significant task. (<- read out the period aloud) Having
climbed part of the way for both C and common lisp a long time ago, I
am obviously biased, BUT I am not aware of convincing arguments that
learning common lisp is any harder than anything else out there. In
the GNU context it should be _easier_, if nothing else, as proficiency
in emacs usage can be taken for granted. I suspect the consensus in
this NG would be that learning common lisp has very significant
rewards. I doubt RMS would dispute that.
cheers,
BM
Henrik Motakef
> Is there anything by RMS that one can read on this? I do remember
> "don't use tcl wait for us to complete guile" postings. Anything
> else?
There was a rather long thread about a Guild-based Emacs about one or
two months ago, on emacs-devel. Of course some people mentioned Common
Lisp as a non-braindead alternative, and IIRC RMS himself commented on
this. I'm sure there are archives at gnu.org.
Dave Bakhash
ste...@dino.dnsalias.com (Stephen J. Bevan) wrote in message news:
> Therefore it seems to me that you are comparing Common Lisp
> to two languages with two orthogonal features (the ability to use Java
> libraries and the ability to run anywhere there is a gcc) not one
> which has all features.
Not at all. Jython runs, AFAIK, straight from Java. Java tends to be
portable to just about any platform that anyone out there cares about
-- VAX/VMS, OS/2, Linux, AIX, HPUX, SCO, Win32, BSDs...the list goes
on forever. I don't think people have a problem with the portability
of the JVM. It's more or less become the epitome of portability.
Maybe I shouldn't have mentioned Python, as its portability is more of
a function of gcc than the JVM.
But my point was mostly that [JP]ython are portable languages, more so
than the free CL implementations, and have many features lacking in
the analogous CL implementations. Jython, by virtue of Java, has more
features than any CL I am aware of.
> > Oh...and in about 3/4 of a meg, you can download a simple Java library
> > (plugin) that implements a complete Jython interpreter right into the
> > browser. Additional libraries are delivered on-demand. That is my
> > current understanding, and it is a brilliant design.
>
> One can do something similar with Kawa or SISC which are based on
> Scheme, which while not Common Lisp is perhaps closer than [JP]ython.
the bottom line is that Scheme sucks, and I would personally much
rather code in Jython than in Scheme. Unlike Scheme, Python has an OO
model, and that model happens to work well with Java, which is the
reason for its success. The mismatch between CLOS and Java would is
so severe that if CL were to attempt to use Java's libraries (as in
JIL), you have to part from CLOS in some ways...similarly to how CL
implementations of Corba don't allow for specializing on more than one
argument.
My point, all-in-all, is that Jython is probably here to stay. And it
has set a precedent (at least, to me) as the first successful "hybrid"
language. Python had demonstrated its success (at least, in a
particular niche) well before Jython was out and stable. Jython just
added tons of value to an already-successful language by bringing in
Java/JVM technology.
Jython may not be the last of these languages that compile to the JVM,
and work well with Java and its OO model. But it is a clean language
that is many programmers consider a pleasure to program in. I don't
view it as a threat to CL...just as one of the better alternatives. I
think that a good Jython programmer understands the advantage of
leveraging Java. I am working with someone now who uses Jython, and I
know first-hand just how productive Jython development can be. It's
always been very obvious that CL suffers from a lack of standard
libraries. Java does not. Java suffers from poor language design.
Python does not (except for the whitespace madness, and some other
cruft). So while Jython might have some mild shortcomings, CL has a
huge defficiency that Jython doesn't.
dave
dave
Bruce Hoult
Carl Shapiro <cshapi...@panix.com> wrote:
> About six months ago I had a brief discussion with Richard Stallman
> where I asked him a question similar to yours. His reply was that,
> "Common Lisp is eeeeeenormous!".
Hmm.
bruce@k7:~ > l /usr/local/cmucl/bin/lisp
-rwxr-xr-x 1 1000 1000 358257 Feb 5 2001
/usr/local/cmucl/bin/lisp*
bruce@k7:~ > l /usr/bin/emacs
-rwxr-xr-x 1 root root 2979192 Jan 22 2001 /usr/bin/emacs*
One of these things is eight times bigger than the other...
-- Bruce
Will Deakin
> > Basile STARYNKEVITCH writes:
> > I believe that RMS talked about the CommonLisp language
>
> Yes the spec is not minimalist, neither is the language. Compared to
> C+libc, C++ + libc + stl, scheme+SRFI's+additional libraries etc. it
> is not that huge and certainly not gratuitously so. Is there anything
> by RMS that one can read on this?
an interesting study[1] which IIRC showed that common lisp could produce
effective and efficient result quick with even relatively inexperienced
programmers.
I would be interested to see if the same is true of scheme[2] or if this
is specifically the domain of common lisp.
> > Learning CommonLisp is a very significant task!
> Learning is a significant task. (<- read out the period aloud).
Yes. Although, surely you mean "full stop" ;) And would add the sometime
getting out of bed in the morning can be a significant task too...
> In the GNU context it should be _easier_, if nothing else, as proficiency
> in emacs usage can be taken for granted. I suspect the consensus in
> this NG would be that learning common lisp has very significant
> rewards.
FWIW I certainly concur.
:)w
[1] www.flownet.com/gat/papers/lisp-java.pdf
[2] or guile, emacs lisp or whatever lisp decendant you could select.
Will Deakin
> Hmm.
>
> bruce@k7:~ > l /usr/local/cmucl/bin/lisp
> -rwxr-xr-x 1 1000 1000 358257 Feb 5 2001
> /usr/local/cmucl/bin/lisp*
>
> bruce@k7:~ > l /usr/bin/emacs
> -rwxr-xr-x 1 root root 2979192 Jan 22 2001 /usr/bin/emacs*
>
> One of these things is eight times bigger than the other...
;)
Paul Dietz
> I believe that RMS talked about the CommonLisp language specification,
> which is indeed a big stuff.
Is it? Since I haven't seen a specification for, say, emacslisp,
I can't compare. :)
> And CommonLisp requires not only the core language but also a
> very rich standard library.
What the EFF are you talking about? The CL spec describes the
language and all its builtin functions; there is no separate
'standard library', very rich or otherwise.
Are you confusing CL with Scheme, perhaps?
Paul
Bulent Murtezaoglu
[...]
WD> I would be interested to see if the same is true of scheme[2]
WD> or if this is specifically the domain of common lisp.
I think that paper covers scheme programmers also.
BM> [...] Learning is
BM> a significant task. (<- read out the period aloud).
WD> Yes. Although, surely you mean "full stop" ;)
I would have, about 10 years ago, before my foreign brain got used to
the US dialect of your language. A smaller move than scheme->CL,
I'd say.
cheers,
BM
Erik Naggum
| I believe that RMS talked about the CommonLisp language specification, which
| is indeed a big stuff.
This is such an idiotic line.
| And CommonLisp requires not only the core language but also a very rich
| standard library.
It also requires learning a significant amount of computer science. Every
useful programming language in this century has a large standard library of
functions, types, and other supporting technology. Programming languages
that have yet to be brought into the 3rd millennium look smaller only because
their non-standard libraries are much, much larger than standard libraries of
any modern programming language.
| Learning CommonLisp is a very significant task!
More utter nonsense! It takes significantly /less/ time to master Common
Lisp than to master C++ or Java or even Perl or Python. Programming under
Windows requires about two orders of magnitude more stuff to learn than the
language.
If all you can do is repeat nonsense you may believe but you have not thought
about, consider yielding to people who at least spout /original/ nonsense.
(On the off chance that your typographical novelty is semantically relevant,
you should notice that other people write "Common Lisp" and make your claims
about that other language called "CommonLisp" stand out more from what people
might think it means.)
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Pascal Costanza
> Pascal Costanza a écrit:
[...]
>>Yes, if Python is really so close to Common Lisp on the semantic level
>>as some people say, a good Python-2-CL compiler could convince some
>>people to take a closer look at Common Lisp. The performance would play
>>an important part here - as far as I remember Python's performance is
>>not that good, right?
>
> As for much of Lisp code (or C code etc)... performance is at first a matter
> of knowing the inner 'language' (means : interpreter and/or compiler)
> mechanism and writing the appropriate algorithme.
>
> But it's a fact that outstanding execution speed is not the first strength of
> Python. Still, the question is : is it fast enough for your needs ?
Sorry, I didn't mean to bash Python because of its lack of performance.
However, it seems to be feasible to translate Python to Common Lisp and
would give Python a performance boost nearly for free, wouldn't it?
Even if speed is not one of your concerns you wouldn't refuse it, would
you? ;)
Pascal
Pascal Costanza
> The mismatch between CLOS and Java is
> so severe that if CL were to attempt to use Java's libraries (as in
> JIL), you have to part from CLOS in some ways...similarly to how CL
> implementations of Corba don't allow for specializing on more than one
> argument.
Huh? Could you explain in which sense the mismatch between Java's object
model and CLOS is so severe? There are some differences but I don't have
the impression they are severe.
Background: I am currently implementing a JVM in Common Lisp, and the
translation of Java's object model to CLOS seems to be doable as of yet
by way of dedicated method combinations. If there really is some serious
hindrance I would surely be interested in knowing this upfront. ;)
Pascal
Paul Dietz
> bruce@k7:~ > l /usr/local/cmucl/bin/lisp
> -rwxr-xr-x 1 1000 1000 358257 Feb 5 2001
> /usr/local/cmucl/bin/lisp*
>
> bruce@k7:~ > l /usr/bin/emacs
> -rwxr-xr-x 1 root root 2979192 Jan 22 2001 /usr/bin/emacs*
>
> One of these things is eight times bigger than the other...
The CMUCL lisp* is just the loader; locate lisp.core for the guts.
On my machine the CMUCL 18d lisp.core file is 23MB.
Now, GCL is rather small (but it isn't a full ANSI CL at this time).
Paul
Bruce Hoult
Paul Dietz <paul.f...@motorola.com> wrote:
> Bruce Hoult wrote:
>
> > bruce@k7:~ > l /usr/local/cmucl/bin/lisp
> > -rwxr-xr-x 1 1000 1000 358257 Feb 5 2001
> > /usr/local/cmucl/bin/lisp*
> >
> > bruce@k7:~ > l /usr/bin/emacs
> > -rwxr-xr-x 1 root root 2979192 Jan 22 2001 /usr/bin/emacs*
> >
> > One of these things is eight times bigger than the other...
>
>
> The CMUCL lisp* is just the loader; locate lisp.core for the guts.
> On my machine the CMUCL 18d lisp.core file is 23MB.
True. 20127744 bytes here for 18c. But then emacs has a *lot* of other
stuff, too. My /usr/share/emacs is 24 MB, and I haven't installed any
extras myself.
-- Bruce
Donald Fisk
>
> Basile STARYNKEVITCH wrote:
>
> > I believe that RMS talked about the CommonLisp language specification,
> > which is indeed a big stuff.
>
> Is it? Since I haven't seen a specification for, say, emacslisp,
> I can't compare. :)
The Emacs Lisp reference manual's only 70000 lines of HTML.
> > And CommonLisp requires not only the core language but also a
> > very rich standard library.
>
> What the EFF are you talking about? The CL spec describes the
> language and all its builtin functions; there is no separate
> 'standard library', very rich or otherwise.
>
> Are you confusing CL with Scheme, perhaps?
I think what's meant is that there are lots of CL functions
that can be defined easily using other CL functions. How
far down you go before you hit the "core language" is an
exercise in drawing arbitrary boundaries.
> Paul
Le Hibou
--
Dalinian: Lisp. Java. Which one sounds sexier?
RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders,
drugs,
sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by
LSD.
Java evokes a vision of a stereotypical nerd, with no life or social
skills.
Jeremy H. Brown
> It takes significantly /less/ time to master Common Lisp than to
> master C++ or Java or even Perl or Python. Programming under
> Windows requires about two orders of magnitude more stuff to learn
> than the language.
I would argue that this depends on where you draw the line of mastery.
Language primitives? Language syntax? Object models? Libraries?
At the primitives level, I agree with you. Ditto for syntax
(excepting macros.) But CLOS is a *hard* thing to *master*; the Java
object model is comparatively trivial. And libraries, well,
"standard" Java libraries are breeding like rats, so you can never
master the "entire" language at that level.
Scheme, now, that's easier to master than Java et al on all fronts.
Jeremy
Bulent Murtezaoglu
[...]
JHB> I would argue that this depends on where you draw the line of
JHB> mastery. Language primitives? Language syntax? Object
JHB> models? Libraries?
This is a legitimate question to ask, and a tough one to answer. It
is also not clear to me where mastery of a language stops and mastery
of parts of computer science begins.
My gut feeling is it is everything except task-specific libraries. By
task-specific I mean things like GUI and networking libraries as they
require additonal domain knowledge. I am unsure if variants of thread
libraries (C and C++ had quite a few in the late 80's early 90's) can be
included in language mastery.
JHB> At the primitives level, I agree with you. Ditto for syntax
JHB> (excepting macros.) But CLOS is a *hard* thing to *master*;
JHB> the Java object model is comparatively trivial. [...]
Java does less, that's clear. Outside of MOP, what is hard to understand
about CLOS that makes mastering it so difficult? Let's assume a parallel
universe where Keene's book is the first book people read that covers OO,
would CLOS be as hard to master _there_?
cheers,
BM
Paul F. Dietz
> I think what's meant is that there are lots of CL functions
> that can be defined easily using other CL functions. How
> far down you go before you hit the "core language" is an
> exercise in drawing arbitrary boundaries.
But all the builtin CL functions are defined in the spec, so if
he considered them part of a library he'd be counting them
twice (remember, he already complained the spec was large).
His argument only makes sense if there is some large set
of additional functions, not defined in the spec, that are
considered a part of CL.
Paul
Matthew Danish
> At the primitives level, I agree with you. Ditto for syntax
> (excepting macros.) But CLOS is a *hard* thing to *master*; the Java
> object model is comparatively trivial. And libraries, well,
Actually I think the additional effort required to learn CLOS is more
to clear your mind of the misconceptions of the Java/C++ model than of
any innate difficulty of CLOS itself.
I certainly had trouble with CLOS at first because I kept trying to
program it as if it were C++. Now it seems almost trivial to me.
Not to mention, the freedom one gets when dealing with `objects' and not
`machine data' can be a bit overwhelming at first. Would you have ever
considered using a function like MAPCAR if you were accustomed to C++?
Most of the confusion with call-by-value semantics are probably due to
this too.
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish
> As for much of Lisp code (or C code etc)... performance is at first a matter
> of knowing the inner 'language' (means : interpreter and/or compiler)
> mechanism and writing the appropriate algorithme.
Actually I would put this optimization last. Exploiting peculiarities
of your compiler should be the last thing you do, if at all. Choice of
algorithm does not depend on language. You simply need to know which
language constructs provide the behavior you are looking for. Of
course, a language may more conveniently express certain algorithms than
others.
For example, in the case of Python (language) the `list' type is in fact
a vector with O(1) access. In Common Lisp, `list's are linked-lists and
have O(n) access time for arbitrary elements. Whatever the compiler
happens to do is unimportant at this level; the language defines these
particular data-structures and all conforming implementations of the
language should follow this definition.
(It is unfortunate that Python (language) chose the name `list' for what
is not a list, this seems to have resulted in a great deal of confusion,
as witnessed in another recent thread)
Stephen J. Bevan
> Not at all. Jython runs, AFAIK, straight from Java. Java tends to be
> portable to just about any platform that anyone out there cares about
> -- VAX/VMS, OS/2, Linux, AIX, HPUX, SCO, Win32, BSDs...the list goes
> on forever. I don't think people have a problem with the portability
> of the JVM.
If you don't mind non-native ports perhaps. However, on *BSD one
either has to run an older native port (FreeBSD) or run under Linux
compatability which means that some things don't work :-<
> the bottom line is that Scheme sucks, and I would personally much
> rather code in Jython than in Scheme. Unlike Scheme, Python has an OO
> model, and that model happens to work well with Java, which is the
> reason for its success.
Kawa has a OO model that seems to work well with Java too. Obviously
if one uses it, one is no longer programming in standard Scheme but
since the comparison here is with Jython, standards clearly aren't an
issue.
If someone prefers Jython to Kawa or SISC, that's fine by me,
I was just pointing out that if someone wants an interactive
environment that can leverage various Java features, there are couple
of Scheme based ones available. That's obviously not the same as
having a Common Lisp available but some might find it a closer fit
than Python.
Christopher Browne
This seems a somewhat "extreme" claim.
To be sure, I'd not expect to get "multiple dispatch for free" in the
process of FFIing out to a set of Java libraries.
The most I'd expect out of a "Java library binding" would be to have
access to the methods as they are, with the types as specified by the
library, which, being defined in a language that doesn't offer
multiple dispatch, would clearly not include MD instances.
This rather parallels the way that I'd expect an initial binding to
(say) PostgreSQL or Sleepycat DB databases to consist of a bunch of C
calls, and not much more. (The CL binding for Sleepycat DB does not
include any 'multiple dispatch,' FYI, and that distresses me exactly
NOT AT ALL. It does not contain a single DEFMETHOD, and that does not
leave me particularly aghast...)
Not that anything would prevent adding some macrology for
WITH-TRANSACTION or WITH-DATABASE or WITH-QUERY, or of adding some
handy-dandy generic functions to map requested arguments onto those
actually offered by the "alien/FFI" functions.
Multiple dispatch is handy and all, but it only actually /occurs/ if
there are multiple methods defined with varying type signatures, and
CORBA and Java both seem to reflect examples of things where that
won't directly happen.
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://cbbrowne.com/info/spiritual.html
"...make -k all to compile everything in the core distribution. This
will take anywhere from 15 minutes (on a Cray Y-MP) to 12 hours."
-- X Window System Release Notes
Friedrich Dominicus
> Friedrich Dominicus <fr...@q-software-solutions.com> writes:
>
> > I suggest asking RMS why they do not use Common Lisp. Might be an
> > interesting reply (well getting none, says enough too)
>
> About six months ago I had a brief discussion with Richard Stallman
> where I asked him a question similar to yours. His reply was that,
> "Common Lisp is eeeeeenormous!".
I can't believe that. It's do brain damaged. I wonder why they make
Guile bigger and bigger if they do not like that.
Thy try to implement a CLOS like OO system see:
http://www.gnu.org/software/guile/gnu-guile-projects.html#Core
please see the #Core at the end! This means a OO system is though to
be essential part of Guile
Than see the zillions of libraries they are working on.
Another thing which drive me nuts is that some 4 weeks or so ago RMS
posted to the gnu.sources newsgroups and mentioned Guile-Emacs. I
tried to find the most acutal version and found this:
Guile Emacs is a variant of Emacs which is integrating the Guile extension language in addition to Emacs Lisp so to provide a better programming environment for both Emacs users and Guile users.
This version of Guile Emacs is a quick hack; it provides a minimum modification to GNU Emacs. The goal of this project is not to replace the Emacs internals by Guile but to utilize the Guile Scheme interpreter as well as the Emacs Lisp interpreter simultaneously. The project replacing the internals is being done separately, and these two projects will be merged in the future.
Well the quick hack page date back to 07/2000 !!! How intensively are
they working?
Friedrich
Carl Shapiro
> bruce@k7:~ > l /usr/local/cmucl/bin/lisp
> -rwxr-xr-x 1 1000 1000 358257 Feb 5 2001
> /usr/local/cmucl/bin/lisp*
>
> bruce@k7:~ > l /usr/bin/emacs
> -rwxr-xr-x 1 root root 2979192 Jan 22 2001 /usr/bin/emacs*
>
> One of these things is eight times bigger than the other...
These days Gnu Emacs is just as obese as the next piece of modern
bloated software. Hell, even a LispM world load with Zmacs has a
smaller on-disk footprint than Gnu Emacs. Fortunately, we have an
over-abundance of hardware which can effortlessly digest today's
gluttonous applications.
Sorry for preaching to the choir...
Laotseu
> On Wed, Sep 25, 2002 at 10:56:27PM +0200, laotseu wrote:
> > As for much of Lisp code (or C code etc)... performance is at first a matter
> > of knowing the inner 'language' (means : interpreter and/or compiler)
> > mechanism and writing the appropriate algorithme.
>
> Actually I would put this optimization last. Exploiting peculiarities
> of your compiler should be the last thing you do, if at all. Choice of
> algorithm does not depend on language.
Theorically (? not sure this is the right english word ?) no. But
practically, you have to implement the algorithm in a particular
language, so the language does matter.
But I was not talking about optimisation, just about the choice of the
right construct for a particular language, *and* (as a distinct step)
writing the good algorithm.
An exemple of choosing the right construct could be, in C, wether to
use a 'dynamic array' (ie : int **int_array) with realloc() or a
linked list, depending on the intended use of the data structure.
There are cases where you could use one or the other construct for
implementing the same algorithm, but with significant difference when
it come to performance.
> You simply need to know which
> language constructs provide the behavior you are looking for. Of
> course, a language may more conveniently express certain algorithms than
> others.
Ok, that's exactly what I meant.
> For example, in the case of Python (language) the `list' type is in fact
> a vector with O(1) access. In Common Lisp, `list's are linked-lists and
> have O(n) access time for arbitrary elements. Whatever the compiler
> happens to do is unimportant at this level; the language defines these
> particular data-structures and all conforming implementations of the
> language should follow this definition.
> (It is unfortunate that Python (language) chose the name `list' for what
> is not a list, this seems to have resulted in a great deal of confusion,
> as witnessed in another recent thread)
That's was I was talking about when I said "knowing the inner language
mechanisms". I had read the thread you're talking about, and it is an
exemple of not choosing the appropriate construct for a given
language.
Sorry if my point wasn't clear...
Laotseu
Pascal Costanza
> On Wed, Sep 25, 2002 at 08:20:50PM -0400, Jeremy H. Brown wrote:
>
>>At the primitives level, I agree with you. Ditto for syntax
>>(excepting macros.) But CLOS is a *hard* thing to *master*; the Java
>>object model is comparatively trivial. And libraries, well,
>
> Actually I think the additional effort required to learn CLOS is more
> to clear your mind of the misconceptions of the Java/C++ model than of
> any innate difficulty of CLOS itself.
Could you name a few of those misconceptions? (Or alternatively give a
link?)
(This is not a rhetorical question, I am really interested.)
Pascal
--
Pascal Costanza University of Bonn
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Pascal Costanza
> Quoth Pascal Costanza <cost...@web.de>:
>
>>Background: I am currently implementing a JVM in Common Lisp, and
>>the translation of Java's object model to CLOS seems to be doable as
>>of yet by way of dedicated method combinations. If there really is
>>some serious hindrance I would surely be interested in knowing this
>>upfront. ;)
>
> This seems a somewhat "extreme" claim.
>
> To be sure, I'd not expect to get "multiple dispatch for free" in the
> process of FFIing out to a set of Java libraries.
Perhaps there's a misunderstanding here: I am not writing an FFI-like
thing, but rather a kind of JIT that translates Java bytecode into Lisp
code at runtime. So this essentially produces true CLOS classes and
methods. I think you are quite free to do anything you want with the
outcome afterwards.
Matthew Danish
> Matthew Danish <mda...@andrew.cmu.edu> wrote in message news:<2002092521...@lain.res.cmu.edu>...
> > On Wed, Sep 25, 2002 at 10:56:27PM +0200, laotseu wrote:
> > > As for much of Lisp code (or C code etc)... performance is at first a matter
> > > of knowing the inner 'language' (means : interpreter and/or compiler)
> > > mechanism and writing the appropriate algorithme.
> >
> That's was I was talking about when I said "knowing the inner language
> mechanisms". I had read the thread you're talking about, and it is an
> exemple of not choosing the appropriate construct for a given
> language.
I interpreted your statement as meaning ``knowing compiler internals''
which is a somewhat different thing.
I see that we agree, however. Sorry for the confusion.
Nicolas Neuss
> Bulent Murtezaoglu <b...@acm.org> writes:
>
> > Is there anything by RMS that one can read on this? I do remember
> > "don't use tcl wait for us to complete guile" postings. Anything
> > else?
>
> There was a rather long thread about a Guild-based Emacs about one or
> two months ago, on emacs-devel. Of course some people mentioned Common
> Lisp as a non-braindead alternative, and IIRC RMS himself commented on
> this. I'm sure there are archives at gnu.org.
http://mail.gnu.org/pipermail/emacs-devel/2002-August/011003.html
It is amazing how this voice of reason is ignored. And I'm astonished
that RMS apears not to have a deep knowledge of Scheme which he is
advocating, see e.g.
http://mail.gnu.org/pipermail/emacs-devel/2002-August/011258.html
Based on this, my guess is that he became a manager and ignores
important technical details not fitting to his view of the world.
Nicolas.
Tim Bradshaw
> At the primitives level, I agree with you. Ditto for syntax
> (excepting macros.) But CLOS is a *hard* thing to *master*; the Java
> object model is comparatively trivial. And libraries, well,
> "standard" Java libraries are breeding like rats, so you can never
> master the "entire" language at that level.
The Java object model may be simple, but once you've mastered it you
have to spend a whole lot more time mastering a whole repertoire of
tricks and techniques to make it actually useful. And then you spend
the rest of your life repeatedly working around the limitations. CLOS
is a bit more complicated, of course, but once you've understood it
you can actually get on and do stuff.
--tim
