AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (06/16/88)
[Sorry this is late--my site is having trouble talking to BRL.ARPA] >Date: Thu, 9 Jun 88 21:13:49 CDT >Reply-To: Info-Apple@BRL.ARPA >From: "Jeremy G. Mereness" <jm7e+@andrew.cmu.edu> >Subject: Re: Danger of IIgs+ >As computers can more handily perform the work we don't want to, >programmers have become lazier, code has become fatter and more >inefficient, and now, Macintoshes and even //GS's aren't practical >w/o a hard disk and require programming environments (avail. for >another $100 or more) to program on them. Hang on! We need hard drives because software has gotten *bigger*, but that doesn't imply that it's inefficient! Sure, *some* of it is, but MOSTLY it's just many times more COMPLEX than the software of yesteryear. Sure, the Applesoft "programming environment" is FREE. But it's well worth $100 for me to have a linker, text editor, library utilities, macro assembler, and other utilities. Also note that all of Apple's toolsets, all of the IIgs ROM code, and all of ProDOS is written in straight assembly language for efficiency. This doesn't mean it's as fast as we would like. Some of the stuff *could* be faster if it was made less general-- for example, QuickDraw is not a very fast way to do full-screen windowless animation. You can write your code code if you need the speed for a specific application. But QuickDraw needs its flexibility to support arbitrarily-shaped overlapping windows, and to support the Print Manager. The straight assembly-language coding also means, of course, that we are STILL waiting for the "real" ProDOS 16. >There is an arcane elegance to the old ]['s of yesteryear that made >us work a little harder and encouraged us to understand the inner >workings of the machines instead of trusting a compiler and figuring >the damned thing is so fast that no-one will know the difference >between good programming and a heaping mess. Have you actually tried writing any desktop-based applications for the IIgs? I understand the inner workings of my machine very well, largely because I *have* to dig into it to figure out why my programs aren't working right--whether because of a toolbox bug, my misinterpreting the documentation, or simply incorrect documentation. After I've looked at enough code generated by a particular compiler, THEN I trust it. When appropriate, I code portions of a project in assembly language. A lot of the time, the code is mostly making toolbox calls anyway, so it won't matter much whether they get called from assembler or from C or Pascal. >Capt. Albatross >jm7e+@andrew.cmu.edu --David A. Lyons a.k.a. DAL Systems PO Box 287 | North Liberty, IA 52317 BITNET: AWCTTYPA@UIAMVS CompuServe: 72177,3233 GEnie mail: D.LYONS2