Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Lisp development not using emacs.

6 views
Skip to first unread message

Peter Seibel

unread,
Apr 7, 2003, 2:10:24 AM4/7/03
to
Hi, I'm curious how folks who don't who *don't* use emacs for their
Lisp development work. Not as in, how on earth? but as in, I'm
interested in more details. I'm particularly interested in
alternatives that might be palatable to folks on Unix (including Linux
and OS X) and/or Windows who, for whatever reason don't want to use
Emacs.

What's do people would be the quickest path for, say a experienced vi
user, new to Lisp to get up an running? Is there anything like ILISP
for vi?

I ask because I'm writing some materials aimed at new Lisp programmers
and I'm trying to avoid having to say that step one on the way to
becoming a Lisp programmer is "Install Emacs and learn how to use it."

-Peter

--
Peter Seibel pe...@javamonkey.com

The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra

Espen Vestre

unread,
Apr 7, 2003, 3:06:42 AM4/7/03
to
Peter Seibel <pe...@javamonkey.com> writes:

> Hi, I'm curious how folks who don't who *don't* use emacs for their
> Lisp development work.

if you mean emacs as in 'gnu emacs' or 'xemacs', there are quite a few
programmers who don't use emacs for their lisp development work. I use
the LispWorks editor. When I occasionally work in MCL, I use its
built-in editor FRED (but both of these are of course 'emacs family'
editors).
--
(espen)

Peter Seibel

unread,
Apr 7, 2003, 4:36:50 AM4/7/03
to
Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes:

Right. I guess I don't need the details of the integrated
editors--they are what they are and are presumably documented by the
vendors. (And they may well be a good solution for someone who's used
to programming in an IDE in whatever language they used before Lisp.)

I'm mostly stuck on what to tell the hard-core vi user. I seem to
recall some folks in this group talking about using vi for Lisp
development but my googling isn't turning up anything about how they
do it.

Espen Vestre

unread,
Apr 7, 2003, 4:44:45 AM4/7/03
to
Peter Seibel <pe...@javamonkey.com> writes:

> I'm mostly stuck on what to tell the hard-core vi user.

Hmm. Will the hard-core vi user ever catch the good vibrations
of CL ;-)? (I remember a comment from one hacker: What? Are you
using emacs? I thought you were a unix guy?)

Seriously: Would it help to provide them with vi emulation in emacs
(e.g. viper)?
--
(espen)

Peter Seibel

unread,
Apr 7, 2003, 4:46:44 AM4/7/03
to
Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes:

That'll probably help the vi'er who just doesn't know any better. ;-)
But not the hard core vi'er. And it doesn't really save the having to
figure out how to install emacs and get it running and into vi mode.
But it's definitely a good suggestion for some folks. Thanks.

Espen Vestre

unread,
Apr 7, 2003, 4:51:05 AM4/7/03
to
Peter Seibel <pe...@javamonkey.com> writes:

> But not the hard core vi'er.

The hard core vi'er needs an attitude adjustment tool. Emacs is an
excellent such tool ;-)
--
(espen)

John R. Strohm

unread,
Apr 7, 2003, 6:21:11 AM4/7/03
to

"Peter Seibel" <pe...@javamonkey.com> wrote in message
news:m3u1dae...@javamonkey.com...

> Hi, I'm curious how folks who don't who *don't* use emacs for their
> Lisp development work. Not as in, how on earth? but as in, I'm
> interested in more details. I'm particularly interested in
> alternatives that might be palatable to folks on Unix (including Linux
> and OS X) and/or Windows who, for whatever reason don't want to use
> Emacs.
>
> What's do people would be the quickest path for, say a experienced vi
> user, new to Lisp to get up an running? Is there anything like ILISP
> for vi?
>
> I ask because I'm writing some materials aimed at new Lisp programmers
> and I'm trying to avoid having to say that step one on the way to
> becoming a Lisp programmer is "Install Emacs and learn how to use it."

There were LOTS of places that did LISP in the early days that didn't do
emacs.

UT Austin maintained a LISP for the Control Data 60-bit supercomputers.
emacs didn't run on a 6600 (to put it mildly).

I got my start in LISP using punched cards. So did a lot of people. My
first serious exposure to emacs was actually to Zmacs on a Symbolics. I
used it at novice level, which was good enough to do basic editing, and to
go browsing three hours down into Symbolic source code when I was chasing a
networking problem one night.


Rudi Schlatte

unread,
Apr 7, 2003, 6:44:05 AM4/7/03
to
Peter Seibel <pe...@javamonkey.com> writes:

> I'm mostly stuck on what to tell the hard-core vi user. I seem to
> recall some folks in this group talking about using vi for Lisp
> development but my googling isn't turning up anything about how they
> do it.

Google for vilisp, then ;)

Rudi
--
whois DRS1020334-NICAT http://constantly.at/pubkey.gpg.asc
Key fingerprint = C182 F738 6B9A 83AF 9C25 62D9 EFAE 45A6 9A69 0867

Peter Seibel

unread,
Apr 7, 2003, 7:20:11 AM4/7/03
to
Rudi Schlatte <rsch...@ist.tu-graz.ac.at> writes:

> Peter Seibel <pe...@javamonkey.com> writes:
>
> > I'm mostly stuck on what to tell the hard-core vi user. I seem to
> > recall some folks in this group talking about using vi for Lisp
> > development but my googling isn't turning up anything about how they
> > do it.
>
> Google for vilisp, then ;)

Ah. Great. Thanks.

-Peter

P.S. I had this wacky idea the other day while thinking about the
periodic "let's rewrite emacs in Common Lisp" thread: it seems like
the nvi guys figured out how to embed both Perl and Python (IIRC) into
nvi. Maybe the hard-core vi'ers can steal a march on us emacs users by
hacking one of the modern vi's to use some Common Lisp as an extension
language. Heh. Combine that with the evil paperclip vi hack and you
might have the world's scariest editor.

Daniel Barlow

unread,
Apr 7, 2003, 6:45:55 AM4/7/03
to
Peter Seibel <pe...@javamonkey.com> writes:

> I'm mostly stuck on what to tell the hard-core vi user. I seem to
> recall some folks in this group talking about using vi for Lisp
> development but my googling isn't turning up anything about how they
> do it.

You might want to point them at http://www.lisp-p.org/htdocs/15-vim/

Lisp with Vim
by Larry Clapp
Tuesday, 9 April 2002
"This article assumes some familiarity with Vim, but mentions some
points anyway (like the "%" key, and how to get help). I should also
mention that, while I'm not new to Vim or programming in general, I am
new to Lisp. Caveat reader."


-dan

--

http://www.cliki.net/ - Link farm for free CL-on-Unix resources

Dorai Sitaram

unread,
Apr 7, 2003, 9:21:10 AM4/7/03
to
In article <m3u1dae...@javamonkey.com>,

Peter Seibel <pe...@javamonkey.com> wrote:
>Hi, I'm curious how folks who don't who *don't* use emacs for their
>Lisp development work. Not as in, how on earth? but as in, I'm
>interested in more details. I'm particularly interested in
>alternatives that might be palatable to folks on Unix (including Linux
>and OS X) and/or Windows who, for whatever reason don't want to use
>Emacs.
>
>What's do people would be the quickest path for, say a experienced vi
>user, new to Lisp to get up an running? Is there anything like ILISP
>for vi?
>
>I ask because I'm writing some materials aimed at new Lisp programmers
>and I'm trying to avoid having to say that step one on the way to
>becoming a Lisp programmer is "Install Emacs and learn how to use it."

For a few years now I have been doing all my lisp
editing with vi(m). I used emacs for a long
time before that (longer than I have vi), so I actually
know what I'm missing. :-) I have a couple of pages on
lisp editing, with both vim and "classic" vi, at
http://www.ccs.neu.edu/~dorai.

Essentially, there are some vim options that you can
set for lisp editing, e.g., 'lisp', 'autoindent',
'comments', 'isident', 'iskeyword'. A vim user
will know how to have these automatically set based on
identifying that the file contains lisp code.

The one thing missing is the interactive lisp shell of
emacs; but here too, Larry Clapp (quod google) has
written vim and perl scripts for communicating between
vim and a lisp (maybe only CMUCL) process. I remember
not being able to get it to work, but then I admit I
have happily regressed to a more textual attitude
toward code since my emacs days, and thus found I
didn't really miss the lisp-repl-within-the-editor, and
so very likely didn't try hard enough.

Mario S. Mommer

unread,
Apr 7, 2003, 10:09:49 AM4/7/03
to

Peter Seibel <pe...@javamonkey.com> writes:
> Hi, I'm curious how folks who don't who *don't* use emacs for their
> Lisp development work. Not as in, how on earth? but as in, I'm
> interested in more details. I'm particularly interested in
> alternatives that might be palatable to folks on Unix (including Linux
> and OS X) and/or Windows who, for whatever reason don't want to use
> Emacs.

How about Jabberwocky?

http://jabberwocky.sourceforge.net/

Mario.

Christopher C. Stacy

unread,
Apr 7, 2003, 12:55:41 PM4/7/03
to
>>>>> On Mon, 07 Apr 2003 08:36:50 GMT, Peter Seibel ("Peter") writes:

Peter> I'm mostly stuck on what to tell the hard-core vi user. I seem
Peter> to recall some folks in this group talking about using vi for
Peter> Lisp development but my googling isn't turning up anything
Peter> about how they do it.

In recent experiments, it's taken me about 45 minutes to teach
enough Emacs a not-widely-experienced person who knows only vi,
such that they could type in a Lisp program and compile it.

You could also consider using the "vi" emulation mode in Emacs.

But just showing them the Lisp editing mode in Emacs ought
to convince them. This is best done in person.

If they're not willing to learn enough Emacs (about 10 commands)
to see if they like using it for Lisp, are they likely to want
to put in enough effort to learn Lisp?

Erann Gat

unread,
Apr 7, 2003, 1:50:01 PM4/7/03
to
In article <uu1dan...@dtpq.com>, cst...@dtpq.com (Christopher C.
Stacy) wrote:

> If they're not willing to learn enough Emacs (about 10 commands)
> to see if they like using it for Lisp, are they likely to want
> to put in enough effort to learn Lisp?

Exactly.

<imo>

Lisp is more than just a programming language, it is a gateway to a
completely different mindset about what programming *is*, even to a
completely different mindset about what interacting with computers ought
to be like, to the point where even the term "programming" can start to be
no longer well defined.

What make's Lisp cool is that it breaks down artificial barriers that the
"traditional" programming community has erected for itself.
Traditionally, there are strong distinctions between "code" and "data",
between "programming" and "using a computer", between an editor, a
compiler, and a debugger. Lisp breaks down these barriers, starting with
the distinction between "code" and "data", then between "compiler" and
"debugger", and finally, in many cases, between "programming" and "using a
computer".

Because of this, Lisp does not play well in the traditional structure.
This is at once its greatest strengh and its greatest weakness. The
consequences of not realizing this -- on both sides of the
misunderstanding -- are evident again and again in discussions on c.l.l.
(Most recently the thread on "command line arguments" is about precisely
this confusion.)

So I would say you can't learn Lisp without learning emacs, or to be more
precise, if you're a C programmer, part of learning Lisp is learning a new
editor (or new capabilities of your old editor) so that you can experience
the dissolution of the barriers between "writing code" and "compiling"
that is part and parcel using Lisp. If you are not willing to do this
then you may as well not even bother because all that will happen is
you'll get very frustrated and become just another member of the
well-Lisp-would-be-OK-if-only-they-could-get-rid-of-those-awful-parentheses
crowd.

</imo>

E.

--
The opinions expressed here are my own and do not necessarily
reflect the views of JPL or NASA.

Simon H.

unread,
Apr 7, 2003, 2:54:16 PM4/7/03
to
Peter Seibel <pe...@javamonkey.com> wrote in message news:<m3llyme...@javamonkey.com>...

> Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes:
>
> > Peter Seibel <pe...@javamonkey.com> writes:
> >
> > > I'm mostly stuck on what to tell the hard-core vi user.
> >
> > Hmm. Will the hard-core vi user ever catch the good vibrations
> > of CL ;-)? (I remember a comment from one hacker: What? Are you
> > using emacs? I thought you were a unix guy?)
> >
> > Seriously: Would it help to provide them with vi emulation in emacs
> > (e.g. viper)?
>
> That'll probably help the vi'er who just doesn't know any better. ;-)
> But not the hard core vi'er.

Speaking as a hard-core Vim user... The syntax highlighting for Vim
is better and easier to use than for the emacsen I've used. :-P

Seriously, I don't see what the problem is. You save the file you're
working and type (load "myfile.lsp") before trying the program again.
If you're using clisp that amounts to 7 keystrokes.

Peter Seibel

unread,
Apr 7, 2003, 3:50:50 PM4/7/03
to
she...@mail.com (Simon H.) writes:

Okay. That was the bit that I was missing--when working in emacs I
more often send expressions to Lisp onsey-twosey; i.e. not load the
whole file, just because one definition changed. I didn't know if
there was a way to do that in vi or if folks just used (load
"file.lisp") to grab new definitions. It seems the answer is both:
Larry Clapp's vilisp scripts for vim let's you do things in more
'emacsy' way while you're not the only person who's told me they just
use LOAD. Thanks.

Eduardo Muñoz

unread,
Apr 7, 2003, 4:43:04 PM4/7/03
to
Peter Seibel <pe...@javamonkey.com> writes:

> she...@mail.com (Simon H.) writes:
> > Seriously, I don't see what the problem is. You save the file you're
> > working and type (load "myfile.lsp") before trying the program
> > again. If you're using clisp that amounts to 7 keystrokes.
>
> Okay. That was the bit that I was missing--when working in emacs I
> more often send expressions to Lisp onsey-twosey; i.e. not load the
> whole file, just because one definition changed. I didn't know if
> there was a way to do that in vi or if folks just used (load
> "file.lisp") to grab new definitions. It seems the answer is both:
> Larry Clapp's vilisp scripts for vim let's you do things in more
> 'emacsy' way while you're not the only person who's told me they just
> use LOAD. Thanks.


But the file may be in an inconsistent state (read
unloadable) or take a fair amount of time to load, or to
compile if you want compiled functions.
With emacs you can compile a single function definition into
an image with only two keystrokes (I do it all the time with
my webserver :)


--

Eduardo Muñoz
http://213.97.131.125/

Chris Perkins

unread,
Apr 7, 2003, 5:45:20 PM4/7/03
to
Peter Seibel <pe...@javamonkey.com> wrote in message news:<m3u1dae...@javamonkey.com>...

> Hi, I'm curious how folks who don't who *don't* use emacs for their
> Lisp development work. Not as in, how on earth? but as in, I'm
> interested in more details.

I've always had the opposite question - why do people use emacs in the
first place? My seminal computer using experience is the Mac and I've
never been one for memorizing pathnames or complex C- M- commands.
I've downloaded and installed/uninstalled emacs twice and xemacs too,
and I've yet to see what people like about these packages.

As a Lisp programmer, I've scanned the ilisp documentation, and it
seems to have some nice functions for handling packages and multiple
file projects, but nothing compelling. Learning Lisp has been a big
enough undertaking without complicating it with emacs.

Perhaps if I was using CLISP or CMUCL I'd feel differently, but I'm on
Windows so I don't use them (OK - CLISP under Jabberwocky for
compatibility testing)

When using LispWorks, the IDE is great, I don't feel poor.
CormanLisp, on the other hand, is pretty bare bones. But it has a
nice tooltip feature that popups the arguments for any Lisp
function/macro as well as integration with the Hyperspec.

But lately, as I've working on bigger projects I've been more
concerned about maximizing my productivity. So I ask honestly (not a
troll), as a Windows Lisp developer, what does xemacs/emacs/ilisp
offer that makes it worth the learning curve?


Chris Perkins
Media Lab, Inc.

Matthew Danish

unread,
Apr 7, 2003, 7:24:24 PM4/7/03
to
On Mon, Apr 07, 2003 at 02:45:20PM -0700, Chris Perkins wrote:
> Peter Seibel <pe...@javamonkey.com> wrote in message
> news:<m3u1dae...@javamonkey.com>...
> > Hi, I'm curious how folks who don't who *don't* use emacs for their
> > Lisp development work. Not as in, how on earth? but as in, I'm
> > interested in more details.
>
> I've always had the opposite question - why do people use emacs in the
> first place? My seminal computer using experience is the Mac and I've
> never been one for memorizing pathnames or complex C- M- commands.
> I've downloaded and installed/uninstalled emacs twice and xemacs too,
> and I've yet to see what people like about these packages.

Don't know where you get ``memorizing pathnames'' from. The C-M-
commands aren't that complex... usually of the form C-M-f (forward
S-expr), C-M-b (back S-expr), C-M-k (kill S-expr) ...

I'll tell you why people use Emacs. First, automatic indentation is a
huge boon. Second, programmers hate to use the mouse; you must remove
your hands from the touch-typing position, orient them on the mouse,
hunt and click some portion of the screen, then replace your hands in
the correct position on the keyboard. Third, Emacs has been around for
so long that its been customized an incredible amount, and you can
obtain packages for everything.

I don't think Emacs is the best thing possible, but it beats most
run-of-the-mill editors out there.

> When using LispWorks, the IDE is great, I don't feel poor.

LispWorks's IDE is Emacs-like, with nicer graphical tools.

> CormanLisp, on the other hand, is pretty bare bones. But it has a
> nice tooltip feature that popups the arguments for any Lisp
> function/macro as well as integration with the Hyperspec.

But the rest of the IDE is unforgivable. And ILISP certainly offers
this very same feature (listing the arguments). I use it all the time.

> But lately, as I've working on bigger projects I've been more
> concerned about maximizing my productivity. So I ask honestly (not a
> troll), as a Windows Lisp developer, what does xemacs/emacs/ilisp
> offer that makes it worth the learning curve?

Over LispWorks? Nothing really (though M-( at least works properly in
Emacs, which is nice), unless you are also doing non-Lisp things. Over
nothing (ie notepad)? It's amazingly better.

--
; 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."

Vladimir S.

unread,
Apr 7, 2003, 9:49:44 PM4/7/03
to

In a thread* on lemonodor (John Wiseman's blog), it's mentioned that
Mike Hannemann has a Lisp plugin for Eclipse (the IDE that's popular
with the Java folks nowadays) almost ready to be released.

* - http://lemonodor.com/archives/000218.html#000218

Vladimir

Steven M. Haflich

unread,
Apr 7, 2003, 11:26:48 PM4/7/03
to
Simon H. wrote:

> Seriously, I don't see what the problem is. You save the file you're
> working and type (load "myfile.lsp") before trying the program again.
> If you're using clisp that amounts to 7 keystrokes.

Perhaps you don't see the benefits that can be provided by an editor
that has been customerized to know a little more about the target
programming language. Emacs-family editors can cooperate with the
running Lisp environment to provide extra tools, such as:

- argument lists.
- links to online documentation,
- macro expansion of forms (good for debugging both macro
implementations and macro invocations, such as loop forms).
- complete macroexpansion walks of forms, similar to above.
- automatic "find definition", either by tags files or source-file
recording by the implementation.
- "Who calls" listings, with the ability to visit all calls to a
function. or all references to a special variable.
- Ability to _undefine_ a definition. Otherwise, it is tricky or
tedious to remove (rather than _replace_) a method definition.

All these things go far beyond mere editing and reediting code.

Thaddeus L Olczyk

unread,
Apr 8, 2003, 12:45:08 AM4/8/03
to
On Mon, 07 Apr 2003 16:55:41 GMT, cst...@dtpq.com (Christopher C.
Stacy) wrote:

>In recent experiments, it's taken me about 45 minutes to teach
>enough Emacs a not-widely-experienced person who knows only vi,
>such that they could type in a Lisp program and compile it.
>
>You could also consider using the "vi" emulation mode in Emacs.
>
>But just showing them the Lisp editing mode in Emacs ought
>to convince them. This is best done in person.
>
>If they're not willing to learn enough Emacs (about 10 commands)
>to see if they like using it for Lisp, are they likely to want
>to put in enough effort to learn Lisp?

Potential Lisp programmer:
" So now I have to learn Emacs befor I can learn Lisp. Hmm. Only 45
minutes. Wait what's this? If I do it right I have to write a .emacs
in Lisp? What else am I going to have to learn? Worse, how am I
going to convince my coworkers?

"What I'm too lazy to learn Lisp, if I can't be bothered to learn
Emacs. OK fine. Guess I'll learn Python instead. The Python crowd
isn't going to make me waste my time learning a new editor when I
don't even know if I like the language."

Result: a programmer that blows off Lisp.
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.

Will Hartung

unread,
Apr 8, 2003, 12:53:03 AM4/8/03
to

"Erann Gat" <g...@jpl.nasa.gov> wrote in message
news:gat-070403...@k-137-79-50-101.jpl.nasa.gov...

> Lisp is more than just a programming language, it is a gateway to a
> completely different mindset about what programming *is*, even to a
> completely different mindset about what interacting with computers ought
> to be like, to the point where even the term "programming" can start to be
> no longer well defined.

And you know what? That whole "environment" part is the part that is pretty
much completely undocumented. Sure, there's a slew of EMACS commands, but I
have yet to see a "users guide" to using Lisp in the Lisp Way.

As another person noted, "it's best done if you show them".

I've never seen something like a walk through showing how all of this really
fits together. How it all fits so seemlessly, from code to compile to
debugger.

I've been playing with this stuff for several years. My most serious
projects were in Lispworks, and they pretty much never needed anything more
sophisticated than paren matching, auto-indent and compile buffer. I don't
even know the control or meta key sequence to compile a defun in Lispworks
or EMACS.

I almost never used the debugger beyond a quick traceback. I've never fixed
something on the fly, and let it continue running. (print ...) and Compile
Buffer are my friend.

My projects have never been large enough that I needed to delve into
defpackage, and I've yet to see a good solid guide on Good Lisp, Good
Packaging, Good Techniques.

"You can restart from the debugger!" Ever see a solid example of this
written down beyond a really toy example?

"You can load code dynamically!" But you never hear about how you might want
to structure your code to deal with that eventuality. What kind of
precautions need to be taken? How aware does the code need to be that it's
entire foundation can be yanked out and stuffed back in again? How do you do
that?

Maybe its because none of this stuff really comes to play at the "toy"
level. Perhaps it only matters when starting over is vastly more expensive
than fixing it in place, and my stuff has never reached that level.

I know enough emacs to get me through my day, but I rarely crack open my
~/.emacs file. All of my emacs translated pretty much seemlessly to
Lispworks, and that was swell. But unless I am truly stuck, I rarely have
need to get out into the more arcane areas of emacs. After using the silly
thing for 4 years, just last week I finally used EMerge. It was finally
necessary to make that leap and go down that potential black hole and
interpret "fact" as its documented vs "reality" as it's implemented. But I
still bounce back and forth between emacs and vi and Shell Stuff(tm) because
it's simply easier and faster for me to do that.

Lispworks has a bunch of apparently nice tools that I've never grokked. I
bet if I had my hands on an actual LispM, I still wouldn't use much more
than paren matching, auto indent, and compile buffer. And then I'd wonder
what all the hub bub was about.

There is a lot of folklore based knowledge in this community that doesn't
seem to translate well to text, as it's mostly experiential. I think that
the Lisp User Group should perhaps spend more time communicating in song and
poems to try and get the point across.

I can get thousands of pages of writing that will go into the inner details
of the language, but there is almost nothing on the environment.

"Well, the environment isn't portable!" Yeah, that's why they're all based
on emacs. Just dumb luck I guess.

Anyway, perhaps it's the wrong path but vi is fine for learning The Lisp
LANGUAGE.

Regards,

Will Hartung
(wi...@msoft.com)

Mario S. Mommer

unread,
Apr 8, 2003, 2:24:58 AM4/8/03
to
Thaddeus L Olczyk <olc...@interaccess.com> writes:
> Potential Lisp programmer:
> " So now I have to learn Emacs befor I can learn Lisp. Hmm. Only 45
> minutes. Wait what's this? If I do it right I have to write a .emacs
> in Lisp? What else am I going to have to learn? Worse, how am I
> going to convince my coworkers?
>
> "What I'm too lazy to learn Lisp, if I can't be bothered to learn
> Emacs. OK fine. Guess I'll learn Python instead. The Python crowd
> isn't going to make me waste my time learning a new editor when I
> don't even know if I like the language."
>
> Result: a programmer that blows off Lisp.

Good riddance.

Erann Gat

unread,
Apr 8, 2003, 3:04:47 AM4/8/03
to
In article <PAska.267$Hv2.24...@newssvr21.news.prodigy.com>, "Will
Hartung" <wi...@msoft.com> wrote:

> "Erann Gat" <g...@jpl.nasa.gov> wrote in message
> news:gat-070403...@k-137-79-50-101.jpl.nasa.gov...
> > Lisp is more than just a programming language, it is a gateway to a
> > completely different mindset about what programming *is*, even to a
> > completely different mindset about what interacting with computers ought
> > to be like, to the point where even the term "programming" can start to be
> > no longer well defined.
>
> And you know what? That whole "environment" part is the part that is pretty
> much completely undocumented. Sure, there's a slew of EMACS commands, but I
> have yet to see a "users guide" to using Lisp in the Lisp Way.

This is a valid point, but such a thing is incredibly hard to write.

> As another person noted, "it's best done if you show them".

And this is in fact true.

I have a little demo that I like to show people. It consists of a few
dozen lines of code in MCL. First, I define a class whose instances know
how to draw themselves in windows. Then I create an instance of this
class and it pops up in a window. You click on it an nothing happens.

Then I define a class called "draggable" that is a "mixin". It contains
methods for "dragging" an object in a window, and popping up an inspector
window if you double-click on an object.

I then redefine the original class to inherit from draggable. Voila!
Suddenly you can drag the instance that was created earlier. This
absolutely knocks people's socks off when they actually see it. The whole
demo takes literally thirty seconds, and no description can really do it
justice. It's a visceral, almost emotional thing, and you have to see it
because the *timing* is actually a crucial part of it. There is literally
no delay whatsoever between redefining the class inheritance structure and
being able to drag the thing around. Nothing happens that fast in the C
world (at least not at development time).

The emotional impact of this is somewhat tempered if you have to slog
through ten minutes of text to get from A to B.

What's really needed is some sort of interactive tutorial, but putting
something like that together is a nontrivial effort.

Bruce Hoult

unread,
Apr 8, 2003, 5:16:55 AM4/8/03
to
In article <7aj49vsa9q3q89deb...@4ax.com>,

Thaddeus L Olczyk <olc...@interaccess.com> wrote:

> Potential Lisp programmer:
> " So now I have to learn Emacs befor I can learn Lisp. Hmm. Only 45
> minutes. Wait what's this? If I do it right I have to write a .emacs
> in Lisp? What else am I going to have to learn? Worse, how am I
> going to convince my coworkers?
>
> "What I'm too lazy to learn Lisp, if I can't be bothered to learn
> Emacs. OK fine. Guess I'll learn Python instead. The Python crowd
> isn't going to make me waste my time learning a new editor when I
> don't even know if I like the language."
>
> Result: a programmer that blows off Lisp.

You must work somewhere quite different to where I do -- we're doing
basic C/C++/Java programming and the emacs users outnumber the vi users
by at least four to one (and all the machines are dual-boot and Linux
users outnumber Windows users by more like 10:1).

-- Bruce

Nils Goesche

unread,
Apr 8, 2003, 7:24:39 AM4/8/03
to
Matthew Danish <mda...@andrew.cmu.edu> writes:

Actually, M-( works fine in LispWorks, too; it's M-) that doesn't
work, or at least didn't in some earlier version. I still have

(editor:bind-key "Insert ()" #\[)
(editor:bind-key "Move Past Close And Reindent" #\])

in my .lispworks file, together with

(defcommand "Move Past Close And Reindent" (p)
"Move past next `)', delete indentation before it, then indent after it.
Prefix argument is ignored."
"Just like Emacs' M-), as God intended."
(declare (ignore p))
(let ((cpoint (current-point)))
(form-offset cpoint 1 t 1)
(forward-character-command -1)
(when (save-excursion
(let ((before-paren (copy-point cpoint :temporary)))
(back-to-indentation-command nil)
(point= cpoint before-paren)))
(beginning-of-line-command nil)
(delete-previous-character-command nil)
(delete-horizontal-space-command nil)))
(forward-character-command 1)
(new-line-command nil)
(indent-command nil))

so I am not sure whether they have fixed it by now.

Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x0655CFA0

Larry Clapp

unread,
Apr 8, 2003, 8:12:17 AM4/8/03
to
In article <m33ckue...@javamonkey.com>, Peter Seibel wrote:
> Rudi Schlatte <rsch...@ist.tu-graz.ac.at> writes:
>> Peter Seibel <pe...@javamonkey.com> writes:
>> > I'm mostly stuck on what to tell the hard-core vi user. I seem to
>> > recall some folks in this group talking about using vi for Lisp
>> > development but my googling isn't turning up anything about how
>> > they do it.
>>
>> Google for vilisp, then ;)

Thanks for the mention, Rudi!

> Ah. Great. Thanks.

Hi, Peter,

To you and anyone else reading: if you have any suggestions or
enhancement requests (or patches! :), please feel free to ask/submit
them.

See also my article "Lisp with Vim" at
http://www.lisp-p.org/htdocs/15-vim/index.html; hardly exhaustive, but
may prove useful, nonetheless.

--
Larry Clapp / la...@theclapp.org
Use Lisp from Vim: VILisp: http://vim.sourceforge.net/script.php?script_id=221


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

William Bland

unread,
Apr 8, 2003, 9:31:26 AM4/8/03
to
On Tue, 08 Apr 2003 00:04:47 +0000, Erann Gat wrote:

> In article <PAska.267$Hv2.24...@newssvr21.news.prodigy.com>, "Will
> Hartung" <wi...@msoft.com> wrote:
>
> I have a little demo that I like to show people.

[snip]

Do you have a webcam? I would love to see a video of you doing
this demo - it sounds very inspiring! I have successfully used my
webcam in the past for making videos of myself doing things on my
computer. It works well, even though my webcam is very cheap.

Best wishes,
Bill.

Paolo Amoroso

unread,
Apr 8, 2003, 9:38:59 AM4/8/03
to
On Tue, 08 Apr 2003 04:45:08 GMT, Thaddeus L Olczyk
<olc...@interaccess.com> wrote:

> Potential Lisp programmer:
> " So now I have to learn Emacs befor I can learn Lisp. Hmm. Only 45
> minutes. Wait what's this? If I do it right I have to write a .emacs
> in Lisp? What else am I going to have to learn? Worse, how am I
> going to convince my coworkers?

Lisp and its tools are not for dummies.

Potential astronaut:
"So now I have to learn orbital dynamics before I fly into space: Hmm. Only
a few years. Wait what's this? If I do it right I have to train with a
simulator? What else am I going to have to learn? Worse, how am I going to
convince my crewmembers?"


> "What I'm too lazy to learn Lisp, if I can't be bothered to learn
> Emacs. OK fine. Guess I'll learn Python instead. The Python crowd
> isn't going to make me waste my time learning a new editor when I
> don't even know if I like the language."
>
> Result: a programmer that blows off Lisp.

Given the above, it may not be such a bad thing that Lisp does not attract
dummies.

"What I'm too lazy to fly into space, if I can't be bothered to learn
orbital dynamics. OK fine. Guess I'll learn a space videogame instead. The
game crowd isn't going to make me waste my time learning orbital dynamics
when I don't even know if I like to fly into space."


Paolo
--
Paolo Amoroso <amo...@mclink.it>

Dorai Sitaram

unread,
Apr 8, 2003, 9:49:11 AM4/8/03
to
In article <pan.2003.04.08....@abstractnonsense.com>,

William Bland <ne...@abstractnonsense.com> wrote:
>I have successfully used my
>webcam in the past for making videos of myself doing things on my
>computer.

Uh, Bill, this is a family newsgroup.

Alan Shutko

unread,
Apr 8, 2003, 10:23:01 AM4/8/03
to
"Will Hartung" <wi...@msoft.com> writes:

> Maybe its because none of this stuff really comes to play at the "toy"
> level. Perhaps it only matters when starting over is vastly more expensive
> than fixing it in place, and my stuff has never reached that level.

That's probably part of it. Also, a big part of it is that some of
these features are "obviously" useful to most people who have done
large systems, because they've been bitten by the lack in other
languages in the past. I can think of a number of examples where I
wished I could have been able to load some code dynamically into a
process and restart it, because they were all long-running processes
(like running a billing monthend or converting a really large 3-d
model from one 3-d format to another) where the bug was, say, 7 hours
into a 12 hour process.

So I can see why a one set of the programming community would see
these features and think "I've got to have them" but another set
without experience with problems in lengthy processes would wonder
why it mattered. Unfortunately, it's hard to convey that experience
in a way that shows the impact.

--
Alan Shutko <a...@acm.org> - I am the rocks.
Looking for a developer in St. Louis? http://web.springies.com/~ats/
Def: Hardware: The part you kick.

Kent M Pitman

unread,
Apr 8, 2003, 10:51:05 AM4/8/03
to
Alan Shutko <a...@acm.org> writes:

> "Will Hartung" <wi...@msoft.com> writes:
>
> > Maybe its because none of this stuff really comes to play at the "toy"
> > level. Perhaps it only matters when starting over is vastly more expensive
> > than fixing it in place, and my stuff has never reached that level.
>
> That's probably part of it. Also, a big part of it is that some of
> these features are "obviously" useful to most people who have done
> large systems, because they've been bitten by the lack in other
> languages in the past. I can think of a number of examples where I
> wished I could have been able to load some code dynamically into a
> process and restart it, because they were all long-running processes
> (like running a billing monthend or converting a really large 3-d
> model from one 3-d format to another) where the bug was, say, 7 hours
> into a 12 hour process.
>
> So I can see why a one set of the programming community would see
> these features and think "I've got to have them" but another set
> without experience with problems in lengthy processes would wonder
> why it mattered. Unfortunately, it's hard to convey that experience
> in a way that shows the impact.

I dunno. Before I worked for Symbolics, I used to go to AI conferences
and hang out at their booth and try to sell the machines, just because
it was such fun. (A couple of times the Symbolics people paid for me
to go to the conference just so I could sit there and play on things
in their booth while people walked by because it showed favorably to have
people who knew the machine demo'ing it.) They outright cringed the first
time I was talking to someone and they said "Can you do such-and-so?" and
I said "I don't know. Never tried it. Let's see." Sales people hate
the unknown and (even moreso decades ago, but even now) fear something
will show badly. But the coolest thing about the LispM was that either
what the person wanted was going to work (and they'd be happy) or else we
could debug it (and then we'd show them how to debug). It took a while,
but eventually the sales people relaxed and stopped trying to talk me out
of doing untested things because this was one machine where it wasn't a
problem being in the debugger. It was enabling in so many ways. You could
get the data you wanted, fix the function, restart, and get out of there
fast. We later used to talk about the importance of speed not in the
read-eval-print loop (which the machine was executing) but in the
edit-compile-debug loop (which the person using the machine is executing).
You can see it even in small examples, but you probably do have to have
been trained--it may not be your impulse to do by accident.

Ng Pheng Siong

unread,
Apr 8, 2003, 11:19:22 AM4/8/03
to
According to Thaddeus L Olczyk <olc...@interaccess.com>:

> Result: a programmer that blows off Lisp.

The programmer's loss.

--
Ng Pheng Siong <ng...@netmemetic.com>

http://firewall.rulemaker.net -+- Manage Your Firewall Rulebase Changes
http://www.post1.com/home/ngps -+- Open Source Python Crypto & SSL

Chris Perkins

unread,
Apr 8, 2003, 12:09:01 PM4/8/03
to
Matthew Danish <mda...@andrew.cmu.edu> wrote in message news

[snip]

> Over LispWorks? Nothing really (though M-( at least works properly in
> Emacs, which is nice), unless you are also doing non-Lisp things. Over
> nothing (ie notepad)? It's amazingly better.


Thanks. It's good to hear that I'm not missing anything. As was
recently commented about Lisp, it is the collection of lots of little
things that make their sum greater than the whole. I was always
afraid that might be true of emacs as well, and thus my attempts to
use it.

But, I have no trouble with the mouse, I'm not using Unix, my Lisp
editors all have parenthesis matching, indenting, hyperspec
integration, etc. So I'll continue to avoid emacs unless anyone has a
really compelling story that'll intrigue me enough to download and
install it (again).

Thanks,

Chris

William Bland

unread,
Apr 8, 2003, 12:29:26 PM4/8/03
to

ROTFL!

I'm sure you all know what I meant ;-)

Cheers,
Bill.

Kaz Kylheku

unread,
Apr 8, 2003, 1:04:41 PM4/8/03
to
Peter Seibel <pe...@javamonkey.com> wrote in message news:<m3u1dae...@javamonkey.com>...
> Hi, I'm curious how folks who don't who *don't* use emacs for their
> Lisp development work.

I use the Vim editor exclusively. It has a weak Lisp mode that can
indent many things okay but sometimes requires manual help, because we
disagree about the identation for certain forms. For example, it gets
IF and LET right, but it wants to line up the body of a WHEN with the
expression, rather than just indent it. I could teach it to do the
right thing by tweaking its configuration files, but I haven't
bothered. The coloring of CL code, and flagging of excessive parens is
fairly good, but it does get confused by some lexical syntax.

If I need to evaluate something from the editor, I do it the same way
I have always done it for any language, such as the ``bc'' calculator.
I pipe a bunch of lines to a command, which get replaced by the output
of that command.

I cut my teeth on programming languages in which I was productive by
writing a mountain of code, compiling it, and only then running it. So
I don't require all that much interactivity. Sure do some REPL
experimenting, but I also do the ``write mountain of Lisp and run it''
thing. I usually combine both approaches: write a whole bunch of code
in the text editor, then load it into the Lisp image and test it
interactively.

On some projects, I do the full edit compile run cycle. E.g. when I'm
working on Meta-CVS, after a change I usually build the whole thing
and run it as a stanadalone application, exactly as I would do if it
were written in C. Except that the compiling and loading is a lot
quicker for a program of comparable size due to the lack of static
dependencies of anything on anything else, other than when macros are
changed.

> What's do people would be the quickest path for, say a experienced vi
> user, new to Lisp to get up an running? Is there anything like ILISP
> for vi?

That depends on what Lisp you are using. If you are on some
proprietary Lisp with a GUI development environment, obviously just
use that.

If you want freeware, CLISP is nice for beginners because it has a
REPL based on GNU readline. So you have command history and tab
completion.

> I ask because I'm writing some materials aimed at new Lisp programmers
> and I'm trying to avoid having to say that step one on the way to
> becoming a Lisp programmer is "Install Emacs and learn how to use it."

The key question is, are they new programmers or just new Lisp
programmers? If they are not programmers, then they have to get used
to the idea that program text goes into a file which is then somehow
presented for processing by the machine. This is largely independent
of the programming language. With Lisp you have the interactive REPL
advantage; you can get students started on programming before
requiring them to learn about editing text files.

Think lazy evaluation: don't force something on the students that can
be delayed. I would get them hooked on programming first, and then
when they start making larger programs, introduce them to the idea of
retaining valuable source code in files.

Also it might be useful to teach students how to save and restore a
Lisp image. Lisp images should be intuitive to anyone who is familiar
with desktop applications, because basically that is where the idea
comes from. Saving a Lisp image after writing some code is not unlike
saving a word processor document. I would even hack some very easy
mechanism for doing this, so that the saving and restoring is done
automatically, or just about. So that each time the student starts up
the Lisp system, her prior work is simply there already.

For example, if I were using CLISP, I would give it a custom image
which contains some very simple function that performs ``save and
quit'' logic, and I would install it in such a way that it always
starts with the previously saved memory image. It could be a wrapped
in a simple script that gives the student a choice: continue with
prior work or start with a blank slate?

I would also give the students demonstrations of a variety of Lisp
systems from different vendors on different platforms, so they don't
confuse the implementation for the language.

Alexander Schmolck

unread,
Apr 8, 2003, 1:14:18 PM4/8/03
to
Paolo Amoroso <amo...@mclink.it> writes:

> > "What I'm too lazy to learn Lisp, if I can't be bothered to learn
> > Emacs. OK fine. Guess I'll learn Python instead. The Python crowd
> > isn't going to make me waste my time learning a new editor when I
> > don't even know if I like the language."
> >
> > Result: a programmer that blows off Lisp.
>
> Given the above, it may not be such a bad thing that Lisp does not attract
> dummies.

I think it would be helpful to distinguishing more carefully between a dummy
and someone with limited mastery of and interest in obscure computer skills.

'as

Jock Cooper

unread,
Apr 8, 2003, 12:59:37 PM4/8/03
to
"Eduardo Muñoz" <emu...@terra.es> writes:

I do the same thing, and for the same reasons. Sometimes if I've been
working on a file and it's "in progress" I can't load it yet. But I can
^c-e single functions no problem. Most of my software is web based. I use
allegroserve (for ACL) or portable allegroserve (for CMU). My work flow just
seems faster (even if only by seconds per loop) by doing this:

1. Browser: press form submit button
2. observe results
3. Emacs: tweak function, press ^c-e
4. repeat

Jock Cooper
http://www.fractal-recursions.com

Erann Gat

unread,
Apr 8, 2003, 1:31:47 PM4/8/03
to

> On Tue, 08 Apr 2003 00:04:47 +0000, Erann Gat wrote:
>
> > In article <PAska.267$Hv2.24...@newssvr21.news.prodigy.com>, "Will
> > Hartung" <wi...@msoft.com> wrote:
> >
> > I have a little demo that I like to show people.
> [snip]
>
> Do you have a webcam? I would love to see a video of you doing
> this demo - it sounds very inspiring!

No, I don't have a webcam, and I also don't have all that many
opportunities to do this demo. People around here mostly don't care. But
here's the code. You can do it yourself if you have a Mac.

(DEFCLASS DRAGGABLE () NIL)

(DEFMETHOD VIEW-CLICK-EVENT-HANDLER ((D DRAGGABLE) LOC)
(PROGN (IF (DOUBLE-CLICK-P)
(INSPECT D)
(WHILE (MOUSE-DOWN-P)
(LET ((P (VIEW-MOUSE-POSITION D)))
(WHEN (NOT (= P LOC))
(SET-VIEW-POSITION D (+ (VIEW-POSITION D) (- P LOC)))
(WINDOW-UPDATE-EVENT-HANDLER (VIEW-CONTAINER D))))))))

(DEFCLASS MYCLASS (VIEW) NIL)

(setf txt (make-instance 'static-text-dialog-item
:dialog-item-text "Lisp rules!"
:view-size #@(200 30)
:view-font '("Times" 24)))

(setf w (make-instance 'window :view-size #@(300 300)))
(setf v (make-instance 'myclass))
(add-subviews w v)
(add-subviews v txt)

; Try dragging the text and verify that it doesn't move.
; Try double-clicking and verify that nothing happens.
; Then do:
; (DEFCLASS MYCLASS (DRAGGABLE VIEW) NIL)
; and try it again.

Kenny Tilton

unread,
Apr 8, 2003, 3:00:41 PM4/8/03
to

I agree with both views here. When I came to Lisp from C the IDE
transition was Symantec (ne Think ne Lightspeed) to MCL. Over time I
came to love the MCL IDE, including Fred ("Fred Resembles Emacs
Deliberately"), but my initial reaction was that the MCL IDE needed a
freindlier face for newbies. ACL has a project manager which I much
prefer to defsystem (even tho defsystem can do cuter stuff in some
ways). But I was used to a project manager, so I was looking for one. (I
also did not find one when I went on my Python walkabout.)

Granted, part of the problem was simply that CL offers different and
better ways of doing things than C, so there was that learning curve.
And a huge point: I suffered IDE-shock moving within CL from MCL to ACL,
but now I love ACL and have trouble in MCL.

So it is a good thing that casual explorers can play with serious IDEs
like ACL and LW, and it is a good thing Peter is working on a "CL for
Fools Enough to Try Something Other Than Java". The skids to CL run
uphill, we damn well better grease them.

But! With many respondents and Paolo I agree: anyone who gets
discouraged by the need to learn Emacs (or its copycats) might be too
casual a prospect to worry over. A serious investigator will understand
that a new language or even a different IDE for the same language will
have a learning curve. They'll be surprised to find that somehow Notepad
cannot be used to edit the source(!), but two seconds later they'll
understand why and that editing Lisp with a Lisp-aware editor is just
one of Lisp's productivity wins.

--

kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay

Gisle Sælensminde

unread,
Apr 8, 2003, 4:31:32 PM4/8/03
to
Erann Gat wrote:
>
> Because of this, Lisp does not play well in the traditional structure.
> This is at once its greatest strengh and its greatest weakness. The
> consequences of not realizing this -- on both sides of the
> misunderstanding -- are evident again and again in discussions on c.l.l.
> (Most recently the thread on "command line arguments" is about precisely
> this confusion.)

Even if you are using lisp, you still need to interact with the
environment, and command line arguments are part of this, and
you may occationally need it, even if you have understood the paradigm.
Then, when somebody ask for e.g. command line arguments, they don't get
the answer, and get accused for not having a clue, since real lisp users
don't need command line arguments. I find that incredible arrogant, also
when the user has not specified why he need command line arguments.
There are perfectly good examples where command line arguments are needed.
The lisp vendors obviously recognized this fact, since all of them provide
some (non-standard) way of reading command line arguments.

--
Gisle Sælensminde
Computational biology unit, University of Bergen, Norway
Email: gi...@cbu.uib.no
Biology easily has 500 years of exciting problems to work on. (Donald Knuth)

Erann Gat

unread,
Apr 8, 2003, 5:22:14 PM4/8/03
to
In article <slrnb96cd3...@apal.ii.uib.no>, Gisle
=?iso-8859-1?Q?S=E6lensminde?= <gi...@apal.ii.uib.no> wrote:

> Erann Gat wrote:
> >
> > Because of this, Lisp does not play well in the traditional structure.
> > This is at once its greatest strengh and its greatest weakness. The
> > consequences of not realizing this -- on both sides of the
> > misunderstanding -- are evident again and again in discussions on c.l.l.
> > (Most recently the thread on "command line arguments" is about precisely
> > this confusion.)
>
> Even if you are using lisp, you still need to interact with the
> environment, and command line arguments are part of this, and
> you may occationally need it, even if you have understood the paradigm.
> Then, when somebody ask for e.g. command line arguments, they don't get
> the answer, and get accused for not having a clue, since real lisp users
> don't need command line arguments. I find that incredible arrogant, also
> when the user has not specified why he need command line arguments.
> There are perfectly good examples where command line arguments are needed.
> The lisp vendors obviously recognized this fact, since all of them provide
> some (non-standard) way of reading command line arguments.

This is a perfect example of what I'm talking about. This post is rife
with assumptions that C people take for granted but which are in fact not
true. The assumptions are so deeply ingrained that merely questioning
them provokes anger.

For example:

> you still need to interact with the environment

The depends on what you are trying to do. In C you need to interact with
the environment in order to do anything non-trivial because C is such an
impoverished language that it's nearly impossible to do anything without
interacting with the environment. But Lisp is rich enough that you can do
many interesting things with it with only minimal interaction with the
host environment. This is not to say the the ability to interact with the
environment is not desirable (it certainly is) but to say that you *need*
to interact with the environment is just wrong.

> and command line arguments are part of this

Command line arguments are one small part of one particular environment:
unix. There are many other environments. And even in unix one can do
many interesting and useful things in Lisp without ever touching a command
line argument.

> Then, when somebody ask for e.g. command line arguments, they don't get
> the answer, and get accused for not having a clue,

That is not what happened in the thread to which I alluded. What happened
there was that the OP had a fundamenal misunderstanding of how Lisp was
intended to work. That misunderstanding was masked by the ostensible
subject of his question. The real substance of that discussion had
nothing at all to do with command line arguments. That the OP (and you,
apparently) thought that it did is an indication of just how deep the
misunderstandings are.

> There are perfectly good examples where command line arguments are needed.

Really? Name one.

> The lisp vendors obviously recognized this fact, since all of them provide
> some (non-standard) way of reading command line arguments.

No. Being needed and being desired by one's customers are two entirely
different things.

The fundamental problem with the mainstream is that it is so pervasive
that most people think that the world has to be the way the mainstream has
shaped it to be. It doesn't. There are alternatives. But most people
don't realize this because they are so indoctrinated that they cannot
recognize that many of the things that they consider features (like
command line arguments) are actually symptoms of an underlying problem
(the lack of a comprehensive interactive environment for constructing
programs). Command line arguments get short shrift in Lisp because they
are unnecessary. They are subsumed by the facilities provided by the
language itself. 90% of the things that people spend their time on in the
C world is like this. My favorite current example is XML.

All this goes back to Kent's point about most of the world preferring
inefficient solutions over efficient ones. It really does appear to be
so. Why this should be a survivable strategy is still a mystery to me
though.

E.

Nils Goesche

unread,
Apr 8, 2003, 6:42:06 PM4/8/03
to
cper...@medialab.com (Chris Perkins) writes:

> Matthew Danish <mda...@andrew.cmu.edu> wrote in message news
>
> [snip]
>
> > Over LispWorks? Nothing really (though M-( at least works
> > properly in Emacs, which is nice), unless you are also doing
> > non-Lisp things. Over nothing (ie notepad)? It's amazingly
> > better.
>
>
> Thanks. It's good to hear that I'm not missing anything. As
> was recently commented about Lisp, it is the collection of lots
> of little things that make their sum greater than the whole. I
> was always afraid that might be true of emacs as well, and thus
> my attempts to use it.

While it is true that programming Lisp with LispWorks is even
/better/ than the Emacs/ILisp combo, I'd like to point out that
learning Emacs, even under Windows, is /still/ worth it. If you
can handle the LispWorks editor, then learning Emacs for basic
editing shouldn't be hard at all, as the LispWorks editor /is/
some form of Emacs, after all. But once you get used to the Lisp
way of doing things, you will learn to appreciate the way Emacs
lets you do all kinds of things -- writing programs in other
languages, for instance, or simply reading and writing mail and
news. Until a few years ago, when I was still forced to use M$
Windows, I was really happy that I had at least GNU Emacs (called
NTEmacs back then, under Windows); I would switch it to full
screen and do everything imaginable with it alone. If anything
didn't work, you could easily make it work by writing some Elisp
code, possibly combined with some custom C code accessing the
Win32 API, but that was rarely necessary. But once you get used
to Emacs, you realize that its interface is /so/ much better and
easier (and faster!) to use (especially because you can customize
every bit you don't like) than anything that ships with Windows,
that learning it is really worth it.

One other nice side-effect is that Emacs is more or less the same
under all OS's. Originally, I got used to Emacs under Irix on
SGIs; I never grokked that OS, nor did I care about it -- if you
only get Emacs, you can do pretty much anything you want under
/any/ OS, because Emacs is the same everywhere.

Regards,
--
Nils Gösche
Ask not for whom the <CONTROL-G> tolls.

PGP key ID #xD26EF2A0

Larry Clapp

unread,
Apr 8, 2003, 10:16:03 PM4/8/03
to
In article <cf333042.03040...@posting.google.com>, Kaz
Kylheku wrote:
> For example, [vim] gets IF and LET right, but it wants to line up

> the body of a WHEN with the expression, rather than just indent it.

:set lispwords+=when

> If you want freeware, CLISP is nice for beginners because it has a
> REPL based on GNU readline. So you have command history and tab
> completion.

VILisp adds a(n imperfect) readline frontend to CMU CL.

> Also it might be useful to teach students how to save and restore a
> Lisp image.

Excellent idea.

Peter Seibel

unread,
Apr 8, 2003, 11:33:17 PM4/8/03
to

I guess that's one view. And some days I agree with what I think of as
the Naggumian view that it would be horrible for Lisp to become too
popular because then it would have to get watered down because of
regression to the mean.

But most days I look around and, ignoring all the "dummies" who aren't
using Lisp, I see a lot of *smart* programmers who *also* aren't using
Lisp. Some of these are my friends and colleagues. Several of them are
folks I suspect will be starting new companies in the not too distant
future, and thus in a position to give me a job. Or they are the folks
I'd like to hire if *I* start a company. In either case I hope we'll
be using Lisp.

But when I talk to them about Lisp, they have a whole raft of
reasons/excuses about why they don't want to use it. Some really are
excuses--reasons that if they were ever true are now invalid and out
of date. These only require patient education on my part. Other
objections are more serious and can probably only be overcome by
getting them to actually *try* Lisp and see that, for a variety of
reasons involving the sum of the parts, etc., their objections really
don't manifest in actual Lisp programming.

Anyway, for me, I'm interested in seeing Lisp spread to more smart
programmers. And I don't see any way to do that but to tear down, or
build bridges over, the various barriers that stand between where they
are now and where I'd like them to be. Because even deeply smart folks
have limited time and energy and they, like the rest of us, have to
make bets about where they're going to get the most payoff for
investing either or both. And the more costly it seems to invest in
learning Lisp--the more other things they have to learn along the
way--the less likely that learning Lisp is going to seem like the best
investment they can make. *We* know what they payoff is because we're
enjoying it now. But for them it's a *potential* payoff and the costs
are real.

-Peter

--
Peter Seibel pe...@javamonkey.com

The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra

Will Hartung

unread,
Apr 9, 2003, 1:19:33 AM4/9/03
to
"Erann Gat" <g...@jpl.nasa.gov> wrote in message
news:gat-080403...@192.168.1.51...

> In article <PAska.267$Hv2.24...@newssvr21.news.prodigy.com>, "Will
> Hartung" <wi...@msoft.com> wrote:
> > And you know what? That whole "environment" part is the part that is
pretty
> > much completely undocumented. Sure, there's a slew of EMACS commands,
but I
> > have yet to see a "users guide" to using Lisp in the Lisp Way.
>
> This is a valid point, but such a thing is incredibly hard to write.

Yes, of course. No doubt a factor in why there are so few examples today.

>
> > As another person noted, "it's best done if you show them".
>
> And this is in fact true.
>
> I have a little demo that I like to show people. It consists of a few
> dozen lines of code in MCL.

*demo snipped*

I witnessed a similar demo a gazillion years ago at a Macintosh event at our
school. A fellow had the Apple port of Xerox Smalltalk (the predecessor of
todays Squeak).

He basically showed the inspector and simple widgets.

Then he found the scrollbar code, found the constant for the width of the
scrollbar, changed it, accepted it, and Voila! Every scrollbar changed. Wow!

This was pretty darn dumbfounding in 1985.

Of course, what all this really means is the simple fact that the
"Apprentice/Master" relationship is still required in todays wired world,
and the wired world is particularly lacking in being able to effectively
communicate this kind of knowledge, at least at low bandwidth like a news
group.

Perhaps this is also a factor in the adoption of new systems. Java has the
benefit of taking traditional idioms and lightly expanding on them. That,
plus the fact that it is a batch environment means that it is easier to pass
these idioms along.

There are several bits of "Best Practice" that Java coders can and do use.
From code style and project layout to debugging and process design. None of
these facets really relate to how the programmer interacts with the
environment, because Java itself really isn't an environment. Windows is.
Unix is. EMACS is. But not Java.

Our shop epitomizes this by the fact that I think among the 7 programmers,
we have 5 different editors. I'm the only one who uses EMACS, and frankly
feel it's the best of the bunch with the JDE and Ant.

But I don't evangelize it. It's hard enough trying to get decent design out
of the other coders, much less trying to present a new editing environment.
Let them struggle in their world. Only where I end up in their code can I
hope to add new light to their dark world of "abstraction through
cut-n-paste".

A similar event happened with my new motorcycle. Of all things, it has an
electronic cruise control, just like many modern cars. You don't think about
these kinds of things for a motorcycle, but it's the kind of thing that once
you've tried it, it's hard to fathom not having it.

But what it does do is it makes you listen more to other folks who may rave
about some "new, different" thing or another. Another motorcyle accessory I
need to try is the Electric Vest. Riders rave about these things.

How good can it be? I mean, sure, heated vest, keeps you warm, etc. But I
haven't been that cold that often. I can't say I've ever needed an electric
vest. But, after trying out my cruise control for the first time, I'm more
interested about this vest thing. Perhaps they really are the bees knees.

This comes back to Lisp. Folks here rave about it. "Religion" comes up a
lot. I use it, I like it. I mostly like the interactivity, writing little
tests at the listener. Macros. Very nice. (Another habit I've tried to
instill in fellow Java coders who seem to insist that firing up and loading
the entire application on two seperate servers is necessary to test their 2
line code changes...*sigh*).

I like Lisp and I haven't used hardly any of the stuff that folks hail from
the rooftops about: dynamic class changes, code loading, multiple
inheritance, etc.

A few macros, car, cdr, defstruct. That pretty much sums up my experience.

But the advanced stuff? defpackage, defsystem, even CLOS, I've not had the
need for yet.

I'll just have to take y'alls words for it that these too are the bee knees,
and that the Lisp fairy will land on my shoulder someday when whatever thing
I'm working on needs them and says "Today is the day!". It's just hard to
know what I'm missing when, well, I don't know what I'm missing :-).

Regards,

Will Hartung
(wi...@msoft.com)

Will Hartung

unread,
Apr 9, 2003, 1:51:56 AM4/9/03
to

"Thaddeus L Olczyk" <olc...@interaccess.com> wrote in message
news:7aj49vsa9q3q89deb...@4ax.com...

> Potential Lisp programmer:
> " So now I have to learn Emacs befor I can learn Lisp. Hmm. Only 45
> minutes. Wait what's this? If I do it right I have to write a .emacs
> in Lisp? What else am I going to have to learn? Worse, how am I
> going to convince my coworkers?

The problem here is all expectations, no doubt some sourced by this group.

However, notice that none of the books about Lisp even touch hardly any of
these topics. Rather they focus on the language.

'vi' works fine for Lisp code. I did a boatload of Scheme in vi. Not vim,
but braindead, circa 1980ish vi.

:set lisp sm

Boom, Lisp mode.

Is it truly an incredible editing experience? Umm...no. but it's completely
functional, and the % key makes it easy to move around and check the parens.

(edit "filename.lsp")
(load "filename.lsp")

These soon became:
(defvar *filename*)

(defun (ed file)
(setf *filename* file)
(edit *filename*))

(defun (e)
(edit *filename*))

(defun (ld file)
(setf *filename* file)
(load *filename*))

(defun (reload)
(load *filename*))

Instant environment. I even put this into a file named "init.lsp".

When reload or load took too long, you break up the file: util.lsp,
code.lsp. If you're really impatient, use a work.lsp, filled with patches.
When it gets too big, reintegrate it with the rest of the code base and
empty it. When it gets really really bad, dump an image.

EMACS is nice, for all sorts of reasons. But it certainly isn't required.
The only real requirement that Lisp imposes over writing code for any other
language is paren matching. It's pretty maddening without it.

What do you need to run Java? A JVM and an editor.
What do you need to run C? A C compiler and an editor.
What do you need to run Python? A Python interpreter and an editor.
What do you need to run Lisp?

Amazingly, none of the benefits of Lisp Go Away in this simple mode. All of
the language features are still there. Macros, Advice, CLOS. None of these
are provided by the editor you use, so none of these are lost by the editor
you use.

Amazing how that works.

Regards,

Will Hartung
(wi...@msoft.com)

Edi Weitz

unread,
Apr 9, 2003, 4:03:17 AM4/9/03
to
Larry Clapp <la...@theclapp.org> writes:

> In article <cf333042.03040...@posting.google.com>, Kaz
> Kylheku wrote:
> > If you want freeware, CLISP is nice for beginners because it has a
> > REPL based on GNU readline. So you have command history and tab
> > completion.
>
> VILisp adds a(n imperfect) readline frontend to CMU CL.

BTW, here's another (imperfect) readline frontend for CMUCL (or SBCL
or others):

<http://www.weitz.de/completions.html>

It's not as smart as that of CLISP but you'll also get a history which
persists between sessions. Don't know how to do that with CLISP.

Cheers,
Edi.

Florian Weimer

unread,
Apr 9, 2003, 6:55:20 AM4/9/03
to
Bruce Hoult <br...@hoult.org> writes:

> You must work somewhere quite different to where I do -- we're doing
> basic C/C++/Java programming and the emacs users outnumber the vi users
> by at least four to one (and all the machines are dual-boot and Linux
> users outnumber Windows users by more like 10:1).

In my team at work, I'm the only Emacs user. However, it's me who
explains advanced vi (or VIM) commands to the other team members. 8-)

Adam Warner

unread,
Apr 9, 2003, 7:02:52 AM4/9/03
to
Hi Edi Weitz,

> <http://www.weitz.de/completions.html>
>
> It's not as smart as that of CLISP but you'll also get a history which
> persists between sessions. Don't know how to do that with CLISP.

I find the persistent history of rlwrap extremely useful. It's interesting
how CLISP's licensing was irrevocably changed by something so ultimately
unnecessary.

Some Readline support in CLISP is currently broken when compiling CLISP
with GCC 3.2.x: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=183796>

Regards,
Adam

Thaddeus L Olczyk

unread,
Apr 9, 2003, 7:47:18 AM4/9/03
to
On Wed, 09 Apr 2003 03:33:17 GMT, Peter Seibel <pe...@javamonkey.com>
wrote:

>Because even deeply smart folks
>have limited time and energy and they, like the rest of us, have to
>make bets about where they're going to get the most payoff for
>investing either or both.

Let me a correct a bit of this this.
You say "because even deeply" .
Change the context ( if not the English )
to "especially deeply".
I find the smartest folks tend to have many oars in many different
waters and therefore less time and energy to devote to side-projects
then the rest of us.
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.

Joerg Hoehle

unread,
Apr 9, 2003, 10:29:52 AM4/9/03
to
Peter Seibel <pe...@javamonkey.com> writes:
> > > > > I'm mostly stuck on what to tell the hard-core vi user.
> Larry Clapp's vilisp scripts for vim let's you do things in more
> 'emacsy' way while you're not the only person who's told me they just
> use LOAD. Thanks.

But isn't that rather unlispy? There's this other current thread where
Edi Weitz enlighted somebody coming from C explaining him that
gcc -o foo -c foo.c -> clisp -c foo.lisp
is not the way to use Lisp.

I feel missing something important when all I have is LOAD. Copy&Paste
of individual forms helps a little, but it's still feeling underpowered.

M-x lisp-eval-region and M-x lisp-eval-last-sexp help a great deal. I
also had code to copy&paste sexp-delimited forms with a single mouse
click (also works in C or any mode where Emacs' forward-sexp works).

I typically have source files like these
(defun foo ...)
;(foo "bla")

#|
comments and other forms like
(foo 123345)
#|

This makes only sense in interactive mode:
Place cursor behind ;(foo "bla") or (foo 123456) and perform a quick
unit test - nice for portability

What I've seen elsewhere (Oleg's SXML Scheme code IIRC) is an embedded
testing mini-framework:
(defun ...)
(test
(foo "bla") 406) ; checks return type
This can be automated.
Here test is a macro that either expands to nothing during compilation, or to
the testing code.

Regards,
Jorg Hohle
Telekom/T-Systems Technology Center

Duane Rettig

unread,
Apr 9, 2003, 11:24:47 AM4/9/03
to
Alain Picard <apicard+die...@optushome.com.au> writes:

> cper...@medialab.com (Chris Perkins) writes:
>
> > I've always had the opposite question - why do people use emacs in the
> > first place?
>
> [Note: here, I assume that "people" are meant to be "programmers"]
>
> They use it so they can get to the point that a good musician
> is at in front of a piano: so they can make music.
>
> I mean that absolutely literally. The pianist doesn't think
> about the piano, they think about the music. The seasoned
> programmer doesn't think about the C-M-keybindings, they
> think about what s-expression they want to see appear on
> the screen and.... they just appear. The _last_ think you
> want to do is to _think_ about your editor.

I like this analogy, but I would give it a different instrument.

Consider the difference between the piano and the trumpet.
Anyone can sit down at a piano and play a note, and the note
sounds good, because the piano is making the note. One can even
start playing chords right away, and with a little practice, and
as mistakes are reduced, it can start sounding good fairly quickly.
But put a trumpet to your mouth for the first time, and it sounds
horrible. And not only does it sound horrible, but it stays
sounding that way for months or for years. It takes a long time to
even build up the muscles in your mouth (the embuchure, or "chops")
to the point where the tone quality is even bearable to listen to.

So why do people learn the trumpet in the first place?

--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182

Mario S. Mommer

unread,
Apr 9, 2003, 11:25:14 AM4/9/03
to

Peter Seibel <pe...@javamonkey.com> writes:
> Mario S. Mommer <m_mo...@yahoo.com> writes:
> > Good riddance.
>
> I guess that's one view. And some days I agree with what I think of as
> the Naggumian view that it would be horrible for Lisp to become too
> popular because then it would have to get watered down because of
> regression to the mean.
[...]

> Anyway, for me, I'm interested in seeing Lisp spread to more smart
> programmers. And I don't see any way to do that but to tear down, or
> build bridges over, the various barriers that stand between where they
> are now and where I'd like them to be.

These aren't really contradictory positions :-). I agree with you that
there is quite a lot to improve concernig usability, completeness
(guis, threads, etc.), etc. and there are too few people doing things
in that direction. More are needed.

On the other hand, many of the complaints are fairly infantile, and if
they were taken seriously I don't think anybody would benefit. If
somebody sees emacs and says "I'm going python, where I can program
using msnotepad" then I won't invest neither time nor energy into
bothering.

> Because even deeply smart folks have limited time and energy and
> they, like the rest of us, have to make bets about where they're
> going to get the most payoff for investing either or both. And the
> more costly it seems to invest in learning Lisp--the more other
> things they have to learn along the way--the less likely that
> learning Lisp is going to seem like the best investment they can
> make. *We* know what they payoff is because we're enjoying it
> now. But for them it's a *potential* payoff and the costs are real.

I really don't think that if you solve the editor problem you have
taken away much of what is different in the CL world. And in any case,
if your editor doesn't help you with the parens you are screwed
anyway.

Mario.

Daniel Barlow

unread,
Apr 9, 2003, 11:39:23 AM4/9/03
to
Duane Rettig <du...@franz.com> writes:

> So why do people learn the trumpet in the first place?

I guess because they like the sound of the trumpet as played by
proficient trumpet players, and are aware that the "trumpet" setting
on their synthesizer just isn't the same.

Given how careful many Lisp users (not Franz, obviously) are to not
give away their "competitive advantage" by telling anyone they're
using Lisp, it's perhaps not too surprising that so many people think
they can produce the same music using Java.


-dan, bad guitar player

--

http://www.cliki.net/ - Link farm for free CL-on-Unix resources

Johan Kullstam

unread,
Apr 9, 2003, 12:24:04 PM4/9/03
to
g...@jpl.nasa.gov (Erann Gat) writes:

Well, in lisp you can look at top level functions as programs and they
can easily take arguments.

(sqrt 2)
=> 1.4142135

SQRT is a program, 2 is a command line argument. Lisp args are
much better done than unix command line since the better lisp
syntax can give more structure.

> They are subsumed by the facilities provided by the
> language itself. 90% of the things that people spend their time on in the
> C world is like this. My favorite current example is XML.

> All this goes back to Kent's point about most of the world preferring
> inefficient solutions over efficient ones. It really does appear to be
> so. Why this should be a survivable strategy is still a mystery to me
> though.

I think it's usually a preference for short-term effecient and
long-term inefficient. Hard work pays off later, procrastination pays
off now. Worse is better, &c.

XML seems to buck this trend giving both short and long term
inefficiency.

--
Johan KULLSTAM <kulls...@attbi.com> sysengr

Erann Gat

unread,
Apr 9, 2003, 12:43:14 PM4/9/03
to
In article <87ptnva...@sysengr.res.ray.com>, Johan Kullstam
<kulls...@attbi.com> wrote:

> > Command line arguments get short shrift in Lisp because they
> > are unnecessary.
>
> Well, in lisp you can look at top level functions as programs and they
> can easily take arguments.
>
> (sqrt 2)
> => 1.4142135
>
> SQRT is a program, 2 is a command line argument.

I guess I should have said that *unix* command line arguments get short shrift.

> Lisp args are
> much better done than unix command line since the better lisp
> syntax can give more structure.

It's much, much more than that. The semantics of a Lisp "command" are
fundamentally different than the semantics of a unix command. When you
"run" a Lisp program you are calling a function which returns a value.
When you run a unix program you are spawning a task which produces
output. These are two completely different things, and they compose in
completely different ways. For example, in Lisp you could imagine doing
something like:

(foo (get-value-from-web "http://foo.baz.bar"))

You can do something analogous in unix with, e.g.:

wget http://foo.bar.bar | foo

But what about this:

(baz (get-value-from-web url1) (get-value-from-database db1))

There is no straightforward analog of this in unix. The unix way of
composing things is fundamentally limited by the fact that a process has
only a single stdin stream. And that is just one example of the kinds of
constraints that C programmers wrestle with day in and day out.

Joost Kremers

unread,
Apr 9, 2003, 2:11:30 PM4/9/03
to
Erann Gat wrote:
> But what about this:
>
> (baz (get-value-from-web url1) (get-value-from-database db1))

what about:

baz $(wget url1) $(dget db1)



> There is no straightforward analog of this in unix.

well, there is a way to do it. i don't know if you consider it a
"straightforward analog", but the idea is the same: the interpreter first
executes 'wget url1' and 'dget db1' and then feeds the results to baz.

> The unix way of
> composing things is fundamentally limited by the fact that a process has
> only a single stdin stream. And that is just one example of the kinds of
> constraints that C programmers wrestle with day in and day out.

since i'm not a real programmer, i won't say you're wrong, but why wouldn't
this work:

baz(get-value-from-web(url), get-value-from-database(db1));

not that you often see that sort of thing...

--
Joost Kremers http://baserv.uci.kun.nl/~jkremers
since when is vi an editor? a discussion on vi belongs in
comp.tools.unusable or something...

Pascal Bourguignon

unread,
Apr 9, 2003, 2:27:43 PM4/9/03
to
g...@jpl.nasa.gov (Erann Gat) writes:

> In article <87ptnva...@sysengr.res.ray.com>, Johan Kullstam
> <kulls...@attbi.com> wrote:

> [...]


> > Lisp args are much better done than unix command line since the
> > better lisp syntax can give more structure.
>
> It's much, much more than that. The semantics of a Lisp "command" are
> fundamentally different than the semantics of a unix command. When you
> "run" a Lisp program you are calling a function which returns a value.
> When you run a unix program you are spawning a task which produces
> output. These are two completely different things, and they compose in
> completely different ways. For example, in Lisp you could imagine doing
> something like:
>
> (foo (get-value-from-web "http://foo.baz.bar"))
>
> You can do something analogous in unix with, e.g.:
>
> wget http://foo.bar.bar | foo
>
> But what about this:
>
> (baz (get-value-from-web url1) (get-value-from-database db1))
>
> There is no straightforward analog of this in unix. The unix way of
> composing things is fundamentally limited by the fact that a process has
> only a single stdin stream. And that is just one example of the kinds of
> constraints that C programmers wrestle with day in and day out.

Not the unix way. What about the 'ls' command? It takes 0 stdin stream!
(Just try: echo hello | ls).

Some unix commands take more input streams. For example, gpg:

gpg --passphrase-fd 3 -e < clear-input > crypted-output 6< password-file

The rest of the limititations are limitations of the shell used, not
of unix. For example, scsh does not have these limitations.


But in any case, that's not the point. The question is whether lisp
interpreters and lisp compilers can be used to program unix commands?

--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.

Erann Gat

unread,
Apr 9, 2003, 3:33:09 PM4/9/03
to
In article <slrnb98nlg.68...@catv0149.extern.kun.nl>, Joost
Kremers <joostk...@yahoo.com> wrote:

> Erann Gat wrote:
> > But what about this:
> >
> > (baz (get-value-from-web url1) (get-value-from-database db1))
>
> what about:
>
> baz $(wget url1) $(dget db1)

How is baz going to tell where the result from wget stops and the result
of dget begins?

> > There is no straightforward analog of this in unix.
>
> well, there is a way to do it. i don't know if you consider it a
> "straightforward analog", but the idea is the same: the interpreter first
> executes 'wget url1' and 'dget db1' and then feeds the results to baz.

The devil is always in the details. The problem is not that you can't
describe a simple solution. The problem is that when you actually get
around to implementing that simple solution using mainstream approaches it
almost invariably ceases to be simple.

> > The unix way of
> > composing things is fundamentally limited by the fact that a process has
> > only a single stdin stream. And that is just one example of the kinds of
> > constraints that C programmers wrestle with day in and day out.
>
> since i'm not a real programmer, i won't say you're wrong, but why wouldn't
> this work:
>
> baz(get-value-from-web(url), get-value-from-database(db1));
>
> not that you often see that sort of thing...

Again, the devil is in the details. Are we taling about C or the shell?
If we're talking about the shell then this is just a syntax error. If
we're talking about C then there are all the problems inherent in C: no
interactive top level, no automatic memory management, etc. etc.

These things are obviously not impossible using mainstream approachs, they
are just much harder.

Erann Gat

unread,
Apr 9, 2003, 3:38:21 PM4/9/03
to
In article <87ptnvo...@thalassa.informatimago.com>, Pascal Bourguignon
<p...@informatimago.com> wrote:

> Some unix commands take more input streams. For example, gpg:
>
> gpg --passphrase-fd 3 -e < clear-input > crypted-output 6< password-file

Not all shells support this. (In fact, I believe the N< syntax is unique
to ksh.)

But be that as it may, this is tantamount to having keyword arguments
where the names of the arguments are required to be numbers. Blech!

> But in any case, that's not the point. The question is whether lisp
> interpreters and lisp compilers can be used to program unix commands?

Was that the question? I thought the question was: why is it important to
couple learning Lisp with learning emacs? (See the title of the thread.)

In any case, the answer to the question you pose is obviously "yes".

Joost Kremers

unread,
Apr 9, 2003, 4:26:00 PM4/9/03
to
Erann Gat wrote:
> In article <slrnb98nlg.68...@catv0149.extern.kun.nl>, Joost
> Kremers <joostk...@yahoo.com> wrote:
>
>> Erann Gat wrote:
>> > But what about this:
>> >
>> > (baz (get-value-from-web url1) (get-value-from-database db1))
>>
>> what about:
>>
>> baz $(wget url1) $(dget db1)
>
> How is baz going to tell where the result from wget stops and the result
> of dget begins?

the answer being so straightforward, i'll assume that's a rhetorical
question. ;-)

>> since i'm not a real programmer, i won't say you're wrong, but why wouldn't
>> this work:
>>
>> baz(get-value-from-web(url), get-value-from-database(db1));
>>
>> not that you often see that sort of thing...
>
> Again, the devil is in the details. Are we taling about C or the shell?

C

> If we're talking about the shell then this is just a syntax error.

i know.

> If
> we're talking about C then there are all the problems inherent in C: no
> interactive top level, no automatic memory management, etc. etc.
> These things are obviously not impossible using mainstream approachs, they
> are just much harder.

sure, and i'm not arguing the point that lisp has such advantages over
bash/C. i just wanted to point out that the example you gave doesn't really
illustrate that point.

Alan Shutko

unread,
Apr 9, 2003, 5:37:59 PM4/9/03
to
Joost Kremers <joostk...@yahoo.com> writes:

> baz $(wget url1) $(dget db1)

You realize that won't work if the page wget retrieves is of any
size, at all. Or has spaces.

--
Alan Shutko <a...@acm.org> - I am the rocks.
Looking for a developer in St. Louis? http://web.springies.com/~ats/
When all else fails, ask a 10-year-old.

Joost Kremers

unread,
Apr 9, 2003, 5:42:23 PM4/9/03
to
Alan Shutko wrote:
> Joost Kremers <joostk...@yahoo.com> writes:
>
>> baz $(wget url1) $(dget db1)
>
> You realize that won't work if the page wget retrieves is of any
> size, at all. Or has spaces.

wget was only an example. it doesn't even write the pages it retrieves to
stout. replace it with any command or command sequence that outputs
whatever information you like. if it contains spaces, simply write:

bas "$(some-command url1)" "$(some-other-command db1)"

Gisle Sælensminde

unread,
Apr 9, 2003, 5:44:37 PM4/9/03
to
In article <gat-080403...@k-137-79-50-101.jpl.nasa.gov>, Erann Gat wrote:
> In article <slrnb96cd3...@apal.ii.uib.no>, Gisle
>=?iso-8859-1?Q?S=E6lensminde?= <gi...@apal.ii.uib.no> wrote:
>
>> Erann Gat wrote:
>> >
>> > Because of this, Lisp does not play well in the traditional structure.
>> > This is at once its greatest strengh and its greatest weakness. The
>> > consequences of not realizing this -- on both sides of the
>> > misunderstanding -- are evident again and again in discussions on c.l.l.
>> > (Most recently the thread on "command line arguments" is about precisely
>> > this confusion.)
>>
>> Even if you are using lisp, you still need to interact with the
>> environment, and command line arguments are part of this, and
>> you may occationally need it, even if you have understood the paradigm.
>> Then, when somebody ask for e.g. command line arguments, they don't get
>> the answer, and get accused for not having a clue, since real lisp users
>> don't need command line arguments. I find that incredible arrogant, also
>> when the user has not specified why he need command line arguments.
>> There are perfectly good examples where command line arguments are needed.
>> The lisp vendors obviously recognized this fact, since all of them provide
>> some (non-standard) way of reading command line arguments.
>
> This is a perfect example of what I'm talking about. This post is rife
> with assumptions that C people take for granted but which are in fact not
> true. The assumptions are so deeply ingrained that merely questioning
> them provokes anger.

It seems for me that you are assuming that you want to do the whole application
in Lisp. Fine if you can, but if you are using big portions of code that is
written in other languages, then you must interact with the environment in
some way. In my case this is scientific code that required several
man-years to make, and required several man-years to be developed, and
would require probably a year or more to recode it all in CL, and require
me to understand every aspect of the underlying code and theories it is
built upon. Now I have a working system after two less then two months.
I'm not using command line
arguments in this case, but calling external programs or foreign
functions call counts as interaction with the environment.

> For example:
>
>> you still need to interact with the environment
>
> The depends on what you are trying to do. In C you need to interact with
> the environment in order to do anything non-trivial because C is such an
> impoverished language that it's nearly impossible to do anything without
> interacting with the environment. But Lisp is rich enough that you can do
> many interesting things with it with only minimal interaction with the
> host environment. This is not to say the the ability to interact with the
> environment is not desirable (it certainly is) but to say that you *need*
> to interact with the environment is just wrong.

I need to interact with the environment in order to run programs or code
written by others in languages other than lisp. I don't need to interact
with the environment for most non-trivial things, but lisp can be as
fantastic as it want, and I still need to interact with other peoples
nontrivial code, and rewriting all code that don't fit into that model is
not an option. In practice you will need to interact with the environment
in at least some situations. It may be true that most people don't need it
most of the time, but you can't just say it is not needed without knowing
the context. In a way I'm sitting on the shoulders of giants. Unfortunatly
those giants didn't use Lisp.

>
> Really? Name one.

One example is the queing system on some linux clusters. Queued job are
started, the way of telling where the input can be found, is through the
command line arguments, since many jobs can run in parallell, and you
don't know in advance which node you will use. This is a batch system
that I can't use interactivly, but I still want to run lisp on it for
some tasks. Maybe not a common situation, but there are many uncommon
situations.

I know that many people don't have the ability to think about other ways of
interaction with the environment, but that there is another way of doing it
that is more "Lispy" that can and should be used in most cases, don't mean
that you never need it.

Erann Gat

unread,
Apr 9, 2003, 7:26:49 PM4/9/03
to
In article <slrnb9940d.68...@catv0149.extern.kun.nl>, Joost
Kremers <joostk...@yahoo.com> wrote:

> Alan Shutko wrote:
> > Joost Kremers <joostk...@yahoo.com> writes:
> >
> >> baz $(wget url1) $(dget db1)
> >
> > You realize that won't work if the page wget retrieves is of any
> > size, at all. Or has spaces.
>
> wget was only an example. it doesn't even write the pages it retrieves to
> stout.

Assume some hypothetical wget that writes the page to stdout.

> replace it with any command or command sequence that outputs
> whatever information you like. if it contains spaces, simply write:
>
> bas "$(some-command url1)" "$(some-other-command db1)"

OK, now what if I want to nest these "function calls" three levels deep? Four?

Larry Clapp

unread,
Apr 9, 2003, 11:33:26 PM4/9/03
to
In article <gat-090403...@k-137-79-50-101.jpl.nasa.gov>, Erann Gat wrote:
> In article <87ptnva...@sysengr.res.ray.com>, Johan Kullstam
><kulls...@attbi.com> wrote:
>> Lisp args are much better done than unix command line since the
>> better lisp syntax can give more structure.
>
> It's much, much more than that. The semantics of a Lisp "command"
> are fundamentally different than the semantics of a unix command.
> When you "run" a Lisp program you are calling a function which
> returns a value. When you run a unix program you are spawning a
> task which produces output. These are two completely different
> things, and they compose in completely different ways. For example,
> in Lisp you could imagine doing something like:
>
> (foo (get-value-from-web "http://foo.baz.bar"))
>
> You can do something analogous in unix with, e.g.:
>
> wget http://foo.bar.bar | foo
>
> But what about this:
>
> (baz (get-value-from-web url1) (get-value-from-database db1))
>
> There is no straightforward analog of this in unix.

Just to throw in my irrelevant two cents: zsh can do that.[1]

Of course, this doesn't deal at all with your primary point of
"argument passing" vs "reading serialized data streams".

-- Larry

[1]

baz <(get-value-from-web url1) <(get-value-from-database db1)

The <() construct creates a FIFO (or "named pipe")[2], and passes the
name to baz as an argument. You can also say >() to send output to a
process's stdin. zsh will even do an implicit tee if you use two (or
more) >() at once.

If your program needs actual files, or does seeks, or reads all input
before producing any output (like sort), you can also do the
equivalent of

get-value-from-web url1 > temp1
get-value-from-database db1 > temp2
baz temp1 temp2

like so

baz =(get-value-from-web url1) =(get-value-from-database db1)

As the manpage points out, both these approaches have some drawbacks.
See zshexpn(1).

[2] Or, if the OS supports it, /dev/fd/<n>.

Andy Freeman

unread,
Apr 9, 2003, 11:51:22 PM4/9/03
to
Thaddeus L Olczyk <olc...@interaccess.com> wrote in message news:<7aj49vsa9q3q89deb...@4ax.com>...
> On Mon, 07 Apr 2003 16:55:41 GMT, cst...@dtpq.com (Christopher C.

> Potential Lisp programmer:
> " So now I have to learn Emacs befor I can learn Lisp.

As others pointed out, vi works well with lisp, and lots of folks
who don't know lisp already use emacs.

> If I do it right I have to write a .emacs in Lisp?

No.

While one can customize emacs, it is completely optional. I've
never bothered, and I've been using it since the late 70s.

> The Python crowd
> isn't going to make me waste my time learning a new editor when I
> don't even know if I like the language."

Which generic text editor supports python better than it supports
lisp? (BTW - The pythonistas do suggest using a Python-specific IDE.)

-andy

Marc Spitzer

unread,
Apr 10, 2003, 12:21:10 AM4/10/03
to
g...@jpl.nasa.gov (Erann Gat) writes:

in current versions of ksh:

baz $( get-value-from-web $url1 ) $( get-value-from-db $db1)

and you can nest $() as many times as you need to.

>
> There is no straightforward analog of this in unix. The unix way of
> composing things is fundamentally limited by the fact that a process has
> only a single stdin stream. And that is just one example of the kinds of
> constraints that C programmers wrestle with day in and day out.

A process can have multiple input streams, you just get 1 set up by the
os and the rest you need to setup manually. Now if you are talking
about a process communicating via pipes, not named pipes, you are
much closer to accurate.

marc

Marc Spitzer

unread,
Apr 10, 2003, 12:26:10 AM4/10/03
to
g...@jpl.nasa.gov (Erann Gat) writes:

> In article <slrnb98nlg.68...@catv0149.extern.kun.nl>, Joost
> Kremers <joostk...@yahoo.com> wrote:
>
> > Erann Gat wrote:
> > > But what about this:
> > >
> > > (baz (get-value-from-web url1) (get-value-from-database db1))
> >
> > what about:
> >
> > baz $(wget url1) $(dget db1)
>
> How is baz going to tell where the result from wget stops and the result
> of dget begins?

from my ksh93 man page:

Command Substitution.
The standard output from a command enclosed in parentheses preceded by
a dollar sign ( $() ) or a pair of grave accents (``) may be used as
part or all of a word; trailing new-lines are removed. In the second
(obsolete) form, the string between the quotes is processed for special
quoting characters before the command is executed (see Quoting below).
The command substitution $(cat file) can be replaced by the equivalent
but faster $(<file).

And it does work.

marc

Marc Spitzer

unread,
Apr 10, 2003, 1:07:54 AM4/10/03
to
g...@jpl.nasa.gov (Erann Gat) writes:

> In article <slrnb9940d.68...@catv0149.extern.kun.nl>, Joost
> Kremers <joostk...@yahoo.com> wrote:
>
> > Alan Shutko wrote:
> > > Joost Kremers <joostk...@yahoo.com> writes:
> > >
> > >> baz $(wget url1) $(dget db1)
> > >
> > > You realize that won't work if the page wget retrieves is of any
> > > size, at all. Or has spaces.
> >
> > wget was only an example. it doesn't even write the pages it retrieves to
> > stout.
>
> Assume some hypothetical wget that writes the page to stdout.
>
> > replace it with any command or command sequence that outputs
> > whatever information you like. if it contains spaces, simply write:
> >
> > bas "$(some-command url1)" "$(some-other-command db1)"
>
> OK, now what if I want to nest these "function calls" three levels
> deep? Four?

in the ksh that is in freebsd's ports collection, yes it works.

marc

Erann Gat

unread,
Apr 10, 2003, 2:16:26 AM4/10/03
to
In article <86y92j9...@bogomips.optonline.net>, Marc Spitzer
<mspi...@optonline.net> wrote:

Well, I'll be damned. I didn't think that double-quotes nested, but they
do --at least in ksh and bash. tcsh doesn't seem to support $() syntax at
all.

When you use this, ksh code comes out looking an awful lot like Lisp:

echo "$(foo "$(baz $bar)" $bing)

Wrap the whole thing in a pair of parens, strip off the dollars and
quotes, and voila!

ksh even has EVAL! I guess it must be just as good as Lisp!

Well, I'm of to Google for a free native code ksh compiler. Wish me luck.

Erann Gat

unread,
Apr 10, 2003, 2:26:59 AM4/10/03
to
In article <slrnb99525...@apal.ii.uib.no>, Gisle
=?iso-8859-1?Q?S=E6lensminde?= <gi...@apal.ii.uib.no> wrote:

No, you have to interface to those programs. That's not quite the same thing.

Nonetheless, perhaps you'd better re-read the very first sentence that I
wrote in this exchange:

"... Lisp does not play well in the traditional structure."

> In a way I'm sitting on the shoulders of giants. Unfortunatly
> those giants didn't use Lisp.

Choose better giants next time. ;-)

Seriously though, Lisp is not the best tool for all jobs (though it is a
better tool for more jobs than most people realize). Perhaps your task is
just not a good fit.

However...

> One example is the queing system on some linux clusters. Queued job are
> started, the way of telling where the input can be found, is through the
> command line arguments,

This doesn't sound like it should be a serious problem. In any case, it's
a completely different issue than the original "command line arguments"
issue. The original issue was all about passing command line arguments
*to* Lisp, not from Lisp.

Marc Spitzer

unread,
Apr 10, 2003, 3:51:35 AM4/10/03
to
g...@jpl.nasa.gov (Erann Gat) writes:

why? It serves a different purpose and does a pretty good job of
it thats all. And no one said it was as good as CL for what CL
does. People have just been pointing out your flawed, limited,
lacking understanding of parts of unix work. The alternative was
that you were behaving as a troll.

>
> Well, I'm of to Google for a free native code ksh compiler. Wish me luck.

Why would you expect anyone to create such a stupid thing for free? The
closest thing I am aware of is the hamaltonian-csh(sp?) product(costs
money) for csh and it does bytecode.

Here is how it is suposed to be done in unix:

1: write a script that does what you need
2: if it is fast enough stop
3: otherwise rewrite it in C(or C++ or CL or fortran ...)

marc

Ingvar Mattsson

unread,
Apr 10, 2003, 5:35:48 AM4/10/03
to
g...@jpl.nasa.gov (Erann Gat) writes:

> In article <slrnb98nlg.68...@catv0149.extern.kun.nl>, Joost
> Kremers <joostk...@yahoo.com> wrote:
>
> > Erann Gat wrote:
> > > But what about this:
> > >
> > > (baz (get-value-from-web url1) (get-value-from-database db1))
> >
> > what about:
> >
> > baz $(wget url1) $(dget db1)
>
> How is baz going to tell where the result from wget stops and the result
> of dget begins?

baz "$(wget url1)" "$(dget db1)"

Let's try a small experiment:
ingvar@gruk$ cat > /tmp/gat-demo
#!/bin/sh
for arg
do
echo "$arg"
done
ingvar@gruk$ chmod +x /tmp/gat-demo
ingvar@gruk$ cat > /tmp/cmd1
#!/bin/sh
echo This is a multi-word repsone from cmd1
ingvar@gruk$ chmod +x /tmp/cmd1
ingvar@gruk$ cat > /tmp/cmd2
#!/bin/sh
echo And this is from cmd2
ingvar@gruk$ chmod +x /tmp/cmd2
ingvar@gruk$ /tmp/gat-demo "$(/tmp/cmd1)" "$(/tmp/cmd2)"
This is a multi-word repsone from cmd1
And this is from cmd2
ingvar@gruk$ /tmp/gat-demo $(/tmp/cmd1) $(/tmp/cmd2)
This
is
a
multi-word
repsone
from
cmd1
And
this
is
from
cmd2

//Ingvar
--
Self-referencing
Five, seven, five syllables
This haiku contains

Florian Weimer

unread,
Apr 10, 2003, 5:45:25 AM4/10/03
to
Alan Shutko <a...@acm.org> writes:

> Joost Kremers <joostk...@yahoo.com> writes:
>
>> baz $(wget url1) $(dget db1)
>
> You realize that won't work if the page wget retrieves is of any
> size, at all. Or has spaces.

Apply a bashism instead:

baz <(wget -q -O - url1) <(dget db1)

I actually use such constructs (with baz = diff).

Jonas Öster

unread,
Apr 10, 2003, 5:59:39 AM4/10/03
to
On 10 Apr 2003 10:35:48 +0100,
Ingvar Mattsson <ing...@cathouse.bofh.se> wrote:

[shell scripts cut out]

>ingvar@gruk$ /tmp/gat-demo $(/tmp/cmd1) $(/tmp/cmd2)
>This
>is
>a
>multi-word
>repsone
>from
>cmd1
>And
>this
>is
>from
>cmd2

Unix command lines are limited in size; what if cmd1 and/or cmd2 output
several megabytes of data?

/Jonas

--
typedef enum { false, true, wow } bool; - Donald E. Knuth

Ingvar Mattsson

unread,
Apr 10, 2003, 8:12:34 AM4/10/03
to
d97...@dtek.chalmers.se (Jonas Öster) writes:

> On 10 Apr 2003 10:35:48 +0100,
> Ingvar Mattsson <ing...@cathouse.bofh.se> wrote:

[SNIP]


> Unix command lines are limited in size; what if cmd1 and/or cmd2 output
> several megabytes of data?

Then you lose. Badly.

Joe Marshall

unread,
Apr 10, 2003, 9:37:17 AM4/10/03
to
g...@jpl.nasa.gov (Erann Gat) writes:

> Well, I'm off to Google for a free native code ksh compiler. Wish me luck.

Don't forget that it has to create `stand-alone executables'.

Godspeed!

Erann Gat

unread,
Apr 10, 2003, 11:37:37 AM4/10/03
to
In article <86of3e9...@bogomips.optonline.net>, Marc Spitzer
<mspi...@optonline.net> wrote:

> g...@jpl.nasa.gov (Erann Gat) writes:

> > ksh even has EVAL! I guess it must be just as good as Lisp!
>
> why? It serves a different purpose and does a pretty good job of
> it thats all. And no one said it was as good as CL for what CL
> does.

I thought it was obvious (since this comment came on the tail end of a
long exchange where I was taking the position that Lisp was superior to
"the traditional approach" of which ksh is a part) but for the record: I
was being facetious.

> > Well, I'm of to Google for a free native code ksh compiler. Wish me luck.
>
> Why would you expect anyone to create such a stupid thing for free? The
> closest thing I am aware of is the hamaltonian-csh(sp?) product(costs
> money) for csh and it does bytecode.

Again, I was being facetious. I never did search for such a thing, being
1) quite confident that it didn't exist and 2) not really caring if it did
since I have no intention whatsoever of switching from Lisp to ksh.
(Python maybe, but not ksh ;-)

> Here is how it is suposed to be done in unix:
>
> 1: write a script that does what you need
> 2: if it is fast enough stop
> 3: otherwise rewrite it in C(or C++ or CL or fortran ...)

Just to be clear: I am taking the position that when you program in Lisp
you (potentially) end up with a radically different mindset about
programming than when you program in "the traditional way", i.e. using
shells, C, C++, Java, and whatnot. I claim that the Lisp mindset is at
once powerful and limiting, powerful since it makes it easy to do many
things that are hard in the traditional approach, and limiting since it
makes it difficult (though not impossible) to interoperate with the vast
infrastructure that has evolved out of and been shaped by the limitations
of the traditional approach. (As an example of a feature that is a result
of the limitations of the traditional approach I cite the proliferation of
syntaxes and the ubiquitous necessity of parsers.)

Unfortunately, I was mistaken about one narrow aspect of unix shells: I
thought double-quotes, which are necessary in order to maintain the
integrity of argument boundaries in shells when using $() syntax to
emulate function calls, didn't nest. They do. But IMO this is a minor
detail, and we should not get too distracted by the fact that I am not a
shell wizard. It in no way refutes the broader point.

foomaster1200

unread,
Apr 10, 2003, 12:32:57 PM4/10/03
to
Ingvar Mattsson <ing...@cathouse.bofh.se> writes:

> d97...@dtek.chalmers.se (Jonas Öster) writes:
>
>> On 10 Apr 2003 10:35:48 +0100,
>> Ingvar Mattsson <ing...@cathouse.bofh.se> wrote:
> [SNIP]
>> Unix command lines are limited in size; what if cmd1 and/or cmd2 output
>> several megabytes of data?
>
> Then you lose. Badly.

Use something like bash's process substitution:

bar <(foo) <(baz)


--
I'm having a BIG BANG THEORY!!

Tim Daly, Jr.

unread,
Apr 10, 2003, 3:10:35 PM4/10/03
to

I would like to interject an observation here, if I may. I believe
that every interaction with a computer is a form of programming, and
that the more involved forms of programming are best done in Lisp.

Yeah, you can eventually do X in crufty language Y, even if you have
to write an embedded Lisp to do it. This is a mathematical, if not
always a pragmatic, truth.

Lisp is just a simplified, cleaned up, and documented version of every
programming language there ever was. All of the dollar-wakka-paren-
-pipe-quote in this thread just made me realize that again.

-Tim

--

kru...@kruhftwerk.dyndns.org

unread,
Apr 10, 2003, 4:00:43 PM4/10/03
to
Marc Spitzer <mspi...@optonline.net> writes:
> Here is how it is suposed to be done in unix:
>
> 1: write a script that does what you need
> 2: if it is fast enough stop
> 3: otherwise rewrite it in C(or C++ or CL or fortran ...)

That 3rd step is the one that is the biggest pain in the ass as I just
discovered after doing a project which explicity had to be delivered
in C. After writing a ~150 line bash script prototype, it ended up
being over 1500 lines of C, not including headers. The thought of
writing a shell script compiler just so I could send the client the
output did pass through my mind a couple of times...

I think the "way it is supposed" to be in unix is more along the lines
of:

1) write a script to do what you want
2) if it's fast enough and works, break
3) find out the slow parts and rewrite that part in C as a pipeable
program and replace the slow parts with a call to that

Rewriting all of a shell script is painful and not really what was
intended by the early unix developers. I see the whole collection of
unix utilities as a simple well documented callable library of
functions, and the unix "system" as a bunch of shell scripts tying
them together. Hell, all perl did was move all the unix utils and put
them in an interpreter...the schemantics are all the same.

Man, I'm not even 30 yet and the good old days are over and I wasn't
even able to use a computer. Maybe that's why I'm hanging out with
lisper's, so I can actually learn a few things that might last rather
than play cachup forever with something that will just dissappear the
next year (or isn't any different from the same thing that came out
last year except with different variable names and documentation
format).

--
burton samograd
kru...@kruhft.dyndns.org
http://kruhftwerk.dyndns.org

Johan Ur Riise

unread,
Apr 10, 2003, 4:29:10 PM4/10/03
to
d97...@dtek.chalmers.se (Jonas Öster) writes:

> On 10 Apr 2003 10:35:48 +0100,
> Ingvar Mattsson <ing...@cathouse.bofh.se> wrote:
>
> [shell scripts cut out]
>
> >ingvar@gruk$ /tmp/gat-demo $(/tmp/cmd1) $(/tmp/cmd2)
> >This
> >is
> >a
> >multi-word
> >repsone
> >from
> >cmd1
> >And
> >this
> >is
> >from
> >cmd2
>
> Unix command lines are limited in size; what if cmd1 and/or cmd2 output
> several megabytes of data?

Make sure the command line can take megabytes. For Linux, go to
./include/linux/limits.h
and change this
#define ARG_MAX 131072 /* # bytes of args + environ for exec() */
to whatever you like.

--
Hilsen
Johan Ur Riise

Barry Wilkes

unread,
Apr 10, 2003, 5:26:13 PM4/10/03
to

Yeah, just replace one fixed size buffer with another, bigger one. That'll fix
it. You could go through the whole of the Linux source 'fixing' problems like
that. Brilliant.

Sorry if what I'm replying to is some kind of joke that I just didn't see in
the original.

Barry.

Erann Gat

unread,
Apr 10, 2003, 5:00:06 PM4/10/03
to
In article <87he96w...@tenkan.org>, t...@tenkan.org (Tim Daly, Jr.) wrote:

> every interaction with a computer is a form of programming,

This is the Lisp mindset. Most of the world doesn't think this way. The
mainstream draws a sharp boundary between "programming" a computer and
"using" one. Almost every aspect of the mainstream mindset is a
consequence of this artificial boundary. The concept of "application" or
"executable binary" stems directly from this artificial separation of
programming and use.

Gisle Sælensminde

unread,
Apr 10, 2003, 6:37:06 PM4/10/03
to
In article <gat-090403...@192.168.1.51>, Erann Gat wrote:
> In article <slrnb99525...@apal.ii.uib.no>, Gisle
>=?iso-8859-1?Q?S=E6lensminde?= <gi...@apal.ii.uib.no> wrote:
>
>> It seems for me that you are assuming that you want to do the whole
> application
>> in Lisp. Fine if you can, but if you are using big portions of code that is
>> written in other languages, then you must interact with the environment in
>> some way.
>
> No, you have to interface to those programs. That's not quite the same thing.
>
> Nonetheless, perhaps you'd better re-read the very first sentence that I
> wrote in this exchange:
>
> "... Lisp does not play well in the traditional structure."

Well, I consider both foreign function calls, external programs called
form lisp as a part of the environment as long as it is not written in
lisp or use a lisp-like design. This could even include environment
variables and stream based IO.

I still use the interactive development, including interactive debugging
and loading code into a running lisp process, so even if I have to deal
with code that follows the traditional structure, I can still enjoy
interactive development for the part written in lisp.

I find the hostility against newbies quite horrible, since the lisp
community need to be renewed, and when they continue to learn lisp
they will usually learn the idiomatic way of doing lisp programming.
When I started programming lisp in my sparetime, I used to start
my lisp "scripts" by #!/local/bin/clisp when I was a lisp newbie.
After some time I found better ways of doing things. All good teatchers
know that calling their student an idiot is the best way of blocking
the learning process. Those willing to learn will eventually pick
up important points, flaming them is more suited if you want to scare
them away. That is not a good idea, the common lisp community needs
a critical mass of programmers to be kept alive.

The lisp idioms are as stated earlier in this thread, not documented, and
they are very different from everything else, and you can't expect
newbies to pick them up easily.

>> In a way I'm sitting on the shoulders of giants. Unfortunatly
>> those giants didn't use Lisp.
>
> Choose better giants next time. ;-)
>
> Seriously though, Lisp is not the best tool for all jobs (though it is a
> better tool for more jobs than most people realize). Perhaps your task is
> just not a good fit.

The kind of programming involves parsing and quite advanced data
processing processing, and the requirements evolves as the project goes.
This kind of programming is at least according to the textbooks a thing lisp
is good at.

If I only could use lisp where lisp is a good fit in that sense, I would
probably never use lisp, and like in the Lisp machine thread complaining
that the nostalgia isn't what it used to be. They may indeed be right, but
I want to do usefull things today, and todays environment don't involve
lisp machines.

> However...
>
>> One example is the queing system on some linux clusters. Queued job are
>> started, the way of telling where the input can be found, is through the
>> command line arguments,
>
> This doesn't sound like it should be a serious problem. In any case, it's
> a completely different issue than the original "command line arguments"
> issue. The original issue was all about passing command line arguments
> *to* Lisp, not from Lisp.

This is indeed about command line arguments to lisp, since I need to start
a lisp image on a node, and on that node need a lisp image is started, and
I need to give it information of where the input is. That happens through
command line arguments. Maybe not the job that lisp is traditionally used
for, but indeed there is a way of passing command line arguments. They don't
come from a user that is interactivly giving the command line arguments, and
then waits for output. The command line comes from the queue system that
merly use the command line argument mechanism for passing data to a node.

Michael Livshin

unread,
Apr 10, 2003, 7:08:39 PM4/10/03
to
Gisle Sælensminde <gi...@apal.ii.uib.no> writes:

> I find the hostility against newbies quite horrible

I find the hostility against newbies non-existent here.

I find the low tolerance of stupidity commendable, and a sign that the
active members of the community posess an aqute sense of quality.

I find the popular confusion between newbie-frendliness and
idiot-tolerance very unfortunate.

I find some hope in the thought that this confusion was not deliberate
on your part.

--
In an experiment to determine the precise amount of beer required to
enjoy this film, I passed out. -- dave o'brien, on Highlander II

Erann Gat

unread,
Apr 10, 2003, 7:40:25 PM4/10/03
to
In article <slrnb9bsgh...@apal.ii.uib.no>, Gisle
=?iso-8859-1?Q?S=E6lensminde?= <gi...@apal.ii.uib.no> wrote:

> This is indeed about command line arguments to lisp, since I need to start
> a lisp image on a node, and on that node need a lisp image is started, and
> I need to give it information of where the input is. That happens through
> command line arguments.

OK, this is not hard. Every Unix Lisp has some interface to command line
arguments, but they are all different. You need to consult the
documentation for the particular Lisp you are using.

As to:

> I find the hostility against newbies quite horrible

There is no hostility against newbies here; quite the opposite. There is
occasionally hostility towards the presumptuousness of asking questions
that make it obvious that the questioner has not bothered to do even the
most rudimentary research. At a minimum nowadays one should do a Google
search before asking anyone about anything.

E.

Andrzej Lewandowski

unread,
Apr 10, 2003, 9:20:41 PM4/10/03
to
On Tue, 08 Apr 2003 04:45:08 GMT, Thaddeus L Olczyk
<olc...@interaccess.com> wrote:


>
>"What I'm too lazy to learn Lisp, if I can't be bothered to learn
>Emacs. OK fine. Guess I'll learn Python instead. The Python crowd


>isn't going to make me waste my time learning a new editor when I
>don't even know if I like the language."
>

>Result: a programmer that blows off Lisp.

I am using Notepad. Blowing off Lisp for the lask of libraries.

A.L.

Luke J Crook

unread,
Apr 11, 2003, 4:07:41 AM4/11/03
to

"William Bland" <ne...@abstractnonsense.com> wrote in message
news:pan.2003.04.08....@abstractnonsense.com...
> On Tue, 08 Apr 2003 00:04:47 +0000, Erann Gat wrote:
>
> > In article <PAska.267$Hv2.24...@newssvr21.news.prodigy.com>, "Will
> > Hartung" <wi...@msoft.com> wrote:
> >
> > I have a little demo that I like to show people.
> [snip]
>
> Do you have a webcam? I would love to see a video of you doing
> this demo - it sounds very inspiring!

Preferably fully clothed, of course :)

Mario S. Mommer

unread,
Apr 11, 2003, 4:30:26 AM4/11/03
to
Andrzej Lewandowski <lewand...@attglobal.net> writes:
>
> I am using Notepad. Blowing off Lisp for the lask of libraries.
>

Folks!! Lisp has been ... *DISMISSED*!!!

Let's all sit down and have a massive weep. BOOHOOOO....

Will Hartung

unread,
Apr 11, 2003, 11:56:26 AM4/11/03
to
> 1) write a script to do what you want
> 2) if it's fast enough and works, break
> 3) find out the slow parts and rewrite that part in C as a pipeable
> program and replace the slow parts with a call to that

Actually, depending of course on the task, I'd not even do the C thing, but
rather dump into a more efficient scripting language.

> Rewriting all of a shell script is painful and not really what was
> intended by the early unix developers. I see the whole collection of
> unix utilities as a simple well documented callable library of
> functions, and the unix "system" as a bunch of shell scripts tying
> them together. Hell, all perl did was move all the unix utils and put
> them in an interpreter...the schemantics are all the same.

The clear benefit of shell scripting is that it is trivial to automate the
sequencing of external commands. The only problem with that is that the
price of the function call is just insanely high. Great for one off items,
but really lousy in tight loops.

The scripting languages help leap that barrier by providing, ideally, a
richer set of internal primitives that are cheap to execute compared to
external Unix calls.

For example, my "swiss army knife" Unix tool is awk (actually, nawk or gawk,
but...). I like the free field parsing and free main read loop, and the
syntax isn't dominated by the top row of the keyboad.

Idiomatically, I write a alot of shell scripts like this:
$ cd old
$ for i in *.ext
> do
> awk -f tmp.awk $i > ../new/$i
> done

Brain dead simple, and is fine if you're under 100 files or so. Get larger,
though, and the awk call gets expensive. In this case, I had to crawl over
3500 files across the file system. At that point I dig out the Perl manual,
relearn it (again), and bring the entire thing into Perl. ZAM! MUCH faster.

99.99% of the time it's unnecessary. 99.99% of the time, the over head of
the calls to the commands are vastly overtaken by the time spent within the
commands.

I don't use Perl normally because for what I do, I find it's hard to use. I
find that if I leave it for 6 months I completely forget the most basic of
things. I've yet to forget awk.

The biggest problem with the scripting languages is that while they have
rich primitives, they don't have the richness of the Unix utilities,
specifically in the "get me stuff easily out of files" level, and most
certainly don't make them as easy to use. So, it has to be a major step to
give up the Unix utilities and dive into a scripting language to make the
task worthwhile. Most of my efforts are one off scripts where the run time
is far far less than the development in anything else would be.


Joe Marshall

unread,
Apr 11, 2003, 4:21:26 PM4/11/03
to
Barry Wilkes <wil...@acm.org> writes:

> Johan Ur Riise <jo...@riise-data.no> writes:
>
> > Make sure the command line can take megabytes. For Linux, go to
> > ./include/linux/limits.h
> > and change this
> > #define ARG_MAX 131072 /* # bytes of args + environ for exec() */
> > to whatever you like.
> >
> Yeah, just replace one fixed size buffer with another, bigger one.

Sure. No one could ever need more than a million arguments.....


Harri Haataja

unread,
Apr 12, 2003, 9:51:26 AM4/12/03
to
Kaz Kylheku wrote:
> Peter Seibel <pe...@javamonkey.com> wrote in message

>> Hi, I'm curious how folks who don't who *don't* use emacs for their
>> Lisp development work.

> If I need to evaluate something from the editor, I do it the same way I
> have always done it for any language, such as the ``bc'' calculator. I
> pipe a bunch of lines to a command, which get replaced by the output of
> that command.

Facing a REPL wihout usable editing facilities, I often edis snippets
(like a defun/define) in a vim and just paste the code from one term or
window to another. In X, it's just a flick of a mouse. It would be nicer
to have it work with keys and an "invisible" interpreter like in emacs. I
guess vim could use some more remote-control features. (Yes, I've seen the
perl pipe mentioned in those vim/lisp things everything points to.)

>> What's do people would be the quickest path for, say a experienced vi
>> user, new to Lisp to get up an running? Is there anything like ILISP
>> for vi?

> If you want freeware, CLISP is nice for beginners because it has a REPL
> based on GNU readline. So you have command history and tab completion.

And obeys .inputrc and thus can get vi bindings? (I never tried that)

> Also it might be useful to teach students how to save and restore a Lisp
> image. Lisp images should be intuitive to anyone who is familiar with
> desktop applications, because basically that is where the idea comes
> from.

.. and which causes an infinite number of problems. I, like many, will
always favour a language in a plain text file I can use all my tools on
over an application if the task is anything that can be done with a
compiler or such (for example LaTeX over any disgusting wysiwyg editor).

> I would also give the students demonstrations of a variety of Lisp
> systems from different vendors on different platforms, so they don't
> confuse the implementation for the language.

A very important and usually sorely missed point. A language or a paradigm
without a working implementation is just a mental model.

--
War is Peace
Slavery is Freedom
Backspace is Delete.
-- Currently unattributed .sig

Johan Ur Riise

unread,
Apr 12, 2003, 12:09:39 PM4/12/03
to
Barry Wilkes <wil...@acm.org> writes:

> Johan Ur Riise <jo...@riise-data.no> writes:
>

> > #define ARG_MAX 131072 /* # bytes of args + environ for exec() */

> Yeah, just replace one fixed size buffer with another, bigger one.

Shell scripting of course has other limitations compared to CL, but there
are not too many arbitrary fixed buffer size limitations.

sv0f

unread,
Apr 14, 2003, 11:14:49 AM4/14/03
to
In article <gat-080403...@k-137-79-50-101.jpl.nasa.gov>,
g...@jpl.nasa.gov (Erann Gat) wrote:

>(DEFMETHOD VIEW-CLICK-EVENT-HANDLER ((D DRAGGABLE) LOC)
> (PROGN (IF (DOUBLE-CLICK-P)
> (INSPECT D)
> (WHILE (MOUSE-DOWN-P)
> (LET ((P (VIEW-MOUSE-POSITION D)))
> (WHEN (NOT (= P LOC))
> (SET-VIEW-POSITION D (+ (VIEW-POSITION D) (- P LOC)))
> (WINDOW-UPDATE-EVENT-HANDLER (VIEW-CONTAINER D))))))))

I was at a conference on programming languages this weekend
and a Lisper used exactly this code to wow a non-Lisper!
USENET posts propagate memes faster and farther than I thought.

Three questions:

(1) Why the extra PROGN?

(2) Is WHILE just macro-based syntactic sugar for WHEN?

(3) How many people use (WHEN (NOT ...) ...) instead of
UNLESS around here? My eyes parse the former more readily
but I force myself to use the latter for the sake of
specificity. Perhaps I am just being masochistic.

Kent M Pitman

unread,
Apr 14, 2003, 11:38:36 AM4/14/03
to
sv0f <no...@vanderbilt.edu> writes:

> In article <gat-080403...@k-137-79-50-101.jpl.nasa.gov>,
> g...@jpl.nasa.gov (Erann Gat) wrote:
>
> >(DEFMETHOD VIEW-CLICK-EVENT-HANDLER ((D DRAGGABLE) LOC)
> > (PROGN (IF (DOUBLE-CLICK-P)
> > (INSPECT D)
> > (WHILE (MOUSE-DOWN-P)
> > (LET ((P (VIEW-MOUSE-POSITION D)))
> > (WHEN (NOT (= P LOC))
> > (SET-VIEW-POSITION D (+ (VIEW-POSITION D) (- P LOC)))
> > (WINDOW-UPDATE-EVENT-HANDLER (VIEW-CONTAINER D))))))))
>
> I was at a conference on programming languages this weekend
> and a Lisper used exactly this code to wow a non-Lisper!
> USENET posts propagate memes faster and farther than I thought.
>
> Three questions:
>
> (1) Why the extra PROGN?

It's harmless. It might be vestigial. It might be someone doesn't know
it's not needed. It might be it's the result of a macroexpansion in a
macro. The topleve of a defmethod is an implicit progn anyway, so it would
never be needed, but the (IF (DOUBLE-CLICK-P) ...) might be a macro expansion
result that was potentially for some other context. Btw, the fact that it's
in all-uppercase suggests something like macroexpansion. No one but me
actually seems to write in uppercase much any more.

> (2) Is WHILE just macro-based syntactic sugar for WHEN?

It's probably (loop while ... do ...).
I don't know though.



> (3) How many people use (WHEN (NOT ...) ...) instead of
> UNLESS around here?

I do it a lot, but I use UNLESS a lot. Just as in English I might sometimes
say "When you're not here, I'm lonely." and other times say "Unless you're
here, I'm lonely." They mean the same thing, but they have subtly different
connotational senses.

> My eyes parse the former more readily
> but I force myself to use the latter for the sake of
> specificity. Perhaps I am just being masochistic.

It may depend on the complexity of the expression. There is good hard
psychological evidence that if you are in a deeply nested expression,
it costs you short-term-memory space (at least for parsing, maybe for
other later understanding) to hold onto the 'not' token. If you
believe (as some of us do) that there are 7 +/- 2 short term memory
cells (or any small finite number), then using an extra slot reduces
the number of complex parses you can do. If that isn't going to be
enough to keep you from parsing, you will not see the effect. But in
some complex cases, the reduction can be enough to make the parse
fail, as in the way garden path sentences fail. The theory suggests
that some sentences (or lisp expressions) involving 'unless' that are
not garden path sentences might become so with the change from
'unless' to 'when not'.

The underlying structure for WHEN NOT looks like

yes
/
input ----> negate ---> test
\
no

while that for UNLESS looks like

no
/
input ----> test
\
yes

So you can see that UNLESS is structurally simpler (just a flipped set of
branches, no actual time spent in doing negating). Of course, a good compiler
will get rid of this difference. But your brain may not be a good compiler.

Giorgos Keramidas

unread,
Apr 20, 2003, 6:21:06 AM4/20/03
to

None will ever need more than 640 KB of physical memory either :P

Seriously, this very moment the number of files in /usr/src on a typical
FreeBSD workstation that has all the sources is in the thousands:

$ find /usr/src -type f | grep -v 'CVS$' | wc -l
28948

It's not hard to imagine crossing the million boundary with the entire
disk. You could, of course argue that an iterative solution is better
and I'd probably agree, but that's another thing.

It is loading more messages.
0 new messages