🚀 go-pugleaf

Ten Challenges:

      The Macintosh has been out long enough now that there is a large
community of people sufficiently skilled, and equipped, to program it.
There is no lack of coding talent, but it's often applied in obsolete
ways.  Each of us, after climbing the learning curve and  wanting to
display our skill, writes a little  utility. (Remember all the
screensavers, minifinders, and clocks?)  While these have added to our
capabilities, we still don't have the "shower-of-sparks" effect that
occurs when our creations resonate together, as occurred under Unix,
and Smalltalk, and certain Lisps.  If we are to uphold the revolution,
we must automate our automation.

     What is short now is not coding, but design.  "What can we do to
multiply the effects of all our efforts?"  In this spirit I offer ten
Challenges to the Macintosh software community.  Some may seem wildly
impractical (or just too hard); others too pedestrian.  Choose wisely.

Myers Challenge #1:
     A serious weakness found in every Mac editor I know of is the
search/replace function.  Search patterns on obsolete systems have
always been restricted by the typographical problem: each additional
meta-symbol made it that much harder to use and to understand.  On the
Mac we have a couple of new problems -- fonts & styles, and a distaste
for complexity -- but we have a huge advantage: we don't have to use
ASCII characters as meta-symbols!  If you think of the "search window"
as being set up like a construction kit, you're on the right track.
     But this is just the beginning: Why restrict ourselves to regular
expressions, when context-free expressions could be at our fingertips?
(Picture the day when every editor has a "railroad diagram" window)
     The person who designs such an interface will have the adulation
of thousands.

Myers Challenge #2:
     On Unix, we get tremendous mileage out of the "pipeline" concept.
Every little program is part of a (more-or-less) integrated system.
Without it, Unix would feel a lot like CP/M.  On the Mac, each
program stands alone, except for a few DA's which have to be on the
boot disk.
     What we need is support for a building-block approach that
allows dozens of little filters, on various volumes, to interact.  In
place of Unix's pipe we have the Desk Scrap.  I picture a DA, which I
call "Plumber", that (quickly) loads and runs miniprograms: they read
the Scrap, munch it, and write the result.  
     These miniprograms wouldn't have to handle events or
initialization, so they'd be much simpler than a Mac application.
Plumber would remain resident, so they'd be quick.  The most common
library code would be in Plumber itself, so they'd be small.  Plumber
would contain code to operate a dialog box that supplies option flags
& parameters to the miniprogram, if needed.  It would also "redirect"
data to and from files.  Allowing old pipelines (with their options
intact) to be left scattered about would subsitute for the "history"
mechanism found on obsolete systems.
     The person who designs and publishes a "Bus Interface" to
miniprograms will be worshipped (and $upported?) by millions.

Myers Challenge #3:
     Every RAMdisk I've seen on a Mac has been terribly primitive.
Why do they use up space not occupied by files, instead of claiming
the storage when it is needed?  Further, when a program is run off
of a RAMdisk, why is it in memory twice?  Free up the blocks it
occupied and use the core image from then on.  Allow files to be
copied into RAM when they're first opened instead of at startup.
     The person who builds a smart Ramdisk will own the business.

Myers Challenge #4:
     Not to leave the bit-bangers among us unchallenged, I propose
that a two-button mouse is possible and desirable.  The Mac has the
only one-button mouse on the market, and portability suffers.  The x/y
data would have to come in serially to free up a wire for the second
button, but many mouses on the market are programmable, so that's not
so bad.  The extra button would be be useful in existing programs,
emulating a Shift or Option key, but new programs could use it as
intended -- and it would be easier to make things run the same way on
Mac's, Atari's, and Amiga's.  If you believe in portability, you may
have found your calling.

Myers Challenge #5:
     The only Finder function I haven't seen duplicated in a desk
accessory is this: copying files.  Why has this been neglected?
Having a fast multi-file copy function as a DA would mean never having
to use the Finder at all!  The author of a successful Copy DA would be
admired by everybody but Steve Capps, and maybe him too.

Myers Challenge #6:
     Anyone who's used an Atari knows that GEM's menu-bar approach, in
which you don't have to hold the mouse button down while you make a
menu selection, is less fatiguing than Apple's.  What we need is a
replacement for the desktop code that tracks the mouse.  It would pop
up the menu without prodding from the button.  Probably most
applications wouldn't even notice the difference.  (Them that do could
have a resource pasted on which disables the feature.)
     This one sounds like a weekend's work in the right hands.  I'm
sure everyone would send scads of money to the person who pulls this
one off.

Myers Challenge #7:
     Apple's resource editor is huge, cumbersome, non-expandable,
and unreliable.  The only thing to say in its favor is that it's
indispensable.  (This is not to criticize the authors: it had to be
written before its problems could be understood.)  But it's not
irreplaceable.
     I propose a core program which itself is little more than a
resource mover.  It would load an edit module for each resource
type, as needed, from a separate file identified by the resource
name.  The interface for such modules could be very similar to
that for DA's, so existing compilers could be used to create
the edit modules.  Supporting a new resource type would require
*no* changes to the core program.  Bugs would be easily localized.
The core program would be small enough to be a DA.
     If the interface for the edit modules were published, Apple
would be rid of a big maintenance headache, and "the rest of us"
programmers wouldn't have to be so paranoid about our resource
editor wiping out our new programs.  Further, anyone could write
an editor for "his" resource type, and not have to wait for Apple
to get around to it.  Even Andy Herzfeld will thank you for
tackling this one, and Gassee will invite you to lunch.

Myers Challenge #8:
     Another thing that makes Unix powerful is that almost everything
is accessible through the file system.  On the Mac, there are all kinds
of different incompatible channels for data: serial ports, floppy
drivers, the sound driver, Quickdraw, the SCSI port, Appletalk, the
keyboard -- none of which are accessible through a common interface.
We need an equivalent of "/dev" to integrate all these channels.  In
place of driver or manager calls, I propose that we use Resources.
The file "Serial 1", for example, might have "Baud", "Flow", and
"Fram" resources to control the port.  An Appletalk virtual circuit
could be established by writing to certain resources; then data could
be sent (perhaps by another program which knows nothing of Appletalk)
just as if to a file.
     With this scheme we could eliminate the proliferation of trap
calls, and make our programs more flexible too.  This is one place
where I expect we'll need cooperation from Apple.

Myers Challenge #9:
The corporate market is starting to demand compatibility among word
processors.  Unfortunately, what they're specifying is IBM's
DisplayWriter format: an abomination.  Only a strong, flexible
standard can overcome IBM backing, but it is needed NOW!  So: Design a
document-description interchange standard powerful enough to
represent all document-processing needs for both present and future
document systems.  It need not be terribly compact; but it must be
capable of representing all constructs found in Microsoft Word, Troff,
TeX, Word Perfect, and Interleaf files.  To do this, it must of course
be an extensible, hierarchical language.  Get an ANSI or NBS
committee to rubber-stamp it, and make a fortune.

Myers Challenge #10:
Come up with a better set of challenges, and put your own name on
them.  Offer prizes, record contracts, talk-show circuits, dates with
starlets, marketing agreements, Knighthood, fame, anything you can afford.

******
I encourage collaboration on these goals, and ask for help in
cross-posting them to other networks and BBS's.  The more people who
know about them, the sooner we may hope for results.  Also, I am
willing to co-ordinate collaboration on projects and offer any
assistance I can.  I hope someone will volunteer to forward mail from
other nets to me.  I will keep all posted on any progress I hear
about.

Nathan C. Myers     uucp: {hplabs!hp-pcd|tektronix}!orstcs!nathan
780 NW 11th St.       arpa: nathan@oregon-state
Corvallis, OR 97330   belltel: (503) 753-5110
Quote: "Laugh-a while you can-a, Monkey-boy!" -- John Whorfin