[Edu-sig] more simmering debate...

[kirby urner]

On Wed, Apr 20, 2016 at 11:00 PM, Iwan Vosloo <iwan at reahl.org> wrote:

> Hi Kirby,
>
> You may be interested in Dijkstra's take on teaching via metaphor:
> https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html
> I am not sure exactly how it applies to your case.
>
>


I'm going through this.  Interesting.  I've not plumbed his writing much.

There're some hours of me on-line doing a workshop in Chicago where I cite
the guy, as the father of structured programming (new idea at the time, the
Age of Spaghetti Code).

Steve Holden, co-presenter, interjects that Dijkstra's medicine could be
hard to swallow given he had no bedside manner (paraphrase). [1]

I just heard the joke about arrogance being measured in nano-dijkstras
(some Youtube from the Javascript culture).

Anyway, I'm glad for the link, so thank you.

What about coding just to experiment, as an art project?

He seems very fixated on his model program with its "functional
specification" along with some "proof".

But some styles of coding are much more like experimenting in a lab, just
trying stuff, not knowing the result in advance.

He seems to have a rather narrow definition of what it means to program?
The languages were lower level back then, is maybe part of it.



It seems to me that OO tends to get taught in terms of the mechanisms
> present in OO languages and how that is implemented. Things like the notion
> of inheritance, polymorphism and the idea of putting behaviour and data
> together.
>
>
I really want to anchor OO in human language (human-executable: Hx).

It's in English that we have "things" (etymology is closer to "meetup" but
that's another story).

Things have properties and behaviors.  Not news.

Plus we also understand about inheritance, not only in agronomy and animal
husbandry (including of humans by humans) but in terms of cultural heritage
(memes not just genes).

These metaphors are ingrained in how we think about everything and for all
the "radical novelty" a computer may represent, sometimes the goal is not
to be amazed and agog at the stunning genius of computer architecture, and
to get on with cell biology, the real focus, the work at hand. [3]

To that end, the fact that an OO language that lets us start right away
with "class Cell:" (immediately and not after two years of computer
science), is a big relief, a boon, a godsend.

What I want is for students to daydream about their own lives in Python
code.

I go to start my car, there's an exception.  How do I handle that
exception?  Is the battery dead (raise BatteryDead)?  Or did the key break
off?  (raise KeyBreak).

The latter is pretty rare but happened to me in the code school parking
lot.  The next day, I shared a little program about it.

https://github.com/4dsolutions/Python5/blob/master/carkeys.py

Thinking in Python includes thinking about ordinary everyday things in
Python.  It doesn't mean fantasizing about the guts of a Von Neumann
architecture computer unless you really need that to be your knowledge
domain i.e. that's your line of work.

Lets think about Cells and Proteins in Python.  What attributes do they
have, what behaviors?  And what inherits from what?

https://github.com/4dsolutions/Python5/blob/master/genetics.py
(just native Python types here, no use of class semantics)

Lets talk about ancestral trees in the discipline at hand.  Are there any?

OO is a way of analyzing a knowledge domain D into an expressive language L
that is also machine executable (Mx).

Mx <----- L -----> Hx

Fig. 1:  a spectrum



> When I learnt OO we were taught about concepts, how they're defined by
> intention/extension and how they can be reasoned about in terms of set
> theory. We were taught about how to produce OO analysis models. That shows
> you how to think about a problem.
>
> Language features and how they work are—out of  necessity—a very limited
> shadow of such models. Language features are not even necessary for
> implementing an OO model - you can happily reap OO benefits writing C code.
>
>
Indeed, given Python is just a pile of C code (some Pythons that is).


> My feeling is teaching OO by language features is like giving people a
> physical tool without giving them the mental tool that gives direction on
> how to  and why and where use it (or not).
>
>
I'm suggesting Human Language already has a lot of what we need in its
toolbox.

For all Dijkstra's criticizing how we dumb it down with misshapen
metaphors, OO is intentionally and by design aimed it implementing everyday
experiential concepts we learn in Hx languages -- way before we try our
hand at using Ls closer to the Mx end of the spectrum (see Fig. 1).

Concrete (computable) <----- L -----> Speculative (non-computable)

Fig. 2:  same spectrum


> One nice book that does explain the fundamentals really well IMHO is
> "Object-Oriented Methods: A Foundation" by James Martin/James Odell.
> http://www.amazon.com/Object-Oriented-Methods-Foundation-UML-2nd/dp/0139055975
>
> Regards
> - Iwan
>
>
I'll check this out as well.  I have Safari On-Line, maybe it's there.

Kirby


[1]  http://worldgame.blogspot.com/2009/03/urner-workshop.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/edu-sig/attachments/20160421/03c1b7b8/attachment.html>