[Tutor] Volunteer teacher

[Alan Gauld]

On 26/07/2022 04:03, avi.e.gross at gmail.com wrote:

> <AG-UK> As I said in an earlier post you can do OOP in most any language.
> 
> I differentiate between using IDEAS and code built-in to the language meant
> to facilitate it. If you mean you can implement a design focusing on objects
> with serious amounts of work, sure. 

That's exactly what I mean. My point is that OOP is a style of
programming not a set of language features (that's an OOPL). It's
the same with functional programming. You can discuss how languages
like ML, Lisp, Haskell or Python implement functional features but
you cannot fully discuss FP purely by using any one of those languages.
And you can write non FP code in any of those languages while
still using the FP features.

> <AG-UK> IME. I'm not saying that nobody has a genuine use for a strictly
> homogenous container, just that 
> <AG-UK> I've never needed such a thing personally.
> 
> What I was talking about may be subtle. There are times you want to
> guarantee things or perhaps have automatic conversions. ...

Sure, and I have used arrays when dealing with code from say C
libraries that require type consistency. But that's a requirement
of the tools I'm using and their interface. Efficiency is
another pragmatic reason to use them but I've never needed
that much efficiency in my Python projects.

> I will note that many programming languages that tried to force you to have
> containers that only held on kind of thing, often cheated by techniques like
> a UNION...
> Languages like JAVA and others inheriting from a common ancestor

That's how most OOPL programs work by defining a collection of "object"
and all objects inherit from "object". And generics allow you to do the
same in non OOPLs like ADA.

> I won't quote what you said about Python being simple or complex except to
> say that it depends on perspective. As an experienced programmer, I do not
> want something so simple it is hard to do much with it without lots of extra
> work. 

Sure, and Guido had to walk the tightrope between ease of use for
beginners and experts. In the early days the bias was towards beginners
but nowadays it is towards experts, but we have historic legacy that
clearly favours the learners.

> But as a teaching tool, it reminds me a bit of conversations I have had with
> my kids where everything I said seemed to have a reference or vocabulary
> word they did not know.

That's always a problem teaching programming. I tried very hard when
writing my tutorial not to use features before decribing them but
it is almost impossible. You can get away with a cursory explanation
then go deeper later but you can't avoid it completely. I suspect thats
true of any complex topic (music, art etc)

> <AG-UK> That's not OOP, it's information hiding and predates OOP by quite a
> way.
> 
> I accept that in a sense data hiding may be partially or even completely
> independent from OOP 

> In that sense, we could argue (and I would lose) about what in a language is
> OOP and what is something else or optional. 

My point is that language features are never OOP. They are tools to
facilitate OOP. Data hiding is a curious case because it's a concept
that is separate from OOP but often conflated with OOP in the
implementation.

> topic, not just see how each language brags it supports OOP. In particular,
> your idea it involves message passing is true in some arenas but mostly NOT
> how it is done elsewhere. 

OOP is all about message passing. That's why we have the terminology we
do. Why is a method called that? It's because when a message is received
by an object the object knows the method it should use to service that
message. The fact that the method is implemented as a function with the
same name as the message is purely an implementation detail. There are
OOPLs that allow you to map messages to methods internally and these
(correctly from an OOP standpoint) allow the same method to be used to
process multiple messages.

> Calling a member function is not a general message
> passing method, 

No, but that's a language feature not OOP.
Languages like Lisp Flavours used a different approach where you
wrote code like:

(Send (anObject, "messageName", (object list))

The receiving object then mapped the string "messageName" to
an internal method function.

So the important point is that programmers writing OOP code in an
OOPL should *think* that they are passing messages not calling
functions. That's a subtle but very important distinction. And
of course, in one sense it's true because, when you have a class
heirarchy (something that is also not an essential OOP feature!),
and send a message to a leaf node you may not in fact be calling
a function in that node, it may well be defined in a totally
different class further up the heirarchy.

[ And we can say the same about calling functions. That's a
conceptual thing inherited from math. It practice we are doing
a goto in the assembler code. But we think of it as a conceptual
function invocation like we were taught at high school. The
difference with OOP is that message passing is a new concept
to learn (unless coming from a traditional engineering background)
whereas function calls we already know about from math class.]

> Perhaps it does make sense to not just teach OOP in Python but also snippets
> of how it is implemented in pseudocode or in other languages that perhaps do
> it more purely.

Certainly Booch takes that approach in his first and third editions
of his book. But even that leads to confusion between OOP and
language features (OOPLs). The essence of OOP is about how you
think about the program. Is it composed of objects communicating -
object *oriented* -  or is it composed of a functional decomposition
that uses objects in the mix (the more common case). Objects are a
powerful tool that can add value to a procedural solution. But OOP
is a far more powerful tool, especially when dealing with larger systems.

One of the best books IMHO to describe the difference in the
approaches is Peter Coad's book "Object Models, Strategies
and Implementations" It's not an especially well written book
and makes some controversial claims, but the concepts within
are clearly explained. But it is written at the UML level not code.

And of course there comes a point in almost all OOPLs where you
have to drop out of OOP thinking to use low level raw data types.
(Smalltalk and a few others being the exceptions where
absolutely everything is an object) Ultimately, pragmatism has
to take over from principle and the trick is working with OOP
at the program structure level and  raw data at the detailed
implementation level. Knowing where that line lives is still
one of the hardest aspects of using any OOPL. But it is still
an implementation issue not an OOP issue.

-- 
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