Re- MCL Direction

[STEVE.M@AppleLink.Apple.COM (Aladdin Systems,Steven Mitchell,PRT)]

To:     Dave Lucky       [76557.704@COMPUSERVE.COM@INTERNET#]
cc:     info-mcl         [info-mcl@cambridge.apple.com@INTERNET#]
        Harvey Alcabes   [ALCABES]
From:   Steve Mitchell   [STEVE.M]
Date:   12-31-91
 
Sub:    MCL Direction?
 
        Open letter reply to Dave Lucky's info-mcl posting of 12/31/91.
 
Dave:
 
> 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
   right.
 
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
   questions...
 
 
> 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
   electronically.
 
 
> 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
   tool.
 
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.
 
Good question.
 
 
> 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
   program examples.
 
"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
   to start.
 
 
> 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
> MacApp.
 
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
   the Mac.
 
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?
 
_Steve