is there any other market for which this is true and which you can make a
  reasonable comparison with, or are you making a claim that software is
  unique?  if the latter, I'd be much more interested in your reasoning
  than in your conclusion.

  this must have been in the times of _really_ expensive long distance or
  international phone calls.  if you get a system for a period to try it
  out, without paying for it or with a full refund policy, what does it
  _take_ to satisfy your demands?  I don't know a single market where you
  are actively disallowed from determining whether you can use a product
  _except_ software _other_ than Lisp environments.  and considering that
  people can learn Common Lisp with free environments, just what are you
  going to consider before investing in a commercial environment that needs
  it to be free or extremely low-cost?

  all of you guys who scream and shout about low-cost Common Lisp systems,
  do you _really_ go out and _buy_ the low-cost versions of all the
  environments of all the languages out there to try them out?  I don't
  think anybody actually does that.  if you wanted to take a test-drive,
  how come you accept the policies that come with shrink-wrapped software?

  I wonder: what is the _real_ argument behind all these weird claims?

  people see what they want to see, apparantly, and that might just sum up
  this fruitless "discussion".  but anyway, I have never heard of ghettos
  being warm and welcoming towards outsiders who would like to know them --
  "ghetto" to me sort of means exactly the opposite: keeping people out and
  not letting insiders out, either.  I have never heard of ghettos who are
  willing to listen to people outside when they have a valid point, either
  -- it sort of defeats the whole purpose of a ghetto.  I have also never
  heard of people who try to explain why they don't join the masses as
  being a "ghetto".  I'd might settle for "elite" in some cases, the same
  way I certainly would agree some of my other tastes are "elite" even if
  it were flung at me like the accusation that your "ghetto mentality" is.

  obviously, you and I have very differing views about ghettos and their
  mentalities, Andrew, and I'm sure we'll never find anything at all to
  talk about, anyway, so let me just tell you that if you want to accuse
  people of an attitude that is entirely one of your own, don't act very
  surprised if you meet hostility on your way, but please be smart and
  honest enough to realize that the ghetto mentality is around yourself and
  is your own attitude to people _you_ want to keep a distance to, and that
  that is the only reason you keep seeing it.

| I don't feel I am a "better" programmer when I use one language rather
| than another ...

  I'd like to you do some soul-searching and discover for yourself where
  the need to write this statement _actually_ comes from.  then apologize
  to me for imputing it to me.  thank you.

| So, finally, my summary is: if Java attracts less skilled programmers
| that is more because it is popular (maybe because it is more suited to
| a code-shop approach) than because Lisp is necessarily "better".

  you obviously equate "less skilled" with "liar".  that is also an
  attitude entirely of your own creation, and I would again like you to
  think very carefully about why you needed to make it appear to be mine.
  in my world, you don't usually need to lie if you are actually skilled,
  but lying and being skilled are completely orthogonal qualities.  I
  challenge you to imagine these two people: person A is a very honest
  person who is currently not skilled in field F, and he sets out to learn,
  and he does obviously not tell anyone that is is skilled in field F.
  person B is actually very skilled in field F, but is so insecure that he
  is constantly lying about his skills and alsowants people to believe that
  since he is skilled in field F, he is also skilled in neighboring fields
  E and G.  now, think very carefully about these two people, Andrew, and
  read this sentence again:

    then you go do complex stuff that insecure losers who lie about their
    Java skills can't even imagine, and therefore do not consider part of
    the competition.

  is it person A of little skill or person B of much skill I am talking
  about?  if you think it is person A, I will conclude that you are a
  deeply dishonest person yourself.  if you understand that it is person B
  that I might be talking about (one of little skill may also be lying), I
  think you should publish your deeply felt remorse for having tried to
  impute a bunch of dishonest views to me.

  of course it's easier to implement Emacs in Guile than in C, but Guile is
  implemented in C, which makes it much harder to implement Emacs.  because
  any Scheme used in the real world will accumulate approximately 6 billion
  special-purpose functions that do very small things because Scheme does
  not support abstractions conveniently and nobody can agree on how to do
  it inconveniently, Guile will do a full circle and be approximately 360
  times bigger than Common Lisp (except all the OO stuff will be glued on
  inefficiently, because OO is complex and Scheme is simple and elegant or
  so says the book, therefore the OO stuff is always too complex, so yet
  another attempt is always needed as soon as the last attempt approaches
  useful asymptotically from below), with cultural differences in naming
  and argument conventions and such, and then someone will come along and
  write a Common Lisp layer on top of everything, just like cl.el because
  Emacs Lisp actually sucks, but at least we know _how_ it sucks, unlike
  Guile, which will suck in entirely new, and much improved, ways.

  also, Emacs is easier to implement in Guile because it hasn't actually
  been done, whereas we know exactly how hard it was to do it in C and a
  dynamically scoped Lisp (and nobody will ever do _that_ again, which also
  means it's trivially easier to do it Guile, simply because someone is
  actually trying to do that.)  and obviously, whoever thought it would be
  easier had ignored the fact that Guile Emacs needs to implement Emacs
  Lisp, too, considering the millions of lines of really crappy Emacs Lisp
  out there that gets run at completely random times because it has wound
  up in default.el and .emacs and such, having been copied all over the
  globe across amazingly lossy connections that each introduce a minor
  mistake on every copy, and equally amazingly, doesn't work at all from
  version to version of Emacs, or from the system admin's equally messed up
  changes to default.el from week to week as users complain.  oh, joy!

  this is Emacs.  this is Guile.  this is Emacs on Guile.  any questions?

I don't think the Scheme interpreters used in CS curricula made this
any worse. Without them you'd probably have even fewer Lisp programmers
today and a bigger Modula-2 crowd who'd use "#define BEGIN {" to get
any work at all...

We can argue 'til the Second Coming scheduled in a few months, but all
this 'open-source' think is the hype of the moment and I guess it will
stay that way for quite a long time. All this idle chatter about Apple
supporting open-source while Microsoft doesn't, the fanatic marketing
of Linux by its rabid supporters. etc shows that there's something going
on. Hey, if guys like RMS, ESR or Linus Torvalds manage to get into  the
mainstream press it shows how important computers get and how a basically
nice thing gets blown up beyond proportion.

Remember when Java came out and every new project had to be written in
it, even if the manager just read the name in his Wall Street Journal?
Open-Source(tm) is in the same league right now.

If you're a independent 'consultant', hired to solve a problem on
you own, it doesn't matter what language, environment or even
operating system you're using ("We need a high-performance web
server!" "Ok, I'll use CP/M and my hand-crafted Tarantula
web-server written in FooForth" "Erm, okay, just go ahead...").

But that isn't the only breed of programmer out there. And sometimes
the choice what language to use isn't up to you. You're more likely
to sell Lisp to your local pointy-haired boss if you say it's
"object-oriented", "open-source" and "provides increased synergy
for leveraging client-server paradigms". Besides, for a large
group of developers the money you save can add up to a relevant
sum.

And don't forget the hobbyist camp. Just a few years ago, it
wasn't very likely that the new programmer you just hired could
play with the environment you're using in the comfort of his
own home. Then there came PCs and all those nice Borland compilers
and now you have a huge bunch of 'Unix worksations' around
somewhere. If the new employee already knows how to handle
Makefiles, CVS or other C crutches, you save quite some training
time.
One might argue, that this is even more important for Common
Lisp environments. The Lisp portion might be 'common', the
rest isn't...

Filesystems and the way they are used today are a relic of Unix and
the 70s when machines had very little RAM, even though nowadays your
basic Mac or Gateway/Dell comes with 128MB or so. Netscape takes about
7 seconds to start up on my P200 MMX if there has been a lot of memory
activity since its last use or after a fresh boot, or 4 seconds if it
just crashed or was shut down. It spends this time searching for and
loading shared libraries for image handling, searching for and loading
plugins, parsing the 794k /usr/lib/netscape/Netscape.ad configuration
file, and doing about 30 other distinct things. The resulting image in
memory is more less the same each time, but unless I have the sources
and compile the binary file just as I want it, I must tolerate things
as they are.

A feature of Lisp systems has always been that you can save images;
that you can dump and restore heap to and from core. I'm not sure what
the MIT CADR had in terms of RAM, but I think it was in the
whereabouts of 512 kilowords. As far as I know the Symbolics 3600
debuted with 2 megawords, 36 bits per word.

Many times, especially with something like a large database, you don't
want to parse some textual representation of configuration or state
off of a filesystem but instead you want heap. With a Lisp system you
can dump and restore your application's heap, and you can arrange an
interface to this ability for your users as well so that they don't
have to wait for their configuration data to be parsed and loaded on
each application boot. With a Lisp Machine you can dump and restore
your entire operating system's image so that you don't ever need to
start up an application if you always just want it there and ready to
go after boot.

My 20MHz Lisp Machine can go from shutdown to a Zmacs buffer in a
graphical GUI faster than my 200MHz Linux box can go from shutdown to
a mounted filesystem, loaded X windowing system, and loaded Emacs. (If
the Linux box weren't SCSI it would probably boot faster than the Lisp
Machine though; there are at least 2 five-second pauses during boot do
to SCSI: one during BIOS hardware probing and initialization and
another after Linux SCSI device detect when the bus is reset. This is
part of the hardware brain-damage aspect of modern PCs though which
are architecturally based on junk that was easy to mass-produce for
consumers in the early 80s and not designed to scale in any area at
all.)

I have been in exactly this situation on Xerox lisp machines. I
suspect in any case that the machines were a huge example of this
`sacred sysout' syndrome (Xerox called world loads or images
`sysouts'), but on top of this, we had a sysout which had various
stuff in it, some of which was now unwanted and we  had to work to
turn off, which no one knew how to reconstruct any more.  I was a lot
younger then so this didn't seem quite as frightening as it does now.

It's interesting that Windows machines seem to rather frequently get
into this state.  Because there is (typically) rather poor control
over all the shared libraries & stuff they have, you end up with these
machines which will run stuff that you can no longer install on other
machines for reasons which are often totally opaque (to me, anyway,
the Windows people probably say the same stuff about Unix, and we both
say it about Macs).  Worse still is when the machine that *would* run
stuff mysteriously stops doing so (usually because someone has
secretly installed doom or something & trashed some bit of state in
there).

I've never been in quite this state with a Symbolics, but they had a
lot more control over state than the Xerox machines did (though still
not enough in my opinion).

--tim

Hartmann Schaffer

  so people who can't use Lisp for free won't know that they should use it
  because they don't know what it is, but people know they should use CLIM
  and can't because it isn't free?  I don't get it.  how did they discover
  the need to use CLIM to begin with?  

  there's something going on that is not at all about the issues you guys
  keep dragging up.  this is _so_ not about free environments!  can't you
  guys do us all a favor and stop hitting on that single argument and be a
  little more precise in what you're _actually_ after?  this is just like
  listening to people who have thought up a solution to all the world's
  problems and keep whining that nobody will do as they say.  that's not
  how this world works.  you can't decide for yourself that you have the
  solution and then go apply it to all problems.

  where is this "free environment" requirement _coming_ from?  people go
  through their very expensive educations, most spend half their life
  paying back the loans or saving up for their own kids to get educated,
  and then they suddenly want one particular thing for free or they won't
  even try, but will instead sit there and whine that it isn't free.  who
  gives a fuck about these people?  _I_ don't want to give such people
  anything at all, especially not for free.  I don't expect those who have
  what they want to have very different sentiments, even if they, like me,
  have given away tremendous amount of work and values previously.

  what happens when CLIM is available for free?  hey, it might need MOTIF.
  whine, whine, MOTIF isn't free, so we can't use CLIM, and we can't use
  Common Lisp because we can't use CLIM, and life is hell, or whatever.

  what I _really_ don't understand is why you guys all want somebody else
  to take a huge risk (providing expensive software for free) when you
  obviously won't take the slightest risk yourselves (spend the time to
  learn something from the manuals).

  what's hugely important in the free software world is to distinguish
  those who will not stop asking for more from those who can make do with
  whatever they get and return something useful to the community.  I have
  come to conclude that the successes of those who cry for more has made it
  hard for those who want to work something out for themselves to keep up
  their spirits.  in my view, whining should be punishable by law, and
  parents who give in to whining should be punished, too, because I guess
  the only reason grown men whine when they can't get something for free is
  that they are reduced to children who don't get what they want from
  whoever they still think has an obligation to cater to their needs, and
  they could only have learned that from weak-willed, unfit parents.

  make take on this is: just fucking do it.  we're programmers, damn it!
  the whole _point_ is to bring stuff into existence that exist merely in
  our dreams and on our wish lists.  yeah, it sucks that we have to live
  with inferior solutions instead of perfection all around us all the time.
  yeah, programming is frustrating at the very core of the task, but do we
  not do this because we want to solve problems that are too hard to do
  manually all the time?  why does this not apply to our own tools?  and if
  it does apply, why does it _have_ to be free?  I really don't get this.

  we can only expect that which is extremely well-known to be free, because
  the dilution of investment that this information society is all about is
  itself an extremely expensive process -- making a new concept into common
  knowledge is estimated to cost more than 10 billion dollars, and it has
  to be a community effort, with journalists, authors, teachers, and even
  politicians involved in its spread.  it is clear to me that graphic user
  interfaces and window systems are still largely unknown technologies and
  that getting it usefully right involves a serious investment in genius
  time.  in particular, doing something that is intended to track the
  myriad failures that Microsoft is going through with their random trial
  and error-based development process with beta-testing using customers and
  software developers who do it only because they are afraid to be left
  behind the times, is doomed to equal or greater failure from the start.
  to get this stuff right probably needs a whole new infrastructure, and
  that won't happen until the paranoid psychotic behavior of Microsoft is
  stopped and people can actually begin to develop real software again.

  my suggestion is to write software that is completely independent of its
  graphic user interface, using protocols and very abstract programming
  interfaces between the user interface module and the functionality that
  enables a protection of investment in the functionality even while the
  user interface keeps changing.  sadly, this is not a programming style
  that "modern" programmers know how to write, because they have been
  reduced to deal with user interfaces that invade the entire system.

Those of us from the Genera camp felt a good deal of personal
embarrassment at the degree to which our attempts to influence product
direction were rebuffed within Harlequin.  Although it was politically
improper within Harlequin to frame it this way (and the fact of that
political issue made it hard to confront the issue directly), this
was perceived in the US as very much a US/UK clash.  The UK had strong
hold over the sources and things didn't get done unless the people in
the UK wanted them done.  In the US, it was perceived very much as an
NIH problem [not invented here], since CAPI was from the UK and CLIM
was from the US.  I suspect that in the UK the thought was that CAPI
was just technically better, and people probably don't realize the degree
to which this didn't sit well with the US.  Of course, it's common with
NIH for people to not frame it that way in their own minds.  But the fact
that there was never a meeting to simply resolve this fact once and for
all was telling.

Indeed, Harlequin had very few mechanisms for resolving internal wars
of this kind.  This management shortfall was touted at the time as one
of harlequin's strengths; Harlequin has some good software, but would
have had a lot more of it, IMO, without this "strength".  I can only
hope that now under new ownership and management, that fact will
change.  I think a solution to the various long-festering problems
(CAPI vs CLIM, LCL vs LW, Dylan vs Lisp, etc.)  is key to its ever
digging itself out of the financial pit it's in of late.  And I have
to say that in this post-Dilbert era, few are the companies that have
cried out for "more" (rather than "less") management, so you can see
just how far Harlequin had gone...

But in any case, I wrote this message mainly to say that this CLIM-based
development system did exist.  Bad enough for poor old Scott McKay that
no one ever used the fruit of his labors but to have people deny it ever
happened on top of it is too much.  Surely he must feel the kind of
private agony over this that I was remarking the other day I had felt
about the CL HyperSpec being buried for so long before its release.
Scott just didn't have the energy to push as hard for bagel's release.

Nature takes the path of least resistance, thus humans naturally want
something for nothing.  We all do.  Part of growing up is learning
that the world doesn't work that way (at least most of the time and
when you can keep liberals away from the budget).

I think part of the problem is the environment in which Lisp was
originally developed - the college hacker community which McCarthy
used as his work force.  In this particular venue, software was viewed
much as literature; to be read, enjoyed and learned from.

Unix in general suffers from the same fate - most people know that
AT&T licensed the source for Unix and the development system to
universities, basically for nothing, for years.  They really didn't
treat Unix as a product until version 7.

All of us who went through college during this period and did any
computing became accustomed to the use of free (more rightly
"subsidized") software.  Was it a good thing?  Probably not given the
trend today of treating every burp as "intellectual property" and
suing at the drop of a hat.  

Hindsight is perfect - foresight is cloudy at best.

Those who write the code get to choose the license, no whining
allowed.  It's a truism, but it seems to be forgotten quite often.

Lisp systems require a tremendous amount of resources to produce in
their entirety.  They are on the outer edge of what Free Software
production practices are capable of creating, and these systems are
not even complete.  Even if someone GAVE us a free CL, there is IMO,
no way it could be supported without significant infrastructure.  It
is indeed expensive software, very expensive to produce and maintain.

This does not mean privatisation of that code base, but at least an
organization who is making a significant investment in the system.
Cygnus and others provided these resources for gcc, without which the
compiler would be nowhere near as usable and portable as it is today.
Despite recent hype, Free Software does not maintain itself.
Harlequin and Franz have put *tremendous* effort and resources into
their systems, that cannot be overlooked.

The code bases are their already in CMUCL, CLisp and others.  So you
can help build the infrastructure to maintain these giant systems by
either becoming a developer yourself and contributing your time and
energy, or you could find a way to get more developers involved.  One
way to do that is to pay people to work on the system.  That might
mean starting a company that sells support contracts or customization
work or any other Free Software business model.

I think that competitive and complete Free Lisp systems are a
possibility, but not by whining for the commercial vendors to free
their investments as loss leaders or something of that sort.  Those
who want it need to take responsibility for making it happen, and that
means giving energy, time, and thought to how it can be done.

"Just because it's free doesn't mean you can afford it."

This abstract approach works between GUI tools that work
similarly. For example, with GTK, Motif, QT, Swing or 99% of other
tools out there you basically begin by creating a window, then layout
basic areas of your app using the GUI tools' implementation of the
layout manager concept, then add a menubar and menus, buttons,
scrollbars and myriad other widgets and gizmos, and then you finally
associate mouse and keyboard events with these objects with your
program's control-flow.

With CLIM you don't spend your time laying out widgets and then set
them up to handle "low-level" keyboard and mouse events. (Though it
supports this paradigm kinda like Lisp supports the BASIC/flowchart
control-flow paradigm via TAGBODY/GO, but I digress....) CLIM actually
has very few widgets; it doesn't even have pull-down menus and
menubars that 99% of GUI apps nowadays have. (Though it has all the
primitive functionality you need to implement them and I think there
is a free implementation floating around the net like at the AI
Repository or something....)

Anyways, saying that you can write an application with a graphical
user interface using abstract protocols and abstract programming
interfaces and then using Motif or Emacs as the tool to the
realization of your application's GUI is as meaningful as saying that
you can write a program using abstract concepts of OO and control-flow
so as to be independant of the implementation language and then
writing it in C.

The real problem with CLIM is that people don't "get" CLIM (many don't
even get the chance to "get" it) kinda like you might say that the
problem with Lisp is that people don't "get" Lisp and its "unsane"
syntax that "wears out the top row of your keyboard." Lisp isn't for
"hello world" applications and CLIM isn't for tic-tac-toe
players. Lisp is a good language for creating, for example, a
real-time news distribution system for a financial news agency and
CLIM is a good GUI tool for creating an intuitive, natural and
powerful monitoring and control application for a real-time news
distribution system that facilitates the exploration of and recovering
from error conditions in a very efficient and natural way and lets you
quickly pick out what you are looking for from 30MB of logging
information and enables you to generate different kinds mouse
sensitive information displays and reports from real-time and log
information in a very efficient, cool and attractive way (not to
mention printer-friendly), without needing 6 menus on a menubar each
containing their own nested menus and about 15 buttons and widgets and
text entry fields and a help menu giving documention on what all that
crap does, or needing to type in forms into a listener after figuring
out what it is you need to type and painstakingly writing a custom
parser to check errors at read time or some other way if you plan on
giving your users some control and customization ability via typing in
forms directly.

I don't see what vendors risk by letting people get a copy of CLIM to
learn to use it with. Sure, we're not entitled to it, but I only see
it helping Lisp and the vendors and community in general. I'd rather
have a CLIM from a commercial vendor that works with a free Lisp then
have a free version of their Lisp without CLIM. Lisp isn't dying nor
on the way out, and it is possible to get good information and books
on it and decent free implementations, making free versions of
commercial Lisps really nice to have but not essential if you just
want to learn the language, but CLIM seems to be on the way out and
you can't learn to use it for free nor get your general questions
about working with it and learning it answered anywhere and it's
really sad and frustrating.

cba...@2xtreme.net (Christopher R. Barry) writes:

I am *not* asking CLIM for free.  I am asking why Franz and
Harlequin keep distributing Common Windows and CAPI *bundled* (read:
almost "gratis") with their systems (even the "free" editions
downloadable from the net), instead of phasing them out and start
shipping CLIM in the *same* fashion instead (i.e. with no extra
charge).  (Alright, Harlequin seems to be doing something like that
when you by their Professional Edition).

I believe that all the developers in those outfits see this point.

Cheers

They must have done something right:

   MCL ships with almost complete source code for the
   user interface stuff:

   Editor, Tools, Interface Designer,
   Menus, Windows, Dialogs, Widgets, IPC, Processes,
   Read-Eval-Print loop, networking, some stuff from Common Lisp
   itself, ... It's a bit like Genera (where you have
   much of the source for the OS). You can
   type "process-run-function" and press Meta-. and
   you get the source.

On the other hand, LispWorks ships with no source.
CLIM ships with no source. Does ACL come with source?

I would like a more open approach to delivery of
source code. Let people read and learn, let them
change it, let them write new versions, let them
improve things, ... - if you fear that users will
break things, then you are already dead.

I think this is missing the point.  (Note: I am not writing this on Erik
Naggum's `behalf,' as it were, but to show that somebody else also
understands this issue in such a way.)

The point about the abstract protocol and interface is this.  An
application with a user interface should not be built as one
homogeneous whole.  In other words, many (or most) GUI
applications are built as a `single agent,' where the part that
does the actual work is intertwined (in an inseparable way) with
the part that takes care of interacting with the user.  (Very roughly
speaking, the `work loop' of the application and the `UI loop' handling
GUI events are one and the same loop.)

A much better approach is to build the application as a system of at
least two separate agents, one being the `work horse' taking care of
the working functionality and the other being the `front end' taking
care of the user.  The interaction between the two agents is done
according to a protocol that is, among other things, independent of
the particular nature of the user interface.  Thus, for example, one
could substitute a GUI for a command-line interface just by replacing
the second agent, and both versions would have the same user
functionality (though they would differ in ease of use, user productivity,
etc. (note that I just say `differ': I am not going here into details which
one is better, and in what aspects)).

This is not something new, of course.  Client-server systems are a
particular case of this architectural principle.  Consider, for example,
that the interaction between an FTP server and an FTP client is based
upon an abstract protocol that can express the functionality of file
transfer, and the client can be controlled by a command line or
a GUI and the user can run any kind of client at will.  (The case with
HTTP is more complicated as some of the UI functionality is
represented in the content being exchanged, i.e. in the HTML tags
in the pages, possibly containing JavaScript or Java code, etc.)

(What I have written above is essentially repeating Erik Naggum's
point in more words.)

  [...]
  > Lisp is a good language for creating, for example, a
  > real-time news distribution system for a financial news agency and
  > CLIM is a good GUI tool for creating an intuitive, natural and
  > powerful monitoring and control application for a real-time news
  > distribution system that facilitates the exploration of and recovering
  > from error conditions in a very efficient and natural way and lets you
  > quickly pick out what you are looking for from 30MB of logging
  > information and enables you to generate different kinds mouse
  > sensitive information displays and reports from real-time and log
  > information in a very efficient, cool and attractive way (not to
  > mention printer-friendly), without needing 6 menus on a menubar each
  > containing their own nested menus and about 15 buttons and widgets and
  > text entry fields and a help menu giving documention on what all that
  > crap does, or needing to type in forms into a listener after figuring
  > out what it is you need to type and painstakingly writing a custom
  > parser to check errors at read time or some other way if you plan on
  > giving your users some control and customization ability via typing in
  > forms directly.

Just for the record, this sentence contains 193 words (and no indentation).

  [...]