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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
