amanda@lts.UUCP (Amanda Walker) (12/29/88)
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.mce@tc.fluke.COM (Brian McElhinney) (01/04/89)
In article <749@lts.UUCP> amanda@lts.UUCP (Amanda Walker) writes: > 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. Well said, but, hey, that's not why I complain about MacOS. I imagine in my fevered vision that I am not alone. I want the Macintosh operating system to be as advanced as the user interface, or at least a closer match. Instead we have an OS *designed* to run in < 128K RAM and on a single floppy disk, and then horn shoed, stretched, and prodded for four years. It is a testimony to the talent of Apple's employees that the present incarnation works as well as it does. But is it any wonder people complain? Brian McElhinney mce@tc.fluke.com
clive@drutx.ATT.COM (Clive Steward) (01/05/89)
From article <6475@fluke.COM>, by mce@tc.fluke.COM (Brian McElhinney): (replying to Amanda Walker's well-spoken expression) > I want the Macintosh operating system to be as advanced as the user > interface, or at least a closer match. > It is a testimony to the talent of Apple's employees that the present > incarnation works as well as it does. But is it any wonder people complain? Brian, I have a task for you. I really do 'wonder that people complain'. Can you come up with something important to do, which the present Mac operating system _won't_ let you do? You can pass on IPC and its opened possibilities, since that's apparently in the works. We've disposed of the hobgoblins which haunt people who worry about what it might not do; such as allow background tasks time during dialogs, etc.. It does these things fine. I think the same is true of 'I want my Unix command line interface, pipes, and utilities'. With MPW, and especially the latest 3.0, it's quite apparent that the Mac OS easily supports an at first similar appearing, but very much superior interface: 'live scripts', with ever so many features you'd really miss doing without. Listening, it must be clear that people in the 'straight Unix' community, especially new engineers and school people, have a constant murmur going with just about as much unpleasant to say about Unix itself: the most especially preferred of all, 'not a real modern OS'. Yes, there will be better things, for Mac and other machines. Probably as with the living world in our better dreams, they will become expressions of plurality of cultural context, rather than singular 'better answers'. That world might just be beginning to grow up, into the next phase at least. Will computer programmers grow with it? Clive Steward
mce@tc.fluke.COM (Brian McElhinney) (01/11/89)
In article <9831@drutx.ATT.COM> clive@drutx.ATT.COM (Clive Steward) writes: > >Can you come up with something important to do, which the present Mac >operating system _won't_ let you do? Sigh. The question is not what is *possible* or not. We're talking software. Almost anything is possible for a given architecture. That doesn't mean it is reasonable. Try doing ray tracing, or 3D hidden-surface removal, or a CAD/CAM all in little bitty pieces and contexts. Possible, yes. Now how long will it take to write? How robust will it be? How responsive? Now ask the same questions for an implementation using process threads and semaphores. There is no doubt that the present "event driven" Multifinder environment is very useful, and works for a very large class of problems. You will no doubt have also noted that applications are getting larger. And more complicated. And slower. And take longer to write and have more bugs. It's a problem of the additional complexity required, in both the application and in it's implementation for the Mac OS (which has bent over backwards to maintain backward compatibility; a wonderful thing, but it has it's price). >We've disposed of the hobgoblins which haunt people who worry about what it >might not do; such as allow background tasks time during dialogs, etc.. It >does these things fine. Your definition of a task is has some dismaying assumptions. >I think the same is true of 'I want my Unix command line interface, pipes, >and utilities'. With MPW, and especially the latest 3.0, it's quite apparent >that the Mac OS easily supports an at first similar appearing, but very much >superior interface: 'live scripts', with ever so many features you'd >really miss doing without. Not much different than GNU Emacs under UNIX. Not as good in some respects. Emacs lets me bind any event sequence to customized actions, and is programmed in Common Lisp (not Yet Another Shell Script). And knowns to abort window refreshes if a new update event comes along, and has filename completion, and more. MPW has it strengths as well; my point is that, having experience with both, I feel it is not superior. >Listening, it must be clear that people in the 'straight Unix' community, >especially new engineers and school people, have a constant murmur going with >just about as much unpleasant to say about Unix itself: the most especially >preferred of all, 'not a real modern OS'. Who ever said UNIX was 'a real modern OS' was probably in marketing. It has it's advantages; ever use a SUN for software development? Overall, it beats VMS and DOS and MacOS (MPW or LSC) by a mile. MACH appears to be a big step in the 'modern' direction. So does a rewrite of the MacOS. I look forward to both. >That world might just be beginning to grow up, into the next phase at >least. Will computer programmers grow with it? Yes, if they are willing to look outside their narrow environment and see that the tools they are *used to* may solve their problem, but at a cost. Brian McElhinney mce@tc.fluke.com