"I often quote what George Vallasi used to say (George: do you lurk here?)
`XyWrite isn't a word processor. It's a kit from which one can assemble a
word processor.' Truer words were never expressed. [ ... ]
"Annie, I don't think there's any such thing as a typical XyWrite user."
--Leslie Bialler
"Truer words were never written." --K.
I agree in both instances. Wow! Who is this George dude? That's an epigram of
Robert Holmgren's:
"I think XPL is peculiarly suited to manipulating an editor with XyWrite's
design of sub-atomic particles (read: functions) that perform tiny discreet
tasks; of directly handling EDITOR's command set; of manipulating text. XPL
works! It reflects precisely the construction of XyWrite deep down inside.
(It's a beautiful concept, if you think about it.) The _task_ is to educate
users in the logic of this structure--nobody ever even talks about it as an
array of minute building-block resources that can be freely arranged to
perform nearly any task --TTG needs PR with brains!--and to demonstrate XPL's
unique suitability to manipulate these assets. I.e., to build on and develop
your strengths, not start all over. XPL and XyWrite are really hand and
glove, organically related; so why waste energy trying to reinvent in the
high level language all the capabilities that already exist in, and are more
suitably implemented in, XPL? Enough parallel tracking already! Improve XPL
instead."
XyWrite's construction deep down inside is something I'd only inferred before
reading that. As high level languages go, xpl's problem is that it's
unstructured. Even GW-BASIC can be structured de facto (I did so
instinctively before I learned C); not so, xpl. I suppose SU is intended for
the purpose and v4 memory manipulation must ease the situation, but SUs are
weak and I'm conditioned by v3 to go to extremes to avoid sacrificing memory
to variables that aren't absolutely required. The high level language I know
best, C, has a goto statement that programmers learn early *never* to use.
It's only to break out of a situation so uncommon as to be nigh unthinkable.
Structuring eliminates the need, and xpl is immensely untidy because GL ...
LBs are so vital. But, like xpl, C is very compact--enhanced by libraries of
functions, and I guess the same is true of xpl as regards both EDITOR and
user-definable functions. Being able to manipulate xyWrite with C is an
exciting fantasy, but Robert makes a powerful argument for beefing up xpl
instead of turning to an alternative. Flow control would surely be the place
to start, so structure can be imposed.
"... that insulting XyQuest xpl pamphlet." --me
"Which pamphlet do you mean, Annie?" --Leslie
I think you've mentioned it--actually a booklet. When it was published I was
still a xyPirate, and compounding the felony I photocopied it, but never used
it. With Sladek (the rough equivalent of early v3 documentation) plus
experimentation, I was already ahead of it. I'd worked out on my own stuff
like the
{sv86,foo bar}{sx86,{is00}e{is86}}
counterpart to C strchr (my proudest xpl moment--*before* I learned C). The
only place I ever read that and a bunch of stuff I never *ever* could have
worked out on my own was "XyWrite Revealed"--none of it in the XyQuest
booklet.
"XyQuest was as delinquent with configuration info as TTG." --me
"At least they tried, with the app notes, etc. etc." --Leslie
Pirates do pay. I never saw them. And now ...? Guess we really can thank IBM
and XyQuest marketing jointly for the present dearth.
"If this was the recording industry, the reporters would be the musicians and
the editors the sound engineers."
My experience is that the people behind the scenes in that business are as
creative as and more interesting than the musicians. On the business side
especially, rogues and scoundrels who'd defy fictionalization, great fun to
watch in action. --annie
========================== annie fisher <okAnnie@aol.com> nyc