Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!usc!cs.utexas.edu!uunet!snjsn1!bilbo!greg From: greg@bilbo (Greg Wageman) Newsgroups: comp.sys.atari.st Subject: Re: What's so FUN about the ST?!? Message-ID: <1109@snjsn1.SJ.ATE.SLB.COM> Date: 22 Jun 89 17:13:10 GMT References: <8906170329.AA03128@ucbvax.Berkeley.EDU> <14596@watdragon.waterloo.edu> <1580@atari.UUCP> Sender: news@SJ.ATE.SLB.COM Reply-To: greg@sj.ate.slb.com (Greg Wageman) Organization: Schlumberger ATE, San Jose, CA Lines: 125 In article <1580@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >> In article <8906170329.AA03128@ucbvax.Berkeley.EDU> TK0GRM1@NIU.BITNET >> (Gordon Meyer) writes: >> >Hello Netters! I'm a lowly ST *user*... [edited] >> >What is so fun about programming on the ST? >> >Note that I don't want to be a programmer...so don't try and sell >> >me any packages. Consider it cocktail party conversation. >> >I like to program the ST because it doesn't get in my way. I haven't >done much programming on a Mac, but the impression I have gotten is that >there is a lot of overhead involved in getting a program flying, while >on an ST you can say puts("Hello world."); and be done with it. > >Note that I am not a GEM programmer. If I were, I would notice all the >things which get in the way. Even so, I am given to understand that GEM >isn't as much of a pain as the Mac's application manager. It's true that, for non-GEM programs, the ST is easier to program. In fact, it is much like a standard Unix machine, except for a few multitasking and signal (software-interrupt) facilities. To write a GEM-based application, the amount of overhead is about equal to a Mac. Macs have a certain amount of "boiler-plate" code that must be there for them to function, just like the ST has "appl_init()", "form_dial()", "objc_draw()", and "form_do()". When you start manipulating windows on the ST, you quickly get into as much "mess" as on the Mac. >Naturally, the lack of complexity and lack of enforcement of "rules" of >programming makes some things harder on the ST, and makes upgrades like >a new TOS or multitasking (on the Mac, MultiFinder) difficult. It's all >too easy to do something "by hand," using explicit addresses or data >structures which are meant to be private to the OS. When we change the >way those addresses or data structures are used, your program will stop >working (c.f. the 'mem' command in Gulam under TOS 1.4). > >This environment is nice because it doesn't shackle you, but the absence >of shackles also makes compatibility of OS upgrades difficult. The reason people run into trouble with OS compatibility is that they try to be too clever. Unsatisified with the speed of execution or response of the standard TOS routines, or to circumvent bugs, they delve into the OS code and engineer their own alternatives. I have written a lot of ST programs, some of which will soon be released as shareware. I don't anticipate any compatability problems because I have always relied on the official Atari-documentated interfaces. Of course, this means that my programs won't always be as quick or responsive as others with hand-tuned assembler routines, but they're "legal". This is a design decision that commercial publishers have to make. Many bite the bullet, and go for speed over compatibility. If TOS worked as advertised from day 1, in many cases this wouldn't have been necessary. But that's water under the bridge, as they say. I have found the ST easy to program. The OS provides a huge (and daunting, to a novice) range of services. There are frequently multiple ways of doing things. For example, there are at least two means to simply draw colored lines on the screen: via VDI and LineA. Within the VDI itself there are multiple routines that can be used to do the job, in different ways. Once one gets over the learning curve and understand the abilities and limitiations of the various functions, one gets a rather heady feeling of power over the machine (without the price (-: ). The resource file provides the programmer with a means of making all text independent of the code. It is possible to write a program with no imbedded text strings, that never need be recompiled for translation into other languages. This is very desirable, given the international nature of the Atari ST marketplace. This also reduces the size of executables, since the actual text resides in the separate resource file, or in the ROM if you take advantage of TOS's inbuilt error messages. And while trying to construct a typical object tree by hand is, at best, a challenging experience, a good resource construction set (RCS) makes this task nearly trivial. Of course it takes some experimentation to come to understand all of the options and objects that are available, and just what they can do for you. However, the time spent is well rewarded when you discover just how flexible and powerful the forms-based user interface is. I have written a number of window-based applications on a Sun workstation, under SunView1, and I have frequently wished for a RCS-type of tool to eliminate the hundreds of lines of code that must be written to generate a window-based tool, most of which are parameter selection and object placement similar to what is specified in the OBJECT structure. The structure of a program using the "Notifier" under SunView (something like an evnt_multi() call) is also much more restricted than is a GEM-based program under TOS. Under SunView, the programmer sets up the window and calls the Notifier. The Notifier only returns control to the programmer, by calls to programmer-specified routines, when the user has taken some action. The programmer's code cannot get control until the Notifier grants it. On the ST, the programmer gives up control to TOS only when he wishes, and then only until a requested event occurs (ignoring interrupts, of course). This allows the flow of control and the program structure to be much more straightforward and obvious. This, in turn, reduces complexity and potential for unwanted "features" (i. e. bugs). The "forms" functions provide easy access to automatically-verified forms-based user input. IF THESE WORKED, they would shift much of the typical error-checking burden onto TOS. However, this is one of the major letdowns, as the TEDINFO code is seriously buggy. Ah, well. Once one understands the somewhat non-obvious modus operandi of the standard file selector, even this becomes a convenience for the programmer, and certainly for the user, who needs to understand only one method of specifying and selecting files. In summary, I don't find TOS getting in my way at all; in fact it provides in ROM many of the services I would otherwise have to write myself. The only time it "gets in the way" is when those services don't work properly or at all, or aren't documented properly or at all. And this, I am told, is "fixed in TOS 1.4". Longish .signature follows. Skip now. Greg Wageman DOMAIN: greg@sj.ate.slb.com Schlumberger Technologies UUCP: ...!uunet!sjsca4!greg 1601 Technology Drive BIX: gwage San Jose, CA 95110-1397 CIS: 74016,352 (408) 437-5198 GEnie: G.WAGEMAN ------------------ "Live Free; Die Anyway." ------------------ Opinions expressed herein are solely the responsibility of the author.