larry@postgres.Berkeley.EDU (Larry Rowe) (06/01/91)
Several people made interesting comments to my overly caustic flame about Lisp. Here's some more comments: 1. The person who noted that it is hard to build systems composed of multiple languages is really right. The Postgres database system was originally coded partly in Lisp and partly in C at my suggestion. After the first version of the system was completed the Lisp part was recoded in C to reduce runtime space and time. But, there was another reason too, namely that the mixed developed environment was hard to work in. Although some of these problems were specific to the Lisp chosen (Franz Lisp Opus 42), many are inherent in mixed language systems. For example, you couldn't call arbitrary functions across the language boundary (e.g., C code couldn't call "cons" to create a cell and C allocated data couldn't be managed by the Lisp runtime system). Another problem was that no debugger worked on the combined image system. So, you were reduced to machine-level debugging on one language or the other. Now, it may have been impractical to try this combination in the first place, but in fact it allowed us to get the first version of the system running much faster than expected. But, what surprised me, was that the reason wasn't the one I predicted. I thought doing the query optimizer (QO) in Lisp would be much faster because QO is essentially manipulations on abstract syntax trees which Lisp is *great* at manipulating. In fact, the student doing the project said she gained the most productivity from the interactive development environment. She thought the data structures and manipulation functions were ok, but not as helpful. Interesting research question: how about developing distributed systems using a distributed object system (e.g., HP/Sun or DEC/NCR/?'s distributed object systems proposed to the Object Management Group) in which different processes are written in different languages. Someone ought to think about developing debugging tools for that kind of environment *and* Lisp bindings (the proposals only support kludgy C interfaces or C++ compatible interfaces). 2. Jon L. White made a good point about economics but I think it could be sharpened. I will never pay $1,500 per seat for a spreadsheet. That probably goes for the majority of other applications I might run (e.g., document preparation systems, accounting packages, inventory control, hypermedia systems, email systems, programming tools, etc.). I can buy top-of-the-line high function applications for somewhere between $500 and $1,000 per seat that operate well in machines with 8MB of memory. Think PC's and Macs. They don't have the multitasking and networking that we take for granted in Unix land, but that is changing. In fact, I think *everyone* in the software business should be figuring out how they are going to survive when their software sells for under $1K/seat. That's the direction *all* software is going. Too many companies today are selling products into the workstation and mainframe markets today for one or two orders of magnitude more than that price point. Unless they have a small captive market that must pay those prices for semi-custom software, the companies won't survive. Consolodation has already hit the microcomputer market, it won't be long before it hits the workstation market. Now, what does this do to companies that sell development tools? Well, they had better get ready for OEM pricing on the order of $50/copy or less. I know *many* companies today who sell development systems that require per copy payments for generated systems above $500 or $1k (e.g., Smalltalk, Saber C++, and ASK/Ingres Windows 4GL). The economics will not support that situation. Right now it will because the companies have a technical advantage. But it won't last for long. Anybody out there working on a low cost C++ development environment? Anybody heard of Digitalk Smalltalk? I'm not familiar with the pricing of Lisp developed applications, but they may have a similar problem. 3. Now to the good news. There's a company in Emeryville CA that sells work group software for networks of IBM PC's and compatibles for document preparation and management. The products are written in Gold Hill CL. Manager's there say it is *very* good for development, but they have had troubles with the stability of the CL supplier. But, they are in the right part of the market -- high volume, low cost. And, has anybody looked at the customization language for AutoCad? It's a home grown Lisp. I don't know if either product uses an object system. Larry
jln@leland.Stanford.EDU (Jared Nedzel) (06/05/91)
In article <42280@ucbvax.BERKELEY.EDU> larry@postgres.Berkeley.EDU writes: > And, has anybody >looked at the customization language for AutoCad? It's a home grown Lisp. >I don't know if either product uses an object system. Btw, AutoLisp is described by AutoDesk as a "superset of a subset of Lisp." That is, it is a subset of lisp with access to the drawing/object manipulation functions of AutoCad. It doesn't have CLOS. People who have used it tell me it has some significant limitations as an implementation of lisp. The newest version of AutoCad (Release 11), allows developers to customise AutoCad using C, rather than AutoLisp. Regarding the problems of developing mixed language systems, let me also second Walter Gilette's (sp?) comments: debugging a mixed-language C-Lisp program is a bitch. I'm working on a network communication program that does the low-level communications in C and more interesting stuff in Lisp. This results in a lot of potential failure points. -- --------------------------------------------------------------------- Jared L. Nedzel nedzel@cive.stanford.edu jln@portia.stanford.edu
jeff@aiai.ed.ac.uk (Jeff Dalton) (06/06/91)
In article <42280@ucbvax.BERKELEY.EDU> larry@postgres.Berkeley.EDU writes: > Although some of these problems were specific to the Lisp >chosen (Franz Lisp Opus 42), many are inherent in mixed language systems. > >For example, you couldn't call arbitrary functions across the language >boundary (e.g., C code couldn't call "cons" to create a cell and C >allocated data couldn't be managed by the Lisp runtime system). It's a relatively minor point, but it is possible to call functions across the language boundary in Franz Lisp Opus 42. It's not straightforward, but it is possible.
olasov@cs.columbia.edu (Benjamin Olasov) (06/08/91)
In article <1991Jun4.172218.13803@leland.Stanford.EDU> jln@leland.Stanford.EDU (Jared Nedzel) writes: >In article <42280@ucbvax.BERKELEY.EDU> larry@postgres.Berkeley.EDU writes: > >> And, has anybody >>looked at the customization language for AutoCad? It's a home grown Lisp. >>I don't know if either product uses an object system. > >Btw, AutoLisp is described by AutoDesk as a "superset of a subset of Lisp." >That is, it is a subset of lisp with access to the drawing/object manipulation >functions of AutoCad. It doesn't have CLOS. People who have used it tell >me it has some significant limitations as an implementation of lisp. The >newest version of AutoCad (Release 11), allows developers to customise >AutoCad using C, rather than AutoLisp. AutoLisp is based on David Betz's XLISP program. Apparently this was something that AutoDesk's president John Walker decided to incorporate in AutoCad one weekend, and it was really a nifty idea! Yes, if you're used to full Common LISPs you'll find it limiting (no &keyword or &optional arguments possible, etc., etc.) but in terms of what it can do, it's really very nice. One company in California interfaces it to CLOS and other Common LISP applcations by having the Common LISP application write out a program that AutoLisp can read, and thereby increases the scope of what can be be done with the AutoLisp interpreter. In short, it's neat! I use it often - if you have specific questions on it, email me. Ben olasov@cs.columbia.edu