[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: MCL direction
- From: Marc Domenig <firstname.lastname@example.org>
- Date: Fri, 3 Jan 1992 09:04:31 +0200
- Conversion: Prohibited
- X400-content-type: P2-1984 (2)
- X400-mts-identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;920103090431]
- X400-originator: email@example.com
- X400-received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/; Relayed; Fri, 3 Jan 1992 09:06:53 +0100
- X400-received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Fri, 3 Jan 1992 08:04:31 +0100
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
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?