license issues (was mystery exception)

[Robert Brenstein]

>
>If all you wanted to do was give away a 12-year effort in crafting a highly
>optimized scripting engine by just slapping a five-minute UI on it, you'd
>have to work a litte harder than that.
>
>Moreover, as a scripting product it would face the same challenges in
>documentation, training, and support as Transcript itself.
>
>Given the relatively few people who enjoy scripting in any given gene pool,
>such a product might not do as well as one that offers equivalent
>functionality through point-and-click.
>
>For the very small set of tasks that truly require "do", taking a moment to
>break them into 10-line chunks would suffice for many of them; more complex
>needs will require more effort, but they should anyway:  Trancript is a
>great general-purpose language, but is it optimal for statistical modelling?
>Could there be another language design that is more effective for that task
>than Transcript?  And could it compete with Mathematica?
>
>You'd probably want simpler variable assignments than "put", and tons of
>custom functions, in addition to ways to load and parse the input data, etc.
>
>If they truly need wide open general scripting, the various pricing options
>for Rev make such power affordable.
>
>But you can't expect to pay once and then turn around and deliver Transcript
>as a whole to your end users.  Think of how easy it would be to make an
>alternative authoring tool without such limits.  I've seen this happen with
>another xTalk, and it became a direct competitor that took a good many sales
>away from the tool that made it possible.
>
>Admittedly I'm having a tough time thinking of a commercially viable
>opportunity for an app that truly needs dynamic scripting and doesn't
>compete with Rev....
>
>--
>  Richard Gaskin
>  Fourth World Media Corporation
>  Developer of WebMerge 2.2: Publish any database on any site

Mathematica is no competition. Yes, users would not use put directly 
but my parser would convert their code into proper Transcript.

No, I do not want open general scripting and I don't see how one can 
easily make an alternative authoring tool. If a do is executed within 
a context of my handler, not everything will run. In this specific 
project I would parse user input anyway to make sure it meets my 
requirements, so I could check for any illegal calls, but I'd want to 
use do for efficiency of execution (data is read separately so it is 
not a concern here).

In my view, I'd not be opening full Transcript to end users. I agree, 
though, that a malicious programmer could release such a 
general-purpose tool. However, if a license key was required and 
embedded, then this would be traceable and prosecutable.

Robert