gjc@paradigm.com (04/09/90)
Here I am, a lisp hacker, who learned what a macro was from JONL,
and what lisp microcode was from RG, and what lexical scoping was
from GLS.
So when I go to write an expert system at a startup-company
do I decide to use LISP?
NO!
Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp.
three costs:
(1) technical cost of the overly-complex and large runtime portions.
(2) financial cost-of-sales for runtime licenses.
(3) administrative costs of runtime licensing procedures.
Do language vendors for C,FORTRAN,PASCAL generally charge a runtime
license fee? No, they do not. (Not even 3rd-party vendors).
But lisp vendors generally have various "technical" rationalizations for
per-instance runtime licensing costs and complexities. No need to go
into these here. The result is a classic downward spiral:
Fewer Commercial/Developers Users of Lisp
=> Justification for obtaining revenue from runtime licenses
=> Fewer Commercial/Developers who will want to use Lisp
=> need for higher runtime license costs for more revenue
=> Fewer users of lisp ...
-gjckend@tekchips.LABS.TEK.COM (Ken Dickey) (04/10/90)
In article <485@paradigm.com> gjc@paradigm.com writes: ... >So when I go to write an expert system at a startup-company >do I decide to use LISP? > >NO! > >Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp. > >three costs: >(1) technical cost of the overly-complex and large runtime portions. >(2) financial cost-of-sales for runtime licenses. >(3) administrative costs of runtime licensing procedures. > >Do language vendors for C,FORTRAN,PASCAL generally charge a runtime >license fee? No, they do not. (Not even 3rd-party vendors). > >But lisp vendors generally have various "technical" rationalizations for >per-instance runtime licensing costs and complexities. No need to go >into these here. The result is a classic downward spiral: ... >-gjc Perhaps you should try Scheme. Aside from the academic/no-cost compilers with source, Chez Scheme [Cadence Research Systems: (812) 333-9269] has an application builder which links in a minimal runtime for stand-alone applications. Chez runs on Sun3/4, Vax, Apollo, 88K and various other boxes. Using Scheme gets rid of 1,2,&3. Don't forget the cost of storage leaks. [I know of at least 1 C++ product which uses 5 heaps!]. Also, don't forget the cost of development time. If you use a productive enviroment which gets your software done in 1/2 the time of batch-compiled languages (C,FORTRAN,PASCAL) you may just hit your market windows. Perhaps I should ask what you mean by Lisp. Lisp 1.5 probably is dead! -Ken Dickey
alms@cambridge.apple.com (Andrew L. M. Shalit) (04/10/90)
In article <5951@tekcrl.LABS.TEK.COM> kend@tekchips.LABS.TEK.COM (Ken Dickey) writes: In article <485@paradigm.com> gjc@paradigm.com writes: ... >So when I go to write an expert system at a startup-company >do I decide to use LISP? > >NO! Perhaps you should try Scheme. Aside from the academic/no-cost compilers with source, Chez Scheme [Cadence Research Systems: (812) 333-9269] has an application builder which links in a minimal runtime for stand-alone applications. Chez runs on Sun3/4, Vax, Apollo, 88K and various other boxes. Ken also probably should have mentioned MacScheme (Lightship Scheme?) which can produce ~120K applications for distribution. I believe there is no licensing fee. Also, MACommonLisp (disclaimer alert!) has a single shot licensing fee. That is, a developer pays $100 a year, for any number of copies of any number of applications. -andrew
lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (04/10/90)
In article <485@paradigm.com> gjc@paradigm.com writes: >So when I go to write an expert system at a startup-company >do I decide to use LISP? > >NO! > >Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp. > >three costs: >(1) technical cost of the overly-complex and large runtime portions. >(2) financial cost-of-sales for runtime licenses. >(3) administrative costs of runtime licensing procedures. Until the world is ready for Lisp machines... You could develop in (portable) Common Lisp in your favorite environment but deliver your application in Austin Kyoto Common Lisp. My impression is that, with the proper arrangements, the esteemed professors in Kyoto do not impose (2) and (3). Even (1) is not so much of a problem with AKCL as with some other Common Lisp implementations. Can you name your hardware platform? For example, if you're developing for an IBM-compatible PC with 640 Kbytes of RAM, your situation is probably beyond hope unless you can make do with Xlisp. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.
captain@vax1.acs.udel.EDU (Jeffrey Kirk) (04/10/90)
In article <14980@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes: ]In article <485@paradigm.com> gjc@paradigm.com writes: ]>So when I go to write an expert system at a startup-company ]>do I decide to use LISP? ]> ]>NO! ]> ]>Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp. ]> ]>three costs: ]>(1) technical cost of the overly-complex and large runtime portions. ]>(2) financial cost-of-sales for runtime licenses. ]>(3) administrative costs of runtime licensing procedures. ] Support your own LISP, take one of the public-domain LISPS and add/subtract what you want. This solves 1-3 above. -- ZZ :wq! . Jeff C. Kirk: captain@vax1.acs.udel.edu ^x^s
dourish@arisia.Xerox.COM (Paul Dourish) (04/10/90)
In article <6008@udccvax1.acs.udel.EDU> captain@vax1.acs.udel.EDU (Jeffrey Kirk) writes: >Support your own LISP, take one of the public-domain LISPS and add/subtract >what you want. This solves 1-3 above. Scarcely the point.... it proves some sort of "inferiority" for Lisp if I have to do this. I don't have to support my own C, for instance. It's certainly a common criticism of Lisp that the run-time support is large, making it difficult to deliver applications to end-users. What are people's experiences with distillation tools that remove unwanted code and give smaller images for delivery systems? Gjc's right that this is a vicious circle; unfortunately, what it needs is some supplier who can afford to break it, perhaps in conjunction with a Lisp house prepared to lower the financial cost of run-time licenses. (Didn't Symbolics start to address these sorts of problems with a compatability system for PC-type machines?) -- Paul Dourish, Rank Xerox EuroPARC, Cambridge UK <Dourish.EuroPARC.Xerox.com> "Ain't they got no barbers where you come from, boy?"
jdye@zodiac.ADS.COM (John W. Dye Jr.) (04/11/90)
>Gjc's right that this is a vicious circle; unfortunately, what it needs is >some supplier who can afford to break it, perhaps in conjunction with a Lisp >house prepared to lower the financial cost of run-time licenses. (Didn't >Symbolics start to address these sorts of problems with a compatability >system for PC-type machines?) Unfortunately suppliers of Lisp are vicitms of a chicken-and-egg problem. The fact is that Lisp is not a very profitable buisness (Witness Gold Hill's recent chapter 11, Symbolics general status and Lucid and Franz's failure to grow as fast as they would like). Actually, I think that the remaining lisp vendors have done a marvelous job of staying solvent given the marketplace factors them. But GJC does have a very valid point. The delivery liscence is a severe limitation to size of the market for Lisp as an computer system delivery vehicle. Other barriers are the size and speed of applications written in lisp (although those factors are being remedied by the Common-Lisp vendors). But, given a choice between two language products which both produce fast, small, robust applications, I will choose based on which product is cheapest to incorporate into my workstation product. The extra 1K cost for the liscence fee will be 1k of profit that I DONT RECIEVE from the application I am selling and supporting. > >-- >Paul Dourish, Rank Xerox EuroPARC, Cambridge UK <Dourish.EuroPARC.Xerox.com> > > "Ain't they got no barbers where you come from, boy?" JD John Dye jdye@ads.com
Kelly@Vega (04/11/90)
In article <485@paradigm.com> gjc@paradigm.com writes: >>So when I go to write an expert system at a startup-company >>do I decide to use LISP? >> >>NO! >> >>Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp. >> >>three costs: >>(1) technical cost of the overly-complex and large runtime portions. >>(2) financial cost-of-sales for runtime licenses. >>(3) administrative costs of runtime licensing procedures. >lgm@cbnewsc.ATT.COM (lawrence.g.mayka) replies > Until the world is ready for Lisp machines... Common Lisp is more of an Operating System than just a programming language. You certainly don't pay Lisp license fees for applications delivered for a Symbolics or an Explorer. You assume that the delivery machine already has UNIX, or MS-DOS, or whatever. If you have to deliver your application with an Operating System, you would certainly have to pay a license fee for the OS. You are buying into the OS, not C, when you use C as your programming language. Common Lisp is quite healthy. In my opinion, the growth of UNIX, C and C++ is cancerous. Common Lisp will be an Operating System. When you start writing programs that use multiprocessors and parallelism, you will rapidly discover that UNIX and C are dead. -Kelly Murray (Top Level, Inc.) murray@cs.umass.edu
gjc@paradigm.com (04/12/90)
In article <12789@dime.cs.umass.edu>, Kelly@Vega writes: > > Common Lisp is more of an Operating System than just a programming > language. False. A CL does *not* have to implement: - FILESYSTEM - EDITORS - NETWORKING - DEVICE DRIVERS for DISK/TAPE/NETWORK ... - SCHEDULING - WINDOW SYSTEM - PROTECTION - INTERLOCKING - INTERPROCESS COMMUNICATION There is a heck of a lot in an O/S such as VMS or UNIX. For that matter, there is a heck of a lot in something like the Symbolics release 6.x O/S, or the LMI-LAMBDA release 3.x Most all of the stuff of conventional O/S. So why is it that some CL implementations under say Unix, are now bigger than an entire lispmachine O/S image??? > You certainly don't pay Lisp license fees for > applications delivered for a Symbolics or an Explorer. False. You pay one HELL of a lot, since you need to buy a hardware board and pay for additional software licenses when you want to support a Lisp application on your MAC or SUN in that manner. The user must also pay additional monthly hardware support fees. > Common Lisp is quite healthy. In my opinion, the growth of UNIX, C and C++ > is cancerous. C is FORTRAN-DONE-RIGHT, so who could argue with that? And C++ perhaps is just filling the space that could have been taken up by reasonable lisp implementations. -gjc
carlson@Franz.COM (Bill Carlson) (04/12/90)
Hello George,
Lisp is not dead or dying. On Unix machines, Lisp is doing extremely
well, not just as a development tool, but for delivery as well. Franz
as a company is healthy and growing rapidly which makes us believe
that the Unix Lisp market is also healthy and growing. Companies like
NeXT, Cray, Sun, Apollo, DEC, Sequent and IBM all openly endorse Lisp
on their Unix machines. So if Lisp is dying, it must be in other
circles (LMs, DOS?).
Your points about delivery are well taken. I would argue that the
main problem with runtime is with the size of the Lisp and the expense
of the delivery platform rather than the cost of runtime licenses and
the administrative costs. All of these, fortunately, are being dealt
with now by various Lisp vendors. It helps too, that hardware is
still getting less expensive and more powerful.
In Allegro CL 4.0 and in Lucid/Sun CL 4.0 you will have affordable
runtime systems, affordable in both machine resources and in price.
Both are due out this year. Lucid/Sun CL will use tree-shaking
algorithm while Franz will take a very different approach. In either
case, the point is the same; Lisp vendors are dealing with the issue
of delivery in a big way and working to reduce the size of the
deliverable.
Lisp runtime licenses (from Franz, I can't quote others) today cost
from $100 to $600 on typical Unix machines. This is more than C and
Fortran, but it isn't that much considering what is provided to you
with Lisp. With Lisp you get lots more functionality, with lots of
features and customizable options not found in C. Lisp is also
getting more and more portable and is much faster now than ever
before. Lisp is still best suited for maintaining and writing large
complex applications. For some smaller, simpler projects, C is
admittedly more appropriate at the current time. But this will change
and you will see more and more Lisp-based deliverables.
If the cost of Lisp runtimes are too much for you, you can opt for
some free or very inexpensive alternatives (KCL, Ibuki, PD-Franz..).
We don't expect all C-based companies to switch to Lisp or vice versa.
Lisp has its niche, and as software gets more powerful and
complicated, that niche will grow. Lisp is not dead. It is alive and
kicking, even in the commercial world.
Regards,
Bill Carlson
Franz Inc.
carlson@franz.com
--
=========================================================================
Bill Carlson Franz Inc.
1995 University Avenue, Suite 275
INTERNET: carlson@franz.com Berkeley, CA 94704
UUCP: uunet!franz!carlson 415-548-3600, FAX:415-548-8253lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (04/12/90)
In article <509@paradigm.com> gjc@paradigm.com writes: >In article <12789@dime.cs.umass.edu>, Kelly@Vega writes: >> Common Lisp is more of an Operating System than just a programming >> language. >False. A CL does *not* have to implement: > - FILESYSTEM - EDITORS > - NETWORKING - DEVICE DRIVERS for DISK/TAPE/NETWORK ... > - SCHEDULING - WINDOW SYSTEM > - PROTECTION - INTERLOCKING - INTERPROCESS COMMUNICATION Perhaps it is more accurate to say that Common Lisp attempts to provide a portable interface to a software development environment. Common Lisp includes BREAK, INSPECT, TRACE, STEP, COMPILE, LOAD, EVAL, ED, PPRINT, and a host of other environment-related forms. >So why is it that some CL implementations under say Unix, are >now bigger than an entire lispmachine O/S image??? Large Common Lisp images typically include a more or less complete software development environment, plus a number of operating-system-like capabilities such as preemptive multiple-process scheduling. >> You certainly don't pay Lisp license fees for >> applications delivered for a Symbolics or an Explorer. >False. You pay one HELL of a lot, since you need to buy a hardware board >and pay for additional software licenses when you want to support >a Lisp application on your MAC or SUN in that manner. The user must >also pay additional monthly hardware support fees. The point is that any calculation of "overhead" depends on the assumptions one is willing to make about typical customers. If targeted customers usually already have a Lisp machine and a Lisp-based operating system, these are no longer "chargeable" to the application. Even on a computer running the UNIX System, if customers typically already have a Common Lisp implementation and the application is packaged on that assumption (e.g., as a loadable binary), the Lisp is no longer "application overhead." Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.
jeff@aiai.ed.ac.uk (Jeff Dalton) (04/12/90)
In article <12789@dime.cs.umass.edu> Kelly@Vega writes: >In article <485@paradigm.com> gjc@paradigm.com writes: >>>Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp. >>> >>>three costs: >>>(1) technical cost of the overly-complex and large runtime portions. Isn't it a financial cost too? One has to buy larger and more powerful machines in order to run Lisp; and such machines cost more. For example, I use a ~10 mips, 8 megabyte machine. It runs a wide range of programs written in C without much trouble, but if I want to use a Common Lisp on it, I usually stick to KCL because larger ones take a noticable performance hit from paging. Moreover, I find it really annoying that I can't write little programs in Lisp (because they automaticaly become big programs) and have to use C instead. Common Lisp implementations are a step backwards in this respect compared to earlier Lisps such as Franz. [Note that I say implementations. Someone could, I suspect, produce a Common Lisp with different properties.] Not only that, in some ways C has a better programming environment than the Lisps that would run on the same machines. (Try dbxtool on Suns, for example). >>>(2) financial cost-of-sales for runtime licenses. >>>(3) administrative costs of runtime licensing procedures. >Common Lisp is more of an Operating System than just a programming >language. [...] But some people are happy with their current OS and don't want to replace it with a completely new one that may not run the other things they want to run. Common Lisp ought to be analogous to a compiler plus a library. Sure, some implementations will be in a Lisp-based OS, but not all of them. Indeed, it's things like Symbolics Genera that are analogous to an OS, not Common Lisp. >You assume that the delivery machine already has UNIX, or MS-DOS, or >whatever. If you have to deliver your application with an Operating >System, you would certainly have to pay a license fee for the OS. >You are buying into the OS, not C, when you use C as your programming >language. Um, quite a few people do have machines that already have Unix, so it's perfectly reasonable to want to deliver applications for such machines in Lisp just as one could in C. Most people are not going to change operating systems just to use Lisp. >Common Lisp will be an Operating System. When you start >writing programs that use multiprocessors and parallelism, >you will rapidly discover that UNIX and C are dead. Right now, C seems to be winning here rather than losing.
rpk@wheaties.ai.mit.edu (Robert Krajewski) (04/14/90)
>Common Lisp will be an Operating System. When you start >writing programs that use multiprocessors and parallelism, >you will rapidly discover that UNIX and C are dead. Unix and C ain't gonna die. Look at this this way: given current application trends (OOP, complex storage management), environments that can *provide* what Common Lisp and a carefully pruned subset 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. 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.
rpk@wheaties.ai.mit.edu (Robert Krajewski) (04/14/90)
In article <2222@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >In article <12789@dime.cs.umass.edu> Kelly@Vega writes: >>In article <485@paradigm.com> gjc@paradigm.com writes: >>>>Why? Mainly the unreasonable cost of the RUNTIME portion of a lisp. >>>> >>>>three costs: >>>>(1) technical cost of the overly-complex and large runtime portions. > >Isn't it a financial cost too? One has to buy larger and more >powerful machines in order to run Lisp; and such machines cost more. >For example, I use a ~10 mips, 8 megabyte machine. This is becoming less and less of an issue; 8-meg machines are not so uncommon now in the Macintosh world, and in the PC world, such amounts of memory are accessible via modern environments such as OS/2 and Windows 3.0. i3/486s and 68030/40s are quite acceptable both as development and delivery platforms. >Moreover, I find it really annoying that I can't write little programs >in Lisp (because they automaticaly become big programs) and have to >use C instead. Ahh, but what happens if you write a C program that uses a big library in an environment that does not support dynamic linking ? Then, you run into a similar phenomenon, albeit much less drastic. (At Gold Hill, we estimated the Common Lisp core to cost about 600kbytes of moderately optimized 286 code.) Again, Lisp functionality like to reside in a library or OS-core (minus the historically-mandated baggage of sequence functions and other MacLisp artifacts). Powerful support is amortized by reuse. The driving impetus is the demand for powerful programs that are made tractable only by the services that are associated with Scheme or Common Lisp.
lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (04/14/90)
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.