[net.micro.mac] Ease of programming, Mac, Amiga

blh@g.cs.cmu.edu (Bruce Horn) (09/17/86)

The Amiga vs. Mac discussion has, for the most part, been interesting.  I
think that David Phillip Oster's post was reasonably accurate aside from the
one page text editor.  I think to do an editor right would require about
four pages to handle scrolling, file I/O and so on.

I am a fan of some of the Amiga's features, such as the multitasking (which
could have certainly been done better--why not keep track of the memory
allocated as part of the task block so that you can kill a task and recover
the memory?), the communication ports, and the nice defaults provided by
Intuition to handle window resizing, etc.  Amiga proponents should stick to
what is truly better about the Amiga than the Mac.  Matt Dillon's reply to
Oster's post was a little off the mark:

1)  With MacInTalk it is just as easy to get the Mac to talk to you as the
Amiga.  The Mac's sound software seems to be more flexible than the Amiga's,
with the beeper (square-wave synthesizer), 4-voice engine, and free-form
synthesizer.  A friend here at CMU wrote some music software for the Amiga
(quite nice software, as a matter of fact) and stated that the Mac would
have been better for his purposes.

2)  I believe that the results of a crash on a Mac and the Amiga are quite
similar.  Rarely do I have to reboot the Mac because of a crash--I just exit
to the shell and everything is OK, the shell being either LightspeedC or the
Finder.  Now and then things get so messed up that I do have to reboot--but
not often.  I don't quite understand the comment about "rebooting from
scratch"--the Amiga OS is in write-protected RAM, but then the Mac OS is in
ROM, which I would think is roughly equivalent.

3)  I don't understand Matt Dillon's "HA!" about Resources.  I think that he
missed an important point:  you don't have to have the sources to change the
appearance of the software.  All the Amiga's "resource editor" will do is
output C code to create the dialog that you laid out--changes are nearly as
difficult, and there is still this strange struct in your code that isn't
exactly readable.  There is a lot more to Resources than just dialogs and
alerts anyway.

4)  On the Mac you can replace any ROM code with your own just like the
Amiga.  In fact, many applications do this (e.g., Switcher and LightspeedC
both handle ExitToShell, as well as other traps).  Because other code
is loaded as either Packages or Drivers (as resources), you may temporarily
override non-ROM system code with your own, or replace it.  Same with fonts, 
desk acc's, system dialogs (including the standard file "requester"), and
so on.

5)  From what I understand, the Amiga handles graphic printing just like the
Mac:  with a printer driver written for a particular printer.  Low-level
printing (such as text only) is handled by the Amiga more easily than
the Mac...but aren't we trying to support high-level text and graphics?  By
the way, the Byte article comparing the Mac and the Amiga was plain Wrong
about printing--you can print exactly the same way to the LaserWriter as you
can to the Imagewriter, and the results will be very good.  As on any
piece of hardware that is compatible with previous equipment, if you want to
take advantage of the new features (PostScript), you are allowed to.

6)  Multitasking doesn't help your turnaround time.  If you have other
things to do, then it's great (I like multitasking A LOT).  Otherwise, you
are still going to be waiting for the compiler and linker.  Any memory hacks
you can do on the Amiga you can do on the Mac as well ("With a 1Meg Amiga,
you could keep the entire compiler and editor in memory...").  I still think
LightspeedC wins big--fast compiling is fast, period.  You'll still be
waiting for "Deep Thought."

7)  The Amiga will certainly be making big strides in the software area, but
do you think the Apple folks are just sitting around?  Granted, we made some
mistakes early on (Lack of support for multitasking, for one--I want to go
on record as having promoted multitasking for the Mac very early;  I wanted
to build the system so that we had the option for an easy upgrade to
multitasking, but was "convinced" otherwise). I'm sure Larry Kenyon and the
other folks at Apple are improving the Mac system software in some very
fundamental ways, and that the future of Mac software will be at least as
good as that of the Amiga.
-- 
Bruce Horn, Carnegie Mellon CSD
uucp: ...!seismo!cmucspt!cmu-cs-vlsi!bl
ARPA: blh@vlsi.cs.cmu.edu

dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/18/86)

Bruce Horn, Carnegie Mellon CSD WRITES:
>6)  Multitasking doesn't help your turnaround time.  If you have other
>things to do, then it's great (I like multitasking A LOT).  Otherwise, you
>are still going to be waiting for the compiler and linker.  Any memory hacks
>you can do on the Amiga you can do on the Mac as well ("With a 1Meg Amiga,
>you could keep the entire compiler and editor in memory...").  I still think
>LightspeedC wins big--fast compiling is fast, period.  You'll still be
>waiting for "Deep Thought."

	Well, I can't say I know a whole lot about the mac, so I thank your
corrections.

	I agree that LightSpeedC wins big, but I don't agree on your point
about multi-tasking.  You actually CAN have both an editor and a compiler on
the MAC at the same time, but can only have one running at a time.  So
the advantage of the Multi-tasking is simply that you can run both the editor
and compiler at the same time (that is, be editing something while the comiler
is compiling something else).  This does not slow the compiler down in the
least, since your keystrokes into the editor couldn't be taking more than 5%
of the CPU.  

	I run my terminal program over the modem from my amiga all the time.
When I want to compile (or do something else) on the amiga, I don't have to
freeze the terminal program.  In fact, while the compiler is running I might
be reading my mail on ucbvax.  Again, the modem program is mainly passive so
other processes run at full speed.

**	The point here is that multi-tasking gives you a practical working
enviroment just by existing, and that should be taken into account whenever
you compare the two machines or those comparisons will be moot.

Notes on graphics managment:
	Since you can have multiple processes (that don't know about each
other), the window managing system necessarily must be able to handle X
process writing to X possibly overlapping windows.  Thus, if your going to
open your window on the workbench screen, you must follow the rules.  Any
graphics calls (plot/line/circle/blitting/etc....) automatically follow the
rules.  This is not a limitation, however.  If you want FULL control, you can 
simply open your own custom screen with it's own width, height, depth, video 
modes, color map.. and do your own managing (or even opt to have intuition 
manage your custom screen).

	The level that handles the windows is called the layers library, and
utilizes rectangular cliptrects.  Text/graphics which are placed in
hidden areas are automatically placed in other memory so a window move can
'reveal' stuff under it without the program having to do anything.  The reason
the layers library handles only rectangular cliping regions is simply... for
speed.  If you want arbitrary clipping regions you have to do it yourself on
the Amiga, but it isn't difficult.  One blitter pass on the rectangular area
surrounding the oddly shaped cliptrec with a stencil would work very well.
The blitter, after all, has an effective transfer rate of about 12Mbyte/sec,
faster if you use 'blitter nasty' mode (~6Mwords/sec = 12Mbytes/sec.), which
means you can do at-least 180 passes/sec on a 320x200 bitmap).. These values
are lower bounds by the way... in fact, if you calculate it out it looks like
I'm wayyy too low. I'll do some tests tonight and give you better figures.

					-Matt