[Edu-sig] Accessibility to non CS types?

[kirby urner]

> Computer Science is a funny field, reached from both mathematics and
> engineering, so the ideas you see there can come from either of these
> sides (and cause lovely fights in faculty meetings).

Plus I'm this philo guy, stoked on Wittgenstein, coming to CS through
software engineering (Bucciarelli, MIT, is also an LW head I'm told),
and providing perhaps unwelcome (at least to established CSers) new
underpinnings, in the form of "language games".[1]

Philosophy is perennially showing up at the door with new base
classes, or more likely with claims that these classes were inherent
all along ("nothing really new since Plato"), but are now need of
maintenance (updates), perhaps an expensive overhaul.

Sophists maybe got a bad name for such door-to-door tactics, but, per
Pirsig's 'Zen...', the fact is, many did quality work and what we call
"rationality" no doubt owes plenty to these pre-Socratics.[2]

This move (coming to CS through philosophy) allows me to compete with
the more ordinary logical notations, but with OO, claiming OO is far
ahead of the Bertrand Russell era logicians and their propositional
descendants when it comes to fulfilling Leibnizian dream of machine
executable pattern languages.

The only reason OO hasn't made more inroads in K12 by now is
mathematicians wall out what they can't find a way to claim credit for
(I'm talking about an inferior brand of credit-hungry math head, not
top-of-the-line math people like Conway and Guy).

Back to inheritance, it's simply not the case that we only inherit
because of an is-a relationship.  We're always pouring in mixins, or
in Java, interfaces, which merely bolt on some common API, such as a
dial pad or other familiar widget set (a "dashboard" or "cockpit" of
controls and instruments, bells and whistles).

One could argue that composition would be the better approach but, in
Java anyway, we're interested in the gatekeeping and error trapping
functions of type checking.  We use it for quality control.  Unless
you (an instance of some class) support interfaces A, B and C, no way
may you pass yourself off as type X.

Failure to support some interface'd be like a Wild West sheriff who
can't handle a gun.  Sure, pistol packing is more a mixin in this
design, but it's also part of a sheriff's basic identity.  Without
that interface, you're just a wannabee.

In Python, we don't have interfaces per se (thanks in part to multiple
inheritance), and duck typing means we postpone a lot of the critical
gatekeeping until runtime.  Here you are, your first day on the job as
sheriff, in your Wild West saloon (off duty let's say).  Someone comes
through those swinging door thingys and says "Draw!" and you can't,
because you don't have a gun API.  An exception is raised.

Python programmers get used to catching such exceptions while testing
and won't release code that breaks in this way.  Java programmers rely
on their compiler to catch a lot of such problems even before runtime.
 We hope they also do a lot of runtime testing, because a green light
from the compiler doesn't mean your customer will be satisfied (gee,
wouldn't that have been nice?).

So there's a different feel to the debugging process in the two
languages, as a result of this difference in emphasis.  Bruce Eckel
talks a lot about this difference.[3]

Kirby

[1] http://mail.python.org/pipermail/edu-sig/2001-March/001030.html (autobio)
[2] http://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance
(pirsig)
[3] http://www.mindview.net/WebLog/log-0025 (eckel)