Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!hellgate.utah.edu!helios.ee.lbl.gov!ucsd!usc!samsung!uunet!lll-winken!ubvax!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.sys.amiga Subject: Re: Difficulty in programming Message-ID: <1990Jun10.094710.7460@zorch.SF-Bay.ORG> Date: 10 Jun 90 09:47:10 GMT References: <2487@zipeecs.umich.edu> <1990Jun2.063414.10292@agate.berkeley.edu> Organization: SF Bay Public-Access Unix Lines: 81 X-Local-Date: 10 Jun 90 02:47:10 PDT In article <1990Jun2.063414.10292@agate.berkeley.edu> laba-1ei@e260-2f (Joseph Chung) writes: >In article <2487@zipeecs.umich.edu> gilgalad@dip.eecs.umich.edu (Ralph Seguin) >writes: >>Hi. I've been watching the discussion of how difficult it is to >>program the Amiga versus other systems. I've seen a lot of nonsense. >>Somebody has been making claims that it is relatively difficult to >>program the Amiga. It is just as easy, and often far easier to write >>stuff for the Amiga than most other systems around. >> > >Try this one on for size: > >In an IBM (no flames please!), if I want to put a character anywhere on the >screen, I just >1. load a segment register with the segment of the screen. >2. write the proper byte to the screen location (using a simple offset) (In >short, is a basic POKE command!) > >How would you accomplish this in an Amiga? >Let's see. >1. Create my own screen, or should it be my window (damn, where did I put > my copy of NewWindow struct ...) > >The above is just one very tiny example. In short, I would like you to show >me how programming a multitasking system can be *easier* than programming a >monotasking one. No problem! You are considering programming in the small, which is the wrong place to be looking for the benefits of programming the Amiga. Look instead at programming in the large. Many companies look at the large installed base of IBM-PC's and their clones, and say "$$$!!! That's the place to write programs for sale!". Then they get into the beta testing stage of a product and find: more than 20 incompatible printer formats, requiring a separate driver for each; half a dozen incompatible display technologies, requiring either separate drivers or complex code; at least two incompatible mouse technologies, requiring separate drivers; several incompatible raster image export and import formats, ditto; two or more incompatible memory expansion technologies, each with several incompatible software access technologies, ditto; imperfect or incompatible BIOS emulations, requiring separate product releases; a buggy and poorly maintained operating system, causing headaches all through the development cycle; and the list goes on. I was fired from a company a year ago because my (within size spec, within speed spec, meeting functional spec, bug free) code had "held up their development process" (actually, they'd overspec'ed their needs by a factor of four in complexity); the product release date had slipped seven months in the nine months I was there as a member of an 18 person development team! A year later, the product is _still_ not released, and this from about the fifth largest software developer for the PC family. A project originally intended to require 12 months has taken at least 30. Trying to develop _substantial_ code (not screen pokes) in the PC marketplace is at least one order of magnitude harder than it is in the Amiga market, I would guess, and the problem continues to worsen. Kent, the man from xanth. (What held up their development the most was the classic problem Fred Brooks described in The Mythical Man Month: throwing bodies at a late software project. The team went from 9 to 26 from the time the schedule started slipping. Each new person required that work be devised for them to do; most of the existing work was single threaded through one programmer, hard to teach or subdivide, so _new_ features were added to the product, making it late than ever. Still, their stock keeps going up. ;-)