[Edu-sig] re: modelling

[Kirby Urner]

> Put another way, if that is the approach one thinks is appropriate, 
> than go VB

Not sure I agree with your tendency to equate this style of programming
with VB (which I've never used -- except in its VBA form within Office 
products, e.g. inside of Access).  

Using screen painter tools to design a front end is an old idea that 
didn't start with Microsoft, nor is this approach limited to VB.  All 
the so-called Visual products (Visual C++, Visual FoxPro, and yes, the 
emerging Visual Python) are characterized by the floating toolbar 
palette of surfaces and controls.  But then, so are the Java IDEs from 
Borland and Sun.  I have nothing against these for what they are.  
They can save a lot of time.

I also think we need to get away from the "high level versus low level" 
to some degree.  Projecting images to a monitor and polling for keyboard
and mouse events is low-level interfacing to the human through the human's
API.  We're working to bridge the cell-silicon circuitries with interfaces
of sufficient bandwidth to keep both operating with some efficiency.  The
biological is "low level" too, just that it's not a product of conscious
engineering and we're not sure how it works exactly.  But we still need 
to interface with it.

I don't regard using eyeball ports, which are optic-nerve endings of the
brain, as ipso facto "higher level" than talking to a chip through its 
various pins.  We're dealing with a primitive biological interface devices,
highly suited to their functions (devices I don't see a real need to 
bypass, unless they're broken i.e. a lot of this fantasizing about 
hard-wiring components directly to the brain, Borg-style, seems a 
misguided effort to bypass what billions of years of refinement already 
give us "for free" -- like trying to drill holes in a Pentium chip in order
to bypass its pins (why??)).  

So when it comes to a highly graphical GUI, that's just a way of encoding 
frequencies in ways our brains have evolved to interpret, over the aeons.
Electromagnetic radiation in a narrow band of the spectrum (visible light) 
is patterned with information that changes at human-sensible rates (vs. 
supra or infra-tunable speeds e.g. propellor blades when spinning at high 
speed, or glacial movements, are not directly perceivable, because too 
fast or too slow respectively -- GUI events need fit between these extremes, 
although sometimes a Windows progress bar will approach the glacial limit).

What we need to be clear about are "walks of life".  Some people have
no slack for learning the intricacies of something that others groove 
on full time.  We are all "disabled" in one way or another, in the 
sense that we lack capabilities, skills, capacities, which others have
perfected and take for granted.  In a lot of ways, this is exactly what 
interfaces are all about:  making allowances for users who do NOT have 
the time and/or inclination and/or need and/or ability (for whatever 
reason) to penetrate the layers by other means and appreciate what's 
inside the black box.

I think it's this concealment and encapsulation of functionality that 
you are tempermentally disposed to challenge, and I think that's healthy.
People have this natural curiousity to know "how things work" and like
to consult those picture books, exploded diagrams, blueprints, cutaways,
showing the innards, the guts, the "what makes it tick" mechanisms. 
Python is a great language for exposing a layer of mechanism handled 
by higher level programming languages.  Even if you never learn C/C++
or LISP or Assembler (or MMIX), you get a strong dose of what a programming 
language is all about, how it feels to use one, how it mediates between 
a GUI front end, and internalized logic or routines.  This is fun to 
find out about, and should be part of the generic K-12 curriculum IMO.

You pick up on the idea of an event loop, that's always listening, 
polling, waiting for changes, and triggered events, which lead to chains 
of programmed responses, perhaps along various threads each with a 
namespace, relative priority, and memory allocation.  And you learn 
what people are talking about when they speak of class hierarchies, 
polymorphism and instantiated objects. This is all good general 
knowledge to have, even if your walk of life is not programming, not 
computer science.  Because of your exposure to Python "cave paintings" 
which sketch the gist of a web server, or whatever it is, you have a 
feel for the role software plays in the world, even if you don't spend 
a lot of time writing it yourself.  You've aquired a kind of generic 
numeracy a.k.a. literacy that'll help you read and understand technical 
literatures of various kinds.  That's a worthy goal, in and of itself, 
and is what I aim for in my 'Numeracy + Computer Literacy' materials.

What I want to see develop from familiarity with Python, is a common 
short-hand for exploring various objects.  For example, now that this 
8th grader knows some Python, and now that we're studying physics, we 
might write something like:

     class Atom:

         def __init__(self,protons,neutrons,electrons):
              self.protons = protons
              self.neutrons = neutrons
              self.fillorbitals(electrons)
         
         def valence(self):
              ...
              return ion_number

Then you'd have carbon, hydrogen and oxygen objects that instantiated
this template.  Compounds could be defined as assemblies of such.

Knowing Python already, kids would see this as a way of capturing some 
of the essential qualities of an atom.  Furthermore, electrons might 
be a list rather than a number, consisting of Electron objects (same 
with neutrons and protons), such that we have class composition going 
on, with objects inside other objects (not in a class hierarchy sense, 
but in an agglomerative/associational sense).

And in a class hierarchy sense, what are Electrons a subclass of?
We could have Fermion and Boson classes, from which our various 
subclasses with descend, their inherent differences manifest at this 
parent class level).

To me, this is more generic OO thinking, taking objects in the real 
world and expressing their common traits and behaviors in the form of
a class template, then maybe subclassing to hardwire various attributes.

This kind of thinking about classes and objects should encompass the 
GUI widgets as a special case.  Screen controls may be treated as a 
elements in a class hierarchy (or instantiations thereof), no question
about it, but that's not where to *start* with the idea of objects.  
That's just one more example to consider.

To me, the idea of "modeling" really gets interesting to the extent
we free ourselves from just thinking about GUIs in the narrow sense.

Kirby