Why isn't Rev more popular?

[Mark Wieder]

Bill-

Friday, December 2, 2005, 10:06:25 AM, you wrote:

> Well for reasons I may not be aware of, all the new commands seem
> to be in the format, "revDoSomething" followed by parameters.
> Example:

>     revAddXMLNode treeID, parentPath, nodeName, nodeContents

> the official example:

>     revAddXMLNode 9,"/","Balls",""

> Why couldn't you say something like

>     add node "Balls" to the root path of XML tree id 9

> I'm not saying that is the exact perfect syntax, nor is it
> "compact," but it would be super readable/self-documenting and easy
> to remember. That's what I love about the language, and this is what
> I mean about advancing TransScript.

Thanks. That does help sort things out. And I think this is a useful
discussion, and one that comes up every so often. The revdb_xxx
functions are equally ugly. My impression is that the "rev" prefix is
a way to handle namespaces in an xtalk way; i.e., without instituting
a dot mechanism: rev.xml.addNode paramList, which does indeed veer way
too much into javaLand.

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.

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.

> [Oh yeah, reason #15: Inability to copy and paste from the documentation stack! :)]

Ouch!

#16
Lack of built-in hooks to standard version control packages

#17
Lack of a solid debugger

#18
None of the available QA automation tools work with runrev

#19
Lack of a generic way to utilize external libraries (ActiveX, etc)

#20
Lack of an import mechanism limits multi-programmer projects

-- 
-Mark Wieder
 mwieder at ahsoftware.net