Why isn't Rev more popular?

[Bill Marriott]

"Mark Wieder" <mwieder at ahsoftware.net> wrote in 
message news:4910717941.20051202111611 at ahsoftware.net...
> Note that the "add" keyword already has a specific meaning as an
> arithmetic operator, so it wouldn't be the best choice here. And not
> that the (admittedly imperfect) syntax you suggested requires not just
> a change to the "add" keyword parsing, but also the addition of a
> "node" keyword, the ability to parse the words "root path" into a
> meaningful property, and the need to parse "XML tree" into an object
> whose "root path" can be set.

Well that is just exactly it. It would be a lot more work to figure out how 
to express these commands in "plain English" and to expand the meaning of 
existing keywords, if any. But to me that is THE reason to use xTalk as 
opposed to another language. You obviously can't "extend" Transcript in any 
meaningful way without doing the kind of work you outline.

> I'm wary of adding keywords to the language unless there isn't any
> workaround with functions, in spite of the funny-looking syntax.
> Everything added to the core functionality is more baggage the engine
> has to drag around, adding bloat to standalones and slowing down
> script parsing. The xml routines are handled in a separate library
> which can be added explicitly to standalones when needed but doesn't
> take up unneeded extra space when it isn't.

If you read what you just wrote, then there will never be justification for 
extending TranScript, because certainly there is nothing that cannot be 
described as a function.

revReRead(quotedMaterial, twice)
revAnswer("Bill","hogwash",1,"\")

But functions are the antithesis of self-documenting, human-readble code.

Are we then doomed to a future in which the plain language simply fades 
away, as it has in Director and so many other implementations?

Without being too glib, what's another 10K or 100K or 700K in a 
distribution, in the days of CD-ROM and DVD-ROM ubiquity, 8Mbit cable 
modems, and highly efficient compression? I suggest it's negligible given 
the fact you already have a significant minimum file size. (Now if it was 
the difference between a 10K distro and a 5 MB distro that would be another 
thing, but you're talking about basically any RunRev .exe weighing in at 
1.5MB+. How much do you save in % by keeping the XML library out?)

I just don't think a lot of us, myself included, would care a bit about 
HyperCard or Revolution if it didn't feature this beautiful characteristic 
of plain language. The verbosity, "bloat" and performance criticisms have 
always been part-and-parcel of "real programmers" dislike of this platform.

I say xTalk will never be as compact and efficient as C++, and SHOULD never 
be so. You'll never win over a C++ programmer, for one. They will always be 
able to write code with fewer keystrokes and processor overhead. And you end 
up alienating the users who love xTalk for its simplicity and flexibility.

If XML were around when HyperCard was first released, you can bet that we 
wouldn't have kludgy add-on functions like this to work with those 
structures.

This is what I mean by the abandonment of true/pure xTalk contributing to 
the lack of popularity of Revolution. It's the same reason why people barfed 
at the first implementations of color in HyperCard way back when. The 
add-ons didn't have the "religion" of xTalk. They were bolted on, not 
integrated.

I don't know who really "owns" xTalk or TranScript or whatever it is called, 
but in my opinion RunRev is the custodian of it now, and it would be far 
more appealing if serious effort went in to extending the language to 
comprehend, in an integrated way, most if not all of the functionality 
currently embodied in the "revDoThis x,y,z" family of commands. If they fail 
to do this, I believe eventually we'll all switch to the meta-library of 
functions that everyone else uses (i.e., JavaScript).

Bill