Two questions about trev

Richard Gaskin ambassador at fourthworld.com
Tue Sep 15 11:24:45 EDT 2009


Jerry J wrote:

> On Sep 14, 2009, at 8:43 AM, Richard Gaskin wrote:
> 
>> In fact, once could argue it encourages complexity by making it easy  
>> to ignore it.
> 
> Wow, another deep-thought quotable from Richard. There sure are two  
> edges to this sword - after all one could argue that much of computer  
> programming is, at its root, hiding complexity. Good or bad?

Thanks for the kind words.

<possibleWasteOfBandwidthOnPhilosophicalRamblings>

Rather than "good or bad?" we might change the question to ask "useful 
or less useful?", and by that measure the answer may differ whether 
we're talking about the end-user of the system or the person responsible 
for delivering it.

Since the whole computing thing is just smoke and mirrors anyway (who 
bothers to notice that it's just a machine too dumb to count past 1?), 
for the end-user it may be very useful to hide complexity whenever 
practical.  The whole experience is just an illusion, so better to make 
it a pleasant one. :)

But the developer is responsible for providing that illusion of 
simplicity, and therefore is not often in a position to indulge in that 
illusion himself.  The magician has to know that the ball isn't really 
under any of the cups but merely palmed out of view, but it's more fun 
if the user doesn't know that.

True, to a large degree Rev is a sort of "pleasant illusion" itself, 
sheltering us from the ones and zeros marching through the processor so 
we can focus on the user experience unencumbered by counting bits.  As 
helpful as it's been to have worked in C and other lower-level languages 
to be able to imagine what the engine is going though under the hood, 
I'm grateful I can afford to forget such things most of the time.

Since we're waxing philosophical, here's a quote I've found valuable:

I interviewed Bill Appleton for a computer mag shortly after SuperCard 
1.0 came out in '89, and he said something that's stayed with me all 
these years later:  "A lot of really smart people do great work with all 
sorts of applications.  Then there are the people who who make those 
apps, relying on an engine like SuperCard to run them.  And then there's 
folks like me who make an interpreter like SuperCard using Think C.  And 
the folks who wrote the Think C compiler work at an even lower level, 
and going even lower are the people who wrote the chip instruction set. 
  There's plenty of room for excellence at all of these levels, and I've 
seen some amazing work across all of them."

That may be relevant here in discovering the dividing lines that can be 
useful for work at a given level.

No matter what else we may do in Rev, from writing externals in a 
lower-level language or using tools to provide a higher level of work, 
it's all driven by the engine.  Since the engine understands scripts 
only as a block of code, I find it helpful to think like the engine 
whenever I can.

I don't bother thinking like the compiler or the processor often, though 
sometimes it's helpful when optimizing. And I try to step back now and 
then to think like the end user when I can, but the magician can never 
really enjoy the appearance of an illusion he knows the secret to, at 
least not the way the end-user does (which is why usability testing is 
so important, but that's another story).

So when coding in Rev, I tend to favor things like having the IDE use 
property names rather than Rev's default setting of more descriptive 
terms (the first thing I have students do when I'm teaching is change 
that Preferences item), and seeing the whole script rather than a 
handler view (seems Rev 3.0 removed the handler view anyway, no?).  And 
I feel the same about parts of handlers too - might as well see the 
whole thing, just like the engine does.

Like my t-shirt says:

Know the engine.
Trust the engine.
Use the engine.

</possibleWasteOfBandwidthOnPhilosophicalRamblings>

All that said, I think it really boils down to just a matter of taste. :)

--
  Richard Gaskin
  Fourth World
  Revolution training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com



More information about the use-livecode mailing list