[Tutor] teaching for purpose

[Alan Gauld]

n 25/07/2022 19:23, avi.e.gross at gmail.com wrote:
> The recent discussion inspires me to open a new thread.

Probably a good idea! :-)

> It is about teaching a topic like python or kinds of programming it supports
> and doing it for a purpose in a way that does not overwhelm students but
> helps them understand the motivation and use of features.

I think motivation is key here. But many of the things we have been
discussing cannot be understood by true beginners until they have the
elementary programming constructs under their belt (sequence, loop and
selection plus input/output and basic data types),

Only once you get to the level where you can introduce the creation
of functions (and in some languages records or structures) do higher
level issues like procedural v functional v OO become even
comprehensible, let alone relevant.

> One was bottom-up. Show what the world was like...
> Then show what a pain it was to say fire a user or move them elsewhere
> without remembering to make changes all over the place.

That is the usual starting point for OOP, it is certainly
where Booch goes.

> The other way is to work more from top-down. Show them some complex network
> they all use and say this could not easily be build all at once, or
> efficiently, if it was not seen as parts and then parts within parts, 

The Smalltalk community (from whence the term OOP came) took such
a high level view and discussed programming as a process of
communicating objects. And likened it to real world physical objects
like a vehicle etc. You could demontrate how a vehicle is constructed of
parts each of which is an object, then deconstruct those objects further
etc. Thus their students came to programming thinking about ibjects
fiorst and the low level "data entities" were just low-level objects,
no different to the higher level ones they already used.

Seymour Papert took a similar approach with Logo which is
not explicitly OOP focused but does share the idea of issuing
commands to code objects. He used robots(turtles) to teach the
concepts but the ideas were the same.

> program are not RUN in a deterministic manner but must pop into being, 

The may not run in a sequential manner but they most assuredly are
deterministic for any given sequence of events. And from an OOP point of
view an OOP program does not normally appear to run sequentially but
more like an event driven system. As messages are received from other
objects the receiving objects respond. Of course there must be some
initial message to start the system off but its conceptually more
like a GUI than a traditional compiler or payroll system.

> At some point you want to make sure the students get the ideas behind it,
> not just some silly localized syntax useful only in that language.

This is exactly the point I've been trying (badly) to make.
It is the conceptual understanding that is critical, the syntax
is a nice to have and will change with every language.

> ...Take the five or more ways python allows formatting text.

Hmm, yes that's one of the features of modern python I really dislike.
It's simply confusing and a result of the open-source development model.
Even with a benevolant dictator too many variations exist to do the same
job. The community should pick one, make it fit for all purposes(that
already exist) and deeprecate the others. But historic code would get
broken so we have to endure (and become familiar with) them all!
It's the nightmare of legacy code and the same reason that modern
C++ is such a mess. Java is showing signs of going the same way.

> What I find helpful in motivating using objects when they really are NOT
> NEEDED is when it is explained that part of the purpose was to make a set of
> tools that work well together.

One point that needs to be made clear to students is that code objects
are useful and don't need to be used in OOP. In fact most objects are
not used in OOP. Coding with objects is not the same as coding in OOP.
Objects are a useful extension to records/structures and can be used in
procedural code just as well as in OOP code.

It is the same with functions. You can use functions in non functional
code, and indeed the vast majority of functions are non functional in
nature. But you can't write functional code without functions. And you
can't write OOP code without objects(in the general sense, not in the
"instance of a class" sense).


> So why ask the user to set a variable to a new object of some sort, then
> repeatably ask the object to do things to itself like accept data or add to
> existing data, set various internal attributes like values telling it to be
> fast or accurate or which technique to use, or to transform the data by
> normalizing it some way, and run analyses and supply aspects of what it came
> up with or predict now new data would be transformed by the internal model?
> This does not, at first, seem necessary or at all useful.
And certainly not OOP!

> But consider how this scales up if say you want to analyze many files of
> data and do some comparisons. Each file can be held by it's own object and
> the objects can be kept in something like a list or matrix  and can be used
> almost interchangeably with other objects that implement very different ways
> to analyze the data if they all take the same overall set of commands, as
> appropriate. All may be called, say, with new data, and asked to predict
> results based on previous learning steps. 

Again, none of which is OOP.

> The point in all the above, which may easily be dismissed by the volume, is
> that I think part of learning is a mix of ideas in the abstract as well as
> some really concrete programming along the lines of prototyping. Learning
> Object Oriented Programming in the abstract may seem like a good idea,
> albeit implementations vary greatly. But knowing WHY some people developed
> those ideas and what they were meant to improve or handle, .

Learning anything in the purely abstract rarely works.
The problem with OOP is that it only makes sense in fairly
big projects, certainly much bigger than most programming
learners ever experience. Probably bigger than most university
students experience too. Arguably only where multiple programmers
are involved does it really show value - or where the requirements
are very complex.

> I shudder sometimes when a functional programming person tries to sell me on
> using closures to retain values and so on, until I realize that in a sense,
> it overlaps object-oriented programming. Or does it?

Most functional adherents view OOP as the very opposite of
good functional practice with the implicit retention of state.
I've seen arguments to suggest that instance attributes are
just special forms of closure but I'm not convinced. I tend
to view them as orthogonal views of the world that rarely
intersect (but can be usefully combined).

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos