ScriptLimits (was Spreadsheet)

[Richard Gaskin]

Viktoras Didziulis wrote:
 > It is likely to prevent somebody using Revolution studio to
 > create a competing RAD environment. Unfortunately this also
 > prevents from implementing any kind of scripting, or complex
 > formula translations which would not compete with the RAD
 > in any way. Therefore in order to implement end-user
 > scripting for own products (like allowing user to create
 > decision trees with formulas in nodes) some of us have to
 > resort to other languages via shell or SQL92/95 as
 > alternatives.

Those are good options, and you can design your own 4GLs and 5GLs in Rev 
too.  Rev's lighting-fast text processing makes crafting interpreters 
reasonably efficient for lightweight jobs, and you have the freedom to 
tailor the language for your application's audience.  As much as I 
personally enjoy xTalk, I wouldn't wish it on my customers.  Rev is far 
too broad and deep for an audience that just needs to automate a few tasks.


David Bovill wrote:
 > Thanks everyone - yes using Rev syntax would hit the Script
 > limits using "do" - but I think:
 >
 >   put value(field "cell 1,3" +field "cell 1,4"/field "cell 1,5") into
 >
 > Would not be subject to this

True enough: scriptLimits doesn't limit the data you can work on, only 
how many executable statements can be created on the fly.  Using "do" 
and "send" you can execute up to 10 statements at a time, which is 
usually more than most spreadsheets will need.


Roger Eller wrote:
 > Shouldn't this limitation be obsoleted? I had read once that
 > RunTime had no fear of a competing IDE, and in fact, they
 > incourage it. It was explained that a license to the engine
 > is still required, so RunTime would still benefit from sales.
 > This ancient 10 line limit is well, "limiting" us as developers.
 > Do any of Revs competing languages have such a limit imposed on
 > built standalone apps?

Not through that property specifically, but by other means. HyperCard, 
SuperCard, OMO, and Gain Momentum all required non-distributable, 
compiled elements to develop in.  Rev is the first I've seen that packs 
so much raw power into a small self-contained app.

Indeed it is the security provided by the scriptLimits which allows 
RunRev to be supportive of alternate IDEs.  Currently it is as you 
describe:  No matter what collection of stacks a user runs in Rev as the 
IDE, they still need to have a licensed Rev engine to run them.

But if the scriptLimits were bypassed then any standalone could do what 
Rev does, and any customer could buy one copy of Rev, write an IDE for 
it, and compete directly with Rev.  Talk about ROI:  RunRev puts 
hundreds of thousands of pounds in acquiring and enhancing the engine, 
and someone else takes that for the low cost of a Studio license.  With 
nothing more than $299 at stake, they could afford to sell the product 
for far less than RunRev, and could appreciably damage the viability of 
the company, and hence further enhancement of the engine myself and my 
clients depend on for our businesses.

The downsides of removing scriptLimits are clear, but what are the 
downsides of keeping it?  While there may be theoretical annoyances 
related to scriptLimits, in practice I haven't seen a case yet where it 
was an actual issue.

Most of Rev's thousands of customers never even have occasion to run 
across the scriptLimits, and many of those who do either find more 
efficient solutions than the complexity of self-modifying code or, like 
David Bovill, custom-craft their own parsers to arrive at exactly the 
syntax they want to deliver to their customers.

For the very, very small subset of those whose app truly needs to 
support Transcript scripting specifically, Kevin has made it clear time 
and again that they can contact him to arrange that.  Last time I asked 
him about this no on had taken him up on the offer.

And depending on one's business model, it may not even require such 
negotiation.  One of my apps will support its own 5GL later this year, 
and may offer direct xTalk scripting as an optional add-on pack for the 
very few customers who would want it.  In such cases we plan to just buy 
licenses for RevMedia, add our tools, and sell the package for $99.  Rev 
makes their $49, we make an additional $50 for our value-added 
components, and the customer discovers that they not only get open 
scripting but also a bunch of nifty media templates.   What's not to 
like? :)

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com