CLIM mail archive
[Prev][Next][Index][Thread]

Lisp companies


  Date: Wed, 16 Sep 1992 18:11-0400
  From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>

  Could somebody suggest a way that us Lisp companies get to stay in
  business?  Please don't make any suggestions that you and your
  management aren't willing to pay cash-money for.  I'm serious. 

  From: Marty Hall <hall@aplcenmp.apl.jhu.edu>
  Date: Thu, 17 Sep 1992 11:39:06 -0400
  
  At LUV-92, during the "CLOS vs. C++" Panel, one of the points that 
  struck me was that the "bundledness" of LISP, although better for
  us users, was much worse for the market.

Take this as stream-of-conciousness off-the-cuff, etc.

So what strikes me is this: lisp environments are powerful because they
are a single environment with multiple interdependancies making each
tool stronger and smarter; unlike Unix. However, by creating monolithic
environments, companies in the business must duplicate their efforts as
each must provide complete environments, rather than specializing in
bits and peices. If some of the interfaces could be standardized (a la
the COFF stuff for UNIX, not that this was a good standard, but it was
one), then perhaps a company with a good compiler could sell it
independantly of a company with a good debugger. Of course this will
take more than simply standardizing what can go into a fasl file and
execution methodology; but also where to put debugging info; how much to
provide, various tools to strip such info for non-development work, etc.

Then purchasing lisp tools will become more like picking out peices of a
stereo; or the current C/C++ environment rather than like buying a car
with a limited aftermarket choice of radio.

Admitably a lot of under-the-table effort would have to go on here, but
by reducing duplication of effort, all companies can specialize in the
parts of the market they feel most comfortable in, while still being
able to supply either simple parts of the other pieces (for the one-stop
customer), even cross-licencing if necessary; as well as marketing to
the mid-to-higher end with e.g. specialized CLOS window debuggers
(should be easy with MOP, no? :-). Reduction of effort duplication
should lead to increased profits for all, more advertising (is this
good?), etc. And the big technical challenge is to do this WITHOUT
giving up the major advantages of the monolithic integrated environment;
like Apple hardware (for the most part), you want to be able to buy the
peice you care about, drop it in, and have it work immediately.

What that means for smaller companies is that stuff like the large cl
library implemented in CL need not be reimplemented for a particular
peice of hardware; rather (assuming standardized compiler advice), the
compilers can be given hints on how to compile various functions; and
which compiler is used becomes the user's choice (even buying
super-optimized already compiled libraries). Ibuki need not support
CLIM, because CLIM would have been writtin in generic CL; the high-end
vendors provide in addition hints to allow it to run particularly well
on their system (and can charge some incremental price for this service;
you want CLIM; no problem, it's free. Oh, you want a FAST version that
COMPILES quickly... well that'll cost more than the fully featured free
evaluation version we ship with the product; the following vendors sell
versions optimized for these uses....



0,,
Main Index | Thread Index