Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon From: dillon@CORY.BERKELEY.EDU (Matt Dillon) Newsgroups: net.micro.mac Subject: Re: Easy of programming, Mac, Amiga Message-ID: <8609152222.AA23166@cory.Berkeley.EDU> Date: Mon, 15-Sep-86 18:22:47 EDT Article-I.D.: cory.8609152222.AA23166 Posted: Mon Sep 15 18:22:47 1986 Date-Received: Tue, 16-Sep-86 09:09:18 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: University of California at Berkeley Lines: 179 >From: (David Phillip Oster) >I am not a great amiga expert, but the mac has some definate advantages >for the programmer in certain areas: > Text handling - when the mac was released, they gave me a one page > pascal program that implemented a mouse based text editor with cut, > copy, and paste. I sincerely doubt you could do as much on the amiga as > concisely. If it's only one page I'd like to see it. > Sound - recently net.micro.amiga had a note from R.J.Micah, one of the > designers of the Amiga's software, giving three pages of C code to do > what a mac programmer does as "SysBeep(1)" Most amiga programmers use > the equivalent of MacInTalk to make their machine say "Beep" because it > is too hard to get a tone out of it. For simple BEEPS, the MAC wins. One thing I'd like to see as an addition to one of the run-time libraries for the amiga is a simple BEEP call. It isn't dificult to make the Amiga BEEP, just long winded because the run-time library was set up to utilize the full capability of the amiga's sound and you have to set-up a lot of junk. Taking another point of view, I can make the amiga say something to me with a very simple program (maybe even less than a page). Try doing that on a MAC. > Debugging - for $25 you can get an Apple software supplement that > includes the debugger MacsBug. MacsBug remains in memory application > after application, can dissasemble any code, can give a symbolic trace > of the calling tree, knows the name of each operating system call, and, > with its ES command, lets you exit back to the Mac's shell from a > crashed application. It is not even the best debugger for the Mac. > Nothing even as good as it exists for the Amiga. Most amiga programmers > have to reboot their whole machine if even one task crashes. Nothing quite as good exists for the amiga, but there is a program called 'wack' that does almost as much (everything except the OS call names and symbolic trace). Additionaly, there is a version in ROM that allows you to do post-mortem debugging. There are several versions of Wack. One allows you to delve into the task-structures, system modules, run-time libraries, resource lists, system modules, and other things. And, of course, it disassembles code. If a single task crashes and doesn't upset the rest of the machine, it is frozen (and an alert comes up), but the machine still continues to run other tasks. If a task destroys something very important, the machine comes up with a dead-end alert and you must reboot. If even one task on the MAC crashes (oh! I'm sorry, there is only one task!), you have to reboot your MAC too. Also, when you reboot the amiga you almost never have to reboot from scratch, since the OS is in write-protected RAM. > Resources - The Mac has a what-you-see-is-what-you-get editor called > the resource editor that allows you to change menus, fonts, icons, and > every detail of alerts and dialogs (requestors on the Amiga) without > ever recompiling. An amiga programmer must laborously speel out these > things in C code that does not look at all like the finished product. HA! this is a major difference between the Amiga and the MAC. On the MAC all your requestes and such form a kind-of 'secondary' file, and thus you can easily edit it without recompiling your program. I agree that we don't have anything like a resource editor for the Amiga yet, but there will be one soon. Of course, since the Amiga has a normal file-system and a completely different method of handling menu's and such, the editor would generate C global structures that would then be compiled rather than modify the resource file directory ('cause there ain't to resource file). > Fast dynamic linking, the Mac's control definition procedures, menu > definition procedures, window definition procedures, and packages allow > programmers to substantially change the behavior of compiled code > without recompiling it. I myself have taken Apple's finder, pasted a > new window definition procedure into it using the resource editor, and > made all the windows apple shaped. Apple replaced the standard file > interface recently, and all the old programs suddenly became able to > cope with a hierarchical directory structure, something no other > machine has done without requiring all the software developers to come > out with new releases of their programs. (Unix recently when through a > change in its directory structure, and everybody had to recompile.) The > standard amiga linker is so slow it is known as "Deep Thought" IBM changed from flat to hierarchical without any problems. Since the Amiga employs run-time libraries, and there are system calls to modify library vectors, one could easily modify whichever call he wanted to do something else. In this case, I think the Amiga is more flexible. It means you can change any call in Exec, Intuition, etc... even completely replace system 'rom' modules with your own. (All sounds, window handling, system calls, DOS calls, and most other things are accessed through run-time run-modifiable libraries.) As for the file-system, the Amiga has always had a hierarchical directory structure. It's only slow getting directories. It's speed lies in reading/writing/finding. (but here I believe the MAC+ has a faster filesystem; the amiga only beats out the older MACs). > High level printing - Since mac applications comminucate with printers > as if they accepted high level graphics calls, most applications did not > need to be recompiled to accept laser printers, even though the > applications had not been designed with laser printers in mind. Amiga > applications have to have special code for each kind of printer. The code is part of the system. A particular application program doesn't need to know or care what kind of printer is on the other end, it just uses a standard set of escape codes through AmigaDos's printer device (just another file). I think the Amiga's printer interface wins here. > safety - the amiga crashes if you draw a line that extends outside the > screen. (According to a friend who regularly crashes his amiga this > way.) The mac graphics system calls, although they aren't very safe, > are safer than this! This only happens if you are not using intuition. If you are using Intuition, OOB lines are clipped properly. In fact, one uses the same graphics calls whether using a custom window or one with cliprects. In fact, anything you do via cliprects is clipped properly. In fact, you can have X processes in overlapping windows and completely oblivious to fact as the graphics are clipped properly and saved in alternate buffers so when you move the window nothing is lost. Most people use cliprects, at least during development. > Disk Operating system interface - The mac's operating system takes a Pascal > view of the world. this is not great for a C programmer, but most Mac > compilers have a pascal keyword that handles the details. The system > itself is pretty decent. The Amiga's operating system is written in > BCPL. BCPL is a ancient British language that was directly responsible > for the birth of C. The designers of C started out in BCPL and > concluded that it was not possible to make a BCPL compiler that > generated decent code for a byte addressable machine. Here you are incorrectly assuming that the entire OS is written in BCPL. This is not true. ONLY AMIGADOS is written in BCPL. All the other stuff (Intuition, layers, graphics, devices, the system exec.,...) was written by Amiga in C. I hate pascal. > programming environments - LightSpeed C, with its integrated > compiling, linking, multi-window editor, make, grep, and profiling > is so good and so fast, that I've known users of 8MegaByte, 16MegaHertz, > Sun3 68020 systems to prefer to develop on the mac and port their code > to the sun, because the 1MegaByte 8MegaHertz 68000 mac has a faster > edit, compile test cycle. Currently, and I know of nobody on a 68020 Sun3 who uses a MAC to compile. Remember that the Amiga is multi-tasking. You can EDIT and COMPILE at the same time, leaving your edit active, etc... However, LightSpeedC currently beats the shewabs out of Lattice and Manx on a 512K Amiga, which does make a big difference. With a 1Meg Amiga, you could keep the entire compiler and editor ram-resident, have the editor running continuously (ala multi-tasking), and I think the Amiga just may beat LightSpeedC. As for programming ease, the multi-tasking does all the integrations you need. Add a shell and your set. >Conclusion - both machines have their strengths and weaknesses as >programming machines. I would probably choose an amiga if I were going to >write "Pong". I would certainly choose the mac if I were doing anything >involving fonted text manipulation or object oriented graphics. Although >the hardware of the Amiga should be faster than a Macintosh, the superior >software of the Mac consistantly makes it easier to use, faster, and more >powerful at the kinds of tasks that I like to do. >--- David Phillip Oster -- "The goal of Computer Science is to And the hardware on the Amiga IS faster than a MAC+. The MACs software may be superior now, but then again the MAC's been out a couple years longer than the Amiga. Lets see what happens in another year, you may be in for some surprises. -Matt