[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
About Dave Lucky's questions about MCL.
- To: firstname.lastname@example.org
- Subject: About Dave Lucky's questions about MCL.
- From: email@example.com (Ben A. Hyde)
- Date: Fri, 3 Jan 92 11:29:00 EST
I have on my Mac a desk accessory that provides all the power of the
MacDraw 1.0, it is 37K bytes. I once wrote an analagous thing it took
me about 2 months to get it "80% done." It is possible to write such an
thing in C on top of the Macintosh toolbox because the toolbox so
Meanwhile I also have a trivial application used throughout my
company written in MCL (the released version). It requires a 2Meg
partition and the save file is just over 800K bytes. It is very
popular, took me only three days to get working and a few weeks over
the last two years to maintain.
The toolbox contains some extremely sophisticated data types, i.e.
fonts, pictures, styled text, dialogs etc. etc. Any one of these is an
complex bit of engineering and the product of a very competitive
MCL Common Lisp provides some neat data types too: a heap with both
ephemeral and absolute GC, real error handling, symbols, an outragous
class system, etc. etc. These were all designed with great care by
people deeply concerned about software engineering.
Sad to say these are two very different things. To be succeed working
in Common Lisp on the Macintosh you will need to be fluent in both
For MCL to succeed it will have to be loyal to both communities. An
interesting example of this is CLIM (the Common Lisp Interface Manager)
which MCL must support to be a first class member of the Lisp community.
Meanwhile CLIM is, for a Macintosh developer, an extremely curious thing
as it doesn't seem to be concerned with issues central to building a Mac
application, for example clipboard, undo, rich text, drawings, macros,
menubar, document structure, etc. Providing satisfaction to both these
communities is a facinating task.
Common Lisp is great for building applications where you can ask your
(a) configure thier machine in a way uncommon in most of the installed
(b) accept responsiveness that lags what they are used to in Excel,
MacDraw, or what ever, and
(c) work in English.
In exchange you get to build products faster. That means you get paid
sooner, and that means you chances of success improve.
Both communities carry some baggage. Some examples. If you build to the
toolbox you are limited to the the Macintosh community as your
customers. Someday Apple may find away to enable applications to take
the tool box to other platforms but that isn't going to be easy. If you
build in Common Lisp you must carry the entire language. These days the
class system is very entangled with error handling. If you build on the
toolbox it is difficult to create a seamless object oriented appearance
for your document. If you build in Common Lisp it is extremely difficult
to avoid a full GC creating unacceptable interuptions in user response.
One of the exciting things about MCL is that it resides in both these
communities. I suspect we all wish them great success.
- ben hyde, Gensym, Cambridge Mass.