Re: `power' v wp xyW (long!)

[OkAnnie@xxxxxxxx]

Leslie: Thanks for getting beyond the lead.

"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. --anni
e

========================== annie fisher  nyc