Not forgetting, Brian, just discounting. :-D
Fair enough. For me, that was the only reason to use CompileIt. Speed
of ordinary scripts felt like something I wanted to deal with
algorithmically rather than by compiling. After all, compiling the same
algorithm was probably going to have less impact than my next processor
upgrade! I'm sure there were instances where it was useful, but for me,
it was all about writing externals without having to learn C (which
I've long since done, but alas...)
I avoided that stuff like the plague.
Guess I'm a bit of an xtalk purist (or some would say bigot).
Transcript isn't going to be THE solution/language for all problems.
Every time we try to glue something onto it to solve a problem it
wasn't intended to solve, we risk making the stuff it does do easily
and well harder.
I agree.
Transcript/Rev aren't a general-purpose environment. There's a whole
class of apps for which they are ideally suited. There are also many
for which it's not the right tool. I'm in favor of continuing to make
it do what it does do better and better.
I suspect you are, too, so I'm not being contrary here, just
clarifying.
I actually do feel the same way. For me, it's mostly a moot point. I
write externals in C when I need them, and if I need a lot of them (or
heck, more than 1 of them in a project) then I consider other tools.
I believe I'm mostly speaking for others (dangerous, I know!) who have
expressed a lot of interest in native access to OS routines. I wouldn't
mind seeing a new CompileIt!, just because it would be a cool toy and
handy for some - but I wouldn't personally rank it very high on the
cost vs. benefit scale.
I'm not sure where I would fall if I didn't write externals already,
though.
- Brian
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
