yes, that's exactly it: apparent.

| Without interest there is only disappearance and death, and this makes
| popularity seem essential to me.

  popularity is essential for the mass market.  the sustainability in other
  markets, of which most are far more interesting than the mass market, is
  damaged by popularity, meaning interest from the general population.  for
  instance, enormous markets are dependent on company-to-company sales and
  would be completely unable to educate enough people to deal with regular
  joes as customers.  these are the professional markets.  I stay clear of
  the consumer markets whenever possible, and go through a lot of work to
  get professional products.  the really sad thing is that they often cost
  _less_ than the consumer products, but if they volume went up, so would
  the price.  for instance, doctors, dentists, and vets use this highly
  absorbant material to clean up leaking body liquids of all colors and
  contents, and I got a bunch of this material when my cat had an operation
  and she did not have bladder control while recovering from anesthesia.
  so of course I bought 10 lbs of this stuff from my vet -- it far exceeds
  the absorbancy of _any_ of the consumer paper towels on the market and a
  box of 10 lbs costs the same as about 4 lbs of consumer paper towels.
  now, the reason for the low price and high quality is that people don't
  know about it, don't need to buy small units of it that are convenient to
  households (it comes in stacks of individual sheets, not rolls) in all
  sorts of stores, and there's no marketing for it at all.  which means: no
  sales force to talk to all the stores or chains that might stock it, no
  shipping costs to absord into a retail price (the purchasers pay for the
  shipping from the one outlet in the entire country), etc, etc, etc.  this
  stuff would end up costing more than five times as much as it does today
  if it were to hit the consumer market (of course I asked the people who
  make it).  which probably explains why the paper towels are all low
  quality: the cost of producing a roll of paper towels is less than 10% of
  the price customers are paying for it.

| LISP is by no means on that path (yet), but it seems (to me) to be almost
| a general opinion that it is not as popular as we'd like, either.

  Lisp is a professional product in the professional market.  it would be
  very seriously harmed by becoming a consumer product.

| I would hesitate to say that I am completely happy with them, but I
| prefer that computers are popular, and thus readily available and
| growing rapidly, than that they would have "fallen to the wayside"
| because they lost a battle with a competing inferior technology...

  huh?  Intel and Windows _are_ inferior technology and they're winning,
  leaving all the quality designs by the wayside.

| I can tolerate the lowering of quality on the microscopic scale because
| of the increase in quality overall.

  but we have a decrease in overall quality!  40 years ago, producing a
  business letter had a cost relative to company expenditures in general
  that was about half of what it is today.

| The choice in CPU on a machine only seems relevant for assembly-language
| programming and nitpicking;

  really?  ever heard of any of the numerous Intel bugs?

| Standards such as CL, CLIM, and CLOS protect us from the details of the
| inferior processor we are running on and allow us to work in a more
| comfortable programming environment whatever CPU or operating system lies
| beneath.

  this is not true.  somebody has to care about the CPU to make the
  software run on it.  making highly optimized code for something so
  braindamaged as the Intel instruction set, which isn't even relevant to
  optimization, anymore, as the underlying parallelized microcode-like
  instructions have everything to do with the pipeline, cache, etc, is so
  hard that it takes _years_ of effort to get it optimal.  I have seen code
  that ran 8 times faster just by reordering the instructions on a Pentium
  II.  stuff like this matters a lot more than people would like to believe
  when they use high-level languages, because the computer doesn't go away
  just because we don't _have_ to worry about it all the time.  we _should_
  worry about it, but not all the time, and not for everything we do.

| Thats part of what attracted me (and others) to LISP, is its rich library
| of abstract constructs, and the powerful ways you can add and extend the
| library with minimal effort.

  all fine and dandy, but it has to run on a real CPU, and there's a
  dramatic difference in CPU's that make running anything useful on them
  easy or hard.  this translates to sluggishness of development and
  adoption of new instruction sets.  look at the SPARC -- it has managed to
  upgrade itself 6 or 7 times, and have changed a lot in the meantime,
  because the users were professional users who upgraded everything or were
  satisfied with software emulation of various instructions.  the Intel CPU
  can still run 8086 code, because consumers hold on to old software even
  when they upgrade the hardware, and the third-party investment in the old
  instruction set is so enormous that they couldn't change it dramatically
  without risking that nobody would follow them.  this leads to CPU's that
  are _very_ expensive by today's technological standards.  done right, a
  new chip could cost a lot less and run a lot faster, and we have it:
  Digital Equipment Corporation (rest the blessed soul) produced the first
  processor to break the 100MHz barrier, and it's still amazingly fast.  of
  course, with despicable Compaq buying it all up, it's going to run the #1
  sluggish software in the world: NT, so it basically runs just as slowly
  as Linux on a computer two Intel generations ago.  that's how the world
  doesn't win through popularity contests.

Lisp is `sufficiently popular' if anyone who really wants to make a
living doing Lisp-related work *can* do that.

I think this is much better than the normal `we'd like there to be
more Lisp' because it depends on whether people *want* to do Lisp.  If
no one cares any more them no one will do it, and it's still as
popular as it should be.  It probably does not work from a vendor's
point of view -- they (I think) should like Lisp to be more than
sufficiently popular because they then make more money.

Whether Lisp *is* in fact sufficiently popular by this measure I don't
know.

What I'm saying with all of this is that the situation with the
super-absorbent stuff, which costs less than consumer stuff but offers
better performance, is not really analogous to the situation with the
Alpha processor, which costs a lot more than a consumer (Intel) system
that delivers comparable performance for many applications like Apache
servers, RDBMSs, Beowulf clustering, etc....

You even went with a dual P-II 400MHz system with 512MB for your own
personal development system. [IIRC.]

[Don't hesitate to provide me with a professional contact for cheap
Alpha hardware and prove me wrong! :-) ]

If so, then you are right; Lisp IS a professional product in the
professional (i.e. educational and research) market.

I can only question whether entrance into the mass market is powerful
enough to seriously harm a strongly standardized language like LISP
(well, ANSI CL).

Do you know of similar products (i.e. programming languages) which were
seriously harmed by entering the consumer market?

Languages that are common in the mass market now are C, Java, C++,
Visual Basic, and Pascal (Delphi etc.).  These languages, as far as I
can tell, were not changed by the introduction to the mass market at
all; in some cases they were improved somewhat (such as Borlands
additions to Delphi to make it object-oriented).  C is also an ANSI
standard, and it is a language I continue to enjoy programming in; I
would gladly choose C over LISP where operations involving table
scanning or string and buffer manipulation were involved, if only
because of the compressed syntax (and possibly increased performance).

There are good reasons to go for a Mac anyways for certain kinds of
applications (because of the MacOS and all the media-design tools, not
the hardware). They have the nicest on-screen font rendering of any of
the systems I've used; certainly better than awful Unix. (Yeah, I've
got an extra TTF font server installed + a few hundred high-quality
fonts and they still render like crap compared to Windows with the
font-smoother or particularly the Mac.)

  that I did, and the reason was that I needed a Linux system that ran on
  an Intel for a bunch of other reasons.

It's also a lot easier to read the output of #'disassemble on a MIPS
or SPARC.

And don't even get me started about floating point on the x86.

So I don't think that a _mass_ market is needed to get sustainable
growth, you just need a market that can sustain the investments
needed.

OTOH it seems to me that CL's position in the non-research and non-AI
areas is increasing steadily, in all sorts of business-critical and/or
complex information systems.  Fields like knowledge-based engineering
(see www.ktiworld.com with it's ICAD/KBO environments), simulation,
visualization, OODBMS, decision-support systems, planning and
scheduling systems, etc.

The producers of these systems typically have different needs and
different buying habits than the participants of what has come to be
the programmer mass market.

It is this audience (together with the relevant research and education
communities) that most Lisp vendors are increasingly trying to cater
for nowadays, I'd guess.

I think this is a sustainable strategy for the current number of
players.  OTOH I could imagine other strategies working well, too,
like Kent's suggestion that serveral CL implementations should try
to leverage their connectivity prowess (especially their very well
integrated-CORBA support) better by incorporating it into their
base products, thereby positioning their products as the business
logic/connectivity language of the future.

Since it seems that the current users of CL seem to have other
perceived needs as do members of the mass markets, it seems to me that
the outcome would be less satisfactory to the current users...

Regs, Pierre.

Regs, Pierre.

The standard story is that computerisation has had negligible effects
on productivity, and may in fact have decreased it.  The reasons for
this are (they claim) mysterious and (I claim) very obvious.

However, over the last short period (perhaps 2 years) there have been
really noticeable improvements in productivity in the US economy.

The internet/e-commerce people are jumping up and down waving their
hands claiming that the revolution is finally here because it wasn't
computers it was web-browsers that increase productivity (or something
equally incoherent).

But if you look closely at *where* the productivity gains are
happening you find something interesting: most people are seeing only
small-to-no increases in productivity, but *computer manufacturers*
are seeing *very large* increases, and have also become a significant
part of the economy.

So really what is happening is that computerisation is still not
helping, *but* `lock-in' is happening, so that a company *has* to
computerise or lose, even though it doesn't save money by doing so
(my guess is that this is doe to proprietary-format contagion over
the net, and also because large companies are refusing to deal with
people non-electronically).  So huge numbers of computers are being
sold, and the computer makers are realising really significant
productivity gains at the same time.

Maybe an answer prototype would help.  Suppose that Cavallaro
believes that his c.l.l posts improve people's lives.  An answer
would include a statement of that goalt together with some
argument showing that those posts do have that effect.

BTW - The backhanded accusation of slave-trading was a nice touch.
(Hint - placing two things next to one another in a paragraph
doesn't make them related, and honest people don't confuse "some
Nazis wore pants" with a useful commentary on pants wearers.)

-andy

    (concatenate 'string foo bar)

with

    { size_t l1 = strlen(foo);
      size_t l2 = strlen(bar)+1;
      char * s = xmalloc(l1+l2);
      memcpy(s,foo,l1);
      memcpy(s,bar,l2);
      ...
    }

for instance. Of course, it's easy to write a C function that
concatenates strings like this. But then what if you want to
concatenate three strings? You can't just say

    result = concat(concat(foo),concat(bar,baz))

because that leaks memory (the result of the lexically last
|concat| there). It's niggling things like this (most of which,
in the end, come down to the absence of GC) that make string
manipulation in C really unpleasant. I'll admit that it's
fast, though; but not fast enough to make up for the slowdown
you incur when *writing* the code.

Common Lisp's string handling is certainly verbose, but it's
less verbose than doing the same thing in C.

Hartmann Schaffer

http://store.apple.com/1-800-795-1000/WebObjects/AppleStore?family=G4

$1,599 - 400MHz G4 with 64M RAM, 10GB HD
$2,499 - 450MHz G4 with 128M RAM, 20GB HD
$3,499 - 500MHz G4 with 256M RAM, 27GB HD

They seem to include a 56k modem, a 10/100BT card, a CDROM and an ATI
RAGE 128, the 450MHz+ ones have a DVD-ROM.  It looks like only the
400Mhz version is available now, while the others have increasing
waiting times.  I've heard Apple tends to choose high quality hardware
in their systems (although the choice of the ATI rage is a little
disappointing, I'd rather see something else there).  It might also be
possible to build your own systems, but Macintosh has traditionally been
against customization and expansion.

(concatenate 'string foo bar)

Is not a C-style construct.

When I am talking about string processing, I mean performing several
operations and producing a single string result; the style of lisp woulf
typically produce several intermediate strings in a process like this,
which is less efficient.  I also need to be able to extract specific
types of values at arbitrary points in the string.  To get an integer
out of a long string like "Here is your number: 5, happy?" is more
difficult in LISP than in C.

With buffer processing, it is often necessary to extract binary types
out of a byte stream of some kind, like for example if you are
communicating via TCP or storing data in a compact form on disk.  To be
honest, I dont even know how to encode and decode lisp types into a
binary form, even less extract binary types that may have been written
by other languages...

Try and implement this in LISP:

int i, x=0;
char buf[200] = "xyz,abc,2.3=12";
float foundfloats[20];

for(i=0; i++; i<sizeof(buf))
{
  if(buf[i] == 0)
    break;
  if(buf[i] == ',')
    buf[i] = '\n';
  if(buf[i] == '.')
  {
    int j;
    for(j=i; j>0; j++)
    {
      if(buf[j] == 0)
      {
        foundfloats[x++] = (float) strtod(&(buf[j+1]));
        break;
      }  
    }
  }

I also searched that site for quite some time to see what software
they bundle with the things. If they give you Photoshop 5.0 and a
bunch of other good stuff with all of them, then it might not be that
bad....

Try pricing an imaginary system at http://www.pricewatch.com. You
could get more memory, a faster processor, and a large UltraWide-2 SCSI
disk and probably even have enough left over for a monitor....

   Compaq will end development for all 32-bit and 64-bit Windows NT
   products on the Alpha platform with the delivery of Windows NT 4.0
   Service Pack 6 in late 1999. We will continue to provide support
   for
   current Alpha Windows NT products, and we will offer migration
   paths
   to other Compaq platforms.

        strcat(strcat(xmalloc(strlen(foo) + strlen(bar) + 1),
                                    foo),
                             bar);

is a much simpler way of saying this (well, I think so).  It's
slightly slower than it might be because the second strcat has to walk
the string you are building (your one has a bug BTW, the second memcpy
needs to be memcpy(s + l1, ...)).  I guess C people typically *would*
worry about that kind of inefficiency.

Of course you still get killed by the lack of GC, but you always get
killed by that.

I don't think you can get much more self-describing than this.  Now I
would have been with you if you had accused CORBA of being overly
complex for same language/implementation solutions, which OTOH is to
be expected of an architecture that tries to be cross-language, cross-
platform and cross-network.

I don't know what you mean by clever namespace tactics, but would be
interested to know more.  Maybe the Interface/Namespace split that ILU
does in ISL would be interesting to you?

OTOH if you only use CLOS, it should be quite possible to write your
own RPC protocol over a network link, and hide it behind a
meta-class.  This has been done a couple of times, though I don't know
of anything that is publically available, IMHO.

It seems to me that the sole driving force behind Java's growing
library base is to occupy as much of the teritory as possible, so that
the enemy can't get it.  Only after we've got all of this, will we
think about the quality, stability and usefullness of our libraries.
The same seems to apply to the core of the language itself, only in
more restrained ways (probably because of the need to provide at least
some backward compatability to older JVMs for the time being, to keep
the slogan write once, run everywhere at least somewhat believable).

Compare that to CL, which at the time also had a huge set of built-in
functionality (we've only fallen behind Jave, Perl, etc. in recent
times in quantity), but at a much higher quality.  Most of the things
in CL are both proven by the test of time, and have been analysed
quite well to ensure their stability, versatility and continued
usefullness.  Now you might argue that CL is this way, because it
stayed away from controversial "new" areas, like GUI toolkits, so that
this comparisson is unfair.  I don't think it is unfair for two
reasons:

a) Some of the things CL tried to tackle were at least as controversial
   at the time as (cross-plattform) GUI toolkits were at the time Java
   started:  The condition system and more so the CLOS are examples of
   functionality in CL that could quite easily have been gotten
   wrong.  But CL didn't, and to my knowledge there exist no major
   grievances with both that would need to be adressed in the current
   round of standardization/reaffirmation.

b) CL never exhibited this conquer-at-all costs attitude towards
   functionality.  If some area was not understood well enough to be
   standardized, it was rather left out of the standard, than burden
   future generations with the crap of the current generation.

Note that these are generalized arguments, and I don't claim that
indeed every little feature in CL is as good as the claims above.
OTOH it should be noted that nearly all of the suggestions for changes
in the standard at the current time are for extensions to the
language into different directions, and not to fix defects in existing
constructs (with pathnames probably being one of the notable
exceptions[1]).

So while I too like to have as many functionality as possible in my
language of choice (or available too it), I also want it to be of high
quality, and highly versatile and stable.  Otherwise I'd rather see it
not standardized, so that different third-party vendors can try to
come up with increasingly better ways of doing things, which a
standard would prohibit.  In this way I get at least increasing
quality and choice, while sacrificing stability.  With the Java way I
get neither quality nor stability.

What I would like to see is an increase in (de-facto) standardized
libraries/layers for Common Lisp, but at a decent speed that didn't
try to exchange quality for quantity.

Just my 2 cents.

Regs, Pierre.

Footnotes:
[1]  It is my impression that pathnames were properly understood at
the time (see Symbolics Lisp machines), but that political pressures
to standardize too much Symbolics' stuff kept much of the needed
functionality from being brought in.

For example: when my father was of age to enter the job market, the majority
of accounting and stock control functions in businesses and local
authorities were carried out by large teams of people adding up numbers by
hand (either using mechanical adding machines or ledgers and a pen). This
doesn't happen any more. The payroll and holiday calculations for the large
(~500 person) group of companies I work for, is carried out by one and a
half people. This is possible using stuff like SAGE. In the past took a team
of 20 to do.

More recently (the last 10 years or so), the production of Yellow Pages in
this country was an almost completely manual process. Two sites in this
country employing in excess of 800 people to rearrange film advert and text
items. An experienced person could expect to produce in the order of 23
laid-out pages in a week. The average book took 6 weeks to produce, even
working shifts and weekends. Including amendments, this process now takes
under 4 days and about 10 people.

I have probably missed the point (again) and you were talking about some
other form of computerisation. But I think that standard story is wrong,
that computerisation *has* had an impact on productivity. You can save money
in a lot of processes through the careful use of computerisation.

Best Regards,