[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re- MCL Direction
- To: 76557.704@COMPUSERVE.COM
- Subject: Re- MCL Direction
- From: STEVE.M@AppleLink.Apple.COM (Aladdin Systems,Steven Mitchell,PRT)
- Date: 01 Jan 92 13:55 GMT
- Cc: INFO-MCL@CAMBRIDGE.APPLE.COM, ALCABES@AppleLink.Apple.COM (Alcabes, Harvey)
To: Dave Lucky [76557.704@COMPUSERVE.COM@INTERNET#]
cc: info-mcl [email@example.com@INTERNET#]
Harvey Alcabes [ALCABES]
From: Steve Mitchell [STEVE.M]
Sub: MCL Direction?
Open letter reply to Dave Lucky's info-mcl posting of 12/31/91.
> I'm a Macintosh developer who has used different development
> environments (MPW/C++/Pascal/MacApp, Think C/Pascal,
> Objectworks\Smalltalk, and HyperCard).
> I'm currently taking a look at whether I can use either MCL or
> MacScheme to develop and deliver my applications. Right now, I'm
> still pretty new to MCL (and Lisp in general) but I'm already pretty
> excited about it because I like to develop applications using small,
> incremental steps and I like to experiment with my applications'
> user interfaces. There are, however, some questions that I'd
> like someone at Apple (or anyone else that knows the answers) to
> address before I can make a commitment to using MCL on a project:
A lot of people, including me, will want to hear Apple's answers to
your questions. I've been an MCL beta-tester through its 6 year
history so I'm going to jump in first with an independent
assessment. There's a lot to say...
I've used a lot of different development environments on the Mac over
the past 8 years. Exactly like you "I like to develop applications
using small, incremental steps and I like to experiment with my
applications' user interfaces." MCL is by far the best such
development system on a personal computer. Because of this, I
prefer to use MCL than MPW, MacApp, Think C, or MacScheme for
application development, nomatter how good each may be in its own
If you have to write a standalone CODE resource such as an INIT,
cdev, WDEF, or XCMD, then Think C makes an excellent Assembler
(or even C) development system. I have used MPW Pascal for
CODE resource development and succeeded in spite of its
program structuring restrictions.
For standalone applications, however, there are many advantages and
no disadvantages that I know of to using MCL, but there are a few
> 1) When am I going to be able to deliver an MCL application that
> only contains the code for that application?
I'm not sure that standalone application creation works in MCL 2.0b1.
The standalone application will include a runtime system containing
the complete MCL interpreter and garbage collector.
Any "interesting" program is going to require garbage collection. And
more and more commercial applications have macro languages builtin.
The only one I've ever liked was AutoCAD (on the PC), which has
XLisp builtin! Applications you develop in MCL have Common LISP
and anything you can build on it as their macro languages!
The file size of shrink-wrapped application programs, like Word, Excel
and PageMaker, has been growing at roughly 25% per year. However,
a user's total hard disk space has been increasing by more than 50%
per year. That's why users aren't complaining much. The size of
MCL-created standalone applications is quickly becoming a
non-issue. Beyond the base size the increases are incremental. Apple
is very sensitive about size and is probably working on reducing it,
but I already don't care about it.
> 2) When will garbage collection not cause so much of a hiccup?
In a posting to the MCL Discussion on AppleLink titled "Clarifications
on GC in MCL 2.0", Harvey Alcabes, MCL Product Marketing Mgr, stated
"the ephemeral garbage collector was not done in time to be included
in MCL 2.0B1. We hope to have it ready to include in MCL 2.0 final
which will be sent automatically to all purchasers of MCL 2.0B1 when
it is completed later this year".
Subsequently, Harvey announced that MCL 2.0 final will ship in early
1992 (info-mcl posting "Re- MCL 2.0 release date", Sept 3, 1991).
MCL 2.0b1p3 is the current version. The patches to 2.0b1 are available
> 3) Is there any rule of thumb that I can use to estimate the
> performance differences between an MCL application and a C++/MacApp
> application? In other
> words, is there a performance penalty for using MCL over C++/MacApp
> and what is a reasonable guess (10%, 20%, 50%)?
As you handcraft C code on a microcomputer you can visualize the
machine language (read "assembler" code) that will be generated.
That does not imply anything about the speed of C++/MacApp
applications (although it may say something about the utility of
C for high-level programming). CLOS, designed for Common LISP,
presumably integrates better with it than C++ does with MacApp.
MCL provides you with a high-level framework, but lets you drop down
as low as you want anytime you want. For example, MCL lets you tap
into the event loop at 4 different levels of abstraction (see the
Events chapter in the Reference). There is a foreign function
interface to any code in MPW object file format. You can even
program in embedded Lisp assembly language.
I haven't noticed a speed difference (below 15% you can't tell the
difference without side by side comparison) from the point of view
of a user operating a user interface. MCL runs fine on my SE. The
SE is disk bound, not processor bound. So is a stock Mac II, by
the way! For a GUI-driven application, you can expect about half
your LISP code to interface pretty directly to the ROM.
Syntactically, it won't look very different from Pascal code (MCL
supports Pascal-like record descriptions and trap names), but the
difference in the development systems is remarkable - MCL allows
step-wise incremental code-and-test cycles like never before!
As an example, you can use defpascal to define callbacks, eg from
_TrackControl for real-time tracking thumbs in scroll bars. The
thumb tracks and scrolls the image pane as fast from MCL as I've
seen anywhere, and MCL has this support builtin, and includes
the source as a programming example!
> 4) When will I see a class library of the scope of MacApp? Will I
> have the source to this library?
There is a comparison of MacApp and MCL classes on p93 of "The
Power of Macintosh Common Lisp" by Ruben Kleiman, in "develop",
vol 2, issue 1 (Winter 1991), p85-113. This article gives an
excellent comparison of MCL to MPW, MacApp, ViewEdit and
Object Pascal. Source for the mini-application developed in the
article is available on the associated Developer Essentials CD,
and also now on the monthly developer CDs. I think it may also
be on some of the System 7 CDs.
Some actual source is distributed with MCL in the form of example
files. Just how much will be made available is unclear. I expect
that additional source, especially relating to classes and the
event system, will be made available to developers on an as-needed
basis. The LISP community has a tradition of distributing system
source code. However, CLOS has introduced "protocols" for
information hiding, so anything in MCL that isn't documented or
is internal to a protocol may be changed by Apple without
considering you. You already know the rules for Mac OS sources.
MCL's approach to a "class library" is different from MacApp's.
MCL does not suffer from the numerous limitations of the Resource
Manager; you only use resources if and when you want to.
> 5) When will I see a class browser tool that shows me everything
> I need to know about all of the classes in MCL?
I agree that it is Apple's responsibility to provide a class browser
In the meantime, the built-in Inspector (source is provided) gives
you that information on a class by class basis. MCL 2.0 final will
contain some of the informational functions that are part of the
MOP. See Apple's message "Re- CLOS" posted to info-mcl on 12/23/91
for advance documentation. The grapher.lisp example file graphs
class hierarchies. So far noone outside Apple with the
motivation to convert the relevant parts of PCL appears to have
had both the time and the know how.
> 6) When will the IFT be upgraded to handle all of the interface
> classes? I'd like to be able to layer views and have more control
> over their initial settings like I get with ViewEdit. I'd also like
> to be able to define event behaviors for a view
> within the IFT tool (e.g, adjusting cursors, mouse down/up events,
> double/triple clicks, etc.) as well as defining new classes of views.
Good question. As with the class browser tool, much of the raw material
(ie source) comes with MCL. It is a matter of integrating and
polishing it. The IFT needs to be "productized". Only Apple is in a
position to sponsor this because the IFT needs to continue to ship
with MCL, including source. If Apple does this, then MCL can become
the premier development environment for the Mac. The hardest part
is designing what the IFT interface should look like.
As stated under 3) above, for a GUI-driven application, you can expect
about half your LISP code to interface pretty directly to the ROM.
For a typical application, the IFT should be able to generate just
about all of it. How much can it generate now, the easiest 20%?
I too recently asked Apple to consider documenting more of the
mechanism for manipulating the layers of sub-views.
> 7) When will the equivalent of the MacApp tutorial and cookbook be
> created. These should handle all of the things that I would need to
> do to create a product-quality application (e.g., undo, printing,
> exception handling including low-memory conditions, etc.).
> By the way, I think the tutorials on the IFT and CLOS are
> pretty good but would be a prerequisite to what I've described.
> 8) Will there be a coding-style document explaining guildlines
> for packaging and organizing code into files for a project
> (including code for multi-methods) as well as guidelines for writing
> lisp code, writing higher performance code, writing code for
> stand-alone applications, and how to organize and write code
> for portability.
There's a bunch of portable defsystems; some of them available from
Apple electronically, but nothing so far on "packaging and
organizing code into files for a project" like Think's projects
or MPW's Projector - hopefully Apple will address this.
"guidelines for writing lisp code" are available in a number of
excellent texts, including Norvig's book. See info-mcl message
"Publication announcement of new AI programming book", 11/25/91;
"Paradigms of Artificial Intelligence Programming: Case Studies
in Common Lisp" by Peter Norvig, Oct 1991, Morgan Kaufman, $40.
Source is available electronically. See an appendix in the MCL
Reference for an annotated bibliography of the best texts.
"writing higher performance code" comes from learning how the MCL
implementors write their code. Read the various sources that come
with MCL. File LAP.Doc documents the Lisp Assembly Programming
language. It tells you how to read LAP code. You can disassemble
your own Lisp code to help you learn LAP. Then you can
disassemble system LISP code to see how high performance code
was written by the implementors. LAP.Doc also tells you how
you too can embed LAP code in your programs for really high
performance and precarious living.
"writing code for stand-alone applications" is documented in an
appendix in the Reference. The implementation has been
overhauled. MCL 2.0 final is supposed to include some standalone
"portability" is outside the scope of the documentation of a
language implemented on just one machine. There's plenty of good
material in Lisp Pointers and other journals on cross-platform
window systems, program porting, portable foreign function call
protocols, and even defsystems. CACM of Sept 91 is a good place
> 9) What's a good strategy for localization of applications? What
> are the technical aspects of modifying my product produced with
> MCL for international markets? By the way, I don't know that I
> have seen Apple address this issue for applications produced by
Today this means dealing with non-Roman script systems. For this I'd
start by looking at Inside Mac vol 6, chapter 14, "Worldwide
Software Overview". Unless Apple comes forward perhaps you will
find someone in Japan or elsewhere who is addressing this for MCL.
To program this you will need an Apple document titled "Macintosh
Worldwide Development: Guide to System Software"; I haven't seen it.
> 10) What is Apple's commitment to MCL? The answers to the questions
> above will allow me to judge the commitment level at least for the
> near term. How does Apple see MCL fitting into its PowerPC, Pink,
> and Enterprise plans? Does it plan to provide MCL and all of the
> necessary libraries to these platforms when these things appear?
For the past several years Apple has shown a strong and consistent
commitment to provide an Apple labelled complete Common LISP for
However, Apple should pursue MCL developer productivity tools,
tech support, and promotion more seriously. There is a standing
joke that the existence of APDA is a well-kept secret. See for
example the message "Where to buy MCL" posted on info-mcl; Apple
dealers were unable to tell a prospective user how to obtain MCL.
By my estimate, the number of MCL users is an order of magnitude
smaller than I had previously guessed! Apple tells the world it is
becoming a software company, but the only supported development
tools you can buy from its subsidiary APDA, are from 3rd parties!
With regard to new platforms and ROM libraries, Apple's track record
is good, and better than third parties'. MCL final will of course
run on the new Macs. MCL also runs fine on my SE under System
6.0.5 even without MultiFinder. Apple distributed a hundred System
7 interface files for MCL months before System 7 was released. The
QuickTime interfaces have finally been released. The holdup was
apparently due to there being so many bugs in the Pascal interfaces
until recently, they could not be successfully converted to MCL.
Given that MCL is so great, and that C++/MacApp as another Apple
development system suffers from a lot of the same policy problems,
and that Think products suffer from being outsiders, to me the
choice of MCL is clear.
I'd like to see Apple take the necessary steps to allow MCL to
become the premier development environment for the Mac. To start
with, are any MCL activities planned for MacWorld?
And what do others think?