[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re2: Mother ship App.
- To: email@example.com
- Subject: Re2: Mother ship App.
- From: "Tod Casasent" <firstname.lastname@example.org>
- Date: 21 Jan 1993 17:45:16CST
- Organization: Knowledge Based Systems, Inc.
- Priority: normal
- Reply-to: email@example.com
Lots of stuff cut out between the included comments.
> >MCL does infact make stand alone applications, even though
> >they're too big to be of any use to anyone
> Well, we have one MCL app which is being used in beta, one which has
>'shipped' (vertical market), and another under development now which is due
>to go into late beta by the end of February 93, and four more in design. I
>am sure that there are others out there...
The only problem we have with the size of the final application is in coming
up with a way to ship it. Is there some standard way to break up an MCL
application onto floppy disks???
> >The fact is, MCL makes B I G CLUMSY and BUGGY applications
> As others have pointed out, this is categorically untrue. Admittedly, I
See above comment for response to "B I G", and original letter.
We're doing an application that is highly interactive and graphics oriented.
Users p.o.v.: Clumsy is all in how you write it. Our MCL application
compares resonably speed-wise to our Windows application in C++. And for
redisplay, the MCL application is MUCH MUCH better due to some limitations
I'm told are due to Windows...
Programmers p.o.v.: Ok, integrated debugger, incremental compilation,
snapshots, fasl files, almost everything under the "Tools" menu. The only
machine better set up for LISP is a Symbolics, and that has its own
BUGGY - See final 2 comment for additional comments. Patch 1 fixes most of
the bugs we've found. Patch 2 will fix the rest.
>bigger. No, considering making regular standalone apps with MCL is tribute
>to the effort that has gone into keeping it lean (and mean).
The largest problem I've run into is that features that I, personally,
consider to be standard application functions are not sufficiently
documented (or not documented at all). These include:
1. Supporting AppleEvents
2. Allowing contrl-key, option-key and just plain keystrokes to be processed
without having a window open. (With a window open, the "documentation" as
it were, came mostly off this group.)
3. Describing the top-level function. Users don't want a Lisp Listener
hanging around if they're not going to use it.
>environments. What is more, it is also their best supported product, as we
>in info-mcl benefit from the same standard of technical support normally
>only provided under expensive and select programmes like the Apple Partner
>scheme. We should come to praise MCL, not blindly bury axes into it: if
>you want to offer constructive criticism, then surely a reasoned response
>to the three options for reduction in size would be a wiser move?
Kudos to everyone who spends time reading this stuff and giving answers.
For free yet (minus the cost of Internet or mail of course :-)
To Apple for offering free bug fixes and patches. (minus the cost of
Internet or mail of course :-)
Please document everything. I would be happier with complete and up-to-date
documentation than I would be with yet more (possibly undocumented)
Look at some standard Macintosh applications and ask yourselves, "Do we
allow programmers to emulate this action?" And then ask "Is it sufficiently
documented?" I'm not asking for hand-holding, I just want the bare
"Truth then, that's it truth. For when a man lies he murders some part
of the world. You should know that." - Merlin to Arthur in "Excalibur"
Jean - Henna neko da ne... == Hobbes - Do you believe in God?
Nadia - Raiyon yo! == Calvin - Well, Somebody's out to get me.
The opinions and statements herein expressed are not those of KBSI and,
if attributable to anyone, are mine.