For Kenny Frank re: BASIC?!

[holmgrn@xxxxxxxx]

Since years ago, many voices suggested substituting Basic for XPL
completely, or at least making XPL more like BASIC superficially
(since structurally it's already very BASIC-ish), and adding an
XPL compiler instead of interpreting code at a comparative
snail's pace (not so important anymore, post-8088 and the XPL
optimization that's gone on since Sig and the Menus). For some
reason, people have always resisted learning XPL (although it's
an amazingly easy language). The biggest obstacle to wide user-
adoption remains the naming conventions for variables (read:
"Save/Gets", or the even-more-clumsy, and positively inaccurate,
"Text Macros"): they should be English-like prose names (like
XPL's LaBels) rather than numbers or alphabetic characters -- in
other words, discursive and therefore directly identifiable,
rather than symbols that require translation. No matter how much
experience you've had, you always waste significant time trying
to remember (rediscover) what S/G 1221 is, versus S/G 1702 and
etc. One user wrote a Basic-like front-end for XPL, and called
it (I think) XyBasic; it was primitive, and barely worked, but an
understandable impulse that generated interest and support.
Minimally, one should be able to DECLARE a list of discursive
names as equivalent to specified S/G numbers at the outset of a
PM.

I think its a giant step -- a great idea -- to incorporate a
high-level language, but not one with *duplicative* functions
vis-a-vis XPL. XPL should be rationalized, made easier to use,
beefed up in power, and focused strictly on text manipulation.
The high-level language should be able to run XPL as a child
process. 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.

For the high level language, it has to significantly boost
XyWrite's power and *scope*. In my view, the biggest limitation
of XyWrite (and consequently of XPL) is that users can't get into
the guts of their machines and address the OS or the hardware,
and therefore XyWrite is (increasingly) unable to function as a
powerful shell (per the original design, DOS 2.0 era). Since OSs
and hardware are vastly more complex nowadays, your high-level
language ought to carry most or all of that weight (unburden
EDITOR a bit). (Frankly I wish XyWrite was able to read binary
files, so I could e.g. hot-patch device drivers and such, instead
of having to drag out a zapper for the job. XyWrite should have
more of the all-purpose powers commensurate with an all-purpose
tool! And you should sell it as the all-purpose tool that it is!
What is this "word processor" crap?)

So I'd make my decision based on the ability of the high level
language to manipulate non-XyWrite system assets. Frankly, I too
have forgotten Basic. (Hasn't everybody?) I've no familiarity
with the VBasic command set. But one of the many annoying
aspects of the old Basics I formerly used (written with XyWrite
and compiled under its OS shell -- like Annie says, a "smashing"
programming editor) was that manipulating the OS and hardware was
extremely laborious, and often just impossible. REXX works; it's
easy to learn, it's extremely powerful, and it looks forward
rather than back.

As for XyWin, I'm not negative. True, I don't use it much; but
that's because I can't get it to work, and because I have GPFs
everytime I do anything exotic. You really should fix it up
first, which would bring your existing base over to this
platform. Then enhance it. IMO.

P.S. This StarWriter thing is sad. My publisher in Rotterdam
has tentatively adopted it as his wp of choice. And ... he uses
OS/2, "of course" he says.