From: Paolo Amoroso
Subject: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <hP=QPLbuEEoeV78tU5ymnRuJP6pc@4ax.com>
One of the most interesting recent threads was the one about how people got
started with Lisp. Here is another potentially interesting issue: how did
your impress your clients, bosses or colleagues with Lisp applications,
language features or tools? One of the reasons I ask is because I haven't
impressed anybody--yet :)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
From: Thien-Thi Nguyen
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <kk9g01aeuhu.fsf@glug.org>
Paolo Amoroso <·······@mclink.it> writes:
> how did your impress your clients, bosses or colleagues with
> Lisp applications, language features or tools?
"network chip" (packet pipeline) simulator front-end w/ emacs (for pay),
including configurable register windows, update via ipc, and single-step
mode. an hour to do, an hour to demo, an hour for the (now dead, yay)
startup to have its java programmer pour bignum hours into a feeble
replacement. all but forgotten (except the GPL bits ;-).
GNUGO front-end w/ emacs (for you and everyone).
etc.
elisp may not get the respect it deserves, but that's another thread.
what impresses people changes -- perhaps some day people will be more
impressed w/ the backwards (and slow) pace of software methodologies
that people used to harbor. as in, "ugh, that doesn't look like fun".
thi
From: Marco Antoniotti
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <y6cu1pqmzgj.fsf@octagon.mrl.nyu.edu>
Thien-Thi Nguyen <···@glug.org> writes:
> Paolo Amoroso <·······@mclink.it> writes:
>
> > how did your impress your clients, bosses or colleagues with
> > Lisp applications, language features or tools?
>
> "network chip" (packet pipeline) simulator front-end w/ emacs (for pay),
> including configurable register windows, update via ipc, and single-step
> mode. an hour to do, an hour to demo, an hour for the (now dead, yay)
> startup to have its java programmer pour bignum hours into a feeble
> replacement. all but forgotten (except the GPL bits ;-).
>
> GNUGO front-end w/ emacs (for you and everyone).
>
> etc.
>
> elisp may not get the respect it deserves, but that's another
> thread.
Elisp with (require 'cl) has all my respect :)
cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Friedrich Dominicus
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <874rhqesad.fsf@fbigm.here>
Paolo Amoroso <·······@mclink.it> writes:
> One of the most interesting recent threads was the one about how people got
> started with Lisp. Here is another potentially interesting issue: how did
> your impress your clients, bosses or colleagues with Lisp applications,
> language features or tools? One of the reasons I ask is because I haven't
> impressed anybody--yet :)
Don't know if that counts. I took part on the "Linux World" far last
year. The reactions of the people were.
- Well I remember
- What is Lisp
- Does really anyone work with it yet.
Well the most astonished faces I can remember, was as we showed how one can
patch a running application, second suprise was sometimes that one
could do OO in Common Lisp...
Regards
Friedrich
From: Georges Ko
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <m31ycuogah.fsf@symbiose.dnsalias.net>
Friedrich Dominicus <·····@q-software-solutions.com> wrote:
> Well the most astonished faces I can remember, was as we showed how
> one can patch a running application,
Redefining functions in Emacs counts as patching a running
application, right ?
--
Georges Ko (Taipei, Taiwan) 2002-05-02 ···@gko.net / ICQ: 8719684
Jeudi 2 mai 2002
Georges Ko <···@gko.net> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> wrote:
>
> > Well the most astonished faces I can remember, was as we showed how
> > one can patch a running application,
>
> Redefining functions in Emacs counts as patching a running
> application, right ?
Absolutely. And the ability to do this feels a lot more impressive
once you run into a bug in a part of Emacs written in C. Then your
only choice is to completely rebuild Emacs from source. Yuck. (And
sometimes impossible, if you don't have enough room in your user
account).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Friedrich Dominicus
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <873cx9vm0p.fsf@fbigm.here>
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Georges Ko <···@gko.net> writes:
>
> > Friedrich Dominicus <·····@q-software-solutions.com> wrote:
> >
> > > Well the most astonished faces I can remember, was as we showed how
> > > one can patch a running application,
> >
> > Redefining functions in Emacs counts as patching a running
> > application, right ?
>
> Absolutely. And the ability to do this feels a lot more impressive
> once you run into a bug in a part of Emacs written in C.
As Georges has pointed it out it sounds as if he does not find that
impressing. Which probably shows what Lisp makes you think is all
granted. Re-defining some stuff, what a deal...
Well I suggest he tries something like that in Java, C, C++ and how
they are all called... It will work in Smalltalk, but again if you are
used to it it makes you think all languages work that way..
Regards
Friedrich
From: Bob Bane
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <3CD1713D.2014F4C7@removeme.gst.com>
Running a multi-threaded web server in Lisp under emacs (AllegroServe,
to be precise). Each incoming request is handled by its own thread; if
an error happens, the thread can fall into the debugger where you can
examine the entrails, change the code, compile the change, move down a
few frames and continue the thread, without interrupting processing on
other threads.
Java-based web servers claim to be able to do this inside their IDEs,
but as of two years ago (last time I looked) they were lying. I suspect
they are still lying even today if the code change involves changing
object layout.
I've also done a bunch of work with Lisp in multi-language, peer-to-peer
processing environments. Many times one of my coworkers would message
me saying that "your piece of the system is reporting errors". I'd go
over, look at the error logs, sometimes telnet to my running Lisp
process and look at its internal state (another impressive thing that's
trivial in Lisp, painful elsewhere), and nearly all the time I'd
discover that another process was actually at fault - my stuff was
getting the blame because it was REPORTING the error rather than
crashing and restarting itself.
- Bob Bane
Bob Bane <·····@removeme.gst.com> wrote...
> Running a multi-threaded web server in Lisp under emacs (AllegroServe,
> to be precise). Each incoming request is handled by its own thread; if
> an error happens, the thread can fall into the debugger where you can
> examine the entrails, change the code, compile the change, move down a
> few frames and continue the thread, without interrupting processing on
> other threads.
Is AllegroServe the only one with this capability (or with the best
implementation of it), or are there other Lisp web servers or
server-OS combinations that can do this (or do this equally well)?
From: Pierre R. Mai
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <87offxt9rv.fsf@orion.bln.pmsf.de>
··········@yahoo.com (Pratibha) writes:
> Bob Bane <·····@removeme.gst.com> wrote...
> > Running a multi-threaded web server in Lisp under emacs (AllegroServe,
> > to be precise). Each incoming request is handled by its own thread; if
> > an error happens, the thread can fall into the debugger where you can
> > examine the entrails, change the code, compile the change, move down a
> > few frames and continue the thread, without interrupting processing on
> > other threads.
>
> Is AllegroServe the only one with this capability (or with the best
> implementation of it), or are there other Lisp web servers or
> server-OS combinations that can do this (or do this equally well)?
We have our own HTTP/1.1 server implemented in CL (called CLASH),
which predates AllegroServe, where this works in the same way. It's
been very helpful in debugging buggy IIS Proxies, buggy clients, etc.,
and adding work-arounds for those bugs on-the-fly.
For that matter, I'd expect most CL-based servers to offer similar
capabilities, since it is the natural way to implement those.
One of the core assets in this is CL's very good condition system,
which allows precise reporting of errors, and cooperation between the
signalling and the handling site in handling the error (think restarts
and handlers). Because of those, I'm much more confident in the
reliability of CL servers than servers implemented in more
impoverished languages.
Any other language/OS that offers dynamic redefinition capabilities,
multi-processing and an expressive condition system could offer
similar capabilities.
Many languages don't, either because they don't have the underlying
features to support this, or because they still live in the conceptual
world of batch-processing...
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Stefan Schmiedl
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <aarovr$d743m$1@ID-57631.news.dfncis.de>
On Thu, 02 May 2002 11:04:25 +0200,
Paolo Amoroso <·······@mclink.it> wrote:
> One of the most interesting recent threads was the one about how people got
> started with Lisp. Here is another potentially interesting issue: how did
> your impress your clients, bosses or colleagues with Lisp applications,
> language features or tools? One of the reasons I ask is because I haven't
> impressed anybody--yet :)
>
Are there any "elevator pitches" for lisp?
I.e. statements, questions etc. you could use in an elevator
to convince or at least get interested in the value of CL?
oh ... we're talking about working elevators here, so you have
about 30 seconds ....
s.
Stefan Schmiedl <·@xss.de> wrote in message
···················@ID-57631.news.dfncis.de...
> Are there any "elevator pitches" for lisp?
> I.e. statements, questions etc. you could use in an elevator
> to convince or at least get interested in the value of CL?
>
> oh ... we're talking about working elevators here, so you have
> about 30 seconds ....
I would start off with "Did you know that you can patch or upgrade your lisp
application while it is actually still running on your clients machine?"
That is of course after "Yes, you can compile it." "No, there are other
data types besides lists" and "Actually, lisp applications can perform well
within the speed range of mainstream languages" etc...
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
From: Erik Naggum
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <3229353106350910@naggum.net>
* Paolo Amoroso <·······@mclink.it>
| One of the most interesting recent threads was the one about how people
| got started with Lisp. Here is another potentially interesting issue: how
| did your impress your clients, bosses or colleagues with Lisp
| applications, language features or tools? One of the reasons I ask is
| because I haven't impressed anybody--yet :)
The first thing I did that impressed a system admin and got him on my
side "against" management was to write a small set of wrapper functions
around the /etc/passwd database, which you can do in any language, and
then write setf methods for them that did the real thing. While any
sysadmin knows that changing a user ID involves a file system walk for
files owned by the existing user ID and changing them one by one, this
operation is not generally thought of as
(setf (user-id (find-user "username")) 666)
This operation is now abstracted away from the script-like solution and
can now also be implemented in the kernel, or by modifying an unmounted
file system, or something else. So, a unified approach to getting and
setting all the fields of the password file was so attractive that he
helped me get Common Lisp in the door. And that is just setf...
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
From: Christopher Browne
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <aasirf$dl5gf$1@ID-125932.news.dfncis.de>
In an attempt to throw the authorities off his trail, Erik Naggum <····@naggum.net> transmitted:
> (setf (user-id (find-user "username")) 666)
Interesting.
The one problem I'd see with this is that it would get awfully
inefficient if you try to do a more extensive update, as with:
(setf (id1 (find-user "id1")) 666
(id2 (find-user "id2")) 667
(id3 (find-user "id3")) 668
(id4 (find-user "id4")) 669)
or
(loop
for i in '("id1" "id3" "id7" "foo" "bar" "baz")
for j from 689 by 1
do (setf (find-user i) j))
Did you consider setting up an "environment" for this, as with
(with-deferred-password-updates
(setf (id1 (find-user "id1")) 666
(id2 (find-user "id2")) 667
(id3 (find-user "id3")) 668
(id4 (find-user "id4")) 669))
Which would read the file into a MAKE-HASH in at the start, query
values, as needed, update them, as neded, and then push out all the
updates at the end at once?
The scheme would get rather "old" rather quick if you had to rewrite
/etc/passwd each time you do a component of the SETF...
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www.ntlug.org/~cbbrowne/spiritual.html
Oh, boy, virtual memory! Now I'm gonna make myself a really *big*
RAMdisk!
From: Erik Naggum
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <3229381214862157@naggum.net>
* Erik Naggum
> (setf (user-id (find-user "username")) 666)
* Christopher Browne
| Interesting.
|
| The one problem I'd see with this is that it would get awfully
| inefficient if you try to do a more extensive update
Well, you seldom do this in the first place because it is so inefficient.
Only in the very rare case would you ever want to change a user's uid.
But that you could express the operation abstractly simply as a setf on
the innocuous accessor, is sufficiently elegant that a competent sysadmin
would see the sheer charm of it. I mean, the whole point of this thread
is to share stories of how we convinced people that Common Lisp was good,
right? I did just that. *sigh*
| (setf (id1 (find-user "id1")) 666
| (id2 (find-user "id2")) 667
| (id3 (find-user "id3")) 668
| (id4 (find-user "id4")) 669)
I am not sure what you think this does, but my example has find-user,
which takes a user-name and returns all the data about a user in a user
object, and user-id which is an accessor into the object. The fact that
it has access to the old value and can do more intelligent things than
just setting the slot in the user information was kind of the key here.
| The scheme would get rather "old" rather quick if you had to rewrite
| /etc/passwd each time you do a component of the SETF...
That is a separate layer of abstraction entirely and is not even handled.
The accessors into the user database are already sufficiently abstract
in, e.g., Linux that editing /etc/passwd is deprecated and discouraged.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> (setf (user-id (find-user "username")) 666)
>
> This operation is now abstracted away from the script-like solution
Of course this can also be easily done in Perl (using tied variables) or
Dylan (using -setter functions), but with syntax the sysadmin would
probably find more familiar.
-- Bruce
From: Erik Naggum
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <3229380240459616@naggum.net>
* Bruce Hoult
| Of course this can also be easily done in Perl (using tied variables) or
| Dylan (using -setter functions), but with syntax the sysadmin would
| probably find more familiar.
Sure, but in which case you would not be able to sell anything new.
However, I wonder how you could miss the fact that we were trying to
share actual stories of how we convinced people to use Common Lisp, not
some hypothetical story of how the one Dylan fan in the universe could
have done it. _Please_, do not reply. I do not really want to know.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Bruce Hoult
> | Of course this can also be easily done in Perl (using tied variables) or
> | Dylan (using -setter functions), but with syntax the sysadmin would
> | probably find more familiar.
>
> Sure, but in which case you would not be able to sell anything new.
>
> However, I wonder how you could miss the fact that we were trying to
> share actual stories of how we convinced people to use Common Lisp
I didn't miss it, and your story is valuable, but even more valuable
would be stories that don't depend on ignorance on the part of the
sysadmin but that rather show capabilities only Lisp has, rather than
something convenient in Lisp but also convenient in the scripting
languages already installed on the machine.
-- Bruce
From: Erik Naggum
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <3229385759350563@naggum.net>
* Bruce Hoult
| I didn't miss it, and your story is valuable, but even more valuable
| would be stories that don't depend on ignorance on the part of the
| sysadmin but that rather show capabilities only Lisp has, rather than
| something convenient in Lisp but also convenient in the scripting
| languages already installed on the machine.
Ignorance? Are you for real? (Well, I know you are not.)
The difference between a story of a solution and a blabbering idiot is
that the solution has actually been demonstrated, whereas the blabbering
idiot only talks about some hypothetical world in which he _could_ have
done it, but has yet to do it. Anybody can take a prism and produce a
color spectrum today, but Isaac Newton was the first to do it. I imagine
you being the unimpressed idiot who said "I could do have done that" --
of course you could -- after the fact. The point is that nobody had done
this, yet. But you probably do not understand this, considering that
Dylan is reinvention incarnate.
If you would not have been convinced, fine. If you are not happy that
someone else was convinced, fuck you. If you think you are my target
audience for anything, you are not. If you continue to parade your
ignorant destructiveness, you show the world who Dylan is for and why you
post in comp.lang.lisp to get an audience. Get lost, whining loser.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
>
> The difference between a story of a solution and a blabbering idiot is
[SNIP]
>
> If you would not have been convinced, fine. If you are not happy that
> someone else was convinced, fuck you. If you think you are my target
> audience for anything, you are not. If you continue to parade your
> ignorant destructiveness, you show the world who Dylan is for and why
you
> post in comp.lang.lisp to get an audience. Get lost, whining loser.
If you are not happy because someone is not suitably impressed by your
*startling revelations*, then backatchya buddy. If the above paragraph is
not evidence that you, Erik, are "ignorant destructiveness" personified,
then I don't know what is. Finally, if *you* are the type of person who
Common Lisp is for, then I intend to stop using it immediately.
--
"CL N00b" <·····@room666.hell.com> wrote in message ···························@bin4.nnrp.aus1.giganews.com...
>
> Finally, if *you* are the type of person who
> Common Lisp is for, then I intend to stop using it immediately.
Might I suggest INTERCAL?
From the C-Intercal Supplement section 6:
`A feature of INTERCAL-72 not documented in the manual was that it
required a certain level of politesse from the programmer. If fewer than
1/5th of the program statements included the PLEASE qualifier, the program
would be rejected as insufficiently polite.'
The web site is http://www.webcom.com/nazgul/intercal.html
Considering the return address you have included this seems particularly apt.
From: Pierre R. Mai
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <87k7qlt9at.fsf@orion.bln.pmsf.de>
"CL N00b" <·····@room666.hell.com> writes:
> then I don't know what is. Finally, if *you* are the type of person who
> Common Lisp is for, then I intend to stop using it immediately.
Please do so. It wouldn't do at all to have someone posting under
"CL N00b" <·····@room666.hell.com> to be publically known to use
Common Lisp. Might even lose us the vatican as a client.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Nils Goesche
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <87sn59m8f5.fsf@darkstar.cartan>
"CL N00b" <·····@room666.hell.com> writes:
[nonsense]
Seems Mr. Thomas has developed yet another personality, hm?
Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.
PGP key ID #xC66D6E6F
From: Erik Naggum
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <3229446454723142@naggum.net>
* "CL N00b" <·····@room666.hell.com>
| If you are not happy because someone is not suitably impressed by your
| *startling revelations*, then backatchya buddy.
Wow, George W. Bush is posting to comp.lang.lisp.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Bruce Hoult
> | I didn't miss it, and your story is valuable, but even more valuable
> | would be stories that don't depend on ignorance on the part of the
> | sysadmin but that rather show capabilities only Lisp has, rather than
> | something convenient in Lisp but also convenient in the scripting
> | languages already installed on the machine.
>
> Ignorance? Are you for real? (Well, I know you are not.)
Yes I'm for real. Ignorance is the precisely correct word. They almost
most certainly have Perl installed, and probably use it. If they don't
know how to use tied variables to implement transparent updates to
things external to the program using a simple asignment statement then
that is ignorance, pure and simple.
You can talk about Isaac Newton and prisms if you like, but this isn't
some revelation, it's been standard practice in the Perl world for a
number of years -- perhaps most obviously in the various database
libraries. I've used it in my own code plenty of times.
-- Bruce
From: Will Hartung
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <3cd2d81d$1_6@news.teranews.com>
"Bruce Hoult" <·····@hoult.org> wrote in message
································@copper.ipg.tsnz.net...
> Yes I'm for real. Ignorance is the precisely correct word. They almost
> most certainly have Perl installed, and probably use it. If they don't
> know how to use tied variables to implement transparent updates to
> things external to the program using a simple asignment statement then
> that is ignorance, pure and simple.
...and it could be done with just about any language with reasonable
abstraction. C++, Java, Forth, Smalltalk, etc.
My friend is a SysAdmin, been using Perl for 8 years, and he had never even
heard of "tied variables". "SysAdmins aren't programmers! Must be a Perl 5
thing." he quotes.
I had to look them up myself, but I haven't used perl much either.
What Eriks toy did is not simply show this "tied variable" effect.
I'm guessing here, but I would imagine the that the scenario showed:
Interacting with Lisp.
Tight association between Emacs and Lisp.
The transparent abstraction possible with Lisp.
That Lisp can do "systems programming" tasks (Really!?!?? Really.)
That you never have to leave the Lisp environment to do "real work".
If things went poorly, perhaps he was able to demonstrate the actual
interactive debugging of an error.
All of this was show pretty much transparently I imagine. All of it was,
essentially, taken for granted, like GNU Readline in BASH. It just happens.
And finally, he introduced a very high level "user object" that has
awareness of not only the simple user attributes, but also of its files in
the file system.
Many systems will delete the users home directory as part of the utility to
delete a users account, but this idea is even better integrated.
That was the "aha" moment for me. *I* am not aware of ever seeing a "User
Object" that was that high of level, to include the users files as a (not
necessarily directly accesible) property of the User. That's pretty neet, I
think.
You'd like to think that scsh would have this kind of high level
abstraction, but I don't know if it does or not.
I mean, for me even if I had a Perl module that had this kind of
abstraction, I'd probably still just do it from a command line:
find / -user 123 -print | xargs chown 456
vs writing a small Perl Script to do it.
Even if everything was set up to where you can simply type:
$ perl user["will"].id = 456
And have Magic Happen, it's still not as "elegant", by perhaps the slightest
fraction, as the SETF that Erik used. I still have to stick on that "Perl"
command. (Actually, it gains elegance with the transparent use of the
associative array, but loses elegance by actually having to launch Perl.)
If I wanted to get rid of that, then I have to use a script, and that blows
the abstraction, because now I'm not in perl anymore, and lose all of its
benefits. Once it's a script, the fact that it's one line is meaningless.
With the Lisp I could potentially do something silly like:
;; Give "will" the "next" user-id
(setf (user-id (find-user "will")) (+1 (user-id (find-user :latest))))
Error: The user "will" does not exist
1 (continue) Add user "will"
2 Specify another user to use this time
3 (abort) Return to level 0.
4 Return to top loop level 0.
Anyway, with a this little toy, it helped demonstrate that it is possible
and practical to build up a lot of nice abstractions within the Lisp World
to do Neet Things. Even "Sys Admin" things. I don't think anybody uses Perl
as a shell, but you can easily use Lisp as a shell, particularly when
combined with something like Emacs. (Thus even more motivation for a good CL
based Emacs...)
So, this wasn't simply a demonstration of a "tied" variable. It helps
demonstrate a cohesive whole that a Lisp environment can become.
"Lisp -- It's not just for AI anymore."
I saw a big picture here, and I hope others did too.
Best Regards,
Will Hartung
(·····@msoft.com)
From: Erik Naggum
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <3229444233543445@naggum.net>
* Bruce Hoult
| Yes I'm for real. Ignorance is the precisely correct word. They almost
| most certainly have Perl installed, and probably use it. If they don't
| know how to use tied variables to implement transparent updates to
| things external to the program using a simple asignment statement then
| that is ignorance, pure and simple.
That is not the point. Whether he knew how to do it is irrelevant. If
he knew how to use "tied variables" and how to write the same thing in
Perl, he might _still_ think the Common Lisp way of doing it was nice
enough that he wanted to help give Common Lisp a chance, and I told the
story of how at least one sysadmin was sufficiently impressed. Which was
the point of this thread, you annoying imbecile.
Clearly, doing _anything_ to satisfy you is an utter waste of time.
Please, return to your Dylan newsgroup. Anyone who _wants_ to talk to
you will know where to find you.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
From: Steve Long
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <3CD2009E.E1AFA4CE@hotmail.com>
We used ICAD tool to generate 84 aircraft components -- solid representation
and drawing -- in 15 minutes instead of 6 months. Similarly created bracket
designs that also reduced the number of detail parts. Hundreds of wire part
selections and connector terminations using ICAD (mostly ACL) and Oracle.
These and other applications developed much more quickly in a Lisp-based tool
(ICAD uses Allegro's flavors tech) than with C++ or even Java (although C was
used to get to Oracle thru the back door), allowing companies to bridge the
gap between software developers and mechanical engineers.
Paolo Amoroso wrote:
> One of the most interesting recent threads was the one about how people got
> started with Lisp. Here is another potentially interesting issue: how did
> your impress your clients, bosses or colleagues with Lisp applications,
> language features or tools? One of the reasons I ask is because I haven't
> impressed anybody--yet :)
>
> Paolo
> --
> EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
> http://www.paoloamoroso.it/ency/README
> [http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
From: Chris Perkins
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <ZWzA8.38$id.43738@news.uswest.net>
"Paolo Amoroso" <·······@mclink.it> wrote in message
·································@4ax.com...
> One of the most interesting recent threads was the one about how people
got
> started with Lisp. Here is another potentially interesting issue: how did
> your impress your clients, bosses or colleagues with Lisp applications,
> language features or tools? One of the reasons I ask is because I haven't
> impressed anybody--yet :)
It is almost the same story - the things that impressed me about Lisp and
made me want to learn it are the same things that I have slowly been able to
impress my business partner with (though he has yet to learn it).
There hasn't been one thing (well, maybe the toplevel), but lots of
individual things combined together and, at the same time, shedding lots of
annoyances that exist in C/Java.
Defining method dispatch on value as well as type. We are tired of filling
our code up with this crap:
if (someObj != null){ someCount = someObj.getCount(); } else { someCount =
0; }
instead of simply
(getCount someObj)
and let the method dispatch recognize that someObj is nil and retrieve 0 (or
whatever) for us.
Multiple return values.
Incremental compilation.
Dynamic function creation ( with compilation!!)
A single multiple purpose collection type (the list) as opposed to different
templates / classes for Vector, Stack, Set, Tree.
redefinition of classes while preserving the objects (just started using
this - LOVE IT)
multiple inheritance AND garbage collection (the sometimes C++ vs. Java
debate)
And, of course, the big one: the top level. instant testing, powerful
debugging, experimentation, true "hacking". My business partner is
threatening to build one in Java or C. I told him not to bother.
Anyway, I don't need to preach to this choir. My business partner, like
me, is a programmer. When we took up Java years back it was with a big sigh
of relief: "Aaah, this is so much nicer." Java has lots of problems, and,
as power goes, can be rather limiting. But so many of the annoyances and
obstacles in everyday programming that come with C/C++ are taken away. It's
a vacation, but like a vaction, one doesn't get much done. Even my partner
admits that had we known about Lisp three years ago we never would have
bothered with Java. Lisp has that same sigh of relief, but it has teeth and
muscle.
Chris
From: Hannah Schroeter
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <ab2qkn$k3b$1@c3po.schlund.de>
Hello!
In article <·················@news.uswest.net>,
Chris Perkins <········@medialab.com> wrote:
>[...]
>A single multiple purpose collection type (the list) as opposed to different
>templates / classes for Vector, Stack, Set, Tree.
Hmmm. Lisp has different collection types too.
Lisp lists are *a bit* (only a bit!) akin to C++'s std::list
(the latter is doubly linked, so access to the end is fast, too).
Lisp has arrays (more specific: vectors), which are a bit akin to
C++'s std::vector. Lisp has hash tables, which you can use for
sets (use dummy values, such as nil) and maps (thus covering the
applications of C++'s std::set and std::map, though with a different
implementation: C++ mandates the use of some search tree as the
map/set implementations may not use some hash function, but may
use a less-than comparison operator).
If you use Lisp lists for usages where a vector (be it C++'s
std::vector or a Lisp vector) would be more appropriate,
you lose. For stacks, it's okay, of course. For sets, you lose
too if the set begins to get larger. For trees, it's not so
good either except if it's only a binary tree with no additional
information attached to the interior nodes. Else I'd build my
tree datatype myself using defstruct or defclass.
>[...]
>multiple inheritance AND garbage collection (the sometimes C++ vs. Java
>debate)
Eiffel e.g. has that too, albeit, of course clos is much more powerful.
And there's currently some discussion about GC in C++ going on on
c.l.c++.moderated. Go figure :-)
>[... agree with the other points ...]
Kind regards,
Hanna.
From: Jason Kantz
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <87g019qlfe.fsf@kantz.com>
This is not a direct reply to your question (I can't claim a great
deal of CL machismo yet) but since I started programming I've had this
sense that my motivation was to write cool software. This has always
been a vague thought for me, so maybe this is a good time to ask
myself, "Hey, what is it about cool software that's so cool?"
The care taken to create a complete and conscious design--that tops my
list. When all design decisions are considered and choices are made
based on careful thought, rather than rushed through and left to
chance, that is something to stop and notice. Hacks are not cool
because hacking implies no thought. Charlie Batch's work on
Internationalization for Allegro CL is impressive. The emacs calandar
code is cool. Olin Shivers' preamble to "The SRE regular-expression
notation" about 100% and 80% solutions covers this idea well.
Customizable software is cool. But more fundamental is adaptablility.
Being able to set the indent or the syntax highlight in emacs to
whatever tickles you right is somewhat cool, but the fact that emacs'
is designed so well that it has survived for 25 years, is available on
such a wide range of systems, and can be adapted to whatever text
editing use one can conceive--that deserves a big salute. The next
level of cool is adaptable software that is adaptive, but right now I
can't think of any examples of this.
Software that deals with a massive data set is cool. The scope of the
search problem for Google and the effectiveness of their software is
what makes Google cool--and the way they get all those pigeons to
... never mind.
Software with a massive data set and a massive number of users is
double impressive. Hearing about ITA software and the time
constraints on their problems in order to serve such a large network
of the travel market impressed me. Hearing Philip Greenspun talk
about how many gazillions of requests/sec his AOLServer was handling
always seemed impressive. Machismo.
Culture around impressive software is a good side benefit of being
impressive. For example Kent Pitman was telling some guy not to be
superstitious the other day. I've been told by another CL programmer,
"It's not voodoo!" when my approach to understanding a bug was wrong.
A comment like that stings a bit, but when it is right on, it can be
appreciated. That part of the CL culture is to think things through
and do your homework before making decisions, judgements, or coming up
with "explanatory" theories. So it's nice to see that the complete
and conscious design principle is part of the CL culture.
Software that deals with nonlinear problems is cool.
Software that saves a lot of time is an easy win.
So what makes for impressive software? I've elaborated on some of the
easy answers with some examples, but I'm sure there are more
insightful criteria for what makes for cool software, and many more
examples of systems that fit the bill.
The following articles have been motivating reads:
Preamble: 100% and 80% solutions
http://www.ai.mit.edu/~shivers/sre.txt
EMACS: The Extensible, Customizable Display Editor
http://www.gnu.org/software/emacs/emacs-paper.html
Adaptive Software
http://www.norvig.com/adapaper-pcai.html
Carl De Marcken: Inside Orbitz
http://www.paulgraham.com/paulgraham/carl.html
The technology behind Google's great results
http://www.google.com/technology/pigeonrank.html
From: Chris Beggy
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <87offx2n5i.fsf@lackawana.kippona.com>
Jason Kantz <············@kantz.com> writes:
> The following articles have been motivating reads:
>
> Preamble: 100% and 80% solutions
> http://www.ai.mit.edu/~shivers/sre.txt
Yes.
> EMACS: The Extensible, Customizable Display Editor
> http://www.gnu.org/software/emacs/emacs-paper.html
Yes.
> Adaptive Software
> http://www.norvig.com/adapaper-pcai.html
Yes.
> Carl De Marcken: Inside Orbitz
> http://www.paulgraham.com/paulgraham/carl.html
Yes.
> The technology behind Google's great results
> http://www.google.com/technology/pigeonrank.html
Um, you're just checking to see if anybody got to the end of your
long post, right :-).
Chris
Jason Kantz <············@kantz.com> writes:
> EMACS: The Extensible, Customizable Display Editor
> http://www.gnu.org/software/emacs/emacs-paper.html
Is there a printer-friendly version of this around ?
> > EMACS: The Extensible, Customizable Display Editor
> > http://www.gnu.org/software/emacs/emacs-paper.html
>
> Is there a printer-friendly version of this around ?
(if got-answer-here-p
'cool
(ask-question-again-on "gnu.emacs.help"))
D <http://www.glue.umd.edu/~deego>
--
Jacek Generowicz <················@cern.ch> writes:
> Jason Kantz <············@kantz.com> writes:
>
> > EMACS: The Extensible, Customizable Display Editor
> > http://www.gnu.org/software/emacs/emacs-paper.html
>
> Is there a printer-friendly version of this around ?
Have you tried running it through
<http://www.easysw.com/htmldoc/pdf-o-matic.php>? It's
printer-friendly enough for me.
Edi.
Edi Weitz <···@agharta.de> writes:
> Jacek Generowicz <················@cern.ch> writes:
>
> > Jason Kantz <············@kantz.com> writes:
> >
> > > EMACS: The Extensible, Customizable Display Editor
> > > http://www.gnu.org/software/emacs/emacs-paper.html
> >
> > Is there a printer-friendly version of this around ?
>
> Have you tried running it through
> <http://www.easysw.com/htmldoc/pdf-o-matic.php>? It's
> printer-friendly enough for me.
Now that's a handy little URL to know. Thanks !
Paolo Amoroso <·······@mclink.it> writes:
> One of the most interesting recent threads was the one about how
> people got started with Lisp. Here is another potentially interesting
> issue: how did your impress your clients, bosses or colleagues with
> Lisp applications, language features or tools? One of the reasons I
> ask is because I haven't impressed anybody--yet :)
Unfortunately, Lisp programmers have had it twice as bad. They not only
have to sell themselves, but have to sell Lisp. And it seems that this
newsgroup has seen many of us expound on our experiences with selling
Common Lisp.
I'd like to hear how people would compare Common Lisp to something like
Jython. From what I've read, including Peter Norvig's "Python for Lisp
Programmers" paper, something like Jython would be a very compelling
argument:
1) it's extremely dynamic (rivals CL), including its programming
environment
2) can leverage the full extent of Java's rich set of libraries
3) good for scripting, as well as for bigger applications
4) can be compiled
*5) uses JVM, for which a lot of work is being done
Jython is also free, open-source, and supposedly as cross-platform as
Java is (FWIW), and the Python part itself is as cross platform as gcc
is.
If you read Norvig's paper, he describes using Python instead of CL in
his AI book. I've read that book, and saw some of the examples, Python
vs. CL...and even though I'm appalled by whitespace-dependence, I don't
know that this is necessarily any more rational than how appalled people
are with parens everywhere. But the point made about the removal of
the parens and addition of some indentation makes CL and Python look
surprisingly similar.
Also, reading the paper, you must consider that Jython has more
capabilities than the Python that Norvig was comparing to, not to mention
a compiler that (I think) compiles Jython down to JVM code.
I havn't tried Jacol (http://jacol.sourceforge.net) yet, but after
looking at its interface into CL, it's not quite that smooth.
dave
Dave Bakhash wrote:
> Paolo Amoroso <·······@mclink.it> writes:
>
>> One of the most interesting recent threads was the one about how
>> people got started with Lisp. Here is another potentially interesting
>> issue: how did your impress your clients, bosses or colleagues with
>> Lisp applications, language features or tools? One of the reasons I
>> ask is because I haven't impressed anybody--yet :)
>
> Unfortunately, Lisp programmers have had it twice as bad. They not only
> have to sell themselves, but have to sell Lisp. And it seems that this
> newsgroup has seen many of us expound on our experiences with selling
> Common Lisp.
>
> I'd like to hear how people would compare Common Lisp to something like
> Jython. From what I've read, including Peter Norvig's "Python for Lisp
> Programmers" paper, something like Jython would be a very compelling
> argument:
Here I did not get your change of the topic. How does a comparison between
Common Lisp and [J/P]ython relate to anecdotes about impressing others with
Lisp application, language features or tools? (Not to say that [P/J]ython
has the stated problem of selling both - you and the language - too.)
> 1) it's extremely dynamic (rivals CL), including its programming
> environment
Well - last time I looked - (which is at least 1 year ago) [J/P]ython did
neither have multiple dispatch, method combinations, macros or conditions
comparable to CL.
This enumeration is neither complete nor authorative.
There are many other things I do not like in Python (for example implicit
binding by assignment and indentation dependent semantics.) but this things
may be more or less a matter of taste.
> 2) can leverage the full extent of Java's rich set of libraries
> 3) good for scripting, as well as for bigger applications
> 4) can be compiled
> *5) uses JVM, for which a lot of work is being done
>
> Jython is also free, open-source, and supposedly as cross-platform as
> Java is (FWIW), and the Python part itself is as cross platform as gcc
> is.
>
> If you read Norvig's paper, he describes using Python instead of CL in
> his AI book. I've read that book, and saw some of the examples, Python
> vs. CL...and even though I'm appalled by whitespace-dependence, I don't
> know that this is necessarily any more rational than how appalled people
> are with parens everywhere. But the point made about the removal of
> the parens and addition of some indentation makes CL and Python look
> surprisingly similar.
>
> Also, reading the paper, you must consider that Jython has more
> capabilities than the Python that Norvig was comparing to, not to mention
> a compiler that (I think) compiles Jython down to JVM code.
As far as I remember Jython is even slower than CPython (the original
non-JVM implementation).
But I still do not see in what way this whole stuff is on topic in this
thread? (Maybe asking this question in comp.lang.python is more
appropriate...)
ciao,
Jochen
--
http://www.dataheaven.de
hey,
> Here I did not get your change of the topic. How does a comparison between
> Common Lisp and [J/P]ython relate to anecdotes about impressing others with
> Lisp application, language features or tools? (Not to say that [P/J]ython
> has the stated problem of selling both - you and the language - too.)
Why don't you send me a fine. Or, better yet, just ignore me.
> > 1) it's extremely dynamic (rivals CL), including its programming
> > environment
>
> Well - last time I looked - (which is at least 1 year ago) [J/P]ython did
> neither have multiple dispatch, method combinations, macros or conditions
> comparable to CL.
> This enumeration is neither complete nor authorative.
It doesn't have multimethods, but considering that this is a
discussion focused around being able to leverage the work in Java,
that's probably a good thing. Mismatch in the OO model would only
make integration with Java more difficult.
It does not have macros, and that is legitimate. But there are
several arguments suggesting why they don't need macros, and that they
have something that solves the same problem. It's been explained to
me months ago...but unfortunately, I've since forgotten the details.
Someone here might be able to fill in here.
Method combination is another feature that's very specific to CLOS,
and I would argue that 99% of programs don't use it, and of the 1%
that do, at least half are probably using it wrong (or just using it
for the sake of saying they're using a non-standard method
combination).
> There are many other things I do not like in Python (for example implicit
> binding by assignment and indentation dependent semantics.) but this things
> may be more or less a matter of taste.
They are. I also don't like the Lisp-1 style sematics, and personally
despise the whitespace dependence.
But again, people who work with these rules more often than not
eventually find that they like the indentation rules. Considering
that most programmers already indent their code, some of the
puctuation and delimiters we use could be viewed as redundant, and
even obfuscating the code that's already indented.
> > Also, reading the paper, you must consider that Jython has more
> > capabilities than the Python that Norvig was comparing to, not to mention
> > a compiler that (I think) compiles Jython down to JVM code.
> As far as I remember Jython is even slower than CPython (the original
> non-JVM implementation).
Again, these questions of speed...mean nothing to me. From what I've
heard, Jython has its own compiler, and questions of speed are
long-term (and even mid-term) non-issues.
> But I still do not see in what way this whole stuff is on topic in this
> thread? (Maybe asking this question in comp.lang.python is more
> appropriate...)
You know...It's annoying to bother justifying this to you. But
despite finding you to be pestilent, I'm gonna answer you.
I did indeed start responding to this thread, and was gonna say
something completely different, more in-line with the original thread.
But somehow, for whatever reason, this thread led me into something
I've been thinking about for months (Jython). So, since FOR ME it was
THIS THREAD that led me into that direction (and again, I'm sorry I
can't justify it to the comp.lang.lisp police -- i.e. you), I figured
that changing the subject was sufficient so that people could read the
subject, and if they're not interested in it, or in the author, then
just move past it.
dave
·····@alum.mit.edu (Dave Bakhash) writes:
> Method combination is another feature that's very specific to CLOS,
> and I would argue that 99% of programs don't use it, and of the 1%
> that do, at least half are probably using it wrong (or just using it
> for the sake of saying they're using a non-standard method
> combination).
I have no idea how many programs use or don't use method combinations
other than standard-method-combination, but I really disagree with
your characterization of it as a needless feature that once in a blue
moon someone can find /any/ use for.
Since I posted a couple weeks ago wondering if "Aspect-Oriented
Programming" was anything but hype, some people have pointed me to
informative things to read on the subject. And it's not just hype,
it's really useful. In Lisp, we spell it "refactoring". But in Java,
you can't refactor everything that you can in Lisp, the language
doesn't give you the facilities. CL-style conditions and macros are a
large part of the reason we can factor things that you can't in Java,
but method combinations are another tool that really help us factor
out "Aspects". Gregor Kiczales et al. are trying to bring this power
to users of mainstream languages; I think it'd be a big step backwards
to move from a language without the facilities you need to refactor
"Aspects".
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
hey,
···@hailstorm.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@hailstorm.OCF.Berkeley.EDU>...
> ·····@alum.mit.edu (Dave Bakhash) writes:
>
> > Method combination is another feature that's very specific to CLOS,
> > and I would argue that 99% of programs don't use it, and of the 1%
> > that do, at least half are probably using it wrong (or just using it
> > for the sake of saying they're using a non-standard method
> > combination).
>
> I have no idea how many programs use or don't use method combinations
> other than standard-method-combination, but I really disagree with
> your characterization of it as a needless feature that once in a blue
> moon someone can find /any/ use for.
That's _not_ what I said. What I said was that it's not so often
necessary. I do love having it, and a couple of times in my life have
actually used it. But it's rarely necessary to require something
other than standard method combination. It's nice, of course, if your
style is to immediately figure out how method combination could be
used in everything you write. But then, your programs would be
confusing to most other programmers, since not everyone has such a
strong grip on this particular aspect of programming.
It is in no way a needless feature. In fact, the programmable
construction of functional behavior from multiple methods specialized
on one or more argument types is definately one of my favorite aspects
of CLOS. But just how much the vast majority of CL programmers, and
programs, use it? Not that much. A gray area might be when we use
another's code (e.g. vendor code) which was implemented in CL, and
which uses it. It's hard to gauge.
dave
·····@alum.mit.edu (Dave Bakhash) writes:
> hey,
>
> ···@hailstorm.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@hailstorm.OCF.Berkeley.EDU>...
> > ·····@alum.mit.edu (Dave Bakhash) writes:
> >
> > > Method combination is another feature that's very specific to CLOS,
> > > and I would argue that 99% of programs don't use it, and of the 1%
> > > that do, at least half are probably using it wrong (or just using it
> > > for the sake of saying they're using a non-standard method
> > > combination).
> >
> > I have no idea how many programs use or don't use method combinations
> > other than standard-method-combination, but I really disagree with
> > your characterization of it as a needless feature that once in a blue
> > moon someone can find /any/ use for.
>
> That's _not_ what I said.
No it's not, what you said was "... and of the 1% that do [use method
combination], at least half are probably using wrong ...". I think
it's fair to say that's characterizing method combination as
needless/dangerous. After all, if it's useful in .5% of programs, and
an equal number misuse it, that sounds like a bad thing. It's misused
as often as it's used, which is rarely. And in the context of "what's
missing in Python", I think that's definately the implication of that
statement.
> What I said was that it's not so often necessary. I do love having
> it, and a couple of times in my life have actually used it.
This sounds analagous to saying "I do love Lisp, I never use it."
> But it's rarely necessary to require something other than standard
> method combination. It's nice, of course, if your style is to
> immediately figure out how method combination could be used in
> everything you write. But then, your programs would be confusing to
> most other programmers, since not everyone has such a strong grip on
> this particular aspect of programming.
It's true that not everyone has a good grip on how to use method
combinations, but everyone should be able to figure it out pretty
easily, if they've managed to get a handle on CLOS so far. After all,
its semantics are rather different than mainstream object systems
already.
To the extent that a lot of people probably don't make use of
non-standard method combinations, Common Lisp'ers don't write a huge
amount of OOP code and don't refactor very much. Of course some
people /do/ write OOP code, and some people do go back over their code
and refactor what they can, but you'll only find method combinations
used by those who do both. And the thing about refactoring is that
you /don't/ leave a lot of evidence when you're done. That's kind of
the point. You have to see the tangled code to understand how
important it is to have that /one/ method with
my-funky-method-combination or to put that functionality in a mixin,
or have that iteration GF, or whatever.
> It is in no way a needless feature. In fact, the programmable
> construction of functional behavior from multiple methods specialized
> on one or more argument types is definately one of my favorite aspects
> of CLOS. But just how much the vast majority of CL programmers, and
> programs, use it? Not that much.
Maybe, but we're losing context here. In the context of "what would
you lose by moving to Python," I'd say "Object Oriented Programming,
and the ability to properly refactor code." I don't have any Python
experience, but I find the thought of using an object system without
multimethods and method combinations, well, depressing. I'd probably
just ditch OOP for the most part in that language. I'd need to hear
really good arguments about why, in the context of this particular
object system, you're not losing much, in order to believe it wasn't a
huge practical step down. So, saying "that's peculiar to CLOS"
doesn't cut it for me :)
> A gray area might be when we use another's code (e.g. vendor code)
> which was implemented in CL, and which uses it. It's hard to gauge.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
> No it's not, what you said was "... and of the 1% that do [use method
> combination], at least half are probably using wrong ...". I think
> it's fair to say that's characterizing method combination as
> needless/dangerous. After all, if it's useful in .5% of programs, and
> an equal number misuse it, that sounds like a bad thing. It's misused
> as often as it's used, which is rarely. And in the context of "what's
> missing in Python", I think that's definately the implication of that
> statement.
Again, this is your own way of interpreting these numbers.
Common Lisp as a language does not push programmers into using OO
style the way Java does. I've read many large programs that don't use
CLOS. Of the ones that do, the vast majority do not require a
non-standard method combination, and often there's not a single gf
that is specialized on more than one argument. Corba interfaces in
CL are a good example of this, as well as good examples of how CL can
(through macros) be made to deal with a different set of constraints
and semantics.
When programming is solving a general purpose problem, such as
"develop a system to find `optimal' flight itineraries, given
different cost functions", people immediately think to the most
difficult aspects of the overall problem, and if they know CL, then
they'll probably want to use CL more than anything else to do it.
However, often we have specific problems, such as interfacing with
LDAP, and we end up searching for libraries.
Jython seems to take the approach that:
1) Python is a portable, flexible, dynamic language that can handle
the
full range of programming goals, as well as swallowing another
language whole, (e.g. C++, Java via CPython, JPython, Jython...)
2) Java and its accompanying libraries contain a rich set of
functionality
and standardization (if you consider Sun's standard as such)
3) Compilation to JVM bytecodes makes for the smoothest integration,
and
provides additional leverage of disproportionate Java compiler
improvement.
Since this post, I've noticed a task on the Clisp project page at
Sourceforge called "JVM compilation". This is probably a start toward
letting CL in on Java functionality. I'm sure that Python's libraries
and Java's libraries overlap heavily, and in such situations, I'm not
sure what programmers do, quite frankly. I'd like to find out how
that works.
> > What I said was that it's not so often necessary. I do love having
> > it, and a couple of times in my life have actually used it.
>
> This sounds analagous to saying "I do love Lisp, I never use it."
The couple of times, it's seemed like a big win. I just use it
sparringly, because I think of it as a serious powertool, and one that
comes with consequences. So what I _actually_ said was "I do love
..., though I _hardly_ ever use it." I also made a reference to using
tools that are build upon method combination, this being a gray area
of ``using'' method combination. Anyway, I don't care to focus on
this feature for the whole thread, or any feature for that matter. I
care more about the direction of CL, and esp. with respect to Java,
since there's quite a bit of functionality in the Java libraries. So,
since people here seem to be on the defensive, let me rename the
subject header. I don't care to compare as much as I care to improve
CL, and the direction of CL.
> Maybe, but we're losing context here. In the context of "what would
> you lose by moving to Python," I'd say "Object Oriented Programming,
> and the ability to properly refactor code." I don't have any Python
> experience, but I find the thought of using an object system without
> multimethods and method combinations, well, depressing.
It's hardly a reason to get depressed over. Trying to fit everything
into CL's CLOS/MOP, and getting depressed when things arn't arn't your
way, would probably make you too myopic to really add very much to
this thread, where I'm trying to say "Something non-CL has done
something interesting..." and you're getting depressed over a detail,
saying "these non-CL things that lack certain features found in CL
make me depressed". Maybe we should fork this thread, one trying to
figure out what might be issues, consequences, and strategies for
leveraging Java, and the other talking about how depressing it is to
work with languages that lack certain features.
On that note, since CL's syntax is so flexible, I think that JVM
compilation, along with some macros, could probably lead to a nice
addition to any CL system. I'm interested in hearing more ideas.
dave
·····@alum.mit.edu (Dave Bakhash) wrote in message news:<····························@posting.google.com>...
> On that note, since CL's syntax is so flexible, I think that JVM
> compilation, along with some macros, could probably lead to a nice
> addition to any CL system. I'm interested in hearing more ideas.
Well, I'm not sure what syntax has to do with JVM compilation.
The significant benefit that JVM (or another p-code system) gives is a
portable binary transport layer.
This is useful if you are running though an interpreter and do not
want to keep a compiler at the other end. The other 'use' for this is
to obfuscate code somewhat to make ripping it off harder, although JVM
disassemblers have shown that this goal is not well realised.
For lisp systems, using compressed source code is probably a better
solution.
However, CL doesn't support mobile code very well at the moment, and
improvements in this direction would be very welcome, imho.
Regards,
Brian.
·····@designix.com.au (Brian Spilsbury) writes:
> ·····@alum.mit.edu (Dave Bakhash) wrote:
>
> > On that note, since CL's syntax is so flexible, I think that JVM
> > compilation, along with some macros, could probably lead to a nice
> > addition to any CL system. I'm interested in hearing more ideas.
>
> Well, I'm not sure what syntax has to do with JVM compilation.
What I meant was that CL is syntactically flexible, and therefore able
to provide a way in most cases to be programmed to do things just like
this. Search for infix.lisp, as well as some of the declarative
programming interfaces done in CL. There are many examples of this.
dave
·····@alum.mit.edu (Dave Bakhash) writes:
> hey,
>
> ···@hailstorm.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@hailstorm.OCF.Berkeley.EDU>...
> > ·····@alum.mit.edu (Dave Bakhash) writes:
> >
> > > Method combination is another feature that's very specific to CLOS,
> > > and I would argue that 99% of programs don't use it, and of the 1%
> > > that do, at least half are probably using it wrong (or just using it
> > > for the sake of saying they're using a non-standard method
> > > combination).
> >
> > I have no idea how many programs use or don't use method combinations
> > other than standard-method-combination, but I really disagree with
> > your characterization of it as a needless feature that once in a blue
> > moon someone can find /any/ use for.
>
> That's _not_ what I said. What I said was that it's not so often
> necessary.
Just as an aside, I've learned to distrust the word "often" in contexts
like this because it's too vague.
Often as in "how many times I write it"?
Often as in "what proportion of executable code contains a reference"?
Often as in "what percentage of executing programs pass through it"?
Often as in "what percentage of time is spent in such a thing"?
The reason I raise this is that a major release of Symbolics Genera
was going out at one point years ago and on the day before it did, I
discovered a bug in special bindings wherein ((lambda (*foo*) *foo*)
1) did not work. That is, a lambda combination did not do a special
bind right. I was told by some people that lambda combinations were
not used very "often", and that the release should go ahead. I
managed to fuss enough to get them to hold it up (to the great
irritation of some business people) because it offended my sensibilities
that a Lisp Machine should have a broken LAMBDA... But the use of the
word "often" in the context of this story is what has led me to see
oftenness in a different way.
This may or may not be relevant to the conversation ongoing.
Hello!
In article <····························@posting.google.com>,
Dave Bakhash <·····@alum.mit.edu> wrote:
>[...]
>actually used it. But it's rarely necessary to require something
>other than standard method combination.
Might well be. However even standard method combination offers
much more than other object systems offer, incl. Python's, or
Java's or that of C++.
>[...]
Kind regards,
Hannah.
Dave Bakhash wrote:
> Method combination is another feature that's very specific to CLOS,
> and I would argue that 99% of programs don't use it, and of the 1%
> that do, at least half are probably using it wrong (or just using it
> for the sake of saying they're using a non-standard method
> combination).
Not really.
One example - I was doing an optimization system. I wanted users to
construct optimizations simply. One of the trickier areas was optimization
terminations. You can decide to terminate an optimization on many criteria
- timeout, failure to progress, "good enough" solution found, etc., or a
combination of these items. To implement this in CLOS, I used a base
class, termination-check that had a single generic function,
evaluate. I called this function at the end of each optimization
iteration. To be able to combine these tests, I used a custom method
combination that passed the boolean results of all of the termination
checks to either an 'or' or 'and' function, depending on yet another
parameter` (passed in the make-instance call for the optimization). This
allowed the user to inherit any number of these terminator checks and
combine them with either an 'and' or 'or' semantic. Total number of lines
of code? About 5 for the base class and about 2-3 for each termination
subclass. Add in another 3 or 4 for the combination code and it was done.
All the user had to do was do the equivalent of (defcalss
my-simulation-class (simulation-type termination1 termination2 ,,,)),
followed by a make instance, passing the termination combination as a
parameter (and even this was macroed over so he only needed a single defsim
call).
When I think about what this would take in Python and/or Java, I shudder.
Each user would have to write a custom termination method or you'd have to
have some sort of termination registry. All-in-all, it would take a heck
of a lot more LOC, too. This is one of the many places that CLOS,
multimethods and method combinations help. The point is that you don't
understand the usefulness of these mechanisms until you do enough work in
them to really think about objects in a manner that surpasses the feeble
object models of Python, Java, and even Smalltalk.
The problem is that you really have to think differently to understand
this. That's one of the advantages of Lisp - it causes you to think
differently about almost every aspect of programming. And that's also one
of the disadvantages leading to Lisp's lack of popularity among the hoi
polloi - how do you explain a rainbow to a blind man?
faa
hey,
"Frank A. Adrian" <·······@ancar.org> wrote in message news:<·····················@news.uswest.net>...
> Dave Bakhash wrote:
>
> > Method combination is another feature that's very specific to CLOS,
> > and I would argue that 99% of programs don't use it, and of the 1%
> > that do, at least half are probably using it wrong (or just using it
> > for the sake of saying they're using a non-standard method
> > combination).
>
> Not really.
>
> One example - I was doing an optimization system. I wanted users to
> construct optimizations simply. One of the trickier areas was optimization
> terminations. You can decide to terminate an optimization on many criteria
> - timeout, failure to progress, "good enough" solution found, etc., or a
> combination of these items.
I appreciate your testimony of an application of method combination.
I personally endorse using method combination in situations where you
want define a function based on all of the information about the
arguments.
Let's take a scenario where we use not only method combination, but
multi-methods. Then you have:
(define-method-combination optimization-combination ...)
(defgeneric optimize (x y)
(:method-combination optimization-combination)
...)
If it's clear that your OPTIMIZE function wants to see the complete
class graph of X and Y, and the corresponding methods defined on those
class combinations, then all the power to you; you have demonstrated a
capability that CL has for an interesting and unique situation.
Bravo! (I'm clapping for you.)
What about the situation of needing an LDAP interface? Try
implementing a (Tight)VNC viewer in CL. Do you know what you're up
against?
dave
hey,
> One example - I was doing an optimization system. I wanted users to
> construct optimizations simply. One of the trickier areas was
> optimization terminations. You can decide to terminate an
> optimization on many criteria - timeout, failure to progress, "good
> enough" solution found, etc., or a combination of these items.
thinking more about this whole thread, I think what I'm really driving
at is this:
There's no doubt that CL is great, and that its features are excellent,
and ability to conform to problems, to itself be programmable...and
indeed CLOS and MOP and all the features therein are excellent. I don't
want to discuss just how valuable these features are, or if the lack of
these features in, say, Java or Python, is a serious weakness...I am
interested in using whatever CL has to offer to allow CL to leverage
what has been done elsewhere, and I feel that perhaps the best example
of this is Jython.
I didn't mean to disparage any case stating that CL is great; I just
don't want to focus on exalting CL, but to be productive in this thread,
I figured that we would have to accept and pick apart the shortcomings
in CL in order to address them. I believe that they can be addressed,
of course, but that just _how_ that is...should be discussed.
dave
·····@alum.mit.edu (Dave Bakhash) writes:
> Method combination is another feature that's very specific to CLOS,
And, funnily enough, probably one of the easier missing features from
the posted list to emulate in Python (>=2.2 any way)...
Cheers,
M.
--
In case you're not a computer person, I should probably point out
that "Real Soon Now" is a technical term meaning "sometime before
the heat-death of the universe, maybe".
-- Scott Fahlman <···@cs.cmu.edu>
Hi,
I don't use Franz/ACL, but I noted from another thread (also about Java
integration with CL) the following option, now provided by Franz:
=========================================
- JiL:
http://www.franz.com/support/documentation/6.1/doc/jil.htm
which is a CL-like language for writing programs that run on a JVM.
=========================================
I read the document, and would be interested if other have used JiL to
hear how it went, and how different the JiL approach is to the Jython
approach.
dave
From: Alain Picard
Subject: Re: Impressing colleagues with Lisp - looking for stories from the trenches
Date:
Message-ID: <867kml760s.fsf@gondolin.local.net>
I guess like many of the other stories here, mine depends
on the ability to patch live images.
I've been writing this system which interfaces web pages
running ASP which calls VB functionality (actually coded
in C++ and linked into IIS via a DLL) which talks CORBA
to our lisp server.
When we decided to make a change to the IDL, and just
typed (load-server), redefined the new function, hit
C-M-x. The guy at the other desk had to recompile
the C++ world, and _stop_ IIS because there's no way
to unlink/relink the DLL.
He agreed Lisp has certain advantages. :-)
[He's now a reasonably competent lisp programmer, btw]
As a new Lisp user, I found the single most persuasive example to be
the story by Paul Graham, "Beating the Averages"
http://www.paulgraham.com/avg.html
It seems to me that a lot of the perceptions and arguments surrounding
Lisp are out-of-date. This article is successful in explaining the
merits of Lisp in a much more contemporary context - developing
software for an web startup. It does so in a way that is
understandable to Java-fans who aren't that aware of how the same
problems can be solved using a language like Lisp.
Even more convincing are the trivia/urban-legends around ViaWeb that
Paul Graham didn't mention: that it was sold to Yahoo for $49 million
and was the work of 3 programmers, and that during negotiations with
Yahoo!, they hired a dozen programmers so that the company wouldn't
get too suspicious. These are exactly the arguments that appeal to
Linux/Java weenies like me.
Blub
I love it.
-Earl