From: Christopher C. Stacy
Subject: Why Lisp is too hard for me to use
Date: 
Message-ID: <uisk6ub8o.fsf@news.dtpq.com>
I would like to relate the following comments and suggestions to the
kind people who maintain the various downloadable libraries for Common
Lisp, particularly those aimed at the CLISP/CMUCL/SBCL users.

1. Your software for utility libraries like networking, 
   FFI, OS interfaces, GUIs, and so on, is just what
   is needed for people who want to use Lisp.

   People expect this to be available out-of-the-box,
   as it is (they believe, anyway) for all the other
   major languages.

   So it's great for Lisp that you are providing this.

2.  Your software is TOO HARD to download and use.

My remarks will echo some of the sentiments that are occasionally
expressed by newbies here from time to time.  I think the reasons
that you don't here these complaints continuously are:

1. Most people have already exhausted all their energy trying to
   figure it out, and by the time they get this far, any interest 
   they had in using Lisp has already been exhausted.
   They give up and just go away, and you never hear from them.

   If they're not already Lispniks, they decide NOT to use Lisp.

2. Most people are afraid of appearing too be stupid to figure
   this out.  (And the Lisp community has somewhat of a reputation
   for elitism, which makes it even worse.)

3. Aside from a small and definitely annoying minority, 
   most people don't want to appear to be ungrateful plaintive
   "gimme" jerks who are demanding even more of your time.

Of course I'm not a newbie, and I don't care about (2), and I 
am sure that my comments will be taken as the positive criticism 
that it's meant to be, knowing that I am someone who appreciates 
the work that folks have already put into these public-minded
endeavours.

So I will tell you that I fall into category (1).

By and large, this doesn't affect me personally very much,
because I do most of my work using commercial Lisp products
and using my own libraries that I've written over the decades.

But I can't figure out how to download all this free stuff.
Furthermore, speaking to a number of experienced (> 20 years)
programmers, including both some who are Lisp newbies and
potential converts, as well as some who have used Lisp, 
I can safely assert that I am definitely not in the minority.

If you are trying to promote Lisp, you need to better "sell it",
in a very specific way.  You need to make it easy enough to
obtain and get into -- without a lot of arcane knowledge of Lisp --
and without a lot of arcane knowledge of distributed software
development.  Yes, I am sure you think that the procedures for
obtaining and installing this software is all standard, well-known,
well-documented knowledge.  I'm here to tell you that it is not.

Today I've been trying for several hours to figure out how to 
get CLOCC and use it on my RedHat Linux machine with CLISP.  
This is by no means my first foray into this nightmare.
While doing this, I got a call from another guy trying 
to do essentially the same thing with CMUCL.  On Sunday I
had a a call from someone else in the same boat with Corman.

We're all lost.

It's just too hard.  

There is too little documentation, or too much documentation, 
and it's too hard to figure out where to go and what to read 
and how to do it. 

It is simply too overwhelming to figure out how to download 
and install any of these packages.

The result is that I can't recommend to anyone that they 
use these libraries (and transitively, any Lisp systems 
other than Xanalys or Franz which have bundled their own 
proprietary platform/utility solutions.)

What is needed is a simple installation and distribution system.

If such a thing exists, I don't know where it is, or how to find it.
I am not willing to spend hours researching Google, chasing down
links, making guesses, trying experiments, starting over, etc.

The following may help clarify the problem.
Here is a profile of your target audience:

* We DON'T understand SourceForge, we don't have or want CVS, 
  and, sorry, mostly we don't run Debian.  We may or may not
  have bzip, and we probably don't know even about it, if we do.

If you want your libraries, and Lisp, to be used only by people 
who are willing to invest in those searching, locating, downloading
and installing ways of life, then you can stop reading right now 
(and kiss the largest portion of the community goodbye).

* We DO have Linux or BSD or Windows: we understand tar files, 
  gzip, Winzip, Windows installers, CPAN, RPMs, and BSD ports.
  (But we hate BSD ports. :)

  Some of us have been downloading, compiling, installing,
  and configuring large packages (such as the GNU suite
  and Emacs) for years, before things like RPMs were invented.
  But some of us can not deal with anywhere near that complexity,
  and need to have a single "self-everything" installation.
  Either way, we're not idiots.
  (We wanted your libraries, right? :)

In other words, the ONLY acceptable solution is the SAME as
for all the other software that we use (for Perl, JAVA, and C).
There has to be a series of mostly self-installing download 
distributions, and simple documentation to tell what we need.

I mean a series of tar files that includes the build scripts under 
the standard native shell (eg. GNU Makefiles, or .BAT files).
Of course, an automatic installation system (such as RPM) would be better.
And there needs to be documentation for each system that tells you what
other tar'd systems will need to be installed first.  Something like
CPAN would of course be the best, but that booting module itself needs
to come to us in the above self-contained manner.

If there are clear-cut solutions that already exist for these issues,
then they are just not sufficiently documented.

I am not looking for anyone to educate me here.
Please do not respond by telling me what I need to learn,
or how I missed the obvious documentation.

Rather, I am TELLING YOU what people are willing to do, 
and what they can figure out with what you have provided
to them.  Certainly you are under no obligation to do 
anything, and whether you are interested in catering to 
that community is entirely up to you.  I'm just informing
you of the requirements of the major part of the universe,
should you happen to be interested.

This probably came off sounding rather nasty or harsh, but I would
like to again emphasize how nice it is for people to have put this
stuff together.  The bottom line is that you are appreciated, but
if you want to know the truth: it's not good enough for most users.
But I didn't want to mince words, and I certainly hope you find 
this to be useful feedback.

In any event, thanks again for all your hard work.

From: Thomas F. Burdick
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <xcvu13qocuy.fsf@famine.OCF.Berkeley.EDU>
······@news.dtpq.com (Christopher C. Stacy) writes:

> 2.  Your software is TOO HARD to download and use.

Several times, when I was still fairly new to Lisp, I tried getting
things from CLOCC, and had the same reaction you had.  Since then,
I've stayed clear of it.  Have you actually had a lot of difficulty
with non-CLOCC libraries?

> The result is that I can't recommend to anyone that they 
> use these libraries (and transitively, any Lisp systems 
> other than Xanalys or Franz which have bundled their own 
> proprietary platform/utility solutions.)
> 
> What is needed is a simple installation and distribution system.
> 
> If such a thing exists, I don't know where it is, or how to find it.
> I am not willing to spend hours researching Google, chasing down
> links, making guesses, trying experiments, starting over, etc.

It's not prime-time yet, but there's a start; try asdf (a defsystem
replacement) and asdf-install:

  http://www.cliki.net/asdf-install

The package list isn't what it should be, but it does seem to be
growing.  Unfortunately it's currently SBCL-specific, but there's talk
of starting to ship CMUCL with it.  There's no reason it couldn't be
ported to CLISP, either.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Rahul Jain
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87isjz9hjp.fsf@nyct.net>
······@news.dtpq.com (Christopher C. Stacy) writes:

> * We DON'T understand SourceForge, we don't have or want CVS, 
>   and, sorry, mostly we don't run Debian.  We may or may not
>   have bzip, and we probably don't know even about it, if we do.

Unfortunately, Debian is the only way we can integrate the packages we
provide into the host package management system seamlessly, so you can
easily browse and install lisp libraries just like anything else you'd
want.

Also, it's far easier to put the basic bits needed to support this stuff
into the distribution when the distribution is maintained by a user
community. The people who package cmucl, etc for Debian are lispers and
use all these other libraries, too. It also helps that none of us have
much interest in ever maintaining a RedHat box over the long term.

So if someone who actually uses RedHat AND cares about these libraries
is interested in developing a solution for RedHat (we never needed to do
anything of the sort, as the solution is already intrinsic in debian),
please do so. We've been asking for years and have repeatedly only ever
received comments indicating that some people might use it, but no one
cares to create it. Please understand that we're not making money off
this stuff nor do we use the systems you want us to support, so there's
no reason for us to do it.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Rahul Jain
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <874qvqpze6.fsf@nyct.net>
······@news.dtpq.com (Christopher C. Stacy) writes:

> * We DON'T understand SourceForge, we don't have or want CVS, 
>   and, sorry, mostly we don't run Debian.  We may or may not
>   have bzip, and we probably don't know even about it, if we do.

Unfortunately, Debian is the only way we can integrate the packages we
provide into the host package management system seamlessly, so you can
easily browse and install lisp libraries just like anything else you'd
want.

Also, it's far easier to put the basic bits needed to support this stuff
into the distribution when the distribution is maintained by a user
community. The people who package cmucl, etc for Debian are lispers and
use all these other libraries, too. It also helps that none of us have
much interest in ever maintaining a RedHat box over the long term.

So if someone who actually uses RedHat AND cares about these libraries
is interested in developing a solution for RedHat (we never needed to do
anything of the sort, as the solution is already intrinsic in debian),
please do so. We've been asking for years and have repeatedly only ever
received comments indicating that some people might use it, but no one
cares to create it. Please understand that we're not making money off
this stuff nor do we use the systems you want us to support, so there's
no reason for us to do it.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Don Geddis
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ekuu9itk.fsf@sidious.geddis.org>
······@news.dtpq.com (Christopher C. Stacy) writes:
> CLISP/CMUCL/SBCL users.
> 2.  Your software is TOO HARD to download and use.
> What is needed is a simple installation and distribution system.
> * We DON'T understand SourceForge, we don't have or want CVS, 
>   and, sorry, mostly we don't run Debian.  We may or may not
>   have bzip, and we probably don't know even about it, if we do.
> * We DO have Linux or BSD or Windows: we understand tar files, 
>   gzip, Winzip, Windows installers, CPAN, RPMs, and BSD ports.
>   (But we hate BSD ports. :)

It's too bad you rule out Debian, because CMUCL is especially easy there.

But OK, I'll give it a try.  Headed to Google, typed "CMUCL".  First link is
        www.cons.org/cmucl/
the home page of CMUCL.  Index bar on the left-hand side has an item called
"Download" which takes me to
        http://www.cons.org/cmucl/download.html
This mentions a number of mirrors for sources and binaries.  But that's too
difficult for you.  The second section says "Alternative binary distributions".
No, don't want FreeBSD...no, you've already rejected Debian...apparently
there's some "alien" thing that will convert a Debian .deb to an .rpm, but
perhaps that's too difficult and you don't want to bother.  Ah!  Here goes.
The third "alternative" link is that CMUCL is "available in RPM format"
thanks to Miles Egan.  Sounds great!  Click on the link to
        http://www.caddr.com/lisp/
and you find source and binary Redhat RPMs for CMUCL 18c, 18d, and 18e.

That took less than 30 seconds.  Seems like exactly what you were asking
for.  How hard did you try?

> I am not looking for anyone to educate me here.
> Please do not respond by telling me what I need to learn,
> or how I missed the obvious documentation.

I'm not sure how anyone can help you, then.  I suppose you're not looking for
help, but merely reporting on observed problems in user-land.

Perhaps.  But since there _are_ solutions, just like you want, perhaps you
can be more constructive and say how to improve the solutions that exist so
that users aren't as confused as you believe they are today.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
No man ever steps in the same river twice, for it's not the same river and he's
not the same man.  -- Heraclitas
From: Christopher C. Stacy
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ullp1alnw.fsf@news.dtpq.com>
>>>>> On 24 Dec 2003 10:22:47 -0800, Don Geddis ("Don") writes:
 Don> How hard did you try?

How nice for you.

Average time spent by the people I talked to: three to 
six hours before they gave up.
From: Christopher C. Stacy
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <uhdzpal5y.fsf@news.dtpq.com>
>>>>> On 24 Dec 2003 10:22:47 -0800, Don Geddis ("Don") writes:
 Don> perhaps you can be more constructive and say how to improve the
 Don> solutions that exist so that users aren't as confused as you
 Don> believe they are today.

What you have done, Don, is to recite to me your experience
in solving a different problem than the one that I reported.
Then you suggested I should change operating systems, and
then gave a wisecrack about how it took you thirty seconds 
to do this, how perhaps I didn't try very hard, or there's
something wrong with me, or perhaps I could be "more constructive"
and say how to improve the solutions.

I was not trying to download CMUCL, but rather certain libraries;
changing operating systems is not an option; and I did offer some
specific suggestions as to what kind of download procedures and
formats would be more palatable.

I don't plan on reading any more of your messages.
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <w4cisk5yb34.fsf@haddock.cd.chalmers.se>
······@news.dtpq.com (Christopher C. Stacy) writes:
> I was not trying to download CMUCL, but rather certain libraries;
> changing operating systems is not an option; and I did offer some
> specific suggestions as to what kind of download procedures and
> formats would be more palatable.

I know you don't really want /help/, per se, and I can understand that
the difference in installation procedures for different libraries
might throw one for a spin; your initial post is, IMO, a very fine
problem statement. It's being worked on, as others have written;
asdf-install is, though not yet deployed for very many Common Lisp
implementations, quite a bit on the way to CPAN goodness (personally,
I have problems with CPAN, but I really don't know Perl, and am just
installing software for others).

I find CLiki invaluable in that it contains links to lots of cool
stuff, but that isn't the problem you're talking about, though it is a
great solution of a different problem (finding all that good stuff).

The main reason /I/ see why the same approach as all other software
uses (makefiles, shell scripts and .BAT-files) isn't widely used is
that most free CL implementations are more or less in a state of
flux. Stuff changes, in slight and sometimes incompatible ways. If
there is a makefile or a shell script, it's often (from what I've
seen) most difficult to fix small stuff, and even to see what the
problem is. If you use a in-Lisp approach (be it MK:DEFSYSTEM, ASDF or
some load-/compile-file written to suit the task at hand), it's a lot
easier to fix and diagnose slight breakage, /if/ you know more than
just a bit about your system. With makefiles, it's a lot more bother,
and especially so for a novice (with the particular system). At least,
that's /my/ experience. (I'd like to write something about it being
nicer to get "Stuff broke; these are the parts, what now?" than "Stuff
broke. I threw it away. Fix and start over, or give up/wait for the
next release.", but most people know that, and I can't put it in a
non-obnoxious way, I'm afraid.)

People (and I) have mentioned asdf-install; another project that
sounds like it'll really fit your description is Dan Barlows cirCLe,
if it gets off the ground. (I think, actually, asdf-install is a part
of the infrastructure for that bigger project.)

I'm mostly on Debian/x86, so I don't see a lot of the problems. I also
primarily use CMUCL (mostly the snapshots, not the Debian-supplied
version), so I do see some. Most of the time, I don't find fixing
the problems that arise very hard. I'd like to help. I really don't
know how, though. Major infrastructure is a bit beyond me, being a
long time newbie, not involved in any real project, and usually
woefully behind in the newsgroups and mailing lists.

This might be silly, but what are your suggestions as to what I do to
make the situation less unbearable? English isn't my first language,
but I think I can write understandably. I do know a fair bit about CL,
un*x systems, and shell scripting. Should I try to start writing
alternative installation documents? Alternative installation scripts?
Package up a CMUCL-extra-extras, with pre-compiled modules you'd drop
in $CMUCLLIB? Try harder to stay afloat with mailing lists and
newsgroups, and actually post rather than just read, even though my
"solutions" might not be the cleanest or the Right Thing (since I have
yet to really understand MK:DEFSYSTEM or ASDF)?

The preceding paragraph does seem a bit provocative. It isn't actually
meant to be. It's /definitely/ not meant as an attack. I would like to
know what I, as a mere user, could do. On a case-by-case basis I'm
fairly certain I can help people with installation. Actually telling
people how to /use/ the libraries/apps might be a different issue.

The main problem I've always seen with CL libraries is the sheer
profusion of different solutions to problems, and no actual de facto-
standard. Want to do a GUI? There are dozens of toolkits, in differing
states of either flux or decay, often two or three different versions
of the more interesting ones. XML libraries, HTML generators or
frameworks, web servers, regexp libraries, defsystem variants...

There doesn't seem to be enough of us to make one of either a clear
winner, or even "the most popular". Yet. I /do/ think things will
stabilize, soonish. It's kind of ironical having early adopter-trouble
with a language as old as Lisp, but I think that's what we're seeing.

Regards,

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that
is beautiful.  -- Neal Stephenson, _In the Beginning was the Command
Line_
From: Christopher C. Stacy
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <uzndh5tpz.fsf@news.dtpq.com>
>>>>> On 25 Dec 2003 01:50:39 +0100, Martin Rydstr|m ("mr") writes:

 mr> I know you don't really want /help/, per se, and I can understand that
 mr> the difference in installation procedures for different libraries
 mr> might throw one for a spin; your initial post is, IMO, a very fine
 mr> problem statement. It's being worked on, as others have written;
 mr> asdf-install is, though not yet deployed for very many Common Lisp
 mr> implementations, quite a bit on the way to CPAN goodness (personally,
 mr> I have problems with CPAN, but I really don't know Perl, and am just
 mr> installing software for others).

Some of the things I've read here are very encouraging!

(I've been programming almost exclusively in Lisp full-time for the
past 23 years, so I know that if I find some of these things rather
frustrating, it's gotta be terribly discouraging for new people.
And indeed that's what I hear from almost everyone I've turned
on to using Common Lisp in the last couple of years.)

(I think it's great that people are volunteering on this stuff.
I wish I had time to work on it, but I pretty much used up
this week's free time on just filing that marketing-oriented
"bug report".)
From: Don Geddis
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87r7ys7qvw.fsf@sidious.geddis.org>
I wrote:
>  Don> perhaps you can be more constructive and say how to improve the
>  Don> solutions that exist so that users aren't as confused as you
>  Don> believe they are today.

······@news.dtpq.com (Christopher C. Stacy) writes:
> What you have done, Don, is to recite to me your experience
> in solving a different problem than the one that I reported.

Ah.  My mistake.

Since you made the subject line be "why _Lisp_ is too hard", I got confused
into believing that you had some problems with installing and using Lisp.

Apparently that's not the case.  Despite your subject line, you (and your
friends) _don't_ have any problems installing and programming in Lisp.
(It might have helped clarify things if you had said so.)

Instead, your concern apparently is with installing and using free
open-source contributed libraries, that happen to be written in Lisp.

I guess I'm not as surprised that installing a random programmer's freely-
offered code might take a bit of effort.  But at least you don't have a problem
with Lisp itself, installing or programming in it.

> Then you suggested I should change operating systems, and
> then gave a wisecrack about how it took you thirty seconds 
> to do this, how perhaps I didn't try very hard, or there's
> something wrong with me, or perhaps I could be "more constructive"
> and say how to improve the solutions.

I was much more constructive with you than you're giving me credit here.
I didn't just say it took me 30 seconds: I showed the exact steps I took,
which in each case were the obvious, uneducated ones.  My question was,
how were you not able to follow this same path yourself?

It isn't that I was making wisecracks.  The only issue was your goal:

> I was not trying to download CMUCL, but rather certain libraries;

This no longer seems to be something about Lisp (the language), though.  Now
it's about the user community.  Lisp implementors shouldn't be held
responsible for what Lisp users choose to do independently.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
From: Stephen J. Bevan
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m33cb4glyp.fsf@dino.dnsalias.com>
Don Geddis <···@geddis.org> writes:
> Apparently that's not the case.  Despite your subject line, you (and your
> friends) _don't_ have any problems installing and programming in Lisp.
> (It might have helped clarify things if you had said so.)

The first paragraph in the message was :-

  I would like to relate the following comments and suggestions to the
  kind people who maintain the various downloadable libraries for Common
  Lisp, particularly those aimed at the CLISP/CMUCL/SBCL users.

I'm not sure how much clearer it could have been.
From: Eladio
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <vh7k0midg0.fsf@Cagafuego.opasia.dk>
Amen - preach it, brother!

I'm a newbie - rank amateur all the way, but grossly infected with the
lisp-bug, and I definitely echo the sentiment that the free-lisp environment
needs to be more easily accessible. It's not a question of dumbing it down for
the masses, but simply of making it user-friendly. My time is precious, and
frankly I'd rather crank out code than wasting hours just trying to install a
half-assed getopt-library.

How hard can it be to create a package management tool that downloads wanted
items plus dependencies, compiles the whole nine yards and dumps them in the
right directories and insert the appropriate lines in the config files if need
be? On FreeBSD, the basic CLOCC bundle is actually available in the port
system, and installed nicely. But it at the end of the compilation the
pkg-desc file had told me *exactly* how to call the bundle from lisp, I
wouldn't have wasted 2 days trying to get it right. (And #lisp was useless,
natch)

So I went to the CLOCC page to get the full cllib system, and finally figured
out I should download the nightly *snapshot* in order to get a tar-bundle. To
be brutally honest, that never crossed my mind because I figured snapshots
were caustic, volative development versions which would probably land me in
heaps of troubles if I even managed to get it installed in the first place.

So I untarred the whole nine yards, and now being somewhat familiar with the
manner in which /usr/local/lib/common-lisp was set up, I moved the clocc/
directory to there - on a hunch. Again, why didn't the README say that in
flaming red letters? "Warning: this is not a makefile like you know it from
C. Move the crap into your asdf:central-registry path - and here's how you
find that out via your lisp prompt. Blah blah blah." In fact, would it have
been too much trouble to create a script which automated the process?!

Of course, to actually USE the cllib package, you need to compile it - which
of course requires obscure knowledge of *metering*, *defsystem*, *asdf* and
other no-doubt fabulous utilities, which the newbie has never heard of
before. Result? Hours wasted in maddening frustration to get the stuff
*compiled*!

"2. Edit the logical hosts definitions in the file "clocc.lisp" in the
   top-level directory according to your configuration."

Huh?! Logical hosts definitions?! I scanned like a obsessed for urls in that
file. The only thing that came somewhat close was the *clocc-root* variable,
but that was far from obvious. 

"make clocc-top" prompted me with the following screed:

"Makefile", line 7: Could not find /clocc.mk
"Makefile", line 11: Missing dependency operator
"Makefile", line 12: Missing dependency operator
"Makefile", line 14: Need an operator
"Makefile", line 19: Need an operator
"Makefile", line 26: Need an operator
make: fatal errors encountered -- cannot continue

Again, hours squandered digging into the right files and trying to set the
right variables - to no avail, of course.

So finally I went gaga and decided to try the alternative route and followed
the instructions to compile it from within my lisp system. And lo-and-behold!
It worked! In both clisp and cmucl thank you very much!

Now, can anyone tell me why some shmock didn't bundle all those instructions
into a SINGLE, convenient function call - (load-clocc) or something?!

So now it was all compiled, and there was much rejoice. Then like the fool I
am, I figured I could actually savor my victory by checking out some functions
in my new-fangled libs:

[1]> (load (translate-logical-pathname "clocc:src;cllib;animals"))
;; Loading file /usr/local/lib/common-lisp/clocc/src/cllib/animals.fas ...
;;  Loading file /usr/local/lib/common-lisp/clocc/src/cllib/base.fas ...
*** - TRANSLATE-LOGICAL-PATHNAME: unknown logical host "PORT" in
#S(LOGICAL-PATHNAME :HOST "PORT" :DEVICE NIL :DIRECTORY (:ABSOLUTE) :NAME
"SYS" :TYPE NIL :VERSION NIL)
1. Break [2]> :a

[3]> (load (translate-logical-pathname "clocc:src;cllib;base"))
;; Loading file /usr/local/lib/common-lisp/clocc/src/cllib/base.fas ...
*** - TRANSLATE-LOGICAL-PATHNAME: unknown logical host "PORT" in
#S(LOGICAL-PATHNAME :HOST "PORT" :DEVICE NIL :DIRECTORY (:ABSOLUTE) :NAME
"SYS" :TYPE NIL :VERSION NIL)
1. Break [4]> :a

1. Break [6]> (load (translate-logical-pathname "clocc:src;cllib;html"))
;;   Loading file /usr/local/lib/common-lisp/clocc/src/cllib/html.fas ...
;;    Loading file /usr/local/lib/common-lisp/clocc/src/cllib/base.fas ...
*** - TRANSLATE-LOGICAL-PATHNAME: unknown logical host "PORT" in
#S(LOGICAL-PATHNAME :HOST "PORT" :DEVICE NIL :DIRECTORY (:ABSOLUTE) :NAME
"SYS" :TYPE NIL :VERSION NIL)
2. Break [7]> a:

AAAAAAAAAAAAARRRRRRGGGGGGHHHHHNNNNNNN!!!!! * Simpson-style tongue-rattle*

This can't be happening!!! What on EARTH does this mean?! So after 5 days of
playing around with the coolest programming language I've ever had the
pleasure to work with, I was back to square one. (Incidentally, if anyone has
a clue, I'm buying!)

Now I've downloaded lisp-utilities.ps, and plan on digesting it at the rate of
one tool per day, and then plunge into the whole set-up to tackle it
line-by-line. That is, once I've gotten defpackage to work with my personal
raft of baby-utilities and figured out the intrinsics of eval-when, and other
amigos in the HyperSpec.

Frankly guys, this is too much. You spend so much of your time and efforts to
divine these great utilities, libraries and implementations, but what's the
use if no-one but a handful of insiders get to use them? 

I'm gonna stick to this like fly on shit until I got it down pat - but *only*
because I can't afford a commercial lisp system. Going through "Symbolic
Computation" was a revelation, and "OnLisp" is opening on a whole new world
for me. Lisp dazzles me every step of the way; it's like finally finding that
left-handed hammer in a world of righties. But daaayme, gurl; keepin' that
enthusiasm hot and steamin' is some piece of work.

Here's what could make the ride a tad more pleasant than the cold plunge into
the abyss I've experienced:

 * Instructions when needed. I'm not asking for the Great American novel, just
   a lousy roadmap. If your granny can't install it, it's too hard. But even
   granny knows how to to use "cp", "make" and "cd".

 * Tools with simple interfaces. Perl has 'perl -MCPAN -e 'install FOO', which
   I turned into a simple shell alias; "cpan". Works like a charm. Lisp can't
   be that much harder than Elisp, and I've *never* had problems getting new
   Emacs packages. Asdf-install sounds great, as does cclan-get. But please,
   make them just a tad more accessible.

 * Basic tutorials. "Packages For Dummies" was unnecessarily complex. As a
   newbie, I haven't yet wrapped my head around the concepts of symbols, so
   puh-lease don't lecture me about it. You waste your time. What I want is
   simple boilerplates showing me the rudiments, like a sample defpackage I
   can just cut-and-paste and pluck in my own functions. That's MORE than
   enough, and if I want more, I can always jump into the HyperSpec, or ask on
   #lisp for the skinny.

 * Basic roadmap-to-lisp. I don't care where YOU are coming from, or how much
   cooler your resume is than mine. I want to know how to find my
   way. Something like a Starter's Guide would be nice: read this, and this
   and this in that order, create some projects, then install this gizmo and
   learn about defsystem through this excellent tutorial. This presupposed the
   existence of the above, of course.

I'm gonna make a little "diary of a newbie lispnik" of my little journey here,
and jot down all my woes and frustrations along the way, and make it available
on cliki or wherever. And I'll gladly create the little tools along the way
that would make life easier - or even possible! But it's damn hard to get over
the first few humps and even out of the starting block, so if more experienced
folks would like to pave the way for the next gen, be my guest. I do realize
you're all busy people, and I'm asking for a luxury. But it's a question of
whether you'd rather waste time on pathetic newbies who can't figure anything
out, or add a little more professionalism to the tools that already exist.


Thanks for starting this topic, Christopher.

And if anyone knows the answers to my lastest problem, please do speak out. 
Oh - and how do you start Hemlock?! Thanks for your consideration.

-- 
                            o      _     _         _
------- __o       __o      /\_   _ \\o  (_)\__/o  (_)        -o)
----- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/     /\\
---- (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_  _\_v
Don't Drive And Pray - Listen To InfidelGuy.com And Rock Your Mind
From: tony
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <34175232.0312240826.12eb17b7@posting.google.com>
i have begun the process (hopefully not too long of a process) of
trying to "learn lisp".  i'm using the Xanalys and Franz products on
w2k and redhat 9.0 as well as the CLISP downloads.  while i like the
tools that come with the commercial products, i'm trying to grow my
understanding of the programming process as a whole (i haven't been
programming for long and am trying to wrap my aged brain around these
concepts) and feel that getting to the level of interaction necessary
with the freely distributed products will be beneficial.  i also don't
have the scratch to pay for the unrestricted commercial products yet. 
that being said...

i'd have to agree that the process has proven somewhat difficult.  i
tried to get the Garnet toolkit up and running and found a paucity of
understandable (to my simple mind) documentation on how to make the
damned thing work.  as a result, my attempts of installing Garnet on
Redhat led to a break of the Lispworks and CLISP installs.  I had to
rebuild the system (OS and such) from scratch... which is ok 'cause
every attempt leads me to more knowledge.

i know that the development has ceased on Garnet.  i also know there
is documentation that comes with the product.  most of what i've been
able to extract from that documentation has to do with the tools
available and not about installation related issues.  i also now know
that CLISP comes with MIT-CLX and NEW-CLX as well as an FFI and socket
interfaces.  i was able to find a website that has the manual for CLX
available as an http interface.  so...

again, while i agree that this can prove itself a frustrating process,
i believe that there is gold on the other side and am willing to
accept the frustration... for now.

peace
From: Thomas F. Burdick
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <xcvoetyngeh.fsf@famine.OCF.Berkeley.EDU>
·······@yahoo.com (tony) writes:

> i'd have to agree that the process has proven somewhat difficult.  i
> tried to get the Garnet toolkit up and running and found a paucity of
> understandable (to my simple mind) documentation on how to make the
> damned thing work.  as a result, my attempts of installing Garnet on
> Redhat led to a break of the Lispworks and CLISP installs.  I had to
> rebuild the system (OS and such) from scratch... which is ok 'cause
> every attempt leads me to more knowledge.

Wow, I don't know what you did, but anything you do with compiling
Garnet should only affect things in Garnet's directory.  :-)

I'm still using Fred Gilham's distribution of Garnet, but I don't
imagine much is different in the sourceforge Garnet.  There is good
documentation in the doc/ directory.  I found the build scripts in the
toplevel directory pretty self-explanatory, but I've only used Garnet
with CMUCL.  If you have specific questions, ask here or on the garnet
list.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: tony
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <34175232.0312241413.287cc69c@posting.google.com>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
> ·······@yahoo.com (tony) writes:
> 
> > i'd have to agree that the process has proven somewhat difficult.  i
> > tried to get the Garnet toolkit up and running and found a paucity of
> > understandable (to my simple mind) documentation on how to make the
> > damned thing work.  as a result, my attempts of installing Garnet on
> > Redhat led to a break of the Lispworks and CLISP installs.  I had to
> > rebuild the system (OS and such) from scratch... which is ok 'cause
> > every attempt leads me to more knowledge.
> 
> Wow, I don't know what you did, but anything you do with compiling
> Garnet should only affect things in Garnet's directory.  :-)

i tried to figure out what i'd done.  based  on my reading of the
docs, i thought it an easy process ("run the before-compile, then
run...").  i've a machine i can do another test build on.  i will
certainly ask questions if need be.  thanks for the help.
> 
> I'm still using Fred Gilham's distribution of Garnet, but I don't
> imagine much is different in the sourceforge Garnet.  There is good
> documentation in the doc/ directory.  I found the build scripts in the
> toplevel directory pretty self-explanatory, but I've only used Garnet
> with CMUCL.  If you have specific questions, ask here or on the garnet
> list.
> 
> -- 
>            /|_     .-----------------------.                        
>          ,'  .\  / | No to Imperialist war |                        
>      ,--'    _,'   | Wage class war!       |                        
>     /       /      `-----------------------'                        
>    (   -.  |                               
>    |     ) |                               
>   (`-.  '--.)                              
>    `. )----'
From: Thomas F. Burdick
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <xcvr7yunihg.fsf@famine.OCF.Berkeley.EDU>
FWIW, it's waaaaay easier to find and install things now than it was
in the late 90's.  And the situation's still improving.

Eladio <··············@yahoo.com> writes:

> I'm a newbie - rank amateur all the way, but grossly infected with the
> lisp-bug, and I definitely echo the sentiment that the free-lisp environment
> needs to be more easily accessible. It's not a question of dumbing it down for
> the masses, but simply of making it user-friendly. My time is precious, and
> frankly I'd rather crank out code than wasting hours just trying to install a
> half-assed getopt-library.

I'd recommend that you get SBCL.  Dan Barlow replaced his old guide to
getting started on CMUCL with a new one for SBCL:

  http://ww.telent.net/lisp/according_to/

This should be enough to get you mostly where you need to be.
"... according to" covers library installation, which is as easy as it
is with Perl.  Not everything is available this way, but there should
be enough to get you started.  You can tackle other libraries on a
case by case basis by asking on their lists.  Once you get them
working on your system, be a part of the solution: make that library
asdf-installable.

> Here's what could make the ride a tad more pleasant than the cold plunge into
> the abyss I've experienced:
> 
>  * Instructions when needed. I'm not asking for the Great American novel, just
>    a lousy roadmap. If your granny can't install it, it's too hard. But even
>    granny knows how to to use "cp", "make" and "cd".

There are very good documents for getting started with CMUCL and SBCL.
Check their websites and the CLiki.

>  * Tools with simple interfaces. Perl has 'perl -MCPAN -e 'install FOO', which
>    I turned into a simple shell alias; "cpan". Works like a charm. Lisp can't
>    be that much harder than Elisp, and I've *never* had problems getting new
>    Emacs packages. Asdf-install sounds great, as does cclan-get. But please,
>    make them just a tad more accessible.

SBCL ships with asdf-install, and CMUCL probably will soon.

>  * Basic tutorials. "Packages For Dummies" was unnecessarily complex.

Uh, yeah, the "for complete idiots" part of that title is kind of a
joke.

>    As a
>    newbie, I haven't yet wrapped my head around the concepts of symbols, so
>    puh-lease don't lecture me about it. You waste your time. What I want is
>    simple boilerplates showing me the rudiments, like a sample defpackage I
>    can just cut-and-paste and pluck in my own functions. That's MORE than
>    enough, and if I want more, I can always jump into the HyperSpec, or ask on
>    #lisp for the skinny.
> 
>  * Basic roadmap-to-lisp. I don't care where YOU are coming from, or how much
>    cooler your resume is than mine. I want to know how to find my
>    way. Something like a Starter's Guide would be nice: read this, and this
>    and this in that order, create some projects, then install this gizmo and
>    learn about defsystem through this excellent tutorial. This presupposed the
>    existence of the above, of course.
> 

These exist.

> I'm gonna make a little "diary of a newbie lispnik" of my little journey here,
> and jot down all my woes and frustrations along the way, and make it available
> on cliki or wherever.

Ug.  There are tons of getting-started guides.  The problem is making
them easy to find for newbies and/or getting newbies to ask, "I want to
get started, where is the HOWTO that tells me how to do this?"

> And if anyone knows the answers to my lastest problem, please do speak out. 

(I don't use CLOCC)

> Oh - and how do you start Hemlock?! Thanks for your consideration.

Go to CLiki.  Type "hemlock" in the search.  Click on the third link,
GettingStartedWithHemlock.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Zach Beane
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m3oetyja5s.fsf@unnamed.xach.com>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> Eladio <··············@yahoo.com> writes:
>
>> I'm gonna make a little "diary of a newbie lispnik" of my little
>> journey here, and jot down all my woes and frustrations along the
>> way, and make it available on cliki or wherever.
>
> Ug.  There are tons of getting-started guides.  The problem is making
> them easy to find for newbies and/or getting newbies to ask, "I want to
> get started, where is the HOWTO that tells me how to do this?"

Ug seconded. It's tempting, as a newbie, to write about every false
start and blind alley you wandered down while looking for the right
solution. A truly useful document would apply the benefit of hindsight
and expose the proper path in a way that not only helps the reader in
a specific case, but also provides insight useful to guide futher
intuition when venturing into the unknown.

The "newbies teaching newbies" (or "blind leading the blind") idea
always reminds me of this bit by Erik Naggum:

   I recently reviewed a book in which the author could only be
   understood to apologize for his lack of mastery of the subject when
   he chatted endlessly about how hard it was to linearize the
   material and where he used more promises of what was to come and
   repetitions of what he had discussed than actual new information in
   each paragraph, how this and that feature in the topic he discussed
   "is not easy" to use and understand.  It was torture to read and
   try to lift it to some readable level.

Zach
From: Eladio
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bwy8t1hm7v.fsf@Cagafuego.opasia.dk>
Zach Beane <····@xach.com> writes:

> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> 
> Ug seconded. It's tempting, as a newbie, to write about every false
> start and blind alley you wandered down while looking for the right
> solution. 

Hmmm... damn good point. I hate that too - especially on matters in which I've
gained just a modicum of insight above the author's - and the latter turns out
to be woefully mistaken.

> A truly useful document would apply the benefit of hindsight
> and expose the proper path in a way that not only helps the reader in
> a specific case, but also provides insight useful to guide futher
> intuition when venturing into the unknown.

You're absolutely right. I'm still gonna make a log of my own mistakes, and 
then keep it for later. In practice, the problem is usually that by that time,
most people no longer care about the newbies because they got their hands full
thanks to their own hard-earned skills.

Guess I was just going off my rockers after a long day of going nowhere fast...

> The "newbies teaching newbies" (or "blind leading the blind") idea
> always reminds me of this bit by Erik Naggum:
> 
>    I recently reviewed a book in which the author could only be
>    understood to apologize for his lack of mastery of the subject when
>    he chatted endlessly about how hard it was to linearize the
>    material and where he used more promises of what was to come and
>    repetitions of what he had discussed than actual new information in
>    each paragraph, how this and that feature in the topic he discussed
>    "is not easy" to use and understand.  It was torture to read and
>    try to lift it to some readable level.

That's a great quote, but personally I think the style and incompetence of the
author in this particular case has more to do with why he got put off by the
material. I was never talking about drawing up an exhaustive account of
technicalities I'm way too underqualified to expound on in the first place. That
would be unprofessional and counter productive. 

What I had in mind was something along the lines of www.freebsddiary.org, and
other sites which were started by frustrated starters who decided to sum up
proven techniques of what little they *did* know, and provide a place where
others could post their hard-earned experiences too. Helped me out a ton in the
past. 

Cliki seems to be the perfect medium for that approach, but until today I had no
idea that there were actual tutorials on the site, like the Hemlock hint Thomas
pointed me to.
-- 
                            o      _     _         _
------- __o       __o      /\_   _ \\o  (_)\__/o  (_)        -o)
----- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/     /\\
---- (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_  _\_v
Don't Drive And Pray - Listen To InfidelGuy.com And Rock Your Mind
From: Eladio
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <9o3cb9j45p.fsf@Cagafuego.opasia.dk>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> FWIW, it's waaaaay easier to find and install things now than it was
> in the late 90's.  And the situation's still improving.

Yeah, that's the open source movement for you. Stuff that broke your teeth 3
months ago suddenly fly by wire. But it's still frustrating while it goes
on. *sigh*

> I'd recommend that you get SBCL.  Dan Barlow replaced his old guide to
> getting started on CMUCL with a new one for SBCL:
> 
>   http://ww.telent.net/lisp/according_to/

Wonderful! I've been on #lisp all day, and go the same advice. It still gives
me heaps of trouble since asdf-install doesn't seem to be installed by default
on FreeBSD, but I'm working on it. At least SBCL focuses the problem down a
tad. Thanks for the link too!

> This should be enough to get you mostly where you need to be.
> "... according to" covers library installation, which is as easy as it
> is with Perl.  Not everything is available this way, but there should
> be enough to get you started.  

That's all I'm asking for!

> Once you get them working on your system, be a part of the solution: make
> that library asdf-installable.

Great idea, I'll do that. In fact, I've more or less committed myself to put
my shoulder to the wheel and compile a couple of howtos for others in the same
boat. 

>> RE. Lack of Instructions.
> There are very good documents for getting started with CMUCL and SBCL.
> Check their websites and the CLiki.

The problem is not firing up the lisp systems - they all work. There's also
tons of free, top-notch and accessible material out there for  mastering the
basics. The problems arrive the second you try to write your first application
and it dawns on you that you have nothing along the lines of "getopt",
"configParser", or whatever. WHAMMO - Welcome to Newbie Hell. So you discover
cliki, cclan, cclib and all those great libraries jam-packed with goodies to
sink your teeth into... and find that you spend days on end to move
forward. Hence the frustration.

I have yet to find anything remotely ressembling a manual for asdf, let alone
instructions for actually *fixing* the problems you encounter. So I'm supposed
to type:

(require 'asdf)
(require 'asdf-install)
(asdf-install 'cliki)  ; or whatever

Okay. Peace of cake. But clisp, cmucl, and sbcl ALL break down at step one, so
even though I have an instruction, it flunks in practice, even though the
system I'm on is one of the most widespread of its kind. There's no way to
really solve the problem as a newbie, except by whining about it to the
pros. Again!

Here's an example of just one such crazy situation, from earlier today:

;;; loading #P"/usr/local/lib/common-lisp/asdf/sbclfasl/asdf.fasl"
; loading system definition from
; #P"/usr/local/lib/common-lisp/system-registry/port.asd" into
; #<PACKAGE "ASDF2640">
; registering #<SYSTEM #:PORT {483A90D1}> as PORT

debugger invoked on condition of type SIMPLE-ERROR in thread 12767:
  Don't know how to load ASDF

Crazy, innit?! First it loads asdf.fasl successfully - and then I'm told I
doesn't know how to load it! So I sashay around mailing lists, irc and the
archives of this newsgroup and constantly wind up empty handed. So either the
information out there is obsolete, or the applications were written for
"insiders". But at least by concentrating on SBCL I can now contact people
who're familiar with that particular system, and maybe find some FreeBSD
mavens among them. That always helps!

I'd LOVE to do something about this situation - and I will, once I got at
least a basic system up, but it ain't exactly a gas while it lasts! I was
thinking of creating a tutorial tackling problems newbies face, such as:

* Setting Up Your Lisp System (clocc/cclib, how asdf-install works,
  troubleshooting)
* Setting Up Emacs (ilisp basics)
* Packages 101 (plug-and-rock defpackage, how to use asdf)
* Cllib/cliki lib Tutorials (basic stuff like getopt, configuration parser,
  curl, cgi, xml etc)

I don't wanna step on the toes of the cl-cookbook (which is fantastic), but
provide some salient examples for the newbies who find plunging into libraries
from the get-go a little too sanity-wracking.

Personally, I've found lisp tutorials and guidelines every easily. But I still
think this information and tools need to be at least A) updated for non-Debian
systems B) available for existing libraries.

> SBCL ships with asdf-install, and CMUCL probably will soon.

Yeah, that's great. If you're on Debian. I have SBCL running full speed ahead,
but no asdf-install - and I'm sure I'm not the only one. That's a major
oversight, and it needs to be remedied. Sounds fabulous, though! *daydreams*

> >  * Basic tutorials. "Packages For Dummies" was unnecessarily complex.
> 
> Uh, yeah, the "for complete idiots" part of that title is kind of a
> joke.

Well, they're actually great. I've been absolutely floored every time I've
started a tutorial, and discovered some new aspect of lisp. It blows my mind,
quite frankly. But I think we need some stuff written for the newbies - even
those who use lisp as a first or second language - after PHP, like myself. I'm
talking holding-hands stuff: "do A, B and C - and voila, your mojo
happens". Right now, it's "if you're on Debian, and asdf is perfectly
installed and you're lucky enough to have asdf-install running, THEN type A, B
and C...".

> >    Something like a Starter's Guide would be nice: read this, and this
> 
> These exist.

And I've read them. Or something *like* them. But they virtually all function
as *portals* glumming up a load of resources - many written in dry-ass
academic language, with the occassional gem on little details loop or equality
tossed in. But if they fulfilled the role I outlined above - why am I sitting
here and whine like a baby because I can't load in a single external library?

The ride needs to be less bumpy - especially for the non-Debian guys. I
actually nursed the idea to switch OS today, but that would only mean I'd have
even *more* to learn! All I want is being able to finish my first
baby-project. * WAAAH! *

> Ug.  There are tons of getting-started guides.  The problem is making
> them easy to find for newbies and/or getting newbies to ask, "I want to
> get started, where is the HOWTO that tells me how to do this?"

You'll have to excuse me. Like I said earlier, getting off the ground with
lisp is not really the problem. But there's more to being a newbie than just
figuring out how to access elements in a hash. There's the whole programming
environment to master, and of course the "standard" libraries, without which
the newbie is in for a world of hurt.

The "getting-started" guides completely neglect that aspect of the newbie
period, which is the time where you're ready to kick off your first few
projects and play around with the language in earnest. In PHP, I was
productive from day 1, and whenever I wished to learn something new, like
sockets or xml parsing, I just downloaded a library and *presto* - a whole new
world opened up. In Lisp, you thrash through the tutorials, go "OOOOH!",
"WOW!", "Awesome!", "Honey, you gotta *see* this!!" for a week... and then you
splatter against the window pane like a bug. Again. And again. And again.

Oh well, nobody stays newbie forever!

> > Oh - and how do you start Hemlock?! Thanks for your consideration.
> 
> Go to CLiki.  Type "hemlock" in the search.  Click on the third link,
> GettingStartedWithHemlock.

Success! Success at last!!! Thank you *so* much! I get the feeling I'll spend
the whole day tomorrow on cliki, hehehe! Finally a little victory to round off
the day. Sorry for the verboseness of this post, by the by - and merry
Christmas!
-- 
                            o      _     _         _
------- __o       __o      /\_   _ \\o  (_)\__/o  (_)        -o)
----- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/     /\\
---- (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_  _\_v
Don't Drive And Pray - Listen To InfidelGuy.com And Rock Your Mind
From: Don Geddis
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87llp07qh4.fsf@sidious.geddis.org>
Eladio <··············@yahoo.com> writes:
> The problem is not firing up the lisp systems - they all work.

Great!

> The problems arrive the second you try to write your first application
> and it dawns on you that you have nothing along the lines of "getopt",
> "configParser", or whatever. WHAMMO - Welcome to Newbie Hell. So you discover
> cliki, cclan, cclib and all those great libraries jam-packed with goodies to
> sink your teeth into... and find that you spend days on end to move
> forward. Hence the frustration.

This hasn't been my experience.  I've written tons of Lisp code, and only
very, very rarely have I used third-party libraries.

I'm not saying there's anything right or wrong about using libraries, but
you're far underselling Lisp if you think that you can't do anything useful
with the language (especially with the extras including in the major
implementations) unless you also install many additional packages.

Common Lisp out of the box is a very full-featured language, and you can do
lots of cool stuff by yourself (especially as a novice!) just using the
standard Lisp system with no additional libraries.

I sympathize that there seem to be lots of useful packages out there, yet
newbies find it difficult to install and use them.  My question, though, is
why does this stop you?  Just ignore the packages, and start writing great
Lisp code by yourself!

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
It is possible for your mind to be so open that your brain falls out.
From: Eladio
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <vzhdznvjo7.fsf@Cagafuego.opasia.dk>
Don Geddis <···@geddis.org> writes:

> I'm not saying there's anything right or wrong about using libraries, but
> you're far underselling Lisp if you think that you can't do anything useful
> with the language (especially with the extras including in the major
> implementations) unless you also install many additional packages.

Of course I don't think that way, silly wabbit! Lisp is fabulous - but those
libraries are just too cool, and I'm bristling with great projects I'd love to
kick off. Besides, I'm problably just going through some growing pains. I
remember wasting an entire WEEK just to install a stupid database driver and
figuring out the how to set up the CLASSPATH correctly. Lisp isn't any worse
than that, at the end of the day.

> Common Lisp out of the box is a very full-featured language, and you can do
> lots of cool stuff by yourself (especially as a novice!) just using the
> standard Lisp system with no additional libraries.

Same thing could be said for any other language. The NASM assembler is
amazingly fullfledged too, so are Python, Perl, PHP, C, C++, C# and Java. But
libraries make you so much more productive at a much faster rate. I was
floored when I tried out lisp-functions like "time", compared to what a bitch
it was to figure out how to use the Benchmark module in PHP. At least the Perl
version has documentation in abundance. I've yet to find anything near to
"trace" in any other language. Little features like that are all over
Lisp. It's awesome.

But now I want more! More! MOOOORE!! *slaver*

> I sympathize that there seem to be lots of useful packages out there, yet
> newbies find it difficult to install and use them.  My question, though, is
> why does this stop you?  Just ignore the packages, and start writing great
> Lisp code by yourself!

Stop MOI?! Armaggedon couldn't stop me from blasting out Lisp-code, man! But
imagine hackin' Perl without CPAN. It's just not the same. And frankly, I'd
rather blaze a new trail than reinventing the wheel.

The Lisp libraries out there are fabulous, and DESERVE to be used. I'm just
struggling to do just that, and if FreeBSD won't let me, then I'll just have
to switch to Debian until I grok the package system, and port the whole
stuffed enchilada over at some point myself.

The tools are there, the libraries are there, the knowhow is there, and the
userbase is there. There's just a few kinks which spoil the fun for the
clueless, and little by little they'll all be ironed out, I'm sure.
-- 
                            o      _     _         _
------- __o       __o      /\_   _ \\o  (_)\__/o  (_)        -o)
----- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/     /\\
---- (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_  _\_v
Don't Drive And Pray - Listen To InfidelGuy.com And Rock Your Mind
From: Ng Pheng Siong
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bshol0$v99$1@reader01.singnet.com.sg>
According to Eladio  <··············@yahoo.com>:
> struggling to do just that, and if FreeBSD won't let me...

Of course FreeBSD lets you; you just have to ask properly. ;-)

But really this hasn't much to do with operating systems. (My POV may be
"different": I was a system administrator of several flavours of Un*x and
Windows for some years before moving to programming.)

Going back two nodes in this thread tree, I see you're talking about
(require 'asdf) and (require 'asdf-install).

Well, I haven't looked at asdf-install, but for asdf, I did the following:

0. In a listener, (compile-file ".../.../asdf")

  On CMUCL, this produces asdf.x86f; on LispWorks/Windows, asdf.fsl.

1. In .cmucl-init.lisp (for CMUCL (duh!)) or lispworks-init.lisp (my
convention for LispWorks), add the form at the beginning of the file:

    (load ".../.../asdf")

2. Now ASDF is available. To load Portable AllegroServe, say, I have the
following in the init files:

  (defun go-aserve ()
    (load "/usr/local/pkg/lisp/portableaserve/acl-compat/acl-compat.asd")
    (asdf:oos 'asdf:load-op :acl-compat)
    (load "/usr/local/pkg/lisp/portableaserve/aserve/htmlgen/htmlgen.asd")
    (asdf:oos 'asdf:load-op :htmlgen)
    (load "/usr/local/pkg/lisp/portableaserve/aserve/aserve.asd")
    (asdf:oos 'asdf:load-op :aserve))

So when I want it, I just say "(go-aserve)" in a listener. Works for both
CMUCL and LispWorks/Windows. 

I don't know much about REQUIRE, coz when I got started, I noticed the CLHS
say it is deprecated [*], so I figured out the above and didn't think
about it anymore.

* Fire up Emacs, fire up CMUCL, type "(require<ctrl-c><shift-h>" and the
CLHS pops up in my Mozilla browser window, positioned at the docu for
REQUIRE. Cool huh! IIRC the instructions to do this are in the ILISP
distribution. 


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

http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- Open Source Python Crypto & SSL
From: Eladio
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bbd6abuzfi.fsf@Cagafuego.opasia.dk>
····@netmemetic.com (Ng Pheng Siong) writes:

> Well, I haven't looked at asdf-install, but for asdf, I did the following:
> 
> 0. In a listener, (compile-file ".../.../asdf")
> 
>   On CMUCL, this produces asdf.x86f; on LispWorks/Windows, asdf.fsl.
> 
> 1. In .cmucl-init.lisp (for CMUCL (duh!)) or lispworks-init.lisp (my
> convention for LispWorks), add the form at the beginning of the file:
> 
>     (load ".../.../asdf")
> 
> 2. Now ASDF is available. To load Portable AllegroServe, say, I have the
> following in the init files:
> 
>   (defun go-aserve ()
>     (load "/usr/local/pkg/lisp/portableaserve/acl-compat/acl-compat.asd")
>     (asdf:oos 'asdf:load-op :acl-compat)
>     (load "/usr/local/pkg/lisp/portableaserve/aserve/htmlgen/htmlgen.asd")
>     (asdf:oos 'asdf:load-op :htmlgen)
>     (load "/usr/local/pkg/lisp/portableaserve/aserve/aserve.asd")
>     (asdf:oos 'asdf:load-op :aserve))
> 
> So when I want it, I just say "(go-aserve)" in a listener. Works for both
> CMUCL and LispWorks/Windows. 

Ng, you ARE the man! I'm starting to get the hang of this baby. Actually, I
switched over to SBCL and re-did the clocc-instructions from A-Z. Now at least 
I have the whole CLLIB package tree compiled, and I can load it in too, which
means I now know how to grab any module on cliki by hand, compile it, and load
it in - so I'm aaaaaalmost ready to rock 'n rock!

The only snag left is figuring out which *prefix* to use to get at the goodies,
and I'm all set. For instance, I do a
   (load (translate-logical-pathname "clocc:src;cllib;animals"))

and the following symbols get exported: play-animals, play-game,
*animals-file-name*, but I can't for the life of me not figure out how to call
them. I've tried, say (play-game), (cllib:play-game) and numerous other
variations, including trying to change to different packages. (I'm told that
none of those symbols are bound, which *freaks* me out!)

This is a minor issue, really. Nothing I can't pester the good folks on #lisp
about, hehehe.

So I'm so close I can smell the victory, man. And thank you so much for taking
the time: I'm wasted now, but I'll try it out first thing in the morning.

Cheers!
-- 
                            o      _     _         _
------- __o       __o      /\_   _ \\o  (_)\__/o  (_)        -o)
----- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/     /\\
---- (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_  _\_v
Don't Drive And Pray - Listen To InfidelGuy.com And Rock Your Mind
From: Björn Lindberg
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <hcsekup4wg7.fsf@knatte.nada.kth.se>
····@netmemetic.com (Ng Pheng Siong) writes:

> According to Eladio  <··············@yahoo.com>:
> > struggling to do just that, and if FreeBSD won't let me...
> 
> Of course FreeBSD lets you; you just have to ask properly. ;-)
> 
> But really this hasn't much to do with operating systems. (My POV may be
> "different": I was a system administrator of several flavours of Un*x and
> Windows for some years before moving to programming.)
> 
> Going back two nodes in this thread tree, I see you're talking about
> (require 'asdf) and (require 'asdf-install).
> 
> Well, I haven't looked at asdf-install, but for asdf, I did the following:
>
> [ ... ]

I have the following code for getting asdf packages to work:

==>BEGIN<==================================
(in-package :asdf)

(push "/home/bjorn/share/common-lisp/system/" *central-registry*)

(defvar *system-configuration-paths*
  '(("/home/bjorn/share/common-lisp/src/"
     "/home/bjorn/lib/common-lisp/cmucl/")))

(defun pathname-prefix-p (prefix pathname)
  "Tar tv� s�kv�gsnamn eller namnstr�ngar och returnerar sant om det
f�rsta �r ett prefix i det andra. :absolute/:relative f�rst i
kataloglistan fungerar som ankare, vilket g�r att SEARCH inte kan
matcha en dellista mitt i."
  (search (pathname-directory prefix)
	  (pathname-directory pathname)
	  :test #'equal))

(defmacro iterate (name bindings &body body)
  `(labels ((,name ,(mapcar #'first bindings)
	     ,@body))
    (,name ,@(mapcar #'second bindings))))

(defmethod output-files :around ((operation compile-op)
				      (c cl-source-file))
  (let* ((source-pathname (component-pathname c))
	 (default-pathname (car (call-next-method)))
	 (type (pathname-type default-pathname)))
    (iterate iter ((translations *system-configuration-paths*))
      (let ((translation (first translations)))
	(cond ((null translations) default-pathname)
	      ((pathname-prefix-p (first translation) default-pathname)
	       (list
		(translate-pathname source-pathname
				    (merge-pathnames
				     (make-pathname :directory
						    '(:relative :wild-inferiors)
						    :type
						    :wild)
				     (first translation))
				    (merge-pathnames
				     (make-pathname :directory
						    '(:relative :wild-inferiors)
						    :type
						    type)
				     (second translation)))))
	      (t
	       (iter (rest translations))))))))

==>END<====================================

Now I can put asdf-installable packages (in the tarball sense) under
/home/bjorn/share/common-lisp/src & symlink the .asd file to
/home/bjorn/share/common-lisp/system. That is all that is necessary to
be able to work with it in lisp. In cmucl I can now just write (asdf:oos
'asdf:load-op :cl-ppcre) to eg load the cl-ppcre library. I meant to
expand on the code to make it work with defsystem and clisp as well,
but I haven't gotten around to it yet. Half the point is trying to
parameterize the directories where source, binaries & system
definitions exist. For instance, the *system-configuration-paths*
variable above can have several directory pairs, and the right ones
will be used (eg one can have both /home/user/.../ dirs and
/usr/local/.../ dirs). (Sorry about the iterate macro; I haven't
really learned LOOP yet.)

A comment on the broader issue discussed in this thread: I would like
to see some sort of agreed-upon (informal) standards developed for CL
on Unix. Standardized places where source and binary files go in the
file system, perhaps some standardized environment variables. Compare
with C: anyone writing or installing a C library, or packaging a
library for a distro, can count on the basic directory structure, with
/.../{lib,include}, can count on environment variables like CC, LD_*,
etc. I think more of a de facto standard in this area for CL would
make it much easier for people to use different
administration/installation tools, different distro packaging systems,
and lots of other issues like that.


Bj�rn
From: Christopher C. Stacy
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <uvfo1srrn.fsf@news.dtpq.com>
>>>>> On 28 Dec 2003 01:28:40 +0100, Bj�rn Lindberg ("Bj�rn") writes:
 Bj�rn> A comment on the broader issue discussed in this thread: I would like
 Bj�rn> to see some sort of agreed-upon (informal) standards developed for CL
 Bj�rn> on Unix. Standardized places where source and binary files go in the
 Bj�rn> file system, perhaps some standardized environment variables. 

 Bj�rn> Compare with C: anyone writing or installing a C library,
 Bj�rn> or packaging a library for a distro, can count on the basic
 Bj�rn> directory structure, with /.../{lib,include}, can count on
 Bj�rn> environment variables like CC, LD_*, etc. I think more of a de
 Bj�rn> facto standard in this area for CL would make it much easier
 Bj�rn> for people to use different administration/installation tools,
 Bj�rn> different distro packaging systems, and lots of other issues
 Bj�rn> like that.

This is what logical pathnames are supposed to be for.
The installation procedure is supposed to look in some standard
place to find or put the logical translation host definition.
From: Björn Lindberg
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <hcsad5d4us8.fsf@knatte.nada.kth.se>
······@news.dtpq.com (Christopher C. Stacy) writes:

> >>>>> On 28 Dec 2003 01:28:40 +0100, Bj�rn Lindberg ("Bj�rn") writes:
>  Bj�rn> A comment on the broader issue discussed in this thread: I would like
>  Bj�rn> to see some sort of agreed-upon (informal) standards developed for CL
>  Bj�rn> on Unix. Standardized places where source and binary files go in the
>  Bj�rn> file system, perhaps some standardized environment variables. 
> 
>  Bj�rn> Compare with C: anyone writing or installing a C library,
>  Bj�rn> or packaging a library for a distro, can count on the basic
>  Bj�rn> directory structure, with /.../{lib,include}, can count on
>  Bj�rn> environment variables like CC, LD_*, etc. I think more of a de
>  Bj�rn> facto standard in this area for CL would make it much easier
>  Bj�rn> for people to use different administration/installation tools,
>  Bj�rn> different distro packaging systems, and lots of other issues
>  Bj�rn> like that.
> 
> This is what logical pathnames are supposed to be for.
> The installation procedure is supposed to look in some standard
> place to find or put the logical translation host definition.

Yes, but I think there should also be a Unix standard for pathnames
and environment variables. If these are mapped to by logical
pathnames[1], and these logical pathnames perhaps are stanadrized over
other platforms as well, then all the better, but I still think a more
standardized approach on Unix would be good.

I have a perhaps slightly different perspective than most, since I am
running Lisp on Linux From Scratch. It means that I basically compile
all my software from tarballs, and I am not using any package
system. From this perspective, most tarballs with C programs are
self-contained; they can be compiled and installed by "./configure;
make; make install". This is possible in part, as I see it, because
such standards as I was alluding to above does exist for C on
Unix. You may say that Linux From Scratch users are an insignificant
and uniportant part of the CL user base, but an LFSer is doing
something very similar to what a package maintainer for a distribution
is doing, namely preparing a program package for a platform. If we
want it to be easy to create and maintain packages for different Unix
platforms/distributions, I think this part has to be standarized and
easy, and it is this I am aiming towards when I am talking about
standardizing a few things such as file system structure and
environment variables[2].

[1] I actually did try to use logical pathnames at first for my hack I
included in the post you responded to, but I was hesitant, because
AFAICT, logical pathnames cannot cope with such things as mixed-case
file names and certain characters in filenames, and I cannot guarantee
that a library writer will not name files in a package in such a way
that logical pathnames cannot be used to refer to them.

[2] Here is a not well thought out quick suggestion for a proposal: In
a standard Unix CL installation, library code should reside in the
following locations:

  /usr/share/common-lisp/src/
  /usr/share/common-lisp/system/
  /usr/lib/common-lisp/<implementation name>/

Similar locations could exist for the /usr/local/ hierarchy for local
installations.

An environment variable called COMMON_LISP_FEATURES could function
like a shell equivalent to the *features* variable, and could eg
include the available implementations ("cmucl clisp sbcl").


Bj�rn
From: james anderson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FEECBAB.D570DE9A@setf.de>
Bj�rn Lindberg wrote:
> 
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> 
> > >>>>> On 28 Dec 2003 01:28:40 +0100, Bj�rn Lindberg ("Bj�rn") writes:
> >  Bj�rn> A comment on the broader issue discussed in this thread: I would like
> >  Bj�rn> to see some sort of agreed-upon (informal) standards developed for CL
> >  Bj�rn> on Unix. Standardized places where source and binary files go in the
> >  Bj�rn> file system, perhaps some standardized environment variables.
> >
> >  Bj�rn> Compare with C: anyone writing or installing a C library,
> >  Bj�rn> or packaging a library for a distro, can count on the basic
> >  Bj�rn> directory structure, with /.../{lib,include}, can count on
> >  Bj�rn> environment variables like CC, LD_*, etc. I think more of a de
> >  Bj�rn> facto standard in this area for CL would make it much easier
> >  Bj�rn> for people to use different administration/installation tools,
> >  Bj�rn> different distro packaging systems, and lots of other issues
> >  Bj�rn> like that.
> >
> > This is what logical pathnames are supposed to be for.
> > The installation procedure is supposed to look in some standard
> > place to find or put the logical translation host definition.
> 
> Yes, but I think there should also be a Unix standard for pathnames
> and environment variables. If these are mapped to by logical
> pathnames[1], and these logical pathnames perhaps are stanadrized over
> other platforms as well, then all the better, but I still think a more
> standardized approach on Unix would be good.

unless it is implemented in terms of ansi behaviour, the question remains,
good for what?

> 
> ...
> 

?

> [1] I actually did try to use logical pathnames at first for my hack I
> included in the post you responded to, but I was hesitant, because
> AFAICT, logical pathnames cannot cope with such things as mixed-case
> file names and certain characters in filenames, and I cannot guarantee
> that a library writer will not name files in a package in such a way
> that logical pathnames cannot be used to refer to them.
> 

i thought this thread was about problem-free, portable library installation.
if a library writer has chosen a non-portable syntax to name source files,
they have declared the library to be non-portable. what is the benefit of
tailoring a build system to that goal?

> [2] Here is a not well thought out quick suggestion for a proposal: In
> a standard Unix CL installation, library code should reside in the
> following locations:
> 
>   /usr/share/common-lisp/src/
>   /usr/share/common-lisp/system/
>   /usr/lib/common-lisp/<implementation name>/
> 
> Similar locations could exist for the /usr/local/ hierarchy for local
> installations.
> 
> An environment variable called COMMON_LISP_FEATURES could function
> like a shell equivalent to the *features* variable, and could eg
> include the available implementations ("cmucl clisp sbcl").

what's an environment variable?

...
From: Gareth McCaughan
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87d6a9xfak.fsf@g.mccaughan.ntlworld.com>
James Anderson wrote:

[Bj�rn Lindberg:]
>> [1] I actually did try to use logical pathnames at first for my hack I
>> included in the post you responded to, but I was hesitant, because
>> AFAICT, logical pathnames cannot cope with such things as mixed-case
>> file names and certain characters in filenames, and I cannot guarantee
>> that a library writer will not name files in a package in such a way
>> that logical pathnames cannot be used to refer to them.
> 
> i thought this thread was about problem-free, portable library installation.
> if a library writer has chosen a non-portable syntax to name source files,
> they have declared the library to be non-portable. what is the benefit of
> tailoring a build system to that goal?

Portability is not all-or-nothing. It may be useful to have a
build system that can accommodate minor infractions of portability
by library authors.

>> [2] Here is a not well thought out quick suggestion for a proposal: In
>> a standard Unix CL installation, library code should reside in the
>> following locations:
>> 
>>   /usr/share/common-lisp/src/
>>   /usr/share/common-lisp/system/
>>   /usr/lib/common-lisp/<implementation name>/
>> 
>> Similar locations could exist for the /usr/local/ hierarchy for local
>> installations.
>> 
>> An environment variable called COMMON_LISP_FEATURES could function
>> like a shell equivalent to the *features* variable, and could eg
>> include the available implementations ("cmucl clisp sbcl").
> 
> what's an environment variable?

Something available on every Unix-like system in the world.
Observe the word "Unix" in the paragraph beginning "[2]".

-- 
Gareth McCaughan
.sig under construc
From: james anderson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FEEE4DD.67472108@setf.de>
Gareth McCaughan wrote:
> 
> James Anderson wrote:
> 
> [Bj�rn Lindberg:]
> >> [1] I actually did try to use logical pathnames at first for my hack I
> >> included in the post you responded to, but I was hesitant, because
> >> AFAICT, logical pathnames cannot cope with such things as mixed-case
> >> file names and certain characters in filenames, and I cannot guarantee
> >> that a library writer will not name files in a package in such a way
> >> that logical pathnames cannot be used to refer to them.
> >
> > i thought this thread was about problem-free, portable library installation.
> > if a library writer has chosen a non-portable syntax to name source files,
> > they have declared the library to be non-portable. what is the benefit of
> > tailoring a build system to that goal?
> 
> Portability is not all-or-nothing.

a library which purports to be portable should compile, load, and run in any
conformant lisp. this leaves room for bugs, and for the fact that the given
lisp likely only purports to confrom.

(please note the distinction wrt interfaces to the operating system in another
message.) 

is there another definition for portability?

>    It may be useful to have a
> build system that can accommodate minor infractions of portability
> by library authors.

agreed. it is, on the other hand, not productive for a build system to induce
library authors to formulate a build specification such that either it is, in
itself, non-portable, or the build system is not capable of interpreting it portably.

...
From: Gareth McCaughan
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87zndcx5ri.fsf@g.mccaughan.ntlworld.com>
James Anderson wrote:

> > > i thought this thread was about problem-free, portable library installation.
> > > if a library writer has chosen a non-portable syntax to name source files,
> > > they have declared the library to be non-portable. what is the benefit of
> > > tailoring a build system to that goal?
> > 
> > Portability is not all-or-nothing.
> 
> a library which purports to be portable should compile, load, and run in any
> conformant lisp. this leaves room for bugs, and for the fact that the given
> lisp likely only purports to confrom.
> 
> (please note the distinction wrt interfaces to the operating system in another
> message.) 
> 
> is there another definition for portability?

Application A is more portable than application B if the effort
required to make A run on a new system is less than that required
to make B run on a new system. (It might be advisable to normalize
with respect to the sizes of A and B, somehow.) An application is
maximally portable if there exists (even in potentiality) no other
application that does substantially the same thing in substantially
the same way but which is more portable.

Being able to compile (without intervention), load and run (correctly)
on any conformant Lisp is roughly equivalent to being maximally portable,
for that class of applications whose basic functionality doesn't
prevent that. But, for instance, an application whose purpose is to
dump live Linux filesystems by definition cannot run correctly in
any system that isn't capable of *having* live Linux filesystems,
so such an application could be maximally portable (by my definition)
without being portable (by yours).

> >    It may be useful to have a
> > build system that can accommodate minor infractions of portability
> > by library authors.
> 
> agreed. it is, on the other hand, not productive for a build system to induce
> library authors to formulate a build specification such that either it is, in
> itself, non-portable, or the build system is not capable of interpreting it portably.

Agreed. A good build system might permit, but issue warnings for,
such minor infractions.

-- 
Gareth McCaughan
.sig under construc
From: james anderson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FEF1499.29606CDE@setf.de>
Gareth McCaughan wrote:
> 
> ...
> >
> > is there another definition for portability?
> 
> Application A is more portable than application B if the effort
> required to make A run on a new system is less than that required
> to make B run on a new system. (It might be advisable to normalize
> with respect to the sizes of A and B, somehow.) An application is
> maximally portable if there exists (even in potentiality) no other
> application that does substantially the same thing in substantially
> the same way but which is more portable.
> 
> Being able to compile (without intervention), load and run (correctly)
> on any conformant Lisp is roughly equivalent to being maximally portable,
> for that class of applications whose basic functionality doesn't
> prevent that. But, for instance, an application whose purpose is to
> dump live Linux filesystems by definition cannot run correctly in
> any system that isn't capable of *having* live Linux filesystems,
> so such an application could be maximally portable (by my definition)
> without being portable (by yours).

no, such an application is not portable. it does not even purport to being
portable. the definition

portable adj. (of code) required to produce equivalent results and observable
side effects in all conforming implementations.[0]

is not mine. should it be useful to talk about application which produce
"equivalent results and observable side effects" given constraints in addition
to implementation conformance, it would be appropriate to use another word.

...

[0] http://www.lispworks.com/reference/HyperSpec/Body/26_glo_p.htm#portable
From: Edi Weitz
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87pte8u8az.fsf@bird.agharta.de>
On Sun, 28 Dec 2003 18:36:37 +0100, james anderson <··············@setf.de> wrote:

> portable adj. (of code) required to produce equivalent results and
> observable side effects in all conforming implementations.[0]

Nice. That probably means that /every/ program is portable because
there clearly is no conforming implementation (at least none that I
know of).

To remind you: This thread started with Mr. Stacy complaining that it
is too hard to install a certain library. He specifically mentioned
CLISP and Corman Lisp which both definitely aren't conforming. I
myself remember adding #+/#- in various places of my (otherwise
portable) code to cater to these implementations. Do you suggest it
would be more helpful to prospective users if all libraries were 100%
"portable" but wouldn't run on any existing platform?

Edi.
From: james anderson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FEF2419.928E7B5E@setf.de>
Edi Weitz wrote:
> 
>..
> 
> To remind you: This thread started with Mr. Stacy complaining that it
> is too hard to install a certain library. He specifically mentioned
> CLISP and Corman Lisp which both definitely aren't conforming. I
> myself remember adding #+/#- in various places of my (otherwise
> portable) code to cater to these implementations. Do you suggest it
> would be more helpful to prospective users if all libraries were 100%
> "portable" but wouldn't run on any existing platform?

on the contrary. i entered this discussion to question the notion, that one
has accomplished something fundamental if one has adressed portability among
unix implementations only. i fail to see how the assertion, that purported
portability cannot depend on features which are either not portable or are
non-conformant could somehow lead to a claim that a purportedly portable
application should not run in an implementation which purports but does not
achieve conformance.

i am fairly good speaking terms with read-time conditionalization. where it is
possible to port an application by extending a #+/#- "clause", that is good.
where one can predict, in advance, that such adaptation will likely be
difficult, if not impossible, that is not good.

> 
> Edi.
From: Don Geddis
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ad5bl87s.fsf@sidious.geddis.org>
On Sun, 28 Dec 2003 18:36:37 +0100, james anderson <··············@setf.de> wrote:
> > portable adj. (of code) required to produce equivalent results and
> > observable side effects in all conforming implementations.[0]

Edi Weitz <···@agharta.de> writes:
> Nice. That probably means that /every/ program is portable because
> there clearly is no conforming implementation (at least none that I
> know of).

No, it doesn't mean that.  The definition of portable code doesn't actually
require the existence of any conforming implementation.  You still might be
able to prove that a given piece of source code is portable, even without
having a conforming implementation in front of you.

Of course, the real key is that almost all portable code will run just fine
in implementations which only "purport to conform".  Hence the utility of this
notion of "portable code".

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
From: Gareth McCaughan
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87isk0va03.fsf@g.mccaughan.ntlworld.com>
James Anderson wrote:

> > > is there another definition for portability?
> > 
> > Application A is more portable than application B if the effort
> > required to make A run on a new system is less than that required
> > to make B run on a new system. (It might be advisable to normalize
> > with respect to the sizes of A and B, somehow.) An application is
> > maximally portable if there exists (even in potentiality) no other
> > application that does substantially the same thing in substantially
> > the same way but which is more portable.
> > 
> > Being able to compile (without intervention), load and run (correctly)
> > on any conformant Lisp is roughly equivalent to being maximally portable,
> > for that class of applications whose basic functionality doesn't
> > prevent that. But, for instance, an application whose purpose is to
> > dump live Linux filesystems by definition cannot run correctly in
> > any system that isn't capable of *having* live Linux filesystems,
> > so such an application could be maximally portable (by my definition)
> > without being portable (by yours).
> 
> no, such an application is not portable. it does not even purport to being
> portable. the definition
> 
> portable adj. (of code) required to produce equivalent results and observable
> side effects in all conforming implementations.[0]

(Note: taken from the HyperSpec.)

> is not mine. should it be useful to talk about application which produce
> "equivalent results and observable side effects" given constraints in addition
> to implementation conformance, it would be appropriate to use another word.

The Hyperspec is a wonderful thing, but I see no reason to require
that all discussions of Common Lisp use its definitions in all
contexts. I think my definition is clearly more useful than the
HyperSpec one in most contexts.

Consider two applications. Both are designed to run only on Unix-like
systems. One of them has been written with care to make the minimum
set of assumptions beyond that. The other has been written to run
happily in CMUCL 18e on Debian Linux, and no attempt has been made
to make it easy to transfer to any other implementation or any other
operating system. The definition in the HyperSpec simply says: neither
of these programs is portable. It offers no way of saying that the
second is less portable than the first. Why should I prefer that over
my definition?

If there were something wrong with writing programs designed for
a particular subset of all possible platforms, then indeed it might
be better to use the term "portable" only for programs that will
(modulo bugs) run on any platform at all. So far as I can tell,
that is not the case.

Incidentally, I seem to recall that the following is a conforming
Common Lisp implementation.

    #include <stdio.h>
    #include <stdlib.h>

    int main(void) {
      fprintf(stderr, "Out of memory.\n");
      return 1;
    }

In which case there are *no* portable programs according to the
definition you quoted above.

-- 
Gareth McCaughan
.sig under construc
From: Mario S. Mommer
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <fzad5b8hz1.fsf@cupid.igpm.rwth-aachen.de>
Gareth McCaughan <················@pobox.com> writes:
>     #include <stdio.h>
>     #include <stdlib.h>
> 
>     int main(void) {
>       fprintf(stderr, "Out of memory.\n");
>       return 1;
>     }

Nope, that is scheme showing off its clean semantics.
From: Pascal Bourguignon
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ekuod2yo.fsf@thalassa.informatimago.com>
Gareth McCaughan <················@pobox.com> writes:
> > what's an environment variable?
> 
> Something available on every Unix-like system in the world.
> Observe the word "Unix" in the paragraph beginning "[2]".

Last time  I looked at  MS-DOS (ie, circa  1985), ISTR that  there was
environment variables there too...


-- 
__Pascal_Bourguignon__                              .  *   * . * .* .
http://www.informatimago.com/                        .   *   .   .*
There is no worse tyranny than to force             * .  . /\      . *
a man to pay for what he does not                    . .  / .\   . * .
want merely because you think it                    .*.  / *  \  . .
would be good for him. -- Robert Heinlein             . /*   o \     .
http://www.theadvocates.org/                        *   '''||'''   .
SCO Spam-magnet: ··········@sco.com                 ******************
From: Gareth McCaughan
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ekuov9yi.fsf@g.mccaughan.ntlworld.com>
Pascal Bourguignon <····@thalassa.informatimago.com> writes:

> Gareth McCaughan <················@pobox.com> writes:
> > > what's an environment variable?
> > 
> > Something available on every Unix-like system in the world.
> > Observe the word "Unix" in the paragraph beginning "[2]".
> 
> Last time  I looked at  MS-DOS (ie, circa  1985), ISTR that  there was
> environment variables there too...

I didn't say "only on Unix-like systems".

-- 
Gareth McCaughan
.sig under construc
From: Rahul Jain
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87wu8e93va.fsf@nyct.net>
Gareth McCaughan <················@pobox.com> writes:

> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>
>> Gareth McCaughan <················@pobox.com> writes:
>> > > what's an environment variable?
>> > 
>> > Something available on every Unix-like system in the world.
>> > Observe the word "Unix" in the paragraph beginning "[2]".
>> 
>> Last time  I looked at  MS-DOS (ie, circa  1985), ISTR that  there was
>> environment variables there too...
>
> I didn't say "only on Unix-like systems".

Regardless, the mention of MS-DOS hardly refutes even that incorrect
interpretation. ;)

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Björn Lindberg
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <hcswu8h6r8b.fsf@fnatte.nada.kth.se>
james anderson <··············@setf.de> writes:

> Bj�rn Lindberg wrote:
> > 
> > ······@news.dtpq.com (Christopher C. Stacy) writes:
> > 
> > > >>>>> On 28 Dec 2003 01:28:40 +0100, Bj�rn Lindberg ("Bj�rn") writes:
> > >  Bj�rn> A comment on the broader issue discussed in this thread: I would like
> > >  Bj�rn> to see some sort of agreed-upon (informal) standards developed for CL
> > >  Bj�rn> on Unix. Standardized places where source and binary files go in the
> > >  Bj�rn> file system, perhaps some standardized environment variables.
> > >
> > >  Bj�rn> Compare with C: anyone writing or installing a C library,
> > >  Bj�rn> or packaging a library for a distro, can count on the basic
> > >  Bj�rn> directory structure, with /.../{lib,include}, can count on
> > >  Bj�rn> environment variables like CC, LD_*, etc. I think more of a de
> > >  Bj�rn> facto standard in this area for CL would make it much easier
> > >  Bj�rn> for people to use different administration/installation tools,
> > >  Bj�rn> different distro packaging systems, and lots of other issues
> > >  Bj�rn> like that.
> > >
> > > This is what logical pathnames are supposed to be for.
> > > The installation procedure is supposed to look in some standard
> > > place to find or put the logical translation host definition.
> > 
> > Yes, but I think there should also be a Unix standard for pathnames
> > and environment variables. If these are mapped to by logical
> > pathnames[1], and these logical pathnames perhaps are stanadrized over
> > other platforms as well, then all the better, but I still think a more
> > standardized approach on Unix would be good.
> 
> unless it is implemented in terms of ansi behaviour, the question remains,
> good for what?

Good for (1) anyone implementing or maintaining an implementation of
Lisp on Unix, such that it will easily interoperate with other Lisp
facilities available on Unix, (2) anyone authoring a library for Lisp
on Unix, (3) anyone maintaining packages (in the distro sense) of (1)
or (2) for a specifix Unix system/distribution, (4) etc...

> > [1] I actually did try to use logical pathnames at first for my hack I
> > included in the post you responded to, but I was hesitant, because
> > AFAICT, logical pathnames cannot cope with such things as mixed-case
> > file names and certain characters in filenames, and I cannot guarantee
> > that a library writer will not name files in a package in such a way
> > that logical pathnames cannot be used to refer to them.
> > 
> 
> i thought this thread was about problem-free, portable library installation.
> if a library writer has chosen a non-portable syntax to name source files,
> they have declared the library to be non-portable. what is the benefit of
> tailoring a build system to that goal?

I am sorry if I was unclear. I was restricting the scope to talk about
substandards specifically for Unix. I am well aware that there are
other operating systems out there, but I don't see how they get hurt
just because we make things a bit easier on Unix. Ideally, this Unix
substandard would of course blend well with more general approaches.

> > [2] Here is a not well thought out quick suggestion for a proposal: In
> > a standard Unix CL installation, library code should reside in the
> > following locations:
> > 
> >   /usr/share/common-lisp/src/
> >   /usr/share/common-lisp/system/
> >   /usr/lib/common-lisp/<implementation name>/
> > 
> > Similar locations could exist for the /usr/local/ hierarchy for local
> > installations.
> > 
> > An environment variable called COMMON_LISP_FEATURES could function
> > like a shell equivalent to the *features* variable, and could eg
> > include the available implementations ("cmucl clisp sbcl").
> 
> what's an environment variable?

It is an important concept in the Unix environment. I suggest that
Common Lisp on Unix should standardize its use for Lisp purposes.


Bj�rn
From: james anderson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FEEE1AF.95B9F918@setf.de>
Bj�rn Lindberg wrote:
> 
> james anderson <··············@setf.de> writes:
> 
> ...
> >
> > i thought this thread was about problem-free, portable library installation.
> > if a library writer has chosen a non-portable syntax to name source files,
> > they have declared the library to be non-portable. what is the benefit of
> > tailoring a build system to that goal?
> 
> I am sorry if I was unclear. I was restricting the scope to talk about
> substandards specifically for Unix. I am well aware that there are
> other operating systems out there, but I don't see how they get hurt
> just because we make things a bit easier on Unix. Ideally, this Unix
> substandard would of course blend well with more general approaches.

my impression, from the occasions when i've worked with libraries which are
written from this point of view, is that ideal is an illusion.

> 
> ...
> > >
> > > An environment variable called COMMON_LISP_FEATURES could function
> > > like a shell equivalent to the *features* variable, and could eg
> > > include the available implementations ("cmucl clisp sbcl").
> >
> > what's an environment variable?

the question was rhetorical.

> 
> It is an important concept in the Unix environment. I suggest that
> Common Lisp on Unix should standardize its use for Lisp purposes.

to what end. (note, i did read the 1,2,3,4 in the response before elision.)

just because one can do this,

[tschichold:clisp/clisp-2003-12-26/build-20031226]                            
                                                                        
janson% ./clisp
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2003


[1]> (getenv "COMMON_LISP_FEATURES")
NIL
[2]> (exit)
Bye.
[tschichold:clisp/clisp-2003-12-26/build-20031226]                            
                                                                        
janson% 



does not mean that one is any where near to asking the correct questions to
address this

Welcome to Macintosh Common Lisp Version 4.3.1!
? (getenv "COMMON_LISP_FEATURES")
> Error: Undefined function GETENV called with arguments ("COMMON_LISP_FEATURES") .
> While executing: "Unknown"
> Type Command-/ to continue, Command-. to abort.
> If continued: Retry applying GETENV to ("COMMON_LISP_FEATURES").
See the Restarts� menu item for further choices.
1 > 

...
From: Björn Lindberg
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <hcssmj47vib.fsf@fnatte.nada.kth.se>
james anderson <··············@setf.de> writes:

> Bj�rn Lindberg wrote:
> > 
> > james anderson <··············@setf.de> writes:
> > 
> > ...
> > >
> > > i thought this thread was about problem-free, portable library installation.
> > > if a library writer has chosen a non-portable syntax to name source files,
> > > they have declared the library to be non-portable. what is the benefit of
> > > tailoring a build system to that goal?
> > 
> > I am sorry if I was unclear. I was restricting the scope to talk about
> > substandards specifically for Unix. I am well aware that there are
> > other operating systems out there, but I don't see how they get hurt
> > just because we make things a bit easier on Unix. Ideally, this Unix
> > substandard would of course blend well with more general approaches.
> 
> my impression, from the occasions when i've worked with libraries which are
> written from this point of view, is that ideal is an illusion.

So, independent of there being any truly portable standard for build &
install systems, it is a bad thing if there exists one for Unix? I am
advocating standardising very low level things, for other layers to
build on. I fail to see how this can be a bad thing.

> > > > An environment variable called COMMON_LISP_FEATURES could function
> > > > like a shell equivalent to the *features* variable, and could eg
> > > > include the available implementations ("cmucl clisp sbcl").
> > >
> > > what's an environment variable?
> 
> the question was rhetorical.

I guessed as much.

> > It is an important concept in the Unix environment. I suggest that
> > Common Lisp on Unix should standardize its use for Lisp purposes.
> 
> to what end. (note, i did read the 1,2,3,4 in the response before elision.)
> 
> just because one can do this,
> [ snip example regarding environment variables ]

I will give you an example use case. Suppose that I have three
different Lisps on my Unix box (eg cmucl, sbcl & clisp). I want to use
my build system to install a new Lisp library. Perhaps I give the
commands at the shell prompt, through a GUI program or at a Lisp REPL,
but I want to be able to build the library for all my Lisps by issuing
one command. I do not want to have to manually start up an incarnation
of each Lisp and issue commands from them. Thus, my build system needs
infromation about which Lisps are installed on my box. This
information is system information, not information from within any of
my Lisps. I cannot count on any one of my Lisps being able to present
it. Such system information can, on Unix, be made available through
environment variables. I am proposing that this system interface be
standardised, so that there can exist different build/install systems,
or different layers of them, that all share the same interface. On the
Mac, I guess there is some other way to make this kind of infromation
available, and then a more system independent layer could abstract
away the mechanism, and work on both Unix and Mac.

In the same way, even if there exists a Unix file system hierarchy
standard for CL as I suggested earlier, nothing prevents there being a
higher level layer which maps some standardised logical pathnames to
this directory structure, and thus is portable over different
platforms. The Unix substandard could be very useful at its level
without interfering at all with higher layers. Au contraire, the Unix
substandard would probably help build a higher level layer which will
work well on Unix (as well as other platforms of course).

So, in conclusion, I think we are discussing different layers of the
issue. What I don't see is why you think that standardising the layer
I am talking about would complicate anything at a higher level.


Bj�rn
From: james anderson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FEF1614.341E549B@setf.de>
Bj�rn Lindberg wrote:
> 
> ...
> >
> > my impression, from the occasions when i've worked with libraries which are
> > written from this point of view, is that ideal is an illusion.
> 
> So, independent of there being any truly portable standard for build &
> install systems, it is a bad thing if there exists one for Unix? I am
> advocating standardising very low level things, for other layers to
> build on. I fail to see how this can be a bad thing.
> 

to quote from another respose:

> ... it is, on the other hand, not productive for a build system to induce
> library authors to formulate a build specification such that either it is, in
> itself, non-portable, or the build system is not capable of interpreting it portably.
> 

...
From: Björn Lindberg
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <hcsoets7c56.fsf@fnatte.nada.kth.se>
james anderson <··············@setf.de> writes:

> Bj�rn Lindberg wrote:
> > 
> > ...
> > >
> > > my impression, from the occasions when i've worked with libraries which are
> > > written from this point of view, is that ideal is an illusion.
> > 
> > So, independent of there being any truly portable standard for build &
> > install systems, it is a bad thing if there exists one for Unix? I am
> > advocating standardising very low level things, for other layers to
> > build on. I fail to see how this can be a bad thing.
> > 
> 
> to quote from another respose:
> 
> > ... it is, on the other hand, not productive for a build system to induce
> > library authors to formulate a build specification such that either it is, in
> > itself, non-portable, or the build system is not capable of interpreting it portably.
> > 

I read it the first time, but I still don't see what it has to do with
what I am saying. From the UI of a build/install system all the way
down to the metal, along the way there will be portable layers,
partially portable layers and unportable layers, the last being the
layer that communicates directly with the underlying platform. What I
am talking about is that I see some gains to be had from standardising
this lowest layer *on the Unix platform*.

Here is another reason: Someone working on Unix *will* want to be able
to work with his Lisp system both "from the inside" and "from the
outside". I should be able to sit down at a new box and have some
intuitive notion of where in the file system different Lisp stuff is,
or which Lisps are installed. At least I think so. If I find a Lisp
library that for some reason isn't installable by some fancy
install/build method, I should still be able to manually make it fit
in nicely with the rest of the system. Since Common Lisp is not
exactly common on Unix today, I think a "standard" of some sort could
really succeed in being used. Watch all the pain that went into the
File Hierarchy Standard (http://www.pathname.com/fhs/), standardising
such simple things as which file goes where on a Unix system. Wouldn't
it be great if when Common Lisp becomes really popular again, and is
installed on every box, things like the directory structure and
perhaps cross-implementation information was reasonably 
standardised? :-)

(I'm looking forward to a Common Lisp chapter in the FHS. :-)


Bj�rn
From: james anderson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FEF6DFF.AD25F233@setf.de>
Bj�rn Lindberg wrote:
> 
> ... Watch all the pain that went into the
> File Hierarchy Standard (http://www.pathname.com/fhs/), standardising
> such simple things as which file goes where on a Unix system. Wouldn't
> it be great if when Common Lisp becomes really popular again, and is
> installed on every box, things like the directory structure and
> perhaps cross-implementation information was reasonably
> standardised? :-)

if you figure out how to express "cross-implementation information" in a
standardised form, that would be a good thing. i suggest that "standardized"
does not mix well with physical pathname namestrings and implementation
directly in terms of os-specific primitives.

> 
> (I'm looking forward to a Common Lisp chapter in the FHS. :-)
> 
> Bj�rn
From: Björn Lindberg
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <hcsk74g7a74.fsf@fnatte.nada.kth.se>
james anderson <··············@setf.de> writes:

> Bj�rn Lindberg wrote:
> > 
> > ... Watch all the pain that went into the
> > File Hierarchy Standard (http://www.pathname.com/fhs/), standardising
> > such simple things as which file goes where on a Unix system. Wouldn't
> > it be great if when Common Lisp becomes really popular again, and is
> > installed on every box, things like the directory structure and
> > perhaps cross-implementation information was reasonably
> > standardised? :-)
> 
> if you figure out how to express "cross-implementation information" in a
> standardised form, that would be a good thing.

As far as I can see, and have explained, this cannot be done within
Lisp, it has to be done outside of Lisp, ie in the environment of the
platform. (Eg with Unix environment variables).

> i suggest that "standardized"
> does not mix well with physical pathname namestrings and implementation
> directly in terms of os-specific primitives.

Oh, I see. I mean standardised from a Unix perspective, not a Lisp
one.


Bj�rn
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <w4c7k0fix6i.fsf@boris.cd.chalmers.se>
·······@nada.kth.se (Bj�rn Lindberg) writes:
> james anderson <··············@setf.de> writes:
> > if you figure out how to express "cross-implementation information" in a
> > standardised form, that would be a good thing.
> 
> As far as I can see, and have explained, this cannot be done within
> Lisp, it has to be done outside of Lisp, ie in the environment of the
> platform. (Eg with Unix environment variables).

Keeping this information in an environment variable would, IMO, be
bad. Better to keep it in a file, or something at least accessible
as a file. When in unix, do as the eunuchs, or something.

Regards,

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_
From: Björn Lindberg
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <hcs4qvjb1at.fsf@knatte.nada.kth.se>
rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:

> ·······@nada.kth.se (Bj�rn Lindberg) writes:
> > james anderson <··············@setf.de> writes:
> > > if you figure out how to express "cross-implementation information" in a
> > > standardised form, that would be a good thing.
> > 
> > As far as I can see, and have explained, this cannot be done within
> > Lisp, it has to be done outside of Lisp, ie in the environment of the
> > platform. (Eg with Unix environment variables).
> 
> Keeping this information in an environment variable would, IMO, be
> bad. Better to keep it in a file, or something at least accessible
> as a file. When in unix, do as the eunuchs, or something.

I think it depends on what kind of information is in question. For
small, flag-like pieces of information, I think the difficulty of
agreeing on the format and placement of a file exceeds its increased
flexibility. In my example, I suggested an environment variable holding
information similar to the *features* variable, ie just flags
indicating the presence or absence of something from the system. This
IMO is better kept in an environment variable (which is also easier to
temporarily override), and is in the "Unix spirit".


Bj�rn
From: Pascal Bourguignon
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87n09cd37v.fsf@thalassa.informatimago.com>
james anderson <··············@setf.de> writes:
> [tschichold:clisp/clisp-2003-12-26/build-20031226]                            
> [1]> (getenv "COMMON_LISP_FEATURES")
> NIL

> Welcome to Macintosh Common Lisp Version 4.3.1!
> ? (getenv "COMMON_LISP_FEATURES")
> > Error: Undefined function GETENV called with arguments ("COMMON_LISP_FEATURES") .

Another example of  the kind of items I don't  like in the Common-Lisp
specification.  It  says that a  conformant implementation is  free to
use any implementation defined package in COMMON-LISP-USER.


This has the negative consequences that:

1- I have to do this first thing in ALL the init rc files of all the
   Common-Lisp implementations I use:

(MAPC (LAMBDA (USED) (UNUSE-PACKAGE USED "COMMON-LISP-USER"))
      (REMOVE (FIND-PACKAGE "COMMON-LISP") 
              (COPY-SEQ (PACKAGE-USE-LIST "COMMON-LISP-USER"))))


2- Unsuspecting users of clisp believe that they're entitled to write:
    (GETENV "HOME")
  while they shoud write:
    (EXT:GETENV "HOME")
  and therefore, clearly documenting the fact that they're using 
  clisp specific EXT package.




Ok, nothing  that some self  imposed discipline cannot solve,  but the
point is  exactly here: available free libraries  lack the homogeneity
and  well defined  interfaces  that come  with  self discipline  since
there's no imposed discipline.

-- 
__Pascal_Bourguignon__                              .  *   * . * .* .
http://www.informatimago.com/                        .   *   .   .*
There is no worse tyranny than to force             * .  . /\      . *
a man to pay for what he does not                    . .  / .\   . * .
want merely because you think it                    .*.  / *  \  . .
would be good for him. -- Robert Heinlein             . /*   o \     .
http://www.theadvocates.org/                        *   '''||'''   .
SCO Spam-magnet: ··········@sco.com                 ******************
From: Rahul Jain
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87oetq93g8.fsf@nyct.net>
Pascal Bourguignon <····@thalassa.informatimago.com> writes:

> Ok, nothing  that some self  imposed discipline cannot solve,  but the
> point is  exactly here: available free libraries  lack the homogeneity
> and  well defined  interfaces  that come  with  self discipline  since
> there's no imposed discipline.

The same is true for commercial libraries. The only discipline ever
imposed is your own, unless, of course, there's some sort of legal
conflict involved.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Edi Weitz
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87u13lgl47.fsf@bird.agharta.de>
On Sun, 28 Dec 2003 13:25:16 +0100, james anderson <··············@setf.de> wrote:

> i thought this thread was about problem-free, portable library
> installation. if a library writer has chosen a non-portable syntax
> to name source files, they have declared the library to be
> non-portable.

Most "interesting" libraries (the ones that people on c.l.l are asking
about) are non-portable anyway. As soon as you have to deal with
sockets, foreign functions or anything that isn't a standard character
you are non-portable.

Edi.
From: james anderson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FEEDF77.11A47421@setf.de>
Edi Weitz wrote:
> 
> On Sun, 28 Dec 2003 13:25:16 +0100, james anderson <··············@setf.de> wrote:
> 
> > i thought this thread was about problem-free, portable library
> > installation. if a library writer has chosen a non-portable syntax
> > to name source files, they have declared the library to be
> > non-portable.
> 
> Most "interesting" libraries (the ones that people on c.l.l are asking
> about) are non-portable anyway. As soon as you have to deal with
> sockets, foreign functions or anything that isn't a standard character
> you are non-portable.
> 

if the library is an interface<em><bold>to</bold> the operating system<em>, i agree.

any ""interesting"" library which, despite that is not an interface to the
operating system, is written from this point of view, is not part of the
solution. it is part of the problem.

one of my ruder surprises of late was to discover collections of files which
purport to be clx distributions, but which have been "ported" such that day-1
compatibility was eliminated.

...
From: Christophe Rhodes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <sqsmj429n2.fsf@lambda.jcn.srcf.net>
james anderson <··············@setf.de> writes:

> Edi Weitz wrote:
>> 
>> On Sun, 28 Dec 2003 13:25:16 +0100, james anderson <··············@setf.de> wrote:
>> 
>> > i thought this thread was about problem-free, portable library
>> > installation. if a library writer has chosen a non-portable syntax
>> > to name source files, they have declared the library to be
>> > non-portable.
>> 
>> Most "interesting" libraries (the ones that people on c.l.l are asking
>> about) are non-portable anyway. As soon as you have to deal with
>> sockets, foreign functions or anything that isn't a standard character
>> you are non-portable.
>
> if the library is an interface<em><bold>to</bold> the operating
> system<em>, i agree.

What's an operating system?  Please don't answer "just the kernel".

> any ""interesting"" library which, despite that is not an interface to the
> operating system, is written from this point of view, is not part of the
> solution. it is part of the problem.

You see no use for the MOP as decribed in the Art of the Metaobject
Protocol, then?

> one of my ruder surprises of late was to discover collections of
> files which purport to be clx distributions, but which have been
> "ported" such that day-1 compatibility was eliminated.

I see no-one stepping forward to maintain completely portable CLX.  Do
you?  In case you are under the misguided assumption that there is no
cost involved in such an endeavour, just think about the requirements
for efficiency a little.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: james anderson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FEF15EE.7FC721CC@setf.de>
Christophe Rhodes wrote:
> 
> james anderson <··············@setf.de> writes:
> 
> > Edi Weitz wrote:
> >>
> >> On Sun, 28 Dec 2003 13:25:16 +0100, james anderson <··············@setf.de> wrote:
> >>
> >> > i thought this thread was about problem-free, portable library
> >> > installation. if a library writer has chosen a non-portable syntax
> >> > to name source files, they have declared the library to be
> >> > non-portable.
> >>
> >> Most "interesting" libraries (the ones that people on c.l.l are asking
> >> about) are non-portable anyway. As soon as you have to deal with
> >> sockets, foreign functions or anything that isn't a standard character
> >> you are non-portable.
> >
> > if the library is an interface<em><bold>to</bold> the operating
> > system<em>, i agree.
> 
> What's an operating system?  Please don't answer "just the kernel".

there is no need to prevaricate. to "<em>deal</em> with sockets, foreign
functions or anything that isn't a standard character" requires that the
library afford more than a wrapper for that which the underlying
implementation offers. unless, of course, the goal is to sell a particular
implementation. if the goal is to provide a lisp library, one has not produced
a useful, interesting library until one admits portability as part of the problem.

> 
> > any ""interesting"" library which, despite that is not an interface to the
> > operating system, is written from this point of view, is not part of the
> > solution. it is part of the problem.
> 
> You see no use for the MOP as decribed in the Art of the Metaobject
> Protocol, then?

you misconstrue. i would see no use for a mop which required that the
application use facilities which are present in one implementation only. the
art of the metaobject protocol describes a library which is both interesting
and ostensibly portable.


> 
> > one of my ruder surprises of late was to discover collections of
> > files which purport to be clx distributions, but which have been
> > "ported" such that day-1 compatibility was eliminated.
> 
> I see no-one stepping forward to maintain completely portable CLX. Do
> you?

it does not matter whether or not someone is willing or able to do that. no, i
did not read through the code to attempt to understand why someone identified
expediency with necessity. i remain surpised at seeing code, which derived
from source which i had used over a decade ago in more than one lisp
implementation, which was now non-portable.

...
From: Christophe Rhodes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <sqbrprevf4.fsf@lambda.jcn.srcf.net>
james anderson <··············@setf.de> writes:

> Christophe Rhodes wrote:
>> 
>> james anderson <··············@setf.de> writes:
>> > one of my ruder surprises of late was to discover collections of
>> > files which purport to be clx distributions, but which have been
>> > "ported" such that day-1 compatibility was eliminated.
>> 
>> I see no-one stepping forward to maintain completely portable CLX. Do
>> you?
>
> it does not matter whether or not someone is willing or able to do
> that. no, i did not read through the code to attempt to understand
> why someone identified expediency with necessity. i remain surpised
> at seeing code, which derived from source which i had used over a
> decade ago in more than one lisp implementation, which was now
> non-portable.

Well, let me try to address this surprise, by doing the work of
reading through the code for you.

Firstly, you presumably accept on my word that there are elements of
CLX which must use extra-standard functionality.  If you don't, of
course, we can stop having this discussion.  Such functionality comes
in two parts: firstly, use of implementation-specific interfaces to
sockets; secondly, use of implementation-specific idioms and
optimization directives to ensure non-painful performance.

If one distributes code advertised as 'portable', even implicitly (by
the presence of many read-time conditionals, for instance), one takes
responsibility for functionality.  If one wishes to make modifications
to a relatively complex codebase, it behooves the maintainer to test
that the modifications have not introduced a deleterious effect
anywhere.  That "anywhere" becomes significantly harder to investigate
if access to the systems claimed is not available.  I would therefore
argue that a responsible maintainer for a distribution of CLX would
only advertise functionality for which he feels able to be confident
about, and let the market of potential users offer testing facilities
and/or expertise for those systems not directly accessible.

As for "now non-portable" nature of CLX, please disabuse yourself of
this notion; it always was non-portable.  It may be instructive for
you if you were to attempt to use the original CLX distribution in,
say, SBCL.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Pascal Bourguignon
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87isk0d31v.fsf@thalassa.informatimago.com>
Edi Weitz <···@agharta.de> writes:

> On Sun, 28 Dec 2003 13:25:16 +0100, james anderson <··············@setf.de> wrote:
> 
> > i thought this thread was about problem-free, portable library
> > installation. if a library writer has chosen a non-portable syntax
> > to name source files, they have declared the library to be
> > non-portable.
> 
> Most "interesting" libraries (the ones that people on c.l.l are asking
> about) are non-portable anyway. As soon as you have to deal with
> sockets, foreign functions or anything that isn't a standard character
> you are non-portable.
> 
> Edi.

We don't need portable libraries. We need portable interfaces!

(Well, once  there's a portable  FFI (UFFI being  a step in  the right
direction, but based on a  lowest, common denominator), you can easily
implement   libraries   portable  accros   a   range  of   Common-Lisp
implementations running on a same system class).


-- 
__Pascal_Bourguignon__                              .  *   * . * .* .
http://www.informatimago.com/                        .   *   .   .*
There is no worse tyranny than to force             * .  . /\      . *
a man to pay for what he does not                    . .  / .\   . * .
want merely because you think it                    .*.  / *  \  . .
would be good for him. -- Robert Heinlein             . /*   o \     .
http://www.theadvocates.org/                        *   '''||'''   .
SCO Spam-magnet: ··········@sco.com                 ******************
From: Edi Weitz
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87llowtxnw.fsf@bird.agharta.de>
On 28 Dec 2003 22:51:08 +0100, Pascal Bourguignon <····@thalassa.informatimago.com> wrote:

> We don't need portable libraries. We need portable interfaces!

No, we need people who say that we need portable interfaces. Much
better.

Edi.
From: Rahul Jain
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87smj293mm.fsf@nyct.net>
·······@nada.kth.se (Bj�rn Lindberg) writes:

> [2] Here is a not well thought out quick suggestion for a proposal: In
> a standard Unix CL installation, library code should reside in the
> following locations:
>
>   /usr/share/common-lisp/src/
>   /usr/share/common-lisp/system/
>   /usr/lib/common-lisp/<implementation name>/
>
> Similar locations could exist for the /usr/local/ hierarchy for local
> installations.

This is basically the common-lisp-controller standard. At least this was
how it was viewed back when we were deluded into believing that there
might be some RedHat people interested in helping those of us who hardly
ever use, let alone administer, a redhat box to provide some sort of
similar system for solving the problem cstacy was complaining
about. Needless to say, our delusions were exposed as such, and we even
predicted threads like this one (ok, maybe not as bad as this one) at
the time.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Rahul Jain
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87r7yn9iyp.fsf@nyct.net>
······@news.dtpq.com (Christopher C. Stacy) writes:

> This is what logical pathnames are supposed to be for.
> The installation procedure is supposed to look in some standard
> place to find or put the logical translation host definition.

This would prevent the same directory and file structure from being used
by multiple implementations. This is why asdf does not use LPNs. This is
but one facet of Christophe's combinatorial explosion problem. Not only
will you need each implementation to have a hook for this package
manager, you will need to have a separate source tree (at least symlinks
into one common set of files) for each implementation.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: james anderson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FF14D02.A9ED6551@setf.de>
Rahul Jain wrote:
> 
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> 
> > This is what logical pathnames are supposed to be for.
> > The installation procedure is supposed to look in some standard
> > place to find or put the logical translation host definition.
> 
> This would prevent the same directory and file structure from being used
> by multiple implementations. This is why asdf does not use LPNs. This is
> but one facet of Christophe's combinatorial explosion problem. Not only
> will you need each implementation to have a hook for this package
> manager, you will need to have a separate source tree (at least symlinks
> into one common set of files) for each implementation.
> 

would it be possible to post a library specification which illustrates this problem?
From: Rahul Jain
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ekul5v68.fsf@nyct.net>
james anderson <··············@setf.de> writes:

> Rahul Jain wrote:
>
>> This would prevent the same directory and file structure from being used
>> by multiple implementations. This is why asdf does not use LPNs. This is
>> but one facet of Christophe's combinatorial explosion problem. Not only
>> will you need each implementation to have a hook for this package
>> manager, you will need to have a separate source tree (at least symlinks
>> into one common set of files) for each implementation.
>
> would it be possible to post a library specification which illustrates this problem?

Any library which has files ending in ".lisp" and needing to be loaded
by clisp. (This has possibly changed, but the point is that the previous
behavior was perfectly conforming. LPNs are not a way to read files
pre-existing on the filesystem, but a way to read files that were
created with LPNs _in_the_same_implementation_.)

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: james anderson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FF293E7.3D964628@setf.de>
Rahul Jain wrote:
> 
> james anderson <··············@setf.de> writes:
> 
> > Rahul Jain wrote:
> >
> >> This would prevent the same directory and file structure from being used
> >> by multiple implementations. This is why asdf does not use LPNs. This is
> >> but one facet of Christophe's combinatorial explosion problem. Not only
> >> will you need each implementation to have a hook for this package
> >> manager, you will need to have a separate source tree (at least symlinks
> >> into one common set of files) for each implementation.
> >
> > would it be possible to post a library specification which illustrates this problem?
> 
> Any library which has files ending in ".lisp" and needing to be loaded
> by clisp. (This has possibly changed, but the point is that the previous
> behavior was perfectly conforming. LPNs are not a way to read files
> pre-existing on the filesystem, but a way to read files that were
> created with LPNs _in_the_same_implementation_.)

my most recent attempt to port to clisp was in august, based on 2.30. none of
the conditionalizations concerned pathnames.

...
From: Rahul Jain
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87y8sspmuw.fsf@nyct.net>
james anderson <··············@setf.de> writes:

> my most recent attempt to port to clisp was in august, based on 2.30. none of
> the conditionalizations concerned pathnames.

The point of the thread was that we need to develop a system that is
guaranteed to work on any combination of OS and implementation that
anyone might want to use, otherwise, it's "our" (whoever that is) fault
that it doesn't and people like cstacy will flame us. This is provably
impossible with LPNs.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Lupo LeBoucher
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <OuadneYEOMQMvnCi4p2dnA@io.com>
In article <··············@sidious.geddis.org>,
Don Geddis  <···@geddis.org> wrote:
>Eladio <··············@yahoo.com> writes:
>> The problem is not firing up the lisp systems - they all work.
>
>Great!
>
>> The problems arrive the second you try to write your first application
>> and it dawns on you that you have nothing along the lines of "getopt",
>> "configParser", or whatever. WHAMMO - Welcome to Newbie Hell. So you discover
>> cliki, cclan, cclib and all those great libraries jam-packed with goodies to
>> sink your teeth into... and find that you spend days on end to move
>> forward. Hence the frustration.
>
>This hasn't been my experience.  I've written tons of Lisp code, and only
>very, very rarely have I used third-party libraries.

That's because you never had to do anything which involved, say, something 
like a GUI.

And ... what the first guy said.

-Lupo
"the vague tori, being of too indistinct a character to object, are then
heavily exploited" -W.P. Reinhardt                    <··@fnord.io.com>
From: Don Geddis
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87oetu2kn4.fsf@sidious.geddis.org>
I wrote:
> >This hasn't been my experience.  I've written tons of Lisp code, and only
> >very, very rarely have I used third-party libraries.

··@io.com (Lupo LeBoucher) writes:
> That's because you never had to do anything which involved, say, something 
> like a GUI.

Well, first of all, a newbie isn't forced to write GUIs.  If that's so hard,
then pick some other interesting application to get started.

As for me, I've certainly written web-based GUIs without any third-party
libraries.  HTTP/HTML is a simple enough protocol that you can code it up
yourself in a few hours.

That said, I'll agree that if you wanted to write X-windows GUI applications,
you probably need some libraries on top of Common Lisp before you start.
But this shouldn't be the key that prevents novices from getting into Lisp,
such that their difficult in writing Lisp X GUIs means they abandon Lisp
all together.  That seems too extreme.

        -- Don
_______________________________________________________________________________
Don Geddis                  http://don.geddis.org/               ···@geddis.org
From: Lupo LeBoucher
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <_sqdnd-8-Z-mEmmiRVn-uw@io.com>
In article <··············@sidious.geddis.org>,
Don Geddis  <···@geddis.org> wrote:
>I wrote:
>> >This hasn't been my experience.  I've written tons of Lisp code, and only
>> >very, very rarely have I used third-party libraries.
>
>··@io.com (Lupo LeBoucher) writes:
>> That's because you never had to do anything which involved, say, something 
>> like a GUI.
>
>Well, first of all, a newbie isn't forced to write GUIs.  If that's so hard,
>then pick some other interesting application to get started.

It's not that writing a GUI is hard. It's relatively easy. The hard thing 
is finding, making and loading the damned libraries with the GUI 
intestines in it. That's a big pain in the hiney-hole, and there is no 
reason for it to be.

>As for me, I've certainly written web-based GUIs without any third-party
>libraries.  HTTP/HTML is a simple enough protocol that you can code it up
>yourself in a few hours.

I suppose, but, like, why should you have to?
I was able to pipe all kinds of neat stuff through Python's web doodads 
without knowing much about the language, or having to roll my own web 
server (or using apache). The libraries that come with Python or are 
available for it are most useful, easy to make and use. If I had such 
useful stuff in CMU-CL, I'd never use anything else.

>That said, I'll agree that if you wanted to write X-windows GUI applications,
>you probably need some libraries on top of Common Lisp before you start.
>But this shouldn't be the key that prevents novices from getting into Lisp,
>such that their difficult in writing Lisp X GUIs means they abandon Lisp
>all together.  That seems too extreme.

I heartily agree. The problem for me is, C/L doesn't have the built in 
functionality I would like to use for ... any number of things (data 
analysis & display, GUI doodads, floating point code, etc etc). And I find 
the making and installation of libraries and large packages in CL to be 
atrociously difficult. This hasn't been the case with any other language 
or environment I have ever used (C, C++, Fortran-XX, various assemblers,
Matlab, IDL, Python blah blah).

I find this unfortunate, as the language itself is the tits. Whether or 
not this difficulty is an effect of the inherent niftiness of the 
language, it seems that one could do better than this. Python did.

-Lupo
"Quod licet Jovi, non licet bovi"                       <··@fnord.io.com>
      
From: Matthew Danish
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <20040101235138.GB31217@mapcar.org>
On Thu, Jan 01, 2004 at 03:20:59PM -0600, Lupo LeBoucher wrote:
> >As for me, I've certainly written web-based GUIs without any third-party
> >libraries.  HTTP/HTML is a simple enough protocol that you can code it up
> >yourself in a few hours.
> 
> I suppose, but, like, why should you have to?
> I was able to pipe all kinds of neat stuff through Python's web doodads 
> without knowing much about the language, or having to roll my own web 
> server (or using apache). The libraries that come with Python or are 
> available for it are most useful, easy to make and use. If I had such 
> useful stuff in CMU-CL, I'd never use anything else.

What's wrong with portable allegroserve?  Or mod_lisp?

> >That said, I'll agree that if you wanted to write X-windows GUI applications,
> >you probably need some libraries on top of Common Lisp before you start.
> >But this shouldn't be the key that prevents novices from getting into Lisp,
> >such that their difficult in writing Lisp X GUIs means they abandon Lisp
> >all together.  That seems too extreme.
> 
> I heartily agree. The problem for me is, C/L doesn't have the built in 
> functionality I would like to use for ... any number of things (data 
> analysis & display, GUI doodads, floating point code, etc etc). And I find 
> the making and installation of libraries and large packages in CL to be 
> atrociously difficult. This hasn't been the case with any other language 
> or environment I have ever used (C, C++, Fortran-XX, various assemblers,
> Matlab, IDL, Python blah blah).

Well first, CL most definitely has floating point support.  And its core
numerical support goes far beyond most languages.  Secondly, the only
reason that the making and installation of C (etc) libraries isn't so
difficult is the extraordinary amount of effort that has gone into the
simplication and standardization of the interfaces and processes
involved.  While there aren't so many CL programmers, I think a lot of
good progress has been made with projects like ASDF, and it is pretty
simple to install CL libraries that use ASDF (especially with CMUCL,
SBCL).  Generally you unpack the library (say, from CLiki [1]) and make
a symlink to its .asd file from a directory you have reserved for such
purpose (and that ASDF knows about).  Then you can simply load the
library in an ASDF-enabled lisp by typing 

(asdf:operate 'asdf:load-op 'name) 

> I find this unfortunate, as the language itself is the tits. Whether or 
> not this difficulty is an effect of the inherent niftiness of the 
> language, it seems that one could do better than this. Python did.

The problem is a larger one than for Python because of the availability
of several implementations, and there perhaps is not as much motivation
to create an extensive loading system because of the image-based
development environments; it is not so crucial to have a module system
when you can do lots of work without one.

[1] http://www.cliki.net/

-- 
; Matthew Danish <·······@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."
From: Marc Battyani
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bt262o$d4t@library2.airnews.net>
"Lupo LeBoucher" <··@io.com> wrote in message

> I was able to pipe all kinds of neat stuff through Python's web doodads
> without knowing much about the language, or having to roll my own web
> server (or using apache). The libraries that come with Python or are
> available for it are most useful, easy to make and use. If I had such
> useful stuff in CMU-CL, I'd never use anything else.

Great, so port them to Common Lisp and be happy for ever.

> I find this unfortunate, as the language itself is the tits. Whether or
> not this difficulty is an effect of the inherent niftiness of the
> language, it seems that one could do better than this. Python did.

Hum... It's not Python that did it, it's Python developpers. They write code
instead of talking about how it would be great is somebody would write code.

Marc
From: Kenny Tilton
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <lF2Jb.75340$4F2.7410850@twister.nyc.rr.com>
Lupo LeBoucher wrote:

> server (or using apache). The libraries that come with Python or are 
> available for it are most useful, easy to make and use.


Python has a big, active user base, which is where those libs came from 
(not Python, though it being C at heart does not hurt).

> If I had such 
> useful stuff in CMU-CL, I'd never use anything else.

Getting a CL lib working may be a pain, but it is a finite pain. As is 
rolling the FFI for a C lib you might covet. Then you get to use CL for 
the rest of the project, a joy you clearly appreciate.

I think CL is roughly one step backwards and ten steps forward compared 
to any other language. I like those numbers.

> atrociously difficult. This hasn't been the case with any other language 
> or environment I have ever used (C, C++, Fortran-XX, various assemblers,
> Matlab, IDL, Python blah blah).

And life is much easier if you go with the Matrix. As long as you do not 
know what you are missing.

> 
> I find this unfortunate, as the language itself is the tits. Whether or 
> not this difficulty is an effect of the inherent niftiness of the 
> language, it seems that one could do better than this. Python did.

As per the above, Python's only contribution was being a wrapper for C, 
making FFI a tad easier than Lisp FFI. Oh, yeah, and it has only one 
implementation, so any FFI work becomes something anyone can use. But 
the grunt work was done by a multitude of energetic Pythonistas.

All CL needs is energetic, enthusiastic Lispniks. You seem to be one, 
but...well, ask not what Lisp libraries can do for you, ask what you can 
do for Lisp libraries.


-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application
From: Takehiko Abe
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <keke-0301040205180001@solg4.keke.org>
I do not understand why it has to be so hard. A library can be
distributed with a set of source files and a readme file
specifying the order in which those files should be loaded. No?

Why do we need defsystems at all in order to distribute a
library?
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bt4bu5$hup$1@newsreader2.netcologne.de>
Takehiko Abe wrote:

> I do not understand why it has to be so hard. A library can be
> distributed with a set of source files and a readme file
> specifying the order in which those files should be loaded. No?
> 
> Why do we need defsystems at all in order to distribute a
> library?

Read this: http://www.nhplace.com/kent/Papers/Large-Systems.html


All the best,
Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Takehiko Abe
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <keke-0301041312410001@solg4.keke.org>
In article <············@newsreader2.netcologne.de>, 
Pascal Costanza wrote:

> > I do not understand why it has to be so hard. A library can be
> > distributed with a set of source files and a readme file
> > specifying the order in which those files should be loaded. No?
> > 
> > Why do we need defsystems at all in order to distribute a
> > library?
> 
> Read this: http://www.nhplace.com/kent/Papers/Large-Systems.html
> 

I use a defsystem. I think I know its merit. What do you think
I'm missing? [yes I read the paper.]
From: Barry Wilkes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <u13djst3.fsf@acm.org>
····@com.mac (Takehiko Abe) writes:

> In article <············@newsreader2.netcologne.de>, 
> Pascal Costanza wrote:
>
>> > I do not understand why it has to be so hard. A library can be
>> > distributed with a set of source files and a readme file
>> > specifying the order in which those files should be loaded. No?
>> > 
>> > Why do we need defsystems at all in order to distribute a
>> > library?
>> 
>> Read this: http://www.nhplace.com/kent/Papers/Large-Systems.html
>> 
>
> I use a defsystem. I think I know its merit. What do you think
> I'm missing? [yes I read the paper.]

Yes you *can* compile/load a system by just following an order given in a
readme file.  However, it's a very manual process and hence error prone.  In
particular, while you are developing the system it is very likely that you
would make mistakes/forget to reload a file after modifying another one.  You
would need to keep the dependency list in your head.  

What would probably happen is that you would start to use a 'load.lisp' file,
which ensured that all the files were loaded in the correct order.  But this
is no more than a poor man's defsystem.  Other people have produced defsystems
that ensure that files are loaded in the correct order, and in addition, allow
dependencies to be specified which ensure that only those files which
need to be loaded given a set of modifications are loaded.  So, it would seem
to make sense to use a 'proper' defsystem rather than this simple mechanism.
But you could just use a load.lisp rather than a more sophisticated defsystem.

So, now you are using a defsystem (of some kind) to compile/load your code.
It surely makes sense for you to distribute your code using this mechanism.
Otherwise, you are introducing the unnecessary step of translating the
dependency list in your defsystem/load.lisp into your readme,  which leaves
open the possibility of errors.  In particular, the mechanism which you are
suggesting other people use to compile/load your code is different from that
you use yourself.  So it's not as well tested.  

If your system just consists of a single file then no, you don't need a
defsystem.  But for more than that, I suggest in practice you do. 


Barry.
From: Bulent Murtezaoglu
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87isjtqm0l.fsf@cubx.internal>
>>>>> "BW" == Barry Wilkes <·······@acm.org> writes:
[...]
    BW> What would probably happen is that you would start to use a
    BW> 'load.lisp' file, which ensured that all the files were loaded
    BW> in the correct order.  But this is no more than a poor man's
    BW> defsystem.  

Except it does not require that you have a compatible defsystem in your 
image. 

    BW> Other people have produced defsystems that ensure
    BW> that files are loaded in the correct order, and in addition,
    BW> allow dependencies to be specified which ensure that only
    BW> those files which need to be loaded given a set of
    BW> modifications are loaded.  

And compile the midifications as needed etc.  Which is all fine, but 
the users of the package will usually not modify the package itself. 

    BW> So, it would seem to make sense to
    BW> use a 'proper' defsystem rather than this simple mechanism.
    BW> But you could just use a load.lisp rather than a more
    BW> sophisticated defsystem. [...]

Maybe the defsystem of choice for the developer could be run in a 'dry
run' mode to produce compile/load forms to be put in load.lisp to get
independence from the defsystem.  This does not preclude distributing
the defsystem definition with the code, but the user does not need to
get the particular defsystem up and running unless he wants to start
developing the library itself.  This will work in cases where the
defsystem facility is solving the same kind of problem that 'make'
usually does, if it also is solving the problem 'autoconf' does then a
single load.lisp will not fit all, obviously.

cheers,

BM
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bt6f6h$knf$2@newsreader2.netcologne.de>
Bulent Murtezaoglu wrote:

> Maybe the defsystem of choice for the developer could be run in a 'dry
> run' mode to produce compile/load forms to be put in load.lisp to get
> independence from the defsystem.  This does not preclude distributing
> the defsystem definition with the code, but the user does not need to
> get the particular defsystem up and running unless he wants to start
> developing the library itself.

This would indeed be a good idea. Is there a defsystem out there that 
does this?


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Marco Antoniotti
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <XeFJb.234$Nq.53164@typhoon.nyu.edu>
Pascal Costanza wrote:

> 
> Bulent Murtezaoglu wrote:
> 
>> Maybe the defsystem of choice for the developer could be run in a 'dry
>> run' mode to produce compile/load forms to be put in load.lisp to get
>> independence from the defsystem.  This does not preclude distributing
>> the defsystem definition with the code, but the user does not need to
>> get the particular defsystem up and running unless he wants to start
>> developing the library itself.
> 
> 
> This would indeed be a good idea. Is there a defsystem out there that 
> does this?

It is not thaty difficult to do, as long as you are willing to accept a 
dependence on *LOAD-PATHNAME* and do not pretend to evaluate the forms 
in an Emacs buffer.

Apart from that, I have been following (inconsistently) the "provide 
both a system and a `load' file" approach in my code.  The README should 
do the rest.


Cheers

--
Marco
From: Takehiko Abe
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <keke-0301041845170001@solg4.keke.org>
In article <············@acm.org>, Barry Wilkes wrote:

> >> > Why do we need defsystems at all in order to distribute a
> >> > library?
> >> 
> >> Read this: http://www.nhplace.com/kent/Papers/Large-Systems.html
> >> 
> >
> > I use a defsystem. I think I know its merit. What do you think
> > I'm missing? [yes I read the paper.]
> 
> Yes you *can* compile/load a system by just following an order given in a
> readme file.  However, it's a very manual process and hence error prone.

It's tedious but straight-forward. I don't think it is error prone.

> 
> So, now you are using a defsystem (of some kind) to compile/load your code.
> It surely makes sense for you to distribute your code using this mechanism.

No, it does not. Suppose you use defsystem A and the library you want
to install comes with defsystem B, what would you have to do?

> 
> If your system just consists of a single file then no, you don't need a
> defsystem.  But for more than that, I suggest in practice you do. 

Did I mention that I am using a defsystem?
From: Barry Wilkes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ad55ia2f.fsf@acm.org>
····@com.mac (Takehiko Abe) writes:

> In article <············@acm.org>, Barry Wilkes wrote:
>
>> >> > Why do we need defsystems at all in order to distribute a
>> >> > library?
>> >> 
>> >> Read this: http://www.nhplace.com/kent/Papers/Large-Systems.html
>> >> 
>> >
>> > I use a defsystem. I think I know its merit. What do you think
>> > I'm missing? [yes I read the paper.]
>> 
>> Yes you *can* compile/load a system by just following an order given in a
>> readme file.  However, it's a very manual process and hence error prone.
>
> It's tedious but straight-forward. I don't think it is error prone.

That's very nice.  I personally prefer to get the computer to take care of
tedious, yet straightforward tasks for me.  But, that's your choice.  For
larger systems (like CL-HTTP, for example), I don't even think that the
approach of listing dependencies for a human to follow in a readme file is
even tenable.  I think it even goes beyond the 'tedious, yet straightforward.'

>> 
>> So, now you are using a defsystem (of some kind) to compile/load your code.
>> It surely makes sense for you to distribute your code using this mechanism.
>
> No, it does not. Suppose you use defsystem A and the library you want
> to install comes with defsystem B, what would you have to do?

I currently have three defsystems installed in my lisp.  I personally use the
LispWorks one for my work, but I also have MK:DEFSYSTEM and ASDF for
third-party packages I use.  Other systems I have used have come with a file
which is all you need to load to compile/load the package.  I agree that
having three mechanisms is sub-optimal, but I know which I prefer over having
to manually load/compile files based on the contents of some readme file. 

>> 
>> If your system just consists of a single file then no, you don't need a
>> defsystem.  But for more than that, I suggest in practice you do. 
>
> Did I mention that I am using a defsystem?

So, what you seem to be saying is that other people should use a different
system for compiling your files than the one you use.  I suggest this is error
prone.  Further, I suggest this becomes more error prone as the systems
concerned get bigger.

Barry.

 
From: Takehiko Abe
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <keke-0301042151220001@solg4.keke.org>
In article <············@acm.org>, Barry Wilkes wrote:

> I currently have three defsystems installed in my lisp.  I personally use the
> LispWorks one for my work, but I also have MK:DEFSYSTEM and ASDF for
> third-party packages I use.

I think you are proving the claim that installing a CL library
is hard for novice CL users. If one needs three different defsystem
to install a package...

> > Did I mention that I am using a defsystem?
> 
> So, what you seem to be saying is that other people should use a different
> system for compiling your files than the one you use.

I did not and would not say other people should use "a different system".

> I suggest this is error prone.

I disagree. How come a program is dependent on a particular defsystem
to be error free?
From: Barry Wilkes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <65fti2qq.fsf@acm.org>
····@com.mac (Takehiko Abe) writes:

> In article <············@acm.org>, Barry Wilkes wrote:
>
>> I currently have three defsystems installed in my lisp.  I personally use the
>> LispWorks one for my work, but I also have MK:DEFSYSTEM and ASDF for
>> third-party packages I use.
>
> I think you are proving the claim that installing a CL library
> is hard for novice CL users. If one needs three different defsystem
> to install a package...
>
I agree with you.  Installing a CL library (unless, I am told, one is using
SBCL on Debian) is not paticularly easy for novice CL users.  However, the
alternative you propose -- getting them to compile and load a
series of files manually -- is also not easy for novice CL users.  You also
managed to completly fail to answer my point, which was what you suggest
people who are distributing large, complex systems should do, if not use a
defsystem, or 'load.lisp' solution.  Your original suggestion, that the manual
instructions be distributed in a readme file is unworkable for large systems.
Really, it is.  Perhaps you just haven't worked on large projects in any
language.  Oh well.  If and when you do, you will see what I mean. 

Oh, and I have never needed more than a single defsystem to install a single
package.  I'm not sure anyone would do something as stupid as that.  If you
have an example to prove me wrong, please enlighten me.

I'm actually not sure what the answer is, beyond everyone using the same lisp
system and the same defsystem on the same OS, in terms of making large systems
easy for newcomers to CL to install and use.  But then, we shouldn't lose
sight of the fact that most large systems in other languages need some level
of configuration before they can be used.  In paticular, what seems to pass
for easy to configure and use usually means easy to configure and use under
Linux with gcc, i.e. a single OS and a single compiler.

>> > Did I mention that I am using a defsystem?
>> 
>> So, what you seem to be saying is that other people should use a different
>> system for compiling your files than the one you use.
>
> I did not and would not say other people should use "a different system".
>
>> I suggest this is error prone.
>
> I disagree. How come a program is dependent on a particular defsystem
> to be error free?

I'm not sure I understand what you mean here.  But, whatever.  Carry on doing
whatever it is you do.  It seems to make you happy.  Great.  I'll leave you to
get on with it.

Barry.
From: Takehiko Abe
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <keke-0401041454190001@solg4.keke.org>
In article <············@acm.org>, Barry Wilkes wrote:

> > I think you are proving the claim that installing a CL library
> > is hard for novice CL users. If one needs three different defsystem
> > to install a package...
> >
> I agree with you.  

uhm. you are not agreeing with me.

> Installing a CL library (unless, I am told, one is using
> SBCL on Debian) is not paticularly easy for novice CL users. 

My position is that it should not be hard.

> However, the
> alternative you propose -- getting them to compile and load a
> series of files manually -- is also not easy for novice CL users.

I do not agree.

> You also
> managed to completly fail to answer my point, which was what you suggest
> people who are distributing large, complex systems should do,

I did not have in my mind "large, complex systems". If one is
distributing a large complex system, I think it is fine for him to
require its own defsystem for installation. However, I do not think
most libraries are that large to warrant that.

And I do not believe novice CL users would try installing such
a large complex system *and* give it up because it is too hard.


> if not use a
> defsystem, or 'load.lisp' solution.  Your original suggestion, that the manual
> instructions be distributed in a readme file is unworkable for large systems.
> Really, it is.  Perhaps you just haven't worked on large projects in any
> language.  Oh well.  If and when you do, you will see what I mean. 

Perhaps you are mixing up maintaining a large program and distributing
a library. 

> 
> Oh, and I have never needed more than a single defsystem to install a single
> package.

But you use three different defsystems to maintain your program,
right? Sounds like an amazing feat to me.


> I'm not sure anyone would do something as stupid as that.  If you
> have an example to prove me wrong, please enlighten me.
> 
> I'm actually not sure what the answer is, beyond everyone using the same lisp
> system and the same defsystem on the same OS, in terms of making large systems
> easy for newcomers to CL to install and use.

Please drop the "large systems" and substitute it with "libraries".
From: Christopher C. Stacy
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <uznd4w636.fsf@news.dtpq.com>
>>>>> On Sun, 04 Jan 2004 14:54:19 +0900, Takehiko Abe ("Takehiko") writes:
 Takehiko> In article <············@acm.org>, Barry Wilkes wrote:
 >> I agree with you.  

 Takehiko> uhm. you are not agreeing with me.

 Takehiko> My position is that it should not be hard.

 >> However, the alternative you propose -- getting them to
 >> compile and load a series of files manually -- is also
 >> not easy for novice CL users.

 Takehiko> I do not agree.

I don't know if I agree or not, because I can't quite figure
out what either of you are trying to say here.

It's certainly true that you could give people a tarball with a
README that says, "Start Lisp and load the following files in order",
and that it would be simple.

Of course, there's no reason to ever do that, since the directions
could just as well say, "Start your Lisp and type (LOAD "loader")." 
However, I'm sure most people can handle a little more than 
that for installing the developer's favorite DEFSYSTEM.

Is any of that really an issue?

 >> You also managed to completly fail to answer my point,
 >> which was what you suggest people who are distributing
 >> large, complex systems should do,

 Takehiko> I did not have in my mind "large, complex systems". If one is
 Takehiko> distributing a large complex system, I think it is fine for him to
 Takehiko> require its own defsystem for installation. However, I do not think
 Takehiko> most libraries are that large to warrant that.

 Takehiko> And I do not believe novice CL users would try installing such
 Takehiko> a large complex system *and* give it up because it is too hard.

Users (novices or not) do not know or care which libraries are "complex",
and I think people are just throwing that word around in the discussion
to make things sound scary.  It's lke they're trying to make running 
FTP sound like its NP Complete or something.  Very, very weird!

All we're really talking about here are systems which _might_ require 
other systems to be loaded first, with no circular dependancies.
Where I come from, we call that kind of dependancy "trivial" or
"sequential", regardless of how big or "fancy" or "complex" each 
of the component libraries is.

My original suggestion was simply that libraries ought to be distributed
as download bundles -- that is, the library comes as a tar or zip file.
It should have a README and INSTALL file, and explain where to download
its favoite DEFSYSTEM from.  That's how all C programs I've ever downloaded
come packaged: foo.tar.gz, configure, Makefile, happy hacking.

Some Lisp libraries already have that distribution model, and some don't.

My second suggestion was that this could be automated a little bit,
and wouldn't that be nice.

I am utterly baffled that a system consisting of a library registry, 
a simple description of dependancies for each library, an automated
file-fetcher, and some trivial bootload scripts, would be labeled "complex".

Some of the explanations in the objections given seem to form an even
odder chain of reasoning that somehow because Lisp is more powerful
than Perl, it is ultimately much harder to solve the same problem.

I just can't figure out what those flamers are smoking!

 Takehiko> Perhaps you are mixing up maintaining a large program and
 Takehiko> distributing a library.

I do suspect that some people are conflating the problem of writing
portable libraries with the problem of distributing the libraries.

I am only talking about libraries that have already been written to
run on whatever (presumably multiple) implementations are of interest
to the given user.  The library registry information would indicate
to the user and/or the installation program which platforms it's
available on, and that could be chased down the library dependancy list
to see if you're going to be able to win on your particular platform.

 Takehiko> But you use three different defsystems to maintain your
 Takehiko> program, right? Sounds like an amazing feat to me.

Amazing? I can't agree with that.
Isn't that exactly what everyone does?  

I use Xanalys Lispworks, so I have their native DEFSYSTEM, 
and of course I have MK:DEFSYSTEM and ASDF.  Different third-party
libraries want to use different defsystems, but there's nothing complex
about that.  Trivial loader scripts bring in what's necessary to bootstrap
the application.  My applications (all which include my own libraries,
and some of which include things like CL-SQL and UFFI) run on at least
two different operating systems and Lisp implementations.  
And there's nothing complex about any of that.

What users find complex and daunting is experiences like trying to
download some simple library -- which probably implements something
they expected to find basically built into the language in the first
place -- and being confronted with CVS.

What users love is to have their ass wiped for them, like CPAN does,
and it's ridiculous to suggest that Lisp could not do something similar.

However, I never asked anyone to provide that, various comp.random.crap
hostility to the contrary.  In fact, I went out of my way to say that
nobody was obligated to do anything of the sort.  I merely advised that
there was a frustrated market for it, and hinted that it might be a
little embarassing that Perl had it, in case anyone was interested.

One useful thing I learned is that, if I understood correctly,
it sounded like maybe SBCL already has all that.

I just can't believe most of the responses, and probably mainly 
what I should have learned is not to post on this newsgroup.
From: Barry Wilkes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ad5488kv.fsf@acm.org>
······@news.dtpq.com (Christopher C. Stacy) writes:

> Users (novices or not) do not know or care which libraries are "complex",
> and I think people are just throwing that word around in the discussion
> to make things sound scary.  It's lke they're trying to make running 
> FTP sound like its NP Complete or something.  Very, very weird!

I'm sorry.  I thought I was answering someones message saying that it was a
good idea to list dependencies in a readme rather than just use a defsystem.
Thinking that this was a serious suggestion, I then made the mistake of saying
why I thought this was a bad idea.    

>
> I just can't believe most of the responses, and probably mainly 
> what I should have learned is not to post on this newsgroup.

You'll get absolutly no argument from me on that score.  I've certainly learnt
my lesson.

Barry.
From: Marc Battyani
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bt8uef$5l5@library2.airnews.net>
"Christopher C. Stacy" <······@news.dtpq.com> wrote

> What users find complex and daunting is experiences like trying to
> download some simple library -- which probably implements something
> they expected to find basically built into the language in the first
> place -- and being confronted with CVS.

I also found that CVS checkout was a pain on Windows. But now that I use
TortoiseCVS (http://www.tortoisecvs.org), and the even better TortoiseSVN
(http://tortoisesvn.tigris.org)
for Subversion repositories, the pain has gone. ;-)

Marc
From: Marco Antoniotti
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <MIZJb.253$Nq.53785@typhoon.nyu.edu>
Marc Battyani wrote:

> "Christopher C. Stacy" <······@news.dtpq.com> wrote
> 
> 
>>What users find complex and daunting is experiences like trying to
>>download some simple library -- which probably implements something
>>they expected to find basically built into the language in the first
>>place -- and being confronted with CVS.
> 
> 
> I also found that CVS checkout was a pain on Windows. But now that I use
> TortoiseCVS (http://www.tortoisecvs.org), and the even better TortoiseSVN
> (http://tortoisesvn.tigris.org)
> for Subversion repositories, the pain has gone. ;-)

Agreed.  sub-version is not as nice as PRCS, but is it a vast 
improvement over CVS.

Cheers
--
Marco
From: Rahul Jain
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ad53l9q9.fsf@nyct.net>
······@news.dtpq.com (Christopher C. Stacy) writes:

> I am utterly baffled that a system consisting of a library registry, 
> a simple description of dependancies for each library, an automated
> file-fetcher, and some trivial bootload scripts, would be labeled "complex".

I wouldn't call it complex. I was involved in the design of such a
system. Of course, half of it was already done for us. You're free to
rewrite that half to match your desires.

> Some of the explanations in the objections given seem to form an even
> odder chain of reasoning that somehow because Lisp is more powerful
> than Perl, it is ultimately much harder to solve the same problem.

No one said that. It's because Lisp is more *standardized* that it has
more implementations, and *this* aspect of using Lisp is not
standardized.

> I do suspect that some people are conflating the problem of writing
> portable libraries with the problem of distributing the libraries.

Distributing those libraries involves a portable library to do that.

> I am only talking about libraries that have already been written to
> run on whatever (presumably multiple) implementations are of interest
> to the given user.  The library registry information would indicate
> to the user and/or the installation program which platforms it's
> available on, and that could be chased down the library dependancy list
> to see if you're going to be able to win on your particular platform.

You've just described the system that I use every day. That some people
choose to not write such a system for the tools that they use (or for
the tools that they write) is a problem for THOSE people, not for the
library writers who don't use those other tools.

> I just can't believe most of the responses, and probably mainly 
> what I should have learned is not to post on this newsgroup.

If what you're posting is a flame to people who have volunteered their
time to create the same system that you're describing, but your gripe is
that you don't want to use that system, yes, you shouldn't post that
message.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Lupo LeBoucher
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <k62dna79GJhIeGCiRVn-jw@io.com>
In article <·············@news.dtpq.com>,
Christopher C. Stacy <······@news.dtpq.com> wrote:
>>>>>> On Sun, 04 Jan 2004 14:54:19 +0900, Takehiko Abe ("Takehiko") writes:
> Takehiko> In article <············@acm.org>, Barry Wilkes wrote:
> >> I agree with you.  
>
> Takehiko> uhm. you are not agreeing with me.
>
> Takehiko> My position is that it should not be hard.
>
> >> However, the alternative you propose -- getting them to
> >> compile and load a series of files manually -- is also
> >> not easy for novice CL users.
>
> Takehiko> I do not agree.
>
>I don't know if I agree or not, because I can't quite figure
>out what either of you are trying to say here.

I think Takehiko is trying to say what you and I are saying: it should be 
really freakin easy to download a library and compile it up and use the 
thing without having a five-bladed lisp propellor surgically attached to 
your cranium.

The other guy (and various others in posession of the five-bladed Lisp 
propellor surgically attached to their craniums) seems to be saying that 
you can't use something like 'make' because Lisp is too complicated.

Personally, I don't give a shit if it is called 'make' or 'defsystem' -but 
it should be effectively as simple as 'make' to use. Especially on a Unix 
system, since everything is effectively Unix as far as interesting 
platforms that free (or otherwise) Lisps run on.

>Some of the explanations in the objections given seem to form an even
>odder chain of reasoning that somehow because Lisp is more powerful
>than Perl, it is ultimately much harder to solve the same problem.
>
>I just can't figure out what those flamers are smoking!

Using libraries in Lisp reminds me of changing directories in CDC's NOS 
or Cyber or whatever they used to call it. No I can't remember the 
command; %crec something. There's just no reason for it to be that obscure.

And, shit, if Lisp is so damned good, writing a CPAN thing that works 
should take, like, 1/2 hour or something. Not that I particularly like 
CPAN or anything. I'd be happy with something pythonesque like:

import glob, os, sys, re, rpc
 
>What users find complex and daunting is experiences like trying to
>download some simple library -- which probably implements something
>they expected to find basically built into the language in the first
>place -- and being confronted with CVS.

I've never had a problem using CVS. The problem is downloading a simple 
(or less than simple) library and ... you don't get anything you can use. 
For example, I want to use something like CLIM, but I can't even build any 
of the X-packages.

Or something that hasn't actually run on anything in a decade.
For examples:

"Scigraph requires Common Lisp and has been tested on Symbolics, Allegro,
and Lucid Lisp environments under Dynamic Windows and CLIM (version 0.9
or later).  Graphs may be displayed on either color or monochrome 
screens."

;
;  For the record, the functions in the SAPA package have been tested
;  successfully in the following versions of Common Lisp:
;   [a]  Macintosh Common Lisp 2.0p2
;   [b]  Symbolics Genera 8.1.1 on a Symbolics MacIvory model 3
;   [c]  Allegro Common Lisp running under SunOS Release 4.1.2
;
;

Or, platforms CL-PVM works on:
HPPA  SGI  SUN4

Or, xlispstat:
aix    cray        encore  generic  ibmrt_bsd  linux  README   sunos3  vax
alpha  decstation  epix    hpux     irix       pmax   solaris  sunos4

Now, most of this crap, I am sure I could make work if it was C/Fortran
with makefiles. Lisp, I don't even know where to start.

>What users love is to have their ass wiped for them, like CPAN does,
>and it's ridiculous to suggest that Lisp could not do something similar.

I don't think it is ridiculous to suggest this, really. Especially in 
cases where, as you say, some of the functionality we're looking for (web 
stuff, GUI libraries, parallel tools) should be built into the language in 
the first place.

Yeah, I am a whiney newbie with a "sense of entitlement." My sense of 
entitlement comes from having used good and free software for the last 
decade or so which was not so damned hard to use. 

It's an appliance, dammit. A tool. The problem is, the tool requires hours 
of assembly and comes without anything resembling directions. Oh well; 
at least I have some cool command line stuff.

-Lupo
"If there's one word that sums up everything that's gone wrong since the 
War, it's workshop."-Kingsley Amis                             <··@io.com>
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <btkra3$kua$1@newsreader2.netcologne.de>
Lupo LeBoucher wrote:

> Now, most of this crap, I am sure I could make work if it was C/Fortran
> with makefiles. Lisp, I don't even know where to start.

"This crap" works because there is a sufficiently large number of people 
who care to port software written in C/Fortran to the platform you 
apparently use. Switch to a different platform, and things start to look 
less rosy. For example, it happens every now and then that on Mac OS X, 
configure doesn't know about the platform it's running on. Yes, for 
software written in C.

The important factor is the number of people that care about a language 
+ language implementation + software + platform. These things don't fall 
from the sky but require actual work. Flaming the people who port the 
software is not especially constructive.


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Lupo LeBoucher
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <-ridnZdxgvr04Jnd4p2dnA@io.com>
In article <············@newsreader2.netcologne.de>,
Pascal Costanza  <········@web.de> wrote:
>
>
>Lupo LeBoucher wrote:
>
>> Now, most of this crap, I am sure I could make work if it was C/Fortran
>> with makefiles. Lisp, I don't even know where to start.
>
>"This crap" works because there is a sufficiently large number of people 
>who care to port software written in C/Fortran to the platform you 
>apparently use. Switch to a different platform, and things start to look 
>less rosy. For example, it happens every now and then that on Mac OS X, 
>configure doesn't know about the platform it's running on. Yes, for 
>software written in C.

I won't debate that point.
I was going to ask you what you use for your (free or otherwise) Lisp 
platform, but then I remembered you have put this on a webpage somewhere.

>The important factor is the number of people that care about a language 
>+ language implementation + software + platform. These things don't fall 
>from the sky but require actual work. Flaming the people who port the 
>software is not especially constructive.

Honestly, I am not trying to flame anybody. I don't think any of us scrubs 
have this intention. If it weren't for you guys, I'd probably be trying to 
write code in Java, and that would suck monkey butts.

It's more like, "hey, lookie here -this (lack of nice development 
suites, lack of easily made code, lack of documentation, or whatever) is a 
general problem."

The standard response seems to be something along the lines of "how dare 
you question your betters" or "fix it yourself or write your own if you 
are not happy, and shut your cake hole, you ingrate." I suppose Lispers 
take a lot of shit from other 'modern' software guys, so the sociology 
might loan itself to prickly elititude.

Anyway, I will now go back to figuring out the differences between require 
and load, and defsystem and asdf.

-Lupo
"Your eyes drop millstones, when fools' eyes drop tears" -Richard III
                       <··@fnord.io.com>
From: Edi Weitz
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m3eku32z35.fsf@bird.agharta.de>
On Tue, 13 Jan 2004 17:21:13 -0600, ··@io.com (Lupo LeBoucher) wrote:

> Anyway, I will now go back to figuring out the differences between
> require and load, and defsystem and asdf.

Take a look at this one:

  <http://weitz.de/asdf-install/>

I'd be interested in hearing your comments.

Edi.
From: Marco Antoniotti
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <XXALb.314$Nq.76174@typhoon.nyu.edu>
Lupo LeBoucher wrote:
> In article <·············@news.dtpq.com>,
> Christopher C. Stacy <······@news.dtpq.com> wrote:
> 
>>>>>>>On Sun, 04 Jan 2004 14:54:19 +0900, Takehiko Abe ("Takehiko") writes:
>>
>>Takehiko> In article <············@acm.org>, Barry Wilkes wrote:
>>
>>>>I agree with you.  
>>
>>Takehiko> uhm. you are not agreeing with me.
>>
>>Takehiko> My position is that it should not be hard.
>>
>>
>>>>However, the alternative you propose -- getting them to
>>>>compile and load a series of files manually -- is also
>>>>not easy for novice CL users.
>>
>>Takehiko> I do not agree.
>>
>>I don't know if I agree or not, because I can't quite figure
>>out what either of you are trying to say here.
> 
> 
> I think Takehiko is trying to say what you and I are saying: it should be 
> really freakin easy to download a library and compile it up and use the 
> thing without having a five-bladed lisp propellor surgically attached to 
> your cranium.

Agreed


> 
> The other guy (and various others in posession of the five-bladed Lisp 
> propellor surgically attached to their craniums) seems to be saying that 
> you can't use something like 'make' because Lisp is too complicated.
> 
> Personally, I don't give a shit if it is called 'make' or 'defsystem' -but 
> it should be effectively as simple as 'make' to use. Especially on a Unix 
> system, since everything is effectively Unix as far as interesting 
> platforms that free (or otherwise) Lisps run on.

Most libraries come like this:  a bunch of files and a library.system or 
a library.asdf file or both.  Compiling and loading is usually a matter 
of doing something like

cl-prompt> (mk:compile-system "library")
or
cl-prompt> (asdf:compile-system "library")

What is difficult with this approach I do not know.

>>Some of the explanations in the objections given seem to form an even
>>odder chain of reasoning that somehow because Lisp is more powerful
>>than Perl, it is ultimately much harder to solve the same problem.
>>
>>I just can't figure out what those flamers are smoking!
> 
> 
> Using libraries in Lisp reminds me of changing directories in CDC's NOS 
> or Cyber or whatever they used to call it. No I can't remember the 
> command; %crec something. There's just no reason for it to be that obscure.
> 
> And, shit, if Lisp is so damned good, writing a CPAN thing that works 
> should take, like, 1/2 hour or something. Not that I particularly like 
> CPAN or anything. I'd be happy with something pythonesque like:
> 
> import glob, os, sys, re, rpc

No.  It is not that easy because

1 - the system should be Common Lisp centric, not UNIX centric (I *am*
     wearing my asbetos underwear :) )
2 - Common Lisp is *not* a single implementation language.
3 - Unfortunately, because of 2 we do not have some infrastructure that
     is taken for granted in single implementation languages.


> 
>>What users find complex and daunting is experiences like trying to
>>download some simple library -- which probably implements something
>>they expected to find basically built into the language in the first
>>place -- and being confronted with CVS.
> 
> 
> I've never had a problem using CVS. The problem is downloading a simple 
> (or less than simple) library and ... you don't get anything you can use. 
> For example, I want to use something like CLIM, but I can't even build any 
> of the X-packages.
> 
> Or something that hasn't actually run on anything in a decade.
> For examples:
> 
> "Scigraph requires Common Lisp and has been tested on Symbolics, Allegro,
> and Lucid Lisp environments under Dynamic Windows and CLIM (version 0.9
> or later).  Graphs may be displayed on either color or monochrome 
> screens."

It's called free software.  Now, the case of Scigraph is somewhat "bad" 
as it it is tied to the single worst catastrophe of the "Common Lisp 
Community": i.e. CLIM.  Anyhting that depends on CLIM is inherently 
pathological in the current state of affairs.  The truth is that the 
CLIM implementation is incredibly difficult to get right if you do not 
have a bunch of programmers completely devoted to it (as the heroic and 
saintly FreeCLIM people know - are presentation types finally working?)

> ;
> ;  For the record, the functions in the SAPA package have been tested
> ;  successfully in the following versions of Common Lisp:
> ;   [a]  Macintosh Common Lisp 2.0p2
> ;   [b]  Symbolics Genera 8.1.1 on a Symbolics MacIvory model 3
> ;   [c]  Allegro Common Lisp running under SunOS Release 4.1.2
> ;
> ;
> 
> Or, platforms CL-PVM works on:
> HPPA  SGI  SUN4
> 
> Or, xlispstat:
> aix    cray        encore  generic  ibmrt_bsd  linux  README   sunos3  vax
> alpha  decstation  epix    hpux     irix       pmax   solaris  sunos4
> 
> Now, most of this crap, I am sure I could make work if it was C/Fortran
> with makefiles. Lisp, I don't even know where to start.

So basically you are complaining that for a period of time people went 
out to do (in order) Perl, C++, Java, Ruby, Javascript, Visual Basic and 
Python instead of doing Common Lisp.  We all agree on that :)  I am as 
sorry as you are because of this.  So many wasted energies.

>>What users love is to have their ass wiped for them, like CPAN does,
>>and it's ridiculous to suggest that Lisp could not do something similar.
> 
> 
> I don't think it is ridiculous to suggest this, really. Especially in 
> cases where, as you say, some of the functionality we're looking for (web 
> stuff, GUI libraries, parallel tools) should be built into the language in 
> the first place.
> 
> Yeah, I am a whiney newbie with a "sense of entitlement." My sense of 
> entitlement comes from having used good and free software for the last 
> decade or so which was not so damned hard to use. 
> 
> It's an appliance, dammit. A tool. The problem is, the tool requires hours 
> of assembly and comes without anything resembling directions. Oh well; 
> at least I have some cool command line stuff.

Nobody is asking you to use it.  Youi use it only if you can get 
anything useful out of it.  I am just pointing out what is the state of 
affairs.  Not that I like it, but that is the way things are.  So, 
instead of whining because you do not have a little yellow window 
popping up to show you what are the possible methods of your Java class, 
just think that there are many of us (me at least) who get fits of anger 
whenever I figure out that there is *no* way to compile and run 
something that is not built under the latest IDE X because all the 
stupid XML project files are unintelligible by what IDE Y (which is what 
I use.)  Sorry, but the world is a little more that 'configure; make; 
make install' and a little less that Microsoft VC++ or NetIDE.

Cheers
--
Marco
From: Will Hartung
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <btmr4j$92neu$1@ID-197644.news.uni-berlin.de>
"Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
·······················@typhoon.nyu.edu...

> No.  It is not that easy because
>
> 1 - the system should be Common Lisp centric, not UNIX centric (I *am*
>      wearing my asbetos underwear :) )
> 2 - Common Lisp is *not* a single implementation language.
> 3 - Unfortunately, because of 2 we do not have some infrastructure that
>      is taken for granted in single implementation languages.

No, CL is not a single implementation language, the C part of CL is pretty
well entrenched. Also, I believe every major distribution (CMUCL, SBCL,
CLisp, ACL, LW, MCL, OpenMCL, Corman...dunno about GCL. Any others?) have
the basic extensions necessary to create a more automated central repository
ala CPAN et al. Specifically some kind of Socket implementation, the ability
to read a local directory, and a modicum of Logical Path support in the
implementation.

From this, a portable, pure CL system can arise. While the specific packages
themselves may not be completely portable, there isn't any real reason why
the package and dependency manager can not be.

I completely agree with #1. I see no reason why there should be any
dependencies at all on local tools.

An appropriate example is the build sytem for Jaffers SCM, in which while he
supplies a rudimentary Makefile, he doesn't really support it relying on a
Scheme based system instead.

Ideally, IMHO, the requirements for installing this module system should be
downloading "bootstrap.lisp" and typing (load "bootstrap.list") (bootstrap)
in the listener of any supported CL implementation. From there it can figure
things out, prompt for configuration, etc.

If it's more difficult then that, then there are Issues.

Regards,

Will Hartung
(·····@msoft.com)
From: Marco Antoniotti
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <7sDLb.327$Nq.76376@typhoon.nyu.edu>
Will Hartung wrote:

> "Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
> ·······················@typhoon.nyu.edu...
> 
> 
>>No.  It is not that easy because
>>
>>1 - the system should be Common Lisp centric, not UNIX centric (I *am*
>>     wearing my asbetos underwear :) )
>>2 - Common Lisp is *not* a single implementation language.
>>3 - Unfortunately, because of 2 we do not have some infrastructure that
>>     is taken for granted in single implementation languages.
> 
> 
> No, CL is not a single implementation language, the C part of CL is pretty
> well entrenched. Also, I believe every major distribution (CMUCL, SBCL,
> CLisp, ACL, LW, MCL, OpenMCL, Corman...dunno about GCL. Any others?) have
> the basic extensions necessary to create a more automated central repository
> ala CPAN et al. Specifically some kind of Socket implementation, the ability
> to read a local directory, and a modicum of Logical Path support in the
> implementation.

Yes, that is there.  And there are packages which address (more or less 
nicely) all these problems.  Let me put in my shameless plug for 
CL-ENVIRONMENT and CL-CONFIGURATION here :)

> 
> From this, a portable, pure CL system can arise. While the specific packages
> themselves may not be completely portable, there isn't any real reason why
> the package and dependency manager can not be.

Sounds like a good endevour to me.

> 
> I completely agree with #1. I see no reason why there should be any
> dependencies at all on local tools.

I would not use anything less than #1.  That is why I have not much 
attention for requests of UNIX/Linux specific tools.  Any tool we are 
talking about should have a README that always starts with "Unpack your 
system in any directory you want and start your favourite CL 
implementation....".  As you can see I am willing to accept the 
"Unpack...", which I am sure, sombody will say not being a very well 
defined concept on platform/filesystem X.

> 
> An appropriate example is the build sytem for Jaffers SCM, in which while he
> supplies a rudimentary Makefile, he doesn't really support it relying on a
> Scheme based system instead.
> 
> Ideally, IMHO, the requirements for installing this module system should be
> downloading "bootstrap.lisp" and typing (load "bootstrap.list") (bootstrap)
> in the listener of any supported CL implementation. From there it can figure
> things out, prompt for configuration, etc.
> 
> If it's more difficult then that, then there are Issues.

I do not know Jaffers SCM, but what I try to do - YAMMMV - is always to 
provide a "load-xxx.lisp" file for these basic tools.  CL-ENVIRONMENT, 
CL-CONFIGURATION and MK4 all come with it.  I recognize the fact that 
these tools are the bottoming out of the recursion tower. :)

But, yes!  I still think there are a number of difficulties.  The lack 
of a standardized networking facility makes things complicated.  I have 
no doubt about that.

Cheers
--
Marco
From: Raymond Toy
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <4nvfnkkarx.fsf@edgedsp4.rtp.ericsson.se>
>>>>> "Will" == Will Hartung <·····@msoft.com> writes:


    Will> Ideally, IMHO, the requirements for installing this module system should be
    Will> downloading "bootstrap.lisp" and typing (load "bootstrap.list") (bootstrap)
    Will> in the listener of any supported CL implementation. From there it can figure
    Will> things out, prompt for configuration, etc.

I think asdf-install works pretty well for this.  Grab asdf.lisp and
asdf-install.lisp.  Load them in your lisp, and you can now download
and install various packages.

I think it only requires some simple socket interface so it can talk
http to cliki.net.

Ray, who doesn't use asdf-install very much at all.
From: Robert STRANDH
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <6weku9q7vz.fsf@serveur4.labri.fr>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> ... the single worst catastrophe of the "Common
> Lisp Community": i.e. CLIM.  Anyhting that depends on CLIM is
> inherently pathological in the current state of affairs.  

I am interested in knowing more about why you think so. 

> The truth is
> that the CLIM implementation is incredibly difficult to get right if
> you do not have a bunch of programmers completely devoted to it (as
> the heroic and saintly FreeCLIM people know 

It is difficult, partly because the specification is sometimes vague
and sometimes self-contradictory.  But I am very impressed by the work
of the people who wrote it anyway, since it is a very complex piece of
software.

> - are presentation types finally working?)

I do not know whether all aspects of presentation types work according
to the specification, but I have used McCLIM presentation types in
several applications for the past year or so with no major surprises. 

-- 
Robert Strandh
From: Marco Antoniotti
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <GiDLb.324$Nq.76763@typhoon.nyu.edu>
Robert STRANDH wrote:

> Marco Antoniotti <·······@cs.nyu.edu> writes:
> 
> 
>>... the single worst catastrophe of the "Common
>>Lisp Community": i.e. CLIM.  Anyhting that depends on CLIM is
>>inherently pathological in the current state of affairs.  
> 
> 
> I am interested in knowing more about why you think so. 

Because I cannot get Scigraph to work on LW CLIM even after what seemed 
to me something "obvious" to do (meaning: clean the load file etc etc)?

> 
> 
>>The truth is
>>that the CLIM implementation is incredibly difficult to get right if
>>you do not have a bunch of programmers completely devoted to it (as
>>the heroic and saintly FreeCLIM people know 
> 
> 
> It is difficult, partly because the specification is sometimes vague
> and sometimes self-contradictory.  But I am very impressed by the work
> of the people who wrote it anyway, since it is a very complex piece of
> software.

I am impressed myself.  Yet it is a complicated thing to set up wil a 
lot of functionality that should have been packaged otherwise (e.g. all 
the command processor stuff) and stuff -- presentation types -- that is 
extremely difficult to implement on ANSI CL.

> 
> 
>>- are presentation types finally working?)
> 
> 
> I do not know whether all aspects of presentation types work according
> to the specification, but I have used McCLIM presentation types in
> several applications for the past year or so with no major surprises. 
> 

That is good news.  It means that the first time FreeCLIM has had 
working presentation types was late 2002.


Cheers
--
Marco
From: Raymond Toy
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <4nzncwkaw0.fsf@edgedsp4.rtp.ericsson.se>
>>>>> "Marco" == Marco Antoniotti <·······@cs.nyu.edu> writes:

    Marco> Robert STRANDH wrote:

    >> Marco Antoniotti <·······@cs.nyu.edu> writes:
    >> 
    >>> ... the single worst catastrophe of the "Common
    >>> Lisp Community": i.e. CLIM.  Anyhting that depends on CLIM is
    >>> inherently pathological in the current state of affairs.
    >> I am interested in knowing more about why you think so.

    Marco> Because I cannot get Scigraph to work on LW CLIM even after what
    Marco> seemed to me something "obvious" to do (meaning: clean the load file
    Marco> etc etc)?

Interesting.  I got Scigraph to work (sort of) on cmucl, with a few
changes to the files.  Mostly commenting out the values declarations,
and a few system-specific things.

I only ran the demos, which sort of worked.  Clicking on the graphs to
edit them didn't work, though.  No applicable method or something like
that.

Ray
From: Paolo Amoroso
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87isjkj0qe.fsf@plato.moon.paoloamoroso.it>
Marco Antoniotti writes:

> Because I cannot get Scigraph to work on LW CLIM even after what
> seemed to me something "obvious" to do (meaning: clean the load file
> etc etc)?

The Scigraph code was imported only recently, I seem to remember less
than a couple of months ago, into the McCLIM CVS tree, with the
intention of making it work again. But resources are limited.


> I am impressed myself.  Yet it is a complicated thing to set up wil a
> lot of functionality that should have been packaged otherwise

CLIM may not be perfect, but it is definitely usable. Even McCLIM, in
its current state, can do a lot. Have you checked GSharp or a recent
version of Closure?


> (e.g. all the command processor stuff) and stuff -- presentation types
> -- that is extremely difficult to implement on ANSI CL.

McCLIM runs at least on ACL, CMUCL, OpenMCL and SBCL.


> That is good news.  It means that the first time FreeCLIM has had
> working presentation types was late 2002.

Marco: the fact that you still call it FreeCLIM (note the absence of a
space between the words) strongly suggest that you have not been
keeping in touch with the project for a loooong time :)

For the record, it is now called McCLIM. Its current level of
compliance to the CLIM 2 specification is summarized at:

  http://mcclim.cliki.net/Compliance

Be sure to check the other pages at:

  http://mcclim.cliki.net


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Marco Antoniotti
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <fqGLb.333$Nq.76920@typhoon.nyu.edu>
Paolo Amoroso wrote:
> Marco Antoniotti writes:
> 
> 
>>Because I cannot get Scigraph to work on LW CLIM even after what
>>seemed to me something "obvious" to do (meaning: clean the load file
>>etc etc)?
> 
> 
> The Scigraph code was imported only recently, I seem to remember less
> than a couple of months ago, into the McCLIM CVS tree, with the
> intention of making it work again. But resources are limited.

I said LW CLIM.  Not McCLIM (name corrected :) )  And I have got close 
to make it work on LW CLIM, but not quite completely.

....
>>That is good news.  It means that the first time FreeCLIM has had
>>working presentation types was late 2002.
> 
> 
> Marco: the fact that you still call it FreeCLIM (note the absence of a
> space between the words) strongly suggest that you have not been
> keeping in touch with the project for a loooong time :)
> 

It is true that i do not use McCLIM.  But that was not my point.  My 
point is that the CLIM spec requires *a lot* of work (probably even more 
than that) to get right.  The implementors of FreeCLIM/McCLIM know that 
very well.  With the power of hindsight, had the SILICA implementation 
ended up in the public domain, all of us Lispers would be better off.

Having said that I welcome any progress in the CLIM arena.

Cheers
--
Marco
From: Paolo Amoroso
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87brpcgkgu.fsf@plato.moon.paoloamoroso.it>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> I said LW CLIM.  Not McCLIM (name corrected :) )  And I have got close
> to make it work on LW CLIM, but not quite completely.

I know, but my point was different :) Scigraph is an old application,
and making it work on a modern Lisp system is very likely to take
time. Hence I mentioned the case of McCLIM: the only work that has
been done so far for Scigraph, I guess because of lack of resources,
is to include it in the CVS repository.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Timothy Moore
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <wdrk73xjy73.fsf@trousse.labri.fr>
Paolo Amoroso <·······@mclink.it> writes:

> I know, but my point was different :) Scigraph is an old application,
> and making it work on a modern Lisp system is very likely to take
> time. Hence I mentioned the case of McCLIM: the only work that has
> been done so far for Scigraph, I guess because of lack of resources,
> is to include it in the CVS repository.

Actually, I've done more than that. Scigraph is a bit weird because it
runs (ran) on several versions of CLIM and on Genera Dynamic
Windows. Hence the main application is written to a compatibility
layer that looks more like DW than CLIM. I wrote the necessary support
for McCLIM, a small addition to the existing support for
"CLIM 2.0", whatever that is. Scigraph works until it makes a call
that does something with a "text-field-view". That's a view that
doesn't exist in the Spec nor in the other documentation I've seen. I
can guess what it means, but I haven't done further work on it yet.

Tim
From: Adam Warner
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <pan.2004.01.12.12.31.20.664528@consulting.net.nz>
Hi Timothy Moore,

> ... I wrote the necessary support for McCLIM, a small addition to the
> existing support for "CLIM 2.0", whatever that is. ...

From the just-posted presentation by Michael Wessel of the University
of Hamburg:
<http://kogs-www.informatik.uni-hamburg.de/~mwessel/papers/clim.pdf>

- Symbolics Inc., Genera 7.0, 1986: Dynamic Windows
- CLIM 1.0: 1991, Nachfolger bzw. Erg�nzung zu Dynamic Windows
- CLIM 2.0: Specification vom 6.5.1992, Scott ·····@Symbolics et al.

i.e. CLIM 2.0 is the specification released by Symbolics in May 1992.

Regards,
Adam
From: Robert STRANDH
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <6wwu80jp0g.fsf@serveur4.labri.fr>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> Robert STRANDH wrote:
> 
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> >>... the single worst catastrophe of the "Common
> >>Lisp Community": i.e. CLIM.  Anyhting that depends on CLIM is
> >> inherently pathological in the current state of affairs.
> > I am interested in knowing more about why you think so.
> 
> Because I cannot get Scigraph to work on LW CLIM even after what
> seemed to me something "obvious" to do (meaning: clean the load file
> etc etc)?

Don't you think it is a bit exaggerated to declare CLIM `the single
worst catastrophe of the "Common Lisp Community"' just because one
person was unable to get one piece of software to work on one
implementation of CLIM?

-- 
Robert Strandh
From: Kenny Tilton
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <jeXLb.68073$cM1.11589083@twister.nyc.rr.com>
Robert STRANDH wrote:

> Marco Antoniotti <·······@cs.nyu.edu> writes:
> 
> 
>>Robert STRANDH wrote:
>>
>>
>>>Marco Antoniotti <·······@cs.nyu.edu> writes:
>>>
>>>
>>>>... the single worst catastrophe of the "Common
>>>>Lisp Community": i.e. CLIM.  Anyhting that depends on CLIM is
>>>>inherently pathological in the current state of affairs.
>>>
>>>I am interested in knowing more about why you think so.
>>
>>Because I cannot get Scigraph to work on LW CLIM even after what
>>seemed to me something "obvious" to do (meaning: clean the load file
>>etc etc)?
> 
> 
> Don't you think it is a bit exaggerated to declare CLIM `the single
> worst catastrophe of the "Common Lisp Community"' just because one
> person was unable to get one piece of software to work on one
> implementation of CLIM?

<g> Well, yes, it seemed to me the exaggeration (dare I say hyperbole?) 
was obvious and playful and not meant to be dragged before a peer 
review. Now if we want to get /serious/...

We've had CLIM pro/con discussions here on c.l.l., with me as a 
potential contributor of a portable CL GUI starting or fomenting a few, 
and I must say it never fares very well. Even the proponents seem 
ambivalent. ACL has one, LW has one, even MCL has one, and there is 
McCLIM, but... when folks ask here "where is the CL gui?", no one talks 
about CLIM. Seems to be a fire that does not want to burn. Maybe it is 
too hard to learn?

kt



> 

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application
From: Robert STRANDH
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <6wptdrdmfj.fsf@serveur4.labri.fr>
Kenny Tilton <·······@nyc.rr.com> writes:

> We've had CLIM pro/con discussions here on c.l.l., with me as a
> potential contributor of a portable CL GUI starting or fomenting a
> few, and I must say it never fares very well. Even the proponents seem
> ambivalent. ACL has one, LW has one, even MCL has one, and there is
> McCLIM, but... when folks ask here "where is the CL gui?", no one
> talks about CLIM. 

I do not like to repeat myself every time such a question comes up.
And I can't compare CLIM to the vendor-specific ones since I have
never used any of them.

Furthermore, I prefer being cautious.  I do not want to recommend
McCLIM in all situations, especially since it is not quite complete
and not quite bug-free yet.  I fear an avalanche of questions and bug
reports that we would not have time to handle, especially from
newbies.  It might be preferable at the moment for experienced CL
programmers only to use it.

That said, I do not hesitate to use it myself every time I need a GUI,
and I have never seen a GUI library as impressive as CLIM.  Some of
the things you can do with it make me laugh out loud.  It is the same
sensation I have when I program in Lisp.

> Seems to be a fire that does not want to burn. Maybe
> it is too hard to learn?

This kind of argument sounds similar to the ones we often hear against
Lisp itself.  Frankly, I don't care whether I am the only CLIM user in
the world, the way I don't care whether I am the only Lisp user in the
world.  If others find CLIM or Lisp too hard to learn, then too bad
for them.  Let them pay in wasted time later on instead.

What is missing though, is a good "getting started" manual.  I have
started one as part of the McCLIM distribution, but as someone else
pointed out, time is a very limited resource for everyone involved.
Also, I am actually not the right person to write such a manual, since
I am not a very experienced CLIM user.

-- 
Robert Strandh
From: Christopher C. Stacy
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <uoetagb0a.fsf@news.dtpq.com>
>>>>> On 11 Jan 2004 07:33:20 +0100, Robert STRANDH ("Robert") writes:
 Robert> What is missing though, is a good "getting started" manual.

I believe that Franz offers courses in programming CLIM.
Maybe that would be the fastest way for people to get started.
From: Kenny Tilton
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <o9gMb.69874$cM1.12003380@twister.nyc.rr.com>
Robert STRANDH wrote:

> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>We've had CLIM pro/con discussions here on c.l.l., with me as a
>>potential contributor of a portable CL GUI starting or fomenting a
>>few, and I must say it never fares very well. Even the proponents seem
>>ambivalent. ACL has one, LW has one, even MCL has one, and there is
>>McCLIM, but... when folks ask here "where is the CL gui?", no one
>>talks about CLIM. 

> That said, I do not hesitate to use it myself every time I need a GUI,
> and I have never seen a GUI library as impressive as CLIM.  Some of
> the things you can do with it make me laugh out loud.

That's certainly a Good Sign.

>>Seems to be a fire that does not want to burn. Maybe
>>it is too hard to learn?
> 
> 
> This kind of argument sounds similar to the ones we often hear against
> Lisp itself.

That is not what I have been hearing here on c.l.l. On the contrary, it 
seems anyone who actually tries Lisp very quickly starts having a very 
good time. True, there is so much good stuff that one can continue to 
learn for years, but the fun starts immediately.

CLIM sounds like months of headscratching before the productivity cuts 
in. If so, that is a bad sign. Good libs do not take months to learn. So 
even if it can be mastered and become useful, it still belongs in a 
dumpster, and it is a shame so much effort is going into McCLIM.

We certainly don't want to offer it to Lisp newbies as The Lisp GUI.

kt

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application
From: Robert STRANDH
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <6w3camgtd0.fsf@serveur4.labri.fr>
Kenny Tilton <·······@nyc.rr.com> writes:

> > This kind of argument sounds similar to the ones we often hear
> > against
> > Lisp itself.
> 
> That is not what I have been hearing here on c.l.l. On the contrary,
> it seems anyone who actually tries Lisp very quickly starts having a
> very good time. True, there is so much good stuff that one can
> continue to learn for years, but the fun starts immediately.

Perhaps c.l.l. is inhabited by people who are convinced that Lisp
makes it possible to have a very good time, but who are not yet
convinced that CLIM makes it possible to go even further, the same way
that comp.programming is inhabited by people who think that
programming makes it possible to have a good time, but who do not yet
know that they can go further by using Lisp.  

And let me confirm that the fun of CLIM starts immediately, and that
one can continue to learn for years. 

> CLIM sounds like months of headscratching before the productivity cuts
> in. If so, that is a bad sign. 

Really?  I am sure that many programmers think that Lisp sounds like
months of headscratching before the productivity cuts in.  Is that a
bad signs for Lisp? 

> Good libs do not take months to
> learn. So even if it can be mastered and become useful, it still
> belongs in a dumpster, and it is a shame so much effort is going into
> McCLIM.

Do you also think that good languages do not take months to learn, and
that languages that take months to learn belong in a dumpster?  Does
that mean that it is a shame that so much effort is going into Lisp? 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <btskao$1un$1@newsreader2.netcologne.de>
Robert STRANDH wrote:

> Perhaps c.l.l. is inhabited by people who are convinced that Lisp
> makes it possible to have a very good time, but who are not yet
> convinced that CLIM makes it possible to go even further, the same way
> that comp.programming is inhabited by people who think that
> programming makes it possible to have a good time, but who do not yet
> know that they can go further by using Lisp.  
> 
> And let me confirm that the fun of CLIM starts immediately, and that
> one can continue to learn for years. 

You have said in an earlier post that you have started writing some 
introductory material. That's a pretty good idea, IMHO.

However, is there link collection at some web page that points to the 
material already available? That should be less work and probably has a 
good effect. Maybe provide some comments to those links that describe 
what's provided.

I have found Ralf Moeller's paper a good overview: 
http://www.sts.tu-harburg.de/~r.f.moeller/uims-clim/clim-intro.html

Maybe there's a difference between the complexity of how CLIM is 
implemented vs. the ease of use that is hard to describe and/or 
understand? (I am just guessing.)


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Robert STRANDH
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <6wy8sdu1gk.fsf@serveur4.labri.fr>
Pascal Costanza <········@web.de> writes:

> You have said in an earlier post that you have started writing some
> introductory material. That's a pretty good idea, IMHO.
> 
> However, is there link collection at some web page that points to the
> material already available? That should be less work and probably has
> a good effect. Maybe provide some comments to those links that
> describe what's provided.

Currently, I consider the "getting started" manual too short to be made
available to the general public.  It is included in the McCLIM
distribution though (as far as I know).  

> I have found Ralf Moeller's paper a good overview:
> http://www.sts.tu-harburg.de/~r.f.moeller/uims-clim/clim-intro.html

I read that paper many times before starting the work on McCLIM, and
found it hard to follow.  Re-reading it now, I find it makes a lot
more sense.  Perhaps that indicates that it is not what an
inexperienced CLIM user would want to read first.  It could of course
also indicate that I am particularly dense.

> Maybe there's a difference between the complexity of how CLIM is
> implemented vs. the ease of use that is hard to describe and/or
> understand? (I am just guessing.)

I think you are basically right.  The "problem" with CLIM is that its
layered approach allows a sophisticated programmer to intervene at
lots of points in the way CLIM works internally.  While this feature
is invaluable to sophisticated programmers, it is confusing to
beginners.  

Any "getting started" documentation must therefore concentrate on how
to write simple applications with little effort.  I have found that
the existing user manuals from Xanalys and Franz very quickly start to
resemble the specification.  I am not so sure a beginner needs to know
about affine transformations or how to modify the coordinate system
of a sheet.  

The "getting started" manual should give the reader the (correct)
impression that getting a simple UI to work is simple.  It should show
some high-level features such as table- and graph formatting, pointer
documentation, command completion, etc.  Then, it should gradually
introduce more sophisticated features, roughly in the order that a
beginner would need them.

Advanced features such as the possibility of writing one's own output
records (which I use in Gsharp) should be mentioned very late or not
at all in the "getting started" manual.  

I found Gilbert Baumann's slides for LSM 2003 in Metz very close to
what I would put first in a "getting started" manual.  

-- 
Robert Strandh
From: Rainer Joswig
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <c366f098.0401120404.27a5c7df@posting.google.com>
Robert STRANDH <·······@labri.fr> wrote in message news:<··············@serveur4.labri.fr>...
> Pascal Costanza <········@web.de> writes:
> 
> > You have said in an earlier post that you have started writing some
> > introductory material. That's a pretty good idea, IMHO.
> > 
> > However, is there link collection at some web page that points to the
> > material already available? That should be less work and probably has
> > a good effect. Maybe provide some comments to those links that
> > describe what's provided.
> 
> Currently, I consider the "getting started" manual too short to be made
> available to the general public.  It is included in the McCLIM
> distribution though (as far as I know).  
> 
> > I have found Ralf Moeller's paper a good overview:
> > http://www.sts.tu-harburg.de/~r.f.moeller/uims-clim/clim-intro.html
> 
> I read that paper many times before starting the work on McCLIM, and
> found it hard to follow.  Re-reading it now, I find it makes a lot
> more sense.  Perhaps that indicates that it is not what an
> inexperienced CLIM user would want to read first.  It could of course
> also indicate that I am particularly dense.

For the german speaking audience, here is a short presentation
by Michael Wessel of the University of Hamburg:

http://kogs-www.informatik.uni-hamburg.de/~mwessel/papers/clim.pdf
http://kogs-www.informatik.uni-hamburg.de/~mwessel/papers/petri2.lisp
From: Robert STRANDH
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <6whdz1tk36.fsf@serveur4.labri.fr>
······@corporate-world.lisp.de (Rainer Joswig) writes:

> For the german speaking audience, here is a short presentation
> by Michael Wessel of the University of Hamburg:
> 
> http://kogs-www.informatik.uni-hamburg.de/~mwessel/papers/clim.pdf
> http://kogs-www.informatik.uni-hamburg.de/~mwessel/papers/petri2.lisp

Looks pretty good.  I wonder whether we could include the Petri net
program in the McCLIM demos. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
From: David Golden
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <qzmMb.4830$HR.9373@news.indigo.ie>
Kenny Tilton wrote:

 
> CLIM sounds like months of headscratching before the productivity cuts
> in.

Rubbish.  So long as you're working through one of the
tutorials/user-manuals  (rather than trying to just magically absorb the
entire spec, which is probably not a sensible approach for most people for
something the size of CLIM), you can have a reasonable GUI up very quickly.
Like with Common Lisp itself, you can be productive long before you know
every nook and cranny of the spec.

> it is a shame so much effort is going into McCLIM.
 
That's just plain not nice. McCLIM is getting pretty damn good, and is being
used for real applications.  It's therefore worthwhile for those working on
it, and hey, they're free to work on what they like. 

> We certainly don't want to offer it to Lisp newbies as The Lisp GUI.

Royal we?  What do you suggest?  Oh. Cello... ;-)
From: Kenny Tilton
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <MopMb.108506$4F2.12110839@twister.nyc.rr.com>
David Golden wrote:

> Kenny Tilton wrote:
> 
>  
> 
>>CLIM sounds like months of headscratching before the productivity cuts
>>in.
> 
> 
> Rubbish. 

Glad to hear it. Like I said, we have had this chat before on c.l.l. and 
this is the first time I am hearing strong pro-CLIM remarks.

>>it is a shame so much effort is going into McCLIM.
> 
>  
> That's just plain not nice.

OK, I take it back.

>>We certainly don't want to offer it to Lisp newbies as The Lisp GUI.
> 
> 
> Royal we?  What do you suggest?  Oh. Cello... ;-)

Cello! <g> Nah, I rejected CLIM before I stumbled onto Cells/Cello, then 
years later gave serious consideration to mixing Cells and McCLIM when I 
set out to build a portable CL gui. Another look at the doc and the 
project status and some discouraging voices here led to a second 
rejection. Now even more years later after (I gather) substantial effort 
McCLIM is (I gather) both suitable for production work yet somehow not 
ready for release to the general programming public.

Are you all /sure/ it is not fundamentally cocked up? The one thing 
Cello does contribute to my doubts on CLIM is that it is so simple to 
use and develop... well, of course, wtih Cells...

:)

kt

-- 
http://tilton-technology.com

Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

Your Project Here! http://alu.cliki.net/Industry%20Application
From: Robert STRANDH
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <6wptdptzm5.fsf@serveur4.labri.fr>
Kenny Tilton <·······@nyc.rr.com> writes:

> Now even more years later after (I gather) substantial
> effort McCLIM is (I gather) both suitable for production work yet
> somehow not ready for release to the general programming public.

I do not see how the amount of effort or the number of years it took
influences the suitability for production work or release to the
general programming public. 

I prefer to let each programmer decide whether McCLIM is suitable for
the task at hand.  I personally do not think that Lisp itself is for
the general programming public (for some value of "general programming
public").  Similarly, I think CLIM (and in particular McCLIM) should
only be used by programmers who do not mind an investment in time
up-front for a potentially huge gain in productivity later on.  As we
know, most programmers prefer simple things, like small languages and
easy-to-learn tools, and they do not really mind wasting development
time later it seems. 

> Are you all /sure/ it is not fundamentally cocked up? 

That is a hard question to answer, and I think the answer will depend
on the person using it.  To many programmers, Lisp itself is
fundamentally cocked up.  But most people reading this newsgroup would
disagree.  Like I said, I happen to think that CLIM is great, at least
what I have seen so far.  

Perhaps you should put in a few hours of time to see for yourself, as
opposed to listening to others.  I mean, if you listened to the voices
of comp.programming concerning the choice of programming language (as
opposed to trying them yourself), you probably would never choose
Lisp. 

> The one thing
> Cello does contribute to my doubts on CLIM is that it is so simple to
> use and develop... well, of course, wtih Cells...

A similar argument could be used in favor of (say) Scheme over Common
Lisp.  Scheme is much more simple to use and develop than Common Lisp.
Many Common Lisp implementations probably took more effort that we
have put into McCLIM, and some of the best ones (SBCL) are still not
considered suitable for release to the general programming public, in
fact not even to the general Lisp programming public (version 0.8.7
was released 2003-12-29).

-- 
Robert Strandh
From: Tim Bradshaw
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ey3r7y6r5ku.fsf@lostwithiel.cley.com>
* Robert STRANDH wrote:

> Don't you think it is a bit exaggerated to declare CLIM `the single
> worst catastrophe of the "Common Lisp Community"' just because one
> person was unable to get one piece of software to work on one
> implementation of CLIM?

No, I think it's fair.  It probably isn't the *worst* catastrophe (I'd
vote for lispm nostalgia), but it's up there.  Like many catastophes
it must have seemed like a good idea at the time, but the end result
was the death of thousands just the same.

--tim
From: Robert STRANDH
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <6wlloeefto.fsf@serveur4.labri.fr>
Tim Bradshaw <···@cley.com> writes:

> > Don't you think it is a bit exaggerated to declare CLIM `the single
> > worst catastrophe of the "Common Lisp Community"' just because one
> > person was unable to get one piece of software to work on one
> > implementation of CLIM?
> 
> No, I think it's fair.  It probably isn't the *worst* catastrophe (I'd
> vote for lispm nostalgia), but it's up there.  Like many catastophes
> it must have seemed like a good idea at the time, but the end result
> was the death of thousands just the same.

Surely, you must have some more profound reasons for thinking this,
than the failure to install Scigraph.  I would be interested in
knowing what they are.

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
From: Tim Bradshaw
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ey3lloekt7o.fsf@lostwithiel.cley.com>
* Robert STRANDH wrote:

> Surely, you must have some more profound reasons for thinking this,
> than the failure to install Scigraph.  I would be interested in
> knowing what they are.

I think `really poor match for any native window system on which which
it has to sit' about sums it up.  Additionally some appalling bits of
misdesign (various things more-or-less can't work without LETF I
think, and LETF is a horrible toxin).

--tim
From: Robert STRANDH
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <6wu131u0zm.fsf@serveur4.labri.fr>
Tim Bradshaw <···@cley.com> writes:

> I think `really poor match for any native window system on which which
> it has to sit' about sums it up.  

A similar thing could be said about Lisp itself as well.  The C
language is certainly a better match for the operating systems (in
particular Unix) on which it has to sit.  But Lisp compensates for
that inconvenience by making programmers more productive.

> Additionally some appalling bits of
> misdesign (various things more-or-less can't work without LETF I
> think, and LETF is a horrible toxin).

Are you saying that the CLIM user is somehow forced to use LETF?  If
not, why does it matter to the end user how CLIM was implemented? 

-- 
Robert Strandh
From: Tim Bradshaw
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <fbc0f5d1.0401121043.1e4365f5@posting.google.com>
Robert STRANDH <·······@labri.fr> wrote in message news:<··············@serveur4.labri.fr>...
> Tim Bradshaw <···@cley.com> writes:
> 
> > I think `really poor match for any native window system on which which
> > it has to sit' about sums it up.  
> 
> A similar thing could be said about Lisp itself as well.  The C
> language is certainly a better match for the operating systems (in
> particular Unix) on which it has to sit.  But Lisp compensates for
> that inconvenience by making programmers more productive.

I don't really agree with this.  C is a better match in a couple of
senses: (1) it's very close to the HW and it's probably better for
that kind of thing; (2) it has a bloody enormous standard library
which has had huge money spent on it for any given platform.  The
second sense is just money: If someone spent that kind of money on
Lisp libraries for, say, Unix, I think it would be a pretty cool Unix
programming Language.  I don't think CLIM will *ever* be a nice way to
write Windows GUIs that behave `right', where `right' is `what users
expect'.

> Are you saying that the CLIM user is somehow forced to use LETF?  If
> not, why does it matter to the end user how CLIM was implemented?

I'm not sure.  The operators which bind things in mediums (media?) are
pretty dubious, as are many others I can't remember I'm sure.  It's
probably possible to get them to work correctly without something like
LETF by having hidden special variables bound to alists keyed on the
medium or something, but, well, yuck (though less yuck than LETF,
obviously).

--tim
From: Timothy Moore
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <wdru131c6zn.fsf@trousse.labri.fr>
··········@tfeb.org (Tim Bradshaw) writes:

> Robert STRANDH <·······@labri.fr> wrote in message
> news:<··············@serveur4.labri.fr>... 
> > Are you saying that the CLIM user is somehow forced to use LETF?  If
> > not, why does it matter to the end user how CLIM was implemented?
> 
> I'm not sure.  The operators which bind things in mediums (media?) are
> pretty dubious, as are many others I can't remember I'm sure.  It's
> probably possible to get them to work correctly without something like
> LETF by having hidden special variables bound to alists keyed on the
> medium or something, but, well, yuck (though less yuck than LETF,
> obviously).

I thought you objected to the version of LETF that has to change
"bindings" on a process switch, which is admittedly gross. Do you have
a problem with any kind of general dynamic binding macro? Plenty of
graphics library toolkits, e.g. OpenGL, have the notion of a stack of
bound graphical state; I'm not sure why the medium stuff rubs you the
wrong way.

Possibly you need to have "letf-on-process-switch" if you let any
thread render into any medium at any time, but that's not required by
the CLIM spec and seems pretty gross too.

Tim
From: Tim Bradshaw
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ey3smiku5j1.fsf@lostwithiel.cley.com>
* Timothy Moore wrote:

> I thought you objected to the version of LETF that has to change
> "bindings" on a process switch, which is admittedly gross. Do you have
> a problem with any kind of general dynamic binding macro? Plenty of
> graphics library toolkits, e.g. OpenGL, have the notion of a stack of
> bound graphical state; I'm not sure why the medium stuff rubs you the
> wrong way.

Anything which expects to dynamically *modify* an object is going to
lose since LETF is not efficiently implementable on real computers:
anything which expands into something like:

(let ((.old. (slot-value x 'foo)))
  (unwind-protect
    (progn
      (setf (slot-value x 'foo) new)
      ...)
   (setf (slot-value x 'foo) .old.)))

is serial code.  There are ways around this: if you hunt in cll I'm
fairly sure you'll find descriptions of them by me. In general the
trick is to hide special variables away behind the scenes.
  
> Possibly you need to have "letf-on-process-switch" if you let any
> thread render into any medium at any time, but that's not required by
> the CLIM spec and seems pretty gross too.

Well, say I have a large image which I am computing and drawing.  I
have a 16-way SMP box, so I decide to break it down into a 4x4 grid,
and have 16 workers compute and draw the image.  Yes, I know, a gross
hack, no-one would do that.

--tim
From: David Golden
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <WHHMb.4970$HR.9476@news.indigo.ie>
Tim Bradshaw wrote:

> Well, say I have a large image which I am computing and drawing.  I
> have a 16-way SMP box, so I decide to break it down into a 4x4 grid,
> and have 16 workers compute and draw the image.  Yes, I know, a gross
> hack, no-one would do that.
> 

I'm pretty sure you know this, but for other readers:  that would be a bit
gross. Usually (on PCish smp hardware where gfx-card mem and cpus' mem are
separate, but cpus share mem) you get much better results doing the
computation in multiple threads, but handing over computed image data to a
collector thread that does the final compositing and drawing involving
interaction with the graphics output system.
From: Timothy Moore
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <wdrptdpc6lp.fsf@trousse.labri.fr>
··········@tfeb.org (Tim Bradshaw) writes:

> programming Language.  I don't think CLIM will *ever* be a nice way to
> write Windows GUIs that behave `right', where `right' is `what users
> expect'.

Does that mean "the way the native window system behaves?"

Tim
From: Tim Bradshaw
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ey3wu7wu646.fsf@lostwithiel.cley.com>
* Timothy Moore wrote:
> ··········@tfeb.org (Tim Bradshaw) writes:
>> programming Language.  I don't think CLIM will *ever* be a nice way to
>> write Windows GUIs that behave `right', where `right' is `what users
>> expect'.

> Does that mean "the way the native window system behaves?"

Yes: my point is that Windows *has won* the GUI battle.  It's not the
best, it's not even *nearly* the best, but the battle is over and its
the only one left standing, other than a few near-clones on Unixoid
systems (heh, including the mac (:-)).  People now know what GUIs are
meant to be like, and they're meant to be terrible crappy Windows
GUIs.  Give them anything else and they just don't want it.  Even I am
shortly going to have to abandon my highly-customised X/rtvtwm/athena
setup in favour of something like Gnome with scrollbars that don't
work, because I can't fight it any more.

The right thing to do with GUIs is to find something which is a
reasonably thin shim on top of native GUIs and use that, not to try
and revive CLIM.  Something like a portable CAPI, for instance.

--tim
From: Greg Menke
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m3y8scqxk9.fsf@europa.pienet>
Tim Bradshaw <···@cley.com> writes:

> * Timothy Moore wrote:
> > ··········@tfeb.org (Tim Bradshaw) writes:
> >> programming Language.  I don't think CLIM will *ever* be a nice way to
> >> write Windows GUIs that behave `right', where `right' is `what users
> >> expect'.
> 
> > Does that mean "the way the native window system behaves?"
> 
> Yes: my point is that Windows *has won* the GUI battle.  It's not the
> best, it's not even *nearly* the best, but the battle is over and its
> the only one left standing, other than a few near-clones on Unixoid
> systems (heh, including the mac (:-)).  People now know what GUIs are
> meant to be like, and they're meant to be terrible crappy Windows
> GUIs.  Give them anything else and they just don't want it.  Even I am
> shortly going to have to abandon my highly-customised X/rtvtwm/athena
> setup in favour of something like Gnome with scrollbars that don't
> work, because I can't fight it any more.
> 
> The right thing to do with GUIs is to find something which is a
> reasonably thin shim on top of native GUIs and use that, not to try
> and revive CLIM.  Something like a portable CAPI, for instance.

You just never know how people react to things other than Windows.  My
step-mother just got a Mac (dual 800 G4) with OSX.  After a day of
messing about her comment was "Its a lot different than Windows, its a
lot more intuitive."  I think the Windows box its replacing is very
soon going to get the Kiss Of Death and be relegated to the garage.

I think the battle is over only for those who are Well Informed.  And
perhaps those who haven't installed WindowMaker.

Gregm
From: Tim Bradshaw
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ey3zncs1bbq.fsf@lostwithiel.cley.com>
* Greg Menke wrote:
> You just never know how people react to things other than Windows.  My
> step-mother just got a Mac (dual 800 G4) with OSX.  After a day of
> messing about her comment was "Its a lot different than Windows, its a
> lot more intuitive."  I think the Windows box its replacing is very
> soon going to get the Kiss Of Death and be relegated to the garage.

I admit to not having played with a mac for a year or two, but is it
significantly *different* than windows?  Is it different, for
instance, in the way that Genera is different than windows, or is it
different in the way that XP is different than Windows 95?

--tim
From: Greg Menke
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m31xq4geyr.fsf@europa.pienet>
Tim Bradshaw <···@cley.com> writes:

> * Greg Menke wrote:
> > You just never know how people react to things other than Windows.  My
> > step-mother just got a Mac (dual 800 G4) with OSX.  After a day of
> > messing about her comment was "Its a lot different than Windows, its a
> > lot more intuitive."  I think the Windows box its replacing is very
> > soon going to get the Kiss Of Death and be relegated to the garage.
> 
> I admit to not having played with a mac for a year or two, but is it
> significantly *different* than windows?  Is it different, for
> instance, in the way that Genera is different than windows, or is it
> different in the way that XP is different than Windows 95?

Unfortunately I've never used Genera, but since XP isn't very
different from 95, I think I would agree to the former.  OSX seems to
be laid out a lot more rationally than Windows.  Its also the first
GUI where I've not needed mouse buttons #2 and #3- so I don't miss
them, which is very strange.  Switching between multiple tasks is kind
of weird too, buts thats clearly due to my predispositions as well.  I
can't really judge the "intuitive" aspect, but that coming from my
step-mother is a considerable hint for me that OSX is a huge
improvement over Windows.

Gregm
From: Tim Bradshaw
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ey38ykbr09g.fsf@lostwithiel.cley.com>
* Greg Menke wrote:

> Unfortunately I've never used Genera, but since XP isn't very
> different from 95, I think I would agree to the former.  

How similar is it to previous mac interfaces?  I wouldn't really
consider any of them significantly different than Windows, at least on
the windows<->genera continuum.

--tim
From: Greg Menke
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m3d69ntlw1.fsf@europa.pienet>
Tim Bradshaw <···@cley.com> writes:

> * Greg Menke wrote:
> 
> > Unfortunately I've never used Genera, but since XP isn't very
> > different from 95, I think I would agree to the former.  
> 
> How similar is it to previous mac interfaces?  I wouldn't really
> consider any of them significantly different than Windows, at least on
> the windows<->genera continuum.

I remember being deeply annoyed by OS9 on several occasions, both from
a usage standpoint and my perceived need of a 2nd mouse button because
the UI just wasn't doing it for me.  OTOH, OSX didn't aggravate me,
and I wasn't wanting to throw the 1 button thing out the window and
replace it with my MouseMan- so something is different.

Whatever that "something" is, it feels sort of like the relief you get
after working with a X window manager with subtly different
keybindings and focus behavior than your usual, then switching to a wm
thats set up to match your needs/style/whatever.  All the unpleasant
wrenching and pounding and cursing just fades away...

Gregm
From: David Golden
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <FS0Nb.5183$HR.10236@news.indigo.ie>
Greg Menke wrote:

> 
> Whatever that "something" is, it feels sort of like the relief you get
> after working with a X window manager with subtly different
> keybindings and focus behavior than your usual, then switching to a wm
> thats set up to match your needs/style/whatever.  All the unpleasant
> wrenching and pounding and cursing just fades away...
> 

But I believe Tim's real point is that most Mac and Windows interfaces still
work in a "conventional" clickety-icons, gadget-interaction-heavy sort of
way. 

Most GUIs just don't work like CLIM used to its full power. And the ones
that kinda do (often in the 3D graphical app field, Mozilla XMLTerm being a
non-3D example, or maybe the recent "NakedObjects" stuff in Javalalaland)
are "quirky".

Of course, you CAN do ordinary stateful-gadgetsy style GUIs in CLIM (one of
the reasons I asserted one can be up and making a reasonable GUI in CLIM
very quickly), but you "miss the point" of CLIM - the
accept/presentation-types/output-records/commands way of interacting is
"just different", combining GUI+CLI spirit to great, but not particularly
"conventional", effect.  

No-one, AFAIK, has "modernised" the "conventional" gadgets+callbacks bits of
CLIM (which do exist!) to include some present-day-popular stateful-gadgets
that weren't in wide use at the time of CLIM 2.0 (N.B. I am no expert on
the modern-day commercial proprietary lisps, so they may have) - the set of
standardised abstract-gadgets is a bit small. Perhaps developers tend to be
seduced by the more interesting and lispier nearly-unique aspects of CLIM
and lose interest in putting buttons everywhere.  But they theoretically
could, and (perhaps unlike Tim) I think it could be worthwhile, and McCLIM
makes for a good playground if someone should choose to do that.


P.S. To McCLIM heads: Can you do with-output-as-gadget at the McCLIM
Listener prompt yet?
From: Greg Menke
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m3vfnfyuck.fsf@europa.pienet>
David Golden <············@oceanfree.net> writes:

> Greg Menke wrote:
> 
> > 
> > Whatever that "something" is, it feels sort of like the relief you get
> > after working with a X window manager with subtly different
> > keybindings and focus behavior than your usual, then switching to a wm
> > thats set up to match your needs/style/whatever.  All the unpleasant
> > wrenching and pounding and cursing just fades away...
> > 
> 
> But I believe Tim's real point is that most Mac and Windows interfaces still
> work in a "conventional" clickety-icons, gadget-interaction-heavy sort of
> way. 

I guess in that sense Doze, X and Mac are in the same boat.  But in
that boat, there is a lot of differentiation between the amount and
type of fiddling that has to go on to get anything done.

 
> Most GUIs just don't work like CLIM used to its full power. And the ones
> that kinda do (often in the 3D graphical app field, Mozilla XMLTerm being a
> non-3D example, or maybe the recent "NakedObjects" stuff in Javalalaland)
> are "quirky".
> 
> Of course, you CAN do ordinary stateful-gadgetsy style GUIs in CLIM (one of
> the reasons I asserted one can be up and making a reasonable GUI in CLIM
> very quickly), but you "miss the point" of CLIM - the
> accept/presentation-types/output-records/commands way of interacting is
> "just different", combining GUI+CLI spirit to great, but not particularly
> "conventional", effect.  

I'll confess right now to opt-ing out of CLIM since Lispworks CAPI
gives me such a easy ride into working up GUI's.  I'm no fan of
conventional approaches as such.  But I'm also poisoned by having
learned something about doing GUI's from Win32 which is oriented
towards gadget-twiddling all the way down to the system calls.  

I guess I've just not been sold yet on CLIM being fundamentally more
right/better/effective for GUI's than the better of the gadget
twiddling techniques.

Gregm
From: Tim Bradshaw
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ey3ad4qut4i.fsf@lostwithiel.cley.com>
* Greg Menke wrote:

> I guess in that sense Doze, X and Mac are in the same boat.  But in
> that boat, there is a lot of differentiation between the amount and
> type of fiddling that has to go on to get anything done.

Sure, that's my point.  They're like English and whatever it is
Americans speak.  CLIM is Latin.

--tim
From: Christopher Jeris
Subject: SOT: GUI design (was Re: Why Lisp is too hard for me to use)
Date: 
Message-ID: <ximhdyyd06b.fsf_-_@hsph.harvard.edu>
David Golden <············@oceanfree.net> writes:
> But I believe Tim's real point is that most Mac and Windows interfaces still
> work in a "conventional" clickety-icons, gadget-interaction-heavy sort of
> way. 
> 
> Most GUIs just don't work like CLIM used to its full power. And the ones
> that kinda do (often in the 3D graphical app field, Mozilla XMLTerm being a
> non-3D example, or maybe the recent "NakedObjects" stuff in Javalalaland)
> are "quirky".

Is there any example of a powerful GUI, _not_ organized according to the
Mac/Windows principles, which is accessible to curious people with
Windows boxes?  Or can you suggest a place to read up on alternative
graphical interface designs?

My experience with user interfaces is limited to Windows/Mac/fvwm/KDE
(all, seemingly, descendants of the Lisa and whatever the Lisa's ancestors
were); twm and similar X window managers which didn't seem to provide
much other than the graphical layer for applications to run in; and
command-line interfaces, which seem absolutely necessary for any
sufficiently evolved application (note that Emacs counts as an example
of a "command-line interface" application, via M-: and
lisp-interaction-mode).

If there's a more "truly graphical" way to make a GUI application
that works well and quickly, something that doesn't reduce to fitting
out a conventional GUI application with a repl and lots of keybindings,
I'd like to know what it is.  Certainly it's very hard for me to
imagine anything other than windows-menubars-icons-etc for the
common cases.

I am very sorry never to have had the chance to use a Lisp Machine.
(I'm 27)

-- 
Chris Jeris ······@oinvzer.net Apply (1 6 2 4)(3 7) to domain to reply.
From: Geoffrey S. Knauth
Subject: Re: SOT: GUI design
Date: 
Message-ID: <1g7k37z.1yj0y5hy2z65bN%geoff@knauth.org>
Christopher Jeris <······@oinvzer.net> wrote:
> Is there any example of a powerful GUI, _not_ organized according to the
> Mac/Windows principles, which is accessible to curious people with
> Windows boxes? 

http://www.squeak.org/

-- 
Geoffrey S. Knauth | http://knauth.org/gsk
From: Henrik Motakef
Subject: Re: SOT: GUI design
Date: 
Message-ID: <x7y8sab6ep.fsf@crocket.internal.henrik-motakef.de>
·····@knauth.org (Geoffrey S. Knauth) writes:

> Christopher Jeris <······@oinvzer.net> wrote:
> > Is there any example of a powerful GUI, _not_ organized according to the
> > Mac/Windows principles, which is accessible to curious people with
> > Windows boxes? 
> 
> http://www.squeak.org/

Given how often squeak is mentioned in this subthread, I cannot help
but express my surprise. The stuff you see in a standard installation
of squeak seems to be a pretty standard GUI from a user point of view
(even if the programmers view might be different/nicer), other than
some relative ugliness.

Is Squeak/Morphic really a fundamentally different approach to user
interaction, or just another way to implement the boring old stuff?
Are there any particular examples in Squeak that demonstrate UI
coolness that I failed to recognize?
From: David Golden
Subject: Re: SOT: GUI design
Date: 
Message-ID: <LjkNb.5350$HR.10812@news.indigo.ie>
Henrik Motakef wrote:

> 
> Is Squeak/Morphic really a fundamentally different approach to user
> interaction, or just another way to implement the boring old stuff?
> Are there any particular examples in Squeak that demonstrate UI
> coolness that I failed to recognize?

Depends how you look at it.  If you inherit a hard distinction in your mind
between "development" of a GUI and "use" of a GUI (or want split the world
into "developer" priests and "user" laypeople to maintain your power base),
then you're kinda missing the point of squeak - after all, the "design
view" for every graphical element is only a click away. Squeak is a
graphical programming system simple (and fun) enough for a smart preteen
child to use (really *use* as a general-purpose USER-PROGRAMMABLE COMPUTER,
not as a virtual typewriter), yet (or perhaps therefore) it is very
powerful.

http://squeakland.org/school/drive_a_car/html/Drivecar12.html
From: Greg Menke
Subject: Re: SOT: GUI design
Date: 
Message-ID: <m3hdyy5c1j.fsf@europa.pienet>
David Golden <············@oceanfree.net> writes:

> Henrik Motakef wrote:
> 
> > 
> > Is Squeak/Morphic really a fundamentally different approach to user
> > interaction, or just another way to implement the boring old stuff?
> > Are there any particular examples in Squeak that demonstrate UI
> > coolness that I failed to recognize?
> 
> Depends how you look at it.  If you inherit a hard distinction in your mind
> between "development" of a GUI and "use" of a GUI (or want split the world
> into "developer" priests and "user" laypeople to maintain your power base),
> then you're kinda missing the point of squeak - after all, the "design
> view" for every graphical element is only a click away. Squeak is a
> graphical programming system simple (and fun) enough for a smart preteen
> child to use (really *use* as a general-purpose USER-PROGRAMMABLE COMPUTER,
> not as a virtual typewriter), yet (or perhaps therefore) it is very
> powerful.
> 
> http://squeakland.org/school/drive_a_car/html/Drivecar12.html

But it seems to me to be essentially more of the same widget fiddling,
just with fancier widgets.  Not that such a thing is bad- just not
fundamentally different.

Gregm
From: David Golden
Subject: Re: SOT: GUI design
Date: 
Message-ID: <DLkNb.5360$HR.10841@news.indigo.ie>
Greg Menke wrote:

> 
> But it seems to me to be essentially more of the same widget fiddling,
> just with fancier widgets.  Not that such a thing is bad- just not
> fundamentally different.
> 

Well,  depends on how fundamental you want to go.  Hell, we're not
"fundamentally" very different to sea urchins, for some value of
fundamental.

A much-promoted feature of lisp is its interactivity, reflectivity, and
blurring of any distinction between the various "times" of development.

Well, Squeak brings that interactive, reflective feel to a GUI, compared to
ordinary GUI toolkits - in Squeak the GUI Builder is the GUI and vice
versa. It is more dynamic and reflective again than CLIM - in CLIM, you
still define GUI stuff textually, pretty much, a GUI CLIM GUI Builder is
certainly feasible but would be an application, I guess, without the
integration of Squeak.
From: Bruce Stephens
Subject: Re: SOT: GUI design
Date: 
Message-ID: <87smiioxra.fsf@cenderis.demon.co.uk>
David Golden <············@oceanfree.net> writes:

[...]

> Well, Squeak brings that interactive, reflective feel to a GUI,
> compared to ordinary GUI toolkits - in Squeak the GUI Builder is the
> GUI and vice versa. It is more dynamic and reflective again than
> CLIM - in CLIM, you still define GUI stuff textually, pretty much, a
> GUI CLIM GUI Builder is certainly feasible but would be an
> application, I guess, without the integration of Squeak.

More than that.  If I understand the intention correctly, MVC divides
things into (at least) two parts, the models (objects) and views of
those objects.  But with Morphic, the idea is that there is only one
kind of thing: the graphical representation and the object are the
same.  So in MVC, by manipulating a view, you're (indirectly)
affecting the underlying object, but in Morphic the manipulation is
immediate and direct, since the graphical thing and the object are the
same.
From: Greg Menke
Subject: Re: SOT: GUI design
Date: 
Message-ID: <m3k73trgku.fsf@europa.pienet>
Bruce Stephens <············@cenderis.demon.co.uk> writes:

> David Golden <············@oceanfree.net> writes:
> 
> [...]
> 
> > Well, Squeak brings that interactive, reflective feel to a GUI,
> > compared to ordinary GUI toolkits - in Squeak the GUI Builder is the
> > GUI and vice versa. It is more dynamic and reflective again than
> > CLIM - in CLIM, you still define GUI stuff textually, pretty much, a
> > GUI CLIM GUI Builder is certainly feasible but would be an
> > application, I guess, without the integration of Squeak.
> 
> More than that.  If I understand the intention correctly, MVC divides
> things into (at least) two parts, the models (objects) and views of
> those objects.  But with Morphic, the idea is that there is only one
> kind of thing: the graphical representation and the object are the
> same.  So in MVC, by manipulating a view, you're (indirectly)
> affecting the underlying object, but in Morphic the manipulation is
> immediate and direct, since the graphical thing and the object are the
> same.

Microsoft Foundation Classes offer similar concepts, though I imagine
in a less elegantly conceived manner- and certainly not particularly
dynamic or reflexive.  Morphic sounds like a concise way of arranging
things, perhaps I'm looking for the wrong sorts of differences.

Gregm
From: David Golden
Subject: Re: SOT: GUI design (was Re: Why Lisp is too hard for me to use)
Date: 
Message-ID: <QWfNb.5289$HR.10379@news.indigo.ie>
Christopher Jeris wrote:

> 
> Is there any example of a powerful GUI, _not_ organized according to the
> Mac/Windows principles, which is accessible to curious people with
> Windows boxes?  Or can you suggest a place to read up on alternative
> graphical interface designs?
> 

Assuming you're unwilling to try one of the commercial lisps that offer
polished Classic/Real CLIM implementations (but AFAIK don't include them in
their trial versions):

McCLIM is fairly accessible if you've got a x86 windoze box - just install a
friendly linux distro dual-boot (I recommend Mandrake, while Debian is
popular among open-source lisp people, it's also not very beginner-friendly
at the moment), then cmucl and mcclim... There should be links to various
papers about CLIM at http://mcclim.cliki.net/
But bear in mind McCLIM isn't "finished", and, while AFAIK most stuff works,
it hasn't IMHO been prettified to look very swish yet.  (Could I do better?
No...)

Rainer Joswig's videos of LispM UI might give you an idea too - the look is
more than a little dated, but some of the power should be apparent if you
can see beyond the cruddy graphics. 
http://www.cliki.net/Lisp Machine Videos

Squeak is also somewhat "different", and kinda cool, but different to CLIM
too.  http://squeak.org/


Jumping to a more abstract level, which I like to think of as a bit
different to a pure gadget GUI:
You can get a LOT of mileage out of "document centric" or "component
linking" guis - i.e. if you want more power than direct manipulation of
stateful gadgets provides, build a document manipulation gui out of
gadgets, then use the built documents as input/controllers of the "real"
program (i.e. end-users are "programming" in a very primitive graphical
language). Audio applications based on a pipes metaphor are a common
example of this, and work very well. Java BeanBoxes or VB Forms editors are
an example of such a GUI that *developers* (here considered as end-users)
like for making more actually making more sedate direct-gadget GUIs in.

Note that CLIM actually makes writing such applications pretty easy, too. 
But modern gadgety GUI toolkits often include "sufficiently complex"
container/composite-document gadgets/components to allow similar
shenanigans without bringing in other more alien aspects of CLIMiness.
From: Bruce Stephens
Subject: Re: SOT: GUI design
Date: 
Message-ID: <87eku2mexo.fsf@cenderis.demon.co.uk>
David Golden <············@oceanfree.net> writes:


[...]

> Audio applications based on a pipes metaphor are a common example of
> this, and work very well. Java BeanBoxes or VB Forms editors are an
> example of such a GUI that *developers* (here considered as
> end-users) like for making more actually making more sedate
> direct-gadget GUIs in.

Another good example of that genre would be <http://www.opendx.org/>,
which does data analysis.

[...]
From: Friedrich Dominicus
Subject: Re: SOT: GUI design
Date: 
Message-ID: <87ptdm4ee2.fsf@fbigm.here>
Christopher Jeris <······@oinvzer.net> writes:
>
> Is there any example of a powerful GUI, _not_ organized according to the
> Mac/Windows principles, which is accessible to curious people with
> Windows boxes?  
Squeak http://www.squeak.org comes to my mind.
Check out the Squeak Morphs 

>
> I am very sorry never to have had the chance to use a Lisp Machine.
> (I'm 27)
You can with a big pocket ;-)

Regards
Friedrich
From: Tim Bradshaw
Subject: Re: SOT: GUI design
Date: 
Message-ID: <ey33caiusu9.fsf@lostwithiel.cley.com>
* Christopher Jeris wrote:

> Is there any example of a powerful GUI, _not_ organized according to the
> Mac/Windows principles, which is accessible to curious people with
> Windows boxes?  Or can you suggest a place to read up on alternative
> graphical interface designs?

I'm not aware of any.  It may be that the smalltalk GUIs are really
different, but when I played with them they were much closer to
Windows than the LispM interfaces were.

I think CLIM is not a good example of what it's trying to be, though
you can play with it, because (a) I've never seen a CLIM
implementation (I've not used the free one, but I've used the ports on
ACL, LW and Genera) that wasn't significantly gritty to use, and (b)
to get the experience you need the *whole system* to be using it.  I'm
not aware of any CLIM applications large enough, really.

--tim
From: Frank A. Adrian
Subject: Re: SOT: GUI design
Date: 
Message-ID: <pan.2004.01.14.22.28.21.230372@ancar.org>
On Wed, 14 Jan 2004 21:24:14 +0000, Tim Bradshaw wrote:

> I'm not aware of any.  It may be that the smalltalk GUIs are really
> different, but when I played with them they were much closer to
> Windows than the LispM interfaces were.

They're not (really different, that is :-).  Even the Lisa interface
(mentioned as the grandma of the WIMP world) was based on the Xerox PARC's
Alto that spawned not only the Xerox Star and D-Series, but also
Smalltalk.  The real queston: Given the limitations of both hands sitting
on a keyboard resting on a desktop with a video display perpendicular to
that desktop is there actually a better interface than WIMP?

I guess that my take on the whole matter is that to get a better GUI, you
have to start by getting rid of the current hardware and display.  If you
don't do that, your perception will always be colored by WIMP.

I sorta like Kay's original Dynabook idea, but instead of some stupid
video-screen, make the thing an actual book using E-paper with an
electrical stylus to mark on the E-paper.  Maybe with detachable
sheets so you can move them around on the table, but with wireless
embedded in each sheet so that the book retains its integrity. Yes, you're
still moving around pictures, words, etc. that you mark on with a stylus,
but you can have an electronic ToC in the front and Index in the back to
organize your data. But then, I *like* books... a lot. I'm really
familiar with books. Heck, even porn doesn't look right without the
staples in the centerfold's belly (I'm aging myself here :-). Maybe
someone else would like a video game-type interface. Maybe someone else
likes hand-mixers.

Maybe, in the final analysis, the entire idea of a standard GUI paradigm
is a bit misguided. Instead, you have data models that hook to whatever
GUI device you happen to be looking at it through. And, if you can get
away from the standard monitor/keyboard/mouse hardware, you can have a
great number of ideas of how to access, view, modify, and save that data. 
In any case, I think that getting rid of the current hardware is a
necessary first step in getting better GUIs.

faa
From: Robert St. Amant
Subject: Re: SOT: GUI design
Date: 
Message-ID: <lpn1xpvwnf7.fsf@haeckel.csc.ncsu.edu>
"Frank A. Adrian" <·······@ancar.org> writes:

> On Wed, 14 Jan 2004 21:24:14 +0000, Tim Bradshaw wrote:
> 
> > I'm not aware of any.  It may be that the smalltalk GUIs are really
> > different, but when I played with them they were much closer to
> > Windows than the LispM interfaces were.
> 
> They're not (really different, that is :-).  Even the Lisa interface
> (mentioned as the grandma of the WIMP world) was based on the Xerox PARC's
> Alto that spawned not only the Xerox Star and D-Series, but also
> Smalltalk.  The real queston: Given the limitations of both hands sitting
> on a keyboard resting on a desktop with a video display perpendicular to
> that desktop is there actually a better interface than WIMP?

I think so.  It means more than changing the "visual syntax", though.
Gentner and Nielsen wrote a piece for CACM on their anti-Mac interface
back in 1996 that is informative:

             <http://www.acm.org/cacm/AUG96/antimac.htm>

For more speculative work, there's the StarFire video, which
unfortunately is difficult to get hold of these days.  It involves
verbal commands, gestures, some specialized input devices, and so
forth, with the computer behaving in a plausibly intelligent way,
being smarter about use in context.

> I guess that my take on the whole matter is that to get a better GUI, you
> have to start by getting rid of the current hardware and display.  If you
> don't do that, your perception will always be colored by WIMP.

(snippage)

> Maybe, in the final analysis, the entire idea of a standard GUI paradigm
> is a bit misguided. Instead, you have data models that hook to whatever
> GUI device you happen to be looking at it through. And, if you can get
> away from the standard monitor/keyboard/mouse hardware, you can have a
> great number of ideas of how to access, view, modify, and save that data. 
> In any case, I think that getting rid of the current hardware is a
> necessary first step in getting better GUIs.

In general I agree.  There's interesting work on tangible interfaces
that moves in this direction, though usually not for general purpose
computing.  To a lesser extent, work on cross-platform interfaces
(e.g., from desktop machines to touch screen kiosks to mobile devices)
has the same flavor of reassessing basic assumptions.  The field of
intelligent user interfaces also has lots of good ideas (though not
everyone has my biases.)

-- 
Rob St. Amant
http://www4.ncsu.edu/~stamant
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bu2154$p53$1@newsreader2.netcologne.de>
Tim Bradshaw wrote:

> * Greg Menke wrote:
> 
>>Unfortunately I've never used Genera, but since XP isn't very
>>different from 95, I think I would agree to the former.  
> 
> How similar is it to previous mac interfaces?  I wouldn't really
> consider any of them significantly different than Windows, at least on
> the windows<->genera continuum.

You can't describe the difference, you can only experience it. ;)

Here is an analogy: Mac OS X is to Windows like a Lisp with lexical 
scoping to a Lisp with dynamic scoping. You won't notice the difference 
by just "playing around with it a little".

It's my personal experience that most of the time, Mac OS X just does 
the right thing how I expect it to work intuitively. I haven't 
experienced this to the same degree on Windows.

BTW, in an earlier post you have said that the Windows has "won the GUI 
battle". I have thought the same thing about C-like syntax until about 
two years ago. My gut feeling is that your statement is on the same level.

Yes, Mac OS X is not a perfect OS. But neither is Common Lisp a perfect 
programming language. So? ;)

Note that these are just subjective statements. I am not even trying to 
be objective. Maybe some expert on cognitive psychology can explain 
these things. I don't know...


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Tim Bradshaw
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ey3eku2ut8a.fsf@lostwithiel.cley.com>
* Pascal Costanza wrote:
> BTW, in an earlier post you have said that the Windows has "won the
> GUI battle". I have thought the same thing about C-like syntax until
> about two years ago. My gut feeling is that your statement is on the
> same level.

Nothing wins for ever, but things that have lost generally don't come
back: something else replaces the current winner.  (And no, Lisp
didn't lose, because it was never in that fight).
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bu0gsg$ogo$1@newsreader2.netcologne.de>
Tim Bradshaw wrote:

> * Greg Menke wrote:
> 
>>You just never know how people react to things other than Windows.  My
>>step-mother just got a Mac (dual 800 G4) with OSX.  After a day of
>>messing about her comment was "Its a lot different than Windows, its a
>>lot more intuitive."  I think the Windows box its replacing is very
>>soon going to get the Kiss Of Death and be relegated to the garage.
> 
> I admit to not having played with a mac for a year or two, but is it
> significantly *different* than windows?  Is it different, for
> instance, in the way that Genera is different than windows, or is it
> different in the way that XP is different than Windows 95?

It's different enough. ;)


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Jeff Dalton
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <fx4u0yf6eqr.fsf@todday.inf.ed.ac.uk>
Tim Bradshaw <···@cley.com> writes:

> Yes: my point is that Windows *has won* the GUI battle.  It's not the
> best, it's not even *nearly* the best, but the battle is over ...

I am still holding out.  Unfortunately, the Linux world seems
to be enslaving itself with Windows-think, resulting in almost
unusable (by me) "desktops".

BTW, is there any way on Windows to move a window to the bottom
of the pile of partly overlapping windows.  There's a mouse-click
way to bring one to the top.  But if a window is covered by others,
so that you can't bring it to the top, it can be quite difficult
to get at it, because you can't make the covering windows go
down.

I have asked various Windows users about this, and they have
a hard time understanding the question.

Anyway, I was stuck in some nightmare Linux window system
a while back, and it had the very same problem.  (What is
wrong with these people?)

-- jd
From: Robert Bruce Carleton
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <10ag5dgn55nkd9a@corp.supernews.com>
Though I've used KDE and Gnome, I've actually gone backwards a bit in my 
unix environment.  I use mwm as my window manager.  I found that I 
usually start things from the shell, and that all the fuss of a desktop 
just got in the way.  The other reason is my primary unix platform has 
"only" 128MB's of RAM, and the fancy desktops just seemed to suck up 
most of that without adding much value.  Mozilla and emacs together 
provide all the features that I think that I would use a desktop for.

On the other hand I also have Windows and Mac OS X machines that I feel 
comfortable with as well.

My two cents,

			--Bruce


Jeff Dalton wrote:
> Tim Bradshaw <···@cley.com> writes:
> 
> 
>>Yes: my point is that Windows *has won* the GUI battle.  It's not the
>>best, it's not even *nearly* the best, but the battle is over ...
> 
> 
> I am still holding out.  Unfortunately, the Linux world seems
> to be enslaving itself with Windows-think, resulting in almost
> unusable (by me) "desktops".
> 
> BTW, is there any way on Windows to move a window to the bottom
> of the pile of partly overlapping windows.  There's a mouse-click
> way to bring one to the top.  But if a window is covered by others,
> so that you can't bring it to the top, it can be quite difficult
> to get at it, because you can't make the covering windows go
> down.
> 
> I have asked various Windows users about this, and they have
> a hard time understanding the question.
> 
> Anyway, I was stuck in some nightmare Linux window system
> a while back, and it had the very same problem.  (What is
> wrong with these people?)
> 
> -- jd
From: Christian Lynbech
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <873c5ztq8n.fsf@dhcp229.ted.dk.eu.ericsson.se>
>>>>> "Robert" == Robert Bruce Carleton <···@hakuhale.net> writes:

Robert> Though I've used KDE and Gnome, I've actually gone backwards a
Robert> bit in my unix environment.  I use mwm as my window manager.

Let me do some advertising for eclipse, the Common Lisp based window
manager.

I have used it for a long time and it has become rather stable and
very usable.

Check it out on 

        http://www.common-lisp.net/project/eclipse/

My feeling is that the window manager is very important part of the UI
and thus I want something I can hack myself.


------------------------+-----------------------------------------------------
Christian Lynbech       | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - ·······@hal.com (Michael A. Petonic)
From: Edi Weitz
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m365avh0z4.fsf@bird.agharta.de>
On Mon, 17 May 2004 10:25:12 +0200, Christian Lynbech <·················@ericsson.com> wrote:

> Let me do some advertising for eclipse, the Common Lisp based window
> manager.
>
> I have used it for a long time and it has become rather stable and
> very usable.
>
> Check it out on 
>
>         http://www.common-lisp.net/project/eclipse/
>
> My feeling is that the window manager is very important part of the
> UI and thus I want something I can hack myself.

Very true.

BTW, there's also "StumpWM", another window manager written in
Common Lisp:

  <http://www.cliki.net/stumpwm>
  <http://www.nongnu.org/stumpwm>

It's following the minimalistic philosophy of WMs like ratpoison.[1]

Cheers,
Edi.

[1] <http://ratpoison.sourceforge.net/>
From: Christian Hofer
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <c8dog6$iq5$1@online.de>
Christian Lynbech wrote:
>>>>>>"Robert" == Robert Bruce Carleton <···@hakuhale.net> writes:
> 
> 
> Robert> Though I've used KDE and Gnome, I've actually gone backwards a
> Robert> bit in my unix environment.  I use mwm as my window manager.
> 
> Let me do some advertising for eclipse, the Common Lisp based window
> manager.
> 
> I have used it for a long time and it has become rather stable and
> very usable.

When I first found Eclipse, I thought: Cool, a CL based window manager. 
Thus, I downloaded the documentation - 4 manuals. But they are nothing 
but templates... So I was convinced that this is a dead project.

But now that you say it, normally a window manager should be quite self 
explaining. Maybe it's worth a try... On the other hand, I would really 
like to have the promised programmer's manual: Why should I need a CL 
window manager, if I cannot hack it?

Chris
From: Iban
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <40AC86B4.908@yahoo.fr>
Christian Hofer wrote:
> Christian Lynbech wrote:
> 
>>>>>>> "Robert" == Robert Bruce Carleton <···@hakuhale.net> writes:
>>
>>
>>
>> Robert> Though I've used KDE and Gnome, I've actually gone backwards a
>> Robert> bit in my unix environment.  I use mwm as my window manager.
>>
>> Let me do some advertising for eclipse, the Common Lisp based window
>> manager.
>>
>> I have used it for a long time and it has become rather stable and
>> very usable.
> 
> 
> When I first found Eclipse, I thought: Cool, a CL based window manager. 
> Thus, I downloaded the documentation - 4 manuals. But they are nothing 
> but templates... So I was convinced that this is a dead project.
> 
> But now that you say it, normally a window manager should be quite self 
> explaining. Maybe it's worth a try... On the other hand, I would really 
> like to have the promised programmer's manual: Why should I need a CL 
> window manager, if I cannot hack it?

First of all, I would like say that the Eclipse project is not dead. I'm 
planning to propose a release (something like 0.9) in a near future.
But as you all said, the lack of documentation is a real problem. In the
past, Erik Enge was working on the manuals, but he switched from a linux
box to a Mac OS X machine and started to be busy with work and almost 
stopped working with me. I must confess that I didn't continue his 
documentation efforts and this is a mistake. But since I am the only one 
who work on Eclipse it is hard for me to maintain and animate the whole 
project alone, and for that reason I concentrate myself on some coding 
effort rather than on writing the docs. But if somebody wants to help, 
I'll be really happy to give anyone cvs write access and have a little 
more traffic on the Eclipse's mailing lists.

If anyone is interested, please let me know.

Best regards,
Iban.
From: Edi Weitz
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m3lljnqtpe.fsf@bird.agharta.de>
On Thu, 20 May 2004 12:21:40 +0200, Iban <········@yahoo.fr> wrote:

> First of all, I would like say that the Eclipse project is not
> dead. I'm planning to propose a release (something like 0.9) in a
> near future.  But as you all said, the lack of documentation is a
> real problem. In the past, Erik Enge was working on the manuals, but
> he switched from a linux box to a Mac OS X machine and started to be
> busy with work and almost stopped working with me. I must confess
> that I didn't continue his documentation efforts and this is a
> mistake. But since I am the only one who work on Eclipse it is hard
> for me to maintain and animate the whole project alone, and for that
> reason I concentrate myself on some coding effort rather than on
> writing the docs. But if somebody wants to help, I'll be really
> happy to give anyone cvs write access and have a little more traffic
> on the Eclipse's mailing lists.
>
> If anyone is interested, please let me know.

I'd like to offer help with the docs but I'm too busy right now. Just
two points:

1. As others have mentioned, the man page is pretty informative.[1]
   Maybe a good first step would be to remove the dead links from the
   website and just put an HTML version of the man page there.

2. If someone is planning to try Eclipse but is afraid of its "alpha
   status" - there's no reason to be afraid. I just grabbed the CVS
   tarball offered by common-lisp.net, built a custome CMUCL core with
   CLX (as described in the docs/README file) and then did

     ./configure --with-initcore=/path/to/this/core
     make
     sudo make install

   and, presto, everything worked! No need to fight with ASDF,
   MK:DEFSYSTEM or other things a "newbie" might not be familiar with.

Cool project!

Cheers,
Edi.

[1] I got a couple of

      eclipse.1:220: a special character is not allowed in a name

    warnings, though.
From: Gareth McCaughan
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87smdxz72q.fsf@g.mccaughan.ntlworld.com>
Christian Lynbech <·················@ericsson.com> writes:

> Let me do some advertising for eclipse, the Common Lisp based window
> manager.
> 
> I have used it for a long time and it has become rather stable and
> very usable.

I'm a bit put off by the documentation page on the website,
with 21 different links, none of which has any actual
documentation at the far end. There does appear to be
some actual information in the manpage accessible via
the browsable CVS...

-- 
Gareth McCaughan
.sig under construc
From: Rainer Joswig
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <c366f098.0405170145.ed264da@posting.google.com>
Jeff Dalton <····@todday.inf.ed.ac.uk> wrote in message news:<···············@todday.inf.ed.ac.uk>...
> Tim Bradshaw <···@cley.com> writes:
> 
> > Yes: my point is that Windows *has won* the GUI battle.  It's not the
> > best, it's not even *nearly* the best, but the battle is over ...
> 
> I am still holding out.  Unfortunately, the Linux world seems
> to be enslaving itself with Windows-think, resulting in almost
> unusable (by me) "desktops".
> 
> BTW, is there any way on Windows to move a window to the bottom
> of the pile of partly overlapping windows.  There's a mouse-click
> way to bring one to the top.  But if a window is covered by others,
> so that you can't bring it to the top, it can be quite difficult
> to get at it, because you can't make the covering windows go
> down.
> 
> I have asked various Windows users about this, and they have
> a hard time understanding the question.
> 
> Anyway, I was stuck in some nightmare Linux window system
> a while back, and it had the very same problem.  (What is
> wrong with these people?)
> 
> -- jd

Maybe you would like something like Apple's 'Expose':
http://www.apple.com/macosx/features/expose/

With a gesture or a keystroke you get an overview over
the windows of an app or all windows or you get down
to the desktop.

Ripoffs for Windows:

http://www.oxygen-inc.com/premium/InsaniSoft/iEx.htm
http://www.winplosion.com/index.html
http://onlinetoolsteam.com/WindowsExposer/Order.asp
From: Alan Shutko
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87hduf2gbh.fsf@wesley.springies.com>
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:

> BTW, is there any way on Windows to move a window to the bottom
> of the pile of partly overlapping windows.

I think Alt-ESC might work.

-- 
Alan Shutko <···@acm.org> - I am the rocks.
Guy: What's this? * Crow: EVIL!
From: Marco Antoniotti
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <RUzMb.365$Nq.77574@typhoon.nyu.edu>
Robert STRANDH wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
> 
> 
>>Robert STRANDH wrote:
>>
>>
>>>Marco Antoniotti <·······@cs.nyu.edu> writes:
>>>
>>>
>>>>... the single worst catastrophe of the "Common
>>>>Lisp Community": i.e. CLIM.  Anyhting that depends on CLIM is
>>>>inherently pathological in the current state of affairs.
>>>
>>>I am interested in knowing more about why you think so.
>>
>>Because I cannot get Scigraph to work on LW CLIM even after what
>>seemed to me something "obvious" to do (meaning: clean the load file
>>etc etc)?
> 
> 
> Don't you think it is a bit exaggerated to declare CLIM `the single
> worst catastrophe of the "Common Lisp Community"' just because one
> person was unable to get one piece of software to work on one
> implementation of CLIM?

My comment was only partially technical.  CLIM is very hard to get 
right.  You have done a lot of work on it and know what that entails.

Compare this to CLX, which is widely available and used in every CL 
running on a machine with an X server.  Again, with the power of 
hindsight, we - the "Lisp Community" - would have been better off had 
the original CLIM implementation be distributed under the same terms of CLX.

In the context of the discussion we were having, I was making the point 
that picking on a CLIM-dependent application to say that something is 
"old" and "does not work" is not all that kosher.  Always because of the 
power of hindsight we have now.

Cheers

--
Marco
From: Timothy Moore
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <wdr4qv4q6x8.fsf@trousse.labri.fr>
Marco Antoniotti <·······@cs.nyu.edu> writes:

> Robert STRANDH wrote:
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> >>The truth is
> >>that the CLIM implementation is incredibly difficult to get right if
> >>you do not have a bunch of programmers completely devoted to it (as
> >> the heroic and saintly FreeCLIM people know
> > It is difficult, partly because the specification is sometimes vague
> > and sometimes self-contradictory.  But I am very impressed by the work
> > of the people who wrote it anyway, since it is a very complex piece of
> > software.
> 
> I am impressed myself.  Yet it is a complicated thing to set up wil a
> lot of functionality that should have been packaged otherwise
> (e.g. all the command processor stuff) and stuff -- presentation types
> -- that is extremely difficult to implement on ANSI CL.

There is/was certainly a "Right Thing" mentality in CLIM, vs. "Worse
Is Better." CLIM bends over backwards to both give the user a lot of power
and also enable rapid application development, at the expense of a ton
of complexity in the implementation. I'm not sure what lesson one
should take away. "The Right Thing" is the better approach if you're
willing to wait a decade :) I think we all see that with Common Lisp
now.

Presentation types would have taken a lot of work -- or a lot of code
-- if restricted to ANSI CL, but they were not so bad with the
support of the MOP. CLIM would be impossible to write in ANSI CL
anyway without rewriting many of the I/O functions, so I'm not sure
that talking about ANSI CL and CLIM is useful at all.

One advantage that the McCLIM has, in the first years of the 21st
century, over the original CLIM is that the extreme need to optimize
doesn't exist. We've been able to concentrate on implementing features
and release  a somewhat naive implementation that people are able to
use, both to learn something about CLIM and do real work. 10 years ago
the same code would have been far too slow.

> >>- are presentation types finally working?)
> > I do not know whether all aspects of presentation types work
> > according
> > to the specification, but I have used McCLIM presentation types in
> > several applications for the past year or so with no major
> > surprises.
> 
> That is good news.  It means that the first time FreeCLIM has had
> working presentation types was late 2002.

I told you once already, in August 2002 in this very newsgroup, that
presentation types were working! :)

Tim
From: Paolo Amoroso
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <877k01vz60.fsf@plato.moon.paoloamoroso.it>
Lupo LeBoucher writes:

> For example, I want to use something like CLIM, but I can't even build any 
> of the X-packages.

Which operating system and Common Lisp implementation are you using?


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Paolo Amoroso
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ekuhhs9z.fsf@plato.moon.paoloamoroso.it>
Takehiko Abe writes:

> In article <············@acm.org>, Barry Wilkes wrote:
>
>> >> > Why do we need defsystems at all in order to distribute a
>> >> > library?
>> >> 
>> >> Read this: http://www.nhplace.com/kent/Papers/Large-Systems.html
>> >> 
>> >
>> > I use a defsystem. I think I know its merit. What do you think
>> > I'm missing? [yes I read the paper.]
>> 
>> Yes you *can* compile/load a system by just following an order given in a
>> readme file.  However, it's a very manual process and hence error prone.
>
> It's tedious but straight-forward. I don't think it is error prone.

This is beginning to look like a Turing completeness argument.
Okay, you are a macho programmer.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Marco Antoniotti
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <hCZJb.252$Nq.53360@typhoon.nyu.edu>
Takehiko Abe wrote:
> In article <············@acm.org>, Barry Wilkes wrote:
> 
> 
>>>>>Why do we need defsystems at all in order to distribute a
>>>>>library?
>>>>
>>>>Read this: http://www.nhplace.com/kent/Papers/Large-Systems.html
>>>>
>>>
>>>I use a defsystem. I think I know its merit. What do you think
>>>I'm missing? [yes I read the paper.]
>>
>>Yes you *can* compile/load a system by just following an order given in a
>>readme file.  However, it's a very manual process and hence error prone.
> 
> 
> It's tedious but straight-forward. I don't think it is error prone.
> 
> 
>>So, now you are using a defsystem (of some kind) to compile/load your code.
>>It surely makes sense for you to distribute your code using this mechanism.
> 
> 
> No, it does not. Suppose you use defsystem A and the library you want
> to install comes with defsystem B, what would you have to do?

The basic definition forms for MK:DEFSYSTEM and ASDF are practically 
identical.  If you do not have fancy (or convoluted, you choose) 
dependencies, translating an ASDF to a MK:DEFSYSTEM or viceversa is 
usually a matter of changing ASDF:DEFSYSTEM to MK:DEFSYSTEM and viceversa.

So, at least this far you can go.

Apart from that, ASDF and MK:DEFSYSTEM share two characteristics: they 
use a "declarative" specification and they do work on a majority of the 
CL implementations around. Only the PCL defsystem may have the second 
characteristic, but it lacks the first one.

Now.  If you need something more complex you can check out 
CL-CONFIGURATION in the CLOCC (shameless plug.) Still rough, but is does 
work. :)

Cheers
--
Marco
From: Tim Bradshaw
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ey37k07g1k2.fsf@lostwithiel.cley.com>
* Takehiko Abe wrote:
> It's tedious but straight-forward. I don't think it is error prone.

So all these automated software build systems are just a huge waste of
time, right?  The user will just know which of their thousands of
source files need to be recompiled.  Of course.

--tim
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bt6f48$knf$1@newsreader2.netcologne.de>
Takehiko Abe wrote:

> In article <············@newsreader2.netcologne.de>, 
> Pascal Costanza wrote:
> 
> 
>>>I do not understand why it has to be so hard. A library can be
>>>distributed with a set of source files and a readme file
>>>specifying the order in which those files should be loaded. No?
>>>
>>>Why do we need defsystems at all in order to distribute a
>>>library?
>>
>>Read this: http://www.nhplace.com/kent/Papers/Large-Systems.html
> 
> I use a defsystem. I think I know its merit. What do you think
> I'm missing? [yes I read the paper.]

I am sorry - I have understood your question to be broader than it 
actually is.


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Michael Livshin
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <s3smix6vcd.fsf@cmm.kakpryg.net.cmm>
····@com.mac (Takehiko Abe) writes:

> Why do we need defsystems at all in order to distribute a
> library?

a defsystem alone is not enough to make a qualitative difference, of
course.  you also need a packaging/installing mechanism and a
dependency-chasing mechanism on top of it.

at which point the difference to the person distributing a library is
still not very big, but the difference to the person _installing_ the
library is enormous.  if you want a library to be widely used, ease
of installation is much more important than ease of packaging.

I must not be seeing your point,
--m

-- 
I am not a Church numeral!
I am a free variable!
From: Thomas F. Burdick
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <xcvlloznpou.fsf@famine.OCF.Berkeley.EDU>
Eladio <··············@yahoo.com> writes:

> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> 
> > FWIW, it's waaaaay easier to find and install things now than it was
> > in the late 90's.  And the situation's still improving.
> 
> Yeah, that's the open source movement for you. Stuff that broke your teeth 3
> months ago suddenly fly by wire. But it's still frustrating while it goes
> on. *sigh*
> 
> > I'd recommend that you get SBCL.  Dan Barlow replaced his old guide to
> > getting started on CMUCL with a new one for SBCL:
> > 
> >   http://ww.telent.net/lisp/according_to/
> 
> Wonderful! I've been on #lisp all day, and go the same advice. It still gives
> me heaps of trouble since asdf-install doesn't seem to be installed by default
> on FreeBSD, but I'm working on it.

Where did you get your SBCL distribution?  I have no idea what's in
ports (I haven't used FreeBSD in a long time), but if you're using
that, try switching to a recent binary from the SBCL website
(sbcl.sf.net).  Either you're using an old SBCL, or something's
broken, in which case it's a bug.

> I have yet to find anything remotely ressembling a manual for asdf,

[ The "README" file is actually decent documentation ]

> let alone
> instructions for actually *fixing* the problems you encounter. So I'm supposed
> to type:
> 
> (require 'asdf)
> (require 'asdf-install)
> (asdf-install 'cliki)  ; or whatever
> 
> Okay. Peace of cake. But clisp, cmucl, and sbcl ALL break down at step one,

Only SBCL ships with ASDF, so that's the only one where this would
work.  When you run into problems like this, don't write long messages
about how you Love Love Love Lisp and it would be Great If This Worked
-- instead, report it as a bug, giving details (software versions,
instructions to reproduce, etc) -- nothing exactly wrong with the
former, but the latter is more helpful :).  In this case, after making
sure you're running the latest SBCL, report this as a bug to sbcl-help
at lists dot sourceforge dot net.

As for CLISP and CMUCL, you can get ASDF for them, just download the
asdf.lisp file, and load it:

  (load "/path/to/asdf.lisp")

It's kind of the Lisp answer to "make".

> > Go to CLiki.  Type "hemlock" in the search.  Click on the third link,
> > GettingStartedWithHemlock.
> 
> Success! Success at last!!! Thank you *so* much! I get the feeling I'll spend
> the whole day tomorrow on cliki, hehehe! Finally a little victory to round off
> the day. Sorry for the verboseness of this post, by the by - and merry
> Christmas!

(Oh good -- and if you have *any* problems with it, lemme know, so I
can fix it for future newbies).

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Eladio
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <2qisk2pkvl.fsf@Cagafuego.opasia.dk>
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> Where did you get your SBCL distribution?  I have no idea what's in
> ports (I haven't used FreeBSD in a long time), but if you're using
> that, try switching to a recent binary from the SBCL website
> (sbcl.sf.net).  Either you're using an old SBCL, or something's
> broken, in which case it's a bug.

Argh! Why didn't I think of that?! I'll try this baby one last time, or it's
goodbye FreeBSD, hello Gentoo.

The sbcl is found in /usr/ports/lang/sbcl, and there're various other ports for
it too. Just use a "locate" & "grep" combo. They're all called 
"-sbcl"-something. 

> Only SBCL ships with ASDF, so that's the only one where this would
> work.  When you run into problems like this, don't write long messages
> about how you Love Love Love Lisp and it would be Great If This Worked
> -- instead, report it as a bug, giving details (software versions,
> instructions to reproduce, etc) -- nothing exactly wrong with the
> former, but the latter is more helpful :).

I know, and I apologize. I was in rant-mode after a long, long day.

> In this case, after making sure you're running the latest SBCL, report this 
> as a bug to sbcl-help at lists dot sourceforge dot net.

Will do.

> As for CLISP and CMUCL, you can get ASDF for them, just download the
> asdf.lisp file, and load it:
> 
>   (load "/path/to/asdf.lisp")
> 
> It's kind of the Lisp answer to "make".

Way ahead of you. Asdf is a port in FreeBSD, and there's even binaries for all 
3 free lisps. It loads just dandy, there's just no asdf-install in sight.

> (Oh good -- and if you have *any* problems with it, lemme know, so I
> can fix it for future newbies).

Count on me! (Actually, the intel was right there, I just had to poke around in
the right spots, as you saw)
-- 
From: Christophe Rhodes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <sqr7yqh4ws.fsf@lambda.jcn.srcf.net>
Eladio <··············@yahoo.com> writes:

> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
>> In this case, after making sure you're running the latest SBCL, report this 
>> as a bug to sbcl-help at lists dot sourceforge dot net.
>
> Will do.

Actually, and I hate to bounce you around (so please do report it to
sbcl-help, as well), I think this is better described as a FreeBSD
packaging bug.  For reasons unknown to me, I believe the FreeBSD port
of sbcl chops out the "contrib" section, containing tools best
described as "userspace" -- including asdf and asdf-install, but also
other handy utilities (not to mention a socket interface!)

If my recollection on this is correct, it would probably also be worth
taking this up with the FreeBSD port maintainer (and logging this
issue with the FreeBSD bug tracking mechanism).

I hope that this isn't too far off the mark, and that it clears up
some of the confusion.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Eladio
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <qpekuqpdq2.fsf@Cagafuego.opasia.dk>
Christophe Rhodes <·····@cam.ac.uk> writes:

> > ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >
> >> In this case, after making sure you're running the latest SBCL, report this 
> >> as a bug to sbcl-help at lists dot sourceforge dot net.

> > Will do.
> 
> Actually, and I hate to bounce you around (so please do report it to
> sbcl-help, as well), I think this is better described as a FreeBSD
> packaging bug.  For reasons unknown to me, I believe the FreeBSD port
> of sbcl chops out the "contrib" section, containing tools best
> described as "userspace" -- including asdf and asdf-install, but also
> other handy utilities (not to mention a socket interface!)

That's right on the money. Asdf is installed via a separate port, either as 
a source-package ("cl-asdf"), or as binaries for individual lisps, such as
"cl-asdf-sbcl". The problem seems to be that the maintainer didn't include the
contrib stuff in either of them. Sockets and the like are found in a separate
package, "cl-port", which successfully installs the following:

ls /usr/local/lib/common-lisp/port
drwxr-xr-x  2 root  wheel    512 Dec 23 11:19 clispfasl
drwxr-xr-x  2 root  wheel    512 Dec 23 11:20 cmuclfasl
-r--r--r--  1 root  wheel   8181 Dec 20 20:07 ext.lisp
-r--r--r--  1 root  wheel   1811 Dec 20 20:07 gray.lisp
-r--r--r--  1 root  wheel  22958 Dec 20 20:07 net.lisp
-r--r--r--  1 root  wheel   5920 Dec 20 20:07 path.lisp
-r--r--r--  1 root  wheel    783 Dec 20 20:07 port.asd
-r--r--r--  1 root  wheel    705 Dec 20 20:07 port.system
-r--r--r--  1 root  wheel  16720 Dec 20 20:07 proc.lisp
drwxr-xr-x  2 root  wheel    512 Dec 24 16:36 sbclfasl
-r--r--r--  1 root  wheel   4447 Dec 20 20:07 shell.lisp
-r--r--r--  1 root  wheel  13728 Dec 20 20:07 sys.lisp

So there's no real "bugs" per se, because all this loads beautifully in all 
the lisps. The only problem is merely that asdf-install doesn't seem to be 
included in the sbcl/asdf installations on FreeBSD so we don't get convenience, 
for now. And no matter how I try to set up asdf-install manually, I just can't 
get it to work, because I'm too unfamiliar with asdf, defsystem, lisp and all
that jazz.

And frankly, right now I'm getting to the point where I can't even eat with 
knife and fork with screwing up, so I'm calling it quits for this time - at 
least on FreeBSD. I'm simply burned out. I'm switching over to either Gentoo or
Debian tonight. I was *floored* when I saw the number of lisp packages they 
have available out of the box. FreeBSD has 5 or 6! But hey, that'll come in
time.

> If my recollection on this is correct, it would probably also be worth
> taking this up with the FreeBSD port maintainer (and logging this
> issue with the FreeBSD bug tracking mechanism).

That's the very last thing I'll do tonight before I crash the machine.

> I hope that this isn't too far off the mark, and that it clears up
> some of the confusion.

Yes, absolutely. It jives completely with my own conclusions. Had
asdf-install been included in sbcl on my system, I could have followed the
laundry-lists on cliki and elsewhere, type (require whatever) and downloaded 
libraries to my heart's content, and I wouldn't have vented to the newsgroup 
about my frustrations in the first place.

But thanks for the assistence all around! It's clear to me that the lisp
community is more than willing to take hand of newbies and make them feel
welcome, and I look so much forward to hack the living daylights out of your 
libraries, ha ha!

C-ya! 
-- 
From: Edi Weitz
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87fzf6hzfm.fsf@bird.agharta.de>
On 27 Dec 2003 13:55:17 +0000, Eladio <··············@yahoo.com> wrote:

> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> Actually, and I hate to bounce you around (so please do report it
>> to sbcl-help, as well), I think this is better described as a
>> FreeBSD packaging bug.  For reasons unknown to me, I believe the
>> FreeBSD port of sbcl chops out the "contrib" section, containing
>> tools best described as "userspace" -- including asdf and
>> asdf-install, but also other handy utilities (not to mention a
>> socket interface!)
>
> That's right on the money. Asdf is installed via a separate port,
> either as a source-package ("cl-asdf"), or as binaries for
> individual lisps, such as "cl-asdf-sbcl". The problem seems to be
> that the maintainer didn't include the contrib stuff in either of
> them. Sockets and the like are found in a separate package,
> "cl-port", which successfully installs the following:
>
> ls /usr/local/lib/common-lisp/port
> drwxr-xr-x  2 root  wheel    512 Dec 23 11:19 clispfasl
> drwxr-xr-x  2 root  wheel    512 Dec 23 11:20 cmuclfasl
> -r--r--r--  1 root  wheel   8181 Dec 20 20:07 ext.lisp
> -r--r--r--  1 root  wheel   1811 Dec 20 20:07 gray.lisp
> -r--r--r--  1 root  wheel  22958 Dec 20 20:07 net.lisp
> -r--r--r--  1 root  wheel   5920 Dec 20 20:07 path.lisp
> -r--r--r--  1 root  wheel    783 Dec 20 20:07 port.asd
> -r--r--r--  1 root  wheel    705 Dec 20 20:07 port.system
> -r--r--r--  1 root  wheel  16720 Dec 20 20:07 proc.lisp
> drwxr-xr-x  2 root  wheel    512 Dec 24 16:36 sbclfasl
> -r--r--r--  1 root  wheel   4447 Dec 20 20:07 shell.lisp
> -r--r--r--  1 root  wheel  13728 Dec 20 20:07 sys.lisp

From the names I'd guess that these are from CLOCC, not from the
contrib directory of SBCL.

Edi.
From: Paolo Amoroso
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ad5ivw9z.fsf@plato.moon.paoloamoroso.it>
Eladio writes:

> I'm a newbie - rank amateur all the way, but grossly infected with the
> lisp-bug, and I definitely echo the sentiment that the free-lisp environment
> needs to be more easily accessible. It's not a question of dumbing it down for
> the masses, but simply of making it user-friendly. My time is precious, and
> frankly I'd rather crank out code than wasting hours just trying to install a
> half-assed getopt-library.

I understand yours and Christopher's frustration. But I think that the
explanation of why Lisp may currently be hard to use is very simple,
and you have hinted at it: the developers' time is precious as well.

There's no deliberate plan by the developers to hide information to
novices. It's just that there is not enough volunteer labor.

The bottom line is that things are improving in the Lisp world, even
in library packaging, but not as fast as in other language
communities.


> How hard can it be to create a package management tool that downloads wanted
> items plus dependencies, compiles the whole nine yards and dumps them in the
> right directories and insert the appropriate lines in the config files if need
> be? On FreeBSD, the basic CLOCC bundle is actually available in the port

I suspect it's not trivial.


>    cooler your resume is than mine. I want to know how to find my
>    way. Something like a Starter's Guide would be nice: read this, and this
>    and this in that order, create some projects, then install this gizmo and
>    learn about defsystem through this excellent tutorial. This presupposed the
>    existence of the above, of course.

A few starting points for understanding the Lisp equivalent of Unix
`make', i.e. DEFSYSTEM tools (Google if necessary). Read:

- Kent Pitman's article "The Description of Large Systems", available
  at his web site
- the manual of Mark Kantrowitz's MK:DEFSYSTEM tool, included in CLOCC
- the README file of Dan Barlow's `asdf' tool


> Oh - and how do you start Hemlock?! Thanks for your consideration.

Evaluate these expressions at the CMUCL prompt:

  (require :clx)
  (require :hemlock)
  (ed)

The Hemlock manual, available at the CMUCL site in the documentation
section, provides more details. Also check the Hemlock page at CLiki.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Pascal Bourguignon
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87vfo5ehho.fsf@thalassa.informatimago.com>
Paolo Amoroso <·······@mclink.it> writes:
> > Oh - and how do you start Hemlock?! Thanks for your consideration.
> 
> Evaluate these expressions at the CMUCL prompt:
> 
>   (require :clx)
>   (require :hemlock)
>   (ed)
> 
> The Hemlock manual, available at the CMUCL site in the documentation
> section, provides more details. Also check the Hemlock page at CLiki.

[······@thalassa pascal]$ cmucl
; Loading #p"/local/users/pascal/.cmucl-init.lisp".
CMU Common Lisp 18d, running on thalassa
Send questions to ··········@cons.org. and bug reports to ·········@cons.org.
Loaded subsystems:
    Python 1.0, target Intel x86
    CLOS based on PCL version:  September 16 92 PCL (f)
* (require :clx)

; Loading #p"/local/languages/cmucl/lib/cmucl/lib/subsystems/clx-library.x86f".
[GC threshold exceeded with 2,005,376 bytes in use.  Commencing GC.]
[...]
[GC will next occur when at least 4,855,200 bytes are in use.]
T                                                                                                                                                        
* (require :hemlock)

; Loading #p"/local/languages/cmucl/lib/cmucl/lib/subsystems/hemlock-library.x86f".
[GC threshold exceeded with 4,855,496 bytes in use.  Commencing GC.]
[...]
[GC will next occur when at least 8,693,592 bytes are in use.]
T
* (ed)

Parse error in namestring: Expecting a file name, got #\..
  home:.hemlock-init
       ^

Restarts:
  0: [CONTINUE] Return NIL from load of "home:.hemlock-init".
  1: [ABORT   ] Return to Top-Level.

Debug  (type H for help)

(COMMON-LISP::EXPECTING "a file name" ((#\. . 5) ("HEMLOCK-INIT" . 6)))
Source: 
; File: target:code/pathname.lisp

; File has been modified since compilation:
;   target:code/pathname.lisp
; Using form offset instead of character position.
(ERROR 'NAMESTRING-PARSE-ERROR
       :COMPLAINT
       "Expecting ~A, got ~:[nothing~;~:*~S~]."
       :ARGUMENTS
       ...)
0] 



-- 
__Pascal_Bourguignon__                              .  *   * . * .* .
http://www.informatimago.com/                        .   *   .   .*
There is no worse tyranny than to force             * .  . /\  (   . *
a man to pay for what he does not                    . .  / .\   . * .
want merely because you think it                    .*.  / *  \  . .
would be good for him. -- Robert Heinlein             . /*   o \     .
http://www.theadvocates.org/                        *   '''||'''   .
SCO Spam-magnet: ··········@sco.com                 ******************
From: Friedrich Dominicus
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87wu8lmnev.fsf@fbigm.here>
Pascal Bourguignon <····@thalassa.informatimago.com> writes:

> Parse error in namestring: Expecting a file name, got #\..
>   home:.hemlock-init
>        ^

Yeah, I posted about this a few days ago. CMUL can not handle a dot in
logical-pathnames. I tried to find a way to report this but just found
the mailings lists.... 

touch $HOME/hemlock-init

will help you go over this hurdle.

This thing in which I agree with you is that many of the available
packages are difficult to install, and that they are often lacking
documentation. On the other hand using the right "Distribution"
(Debian of course) helps quite a bit ;-) 

Regards
Friedrich
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <w4cekutxrk4.fsf@haddock.cd.chalmers.se>
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> 
> > Parse error in namestring: Expecting a file name, got #\..
> >   home:.hemlock-init
> >        ^
> 
> Yeah, I posted about this a few days ago. CMUL can not handle a dot in
> logical-pathnames. I tried to find a way to report this but just found
> the mailings lists.... 

But "home:.hemlock-init" isn't a logical pathname in CMUCL, unless
you've defined a logical host called "HOME". "home:" is a search
list.

Regards,

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_
From: Friedrich Dominicus
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87llp1mh9a.fsf@fbigm.here>
rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:

> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>> 
>> > Parse error in namestring: Expecting a file name, got #\..
>> >   home:.hemlock-init
>> >        ^
>> 
>> Yeah, I posted about this a few days ago. CMUL can not handle a dot in
>> logical-pathnames. I tried to find a way to report this but just found
>> the mailings lists.... 
>
> But "home:.hemlock-init" isn't a logical pathname in CMUCL, unless
> you've defined a logical host called "HOME". "home:" is a search
> list.
I've such a logical-host defined. And there I had this problem with
the . in it. 

(translate-logical-pathname "home:t1.txt")
#p"/home/frido/t1.txt"
CL-USER> 
but
CL-USER> (translate-logical-pathname "home:.t1.txt")
Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER:  the variable CL-USER> is unbound.
   [Condition of type UNBOUND-VARIABLE]

Backtrace
0: (EVAL CL-USER>)
1: (SWANK::EVAL-REGION "(translate-logical-pathname \"home:t1.txt\")
#p\"/home/frido/t1.txt\"
CL-USER> (translate-logical-pathname \"home:.t1.txt\")" T)
2: (SWANK::EVAL-REGION 2 "(translate-logical-pathname \"home:t1.txt\")
#p\"/home/frido/t1.txt\"
CL-USER> (translate-logical-pathname \"home:.t1.txt\")" T)[:EXTERNAL]
3: (SWANK:LISTENER-EVAL "(translate-logical-pathname \"home:t1.txt\")
#p\"/home/frido/t1.txt\"
CL-USER> (translate-logical-pathname \"home:.t1.txt\")")  0: [ABORT] Return to Slime toplevel.


So why is this error message there?

Regards
Friedrich
From: Friedrich Dominicus
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ad5hmfut.fsf@fbigm.here>
Friedrich Dominicus <·····@q-software-solutions.com> writes:

> rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
>
>> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>>> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>>> 
>>> > Parse error in namestring: Expecting a file name, got #\..
>>> >   home:.hemlock-init
>>> >        ^
>>> 
>>> Yeah, I posted about this a few days ago. CMUL can not handle a dot in
>>> logical-pathnames. I tried to find a way to report this but just found
>>> the mailings lists.... 
>>
>> But "home:.hemlock-init" isn't a logical pathname in CMUCL, unless
>> you've defined a logical host called "HOME". "home:" is a search
>> list.

Oh, well that is even worse. The same structure as an logical-pathname
is used in another way. How should a Lisp beginner know?


See below I messed up some stuff.

I've such a logical-host defined. And there I had this problem with
the . in it. 
CL-USER> (setf (logical-pathname-translations "test")
               '(("**;*.*" "/tmp/**/*.*")))
(("**;*.*" "/tmp/**/*.*"))
CL-USER> (translate-logical-pathname "test:t1.txt")
#p"/tmp/t1.txt"
CL-USER> (translate-logical-pathname "test:.t1.txt")
Parse error in namestring: Expecting a file name, got #\..
  test:.t1.txt
       ^
   [Condition of type COMMON-LISP::NAMESTRING-PARSE-ERROR]

Restarts:
  0: [ABORT] Return to Slime toplevel.
  1: [ABORT] Return to Top-Level.

Backtrace:
0: (COMMON-LISP::EXPECTING "a file name" ((#\. . 5) ("T1" . 6) (#\. . 8) ("TXT" . 9)))
1: (COMMON-LISP::PARSE-DIRECTORY ((#\. . 5) ("T1" . 6) (#\. . 8) ("TXT" . 9)))
2: (COMMON-LISP::PARSE-LOGICAL-NAMESTRING "test:.t1.txt" 0 12)
3: (COMMON-LISP::%PARSE-NAMESTRING "test:.t1.txt" NIL #p"" 0 ...)
4: (COMMON-LISP::%PARSE-NAMESTRING 6 "test:.t1.txt" NIL #p"" ...)[:EXTERNAL]
5: (PATHNAME "test:.t1.txt")
6: (TRANSLATE-LOGICAL-PATHNAME "test:.t1.txt")

But know that I know that this Search List exists (I did not even
thought that one could overload the meaning of logical-pathnames,
things get even worse now I can do 
a 
(ed "home:.cint_hist")

and hemlock shows me the proper field but doing a 

(ed "test:.t1.txt") yields an error 

Well I do not know how you think about it, but for me that is an
extremly poor interface.


Regards
Friedrich
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <w4c3cb3ivwf.fsf@boris.cd.chalmers.se>
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
> > rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
> >>> Yeah, I posted about this a few days ago. CMUL can not handle a dot in
> >>> logical-pathnames. I tried to find a way to report this but just found
> >>> the mailings lists.... 
> >>
> >> But "home:.hemlock-init" isn't a logical pathname in CMUCL, unless
> >> you've defined a logical host called "HOME". "home:" is a search
> >> list.
> 
> Oh, well that is even worse. The same structure as an logical-pathname
> is used in another way. How should a Lisp beginner know?

By taking a look in the documentation for the implementation. Search
lists, and the standard search lists, are described in the second
chapter, _Design Choices and Extensions_. (It isn't the same structure
as logical pathnames, by the way.)

<snip>

> But know that I know that this Search List exists (I did not even
> thought that one could overload the meaning of logical-pathnames,
> things get even worse now I can do 
> a 
> (ed "home:.cint_hist")
> 
> and hemlock shows me the proper field but doing a 
> 
> (ed "test:.t1.txt") yields an error 

Yes. Without reading the spec for LPN:s, I can't really say whether
it's standards-conformant, though I suspect it might be. It sure is
inconvenient, though.

> Well I do not know how you think about it, but for me that is an
> extremly poor interface.

No, it isn't, IMO. It might be just your understanding of your chosen
CL implementation that could be described that way.

Regards,

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_
From: Friedrich Dominicus
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87y8svvg9t.fsf@fbigm.here>
rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:

>> 
>> Oh, well that is even worse. The same structure as an logical-pathname
>> is used in another way. How should a Lisp beginner know?
>
> By taking a look in the documentation for the implementation. Search
> lists, and the standard search lists, are described in the second
> chapter, _Design Choices and Extensions_. (It isn't the same structure
> as logical pathnames, by the way.)
After you told me I found it. But the interface is the same. That is
poor style by whatever means how would you decide if
home:somewhat
home:somewhat 

is  a logical pathname or not? You can't, and even if you know once it
must not hold in another try, maybe you have set up a logical pathname
on "home"

> Yes. Without reading the spec for LPN:s, I can't really say whether
> it's standards-conformant, though I suspect it might be. It sure is
> inconvenient, though.
Well you suspect something, so did I. For me the search list looks
like a logical pathname and in fact I can use the same for both. But
if I have a logical pathname than a "." breaks it.

And as I posted LisWorks, SBCL do accept a "." in logical
pathnames. That does not mean of course that those are right but I
can't see anythin in the hyperspect telling me not to use a dot.



>
>> Well I do not know how you think about it, but for me that is an
>> extremly poor interface.
>
> No, it isn't, IMO. 
Yes it is it overloads a standard interface, with unstandard
behaviour. 

Regards
Friedrich
From: Raymond Toy
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <4ny8svy51e.fsf@edgedsp4.rtp.ericsson.se>
>>>>> "Friedrich" == Friedrich Dominicus <·····@q-software-solutions.com> writes:

    Friedrich> rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
    >>> 
    >>> Oh, well that is even worse. The same structure as an logical-pathname
    >>> is used in another way. How should a Lisp beginner know?
    >> 
    >> By taking a look in the documentation for the implementation. Search
    >> lists, and the standard search lists, are described in the second
    >> chapter, _Design Choices and Extensions_. (It isn't the same structure
    >> as logical pathnames, by the way.)
    Friedrich> After you told me I found it. But the interface is the same. That is
    Friedrich> poor style by whatever means how would you decide if
    Friedrich> home:somewhat
    Friedrich> home:somewhat 

[snip]

    >> 
    >>> Well I do not know how you think about it, but for me that is an
    >>> extremly poor interface.
    >> 
    >> No, it isn't, IMO. 
    Friedrich> Yes it is it overloads a standard interface, with unstandard
    Friedrich> behaviour. 

I suspect, but do not know for sure, that CMUCL's search-lists predate
ANSI CL's logical pathnames.  

Ray
From: Christophe Rhodes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <sq7k0fekli.fsf@lambda.jcn.srcf.net>
Friedrich Dominicus <·····@q-software-solutions.com> writes:

> rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
>
>>> 
>>> Oh, well that is even worse. The same structure as an logical-pathname
>>> is used in another way. How should a Lisp beginner know?
>>
>> By taking a look in the documentation for the implementation. Search
>> lists, and the standard search lists, are described in the second
>> chapter, _Design Choices and Extensions_. (It isn't the same structure
>> as logical pathnames, by the way.)
> After you told me I found it. But the interface is the same. That is
> poor style by whatever means how would you decide if
> home:somewhat
> home:somewhat 
>
> is  a logical pathname or not? You can't, and even if you know once it
> must not hold in another try, maybe you have set up a logical pathname
> on "home"

home:somewhat cannot be a Logical Pathname, because it contains
lowercase letters in its namestring.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <w4cy8svhazp.fsf@boris.cd.chalmers.se>
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
> > By taking a look in the documentation for the implementation. Search
> > lists, and the standard search lists, are described in the second
> > chapter, _Design Choices and Extensions_. (It isn't the same structure
> > as logical pathnames, by the way.)
> After you told me I found it. But the interface is the same. That is
> poor style by whatever means how would you decide if
> home:somewhat
> home:somewhat 
> 
> is  a logical pathname or not? You can't, and even if you know once it
> must not hold in another try, maybe you have set up a logical pathname
> on "home"

Right. You can't, by just looking at it. (And no, the interface isn't
the same; the namestrings, however, are.)

You can, by LOGICAL-PATHNAME-TRANSLATIONS and EXT:SEARCH-LIST-DEFINED-P.

> > Yes. Without reading the spec for LPN:s, I can't really say whether
> > it's standards-conformant, though I suspect it might be. It sure is
> > inconvenient, though.

> Well you suspect something, so did I. For me the search list looks
> like a logical pathname and in fact I can use the same for both. But
> if I have a logical pathname than a "." breaks it.

Ok. I checked up on my suspicion. It was, indeed, correct. (As I
suspected, since my suspicion was based on half-remembered reading,
not guesswork.)

The name part of a logical pathname is a /word/. A word consists of
one or more uppercase letters, digits and hyphens. Zero of those is
not specified, nor is #\. a constituent. It can't be the null string,
per 19.3.2.2, and it can't be :unspecific per 19.3.2.1.

> And as I posted LisWorks, SBCL do accept a "." in logical
> pathnames. That does not mean of course that those are right but I
> can't see anythin in the hyperspect telling me not to use a dot.

19.3.1, plus the pages referenced above.

Of course, I may very well be misreading/-understanding.

Regards,

'mr

-- 
[Emacs] is written in Lisp, which is the only computer language that is
beautiful.  -- Neal Stephenson, _In the Beginning was the Command Line_
From: Friedrich Dominicus
Subject: logical pathnames was: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ad5b1r31.fsf_-_@fbigm.here>
rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:

> Right. You can't, by just looking at it. (And no, the interface isn't
> the same; the namestrings, however, are.)
The external visible user interface is the same. 
>
> You can, by LOGICAL-PATHNAME-TRANSLATIONS and
> EXT:SEARCH-LIST-DEFINED-P.
Ok that's an argument.

> Ok. I checked up on my suspicion. It was, indeed, correct. (As I
> suspected, since my suspicion was based on half-remembered reading,
> not guesswork.)
>
> The name part of a logical pathname is a /word/. A word consists of
> one or more uppercase letters, digits and hyphens. Zero of those is
> not specified, nor is #\. a constituent. It can't be the null string,
> per 19.3.2.2, and it can't be :unspecific per 19.3.2.1.
you are right and now we come to the next grey area. 

This is what I tried in CMUCL, SBCL, CLisp, LispWorks
(setf (logical-pathname-translations "tmp")
                  '(("**;*.*" "/tmp/**/*.*")))  

(("**;*.*" "/tmp/**/*.*"))
CL-USER> (translate-logical-pathname "tmp:t1")
#p"/tmp/t1"

all gave the same result !

So by taking the hyperpec is this now unspecified behaviour or is it
an error? Should it be flaged as such?


Regards
Friedrich
From: Pascal Bourguignon
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87vfnzb79m.fsf@thalassa.informatimago.com>
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> And as I posted LisWorks, SBCL do accept a "." in logical
> pathnames. That does not mean of course that those are right but I
> can't see anythin in the hyperspect telling me not to use a dot.


http://www.lispworks.com/reference/HyperSpec/Body/19_ca.htm
    19.3.1 Syntax of Logical Pathname Namestrings

    logical-pathname::= [host host-marker]  
                        [relative-directory-marker] {directory directory-marker}*
                        [name] [type-marker type [version-marker version]] 

    name::= word | wildcard-word

    wildcard-word---one or more asterisks, uppercase letters, digits, and
    hyphens, including at least one asterisk, with no two asterisks
    adjacent.

    word---one or more uppercase letters, digits, and hyphens.


However,

    19.3.1.1.8 Other Syntax in a Logical Pathname Namestring

    The consequences of using characters other than those specified here
    in a logical pathname namestring are unspecified.

and:

    The consequences are unspecified

    This means that the consequences are unpredictable but
    harmless. Implementations are permitted to specify the
    consequences of this situation. No conforming code may depend on
    the results or effects of this situation, and all conforming code
    is required to treat the results and effects of this situation as
    unpredictable but harmless. 

so an implementation is free to specify the consequence of using a dot
in the name part of a logical pathname.

Which is of NO help,  since any other implementation of Common-Lisp on
unix may diverge. Or said otherwise, a "conforming" program cannot use
this possibility.



Now, let's hope 2004 will see  the creation of a subcomitee to SPECIFY
what  happens when  you use  dots in  in the  name part  of  a logical
pathname  on  Common-Lisp implementations  running  on  unix or  POSIX
systems  (and  other Common-Lisp  on  unix  matters).  (Microsoft  and
Corman can participate in another  subcomitee on what should happen on
Common-Lisp on MS-Windows implementations).


Then at least a "conforming" program could use:

     #+unix "H:D;I;R;.NAME.TYPE" #+ms-windows "H:D;I;R;_NAME.TYP"



-- 
__Pascal_Bourguignon__                              .  *   * . * .* .
http://www.informatimago.com/                        .   *   .   .*
There is no worse tyranny than to force             * .  . /\      . *
a man to pay for what he does not                    . .  / .\   . * .
want merely because you think it                    .*.  / *  \  . .
would be good for him. -- Robert Heinlein             . /*   o \     .
http://www.theadvocates.org/                        *   '''||'''   .
SCO Spam-magnet: ··········@sco.com                 ******************
From: Eladio
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <p9isk5m2vw.fsf@Cagafuego.opasia.dk>
Paolo Amoroso <·······@mclink.it> writes:

> A few starting points for understanding the Lisp equivalent of Unix
> `make', i.e. DEFSYSTEM tools (Google if necessary). Read:
> 
> - Kent Pitman's article "The Description of Large Systems", available
>   at his web site
> - the manual of Mark Kantrowitz's MK:DEFSYSTEM tool, included in CLOCC
> - the README file of Dan Barlow's `asdf' tool

Beautiful - I'll sink my teeth into those right off the bat!

> > Oh - and how do you start Hemlock?! Thanks for your consideration.
> 
> Evaluate these expressions at the CMUCL prompt:
> 
>   (require :clx)
>   (require :hemlock)
>   (ed)
> 
> The Hemlock manual, available at the CMUCL site in the documentation
> section, provides more details. Also check the Hemlock page at CLiki.

I'm all over it! Thank you so much for taking the time with this.
-- 
"Thinking gives you wrinkles!" - Malibu Stacy, the Simpsons.
From: Paolo Amoroso
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ekurg9n4.fsf@plato.moon.paoloamoroso.it>
Eladio writes:

> Paolo Amoroso <·······@mclink.it> writes:
>
>> A few starting points for understanding the Lisp equivalent of Unix
>> `make', i.e. DEFSYSTEM tools (Google if necessary). Read:
>> 
>> - Kent Pitman's article "The Description of Large Systems", available
>>   at his web site
>> - the manual of Mark Kantrowitz's MK:DEFSYSTEM tool, included in CLOCC
>> - the README file of Dan Barlow's `asdf' tool
>
> Beautiful - I'll sink my teeth into those right off the bat!

A few additional resources accessible from CLiki:

  Practical Lisp Programming
  http://www.cliki.net/Practical%20Lisp%20Programming

  Fight the System
  Installing and Using Common Lisp Libraries
  http://www.henrik-motakef.de/defsystem.html

The latter looks like what you were looking for, and is accessible
from the former. Have (de)fun,


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: james anderson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FEC29D2.4F99DF7A@setf.de>
Paolo Amoroso wrote:
> 
> ...
> 
> A few additional resources accessible from CLiki:
> 
>   Practical Lisp Programming
>   http://www.cliki.net/Practical%20Lisp%20Programming
> 
>   Fight the System
>   Installing and Using Common Lisp Libraries
>   http://www.henrik-motakef.de/defsystem.html
> 

as informative as this latter may be, it is both ironic and typical that much
of it is expressed in terms of physical pathnames and logical pathnames end up
in a footnote.

...
From: Paolo Amoroso
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87r7yrsag6.fsf@plato.moon.paoloamoroso.it>
James Anderson writes:

> as informative as this latter may be, it is both ironic and typical that much
> of it is expressed in terms of physical pathnames and logical pathnames end up
> in a footnote.

If you put it this way, the glass is indeed half-empty. But if you
consider Eladio's original request of learning what a DEFSYSTEM tool
is in the first place, the glass may look half-full.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Tayssir John Gabbour
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <866764be.0312242321.204adcda@posting.google.com>
>  * Basic tutorials. "Packages For Dummies" was unnecessarily complex. As a
>    newbie, I haven't yet wrapped my head around the concepts of symbols, so
>    puh-lease don't lecture me about it. You waste your time. What I want is
>    simple boilerplates showing me the rudiments, like a sample defpackage I
>    can just cut-and-paste and pluck in my own functions. That's MORE than
>    enough, and if I want more, I can always jump into the HyperSpec, or ask on
>    #lisp for the skinny.

Cltl2 has a good, short section on symbols.  Also check this out:
http://www.cliki.net/Online%20Tutorial
as well as Peter Seibel's book in progress.

I learned that people really weren't kidding when they say Cltl2
diverges from the standard a bit, but it's often more clear than other
sources.

CL is among the best languages in terms of documentation, especially
when you note that the language is simple/extensible enough that you
can cover a great amount of ground fast.

Sadly enough, using Emacs/CLisp on Windows:
- my Emacs doesn't support labels/flet.  When I attempt to trivially
use them, it complains of stack overflow.  This does not reproduce on
Unix.
- ILisp won't install, though perhaps I didn't try particularly hard.

So it's a crazy life.  The problem is, with Free Software, the
consumer must meet the producer half way and provide incentives for
further work.  I read this thread as asking producers for almost pure
altruism, and it's not clear what the results will be.

Companies like O'Reilly have attempted to fix this problem, but AFAIK
they've failed.  If Fred Brooks is right, packaging software to be
simple to use is much more work than simply banging out reasonably
robust code, so this problem is deeper than some may think.  This is
pretty much the reason why commercial developers don't have to commit
suicide in fear of Free Software, unless their hyperspecialized niche
was demolished.

Fortunately, there is little I ask from CL.  As far as interacting
with the system, I simply need I/O to disk for sexprs and text files. 
As far as installing utils, I simply read the lib, and either
cut&paste or rewrite the code.  I have too many important interests to
deal with someone's ghetto install system. ;)
From: Pascal Bourguignon
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87r7yre750.fsf@thalassa.informatimago.com>
···········@yahoo.com (Tayssir John Gabbour) writes:
> So it's a crazy life.  The problem is, with Free Software, the
> consumer must meet the producer half way and provide incentives for
> further work.  I read this thread as asking producers for almost pure
> altruism, and it's not clear what the results will be.

I can assure  you that you will meet the  Free Software producers with
at least as much altruism, if not a thousandfold more, as, for example
Microsoft, if  you, as  with Microsoft, start  to send them  your VISA
number to get support and  to motivate improvements.  In addition, you
have  the  freedom  to  contract  the services  of  your  favorite  IT
professionnal to  make modification to free software,  which you don't
have and can't do with closed proprietary software...
 

> Companies like O'Reilly have attempted to fix this problem, but AFAIK
> they've failed.  If Fred Brooks is right, packaging software to be
> simple to use is much more work than simply banging out reasonably
> robust code, so this problem is deeper than some may think. 

Indeed.


> This is
> pretty much the reason why commercial developers don't have to commit
> suicide in fear of Free Software, unless their hyperspecialized niche
> was demolished.
> 
> Fortunately, there is little I ask from CL.  As far as interacting
> with the system, I simply need I/O to disk for sexprs and text files. 
> As far as installing utils, I simply read the lib, and either
> cut&paste or rewrite the code.  I have too many important interests to
> deal with someone's ghetto install system. ;)



-- 
__Pascal_Bourguignon__                              .  *   * . * .* .
http://www.informatimago.com/                        .   *   .   .*
There is no worse tyranny than to force             * .  . /\  (   . *
a man to pay for what he does not                    . .  / .\   . * .
want merely because you think it                    .*.  / *  \  . .
would be good for him. -- Robert Heinlein             . /*   o \     .
http://www.theadvocates.org/                        *   '''||'''   .
SCO Spam-magnet: ··········@sco.com                 ******************
From: Christophe Rhodes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <sqisk62x45.fsf@lambda.jcn.srcf.net>
······@news.dtpq.com (Christopher C. Stacy) writes:

> I would like to relate the following comments and suggestions to the
> kind people who maintain the various downloadable libraries for Common
> Lisp, particularly those aimed at the CLISP/CMUCL/SBCL users.
                                                    ^^^^

(I'm replying essentially from the perspective of an SBCL implementor;
I understand that you're talking about libraries, but you also
mentioned that the transitive utility would lead you to not be able to
recommend use of free systems, so it affects we implementors as well.)

> 2.  Your software is TOO HARD to download and use.

This is to an extent true.  There are certainly certain spots of the
package space which baffle me, and I know I'm not alone.  However...

> Today I've been trying for several hours to figure out how to 
> get CLOCC and use it on my RedHat Linux machine with CLISP.  

... to a certain extent I wonder how much you are suffering from this
particular effort, and extrapolating to the generality.

> It is simply too overwhelming to figure out how to download 
> and install any of these packages.
              ^^^

SBCL has for several months provided a module for downloading and
installing third-party software, which is then "seamlessly" integrated
into the system (by which I mean that it is then available for use by
REQUIRE).  It automatically chases dependencies; it verifies
authenticity (in as much as that is made possible by the local
configuration) and it's even documented in its own manual page.

Approximately 50 packages are available for download by this method as
I write; no doubt the quality and applicability varies, but I think
you do some library writers a certain disservice by accusing them of
not following your advice when in fact they are.

> What is needed is a simple installation and distribution system.
>
> If such a thing exists, I don't know where it is, or how to find it.
> I am not willing to spend hours researching Google, chasing down
> links, making guesses, trying experiments, starting over, etc.

I'm surprised that you dont mention CLiki, which I would have thought
would be the first port of call for free lisp on Unix.  Did you in
fact try there, or was it an oversight?  A CLiki search for "download
install" gets you asdf-install as the top hit.

> If there are clear-cut solutions that already exist for these issues,
> then they are just not sufficiently documented.

asdf-install is currently sbcl-only, because sbcl is the only
environment that distributes the seed client.  It is a clear-cut
solution, but if you're not using sbcl then it won't work for you
right now.  I can only express sympathy in that case.

> I am not looking for anyone to educate me here.
> Please do not respond by telling me what I need to learn,
> or how I missed the obvious documentation.

I'm asking you how you missed the obvious documentation... maybe it's
because you were tied to clisp?  Implementations need to support such
a automatic download system at least minimally, by providing a simple
client with their distributions.  This needn't be difficult, but
applying a certain amount of pressure to your distributor might help.
"Ask your vendor" as a response works even in the Free Software world.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Rainer Joswig
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <joswig-8760C8.15195324122003@news.fu-berlin.de>
In article <·············@news.dtpq.com>,
 ······@news.dtpq.com (Christopher C. Stacy) wrote:

> I would like to relate the following comments and suggestions to the
> kind people who maintain the various downloadable libraries for Common
> Lisp, particularly those aimed at the CLISP/CMUCL/SBCL users.

Christopher, nice posting. Thanks.

<...>

> By and large, this doesn't affect me personally very much,
> because I do most of my work using commercial Lisp products
> and using my own libraries that I've written over the decades.

I have tried to understand some of the current stuff and
its distribution model. Fortunately (or unfortunately one could say)
I now have with Mac OS X - with it having Unix underneath -
all this Unix stuff right here and can try it out.

> Today I've been trying for several hours to figure out how to 
> get CLOCC and use it on my RedHat Linux machine with CLISP.  
> This is by no means my first foray into this nightmare.
> While doing this, I got a call from another guy trying 
> to do essentially the same thing with CMUCL.  On Sunday I
> had a a call from someone else in the same boat with Corman.

I gave up early on CLOCC.

<...>

> The following may help clarify the problem.
> Here is a profile of your target audience:
> 
> * We DON'T understand SourceForge, we don't have or want CVS, 
>   and, sorry, mostly we don't run Debian.  We may or may not
>   have bzip, and we probably don't know even about it, if we do.

Well, I learned to check out stuff from sourceforge CVS,
I have a Debian system for trying out some stuff and, yes,
I even have bzip. ;-)

<...>

> * We DO have Linux or BSD or Windows: we understand tar files, 
>   gzip, Winzip, Windows installers, CPAN, RPMs, and BSD ports.
>   (But we hate BSD ports. :)

haha. ;-)

>   Some of us have been downloading, compiling, installing,
>   and configuring large packages (such as the GNU suite
>   and Emacs) for years, before things like RPMs were invented.
>   But some of us can not deal with anywhere near that complexity,
>   and need to have a single "self-everything" installation.
>   Either way, we're not idiots.
>   (We wanted your libraries, right? :)

Just some thoughts:

Let's say we have three categories of software:

- commercial

we pay bucks and expect it to work. and it better works,
otherwise we call the support and complain. Though, the
bigger days of commercial Lisps are over - with a
few exceptions.

- university

probably the software is used in some research
projects. as long as that is the case it may work.
if the project is over, good luck. Nowadays
Lisp (Common Lisp) is mostly non-existent at
universities (which says more about the state
of the universities than about Common Lisp).

- hobbyist

currently a lot of the Lisp software that is new falls in
this category. The reason is that since a few years there
is growing interest in Common Lisp from an 'underground'.
Still there are few jobs and few commercial uses, since the
'industry' hasn't (yet) re-discovered Lisp yet. so it
is still more a 'sub-culture' - an underground. You see
Compiler hackers. Lots of them. a few years ago I feared
that CMUCL would die or just stayed on one platform. Now
we have quite a lot Lisp people hacking on Compilers.
More than ever.

What still often is lacking is packaging (yes, you are right).
We have more compilers, but we lack software engineering skills,
more and better libraries (it may need another five years
to get there) and, well, and applications (other than Lisp
compilers compiling itself or other Lisp compilers ;-) ).
Some projects already started - often for web stuff.
Or McCLIM, the reimplementation of CLIM.

It is still experimentation time.

Some people are caring for packaging issues, so SBCL has
been created as an answer to CMUCL's difficult
handling at that time. Installation of CMUCL on debian
is easy. I installed it with apt-get, copied a tar
of CL-HTTP on the machine, loaded the cmucl start file
for CL-HTTP and got a webserver on that machine in Lisp.

(Btw., did I mention that probably the single most
important (IMHO) project now is McCLIM? Oh, and that
a few more hackers would definitely help?)

To sum it up, yes, you are right. it is rough sometimes.
We are very early in the beginning of a (small) Lisp comeback.
Things should get better though, it may take a few years...
Maybe some of the old Lisp hackers should make sure
the old tricks are not forgotten...
From: Paolo Amoroso
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87pteecd6r.fsf@plato.moon.paoloamoroso.it>
Rainer Joswig writes:

> (Btw., did I mention that probably the single most
> important (IMHO) project now is McCLIM? Oh, and that
> a few more hackers would definitely help?)

I agree on the importance of McCLIM, which is in a usable state. But
in a thread where Lisp novices are worried about the difficulties of
installing and running libraries, I wouldn't recommend it to the faint
of heart :)


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Mario S. Mommer
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <fzn09ignyr.fsf@cupid.igpm.rwth-aachen.de>
······@news.dtpq.com (Christopher C. Stacy) writes:
> Today I've been trying for several hours to figure out how to 
> get CLOCC and use it on my RedHat Linux machine with CLISP.  
> This is by no means my first foray into this nightmare.
> While doing this, I got a call from another guy trying 
> to do essentially the same thing with CMUCL.  On Sunday I
> had a a call from someone else in the same boat with Corman.

This is very strange. I have installed CLOCC a few times and I have
never had any problems. Did you try the included readme? That is all
the documentation I ever needed.

> We're all lost.
> 
> It's just too hard.  

I can think of at least one alternative explanation.
From: Friedrich Dominicus
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ptedmkwx.fsf@fbigm.here>
Mario S. Mommer <········@yahoo.com> writes:

> ······@news.dtpq.com (Christopher C. Stacy) writes:
>> Today I've been trying for several hours to figure out how to 
>> get CLOCC and use it on my RedHat Linux machine with CLISP.  
>> This is by no means my first foray into this nightmare.
>> While doing this, I got a call from another guy trying 
>> to do essentially the same thing with CMUCL.  On Sunday I
>> had a a call from someone else in the same boat with Corman.
>
> This is very strange. I have installed CLOCC a few times and I have
> never had any problems. Did you try the included readme? That is all
> the documentation I ever needed.
Well the documentation at the moment states: 

> INSTALLATION OF CLOCC
> 
> You have two options:
>  + using GNU Make or
>  + doing everything from your lisp prompt
> It is entirely up to you what path to take.
> 
> * Using GNU Make (<http://www.gnu.org/software/make/make.html>)
> 
> 1. Set the environment variable LISPTYPE appropriately
>    (currently supported types: acl43, acl5, clisp, cmucl, gcl).
>    Set the environment variable CLOCC_DUMP to the space-separated list of
>    your lisps for which you want to dump images.
>    E.g., ACL/Linux trial version cannot dump images,
>    and CMU CL dumps multi-megabyte images,
>    so you might want to set CLOCC_DUMP to "clisp",
>    and change the value of LISPTYPE according to the implementation
>    you are using at the moment.
> 
Seems reasonable let's do it:
export LISPTYPE=cmucl


> 2. Edit the logical hosts definitions in the file "clocc.lisp" in the
>    top-level directory according to your configuration.
> 

Oh well, at least I have to know what logical hosts are. Remember we
are talking about Lisp beginners. 
Let's see what we find: 
this:
> (defvar *clocc-root*
>   #-(or win32 winnt mswindows) "/home/frid/lib/cl/clocc/"
>   #+(or win32 winnt mswindows) "d:/gnu/clocc/"
>   "*The root CLOCC directory.")
> 
> (setf (logical-pathname-translations "clocc")
>       `(("src;defsystem;*"
>          ,(concatenate 'string *clocc-root* "src/defsystem-3.x/*"))
>         ("src;defsystem;*.*"
>          ,(concatenate 'string *clocc-root* "src/defsystem-3.x/*.*"))
>         ("src;defsystem-3-x;*"
>          ,(concatenate 'string *clocc-root* "src/defsystem-3.x/*"))
>         ("src;defsystem-3-x;*.*"
>          ,(concatenate 'string *clocc-root* "src/defsystem-3.x/*.*"))
>         ("**;*" ,(concatenate 'string *clocc-root* "**/*"))
>         ("**;*.*" ,(concatenate 'string *clocc-root* "**/*.*"))))
> 

Well 2 states I should change the logigical hosts definition. But
that's wrong. I have to change *clocc-root*. If I mess around in the
logical-pathnames-translations what do you think will happen?

OK assume that i adjusted *clocc-root* properly. 

Now we're reaching this:


> 4. You should be able to compile any package in CLOCC now by typing
>    "make system" in the appropriate directory.
>    E.g., if you want to compile "PORT" (the cross-implementation
>    portability system), you do
>         $ cd src/port
>         $ make system
> 
Just let us try:
cd src/tools/ansi-test;
make system
make: *** Keine Regel, um �system� zu erstellen.  Schluss.

well let's try something else
cd src/tools/clunit

/home/frido/lib/cl/clocc/bin/run-lisp -i /home/frido/lib/cl/clocc/clocc-top -i clunit.system 
; Loading #p"/home/frido/lib/common-lisp/clocc/clocc-top.x86f".
Warning:  MAKE also exports the following symbols:
  (HARDCOPY-SYSTEM COMPILE-SYSTEM
                   *COMPILE-DURING-LOAD*
                   *FILES-MISSING-IS-AN-ERROR*
                   AFS-SOURCE-DIRECTORY
                   COMPILER-TYPE-TRANSLATION
                   DEFSYSTEM
                   LOAD-SYSTEM
                   DEFINE-LANGUAGE
                   FILES-IN-SYSTEM
                   OOS
                   UNDEFSYSTEM
                   *MULTIPLE-LISP-SUPPORT*
                   *DONT-REDEFINE-REQUIRE*
                   *BIN-SUBDIR*
                   ADD-REGISTRY-LOCATION
                   DESCRIBE-SYSTEM
                   *RELOAD-SYSTEMS-FROM-DISK*
                   *DEFSYSTEM-VERSION*
                   *MINIMAL-LOAD*
                   DEFINED-SYSTEMS
                   SYSTEM-SOURCE-SIZE
                   FIND-SYSTEM
                   AFS-BINARY-DIRECTORY
                   *CENTRAL-REGISTRY*
                   EDIT-SYSTEM
                   FILES-WHICH-NEED-COMPILATION
                   CLEAN-SYSTEM
                   SOFTWARE-TYPE-TRANSLATION
                   MACHINE-TYPE-TRANSLATION
                   OPERATE-ON-SYSTEM
                   *BINARY-PATHNAME-DEFAULT*
                   MAKE-SYSTEM-TAG-TABLE
                   ALLEGRO-MAKE-SYSTEM-FASL
                   *SOURCE-PATHNAME-DEFAULT*)
; Loading #p"/home/frido/lib/common-lisp/clocc/src/tools/clunit/clunit.system".

Hm what does this warnings mean? 

What can I do with clunit? 
there is a clunit.html so let's look at it:

Somewhere in the first lines:
(load "CLUnit.lisp")
Dummy error occurred in test "Error test"
1 test run; 0 tests passed; 1 test failed.
Dummy error occurred in test "Error test"
1 test run; 0 tests passed; 1 test failed.
2 tests run; 2 tests passed; 0 tests failed.
11 tests run; 11 tests passed; 0 tests failed.
CLUnit self-test passed.

Hm do I have to load this thing or not? The INSTALL says everything
fine while running make system so let's try a test:

(deftest "Test car 1" #'(lambda () (eq (car '(a b)) 'a)))
 
next message:
Error in KERNEL:%COERCE-TO-FUNCTION:  the function DEFTEST is undefined.
   [Condition of type UNDEFINED-FUNCTION]

Restarts:
  0: [ABORT] Return to Slime toplevel.
  1: [ABORT] Return to Top-Level.

Backtrace:
0: (KERNEL:%COERCE-TO-FUNCTION DEFTEST)
1: ("Top-Level Form")[:TOP-LEVEL]

well of course this error will occur, this little line here:
; Loading #p"/home/frido/lib/common-lisp/clocc/src/tools/clunit/clunit.system".

tells what has happened, what is this clunit.system stuff about?
lookint at it:
;;; -*- Mode: Lisp -*-

;;; clunit.system --

(mk:defsystem clunit
    :source-pathname (translate-logical-pathname "clocc:src;tools;clunit;")
    :source-extension "lisp"
    :components ((:file "clunit")))

what does it mean? 

And so on, ...

I assume that is what has driven them nuts. I can understand that
fully.

Regards
Friedrich
From: Vladimir Zolotykh
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <3FEADE9D.6090306@eurocom.od.ua>
Christopher C. Stacy wrote:

! If such a thing exists, I don't know where it is, or how to find it.
! I am not willing to spend hours researching Google, chasing down
! links, making guesses, trying experiments, starting over, etc.

I presume this is the only way. At least for me. Let me give an
example. Some time ago I tried to apply UncommonSQL for my restricted
needs. My way was exactly as you've described it. Searching, trying,
reading sources, making experiments, asking more experienced,
etc. Eventually it began working for me. But to that time I ended up
with my own much simplified code for that. The reason for that was
simple. I know my code and always able to mould it for my own needs.
I'm not saying anything against UncommonSQL. I was just unable to
understood it well enough. Having enough of up-to-date documentation
probably would save me many troubles, but...

! In other words, the ONLY acceptable solution is the SAME as
! for all the other software that we use (for Perl, JAVA, and C).
! There has to be a series of mostly self-installing download
! distributions, and simple documentation to tell what we need.

In that way, if things were so, we would get just another counterpart
for "Perl, JAVA, and C". Let me make a comparison which you may
consider as a trite. Standardization went much further in hardware
than in software. Allow me to think that the analogy is suitable:
hardware and software, traditional languages like C and Lisp. Lisp
software is just too flexible to be easily standardized or restricted
to a few well defined ways or at least susceptible of standardization
by far harder.

To conclude. All you've prospect is possible but hundredfold harder.

-- 
Vladimir Zolotykh
From: Christopher C. Stacy
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <uad5gu2du.fsf@news.dtpq.com>
>>>>> On Thu, 25 Dec 2003 14:57:01 +0200, Vladimir Zolotykh ("Vladimir") writes:
 Vladimir> Lisp software is just too flexible to be easily standardized
 Vladimir> or restricted to a few well defined ways or at least
 Vladimir> susceptible of standardization by far harder.

I was not suggesting that there be only one way, but rather that
there exist a standard way.  To suggest that Lisp is too flexible
for there to exist a standard way to download and install does
not make any sense.

Especially since similar things, such as network-available "autoload"
existed for Lisp more than 20 years ago when I used them.

I think something like CPAN could be implemented in a week.
From: Christophe Rhodes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <sqn09gh5q6.fsf@lambda.jcn.srcf.net>
······@news.dtpq.com (Christopher C. Stacy) writes:

> Especially since similar things, such as network-available "autoload"
> existed for Lisp more than 20 years ago when I used them.
             ^
             +---- a given implementation of

> I think something like CPAN could be implemented in a week.

Actually, this turns out to be hard, based on actual attempts to
implement it.  Or rather, it's easy if you are willing to tolerate
brokenness, or lack of generality.

The problem is the combinatorial explosion, one more than Perl, Python
or other 'one-implementation' languages have to cope with (but even
there, life is not full of roses, as those who remember the transition
between Perl 5.004 and 5.005 will know).

If you restrict the combinatorial explosion to manageable proportions,
then as people have informed you *several times* in this thread,
'something like CPAN' _has_ been implemented more than once; you just
happen to have made choices that prevent you from using it.  I'm
sorry, that's not my fault; please reconsider your choices in the
light of the information you take in (and, while I'm making requests,
please stop peddling misinformation).

The problem gets tricky when you wish to support, say, 4
implementations on 4 operating systems (each of which is more-or-less
braindead) on 5 architectures or so.  Sure, this combinatorial
explosion isn't a problem for portable code, but note that network
interaction is non-portable, so it needs implementation support.

Let me take a little historical diversion, since you seem to assume
that this is a grand new idea that has just burst on the scene, and
that just a little evangelism is needed to get the ball rolling.  Some
people have been working on this problem for about two years (in their
free time, of course, since they're freeloaders^Wfree software
writers).  By far the hardest problem has been in convincing
implementations to support some kind of stub for this kind of
autoloading.

In the first iteration of cCLan (some historical details of which you
can find on CLiki, and on various mailing lists), the problem was
dodged by dealing with just one Linux distribution.  Because Debian is
a distribution with community support and -- and this bit is important
-- a well-constructed package policy (the package /format/ is almost
completely irrelevant) we could construct packages that were
seamlessly integrated with the rest of the system, and that, by
obeying a defined protocol, would be managed by the system for the
productivity benefit of the user: they would be compiled for the
various Lisp compilers that were installed (and understood the
protocol), upgrades to either compiler or library would be
transparently handled, and so on.  The current strong support for Lisp
in Debian is the natural offshoot of this, but note that the Debian
distributors have to modify the lisps that they distribute so that
they obey the various protocols that have been established -- in other
words, they don't distribute vanilla cores for CLISP, CMUCL, and so
on.  Note also that, as has already been said, no one seemed
interested to provide lisps and libraries packaged for this
infrastructure on anything other than Debian.

Fast-forward a little: it turns out that this system for managing Lisp
software is fine for end-users, but a little too intrusive for
developers.  It is tricky, because of these modifications to lisps
(and lighter, but still present, modifications to the upstream
libraries) to work on, rather than with, software distributed in this
form.  It's particularly bad for lisp implementors, who will wish to
test modifications to their lisps, but have no way of easily inserting
it into their system.  So, cCLan version two is born.

cCLan version two is essentially inspired by CTAN (the comprehensive
TeX archive network, which has a well-tested and venerable history).
This consists of simple .tar.gz packages, following extremely simple
policy: have a asdf system description in a file with the same name as
the library.  See CLiki pages "cclan" and "vn-cclan".  Though this
still survives, the problem here is the burden it places on the
archive maintainers and the library writers: the act of placing a
package in the repository is burdensome (particuarly if a project is
fast-moving) for both, and nodes with permanent presence were hard to
find.  The combinatorial explosion is under control, but even the
end-user has to do the work themselves; fairly repetitive work, at
that (download package, untar, link, compile...).

So, to lighten the burden, in comes asdf-install.  This is a simple
http client, so it can easily retrieve packages in the
"vendor-neutral" archive.  However, the additional functionality comes
from the use of CLiki-the-site as a central registry of package
locations.  By adding a tag to a page, say the cl-ppcre page, the
asdf-install client can download and unpack the software, investigate
and possibly recursively operate on its (Lisp package) dependencies,
and compile the library.  However, here again we've lost against the
combinatorial explosion; instead of the first iteration (where we only
support one OS), currently the asdf-install client is only publically
available for one Lisp implementation.

So, where does this leave us?  Well, I can download and install
packages automatically, so I'm happy.  So can the users of my Lisp
implementation, so as long as they're happy, I'm happy.  If users of
other implementations would like to live in this
one-step-closer-to-nirvana, well, I approve and encourage efforts to
make it happen, either by writing or porting a client, or asking your
distributor to do it for you, or even by doing something completely
different (though if you do try doing something completely different,
I'd suggest that you consider the experience of those who have already
trodden down some paths less fruitful).

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Edi Weitz
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87d6ac2yz9.fsf@bird.agharta.de>
On Thu, 25 Dec 2003 22:50:41 +0000, Christophe Rhodes <·····@cam.ac.uk> wrote:

> Note also that, as has already been said, no one seemed interested
> to provide lisps and libraries packaged for this infrastructure on
> anything other than Debian.

... and Gentoo[1].

For those of you who don't know the details it should be noted that
(AFAIK) there are only three "Lisp-y" Debian maintainers (and one of
them, Kevin Rosenberg, maintains the vast majority of the packages)
and there's only one "Lisp-y" Gentoo maintainer.

Being someone who has also contributed a minimal amount of Lisp code
to "the community" (whoever that is) I feel tempted to write much much
more about this subject but a) I'm very busy with other things right
now, and b) it will in no way improve the current situation. The fact
is that, despite of its glorious history, (Common) Lisp currently is
in an "early-adopter" stage. It doesn't help very much to tell people
that it's not very convenient for a user of Corman Lisp on Microsoft
Windows to install CLOCC. We already know that.

As Paolo has mentioned, there is no secret plot to prevent people from
using CL and Lisp libraries, there's just a lack of people working on
this. This is a classical chicken-and-egg problem. For the few
developers working on "free" Lisp stuff it's much more fun[2] to write
new code than to write docs or care about packaging issues. You /will/
find capable people willing to work on this but only if you reach a
"critical mass" of users. Of course it'd be easier to reach this
critical mass if it were easier to install and use these
libraries. Sigh...

Let me ask just a few questions: If CPAN is so great, how easy is it
to install[3] a random Perl module on Windows? How easy would it be if
cygwin or a commercial entity like ActiveState didn't exist? Why does
ActiveState offer Perl, Python, and TCL for Windows but not Common
Lisp? How old is Perl, how old is ActiveState? How many different Perl
implementations do you know?

If you're using Debian or Gentoo or if you happen to use SBCL[4]
together with asdf-install you're already rather lucky. If you
/insist/ on using another OS and/or another Lisp implementation and
you don't have the time or drive to help please ask your commercial
vendor (Red Hat, SuSE, Mandrake, Microsoft, Apple, Franz, Xanalys,
Digitool, Corman, whoever) or come back in two or three years. We're
already working on your problems but we need some more time,
sorry... :)

Edi.


[1] <http://www.cliki.net/gentoo>
[2] or (like me) they're more or less just distributing "offsprings"
    of their commercial work
[3] From the CPAN docs:
      "Does the module require compilation (i.e. does it have files
       that end in .xs, .c, .h, .y, .cc, .cxx, or .C)? [...]. If it
       does, life is now officially tough for you."
[4] CMUCL to come soon...
From: Marc Battyani
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bsij15$l05@library2.airnews.net>
"Edi Weitz" <···@agharta.de> wrote

> As Paolo has mentioned, there is no secret plot to prevent people from
> using CL and Lisp libraries, there's just a lack of people working on
> this. This is a classical chicken-and-egg problem. For the few
> developers working on "free" Lisp stuff it's much more fun[2] to write
> new code than to write docs or care about packaging issues. You /will/
> find capable people willing to work on this but only if you reach a
> "critical mass" of users. Of course it'd be easier to reach this
> critical mass if it were easier to install and use these
> libraries. Sigh...

Hmm, I must admit that there is very few docs for the libraries I release as
open-source. But the problem is not only related to lack of time. If I had
more time I would write more code, not more docs! So the best way IMHO would
be if users wrote some doc/tutorial/how-to/cheat sheet/etc. once they figure
out how some library works ;-)

Marc
From: Igor Carron
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ef3c551.0312260917.4c99bf55@posting.google.com>
So let me get this straight. The community that prides itself in using
a language that deals nicely with extraodirnarly complex problems
dealing with recursion/combinatorial and time critical issues (Hanoi's
towers, Orbitz search engine and so on) cannot come up with a way to
deal with the complexity of having to deal with several OS/several
Lisps and several libraries.

I know this sounds like a bait but if one were to contemplate the
situation from afar like a newbie would (myself being one of them), it
really looks like a lost opportunity to prove a very powerful point.

Igor.


Christophe Rhodes <·····@cam.ac.uk> wrote in message news:<··············@lambda.jcn.srcf.net>...
> ······@news.dtpq.com (Christopher C. Stacy) writes:
> 
> > Especially since similar things, such as network-available "autoload"
> > existed for Lisp more than 20 years ago when I used them.
>              ^
>              +---- a given implementation of
> 
> > I think something like CPAN could be implemented in a week.
> 
> Actually, this turns out to be hard, based on actual attempts to
> implement it.  Or rather, it's easy if you are willing to tolerate
> brokenness, or lack of generality.
> 
> The problem is the combinatorial explosion, one more than Perl, Python
> or other 'one-implementation' languages have to cope with (but even
> there, life is not full of roses, as those who remember the transition
> between Perl 5.004 and 5.005 will know).
> 
> If you restrict the combinatorial explosion to manageable proportions,
> then as people have informed you *several times* in this thread,
> 'something like CPAN' _has_ been implemented more than once; you just
> happen to have made choices that prevent you from using it.  I'm
> sorry, that's not my fault; please reconsider your choices in the
> light of the information you take in (and, while I'm making requests,
> please stop peddling misinformation).
> 
> The problem gets tricky when you wish to support, say, 4
> implementations on 4 operating systems (each of which is more-or-less
> braindead) on 5 architectures or so.  Sure, this combinatorial
> explosion isn't a problem for portable code, but note that network
> interaction is non-portable, so it needs implementation support.
> 
> Let me take a little historical diversion, since you seem to assume
> that this is a grand new idea that has just burst on the scene, and
> that just a little evangelism is needed to get the ball rolling.  Some
> people have been working on this problem for about two years (in their
> free time, of course, since they're freeloaders^Wfree software
> writers).  By far the hardest problem has been in convincing
> implementations to support some kind of stub for this kind of
> autoloading.
> 
> In the first iteration of cCLan (some historical details of which you
> can find on CLiki, and on various mailing lists), the problem was
> dodged by dealing with just one Linux distribution.  Because Debian is
> a distribution with community support and -- and this bit is important
> -- a well-constructed package policy (the package /format/ is almost
> completely irrelevant) we could construct packages that were
> seamlessly integrated with the rest of the system, and that, by
> obeying a defined protocol, would be managed by the system for the
> productivity benefit of the user: they would be compiled for the
> various Lisp compilers that were installed (and understood the
> protocol), upgrades to either compiler or library would be
> transparently handled, and so on.  The current strong support for Lisp
> in Debian is the natural offshoot of this, but note that the Debian
> distributors have to modify the lisps that they distribute so that
> they obey the various protocols that have been established -- in other
> words, they don't distribute vanilla cores for CLISP, CMUCL, and so
> on.  Note also that, as has already been said, no one seemed
> interested to provide lisps and libraries packaged for this
> infrastructure on anything other than Debian.
> 
> Fast-forward a little: it turns out that this system for managing Lisp
> software is fine for end-users, but a little too intrusive for
> developers.  It is tricky, because of these modifications to lisps
> (and lighter, but still present, modifications to the upstream
> libraries) to work on, rather than with, software distributed in this
> form.  It's particularly bad for lisp implementors, who will wish to
> test modifications to their lisps, but have no way of easily inserting
> it into their system.  So, cCLan version two is born.
> 
> cCLan version two is essentially inspired by CTAN (the comprehensive
> TeX archive network, which has a well-tested and venerable history).
> This consists of simple .tar.gz packages, following extremely simple
> policy: have a asdf system description in a file with the same name as
> the library.  See CLiki pages "cclan" and "vn-cclan".  Though this
> still survives, the problem here is the burden it places on the
> archive maintainers and the library writers: the act of placing a
> package in the repository is burdensome (particuarly if a project is
> fast-moving) for both, and nodes with permanent presence were hard to
> find.  The combinatorial explosion is under control, but even the
> end-user has to do the work themselves; fairly repetitive work, at
> that (download package, untar, link, compile...).
> 
> So, to lighten the burden, in comes asdf-install.  This is a simple
> http client, so it can easily retrieve packages in the
> "vendor-neutral" archive.  However, the additional functionality comes
> from the use of CLiki-the-site as a central registry of package
> locations.  By adding a tag to a page, say the cl-ppcre page, the
> asdf-install client can download and unpack the software, investigate
> and possibly recursively operate on its (Lisp package) dependencies,
> and compile the library.  However, here again we've lost against the
> combinatorial explosion; instead of the first iteration (where we only
> support one OS), currently the asdf-install client is only publically
> available for one Lisp implementation.
> 
> So, where does this leave us?  Well, I can download and install
> packages automatically, so I'm happy.  So can the users of my Lisp
> implementation, so as long as they're happy, I'm happy.  If users of
> other implementations would like to live in this
> one-step-closer-to-nirvana, well, I approve and encourage efforts to
> make it happen, either by writing or porting a client, or asking your
> distributor to do it for you, or even by doing something completely
> different (though if you do try doing something completely different,
> I'd suggest that you consider the experience of those who have already
> trodden down some paths less fruitful).
> 
> Christophe
From: Brian Mastenbrook
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <261220031837182289%NObmastenbSPAM@cs.indiana.edu>
In article <···························@posting.google.com>, Igor
Carron <··········@yahoo.com> wrote:

> So let me get this straight. The community that prides itself in using
> a language that deals nicely with extraodirnarly complex problems
> dealing with recursion/combinatorial and time critical issues (Hanoi's
> towers, Orbitz search engine and so on) cannot come up with a way to
> deal with the complexity of having to deal with several OS/several
> Lisps and several libraries.
> 
> I know this sounds like a bait but if one were to contemplate the
> situation from afar like a newbie would (myself being one of them), it
> really looks like a lost opportunity to prove a very powerful point.
> 
> Igor.

As a word of correction: it's improper to top-quote on Usenet, and I
don't think you'll see anyone else here doing so.

That said, I think you are confusing two very different ideas here. The
way that the towers of Hanoi and Orbitz are complex is not the same
thing as vendor packaging. To clarify the situation for you, packaging
is not difficult because it is intrinsically algorithmically complex,
or because the solution is unknown and only hueristics exist. It is
complex because it is like playing whack-a-mole from the perspective of
the mole. It's difficult and I doubt you or any of the carpers could
actually do it. (Not to mention dealing with users who don't read
documentation, know how to use Google, etc.)

Of course, if I'm wrong, go ahead and prove it. I bet you can't.

-- 
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
From: Igor Carron
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ef3c551.0312271537.36ab4f79@posting.google.com>
Brian Mastenbrook <··············@cs.indiana.edu> wrote in message news:<·································@cs.indiana.edu>...
> In article <···························@posting.google.com>, Igor
> Carron <··········@yahoo.com> wrote:
> 
> > So let me get this straight. The community that prides itself in using
> > a language that deals nicely with extraodirnarly complex problems
> > dealing with recursion/combinatorial and time critical issues (Hanoi's
> > towers, Orbitz search engine and so on) cannot come up with a way to
> > deal with the complexity of having to deal with several OS/several
> > Lisps and several libraries.
> > 
> > I know this sounds like a bait but if one were to contemplate the
> > situation from afar like a newbie would (myself being one of them), it
> > really looks like a lost opportunity to prove a very powerful point.
> > 
> > Igor.
> 
> As a word of correction: it's improper to top-quote on Usenet, and I
> don't think you'll see anyone else here doing so.
> 
> That said, I think you are confusing two very different ideas here. The
> way that the towers of Hanoi and Orbitz are complex is not the same
> thing as vendor packaging. To clarify the situation for you, packaging
> is not difficult because it is intrinsically algorithmically complex,
> or because the solution is unknown and only hueristics exist. It is
> complex because it is like playing whack-a-mole from the perspective of
> the mole. It's difficult and I doubt you or any of the carpers could
> actually do it.

It is one thing to give etiquette lessons on top-quoting, it is
another to be polite enough to read posts, take a deep breath and
respond intelligently.

Christopher makes a statement on the current state of the libraries in
Lisp. I make another statement about how it is somehow bizarre that
Lisp being branded by this community as being a very powerful tool
(most probably rightly so), that after some 40 years after its
introduction, there seems to be little more than some ad-hoc way to
deal with the complexity alluded to in this thread. I don't think I
said anything else.

Now let's go back to the complexity issue you are mentionning. A most
intelligent student in cognitive science such as yourself tells us
that the problem of context in our problem (whack-a-mole from the mole
perspective) is complex but at some different level/quality as the
much rehashed "Hanoi's tower" problem (well defined and known
algorithm.) What makes you think that ?

 My lowly non-expert view is that your analysis is a little short. It
is a little short because as far as I can see, a better-than-average
user like Christopher can set up a working library after a day or two
(by essentially understanding the difference between a debian system
and his, reading a lot of how-tos and similar experiences by other
users). While I do not underestimate Christopher's ability in math, I
doubt his ability to solve Hanoi's tower problem on his own in the
same time frame. Most of the messages that have examples in this
thread so far, show that setting up libraries can be handled with a
lot of fortran like "if..then..else" or through the appropriate
transformation of variable names within libraries (a feat I cannot see
as overwhelming using Lisp). I also see the "combinatorial"
complexity, with n OSs, m Lips and l libraries, yes we have n x m x l
possibilities so what ? It is not because you cannot deal with this
complexity that you should resort to name calling (carper) on people
who might want to take a stab at it. Again, I believe your analysis on
the complexity of this issue is flawed. Moreover, if it is shared by
most Lisp experts, your community is doomed. Shoot the messengers all
you want.

By the way, I surely do not advocate solving this library issue in the
way described above: we all have interesting and productive lives
after all. I wished that as a newbie, there had been a Lisp site that
said in big font=7 letters:

" Your experience in lisp and its attendant libraries strongly depends
on your ability to install debian and run lisp from there."

or something equivalent. In this case, the combinatorial complexity
drops significantly.

Some of us newbies wished we had been given this advice in the first
place. Compared to the pain of understanding some of the errors I have
seen on this thread, I would not see a dual boot on my current windows
laptop with a debian distro as being such a major pain. At least, I
know there is ample information on that.


> (Not to mention dealing with users who don't read
> documentation, know how to use Google, etc.)
> 
> Of course, if I'm wrong, go ahead and prove it. I bet you can't.

I most certainly cannot prove wrong somebody doing cognitive science
as you must be more aware than I am.


Igor.
From: Tayssir John Gabbour
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <866764be.0312272135.e4e29aa@posting.google.com>
··········@yahoo.com (Igor Carron) wrote in message news:<···························@posting.google.com>...
> By the way, I surely do not advocate solving this library issue in the
> way described above: we all have interesting and productive lives
> after all. I wished that as a newbie, there had been a Lisp site that
> said in big font=7 letters:
> 
> " Your experience in lisp and its attendant libraries strongly depends
> on your ability to install debian and run lisp from there."

I think you are mistating your criticism.  I doubt anyone lied to you
about the state of Lisp.  The language is huge, and most of it is
"libraries."  The fucker has batteries.  But only until it gets to
interacting with outside systems, which has been an enormously moving
target recently and you must solve through FFI or whatever.

There is a sense that Lisp wants to have a system all to itself, but
right now we're in the diaspora.

However, lispers tend to underestimate the intelligence required to
make a system that works.  I used to get into flamewars here about
Windows because lispers tend to sound like Pythonistas revulsed over
parentheses when they speak of it.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=5627c6fa.0307200237.4acaf99c%40posting.google.com

It is quite fun to write a pretty system from scratch, without the
need for backwards compat.  Especially when you control the damn
hardware.  Microsoft took the tack of having none of these advantages,
and further underpricing their OS (a double-edged sword -- it leads to
devaluation).  And for all that work, they actually changed the world
for the better.  In fact, Gates was right for claiming some credit for
gnu/Linux's success -- MSFT forced PC hardware companies to be
reasonably standardized, which is really an artificial situation. 
gnu/Linux users would be in a lot more pain if this were not so.
From: Greg Menke
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m3k74hrpc8.fsf@europa.pienet>
···········@yahoo.com (Tayssir John Gabbour) writes:

> ··········@yahoo.com (Igor Carron) wrote in message news:<···························@posting.google.com>...
> > By the way, I surely do not advocate solving this library issue in the
> 
> It is quite fun to write a pretty system from scratch, without the
> need for backwards compat.  Especially when you control the damn
> hardware.  Microsoft took the tack of having none of these advantages,
> and further underpricing their OS (a double-edged sword -- it leads to
> devaluation).  And for all that work, they actually changed the world
> for the better.  In fact, Gates was right for claiming some credit for
> gnu/Linux's success -- MSFT forced PC hardware companies to be
> reasonably standardized, which is really an artificial situation. 
> gnu/Linux users would be in a lot more pain if this were not so.

Not quite.  Windows benefited from the standardization and contributed
to it- but remember all the OS's preceeding Windows.  IBM & Intel
pretty much did all the big PC standards up until the mid 90's- and
I'll be you a penny that OS/2 drove more of the fundamental
architecture of PC hardware than Windows did since Windows 3.x was all
Microsoft had for such a long time.  There have been a few standards
that evolved since then, USB, WinModems, etc.. which Microsoft was
probably involved with and/or dominated but thats hardly a cause of
Linux's success.  I think Microsoft is probably a major part of the
cause, but for a different reason; if they were not so dominant and so
monopolistic and writing such unportable, inflexible and low quality
software, then there wouldn't be as much pressure for an alternative.

Are you really asserting Windows is underpriced?

Gregm
From: Tayssir John Gabbour
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <866764be.0312281017.52f48ac6@posting.google.com>
Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...
> Not quite.  Windows benefited from the standardization and contributed
> to it- but remember all the OS's preceeding Windows.  IBM & Intel
> pretty much did all the big PC standards up until the mid 90's- and
> I'll be you a penny that OS/2 drove more of the fundamental
> architecture of PC hardware than Windows did since Windows 3.x was all
> Microsoft had for such a long time.  There have been a few standards
> that evolved since then, USB, WinModems, etc.. which Microsoft was
> probably involved with and/or dominated but thats hardly a cause of
> Linux's success.

Ferguson, _High Stakes, No Prisoners_


> Are you really asserting Windows is underpriced?

Nagel and Holden, _Strategy and Tactics of Pricing_ 3rd ed.


> if they were not so dominant and so
> monopolistic and writing such unportable, inflexible and low quality
> software, then there wouldn't be as much pressure for an alternative.

You forgot, they eat babies.  The cute ones.


- - - -
Food for thought:  Windows rode a price revolution.  So did gnu/Linux.
 And likely Unix.  Note the the chapter before the conclusion of
Kernighan and Mashey's paper "The Unix Programming Environment" for a
hint.
From: Greg Menke
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m3llowi5gq.fsf@europa.pienet>
···········@yahoo.com (Tayssir John Gabbour) writes:

> Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...
> > Not quite.  Windows benefited from the standardization and contributed
> > to it- but remember all the OS's preceeding Windows.  IBM & Intel
> > pretty much did all the big PC standards up until the mid 90's- and
> > I'll be you a penny that OS/2 drove more of the fundamental
> > architecture of PC hardware than Windows did since Windows 3.x was all
> > Microsoft had for such a long time.  There have been a few standards
> > that evolved since then, USB, WinModems, etc.. which Microsoft was
> > probably involved with and/or dominated but thats hardly a cause of
> > Linux's success.
> 
> Ferguson, _High Stakes, No Prisoners_
> 
> 
> > Are you really asserting Windows is underpriced?
> 
> Nagel and Holden, _Strategy and Tactics of Pricing_ 3rd ed.

Please humor me and provide some quotes.

 
> > if they were not so dominant and so
> > monopolistic and writing such unportable, inflexible and low quality
> > software, then there wouldn't be as much pressure for an alternative.
> 
> You forgot, they eat babies.  The cute ones.

You've obviously not spent enough time writing software for the Win32
API, using Visual Basic, or trying to sysadmin a Windows network with
more than a few machines.

Gregm
From: Tayssir John Gabbour
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <866764be.0312290515.3af4eaa0@posting.google.com>
Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...
> > Ferguson, _High Stakes, No Prisoners_
[...]
> > Nagel and Holden, _Strategy and Tactics of Pricing_ 3rd ed.
> 
> Please humor me and provide some quotes.

You didn't seem to be interested in bringing up any new points (I read
Slashdot too, you know), so when I cracked open the pricing book and
noticed how much the index sucked, I didn't think it worthwhile to do
exacting research, and just mentioned the book for anyone who might
want a worthwhile read in the bookstore.

Should I reduce a book to soundbites so we can have a nice flame? 
Maybe gift you a little target to fire at?  I seriously doubt that
approach actually works in reality.  We'll just both be swallowed by
Usenet, a sea of forgotten arguments.


> > You forgot, they eat babies.  The cute ones.
> 
> You've obviously not spent enough time writing software for the Win32
> API, using Visual Basic, or trying to sysadmin a Windows network with
> more than a few machines.

That's because I know better than to do such things.  In the same way,
I do not install every lisp library or gnu/Linux distro because these
things tend to improve with time.  In particular, .net seems to be a
decent though limited system, and eventually the legacy Win32 api may
be written in terms of it.

Of course Windows has sharp edges.  They employ 50k people, and no
matter how well they answer some interview puzzles, some will suck. 
In fact, popularity often brings burdens.

Just the other day, I noticed a Mac dev complaining about Apple's
willingness to break backwards compat:
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=98013&ixReplies=22
whereas Microsoft seems to have the problem that they bend over
backwards to keep it, which can lead to nonconformance to standards
and painful apis.

Sure, no doubt the Mac is currently nicer than Windows, but after
reading enough of Ted Nelson's writings recently, they both look the
same to me.  Mac is more facist but more usable.  Maybe Microsoft will
pull ahead with Longhorn, maybe not.  Yawn.
From: Greg Menke
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m3fzf3ivjw.fsf@europa.pienet>
···········@yahoo.com (Tayssir John Gabbour) writes:

> Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...

 
> > > You forgot, they eat babies.  The cute ones.
> > 
> > You've obviously not spent enough time writing software for the Win32
> > API, using Visual Basic, or trying to sysadmin a Windows network with
> > more than a few machines.
> 
> That's because I know better than to do such things.  In the same way,
> I do not install every lisp library or gnu/Linux distro because these
> things tend to improve with time.  In particular, .net seems to be a
> decent though limited system, and eventually the legacy Win32 api may
> be written in terms of it.

So since you don't sit down and actually <use> the stuff you're
talking about, that makes you somehow well-informed about it?
Remember .net is there to solve a marketing problem, not a technical
one, Microsoft is bound religiously to keeping you off the OS so they
can control the languages and compilers too.  .NET is there to keep
Java away.

 
> Of course Windows has sharp edges.  They employ 50k people, and no
> matter how well they answer some interview puzzles, some will suck. 
> In fact, popularity often brings burdens.

The problem is with Microsoft's management.  If quality architecture
and quality implementation were important to them, thats what we would
have.

 
> Just the other day, I noticed a Mac dev complaining about Apple's
> willingness to break backwards compat:
> http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=98013&ixReplies=22
> whereas Microsoft seems to have the problem that they bend over
> backwards to keep it, which can lead to nonconformance to standards
> and painful apis.

The Windows api was painful from day 1 back in the Win 3.0 days.  They
declined to fix and rationalize it with the first NT, and thus it is
what it is today.  If backwards compatability is so well managed then
why do so many functions in the Win32 api have eratta for so many of
the different OS releases?  And why do the testing people of any
organization that distributes software widely need to have every
version of Windows they support on as many different kinds of PC's
they can get their hands on?

 
> Sure, no doubt the Mac is currently nicer than Windows, but after
> reading enough of Ted Nelson's writings recently, they both look the
> same to me.  Mac is more facist but more usable.  Maybe Microsoft will
> pull ahead with Longhorn, maybe not.  Yawn.

No doubt you've also avoided ever using a Mac and so understand it
much better than everyone else.

Gregm
From: Tayssir John Gabbour
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <866764be.0312291235.2865a725@posting.google.com>
Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...
> > That's because I know better than to do such things.  In the same way,
> > I do not install every lisp library or gnu/Linux distro because these
> > things tend to improve with time.
> 
> So since you don't sit down and actually <use> the stuff you're
> talking about, that makes you somehow well-informed about it?

Tayssir:  You know, Evian water is underrated.  Sure it's absurdly
priced, but it's often convenient when giving a presentation.

Greg:  I saw an ad claiming Evian's great for enemas.  What a crock,
they are the most evil, lying enema-water company around!  I've used
better sewer water.

Tayssir:  Well, I don't do that sort of thing; and if I did I'd
probably not use Evian.  Evian has its disadvantages, but they do run
it through purifiers unlike some brands.

Greg:  You don't use ENEMAS?  You don't understand bottled water.
From: Greg Menke
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m3ad5bhxd4.fsf@europa.pienet>
···········@yahoo.com (Tayssir John Gabbour) writes:

> Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...
> > > That's because I know better than to do such things.  In the same way,
> > > I do not install every lisp library or gnu/Linux distro because these
> > > things tend to improve with time.
> > 
> > So since you don't sit down and actually <use> the stuff you're
> > talking about, that makes you somehow well-informed about it?
> 
> Tayssir:  You know, Evian water is underrated.  Sure it's absurdly
> priced, but it's often convenient when giving a presentation.
> 
> Greg:  I saw an ad claiming Evian's great for enemas.  What a crock,
> they are the most evil, lying enema-water company around!  I've used
> better sewer water.
> 
> Tayssir:  Well, I don't do that sort of thing; and if I did I'd
> probably not use Evian.  Evian has its disadvantages, but they do run
> it through purifiers unlike some brands.
> 
> Greg:  You don't use ENEMAS?  You don't understand bottled water.


Tayssir: I'm a knucklehead and I'm proving it!  I'm a knucklehead and
I'm proving it!  I'm a knucklehead and I'm proving it!  I'm a
knucklehead and I'm proving it!  I'm a knucklehead and I'm proving it!
I'm a knucklehead and I'm proving it!

Greg: Whatever.
From: Pascal Bourguignon
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87ptdkuyn2.fsf@thalassa.informatimago.com>
···········@yahoo.com (Tayssir John Gabbour) writes:

> Greg Menke <··········@toadmail.com> wrote in message news:<··············@europa.pienet>...
> > > That's because I know better than to do such things.  In the same way,
> > > I do not install every lisp library or gnu/Linux distro because these
> > > things tend to improve with time.
> > 
> > So since you don't sit down and actually <use> the stuff you're
> > talking about, that makes you somehow well-informed about it?
> 
> Tayssir:  You know, Evian water is underrated.  Sure it's absurdly
> priced, but it's often convenient when giving a presentation.
> 
> Greg:  I saw an ad claiming Evian's great for enemas.  What a crock,
> they are the most evil, lying enema-water company around!  I've used
> better sewer water.

Actually, Thonon water is better  than Evian. It's a little source not
far from Evian and much less internationnally known.


-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bspel2$k38$1@newsreader2.netcologne.de>
Tayssir John Gabbour wrote:

> Sure, no doubt the Mac is currently nicer than Windows, but after
> reading enough of Ted Nelson's writings recently, they both look the
> same to me.  Mac is more facist but more usable.  Maybe Microsoft will
> pull ahead with Longhorn, maybe not.  Yawn.

[I am going to first comment on the Mac vs. Windows issue, but later on 
I will also make this post related to Common Lisp as well.]

I don't know what you mean by "fascist" wrt to Mac.

On Mac OS X you can, more or less out of the box, run programs written 
for Mac OS 9, Unix, X11 and, of course, Mac OS X. Add Virtual PC to 
that, and you can also run Linux, DOS, Win95, Win98, WinME, Win NT, 
Win2k and WinXP. All of those in parallel, if you want to. If you can 
bear not to run things in parallel, you can also add Linux PPC to the soup.

On top of that, there's Microsoft Office for OS X, one of the best Java 
implementations, and several excellent Common Lisp and Scheme 
implementations, not to mention the various fashionable scripting 
languages of today.

Mac OS X is definitely a dream machine for the post-modern programmer. 
No, "fascist" is not an adequate description.

The problem with Microsoft is not that they write bad software. Most of 
the things they produce are workable solutions within their limited 
confines. The problem with Microsoft is that they successfully make 
people believe that it's very hard to do any better than they can. Your 
remark about the cute babies they eat is telling in this regard - it 
suggests that you think that statements about the low quality of 
Microsoft products are equally laughable.

Microsoft is a successful company because they follow a pattern that has 
proven to be successful in many areas: They promise more than is 
possible, but actually deliver less than that. This keeps you dependent 
in the long run. Food companies follow the same pattern by adding flavor 
enhancers and sweeteners to their products. In fact, this pattern is the 
reason why drugs like alcohol and illegal drugs work: They pretend to 
give you something while they actually take something away. I am 
serious. For example, why is it that there are so many magazines out 
there that try to help to deal with the problems that Microsoft products 
generate?

Back to Lisp: There are many programming languages out there whose 
advocates promise that they solve any problem you might have, while in 
fact they generate problems. Take static type systems as an example and 
the fact that they actually make you write non-evolvable software. The 
usual line of reasoning is this:

a) Language X is not perfect.
b) No language can ever be perfect.
c) Therefore, there is no reason to explore other languages.

It seems hard to understand that c is a non-sequitur. I think it's the 
pattern that I have described above that makes you believe c.


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Tayssir John Gabbour
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <866764be.0312291344.1c6643c2@posting.google.com>
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> The problem with Microsoft is that they successfully make 
> people believe that it's very hard to do any better than they can.

Yes, that's vital.  Tech companies devalue their products if they do
not have "geniuses," as Apple calls its techies.

"Here at Commodore, we make sure only garbagemen work on your OS."

But I think you have a deep point.  You'll likely find this Ted Nelson
essay interesting if you haven't seen it yet:
http://ted.hyperland.com/TQdox/zifty.d9-TQframer.html

It was written in 1999 and likely doesn't apply to MacOS X.  It
venerates the Apple ]['s openness, yet criticizes the Mac philosophy
for creating the cult of the programmer.


> Your remark about the cute babies they eat is telling in this regard - it 
> suggests that you think that statements about the low quality of 
> Microsoft products are equally laughable.

Please ignore my little exchange with Greg Menke.  It's absolutely not
worth your time.

There's the notion that Microsoft is "evil" in an absolute sense.  Ok,
fair enough.  But more important is the contrafactual question --
would the alternate world without Microsoft have been better?

There are a lot of people with quick, anti-nuanced answers to that
puzzle.  They should be ignored.  This is a multidisciplinary
question.


> I don't know what you mean by "fascist" wrt to Mac.

Control.  I've read enough old sources about the Macintosh philosophy
and this description came up often.  Fascism is an authoritarian
design philosophy.  Much brilliant software has been written in a
fascist manner.

Note the next time you hear "benevolent dictator" applied to an
opensource project.  It refers to a fine line between benevolence and
artiste mode.

Vocabulary is often behind the worst misunderstandings.  I once
explained that Unix shell wildcard expansions were bad, since people
expect objects of type filename.  Not characters.  (The Unix Hater's
Handbook talks about this.)

You can imagine the response.  "Are you TALKING ABOUT OOP????!!  Then
we'll have static type declarations in front of everything and..."  I
mean, I didn't even know where to begin finding a common vocab.


> No, "fascist" is not an adequate description.

Fascism does not contradict technical excellence.


> Mac OS X is definitely a dream machine for the post-modern programmer. 

Is that a Feyerabend point of view? ;)

It's actually the little things I like.  When I first used OS X, I
messed around with Wise and the Mac Installer.  They sucked.  Then I
researched what OmniWeb did (.dmg files with controlled
icons/wallpaper), and found the attention to detail charming.

But then things contradicted the intelligent design, such as how
things went >poof< from the Dock when you accidentally dragged them
off.  It's a difficult design decision, but this starts to approach
the horror of when the Windows start menu "disappears."


> a) Language X is not perfect.
> b) No language can ever be perfect.
> c) Therefore, there is no reason to explore other languages.
> 
> It seems hard to understand that c is a non-sequitur. I think it's the 
> pattern that I have described above that makes you believe c.

Remember you're talking to a lisper, who has heard of Lisp Machines. 
Windows does not blind me.

I have a pair of Sony earphones.  I also own Sennheisers.  I know Sony
makes el cheapo trinkets for the masses.  But do I have to go around
decrying it?  No, I accept and vaguely like it.

Same with Bic pens.  Pens that aren't Pilots tend to insult me.  But
there's a place for those nasty Bic pens.  People don't immediately
steal them, for one thing.  So I don't geekily harangue people who
seem to like Bics.

You know, maybe I just feel countercultural liking Microsoft.
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bsqa22$8hi$1@newsreader2.netcologne.de>
Tayssir John Gabbour wrote:

> Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> 
>>The problem with Microsoft is that they successfully make 
>>people believe that it's very hard to do any better than they can.
> 
> Yes, that's vital.  Tech companies devalue their products if they do
> not have "geniuses," as Apple calls its techies.

I haven't heard Apple using this term before, but I have also only 
switched to Apple about 1.5 years ago. Note however that just because 
other companies do it as well - including Apple - doesn't make it an 
acceptable behavior.

> But I think you have a deep point.  You'll likely find this Ted Nelson
> essay interesting if you haven't seen it yet:
> http://ted.hyperland.com/TQdox/zifty.d9-TQframer.html
> 
> It was written in 1999 and likely doesn't apply to MacOS X.  It
> venerates the Apple ]['s openness, yet criticizes the Mac philosophy
> for creating the cult of the programmer.

Thanks for the link. A very interesting read, very Feyerabendish. (which 
means I like it ;)

>>Your remark about the cute babies they eat is telling in this regard - it 
>>suggests that you think that statements about the low quality of 
>>Microsoft products are equally laughable.
> 
> Please ignore my little exchange with Greg Menke.  It's absolutely not
> worth your time.

OK.

> There's the notion that Microsoft is "evil" in an absolute sense.  Ok,
> fair enough.  But more important is the contrafactual question --
> would the alternate world without Microsoft have been better?

Yes. BTW, it is not a contrafactual question. The fact that you think it 
is is part of the problem. Microsoft is successful because it is 
continually overestimated. (I know that you have probably meant 
something slightly different with your claim that it is a contrafactual 
question, but I still stand by my response.)

> There are a lot of people with quick, anti-nuanced answers to that
> puzzle.  They should be ignored.  This is a multidisciplinary
> question.

This is true. However, I sense an implicit underlying assumption that 
one cannot just ignore Microsoft - this assumption reduces the 
multidisciplinarity of the question.

>>I don't know what you mean by "fascist" wrt to Mac.
> 
> Control.  I've read enough old sources about the Macintosh philosophy
> and this description came up often.  Fascism is an authoritarian
> design philosophy.  Much brilliant software has been written in a
> fascist manner.
> 
> Note the next time you hear "benevolent dictator" applied to an
> opensource project.  It refers to a fine line between benevolence and
> artiste mode.

I don't quite get what you are trying to tell me here. Please note that 
I am not talking about the old Mac OS 9 which I didn't like, so any 
criticism of some old Mac philosophy doesn't address what I am trying to 
get at. Furthermore, I think that "benevolent dictatorship" is an oxymoron.

Maybe I am missing something.

>>Mac OS X is definitely a dream machine for the post-modern programmer. 
> 
> Is that a Feyerabend point of view? ;)

No, since Feyerabend is not a post-modern approach. ;) (ouch!)

> It's actually the little things I like.  When I first used OS X, I
> messed around with Wise and the Mac Installer.  They sucked.  Then I
> researched what OmniWeb did (.dmg files with controlled
> icons/wallpaper), and found the attention to detail charming.
> 
> But then things contradicted the intelligent design, such as how
> things went >poof< from the Dock when you accidentally dragged them
> off.  It's a difficult design decision, but this starts to approach
> the horror of when the Windows start menu "disappears."

...but these are superficialities. The good things about Mac OS X are 
really underneath. Like the fact that you actually don't need installers 
for most software. That you don't have a concept of a registry or of a 
shared DLL folder, and so on. That you don't have to deal with viruses 
at all, because everyone is attacking Windows. (That's actually one of 
the really cool features of Windows from an Apple user's POV. ;-P

You need some way to modify the dock. Maybe they didn't find the best, 
but who cares.

Under Windows I have continually lived under the fear that something is 
going to break under the hoods. Under Mac OS X I don't. This is what I 
find important.

>>a) Language X is not perfect.
>>b) No language can ever be perfect.
>>c) Therefore, there is no reason to explore other languages.
>>
>>It seems hard to understand that c is a non-sequitur. I think it's the 
>>pattern that I have described above that makes you believe c.
> 
> Remember you're talking to a lisper, who has heard of Lisp Machines. 
> Windows does not blind me.

That's good to hear. ;)

> I have a pair of Sony earphones.  I also own Sennheisers.  I know Sony
> makes el cheapo trinkets for the masses.  But do I have to go around
> decrying it?  No, I accept and vaguely like it.
> 
> Same with Bic pens.  Pens that aren't Pilots tend to insult me.  But
> there's a place for those nasty Bic pens.  People don't immediately
> steal them, for one thing.  So I don't geekily harangue people who
> seem to like Bics.
> 
> You know, maybe I just feel countercultural liking Microsoft.

You're right, there are good reasons to do these things. There are also 
equally good reasons to use Microsoft products. What puzzles me are 
people who do these things beyond reason.


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Tayssir John Gabbour
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <866764be.0312300414.c470946@posting.google.com>
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> > Note the next time you hear "benevolent dictator" applied to an
> > opensource project.  It refers to a fine line between benevolence and
> > artiste mode.
> 
> I don't quite get what you are trying to tell me here. Please note that 
> I am not talking about the old Mac OS 9 which I didn't like, so any 
> criticism of some old Mac philosophy doesn't address what I am trying to 
> get at. Furthermore, I think that "benevolent dictatorship" is an oxymoron.

I understand benevolent dictator to mean someone who builds a fairly
open and tiered community process with which one forces herself to
publicly justify her own decisions but usually reserves the final
fiat.  Guido van Rossum and Larry Wall are examples.  (I think the
original Moz team described itself as such, but the way they put it,
it wasn't clear to me then.)

A fascist is different in a matter of degree.


> Under Windows I have continually lived under the fear that something is 
> going to break under the hoods. Under Mac OS X I don't. This is what I 
> find important.

This is why I would not sysadmin a cluster of heterogenous Windows
machines.  It took voodoo to get Win98 to understand I was on a
network, where the Nth attempt magically worked when the previous ones
didn't.

But you see, MacOS X was a recent challenge against Windows.  It has a
lead that may or may not be temporary.  I think we must be
professional and consider product cycles.  WinXP solved many of the
stability problems, to the point where if I did the convoluted but
normal procedure to do things, they would always work.  .NET seems to
be a further simplification.

The discussion is thus:  I don't disagree with any of the trees.  I
have eyes, I see the problems with Windows.  I agree with the trees;
disagree with the forest.


> You need some way to modify the dock. Maybe they didn't find the best, 
> but who cares.

Hmm, I think MacOS X should not be a "who cares" platform. 

I just hope the user didn't drag off Sherlock, if it's possible. ;)  I
believe the Mac team's POV was that it was too difficult to hide the
filesystem from the user, at least in the initial release.  And the
market has grown to the point where people may be assumed to
understand hierarchal file systems.


> Yes. BTW, it is not a contrafactual question. The fact that you think it 
> is is part of the problem. Microsoft is successful because it is 
> continually overestimated.

No, I know Microsoft is overestimated.  Dominant companies do that
often, cultivate a threat potential.

Again, I agree with the details.  But my conclusion differs.
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bss0og$60r$1@newsreader2.netcologne.de>
Tayssir John Gabbour wrote:

> I understand benevolent dictator to mean someone who builds a fairly
> open and tiered community process with which one forces herself to
> publicly justify her own decisions but usually reserves the final
> fiat.  Guido van Rossum and Larry Wall are examples.  

Yes, I know. But what's the point?

> (I think the
> original Moz team described itself as such, but the way they put it,
> it wasn't clear to me then.)
> 
> A fascist is different in a matter of degree.

The difference is only very marginal. Just start a discussion on adding 
macros to Python in comp.lang.python and you'll see. ;)

"The Guru Papers" by Kramer/Alstad is a good read on these issues.

>>You need some way to modify the dock. Maybe they didn't find the best, 
>>but who cares.
> 
> Hmm, I think MacOS X should not be a "who cares" platform.

Well, it isn't. The dock is an example of an element in the Mac OS X GUI 
that is only good enough, and that's a pity. But a) it is not 
representative, and b) it still works. If you care a lot, there are many 
replacement utilities for the dock out there.

> I just hope the user didn't drag off Sherlock, if it's possible. ;) 

I don't use Sherlock anymore. They have moved the important 
functionality to the Finder.

> Again, I agree with the details.  But my conclusion differs.

That's ok with me. ;)


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Tayssir John Gabbour
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <866764be.0312310356.8877e41@posting.google.com>
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> Tayssir John Gabbour wrote:
> > Again, I agree with the details.  But my conclusion differs.
> 
> That's ok with me. ;)

True to your word, you're a postmodern programmer.
From: Rahul Jain
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <871xqmaj6g.fsf@nyct.net>
···········@yahoo.com (Tayssir John Gabbour) writes:

> Control.  I've read enough old sources about the Macintosh philosophy
> and this description came up often.  Fascism is an authoritarian
> design philosophy.  Much brilliant software has been written in a
> fascist manner.

That's an amazingly ignorant viewpoint that runs in the face of the
spirit of the community of hackers that grew around the Mac. Maybe this
is more true with OS X, I don't know.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Tayssir John Gabbour
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <866764be.0312300400.1a6148ff@posting.google.com>
Rahul Jain <·····@nyct.net> wrote in message news:<··············@nyct.net>...
> ···········@yahoo.com (Tayssir John Gabbour) writes:
> > Control.  I've read enough old sources about the Macintosh philosophy
> > and this description came up often.  Fascism is an authoritarian
> > design philosophy.  Much brilliant software has been written in a
> > fascist manner.
> 
> That's an amazingly ignorant viewpoint that runs in the face of the
> spirit of the community of hackers that grew around the Mac. Maybe this
> is more true with OS X, I don't know.

Perhaps.  I'm viewing this backwards into history, though both the
tech and biographical material lead me not to doubt the nature was
autocratic.  When I ported to the Mac, I went through all I could,
read Woz's website, watched the Jobs keynotes I could find, etc etc. 
Even saw the 1984 commercial and found "Pirates of Silicon Valley" at
the video store.  To immerse myself in the culture.  No, I did not
believe the movie blindly, but I carefully searched for Woz's opinions
of it.

Of course, I read about Cocoa, the Jonathan Ive design team, Jef
Raskin's books, and all that stuff.

It's hard to shake off the disgust at the PC world when you see Jobs
carefully showing off all the little bits of MacOS X.  Designed to
make peoples' lives incrementally better.  But it is important for me
to kill the fantasy in my mind, because the computer world is really
not my world.  In the same way, I keep my ears out for Lisp critiques,
which seemed to offend some people here.  Even though I ask this
because I fundamentally do like lisp.

(FWIW, the computer world does not contain my community, I guess.  So
if I offend some of the denizens with my impertinence, I'm sorry.  We
are fundamentally unlike each other and I like it that way. ;)
From: Pascal Bourguignon
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87llo8uy8r.fsf@thalassa.informatimago.com>
···········@yahoo.com (Tayssir John Gabbour) writes:
> > Mac OS X is definitely a dream machine for the post-modern programmer. 
> 
> Is that a Feyerabend point of view? ;)
> 
> It's actually the little things I like.  When I first used OS X, I
> messed around with Wise and the Mac Installer.  They sucked.  Then I
> researched what OmniWeb did (.dmg files with controlled
> icons/wallpaper), and found the attention to detail charming.
> 
> But then things contradicted the intelligent design, such as how
> things went >poof< from the Dock when you accidentally dragged them
> off.  It's a difficult design decision, but this starts to approach
> the horror of when the Windows start menu "disappears."

The more I  use MacOSX, the more I regret NS3.3  and OS4.2!  MacOSX is
on very bad slope because they  try to implement their GUI _above_ and
_oblivious_ of the unix layer.  NeXTSTEP represented a perfect GUI for
unix,  there was a  perfect integration  of the  NeXTSTEP GUI  and the
underlying unix OS.  Not anymore. 

One example would be how the Finder ignores the g+s on directories and
refuses  to copy  g+s directories.   Another  would be  how all  files
created by the "Macintosh" (how should  we call it? = MacOSX - Darwin)
are 777 (what an opportunity for virus creators!!!).



-- 
__Pascal_Bourguignon__                     http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
From: Rainer Joswig
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <c366f098.0401160246.22ac3d7b@posting.google.com>
Pascal Bourguignon <····@thalassa.informatimago.com> wrote in message news:<··············@thalassa.informatimago.com>...
> ···········@yahoo.com (Tayssir John Gabbour) writes:
> > > Mac OS X is definitely a dream machine for the post-modern programmer. 
> > 
> > Is that a Feyerabend point of view? ;)
> > 
> > It's actually the little things I like.  When I first used OS X, I
> > messed around with Wise and the Mac Installer.  They sucked.  Then I
> > researched what OmniWeb did (.dmg files with controlled
> > icons/wallpaper), and found the attention to detail charming.
> > 
> > But then things contradicted the intelligent design, such as how
> > things went >poof< from the Dock when you accidentally dragged them
> > off.  It's a difficult design decision, but this starts to approach
> > the horror of when the Windows start menu "disappears."
> 
> The more I  use MacOSX, the more I regret NS3.3  and OS4.2!  MacOSX is
> on very bad slope because they  try to implement their GUI _above_ and
> _oblivious_ of the unix layer.  NeXTSTEP represented a perfect GUI for
> unix,  there was a  perfect integration  of the  NeXTSTEP GUI  and the
> underlying unix OS.  Not anymore. 

Mac OS X is more than Unix.

> One example would be how the Finder ignores the g+s on directories and
> refuses  to copy  g+s directories.   Another  would be  how all  files
> created by the "Macintosh" (how should  we call it? = MacOSX - Darwin)
> are 777 (what an opportunity for virus creators!!!).

777??? Not on my Mac.
From: Espen Vestre
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <kwvfncxggv.fsf@merced.netfonds.no>
······@corporate-world.lisp.de (Rainer Joswig) writes:

> 777??? Not on my Mac.

This probably belongs to a mac group, but since the PowerBook
is the lisp hackers tool of choice ;-), I'll try and elaborate:

Have a look at the protection of files that are copied with
Finder form a .dmg image to the /Application directory. E.g.
if you have an application bundle that is drwxr-xr-x on the 
mounted .dmg image, it will be drwxrwxrwx on the hard disk.

This is on a mounted .dmg image:

drwxr-xr-x  3 ev    unknown   102 Dec  4 14:34 PrimeTrader.app

This is after copying as an admin user:

drwxrwxrwx   3 drift  admin    102 Dec  4 14:34 PrimeTrader.app

I actually thought one of the recent security patches addressed this,
but apparently it didn't, at least not on 10.2.8 (anyone with Panther
that can tell if 10.3 is better?).

I also dislike the fact that other applications are writeable for the
admin group. Most users log in as an admin (they shouldn't, but until
Apple tries to push them to it, they don't even think about using a
non-admin user for their daily work), and thus can destroy
(virus-infect) even those applications that aren't 777.

I think there's an easy way out of this mess without resorting to
using installers for everything: Apple should make the /Application
directory writable to root only, and make Finder context-sensitive to
dropping directories/files on this directory: If a user tries to do
that, he should, instead of an error message (if non-admin) be
prompted for an admin username and password, and Finder could then
use sudo "under the hood".
-- 
  (espen)
From: Raffael Cavallaro
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <raffaelcavallaro-A3330B.01430117012004@netnews.comcast.net>
In article <··············@merced.netfonds.no>,
 Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:

> Have a look at the protection of files that are copied with
> Finder form a .dmg image to the /Application directory. E.g.
> if you have an application bundle that is drwxr-xr-x on the 
> mounted .dmg image, it will be drwxrwxrwx on the hard disk.
> 
> This is on a mounted .dmg image:
> 
> drwxr-xr-x  3 ev    unknown   102 Dec  4 14:34 PrimeTrader.app
> 
> This is after copying as an admin user:
> 
> drwxrwxrwx   3 drift  admin    102 Dec  4 14:34 PrimeTrader.app
> 
> I actually thought one of the recent security patches addressed this,
> but apparently it didn't, at least not on 10.2.8 (anyone with Panther
> that can tell if 10.3 is better?).

Panther seems to fix this - that is to say, permissions are preserved 
when copying from a mounted .dmg to the /Applications directory. So, 
non-admin users can't write to an .app bundle (assuming the application 
author knew what s/he was doing and set permissions to 755 or 775). All 
of Apple's apps are 775, BTW.

> Apple should make the /Application
> directory writable to root only, and make Finder context-sensitive to
> dropping directories/files on this directory: If a user tries to do
> that, he should, instead of an error message (if non-admin) be
> prompted for an admin username and password, and Finder could then
> use sudo "under the hood".

This would certainly be safer, but maybe Apple doesn't do this because 
there are still some carbon apps out there that modify their resource 
forks when run. This would make them impossible to run by non-admin 
users.
From: Immanuel Litzroth
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <1xq0m6jb.fsf@coriander.enfocus.be>
Pascal Bourguignon <····@thalassa.informatimago.com> writes:

> The more I  use MacOSX, the more I regret NS3.3  and OS4.2!  MacOSX is
> on very bad slope because they  try to implement their GUI _above_ and
> _oblivious_ of the unix layer.  NeXTSTEP represented a perfect GUI for
> unix,  there was a  perfect integration  of the  NeXTSTEP GUI  and the
> underlying unix OS.  Not anymore. 
>
> One example would be how the Finder ignores the g+s on directories and
> refuses  to copy  g+s directories.   Another  would be  how all  files
> created by the "Macintosh" (how should  we call it? = MacOSX - Darwin)
> are 777 (what an opportunity for virus creators!!!).

Can I strongly agree with your opinion on MacOS? I have been amazed at
the positive attitude towards apple's new OS. I develop on/for MacOSX and
my "experience" has not been at all positive.
Immanuel
From: Greg Menke
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m38yk8aud0.fsf@europa.pienet>
Immanuel Litzroth <·········@enfocus.be> writes:

> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> 
> > The more I  use MacOSX, the more I regret NS3.3  and OS4.2!  MacOSX is
> > on very bad slope because they  try to implement their GUI _above_ and
> > _oblivious_ of the unix layer.  NeXTSTEP represented a perfect GUI for
> > unix,  there was a  perfect integration  of the  NeXTSTEP GUI  and the
> > underlying unix OS.  Not anymore. 
> >
> > One example would be how the Finder ignores the g+s on directories and
> > refuses  to copy  g+s directories.   Another  would be  how all  files
> > created by the "Macintosh" (how should  we call it? = MacOSX - Darwin)
> > are 777 (what an opportunity for virus creators!!!).
> 
> Can I strongly agree with your opinion on MacOS? I have been amazed at
> the positive attitude towards apple's new OS. I develop on/for MacOSX and
> my "experience" has not been at all positive.

I've been working up my stepmother's G4 to replace a Windows box and
Linux server, and I've found OSX to be very pleasant to deal with.  If
(when) the GUI becomes intransigent, just hop out to a shell and get
it done.  There are a few problems though.  I've also tried using a G3
laptop w/ OS9.x a few times and I just can't get it to do what I want-
and no shell to hop out into so I can get it done.

But then I'd never use Finder for anything but a prettied up menu, any
real work I'll do on the command line and /etc/init.d.  From my
perspective, OSX is pretty much like any other *nix but with all the
admin stuff tucked away in netinfo rather than available in /etc, GUI
fanciness notwithstanding.

Gregm
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bsl963$oc8$1@newsreader2.netcologne.de>
Igor Carron wrote:

> Christopher makes a statement on the current state of the libraries in
> Lisp. I make another statement about how it is somehow bizarre that
> Lisp being branded by this community as being a very powerful tool
> (most probably rightly so), that after some 40 years after its
> introduction, there seems to be little more than some ad-hoc way to
> deal with the complexity alluded to in this thread. I don't think I
> said anything else.

Lisp has had its main quantum leaps at times when it wasn't clear at all 
that Unixy operating systems - including DOS & Windows - would "win", 
i.e the 60's, 70's and 80's. Linux and Windows are relatively recent 
phenomenons that evolved in the 90's - these were times when Lisp 
suffered from the backlash of AI.

The combination of Common Lisp + Unix/Windows + Open Source is a very 
recent evolution. Until the 90's, Common Lisp has been a language that 
was mainly driven by commercial vendors. It is only since recently, that 
people have started to pick up Common Lisp because they have learned 
from languages like Python and Ruby that programming convenience can be 
far more important than micro-efficiency. Since this is a very "young" 
phenomenon, the infrastructure for newbies is far from perfect. This has 
both advantages and disadvantages. One of the advantages is that you can 
very quickly make a good name for yourself by starting to contribute.

> By the way, I surely do not advocate solving this library issue in the
> way described above: we all have interesting and productive lives
> after all. I wished that as a newbie, there had been a Lisp site that
> said in big font=7 letters:
> 
> " Your experience in lisp and its attendant libraries strongly depends
> on your ability to install debian and run lisp from there."

Well, but it doesn't. Look out for personal / free editions of 
commercial Common Lisp implementation that offer an above average newbie 
experience. Don't feel hindered by the fact that the non-free editions 
are typically very expensive. If your goal is to learn the language in 
the first place, these are excellent options. You can change your mind 
later on if you want or need to. Lisp is an extremely flexible language, 
which means that a vendor lock-in is not very likely, at least not at 
the same degree as is the case for other languages.

You might even find out that commercial implementations are good options 
for later projects. Open Source is not a silver bullet.



Pascal


-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Christophe Rhodes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <sq3cb43op1.fsf@lambda.jcn.srcf.net>
··········@yahoo.com (Igor Carron) writes:

> Christopher makes a statement on the current state of the libraries in
> Lisp. 

I'm not sure -- are you referring to me here, or not?  Both
Christopher Stacy and I have made statements on the current state of
library use in Free Lisps, and your wording below (talking about
"carper") points to me, since I'm the only one to have used that word
in this thread, but I'm not sure.  If it is indeed me, note that the
confusion could be avoided by spelling my name correctly :-)

> Now let's go back to the complexity issue you are mentionning. A most
> intelligent student in cognitive science such as yourself tells us
> that the problem of context in our problem (whack-a-mole from the mole
> perspective) is complex but at some different level/quality as the
> much rehashed "Hanoi's tower" problem (well defined and known
> algorithm.) What makes you think that ?

From my perspective: experience.  I know how to solve the Towers of
Hanoi problem; having tried, I don't have a complete solution to the
Make Lisp Libraries Easy To Use By Everyone problem.  I have several
partial results, though.

> Most of the messages that have examples in this
> thread so far, show that setting up libraries can be handled with a
> lot of fortran like "if..then..else" or through the appropriate
> transformation of variable names within libraries (a feat I cannot see
> as overwhelming using Lisp). I also see the "combinatorial"
> complexity, with n OSs, m Lips and l libraries, yes we have n x m x l
> possibilities so what ? 

What you're missing here is that a solution to this problem at exactly
one point in time is no good.  The solution has to be robust enough,
maintainable enough to be able to absorb changes to the external world
(new OSes, new versions of Lisp, new file systems [ha!]) with a
minimum of effort.  If you simply "solve" the problem now with a large
CASE form, you will have in your hands a piece of code that will be
useless in six months' or a year's time.

> It is not because you cannot deal with this
> complexity that you should resort to name calling (carper) on people
> who might want to take a stab at it. 

Since I used the word, I'd like to point out that it's the people who
only speak and do not act who merit the name.  And there are rather a
lot of them.  By all means, Just Do It.

> Again, I believe your analysis on the complexity of this issue is
> flawed. Moreover, if it is shared by most Lisp experts, your
> community is doomed. Shoot the messengers all you want.

There Is No Lisp Community.  There's nothing there to doom.  In that
sense, my message is much more positive than yours: the only way is
up.

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Brian Mastenbrook
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <291220030939556898%NObmastenbSPAM@cs.indiana.edu>
In article <···························@posting.google.com>, Igor
Carron <··········@yahoo.com> wrote:

> It is one thing to give etiquette lessons on top-quoting, it is
> another to be polite enough to read posts, take a deep breath and
> respond intelligently.

It was an intelligent post, based on actual experience in distributing
lisp. Whether or not you agree with it does not make it more or less
intelligent.

> Christopher makes a statement on the current state of the libraries in
> Lisp. I make another statement about how it is somehow bizarre that
> Lisp being branded by this community as being a very powerful tool
> (most probably rightly so), that after some 40 years after its
> introduction, there seems to be little more than some ad-hoc way to
> deal with the complexity alluded to in this thread. I don't think I
> said anything else.

The situation is the same for most every other community. Installing
python libraries without being a python-ite is a major pain. Same goes
for tcl, and even C. The fact that it is no different for lisp should
suggest to you that the problem is not computationally hard, but
practically hard.

> Now let's go back to the complexity issue you are mentionning. A most
> intelligent student in cognitive science such as yourself tells us
> that the problem of context in our problem (whack-a-mole from the mole
> perspective) is complex but at some different level/quality as the
> much rehashed "Hanoi's tower" problem (well defined and known
> algorithm.) What makes you think that ?

Experience. The analogy was intended to suggest that whatever solution
you came up with would break soon anyway, as is the case when dealing
with multiple distributions / operating systems, versions, etc.

>  My lowly non-expert view is that your analysis is a little short. It
> is a little short because as far as I can see, a better-than-average
> user like Christopher can set up a working library after a day or two
> (by essentially understanding the difference between a debian system
> and his, reading a lot of how-tos and similar experiences by other
> users). While I do not underestimate Christopher's ability in math, I
> doubt his ability to solve Hanoi's tower problem on his own in the
> same time frame.

What does this mean? I am confused.

> Most of the messages that have examples in this
> thread so far, show that setting up libraries can be handled with a
> lot of fortran like "if..then..else" or through the appropriate
> transformation of variable names within libraries (a feat I cannot see
> as overwhelming using Lisp). I also see the "combinatorial"
> complexity, with n OSs, m Lips and l libraries, yes we have n x m x l
> possibilities so what ? It is not because you cannot deal with this
> complexity that you should resort to name calling (carper) on people
> who might want to take a stab at it. Again, I believe your analysis on
> the complexity of this issue is flawed. Moreover, if it is shared by
> most Lisp experts, your community is doomed. Shoot the messengers all
> you want.

The name was a direct reference to Cristophe's use, which referred to
people who complain but don't code and don't know how to solve the
problem.

> By the way, I surely do not advocate solving this library issue in the
> way described above: we all have interesting and productive lives
> after all. I wished that as a newbie, there had been a Lisp site that
> said in big font=7 letters:
> 
> " Your experience in lisp and its attendant libraries strongly depends
> on your ability to install debian and run lisp from there."

I run Mac OS X. The situation isn't bad over here. I use asdf-install
to download and run new libraries, and things generally "just work". I
provide SBCL binaries to help this out, since there's a bug in building
the contrib/ libraries that I can't reproduce, yet some others can.

> or something equivalent. In this case, the combinatorial complexity
> drops significantly.
> 
> Some of us newbies wished we had been given this advice in the first
> place. Compared to the pain of understanding some of the errors I have
> seen on this thread, I would not see a dual boot on my current windows
> laptop with a debian distro as being such a major pain. At least, I
> know there is ample information on that.

Debian /is/ a major pain. So is Linux. Some of us don't care about ACPI
or compiling a kernel with some patch for our firewire devices or
whatever. (Insert anti-anti-Linux flamage here.)

> I most certainly cannot prove wrong somebody doing cognitive science
> as you must be more aware than I am.

What? My post had nothing to do with cognitive science. I can't tell
whether this is a veiled ad-hominem attack or just poorly worded, but
it makes no sense to me.

-- 
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
From: Rahul Jain
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <8765fyajoi.fsf@nyct.net>
··········@yahoo.com (Igor Carron) writes:

>  My lowly non-expert view is that your analysis is a little short.

It should come as no surprise to you, in that case, that the opposite is
what's actually true.

> Most of the messages that have examples in this
> thread so far, show that setting up libraries can be handled with a
> lot of fortran like "if..then..else" or through the appropriate
> transformation of variable names within libraries (a feat I cannot see
> as overwhelming using Lisp).

That is because there is no standard for packaging these libraries. When
you don't use the same tools, how can you expect them all to have the
same interface?

> I also see the "combinatorial"
> complexity, with n OSs, m Lips and l libraries, yes we have n x m x l
> possibilities so what ? It is not because you cannot deal with this
> complexity that you should resort to name calling (carper) on people
> who might want to take a stab at it.

I don't see any one of you carpers taking a stab at solving the
problem. Is that because all you can do is carp? It's really sickening
to see the sense of entitlement displayed in both this thread and the
off-topic-tangent healthcare thread.

> Again, I believe your analysis on
> the complexity of this issue is flawed. Moreover, if it is shared by
> most Lisp experts, your community is doomed. Shoot the messengers all
> you want.

Ah, the holier-than-thou attitude. Here we go...

> By the way, I surely do not advocate solving this library issue in the
> way described above: we all have interesting and productive lives
> after all. I wished that as a newbie, there had been a Lisp site that
> said in big font=7 letters:
>
> " Your experience in lisp and its attendant libraries strongly depends
> on your ability to install debian and run lisp from there."
>
> or something equivalent. In this case, the combinatorial complexity
> drops significantly.

The fact remains that some systems are well-designed and others
aren't. Don't shoot the developer of the well-designed system. If you
want to figure out a way to make RedHat or whatever behave like you want
it to behave, that's not our responsibility. Debian behaves like I want
it to behave, so I use it. I'm not tied to RedHat even though it was my
first distro. If you really think RedHat is so good, it should have
attracted a developer who is capable of engineering a system like we
have engineered for debian. I'm praying for the day (if only to shut
people like you up) that RedHat is proven to be that good.

> Some of us newbies wished we had been given this advice in the first
> place. Compared to the pain of understanding some of the errors I have
> seen on this thread, I would not see a dual boot on my current windows
> laptop with a debian distro as being such a major pain. At least, I
> know there is ample information on that.

So blame the messenger, not the one who had the message you wanted in
the first place. Or blame yourself for not stopping for a moment and
looking around first. If I developed user interfaces by just slapping
together any random ideas I had (believe me, this is what some of our
clients try to give us), I'd spend more time trying to figure out what
exactly something was supposed to do instead of fixing the bug or
amending the user documentation.

I don't see why you need to give up the principles you learn as a
programmer when you become a user for a moment. They'll serve you well
in both cases.

-- 
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bshtnq$hkr$1@newsreader2.netcologne.de>
Igor Carron wrote:
> So let me get this straight. The community that prides itself in using
> a language that deals nicely with extraodirnarly complex problems
> dealing with recursion/combinatorial and time critical issues (Hanoi's
> towers, Orbitz search engine and so on) cannot come up with a way to
> deal with the complexity of having to deal with several OS/several
> Lisps and several libraries.
> 
> I know this sounds like a bait but if one were to contemplate the
> situation from afar like a newbie would (myself being one of them), it
> really looks like a lost opportunity to prove a very powerful point.

I hope it doesn't look like a lost opportunity to learn why these are 
two very different issues.


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Paolo Amoroso
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87vfo3sam6.fsf@plato.moon.paoloamoroso.it>
Igor Carron writes:

> So let me get this straight. The community that prides itself in using
> a language that deals nicely with extraodirnarly complex problems
> dealing with recursion/combinatorial and time critical issues (Hanoi's
> towers, Orbitz search engine and so on) cannot come up with a way to
> deal with the complexity of having to deal with several OS/several
> Lisps and several libraries.

Here is a hint. Those who use Lisp to deal with those extraordinarily
complex problems do not need newbie documentation or operating system
independent packaging tools. And given their limited time and
resources, if they have to choose between solving complex problems
that interest them, or writing newbie tools/documentation, you might
guess what they are going to do.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Christopher C. Stacy
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <u3cb7b46f.fsf@news.dtpq.com>
>>>>> On Fri, 26 Dec 2003 19:21:53 +0100, Paolo Amoroso ("Paolo") writes:
 Paolo> Here is a hint. Those who use Lisp to deal with those
 Paolo> extraordinarily complex problems do not need newbie
 Paolo> documentation or operating system independent packaging tools.

That's got to be just about the lamest thing I've ever heard.
From: Christophe Rhodes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <sq4qvnqhxw.fsf@lambda.jcn.srcf.net>
······@news.dtpq.com (Christopher C. Stacy) writes:

>>>>>> On Fri, 26 Dec 2003 19:21:53 +0100, Paolo Amoroso ("Paolo") writes:
>  Paolo> Here is a hint. Those who use Lisp to deal with those
>  Paolo> extraordinarily complex problems do not need newbie
>  Paolo> documentation or operating system independent packaging tools.
>
> That's got to be just about the lamest thing I've ever heard.

Well, thank you for that insightful contribution.

It would be tempting, in the light of this message, to dismiss your
initial post as simply a well-crafted troll.  You haven't responded to
any of the substantive replies to your posts in any meaningful way,
contenting yourself with dismissing reasonable messages in this thread
not with argument but with insult.

However, one must be careful not to let the messenger's rather tedious
behavior to obscure the message too far; it remains true that users of
CLISP on RedHat are less well-served in the general infrastructure
than certain other Lisp programmers.  If that were generally unknown
to compiler maintainers and library writers, well, bringing it to
light in such an obtrusive fashion might have helped; however, as I
hope you are beginning to gather, such issues are not completely
unknown, and not completely without existing solutions, either.

Alternatively, maybe your intervention will motivate young,
enthusiastic programmers to join the cause of making things better.
But with rhetoric like that displayed above, my feeling is that you're
more likely to have a detrimental effect.  Is that your intention?

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Christophe Rhodes
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <sq3cb7gooq.fsf@lambda.jcn.srcf.net>
··········@yahoo.com (Igor Carron) writes:

> So let me get this straight. The community that prides itself in using
> a language that deals nicely with extraodirnarly complex problems
> dealing with recursion/combinatorial and time critical issues (Hanoi's
> towers, Orbitz search engine and so on) cannot come up with a way to
> deal with the complexity of having to deal with several OS/several
> Lisps and several libraries.

What is this "community" and who is in it?  What I see is mostly a
bunch of individuals: some extremely helpful, and a vast majority
sitting on the sidelines and carping.  There Is No Common Lisp
Community.  I'm sorry, but that's the way it is.  If you want one,
help to build one.

> I know this sounds like a bait but if one were to contemplate the
> situation from afar like a newbie would (myself being one of them), it
> really looks like a lost opportunity to prove a very powerful point.

I don't have any points to prove.  I _do_ _not_ _care_ that
Christopher Stacy has made choices that mean that he can't do some
things he whines about; likewise, I do not feel the need to proclaim
Common Lisp, or even one particular implementation of it, as The
Answer.  I care about the misinformation that has been provided, and I
have given recent history for why the current situation is how it is
to try to redress the balance.

I don't need to market Lisp as a silver bullet.  If it meets your
needs, or can be moulded to do so (that being what Lisp is generally
good at, after all) then welcome, and I'll provide such assistance as
I can; if not, then fine.

On the other hand, if I were provided with even the relatively small
budget[1] of Orbitz (though I wouldn't say no to being given the
budget for building large towers, either :-) I don't think I'd have
too much difficulty building a sufficiently complex system to evolving
specifications.  The same goes for those few out there who are not
among the carpers.

Christophe

[1] time is probably the most important bit in the equation here; but
    as Einstein proved, money can be converted to time in a
    thermodynamically reversible process.
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)
From: Marc Battyani
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bsijor$m1a@library2.airnews.net>
"Christophe Rhodes" <·····@cam.ac.uk> wrote
> ··········@yahoo.com (Igor Carron) writes:
>
> > So let me get this straight. The community that prides itself in using
> > a language that deals nicely with extraodirnarly complex problems
> > dealing with recursion/combinatorial and time critical issues (Hanoi's
> > towers, Orbitz search engine and so on) cannot come up with a way to
> > deal with the complexity of having to deal with several OS/several
> > Lisps and several libraries.
>
> What is this "community" and who is in it?  What I see is mostly a
> bunch of individuals: some extremely helpful, and a vast majority
> sitting on the sidelines and carping.  There Is No Common Lisp
> Community.  I'm sorry, but that's the way it is.  If you want one,
> help to build one.

At least there is a Common Whining Community for sure... ;-)

> > I know this sounds like a bait but if one were to contemplate the
> > situation from afar like a newbie would (myself being one of them), it
> > really looks like a lost opportunity to prove a very powerful point.
>
> I don't have any points to prove.  I _do_ _not_ _care_ that
> Christopher Stacy has made choices that mean that he can't do some
> things he whines about; likewise, I do not feel the need to proclaim
> Common Lisp, or even one particular implementation of it, as The
> Answer.  I care about the misinformation that has been provided, and I
> have given recent history for why the current situation is how it is
> to try to redress the balance.

May be he just had a bad day ? I have been puzzled by this post too.
Especially when he says that he doesn't have the time to help... BTW I tried
to install viewcvs for my open-source subversion repositories and, though
it's not in Lisp but in Python, I couldn't make it work on my Debian Woody
box. On the other hand, all the Common Lisp libraries I used worked more or
less out of the box. So YMMV as usual...

[...]
> [1] time is probably the most important bit in the equation here; but
>     as Einstein proved, money can be converted to time in a
>     thermodynamically reversible process.

I like that, but I'm not sure it's really true in the programming world. At
the very least it would be highly non linear...

Marc
From: Michael Hudson
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m3oetvrris.fsf@pc150.maths.bris.ac.uk>
"Marc Battyani" <·············@fractalconcept.com> writes:

> BTW I tried to install viewcvs for my open-source subversion
> repositories and, though it's not in Lisp but in Python, I couldn't
> make it work on my Debian Woody box. On the other hand, all the
> Common Lisp libraries I used worked more or less out of the box. So
> YMMV as usual...

This is a fair point; I'm much more a member of the Python community
than the Lisp community (whatever that means) and I wouldn't want
comp.lang.lisp to get the impression that the grass is all that much
greener on the other side.  A bit greener, in some ways, maybe, but
packaging and distributing applications and libraries seems to be a
hard problem.  At least, that's what the paucity of decent solutions
suggests to me.

Cheers,
mwh

-- 
  If design space weren't so vast, and the good solutions so small a
  portion of it, programming would be a lot easier.
                                            -- maney, comp.lang.python
From: Paolo Amoroso
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <871xqqid7f.fsf@plato.moon.paoloamoroso.it>
Christophe Rhodes writes:

> Answer.  I care about the misinformation that has been provided, and I
> have given recent history for why the current situation is how it is
> to try to redress the balance.

Speaking of history, there was a possibly less know but relevant
attempt to create an `asdf-install'-like tool. In the early days of
the CLOCC project, Marco Antoniotti, Don Geddis(?), and probably
others I can't remember, discussed the possibility of extending
MK:DEFSYSTEM to handle dependencies and versions. The discussion
should still be available in the mailing list archive.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Joe Marshall
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <ad5bog3o.fsf@ccs.neu.edu>
······@news.dtpq.com (Christopher C. Stacy) writes:

> 2.  Your software is TOO HARD to download and use.

I have run into this, too.

> In other words, the ONLY acceptable solution is the SAME as
> for all the other software that we use (for Perl, JAVA, and C).
> There has to be a series of mostly self-installing download 
> distributions, and simple documentation to tell what we need.
>
> I mean a series of tar files that includes the build scripts under 
> the standard native shell (eg. GNU Makefiles, or .BAT files).

It'd be nice, but it is damn hard.  

Where is lisp installed?  There are about 10 common places which
depend on OS, Lisp vendor, and the whims of the sysadmin.

How do you invoke it?  Some lisps require an `image'.  Some lisps have
different executables depending on what flavor of lisp you want.  Some
lisps have user init files, some have system init files, some can
execute forms from the command line, some can execute *some* forms
from the command line, but not all.  Some want environment variables,
others want to be started with the `current directory' set to an
appropriate value.  Some need the `library' on the path.  Some of
these things vary among the products of a single vendor.

I do agree with you, though.  I try to write utility code
`defensively'.  In one project I'm working on I have certain .BAT
files that do a fair amount of `environment sniffing' to figure out
how to get lisp going (and to report a useful diagnostic if it cannot
figure it out).  Still, it isn't an easy task, and I don't know what
the solution is.
From: Pascal Costanza
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <bspf4l$kpc$1@newsreader2.netcologne.de>
Joe Marshall wrote:

> ······@news.dtpq.com (Christopher C. Stacy) writes:
> 
>>2.  Your software is TOO HARD to download and use.
> 
> I have run into this, too.
> 
>>In other words, the ONLY acceptable solution is the SAME as
>>for all the other software that we use (for Perl, JAVA, and C).
>>There has to be a series of mostly self-installing download 
>>distributions, and simple documentation to tell what we need.
>>
>>I mean a series of tar files that includes the build scripts under 
>>the standard native shell (eg. GNU Makefiles, or .BAT files).
> 
> It'd be nice, but it is damn hard.  
[...]

As an additional remark: It's a bad idea to compare Common Lisp as a 
standard for a family of implementations to single-vendor languages. 
Languages like Perl and Java provide a better "user experience" because 
library providers only have to care about one implementation, and that's 
it. Common Lisp has different goals in this regard.

If you are looking for the advantages of a single-vendor language, then 
just go with one particular Common Lisp implementation. I think the 
situation isn't too bad in that light.


Pascal

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Tim Bradshaw
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <fbc0f5d1.0312300839.1fc51314@posting.google.com>
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...

> As an additional remark: It's a bad idea to compare Common Lisp as a 
> standard for a family of implementations to single-vendor languages. 
> Languages like Perl and Java provide a better "user experience" because 
> library providers only have to care about one implementation, and that's 
> it. Common Lisp has different goals in this regard.

While I agree with the spirit of this (it's the usual class/instance
confusion that leads to idiocy like 'lisp is slower than Perl') I
think java is a bad example.  There are indeed multiple Java
implementations, and it might be a good idea to look at what the Java
people did right to make things better for Java.  One obvious thing is
`specify the language in terms of a virtual machine' meaning that
things like binaries can be shipped.  I suspect another is `spend
hundreds of millions of dollars on solving the problem': I'm fairly
sure if someone was willing to invest that much money on standards for
Lisp library distributions the problem would not be so acute. 
Meantime the problem has to be solved by some bootstrap process where
there is (initially) no money.  This is hard, and I'm not sure that
any non-single-implementation systems have done it (even, say C and
Unix were initially essentially single-implementation, and actually
building & installing nontrivial C programs on random Unixoid systems
isn't always that easy even given the huge money that's been spent
there).
From: Gene Kahn
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <4d3f9c15.0312301048.559cab6c@posting.google.com>
[Not directly in response to Christopher C. Stacy's post, but in
keeping with the spirit of the discussion]

What seems to me to be very paradoxical is that, despite Lips's long
life, despite its superiority as a language, the claim that desirable
functions that any language has can be easily MOPped into it, the
apparent high level of intelligence and skills of its practitioners,
Lisp since day 1 has always been *irrelevant* to the computing
industry. At any point in its 40 years of use, take away running Lisp
code in the world and the effect would be negligible, confined to
companies you can count in one hand. Consider taking away running code
of FORTRAN and COBOL  during their prominent years, and now C, C++,
and even HTML (if that is a language), and major portions of the
industry will be crippled.

Lisp is irrelevant to the computing industry and will *always* be. 

My take on this is that because Lisp (the language, the IDE, the
libraries, the knowledge to make it work, help) has always been
inaccessible to mainstream programmers (though lately Lisp IDEs are
freely available).

Keep the current Lisp, for those who thrive in it. Build another one
and bill it as an XML language for all of us (as opposed to ARC, the
language for the intelligent), make it as easy to use as PHP and, as
with PHP, embeddable inside HTML -- that is where mainstream
programming is happening.

gk
From: Gareth McCaughan
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <87u13iqfw9.fsf@g.mccaughan.ntlworld.com>
·······@yahoo.com (Gene Kahn) writes:

> [Not directly in response to Christopher C. Stacy's post, but in
> keeping with the spirit of the discussion]
> 
> What seems to me to be very paradoxical is that, despite Lips's long
> life, despite its superiority as a language, the claim that desirable
> functions that any language has can be easily MOPped into it, the
> apparent high level of intelligence and skills of its practitioners,
> Lisp since day 1 has always been *irrelevant* to the computing
> industry. At any point in its 40 years of use, take away running Lisp
> code in the world and the effect would be negligible, confined to
> companies you can count in one hand. Consider taking away running code
> of FORTRAN and COBOL  during their prominent years, and now C, C++,
> and even HTML (if that is a language), and major portions of the
> industry will be crippled.
> 
> Lisp is irrelevant to the computing industry and will *always* be. 

                      ______
                     /      \
                   .' PLEASE `.
                   |  DO NOT  |      _____
                   | FEED THE |    ,'.....`.
                   `. TROLLS ,'  ,'........ )
                     \_    _/   |........ ,'
                       |  |     `. .... _/
                       |  |      ,'.,'-'
                       |  |     /../
                       |  |   ,'.,'
                       |  |  /../
                     . |  | /..'
                   .\_\|  |/_/,
                   ___ |  | ___
                     . `--' .
                      .    .


-- 
Gareth McCaughan
.sig under construc
From: Christopher C. Stacy
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <uhdzi9kxa.fsf@news.dtpq.com>
 Gene> Lisp is irrelevant

Then why are you writing about it?
From: Thomas Lindgren
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m3zndavuyr.fsf@localhost.localdomain>
·······@yahoo.com (Gene Kahn) writes:

> Lisp is irrelevant to the computing industry and will *always* be. 

Lisp is irrelevant to the mainstream like sportscars are irrelevant to
the average station wagon owner. 

(Whiling away the time with useless metaphors, I kind of like thinking
of Lisp as a sportscar: lots of tinkering possible, a number of
idiosyncracies, exhilarating when used by a skilled driver, and the
features percolate to the rest of the business after ten or twenty
years or so.)

Best,
                        Thomas
-- 
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
 
From: Duane Rettig
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <4vfnx6ev4.fsf@franz.com>
Thomas Lindgren <···········@*****.***> writes:

> ·······@yahoo.com (Gene Kahn) writes:
> 
> > Lisp is irrelevant to the computing industry and will *always* be. 
> 
> Lisp is irrelevant to the mainstream like sportscars are irrelevant to
> the average station wagon owner. 
> 
> (Whiling away the time with useless metaphors, I kind of like thinking
> of Lisp as a sportscar: lots of tinkering possible, a number of
> idiosyncracies, exhilarating when used by a skilled driver, and the
> features percolate to the rest of the business after ten or twenty
> years or so.)

And, once in a while, a driver will walk away from a track with a
huge purse won there.

-- 
Duane Rettig    ·····@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   
From: Scott McKay
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <K_jJb.717912$HS4.5169072@attbi_s01>
"Thomas Lindgren" <···········@*****.***> wrote in message
···················@localhost.localdomain...
>
> ·······@yahoo.com (Gene Kahn) writes:
>
> > Lisp is irrelevant to the computing industry and will *always* be.
>
> Lisp is irrelevant to the mainstream like sportscars are irrelevant to
> the average station wagon owner.
>

For what it's worth, I agree with the notion that Lisp is
irrelevant to the mainstream of the computing industry,
and I'm glad that it is.  Even though I do not myself
drive a BMW, I use the Beemer metaphor -- it's a
small company with a tiny market share, but nobody
questions the quality of the product or the longevity
of its niche.

I'm glad Lisp is overlooked by the mainstream, `cuz
it gives a few of us a substantial competetive advantage.
I am presently employed at ITA Software; what we
have built could not have been built in anything but
Lisp.  I am working on a follow-on product at ITA,
rewriting and modernizing a central piece of legacy
software; what I am doing in Lisp (alone right now)
originally took hundreds of people to do, and I could
not be doing so much in any other language I know
(well, except for maybe Dylan).
From: Scott McKay
Subject: Re: Why Lisp is too hard for me to use
Date: 
Message-ID: <m0kJb.43303$xX.154005@attbi_s02>
"Thomas Lindgren" <···········@*****.***> wrote in message
···················@localhost.localdomain...
>
> ·······@yahoo.com (Gene Kahn) writes:
>
> > Lisp is irrelevant to the computing industry and will *always* be.
>
> Lisp is irrelevant to the mainstream like sportscars are irrelevant to
> the average station wagon owner.
>

For what it's worth, I agree with the notion that Lisp is
irrelevant to the mainstream of the computing industry,
and I'm glad that it is.  Even though I do not myself
drive a BMW, I use the Beemer metaphor -- it's a
small company with a tiny market share, but nobody
questions the quality of the product or the longevity
of its niche.

I'm glad Lisp is overlooked by the mainstream, `cuz
it gives a few of us a substantial competetive advantage.
I am presently employed at ITA Software; what we
have built could not have been built in anything but
Lisp.  I am working on a follow-on product at ITA,
rewriting and modernizing a central piece of legacy
software; what I am doing in Lisp (alone right now)
originally took hundreds of people to do, and I could
not be doing so much in any other language I know
(well, except for maybe Dylan).