🚀 go-pugleaf

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