MCL direction

[Marc Domenig <domenig@urz.unibas.ch>]

Sorry, yesterday's message was clipped. Here's the main point again and
a few comments on some of the questions posed by Dave Lucky:

My main point is that if you intend to live up to the "philosopy" of
Lisp to keep the data in memory, you need a large machine and the
memory issue is not to be neglected. Our experience:

    - the binary of our stand-alone application is 2.7 MB, which corresponds
      to little more than 2 MB of source.

    - if we load a document of 1.4 MB into our application, the dynamic
      data structures built require approximately 4.5 MB.

    - if we start to fill up our system with data seriously - the system
      can be considered a specialized database management system and the
      document of 1.4 MB can be considered the conceptual schema of one
      database - we will predictably end up with memory requirements of
      100 MB or more.


-- For these reasons, I think that the memory requirement
  issue should not be ignored. MCL is not a good solution for all kinds
  of software problems. It is excellent for many, and it is not
  necessarily bad for programs managing large databases. The "solution"
  to the problem we are aiming at in our project is a client/server
  architecture. This means that we will run the process requiring
  100 MB memory on a dedicated server in our
  network, where "small" client applications providing
  a user interface attach to it. It is my opinion that MCL is
  particularly suited for this kind of software factoring, because
  client/server communication is eased by Lisp's capability to process
  ASCII representations of data (which can be easily sent over any net).
  Moreover, the event handling provided by MCL is flexible enough to
  support the handling of multiple clients by the server. Maybe Apple
  should think about promoting this kind of  software architecture for
  MCL (it might also provide higher-level software support for multi-tasking,
  detailed user-interface guidelines for client/server programs etc.).

- Finally, I have a few comments about some of Dave's questions:

> 4) When will I see a class library of the scope of MacApp?  Will I
> have the source to this library?

I agree with Steve Mitchell that the class library of MCL is not worse
    than MacApp's. It is certainly less sophisticated than that of
    high-level class libraries like ET++ (based on C++), which are much
    richer and "deeper", i.e. where the user will never - or hardly -
    need to do any machine-dependent low-level programming at all.


> 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 think that's not one of the tools you really need for development
    once you are experienced. If you have the experience, you can
    realize one very fast. Besides, I'm certain someone will do it soon
    and publish it anyway.


> 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.

I agree that the IFT is nice only for novice users. The structuring
    of views into hierarchies and their layout should be supported
    by higher-level classes. Yet again, a little experience will let
    you write your own abstractions very rapidly and I'm sure the
    development team or users will come up with generic ones eventually.


> 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.

Steve Mitchell has given all the answers. I'd like to add from my own
    experience that switching to Lisp is really different to switching from
    Pascal to C, for example. You will find yourself changing your
    programming style dramatically several times over the first year
    or so, because it is simply not possible to grasp all the new
    options provided. Try it, after a year you'll be faster than
    ever before and you'll love it.


> 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.

AAs has been pointed out previously on this mailing list, resource based
localizing is not an object-oriented approach and should therefore
be dismissed. Maybe I miss a point here, but I don't see why integrating
localizing capabilities in an application should be a problem, given the
increased power of object-orientation and interpretative capabilities of Lisp?

Marc Domenig