TK0GRM1@NIU.BITNET (Gordon Meyer) (06/17/89)
Hello Netters! I'm a lowly ST *user*...the only programming language I've ever used is basic (aside from a tiny little bit of Z80 assembly a few years ago) so I am not, by any stretch, a "programmer". Having had my ST for a few years I've often seen remarks by people that ARE programmers..indicating the ST is "fun" to program. These comments have finally gotten my curiousity up.... 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. Regards... -=->G<-=- -------------------------------------------------------------------- | Gordon R. Meyer, Northern Illinois University, Dept of Sociology | | GEnie: GRMEYER, CIS: 72307,1502, Phone: (815) 753-0555 | | Bitnet: Tee-Kay-Zero-Gee-Are-Em-One AT Enn-Eye-You.bitnet | |------------------------------------------------------------------| |------------------------------------------------------------------| | Disclaimer? Grad students don't need 'em! | |__________________________________________________________________|
swklassen@dahlia.waterloo.edu (Steven W. Klassen) (06/20/89)
In article <8906170329.AA03128@ucbvax.Berkeley.EDU> TK0GRM1@NIU.BITNET (Gordon Meyer) writes: >Hello Netters! I'm a lowly ST *user*...the only programming >language I've ever used is basic (aside from a tiny little bit >of Z80 assembly a few years ago) so I am not, by any stretch, >a "programmer". Having had my ST for a few years I've often >seen remarks by people that ARE programmers..indicating the ST >is "fun" to program. These comments have finally gotten my >curiousity up.... > >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. > If you don't like to paint, you won't like it any more on canvas than on cardboard. If you don't like to hunt, you won't like it any more with a 7mm Magnum than with a .22 rimfire. If you don't like to drive, you won't like it any more in a 911 Turbo than in an Austin mini. IF YOU DON'T LIKE TO PROGRAM, YOU WON'T LIKE IT ANY MORE ON AN ATARI THAN ON AN IBM PC!!!!!!!!!!! Steven W. Klassen Computer Science Major University of Waterloo PS - I love to paint/hunt/drive and love to program on my ST!
apratt@atari.UUCP (Allan Pratt) (06/21/89)
In article <14596@watdragon.waterloo.edu> swklassen@dahlia.waterloo.edu (Steven W. Klassen) 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. > > If you don't like to paint, you won't like it any more on canvas than on > cardboard. > [etc...] > IF YOU DON'T LIKE TO PROGRAM, YOU WON'T LIKE IT ANY MORE ON AN ATARI THAN ON > AN IBM PC!!!!!!!!!!! Why did you (swklassen) flame this guy? He didn't say, "I hate to program, and I hate programming on the ST." What he said was, "Here is your chance to tell an interested novice about programming the ST without starting a religeous argument." 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. 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. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
greg@bilbo (Greg Wageman) (06/23/89)
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.
rmanzie@miclon.UUCP (Roddy Manzie) (06/29/89)
In article <1109@snjsn1.SJ.ATE.SLB.COM>, greg@bilbo (Greg Wageman) writes: > 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). > > Greg Wageman DOMAIN: greg@sj.ate.slb.com Without wanting to turn this into a sunview group, I can't let sunview be slated incorrectly. Faults it may have, but this isn't one of them. The simple notifier interface is as described, but a more advanced usage is possible using the calls notify_do_dispatch(), notify_no_dispatch(), and notify_start() to force the notifier to process outstanding actions, some of which may call user handlers, then return to the user immediately, giving, as I understand it, the features you have in TOS. So, you have the ability only to give control to the notifier when you want to rather than the opposite (notifier only gives you control whan it wants to). Either is possible. I could go on at length, but this is not an atari subject, so.... Roddy Manzie, Micrognosis. ...uunet!mcvax!ukc!miclon!roddy roddy@uk.co.mic.lon roddy@miclon.co.uk