Script Limits vs dynamic programming

[Dr. John R. Vokey]

On Thursday, August 7, 2003 Jeanne A. E. DeVoto wrote:

> I don't understand what you mean by this. Your extensible stacks are 
> your
> products. ("Product" does not mean "commercial product", nor is it
> restricted to standalone applications.) It sounds from your description
> like your products would in fact impact the products you make, so my
> suggestion of discussing this with Kevin is still my advice.
>

This is missing the point.  The principle advantage of metacard/RR is 
that it provides for dynamic programming *and* it does so in a 
cross-platform way.  I have and use c, c++ compilers, Futurebasic, 
RealBasic, and so on, but for different purposes.  None of these other 
programming environments is *dynamic*.  Scott Raney's important 
statement that metacard is written in metacard was not to make the 
point that, as with c or Basic or Fortran compilers one could write a 
c, or Basic or Fortran compiler with it, but rather that the system is 
bootstrapped. The possibility of producing ``standalones'' in hypercard 
and metacard  has unfortunately helped disguise this fact to the point 
where many (Shari C is a fine example, here, and more power to her) 
think of metacard/RR as just another IDE with fine cross-platform 
capabilities.  That it no doubt is, but that's not what makes it either 
unique or important: it is the possibility for dynamic programming that 
the engine provides, as with hypercard.  Limiting script length and 
``do'' to non-licensed RR users means that *only* licensed RR users of 
the stacks I produce can can partake of the dynamic nature.  Thus, 
rather being an essential part of metacard/RR, this dynamism becomes a 
feature *only* licensed users (developers?) can use, but can't retain 
in the stacks they produce.  By all means, strip it out of standalones 
if need be, but leave it as an essential feature of stacks.

For those who remember them, think of the completely different 
experience one has programming in and using TILs (threaded 
interpretative languages) such as APL, and forth: as with hypercard, 
programming is not distinct from using; they are seamlessly integrated. 
  *That* is what we will be losing by these limits.  For those who use 
metacard/RR to produce applications without those dynamic capabilities, 
I can understand why they don't feel these limits amount to much.  But 
for some, at least me, it is the dynamism that is my whole reason for 
using metacard, recommending it to students, and so on.

John R. Vokey