compileIt for revolution?

[Brian Yennie]

> 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