jxf@orion.cis.ksu.edu (Jerry Frain) (01/22/91)
cox@stpstn.UUCP (Brad Cox) writes: >wwtaroli@rodan.acs.syr.edu (Bill Taroli) writes: >>kkirksey@eng.auburn.edu (Kenneth B. Kirksey) writes: >>>Can somebody please tell me why Apple has yet to implement TRUE multitasking >>>in the system software? I know that it's really not that hard of a task, >>>especially since the amiga has had it for quite some time. Is there a valid >>>reason for not doing it? I'm really curious >>I think you've used just about one of the most vague terms in the comuting >>world. No. "Multitasking" is not a vague term. It is a misused term. >The software swamp is full of such vague terms. Not vague terms. Misused terms. "Software swamp," now there's a vague term. >IMHO, this stems from a >semi-religious belief, or dogma, that there is a single, best meaning >for any term; i.e. a panacea meaning that applies to everything, at every >level of granularity. On the other hand, Mr. Cox seems to support a "one-term-for-all-things- even-remotely-related-and-unrelated" system for communication. >Mature domains, like hardware engineering, don't get into these hassles, >which in my opinion, is only a sign of software's immaturity. A gross generalization. >Just as hardware engineers package some stuff as office equipment >(rack-level integration), other stuff as cards (card-level integration), >other stuff as chips, and others as silicon blocks and gates, isn't the >same likely to work for us? Nope. Hardware engineering (much less "packaging") is not even vaguely similar to programming paradigms, OS characteristics, etc. >My Nov90 IEEE software article, Planning the Software Industrial Revolution, >proposes that we bypass this immature confusion by adopting the hardware >engineering vocabulary, and particularly its impatience with those who >seek single, 'true', panacea solutions: > Rack-level integration: as in Unix heavyweight processes; preemptive > Card-level integration: lightweight coroutines; non-preemptive A system of "heavyweight" processes does not imply a preemptive scheduling mechanism which manages these processes. Nor does a system of "lightweight" processes imply a non-preemptive scheduling mechanism. On the other hand, we currently have the terminology preemptive scheduling non-preemptive scheduling lightweight process heavyweight process If these terms are used appropriately, then they are very sufficient. > Chip-level integration: loosely coupled objects as in Smalltalk/Objective-C > Block-level integration: tightly-coupled objects packaged as subroutines > Chip-level integration: tightly-coupled objects; expressions, variables, etc "Chip-level integration" defines object-oriented and objective paradigms, as well as language expressions and variables? This is inappropriate, at best. BTW, the "objective" and "object-oriented" paradigms are different, and should be treated as such. Used here, term "block-level integration" simply redefines "procedural programming." This is unnecessary. All of the terms which Mr. Cox has defined have one thing in common, "integration." The (proposed) definitions of these terms have almost, but not quite, absolutely nothing at all to do with the term "integration." Thanks, but no thanks, Brad. I think we're better off just the way we are. --Jerry -- Jerry Frain -- Systems Programmer Kansas State University Department of Computing & Info Sciences Internet : jxf@cis.ksu.edu Manhattan, Kansas UUCP : ...!rutgers!ksuvax1!jxf