info-mac@uw-beaver (info-mac) (09/22/84)
From: Gustavo Fernandez <FERNANDEZ@SU-SCORE.ARPA>
Hi, I'm Gus Fernandez, a new grad student at Stanford.
I spent this past summer writing MacView, a 3-D graphics program
for the Mac which should be available from United Software of America
in a month or so. (pending documentation, printing, etc.)
I used the Lisa PASCAL development system, and Honestly, I think
it is still the only viable development system for the mac. Lots of native
development stuff is now emerging. Most of these are "quick" ports from other
systems. Things to look for in a development system...
1. Does it support the segment loader fully. This allows for relocatable,
purgable segments, and is much more flexible than overlaying, and is mostly
transparent to the developer.
2. Is full MAC memory management supported? This is a must, because the mac
heap is generally not well behaved.
3. How big is the runtime package? Only the required subroutines should be
linked, and the magority should be 5 line (or so) interfaces to the tool-
box, if not already done inline. As an example, I rote MacView as a single
6000 line, 130K source file. The object was about 56K. The library overhead
was only 2K.
4. How fast is the minimum compile-link-execute cycle? How automated is it?
The speed of the compiler is only a fraction of the total time used. Any
disk swapping makes this almost unacceptable.
5. Does the development system make inteligent use of the mac user interface?
You must think Macish to write Macish. A mouse driven editor would be a
minimum prerequisit. While using full menu bars and the like seems cluumsy
for the assembler,etc. (Look at Apple's assembler) An infocom style command
window with a UNIX shell inside would be nice. (See Zork, etc. for the Mac)
6. Can the package create full-fledged MAC applications? What about resource
compiling/editing?
7. Does the package claim portability to other systems? If so, stay away from
it. Very few programs can be ported to the mac and still be considered MAC
programs without a complete re-write. PFS File/Report is a perfect example
of such a failure. OMNIS2 is a joke.
A mac native development system suffers from many faults right off the
bat.
1. You know in your heart the the Mac really doesn't support hard disk. It was
never designed for it. You can tell by the lousy file system. The new finder
may alleviate part of this problem, but still, you will have problems
daisy chaining peripherals off the serial ports. Also, not hard disk is
standard, and the current standard file pacages interact with the user as
if small (400K) disks are on-line.
2. 128K is a problem. 512K will help, but that is still not standard. 68000
is generally "Fat" code.
3. You still need an extenal terminal, or a second MAC to debug. The new
16 line display debuugger is too small to do serious work, also, no hard-
copy capability.
This is how I would rate current MAC development systems.
1. LISA Pascal - Tried and true. This is what all developers except Microsoft
are currently using. The UCSD shell, however, is an insult to Mac users.
2. Microsoft dev. system - A C compiler running under XENIX which compiles
to P-code. (Use RMover on multiplan some day) Unfortunately, only Microsoft
has access to this one. Too bad.
3. SUMACC - A C cross compiler running on UNIX systems and downloaded to the
Mac. Nice, but still no segmenting.
4. MS BASIC, MAC BASIC, MAC FORTH, MAC PASCAL - These are not true development
systems as they require the host interpreter to run any applications. Mac-
FORTH level 3 is suupposed to address this problem, but it is not out yet
and VERY expensive.
5. Apple native Mac assembler - Full featured assembler is out on pre-release.
The MAC user interface is nice for the editor, but not anything else. The
EXEC capability is extremely limited. Completely disk bound.
6. AZTEC C - The prerelease I say completely ignored the mouse. (OMNIS2?)
While toolbox was suupported, programs could not be written to run outside
the shell. Supports overlays, but this is not the same as segments. I wish
Jim Goodnow luck.
7. SoftWorks C - Don't know much about it. I don't like the whitesmith's
compiler. (is it still unix version 6?)
8. Hippo C - Haven't seen it. Doubt that is supports full OS and toolbox.
(segmenting?)
9. Modula 2 - Not a native code compiler. The Mac can be very fast when running
native code. While most of the time is pent in the main event loop, a highly
interactive program can get tiring if just that much slower.
10.UCSD P system - A joke. Who in MACdom wants all those nested menus and modes?
UGH! This package would encourage portability, wwhich is impossible while
still retaining the MAC user interface.
11.Various "Other" MAC assemblers. I doubt that these will survive once the
"Real" one from Apple comes out. How good is the macro capability? How large
can source and code files be? Also, I doubt that you ould want to write a
complete Mac application (>30K) completely in assembler. Even MacWrite and
MacPaint and the finder are mostly written in PasCal.
I think that covers all of them. I hope I didn't miss any. I have yet to see
the MAC native PASCAL compiler from Apple. (January) Also, has anyone considered
writing a language specifically for the Mac, without regard to portability
considerations. Start off with PASCAL, delete PASCAL I/O library, add built-in
high-level memory manager, and object oriented window support. Something that
looks more like SMALLTALK, but without the huge overhead.
Gus Fernandez
FERNANDEZ@SU-SCORE
-------info-mac@uw-beaver (info-mac) (09/26/84)
From: Kirk Kelley <KIRK.TYM@OFFICE-2.ARPA> Regarding specific Smalltalk-like packages for the Mac ... Last I heard, Apple was working on translating the Smalltalk inspired object-oriented Lisa Toolkit into a Mac Toolkit. I assume it is done like the Lisa's in the Clascal upgrade to Pascal. I dont know if they also decided to go for an Objective-C version of the Toolkit. For what its worth, Dan Ingalls, implementer of early Smalltalks under Alan Kay and since at PARC, recently moved to Apple. -- kirk