Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!att!cbnewsc!lgm
From: lgm@cbnewsc.ATT.COM (lawrence.g.mayka)
Newsgroups: comp.lang.lisp
Subject: Re: why lisp is dead
Message-ID: <15121@cbnewsc.ATT.COM>
Date: 14 Apr 90 13:02:02 GMT
References: <7853@rice-chex.ai.mit.edu>
Reply-To: lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,)
Organization: AT&T Bell Laboratories
Lines: 62

In article <7853@rice-chex.ai.mit.edu> rpk@lammert.ai.mit.edu () writes:
>of CLOS need will be the wave of the future.  The essence of this
>functionality is basically Scheme, since much of Common Lisp
>(generic sequence functions, math, etc.) can viewed as libraries,
>not an essentially computational model.

It is true that much of the "bulkiness" of Common Lisp can be
provided as autoloadable libraries, but to imply that the
remainder is nothing more than Scheme stretches the point, I think.

>Such environments will still have to support the many useful programs
>that don't need object management.  They will probably also have to
>partition data and execution privileges in a more disciplined way
>than the classic Lisp Machine environment.  So what I see coming is
>an environment that can support Unix/Posix/OS/2/Mac things, with
>new breed of ``application'' that is actually a collection of objects
>and classes that augment the basic environment, just as the typical
>Lisp Machine program can offer new functions and flavors to other parts
>of the machine without recourse to streams, pipes, string analysis,
>arbitrary protocols, etc.

In the nearer term, your projection makes a lot of sense.  Lisp
machines, for example, are not necessarily the current best choice
for sharing a single processor among multiple potentially hostile
users.  But eventually, the overhead of interfacing the older,
non-object-oriented programs to the newer, object-oriented
programs will become more trouble than it's worth, and software
vendors will progressively port their products to the new
environment, adding functionality in the process.  The old world
will then take on the characteristics of a "compatibility box,"
appropriate for running "dusty decks" but not for developing new
applications.

This entire technology transition is no different in principle
from others our industry, and other industries, have experienced
over time.  As usual, early adopters will assimilate the new
technology first in search of a competitive advantage; more
conservative market players will wait for widespread popularity or
even ubiquity; and stragglers may never make the conversion,
either servicing obsolete systems indefinitely or simply getting
out of the business as it becomes unprofitable.

Do not underestimate the power of standardization.  The same
market pressures that are forcing the migration of software
products to the UNIX System (despite the latter's alleged
inapproriateness for some applications) will eventually propel a
movement to its successor.  Uniformity of OA&M (operation support,
administration, and maintenance) will of itself be a major
consideration.

This scenario assumes that the new technology will eventually
become competitive in efficiency, cost, etc. with the old (i.e.,
within striking distance for most applications).  If that does not
prove to be the case, the two worlds may simply have to learn to
coexist, communicate, and cooperate indefinitely.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@ihlpf.att.com

Standard disclaimer.