On 6/19/2011 7:20 PM, Steve Dekorte wrote:
On 2011-06-14 Tue, at 09:36 PM, Julian Leviston wrote:
The thing that irritates me about this attitude of "don't consider kids as equal" is that
we DO consider them as equal in other frames... we expect so much of them in terms of linguistic
and cognitive development... and actually the abstractions (zero-th order abstraction) capable of
and exhibited by a 5 year old are used when in the activity called "programming" all the
time... so much so we as adult programmers rarely think about them.
I agree. People seem to define "smart" as something like "things I can't do
easily". So, for example, if they can use a keyboard, well someone like a child who can't must
not be smart and this is why people were surprised when the mouse and graphical UIs allowed
toddlers to use the Mac or touch screens allowed near infants to use iPads today. All along it was
an issue of unnatural conceptual mapping (like asking a right handed person to throw with their
left hand) that was the problem, not a lack of smarts.
also, mouse or touch-screen are relatively direct-feedback, rather than
requiring high-levels of abstract thought to work with.
part of the problem may be that of preexisting knowledge...
sometimes, knowledge can help people understand things easier;
often, existing knowledge will lead to very nasty conceptual kludges.
an example of the above I think is the ever-persistent file-cabinet
metaphor:
people very often portray things like files/... by making references
back to this metaphor.
the assumption (I guess) is that people will be more familiar with
filing cabinets or find them more intuitive or similar.
but, from the POV of someone who has never really used them for their
intended purpose, or worked with piles of paper documents, the analogy
doesn't really seem to work, as filing cabinets and filing systems
really seem very much like unrelated concepts...
at best, the terminology has been overloaded, and the new concept of
file (a hierarchical tree of directories containing files each
containing some number of bytes) has almost entirely subsumed the
file-cabinet concept on which the original metaphor was based.
in a sense, the metaphor no longer works, and should likely itself be
left to fall into the recycle-bin of history. worse yet is having to
read stuff written by people who actually take this metaphor seriously.
granted, there are other annoying metaphors, but most others are not
used nearly so offensively...
a young child though will probably see things more how they are, and not
likely build their thinking around metaphors which are borderline absurd:
that a computer is a filing cabinet in an office residing on the surface
of a giant desk for which a man in a robe will pop out just as soon as
one pokes at it... (and where one is honestly expected to take advice
from an anthropomorphic paper-clip...).
yet, at the same time, it seems far more the case that society in
general disregards people, and tries to force them into their particular
mindset and worldview. one is not then really allowed to see the world
as it is, but expected to deal with it in terms of layers of
intellectual and ideological cruft.
granted, maybe not everyone will come into the same "reality", but maybe
this is ok as well. it is a curious observation that so many people,
living in essentially the same world and often from the same culture and
geographic area, will come to have a number of different worldviews.
(but, going more into this topic goes into some rather awkward issues...).
From this perspective we could see the history of programming as one of
finding ever more natural mappings between how our minds work and how we can
get machines to do what we want - just as steering wheel and floor pedals map
between our bodies and our vehicles. If so, which mappings are more natural and
under which circumstances seems to be the important question and one, AFAICS,
that may not well answered by simply replacing words with ideograms and
expressions with boxes and arrows.
agreed... I really don't believe graphical solutions are necessarily ideal.
but, at the same time, there is also the matter of finding "the right
tool for the job".
for example, code works great for expression program logic, but falls
flat for many other tasks:
creating a graphical image;
creating a 3D model or scene;
...
in these cases, having more specialized tools tends to be far more
effective.
for example, for editing a photo, one summons up a tool like GIMP.
and, for making a 3D model, or working on its animations, one will
generally summon up a dedicated 3D tool.
picking the right sort of tool can notably reduce the effort required to
complete a given task.
in the above cases, a graphical tool is generally the best solution, but
graphics are not best for all tasks either.
a partial issue may then be battling a more subtle problem:
it is very common for most tools to essentially become very large
monolith-like systems, which ultimately detracts from the task at hand.
for example, many commercial DCC tools will try to control *everything*,
but this is ultimately not-very-useful (as is shoving everything in a
scene into a single big file, ...).
my personal beliefs have generally been that it is much better to try to
allow heterogeneity wherever practical, and to try to make smaller and
more streamlined tools for specific tasks (even if most of the backend
code is shared).
maybe the cost of "mode switching" is a little higher if different tasks
are done with different tools, but allowing ones' systems and data
representations to be more open is IMO a worthwhile trade-off...
granted, how to make "ideal" (as in generally usable) DCC tools is
itself a bit of an issue.
the great problem is that most such tools tend to be rather complex and
difficult to use, and trying to do so oneself one can run into a problem
of "keyboard cruft" whereby there are no good ways to map new sets of
actions to the keyboard and/or mouse without interfering with
pre-existing actions.
and, then after a while, one finds themselves looking at a 5,000 line
glob of code mostly just dealing with the task of mapping keyboard and
mouse actions to camera-related controls, and dealing with a lot of
"hair" related to different actions having different results in
different settings.
for things like 3D modeling/animation/mapping tools, probably the
user-interface is one of the bigger and nastier issues in the whole thing.
which is probably why, thus far, there are no such tools which really
give one a sense of "wow, this user interface is a joy to use" but more
like "well, at least it is not as nasty as that one over there...".
despite this, they are still generally the best tools for the jobs.
in a similar way, programming languages are generally at least
adequately effective in doing what they do, and ideally, one can use
different languages for what each does well.
although common, I think it a bad thing if a VM tries to lock the
developer into only developing in the VMs native HLL. a heterogeneous
world is better IMO...
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
