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
Tibor Simko
> The performance would play an important part here - as far as I
> remember Python's performance is not that good, right?
Right. In my experience, Python is typically 5x to 50x slower than
Common Lisp (CMUCL). Similar numbers are cited in
<http://www.norvig.com/python-lisp.html>.
However, with things such as Psyco <http://psyco.sourceforge.net/> one
can get very significant speed improvement (2x-20x, in my experience)
bringing the difference between Python and Common Lisp down to the
same order of magnitude, say 2x-5x. For example, for the Fibonacci
numbers program from the Great Computer Language Shootout
<http://www.bagley.org/~doug/shootout/bench/fibo/>, if I add to the
Python source:
import psyco
psyco.bind(fib)
I obtain, for fib(37)=39088169, practically the CMUCL time:
Python raw ....... 77.71 sec
Python + Psyco ... 1.63 sec
CMUCL ............ 1.42 sec
OCaml ............ 0.42 sec
Just to illustrate where one can get when the bottlenecks in the
Python source code are well "psycoable".
T.
Dave Bakhash
Pascal Costanza <cost...@web.de> wrote in message news:<amtdjg$so$1...@newsreader2.netcologne.de>...
I am no expert in Jython or the underlying Java. However, I think my
point is correct, though it could use some clarification.
Part of the misunderstanding has to do with not just using existing
Java libraries, but defining new ones. In order to do this, CL must
constrain its OO system significantly. Here are some of the reasons:
o CLOS supports multiple inheritance; Java does not
o CLOS provides a programmable method dispatch mechanism
(method combination) that is not present in Java. for SMC alone,
that
means :before/:after/:around methods that don't exist in the Java
OO
framework.
o CLOS methods belong to a generic function -- not a class, as in
Java.
This presents namespace issues as well as deeper semantic
problems.
These are issues that can be solves through macro-level constraints,
meaning that the programmer will have to depart from using
DEFMETHOD/DEFGENERIC/DEFCLASS (among others) to really work well with
Java, similar to corba:define-method in LispWorks.
If you're just using the pre-existing Java libraries, that may not be
quite so challenging. But actually programming in parallel to Java,
and providing additional libraries and behavior -- usable by pure Java
programmers -- would probably help you to see this mismatch.
dave
Pascal Costanza
> hey,
>
> Pascal Costanza <cost...@web.de> wrote in message news:<amtdjg$so$1...@newsreader2.netcologne.de>...
[...]
>>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. ;)
>
> I am no expert in Jython or the underlying Java. However, I think my
> point is correct, though it could use some clarification.
>
> Part of the misunderstanding has to do with not just using existing
> Java libraries, but defining new ones. In order to do this, CL must
> constrain its OO system significantly. Here are some of the reasons:
[...]
> If you're just using the pre-existing Java libraries, that may not be
> quite so challenging. But actually programming in parallel to Java,
> and providing additional libraries and behavior -- usable by pure Java
> programmers -- would probably help you to see this mismatch.
OK, now I understand your concern, thanks for clarification. At the
moment I am only thinking about how to make Java programs run inside of
a Common Lisp environment, or to be more specific, how to translate them
to CLOS classes and methods at runtime/loadtime. So this would
especially allow Common Lispers to use Java libraries, and modify them
for example with before/after/around advices etc.
I haven't yet thought about how Java programmers can make use of Common
Lisp libraries in such a scenario. And I don't think it's too important:
The design of my JVM will result in some conventions and some
macros/functions that allow you to provide classes explicitly for Java;
they would additionally need to be declared as Java classes with
"native" method declarations. (In this context, "native" of course means
"implemented in Common Lisp", not as native code of the platform. ;) So
accessing Common Lisp from Java wouldn't be automatic, but feasible. Do
you agree?
Dave Bakhash
just in case people are interested in this thread, they really should
check out JiL from Franz:
http://www.franz.com/support/documentation/6.2/doc/jil.htm
Since this is probably the most advanced CL system out there that
compiles to JVM bytecodes, tracing this project will determine how much
of CL will fit the Java OO model. I havn't been following it closely,
but I don't remember them supporting CLOS, and then mapping it into
Java. Does anyone who uses JiL care to comment?
dave
Jeff Sandys
> * Basile STARYNKEVITCH
> | Learning CommonLisp is a very significant task!
I disagree.
> More utter nonsense! It takes significantly /less/ time to master
> Common Lisp than to master C++ or Java or even Perl or Python.
C++, Java and Perl, I agree. Python, I disagree.
From my experience Python has a lower threshold (and lower ceiling)
than Common Lisp. We schedule 1-2 weeks (40-80 work hours) to get
a non-programmer over the threshold of Common Lisp, and we schedule
1-2 days (8-16 work hours) to get them over the threshold of Python.
By over the threshold, I mean capable of writing code on their own
with an understand of the syntax and common primitives.
Norvig is converting _A.I.: A Modern Approch_ to Python because it
is easier to read. (Although I am disappointed that Norvig chose
to abandon Lisp, atleast he didn't use Java or C++)
> Programming under Windows requires about two orders of magnitude
> more stuff to learn than the language.
Python makes Windows programming almost fun.
I don't want to start a language war, Common Lisp is worth the effort
to learn. Python is a good language for scripts (throw away programs)
and for introducing people to programming. I have been using Logo
(Lisp without parenthesis) in a 7-8th grade programming club, this
year I am going to try Python.
Thanks,
Jeff Sandys
Thomas F. Burdick
> 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:
[snip]
> Well the quick hack page date back to 07/2000 !!! How intensively are
> they working?
(sssssh!) What, are you complaining? It looks like Guile-Emacs will
never happen. I mean, if we're lucky. *I* would rather stick with
elisp than deal with Guile. And if the FSF eventually does dump
elisp, XEmacs would probably do the same, and that would leave me with
the following options: (1) Go into an Emacs time-warp, and stick with
the last stable elisp-based emacs; (2) fork and become an Elisp-Emacs
maintainer; or (3) fork, do major development, and become a CL-Emacs
developer/maintainer.
(1) Sounds fine, except it would necessarily turn into (2), unless I
go into a complete computing time-warp. I had planned on sticking
with Emacs-20.7 for as long as I could, but then I got Mac OS X, and
couldn't easily get 20.7 to compile on it. So, now I'm running 21.
It was that or essentially maintain my own fork. And personally, I
don't want to maintain Emacs.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Michael Sullivan
> 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. 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)
Is it really "not a list" though? Only in the sense that 'list' in CS
has come to be a term of art for "linked list". If data types share the
same methods, then it's reasonable to want a term that refers to this
equivalence class. I.e. a linked list and a vector have the exact same
functions available to a client programmer, the only difference is the
performance characteristics of both. If 'list' had not come to mean
'linked list', then I would tend to say that 'linked list' and 'vector'
are different implementations of the abstract idea of 'list' (which
would represent any data type with these methods), and this is what
someone coming to CS with no preconceptions, but an understanding of the
outside world concept of 'list' is likely to think.
In the domain of applications Python is designed for, a vector list is
probably a more appropriate choice than a linked list, well over half
the time. So making it the default, and easiest to use version of the
abstract 'list' seems a reasonable choice.
What's unfortunate to me is that 'list' has been coopted as a term of
art to mean something much more specific within the CS community. If
that were not so, there would be no confusion (IMO) in Python (or
Applescript, which makes the same choice) calling a vector a 'list'.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT mic...@bcect.com
Tim Bradshaw
> What's unfortunate to me is that 'list' has been coopted as a term of
> art to mean something much more specific within the CS community. If
> that were not so, there would be no confusion (IMO) in Python (or
> Applescript, which makes the same choice) calling a vector a 'list'.
Well, communities develop jargon and technical language, and it's
usually good to stick to that jargon and language. I don't know if
it's prevalent outside CL, but CL uses the term `sequence' for things
that are either (proper) lists or vectors. It's a good term, I think.
--tim
Fred Gilham
> What's unfortunate to me is that 'list' has been coopted as a term
> of art to mean something much more specific within the CS community.
> If that were not so, there would be no confusion (IMO) in Python (or
> Applescript, which makes the same choice) calling a vector a 'list'.
Well, 'list' has meant 'linked list' in computer science for as long
as I've known anything about it.
Imagine if you started talking to electronics people about `chokes'.
You said, "Here's a 1k choke, and here's a 1meg choke."
They look at you funny. "Those are resistors. Chokes are inductors."
You reply, "They are resistive chokes. The ones you are thinking of
are inductive chokes. Both oppose or 'choke' the flow of current.
Also, resistors are the more appropriate choice in far more than half
the applications of chokes, so making 'resistive choke' the default
meaning of 'choke' seems like a reasonable choice."
After that there's silence, except for a choking sound.
--
-Fred Gilham gil...@csl.sri.com
"In America, we have a two-party system. There is the stupid
party. And there is the evil party. I am proud to be a member of the
stupid party. Periodically, the two parties get together and do
something that is both stupid and evil. This is called --
bipartisanship." --Republican congressional staffer
Matthew Danish
> Matthew Danish wrote:
> > 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?)
Largely the conflation of a module-system and the object-system (such as
the idea that methods `belong' to classes) which leads to difficulties
with multi-method dispatch. If one is coming from the Java viewpoint
then one might view multiple-inheritance as dangerous. I suppose it can
also safely be said that method-combination and redefinition of
classes/methods is not something one encounters in the Java/C++ world.
The design of Java (and C++ to a great extent, as I see it) leads one to
design programs around classes (which are really modules), which makes
classes rather heavyweight. Whereas in Common Lisp, classes are just
data-structures and the `real work' is performed by methods and
functions which are bound to symbols grouped into packages, and
optionally encapsulated in a module system.
I see classes such as Math in Java as being prime examples of their
usage as modules. All the methods are `static' so the only purpose of
the class is to act as a module.
Maybe sometime I'll put together a less subjective explanation and then
I'll have a link for you.
Pascal Costanza
> On Thu, Sep 26, 2002 at 10:59:26AM +0200, Pascal Costanza wrote:
>
>>Matthew Danish wrote:
>>
>>>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?)
>
> Largely the conflation of a module-system and the object-system (such as
> the idea that methods `belong' to classes) which leads to difficulties
> with multi-method dispatch. If one is coming from the Java viewpoint
> then one might view multiple-inheritance as dangerous. I suppose it can
> also safely be said that method-combination and redefinition of
> classes/methods is not something one encounters in the Java/C++ world.
Ah, and I thought it was something serious. ;-))
Thanks for that. The term "misconceptions" made me think that something
about the Java/C++ is "wrong" in the sense that you cannot translate it
to CLOS - but their object models are in fact a special (and restricted)
case of CLOS, so you haven't necessarily learnt something _disastrously_
wrong when you are used to Java/C++. CLOS "just" expands your
possibilities in many directions which can be hard to grasp at first...
Pascal
Christopher Browne
> Friedrich Dominicus <fr...@q-software-solutions.com> writes:
>
>> 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:
>
> [snip]
>
>> Well the quick hack page date back to 07/2000 !!! How intensively are
>> they working?
>
> (sssssh!) What, are you complaining? It looks like Guile-Emacs will
> never happen. I mean, if we're lucky. *I* would rather stick with
> elisp than deal with Guile. And if the FSF eventually does dump
> elisp, XEmacs would probably do the same, and that would leave me with
> the following options: (1) Go into an Emacs time-warp, and stick with
> the last stable elisp-based emacs; (2) fork and become an Elisp-Emacs
> maintainer; or (3) fork, do major development, and become a CL-Emacs
> developer/maintainer.
>
> (1) Sounds fine, except it would necessarily turn into (2), unless I
> go into a complete computing time-warp. I had planned on sticking
> with Emacs-20.7 for as long as I could, but then I got Mac OS X, and
> couldn't easily get 20.7 to compile on it. So, now I'm running 21.
> It was that or essentially maintain my own fork. And personally, I
> don't want to maintain Emacs.
I don't think it's terribly likely that XEmacs would dump elisp, as it
would require retargeting millions of lines of existing elisp code.
The only way it would make /any/ sense to do is if there were
excellent tools in place to automate this, that is, to transform
colloquial elisp code into pretty nearly colloquial Guile code.
If the tools proved good enough to allow something like this to
happen, then they'll surely be good enough that you could
transparently keep writing elisp, perhaps keeping a "timewarp" copy
around to debug in, and redeploy into Guile as needed.
That all being said, Guile doesn't seem to be particularly better than
elisp (and I'm /not/ saying that snidely; in the context here, I'm
trying to give Guile the /most/ benefit of the doubt).
-> It is not /manifestly/ faster;
-> It doesn't bytecode compile for compactness/faster parsing.
The one thing it /does/ have that elisp /doesn't/ that can be regarded
as Rather Valuable is threading, notably via:
(call-with-new-thread THUNK ERROR-THUNK).
It is not at all obvious that porting stuff that Really Needs Threads
would necessarily automate terribly well. I suspect that if Gnus, the
most conspicuous example of something that would benefit vastly, got
ported over, threading wouldn't go in 'for free,' but would rather
require quite a lot of rewriting of Guile code. In the absence of
native code/byte compilers, there's no /vast/ performance win.
My sneaking suspicion is that the "redo in Guile" idea will die
quietly. If it doesn't, it will more than likely lead to a greater
schism than the XEmacs/GNU Emacs schism...
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/rdbms.html
People can be set wondering by loading obscure personal patchable
systems, and sending bug reports. Who would not stop and wonder upon
seeing "Experimental TD80-TAPE 1.17, MegaDeath 2.5..."? The same for
provocatively-named functions and variables in stack traces.
-- from the Symbolics Guidelines for Sending Mail
Matthew Danish
> Thanks for that. The term "misconceptions" made me think that something
> about the Java/C++ is "wrong" in the sense that you cannot translate it
> to CLOS - but their object models are in fact a special (and restricted)
> case of CLOS, so you haven't necessarily learnt something _disastrously_
> wrong when you are used to Java/C++. CLOS "just" expands your
> possibilities in many directions which can be hard to grasp at first...
The misconception was on my part, due to the Java/C++ box I had been
thinking inside. My wording was poor, I probably should have written
something along the lines of: ``The conflation of modules and classes is
of dubious merit and results in, what I find to be, misconceptions about
object-systems.''
Michael Sullivan
> > What's unfortunate to me is that 'list' has been coopted as a term
> > of art to mean something much more specific within the CS community.
> > If that were not so, there would be no confusion (IMO) in Python (or
> > Applescript, which makes the same choice) calling a vector a 'list'.
>
> Well, 'list' has meant 'linked list' in computer science for as long
> as I've known anything about it.
> Imagine if you started talking to electronics people about `chokes'.
> You said, "Here's a 1k choke, and here's a 1meg choke."
The difference here is that people who know nothing of CS, and who would
look at you funny when you say "linked list" can nonetheless get a
pretty good idea of the abstract "sequence" type when you say "list".
These days, a lot of such people are called on to do things remarkably
like programming on little training, and the languages they are using
are things like Python and Applescript, precisely because they are
geared to be understandable fairly rapidly by those who've had little or
no training in CS. That's not necessarily a bad thing, just a question
of playing to one's audience. An interesting question is whether the
tradeoffs made that make the language completely unpalatable to those
who know what they are doing.
I'll admit that calling them sequences is a pretty reasonable idea
(since that still suggests the abstract type to laypeople), and I, if I
were designing those languages and thought of it, probably would have
done so.
Michael, and I'm obviously dragging this way OT for c.l.l so I will shut
up now.
Jeremy H. Brown
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_?
I can't answer these questions as well as I'd like. I haven't read
Keene's book, and I can't claim to have mastered CLOS; I've always
gotten frustrated with its complexity while reading the spec and wound
up ignoring most of it. So I think that'd be my major complaint in a
nutshell: it's extremely complex. The high-level concepts are
tolerably straightforward, but the details are heinous. (I mean, my
God, it's almost impossible to figure out exactly how multiple
inheritance actually works out; who can truly claim to have mastered
that? Not many here, I'll wager.)
Method combination is another point of confusing complexity. before,
after, around, etc... it's easy to make it nearly impossible for
someone coming to the code as a reader, rather than an original
author, to figure out where a program's control flow really goes.
Finally, let me acknowlege here what others will no doubt jump all
over me to point out: the increased complexity of CLOS gives you
increased power. I don't quibble with that. Where those hypothetical
others and I disagree is almost entirely religious in nature: where
lies the point of diminishing returns? Where does added power get
overwhelmed by added confusion? It is merely my opinion that CLOS'
complexity overwhelms the advantages it enables. I'm certain that for
some people that's not the case, and so we come to questions of how
many people, what type of people, etc., should have how much
difficulty with mastering CLOS (or any language feature), and that way
lies madness.
But anyhow, that's roughly why I think CLOS is hard to master.
Jeremy
Kenny Tilton
Jeremy H. Brown wrote:
> I've always
> gotten frustrated with its complexity while reading the spec and wound
> up ignoring most of it.
Not a bad way to get to know a complex system, actually. Start with a
subset one is comfortable with. Later on look back at the CLOS doc and
realize where what once seemed like obscure features could have made
one's code simpler.
> it's almost impossible to figure out exactly how multiple
> inheritance actually works out;
(inspect (find-class 'xxx)) and look for the class precedence list. That
will show you exactly how inheritance got worked out. if you mean, how
can you tell in advance, my experience has been that I am the one that
has gotten too confused (I do not consider "complex" a pejorative) if my
program semantics depend on how M/I precedence pans out.
>
> Method combination is another point of confusing complexity. before,
> after, around, etc... it's easy to make it nearly impossible for
> someone coming to the code as a reader, rather than an original
> author, to figure out where a program's control flow really goes.
yeah. thank god for trace!
>
> Finally, let me acknowlege here what others will no doubt jump all
> over me to point out: the increased complexity of CLOS gives you
> increased power. I don't quibble with that.
OK.
> Where does added power get
> overwhelmed by added confusion? It is merely my opinion that CLOS'
> complexity overwhelms the advantages it enables. I'm certain that for
> some people that's not the case...
Not to quibble, but I think it important then to say that /you/ have
gotten confused by the power of CLOS, not to state as an absolute that
its power is confusing.
The issue here is how one approaches a powerful mechanism, and as I said
above, the answer for some of us is "one step at a time".
> But anyhow, that's roughly why I think CLOS is hard to master.
I have crashed badly three times since moving from 4 wheels to 5 on my
in-line skates. One concussion, lotsa skin loss. I do not blame the
fifth wheel, I blame my lack of respect for the greater speeds/torque
involved. I finally figured out I need to give my motor skills time to
catch up with the more powerful technology. I am practicing speedskating
technique on 4 wheels, and holding back a little when on 5.
btw, those new J&J artifcial-skin bandages are the bomb. :)
kenny
clinisys
Bulent Murtezaoglu
Thanks for posting these links.
[...]
NN> http://mail.gnu.org/pipermail/emacs-devel/2002-August/011258.html
NN> Based on this, my guess is that he became a manager and
NN> ignores important technical details not fitting to his view of
NN> the world.
And the below seems to be his position re CL:
http://mail.gnu.org/pipermail/emacs-devel/2002-August/011184.html
cheers,
BM
Thaddeus L Olczyk
wrote:
>
>Finally, let me acknowlege here what others will no doubt jump all
>over me to point out: the increased complexity of CLOS gives you
>increased power.
The ratio of increased complexity to increased power is enormously
high. This is because CLOS is badly done.
To see CLOS done the way it should be check out:
http://www.ai.mit.edu/~jrb/goo/goo.htm
Joe Marshall
"Thaddeus L Olczyk" <olc...@interaccess.com> wrote in message
news:tqo9puophfrqfdfv1...@4ax.com...
> On 27 Sep 2002 16:28:42 -0400, jhb...@ai.mit.edu (Jeremy H. Brown)
> wrote:
>
> This is because CLOS is badly done.
I'm just so tickled that this group attracts such a high
caliber of people. How did we ever survive before?
Pascal Costanza
> I can't answer these questions as well as I'd like. I haven't read
> Keene's book, and I can't claim to have mastered CLOS; I've always
> gotten frustrated with its complexity while reading the spec and wound
> up ignoring most of it. So I think that'd be my major complaint in a
> nutshell: it's extremely complex. The high-level concepts are
> tolerably straightforward, but the details are heinous.
Well, these concepts may be complex but they are obviously needed.
Look at other languages in use: C++ has templates that are used for
generating complex classes; Java has got the AspectJ addition; there's
already an AspectC# underway; in the AOSD mailing list, people have
already asked for an AOP extension for Python.
In the long run, those "simple" languages always turn out to be too
simple and more features are being added one by one. So you have to
learn these (or similar) concepts anyway in the "real world".
Pascal
Paolo Amoroso
wrote:
> Is it? Since I haven't seen a specification for, say, emacslisp,
> I can't compare. :)
The Emacs Lisp manual is not much shorter than CLtL2.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
ilias
Lisp is bleeding.
ilias
> Bulent Murtezaoglu <b...@acm.org> writes:
> 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_?
>
>
> I can't answer these questions as well as I'd like. I haven't read
> Keene's book, and I can't claim to have mastered CLOS; I've always
> gotten frustrated with its complexity while reading the spec and wound
i'm a lisp-novice.
reading a few parts (reader, macros, backquote ) of CLHS makes it clear
form me:
if the fundamentals parts are defined that fuzzy, how fuzzy most became
a complex systems designed on that?
I'll look at CLOS.
but i know already: i'll be not able to assimilate it, *not* due to its
complexity but duo to its *unneccessary* complexity of
implementation-dependent details in behaviour which will lead to an
intuitive rejection of the information.
Erik Naggum
| I haven't read Keene's book,
You really, really should. Several people, myself included, have found that
the apparent complexity of CLOS was a result of being bombarded with the
whole complexity up front, but with that thin book, the pedagogical steps
that were missing were presented in an orderly fashion. After you have read
Keene and have spent a little time experimenting with the concepts, like a
month of spare-time-hacking, go read the full specification. It wil make
sense like a revelation.
| I've always gotten frustrated with its complexity while reading the spec and
| wound up ignoring most of it.
Many people do that with accounting laws and principles, too.
| So I think that'd be my major complaint in a nutshell: it's extremely
| complex.
No, it is not. It is just complex, and you have decided not to deal with it.
| (I mean, my God, it's almost impossible to figure out exactly how multiple
| inheritance actually works out; who can truly claim to have mastered that?
| Not many here, I'll wager.)
Bullshit. The class precedence list is easy to compute and inspect.
| Method combination is another point of confusing complexity.
Bullshit. It is amazingly straight-forward and almost completely free of
surprises for something that powerful.
| before, after, around, etc...
Extremely elegant.
| it's easy to make it nearly impossible for someone coming to the code as a
| reader, rather than an original author, to figure out where a program's
| control flow really goes.
That is a factor of the intelligence, concentration, dedication, and general
skills of the programmer and has nothing to do with CLOS.
| Where those hypothetical others and I disagree is almost entirely religious
| in nature: where lies the point of diminishing returns?
Yeah, let's drag in "religious" while you are /not/ arguing. No wonder you
refuse to apply yourself to understand it. I mean, my God, it's /religious/!
| Where does added power get overwhelmed by added confusion?
Confusion is the result of less understanding than is required to deal with
the tasks at hand. If you have seriously tried to understand this and have
failed, maybe you should just leave it to others? You have, obviously, never
seriously tried, or you would never, /ever/ have brought up "religious", so
this is only an instance of /fear/ that you might not understand it, /fear/
of watching the time spent go unrewarded, /fear/ that you are not smart
enough to grasp it. Snap the hell out of it and start working on it!
| It is merely my opinion that CLOS' complexity overwhelms the advantages it
| enables.
Life in general is overshelmingly complex to people who refuse to do their
homework. I mean, my God, have you looked at those tax laws recently?
Better ignore them and claim that the IRS folks are "religious" and that the
whole system is so confusing you should be relieved of having to deal with it.
| I'm certain that for some people that's not the case, and so we come to
| questions of how many people, what type of people, etc., should have how much
| difficulty with mastering CLOS (or any language feature), and that way lies
| madness.
Have you looked at superstring theory in physics? That's complex. That's so
complex I cannot seem to remember how things interrelate between each time I
sit down to study it. But to people who work with this stuff all the time
seem to have no problems dealing with the complexity. Should I attack their
theory for being too complex for me to understand because I would sort of
like to, as a hobbyist science-philosopher kind of guy?
| But anyhow, that's roughly why I think CLOS is hard to master.
These thoughts hold you back. Please be so decent as to avoid letting them
hold other people back, as well. Lazy people tend to look for excuses not to
work, and if some other lazy person can tell them "I tried, I failed, but
look at all the trouble /that/ got me into! *snicker*", they will be very
happy because now they can rationalize their laziness. I mean, my God, it's
/religious/!
--
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.
Kaz Kylheku
> Bulent Murtezaoglu <b...@acm.org> writes:
> 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_?
>
> I can't answer these questions as well as I'd like. I haven't read
> Keene's book, and I can't claim to have mastered CLOS; I've always
> gotten frustrated with its complexity while reading the spec and wound
> up ignoring most of it.
Maybe your problem is that you are relying too much on just the spec.
I think that CLOS is the easiest object system in existence. It does
the Right Thing that I expect in a given situation. But then again,
I'm not really familiar with its formal specficiation. It has lots of
features and subtleties that I don't use or know about, but which I
will discover over time.
So I think that'd be my major complaint in a
> nutshell: it's extremely complex. The high-level concepts are
> tolerably straightforward, but the details are heinous. (I mean, my
> God, it's almost impossible to figure out exactly how multiple
> inheritance actually works out; who can truly claim to have mastered
> that? Not many here, I'll wager.)
There are no real difficulties under multiple inheritance. In case of
an ambiguity, there is a simple left to right precedence system. If
you inherit from A and from B, in that order, then you are ever so
slightly more an A, in a context where you could be treated as A or B.
If you have to parameters that are each both of this type, and you
have an (A B) method and a (B A) method, then the choice is again made
left to right over the parameters. You are more of an A, which matches
the left parameter, so the (A B) method takes priority.
> Method combination is another point of confusing complexity. before,
> after, around, etc... it's easy to make it nearly impossible for
I don't see what is so difficult about auxiliary methods. What they do
is pretty obvious. The befores are called in order from general to
specific, then the normal method, then the afters in reverse order of
the befores. It all works in the most obvious way in which it could
work in the most reasonable of all possible worlds. I discovered the
basics by experimenting with them interactively. Though I don't use
CLOS much, I'm entirely confident that I can get it to do exactly what
I want without any difficulties.
> someone coming to the code as a reader, rather than an original
> author, to figure out where a program's control flow really goes.
A confusing program could be deliberately written in any object
system. When you read specifications, you get into a frame of mind
which is conducive to extrapolations into degenerate cases.
I think that the goal in programming with generic functions is to
create an intuitive interface, so that one doesn't have to be
concerned with where the flow of control goes. It goes to the right
``service provider'' which is best fit for the job. Of course you
could design a program which depends on method dispatch as a
control-flow mechanism, where the parameter types are just dummies to
divert the flow. In this program, the methods would do completely
different jobs that must be done in the right order. But who would
design that way?
> Finally, let me acknowlege here what others will no doubt jump all
> over me to point out: the increased complexity of CLOS gives you
> increased power. I don't quibble with that. Where those hypothetical
> others and I disagree is almost entirely religious in nature: where
> lies the point of diminishing returns?
That point rests in individual programs. In solving a given task, you
reach a point of dimishing returns when no additional complexity or
abstraction will buy you anything, whether it comes from features of
the standard language, or from your own devices.
> Where does added power get
> overwhelmed by added confusion?
You can't be confused by what you don't use. If you don't use multiple
inheritance in your program, then the complexity associated with
multiple inheritance does not arise in that program.
It is merely my opinion that CLOS'
> complexity overwhelms the advantages it enables. I'm certain that for
> some people that's not the case, and so we come to questions of how
> many people, what type of people, etc., should have how much
> difficulty with mastering CLOS (or any language feature), and that way
> lies madness.
>
> But anyhow, that's roughly why I think CLOS is hard to master.
Is it necessary to master CLOS? Perhaps as a long term goal for a Lisp
programmer who is serious about becoming a practitioner of object
oriented programming.
Erik Naggum
| I'm just so tickled that this group attracts such a high caliber of people.
| How did we ever survive before?
It is not this group. It is Usenet in general. Usenet in real life would
be like this: Visit a public library with at least a million books. (But
For best results, visit a university library.) Pick books at random. Pick
pages at random. How many pages would you understand? Do you complain
vociferiously about this? Do you blame the library for holding books that
you do not understand? Do you see lots of people flock to the library only
to express their inability to understand random pages from random books? Do
they come back every day to sit down in "support groups" where one can say
"I don't get this!" and get sympathy from another who says "I don't get it,
either!", but then someone says "oh, that's nothing, look at what /I/ don't
get!", and then they can all look at some pages from some books and laugh
and ridicule the authors and the "confusing complexity" of what they cannot
understand? No? Why not?
Suppose we regard Usenet as an instance of democrazyš. People should have
the right to voice their opinions, the more the less they know. If someone
does not understanding something, everybody can vote on it and forbid it.
People who argue that it is possible to learn just about anything, because,
they would argue, look at these people who have spent a decade or three on
this topic -- they surely understand it, would simply be voted down by the
vast majority who do not understand it. Therefore, we can have public votes
on whether carbon dioxide causes floods in Central Europe, tornados in North
America, and greening of Sahara, and we can assume that all the people on
this planet, the total mass of which is far exceeded by /ants/, the emissions
of whose technology is far exceeded by the /intestinal gases/ of all mammals,
the light and heavy metallic pollution of which has been far exceeded by the
heavy bombardment of interstellar matter on our planet, the carbon dioxide
and temperature levels of whose most active time on earsh has been usually
stable compared to the wild fluctuations of times past, which evidently did
not kill off anything but instead let things evolve, include us humans.
The only people who could possibly be wrong about something are the experts.
Yeah, this does indeed go to the "literacy" argument. *Sigh*
-------
š Intentional spelling variation.
Robert Braddock
> Keene's book, and I can't claim to have mastered CLOS; I've always
> gotten frustrated with its complexity while reading the spec and wound
> up ignoring most of it. So I think that'd be my major complaint in a
> nutshell: it's extremely complex. The high-level concepts are
Wait a moment here. Your problem is that the spec is not a tutorial,
not CLOS itself. I know that many bodies seem to make their specs read
like and/or include tutorials nowadays, but you have to realize when
you are using a normative details only spec you just aren't going to
get the kind of hand holding you might want.
I mean, Python has a tutorial and a friendly reference describing a
trivially straightforward system. You read through that, and you're
good to go. Doing the same read-and-go with CLOS requires a proper
introduction, not reading the guide for experienced programmers
IMPLEMENTING lisp compilers, and you can't expect everything.
I think the core misconception here, is that Python's objects are so
dead simple that saying one has "mastered" them is kind of
meaningless. People then come to something like lisp, and expect the
same trivial effort to mastery, and when they don't get it, they fault
CLOS for being hard and confusing.
I'm relatively new to lisp, but this same thing truly killed SGML.
Every new person needs someone next to him/her to periodically yell,
"Dammit, don't use the parts you don't want!"
> But anyhow, that's roughly why I think CLOS is hard to master.
Hard to master is different from hard to use. Frankly, what's the
point of something easy to master? That's really the ultimate in
diminishing returns. CLOS, at least, actually _has_ returns from the
process of mastery. I would go so far as to say it has _increasing_
returns, not diminishing, but one simply must understand and accept
that no one is making you master it.
--
Robert Braddock
Erik Naggum
| I'm relatively new to lisp, but this same thing truly killed SGML. Every new
| person needs someone next to him/her to periodically yell, "Dammit, don't use
| the parts you don't want!"
Hmmm. Part of the problem with SGML was the were about 12 different features
that affected the syntax of the document instance, leading to 4096 different
syntaxes that were all supposed to be SGML. The problem was that you could
neither turn a feature or not turn it on without the possibility of affecting
the way the document would be parsed and processed. This meant that you had
to make a decision as to which of the features you wanted and make that
decision system-wide, leading to a serious lack of interoperability, which
was never the intended purpose of SGML to begin with. E.g., the character
set stuff was supposed to printed out on paper and shipped with the physical
tape to the printer or typesetter. Truly amazing parts of SGML was geared
towards non-electronic document interchange and were horribly dated by the
time the Internet hit the fan.
--
Erik Naggum, Oslo, Norway Today, the sum total of the money I
would retain from the offers in the
more than 7500 Nigerian 419 scam letters received in the past 33 months would
have exceeded USD 100,000,000,000. You can stop sending me more offers, now.
Tim Josling
> ... the carbon dioxide
> and temperature levels of whose most active time on earsh has been usually
> stable compared to the wild fluctuations of times past, which evidently did
> not kill off anything but instead let things evolve, include us humans.
>
Actually Scientific American had an article a while back about an episode of
runaway greenhouse that occured a long time ago on earth. It wiped out almost
all life except a few simple forms.
It was preceded by a runaway cooling caused by an unusual configuration of the
continents. The surface temperature went to -50C and the entire surface was
covered by ice.
Gradually the volcanoes kept putting CO2 into the air. With no rain to take
the CO2 out, the CO2 level increased. The ice started to melt but the CO2
level had built up to high levels. The average surface temperature went to
50C. Eventually the CO2 went to normal levels as it was washed out of the air.
Tim Josling
Aleksandr Skobelev
[...]
> The befores are called in order from general to specific, then the
^^^^^^^^^^^^^^^^^^^^^^^^
> normal method, then the afters in reverse order of the befores.
[...]
You probably meant to say `from specific to general'? :)
Tim Bradshaw
> I can't answer these questions as well as I'd like. I haven't read
> Keene's book, and I can't claim to have mastered CLOS; I've always
> gotten frustrated with its complexity while reading the spec and wound
> up ignoring most of it. So I think that'd be my major complaint in a
> nutshell: it's extremely complex. The high-level concepts are
> tolerably straightforward, but the details are heinous. (I mean, my
> God, it's almost impossible to figure out exactly how multiple
> inheritance actually works out; who can truly claim to have mastered
> that? Not many here, I'll wager.)
> Method combination is another point of confusing complexity. before,
> after, around, etc... it's easy to make it nearly impossible for
> someone coming to the code as a reader, rather than an original
> author, to figure out where a program's control flow really goes.
I think you've been taught, or taught yourself, very badly. If you
find multiple inheritance complicated don't use it. If you find
method combination hard, don't use it. Nothing at all forces you to
use all of CLOS, and there are very few cases where you have to pay
any price for not using parts of it (the only one I can think of
off-hand is slot-naming issues if you don't want to have to worry
about effective slot definitions).
I mean, how hard can it be to just restrict yourself to classes with a
single superclass, and to DEFMETHOD with no qualifiers? You can still
use CALL-NEXT-METHOD to do the kind of stream dispatch-to-superclass
thing that Java &co have?
When you start needing things like method combinations - either one of
the standard ones or user-defined ones - they are waiting for you to
use, but they aren't causing you any extra work until you need them.
I haven't taught a course on Lisp for a few years now, but when I did
so regularly we used to spend about a day (of a week-long course) on
CLOS, and students would be absolutely fine with it. Typically 15-20
minutes at the end of the day would be me pointing them at all the
advanced stuff.
--tim
Paolo Amoroso
> Norvig is converting _A.I.: A Modern Approch_ to Python because it
> is easier to read. (Although I am disappointed that Norvig chose
I seem to remember a different rationale, i.e. the wider availabilty of
Python libraries, especially for GUI.
Rainer Joswig
Paolo Amoroso <amo...@mclink.it> wrote:
> On Thu, 26 Sep 2002 16:38:35 GMT, Jeff Sandys <san...@juno.com> wrote:
>
> > Norvig is converting _A.I.: A Modern Approch_ to Python because it
> > is easier to read. (Although I am disappointed that Norvig chose
>
> I seem to remember a different rationale, i.e. the wider availabilty of
> Python libraries, especially for GUI.
AIMA was never using Lisp. The book uses some pseudo code.
Examples were/are available in several languages, separately.
1. edition - http://www.cs.berkeley.edu/~russell/aima.html
2. edition will be here : http://aima.cs.berkeley.edu/
Jeremy H. Brown
> * Jeremy H Brown wrote:
> > I can't answer these questions as well as I'd like. I haven't read
> > Keene's book, and I can't claim to have mastered CLOS; I've always
> find multiple inheritance complicated don't use it. If you find
> method combination hard, don't use it. Nothing at all forces you to
> use all of CLOS, and there are very few cases where you have to pay
> any price for not using parts of it (the only one I can think of
> off-hand is slot-naming issues if you don't want to have to worry
> about effective slot definitions).
Your points regarding using subsets of CLOS are entirely correct, but
they miss the fact that I was responding to the question "Why is it
harder to master CLOS than <foo>?" I don't think I could claim to
have mastered the technology by using only a subset of its abilities.
Jeremy
PS Is Erik Naggum always so full of poisonous bile? I didn't expect
everyone to agree with me, and indeed, many people didn't, but he was
just out of control. All I was trying to do was provide a coherent
answer to a question I was asked.
Erik Naggum
| PS Is Erik Naggum always so full of poisonous bile?
What, precisely, have I done to you to warrant this direct personal attack?
What, precisely, do you have against poisonous bile when you are so ready and
willing to dispense it yourself? One moral code for you and another for me?
Is Jeremy H. Brown always such a retarded, whining, /unjust/ loser?
What was it that caused you to become evil? Did I fail to please you? Did I
fail to make you feel good? Did I not suck your dick the way you wanted?
What? Do you think this is the place you should go with your "I need to feel
good today" requests? Hire a prostitute if you want to people to please you.
Should I be /nicer/ to some dickweed like yourself for asking such a moronic
"question"? Do you think the retards who obsess about my person on this
newsgroup make me want to come and chop off their fingers or do you think
they make me want to help them understand something you wonder about that I
know and can explain so you understand it, too?
Just how goddamn stupid are you, Jeremy H. Brown? You are clearly unable to
focus on the things that have real value to you and are ready and willing to
squander long-term benefits by behaving like a disgusting little creep whose
feelings are hurt because you do not /think/. Do you think I will help you
again? I do not generally hold grudges against people and respond to what
they say, not to who they are, but you have made a lasting impression on me
with your retarded question.
| I didn't expect everyone to agree with me, and indeed, many people didn't,
| but he was just out of control.
Really? Your emotions are in check and you respond rationally? /Please/
look closer to home for the lack of control. You may find that you have no
control over your emotions and have to blame others for how you feel, which
causes your emotions to run freely out of control -- when it is no longer you
who are responsible for how you feel, you have no reason to control them.
This is your core mistake, and a mistake that intelligent people simply do
not make. You have branded yourself as emotionally unfit. Congratulations.
If you were less emotional and more rational, you would be able to read
something other people write and get something useful out of it even if you
had /personal/ issues with it. But I have not attacked you in any way and I
have not disrespected you. Quite the contrary, in fact: I have held you to a
standard to which you only /think/ you are unable to conform, and I did that
because I believed you could. That is, until your present idiotic response.
If you wish to tell me that I should lower my expectations of you and make
you feel less bad by not expecting anything of you, you could always have
found some non-emotional way to do that and just tell me that you would never
be able to satisfy the simple requirement that you think and act rationally
and focus on what you wish to learn. Robert Hanlin did that very well. I do
not expect him to become a rational being ever, and would rely on others to
tell me he had transformed himself. Just like Erann Gat and "ilias", who are
also beyond reach and pester people because of their own shortcomings.
If, again, you were more in control of yourself, you would not have any
problems seeing that you could have made a much better choice: a rational
course of action that helps you reach /your/ goals. If you wish to feel good
without reason, Usenet is not a good place. If you wish to think about and
/solve/ your problems, it may be a good place. And those who help each other
and respect each other enough to avoid the moronic hostility you have just
committed, become personal friends, too, but then they have the decency not
to air their personal feelings in public, which cretin like you should learn.
As long as you focus on what you think about other people, you will never be
able to improve your own condition, either. Think about how you feel, and do
something about it, which means that you do not attack others, you deal with
these things on a personal level. You may yet find that if you should choose
to think and behave better, people who demand that you think before you spout
nonsense and stupid questions will treat you better. It is really up to you,
but I repeat my question above:
Is Jeremy H. Brown always such a retarded, whining, /unjust/ loser? Does he
always flaunt his emotions in public? Will we see yet another retard make an
utter fool out of himself and destroy his reputation completely before he
wimpers out and accuses people of wanting to hurt him, when in fact you were
the first to attack anyone. Just because you feel hurt does not mean that
anyone attacked you. You may yet learn something as simple as that if you
have a working brain at all and it is not overpowered by testosterone and
other anti-intelligence hormones so useful to retards who need revenge.
And, no, I am only full of poisonous bile towards those who deserve it, and
they always go out of their way to prove it. To people who have the thinking
skills and intelligence of drug-addicted criminals, that is indeed "always"
because they need to protect themselves from the realization that other
people are indeed better people than they are.
Kenny Tilton
Jeremy H. Brown wrote:
> Tim Bradshaw <t...@cley.com> writes:
>
>>* Jeremy H Brown wrote:
>>
>>>I can't answer these questions as well as I'd like. I haven't read
>>>Keene's book, and I can't claim to have mastered CLOS; I've always
>>
>>I think you've been taught, or taught yourself, very badly. If you
>>find multiple inheritance complicated don't use it.
...
>
> Your points regarding using subsets of CLOS are entirely correct, but
> they miss the fact that I was responding to the question "Why is it
> harder to master CLOS than <foo>?" I don't think I could claim to
> have mastered the technology by using only a subset of its abilities.
Neither should you respond to a subset of what TB wrote. He also
mentioned that newbies should know where to go for more info when they
get to the point where they need advanced features.
You might also have responded to a larger subset of the commentary you
received, but I am starting to think you are a troll, perhaps
accidentally for lack of intelligence. Sorry, but the CLOS features you
described as complex seem pretty straightforward to most of us.
And jumping from your own inability to grok CLOS to an absolute
condemnation of it as confusing is either intellectually dishonest or
just plain dumb. Equally uncute was your attempted pre-emptive strike
against such protests by whining "this is just my opinion".
>
> Jeremy
>
> PS Is Erik Naggum always so full of poisonous bile?
No, it depends on the article, and given your sloppy piece I think he
showed admirable restraint. You gave up on studying X not having read
the best introduction to X, then pronounced X too confusing thinking
somehow that that being an opinion made it OK to call X confusing
without having made a decent effort to understand X. When a lot of folk
let your lack of diligence slide you responded selectively to make
yourself look better, then took a cheap shot at the one person who did
not let you slide. Now I wager you are about to find out how many people
were thinking what EN wrote.
Better luck next thread.
kenny
clinisys
ilias
[...]
>
> Jeremy
>
> PS Is Erik Naggum always so full of poisonous bile? I didn't expect
> everyone to agree with me, and indeed, many people didn't, but he was
> just out of control. All I was trying to do was provide a coherent
> answer to a question I was asked.
Bitter:
http://groups.google.com/groups?selm=an6ud4$52m$1...@usenet.otenet.gr
Sheeps:
http://groups.google.com/groups?selm=amv45e$m7v$1...@usenet.otenet.gr
Immunity:
http://groups.google.com/groups?selm=an4oka$slm$1...@usenet.otenet.gr
Frank A. Adrian
> PS Is Erik Naggum always so full of poisonous bile?
I don't see what you're talking about. Erik gave you an honest answer to
your ill-formed question that (indirectly, but quite intentionally) put
forth the proposition that an approach to object orientation that was
difficult to learn because (a) its power was not necessarily something you
immediately needed; and (b) you lacked the insight to go to a tutorial
rather than a reference source; was inherently inferior to another, more
limited approach to object orientation. Given that it is obvious from the
above that you are (a) not very advanced in your use of object-oriented
methods and (b) either clueless or lazy, I believe that Erik was very
charitable in giving you an answer at all, as are any of us in giving you
our knowledge.
> All I was trying to do was provide a coherent
> answer to a question I was asked.
Then try to provide a coherent question that does not label as inferior
something that you don't understand.
faa
Paolo Amoroso
> * Jeremy H. Brown
> | I haven't read Keene's book,
>
> You really, really should. Several people, myself included, have found that
[...]
> | Method combination is another point of confusing complexity.
>
> Bullshit. It is amazingly straight-forward and almost completely free of
> surprises for something that powerful.
Figure 5.1 "Flow of control of standard method combination", on page 114 of
Keene's book, is exceptionally clear.
Tim Bradshaw
> Sorry, but the CLOS features you described as complex seem pretty
> straightforward to most of us.
I disagree with this, at least in part. I think that it can be quite
hard to know what the precedence list of a class is in the case of MI,
and that sometimes it can be quite surprising. I think there are even
arguments that CLOS's CPL algorithm is not ideal (there's a paper on
this somewhere I think) because it gives surprising results sometimes.
It's *fairly* easy to avoid the odd-CPL cases though.
Similarly I think that it can be quite hard to know what methods will
run when, although I think that this is almost always either due to
surprises in the CPL or (much more often) to just plain misdesign.
--tim
Tim Bradshaw
> Your points regarding using subsets of CLOS are entirely correct, but
> they miss the fact that I was responding to the question "Why is it
> harder to master CLOS than <foo>?" I don't think I could claim to
> have mastered the technology by using only a subset of its abilities.
Yes, but the issue is this quote:
I've always gotten frustrated with its complexity while reading
the spec and wound up ignoring most of it. So I think that'd be
my major complaint in a nutshell: it's extremely complex.
This sounds to me like you're doing something backwards and trying to
understand all the hard bits first. And the answer is not to do that.
Understand the easy bits, rely on the fact that the system is well
designed so the hard bits don't get in the way if you don't use them,
and then as you want to do more complex things the hard bits are
sitting there waiting for you. Compare this to a system which doesn't
provide the hard bits: there you spend about the same time doing the
easy stuff, and then you write the hard stuff yourself, each time.
Other than playing, I don't think I'd used user-defined method
combinations in something like 12-13 years of using CLOS (or PCL
before it was quite CLOS), and they'd never hurt me as a result.
Earlier this year I found that I wanted an idiom which standard method
combination did not provide (specifically, I want around-like methods
which run least-specific outermost). So I spent an hour reading the
spec and wrote a method combination, and then a few more hours
converting a bunch of GFs to use it and testing to see if user-defined
MCs had lower performance than predefined ones (they didn't for the
implementation I was using).
You could argue that this means I hadn't mastered CLOS. But I think
that's wrong. For instance if you asked me *now* to write a method
combination, or tell you what all the predefined method combinations
are, I couldn't. But I know it can be done, and I know where the
manual is. That is mastering in my world, because if it's not then
I've never mastered anything.
--tim
Bruce Hoult
wrote:
> I disagree with this, at least in part. I think that it can be quite
> hard to know what the precedence list of a class is in the case of MI,
> and that sometimes it can be quite surprising. I think there are even
> arguments that CLOS's CPL algorithm is not ideal (there's a paper on
> this somewhere I think) because it gives surprising results sometimes.
> It's *fairly* easy to avoid the odd-CPL cases though.
Try this one:
http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
-- Bruce
Kenny Tilton
Tim Bradshaw wrote:
> * Kenny Tilton wrote:
>
>>Sorry, but the CLOS features you described as complex seem pretty
>>straightforward to most of us.
>
>
> I disagree with this, at least in part. I think that it can be quite
> hard to know what the precedence list of a class is in the case of MI,
> and that sometimes it can be quite surprising.
Agreed, and in my first post on this subject I did say that guessing in
advance how class precedence (CP) would pan out can be tough, but that
is only because I have not taken the trouble to understand the
published, deterministic algorithm, the fun bit being:
"Sometimes there are several classes from SC with no predecessors. In
this case select the one that has a direct subclass rightmost in the
class precedence list computed so far."
[btw, is "rightmost" in the right place in that sentence?]
Why haven't I taken the trouble? Because one of Tilton's Laws is that
juggling the CP (by changing the order of the superclasses as declared
to defclass) should not change my program's behavior, so who cares?
IIRC, we are in the neighborhood of one of the problems Graham has with
OO, viz, that one can look neat and tidy while creating a monstrosity.
Happens to me all the time, then <dare I say it?> I refactor.
kenny
clinisys
Tim Bradshaw
> http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
That's one of them definitely. I think the one I was thinking of was
the Baker `CLOstrophobia' paper.
--tim
Kenny Tilton
k,c
Tim Bradshaw
> Why haven't I taken the trouble? Because one of Tilton's Laws is that
> juggling the CP (by changing the order of the superclasses as declared
> to defclass) should not change my program's behavior, so who cares?
That's a good rule. I'm not *sure* it's always possible to obey it,
but I certainly try whenever I can.
--tim
Ray Blaak
> And, no, I am only full of poisonous bile towards those who deserve it,
> and they always go out of their way to prove it.
How appropriate for a public forum. How impersonal. How ... professional.
What you consistently fail to understand is that /even when they deserve it/
such behaviour is not appropriate.
So says I.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@telus.net The Rhythm has my soul.
Erik Naggum
| How appropriate for a public forum. How impersonal. How ... professional.
How emotional.
| What you consistently fail to understand is that /even when they deserve it/
| such behaviour is not appropriate.
And you have gained access to my brain how? If you think personal comments
are so wrong and apparently attack me for not living up to what I have said,
why do /you/ do it? Perhaps you /do/ understand that even when something is
not "appropriate", it can still have its place and function?
Please be less concerned with me and more concerned with yourself, especially
in public. Also note that I /respond/ to your personal attacks. Even though
what you do is clearly inappropriate by all standards, even someone like you
should be able to understand that letting attacks stand is not in anyone's
interest. If you are so interested in better behavior, start with yourself.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Ray Blaak
> | What you consistently fail to understand is that /even when they deserve it/
> | such behaviour is not appropriate.
>
> And you have gained access to my brain how? If you think personal comments
> are so wrong and apparently attack me for not living up to what I have said,
> why do /you/ do it?
I don't think that personal comments are so wrong. I think that poisonous bile
is wrong. I don't do that.
> Perhaps you /do/ understand that even when something is
> not "appropriate", it can still have its place and function?
Yes I do. I just disagree that "poisonous bile" has its place and function in
this instance.
> Also note that I /respond/ to your personal attacks. Even though
> what you do is clearly inappropriate by all standards, even someone like you
> should be able to understand that letting attacks stand is not in anyone's
> interest.
"Attack" my ass. Criticism? Chiding? Pointing out a percieved inconsistent
position? I you think my words constitute an attack you need to get a much
thicker skin. Certainly responding and disagreeing with my criticisms are fair
game, but Jesus, you've got to lighten up.
> If you are so interested in better behavior, start with yourself.
I act consistently with what I preach.
Hannah Schroeter
Paul Dietz <paul.f...@motorola.com> wrote:
>[...]
>Now, GCL is rather small (but it isn't a full ANSI CL at this time).
clisp is also not too bug, and, while it's not completely ANSI, I don't
really think making it completely compliant would really bloat it too
much any more.
Kind regards,
Hannah.
Hannah Schroeter
Hannah Schroeter <han...@schlund.de> wrote:
>[...]
>clisp is also not too bug, and, while it's not completely ANSI, I don't
^i
>really think making it completely compliant would really bloat it too
>much any more.
I should learn to type again.
Kind regards,
Hannah.