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
Well said, John. I am actually in both shoes. I produce standalones
that do not need the dynamic scripting or function fine with the
current limits, but I would love to use MC/Rev for dynamic scripting
as well. Except that 10-line limit is too restrictive for me.
I tried to get over it in the past, but the solution offered by MC
was too expensive and Rev never followed with my inquiry. Kevin's
tinkering with the script limits now just set me off to not only stop
it but rather go the other way and create means to increase those
limits when needed.
I am afraid, though, that such uses continue to be too small market
for Rev to worry about.
Robert
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard
