[From Bill Powers (2000.04.11.1148 MDT)]
Richard Kennaway (2000.04.11.1722 BST)--
I could ramble at length about these issues, but PCT relevance would get
rather thin.
I agree.
I don't think the unavailability of such a system is due to "Massive and
sustained coercion" (going back to the original context).
That's probably an overdramatization, but at least it's due to the conduct
of business as usual. Look how the whole 80X86 computer design got started,
with IBM refusing to believe that anyone would ever need more than 64K for
an array, and 640K altogether. So we get this horrible segmented memory
addressing. The Z80, a much nicer design to my mind, was simply shoved
aside, and the 68xxx (a copy of the PDP11) was relegated to Apple and
Amiga, which precluded any (easy) programming that was not integrated into
the multitasking OS.
Without GUIs,
there's no market for computers among the general population. It's only
programmers who have ever been happy to sit down to a blank screen with a
C:> prompt at the bottom and type magic spells at it, and all the tricks
Microsoft cares to pull aren't going to change that.
Right, but look at the Turbo C or Turbo Pascal Integrated Development
Environment (copied in DJGPP). The screen is laid out just like a GUI,
except it's all in text mode, at least twenty times faster. The fatal
decisions here were made by Apple a long time ago. I remember the extinct
Hercules video cards, which at about that time were starting to include
stored fonts which could be changed on the fly at the speed of text mode.
It would have been easy, then, to start including windowing capability on
such cards, including the ability to switch to graphics mode inside a
window while leaving the screen as a whole in text mode -- in fact, there
was really no need to distinguish between text and graphics mode. It's just
that Woz (and others) thought of things that way, and decided to make the
CPU write pixels one at a time. Then, when the look and feel of Apple
(Xerox) was adopted for PCs, the Gooey became inevitable.
Unfortunately, once a design has been translated into volume production,
any basic changes become impossible. There's both a hardware and a software
"legacy" committment. The best example of this is Digital Equipment
Corporation. In 1990, the PDP11's at the Chicago Sun-Times were still
running the same operating system, with programming being done in the same
macro assembler language, as in 1970. Or maybe IBM is an even better
example: COBOL programmers are still needed, and that goes back at least 40
years; FORTRAN programming is still used by engineering departments, and
that goes back 50 years (it's the second language I learned in the 1950s,
after SOAP).
How many lines of code does it take under MacOS to run the C "hello, world"
program?
If you run it inside a command-line shell such as MPW, the same as the Unix
or DOS version, just a few lines. If you write it as a stand-alone
application, then it gets a lot bigger, maybe 100 lines for a minimal
application, or 1000 for one that supports the entire Mac interface
according to Apple's guidelines.
Yeah, that's what has kept me away from Apple (and Windows) programming.
But I didn't know about MPW then, or more probably it didn't exist.
I guess it's the same under Windows. Linux probably wouldn't have the same
bloat, because its GUI and related facilities seem to be less developed.
Yes, running under Linux would be more like using DOS, since the use of
multitasking isn't mandatory as I understand it. My programs tend to want
to use 100% of the CPU time, and since the PCT stuff involves accurate
timing of simulation frame rates, cycle-stealing by the OS or other
programs is really a no-no. I know that in some of Rick's programs, the
speed of the simulation cycles depended on whether and by how much you
moved the mouse.
It's hard to imagine what the computer world would be like if so much of it
hadn't been set in stone so early. And what would have happened if analog
computing had been given the same development effort?
That's more than enough on _that_.
Best,
Bill P.