Path: utzoo!attcan!uunet!lts!amanda From: amanda@lts.UUCP (Amanda Walker) Newsgroups: comp.sys.mac Subject: Re: programming environments (was: multitasking) Message-ID: <749@lts.UUCP> Date: 28 Dec 88 17:53:12 GMT Reply-To: amanda@lts.UUCP (Amanda Walker) Organization: InterCon Systems Corporation, Reston, VA Lines: 129 Sigh. I was hoping this thread of articles would die out, but instead it's starting to mutate :-). My article of a few days back was a response to specific complaints made about MultiFinder. Brian Gilstrap seems to have taken them as some statements about my philosphy of programming or something, and makes some points that would be quite valid under that assumption. However, I feel fairly strongly about some of these issues, having wrestled with them myself, and so I am now taking the time to discuss them more fully. This posting is going to be a little long, so I won't quote a lot of pieces of Brian's article, but it should still be understandable, even though it's not classic Usenet style... I don't mean it to be a flame, either. Before I get started, I'd like to clarify the position I have put forth in several previous articles. A certain number of people seem to have the perception that if the Mac OS would just become UNIX, that it would suddenly become simple to program, take over the market, and probably cure world hunger. They then say that it's all Apple's fault that the Mac OS is not UNIX, and that Apple better wise up and fix this glaring deficiency. We went through this with MacTCP ("but it's not like BSD sockets!"), and we've gone through it with MultiFinder several times now ("but it's not like the UNIX scheduler!"). I am of the evidently minority opinion that this is OK. The Mac OS provides an amazingly large amount of useful capability with a very small amount of memory, as does MultiFinder. The fact that a Mac Plus can run MacTCP and MultiFinder, and generally be about as useful as most workstations to a large number of people, is, I think, a tribute to how well Apple has done. But a Mac Plus is not a workstation. At best all it will ever do is to provide a set of key capabilities that will make it as useful as possible for a great number of people. I don't use one. It's simply underpowered for what I use it for. At the moment, I use a Mac II with 180MB of disk and 5MB of memory (it was 8 until my boss stole some :-)). Most of the time I'm running MultiFinder, MPW, and our TCP product. And even this, most of the time, is only barely useful enough. I'd much rather be running A/UX, or even better, what A/UX could be in a year or two :-). Anyway, I tried to make the point that the Mac OS is not like UNIX, *whether or not the "ideal" machine "should" be or not*. Read that last phrase again. It's important, and Brian seems to have missed it. >It's my responsibility to do it right? Yes. If you want to program ANY machine, it's your responsibility to do it right. On some machines, this is easier (at least in some respects) than on others. This is not a moral position, it's simply a fact about the current state of mass-market computer technology. It's no less true for MS-DOS machines or the Amiga than it is for the Mac. I'll skip talking about whether or not the Mac is viable in the business market, since I suspect we are both too biased on the subject to argue about it in public :-). It takes a while to understand the Macintosh. It takes about as long to understand MS Windows or the presentation manager. It takes about as long to understand X11 under UNIX, even with the X Toolkit or Open Look. There's just a lot of things to learn. Part of this is the fact that most software development systems are not set up to help manage the complexity, and so the programmer must do it. It's very hard to strike a balance between managing the complexity and retaining fine-grained control. I use C for most of my commercial work, because it allows good control over the end product, at the expense of having to manage the complexity of the Mac OS in my head, which, for my immediate purposes, is a viable tradeoff. There are other tradeoffs. I can run UNIX, which frees me (in a sense) from having to worry about response time, memory useage, and so forth, at the expense of additional hardware, and complexity of other sorts. The Mac OS is the base environment for a mass-market computer. As such, it is in the class of such software as MS-DOS and so forth. The fact that it provides a number of capabilities not heretofore associated with mass-market machines does not mean that it's a baby Sun/Apollo/whatever. If you need virtual memory, pre-emptive scheduling, intertask protection, and so on, which many things do, then the Mac OS is not the right environment for the job, any more than an AT running MS-DOS is. If you need these things, you can have them. A/UX gives you a nice solid UNIX port (well, as solid as UNIX usually gets, anyway :-)), and still gives you the Macintosh Toolbox. You can have the best of both worlds; it just costs money and equipment. >The Mac is not the primary source of programmatic research and innovation; the >academic and research worlds *are*. No question. Until recently, I worked there, and may well again. But that's a separate issue. Apple does very little "pure" innovation. They seem to do a good job of cleaning things up and putting them into a form that will survive in the commercial marketplace, but the Mac is not, and probably never will be, a research machine. That's not what it was designed for, and that's not why Apple sells it. You can make a reasonable research machine out of a Mac, but you have to do it from the top. Take a Mac IIx, add a large monitor, lots of memory & disk, A/UX, and a good Lisp (or other halfway-modern software development environment), and it'll do pretty well, and probably cost as much as anyhting else that's similar in capability. You get what you pay for. >Don't make *every* program worry about it. Do it once, in one place, with >one set of code, with one group maintaining it. Why on earth would you want >to *not* do this? And I'm not flaming Apple here. I would imagine they >are working on this right now. They are. In the current Mac OS, it's called MacApp. In the future, who knows? >But if your OS can't let you run a download in the background, even though >your machine has the CPU-power to do so, it's a losing proposition. But you can do this in the Mac OS. Works great. >Let's examine your metaphor. The only difference in driving a Porsche than >driving a Buick is in physical muscle exertion to use the brakes and turn >the steering wheel. Umm, when's the last time you compared the two? :-) The Mac is not perfect. It's a little closer in some areas than other machines, a little farther than others. If you want a truly modern machine, A Mac can be one of the most cost-effective ways for a normal human being to get one, but it still costs. I hope this clears things up some. I'd rather not get into a long, extended debate, unless someone wants to call for votes for talk.philosophy.programmer.... Peace, -- Amanda Walker ...!uunet!lts!amanda / lts!amanda@uunet.uu.net InterCon, 11732 Bowman Green Drive, Reston, VA 22090 -- Phone: (703) 435-8170 C combines the flexibility of assembler with the power of assembler.