[Tutor] Volunteer teacher

Mon Jul 25 23:03:16 EDT 2022

Alan,

I will selectively quote just a few parts where I want to clarify as overall
we often mainly agree.

<AG-UK> As I said in an earlier post you can do OOP in most any language.

<AG-UK> I've used in in Assembler, COBOL and vanilla C as well as many
OOPLs.

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. I mean I can define an object as
multiple pieces of data and pass all of them to every function I write that
handles them instead of a pointer of sorts to a class. Or if pointers to
functions are allowed I can simulate many things. I just mean that languages
like FORTRAN and Pascal and BASIC that I used way back when, or PROLOG which
you mentioned earlier, came in my timeline BEFORE I had heard much about
Object-Oriented. 

I was programming in plain vanilla C when Bjarne Stroustrup started talking
about making an OO version he eventually put out as C++ and was the first
one in my area who jumped in and started using it and got the agreement to
use it on an existing project where I saw a way to use it for a sort of
polymorphism. I may have told this story already but I was SHOCKED they
allowed me to do that and a tad suspicious. I mean I also had to change the
"makefile" to properly distinguish between my files and regular C files and
properly call the right compilers with the right arguments and then link
them together.

Turns out I was right and the product we were building was never used. This
being the AT&T Bell Labs that wasted money, it seems management pulled
permission for the project but gave them 6 months to find a new project. But
rather than telling us and letting use some vacation time or take classes
and add to our skills or look for other work, they simply called a meeting
to announce that a NEW Project was starting NOW and that management had been
working it out for months and was reshuffling staff among supervisors
assigned to each part and so on! Sheesh!

And, yes, a project or two later, we did start using C++. My point was not
that concepts cannot be used, and arguably were sometimes used. 

<AG-US> If you look at Python, it has some glaring gaps as they considered 

<AG-US> heterogeneous lists to be the most abstract and neglected to make 

<AG-US> something basic in other languages like an array/vector.

<AG-UK> But that's something I've never found a need for in my 20 years of
using Python. I can fill a list with 

<AG-UK> homogenous objects as easily as with he[te]r[e]ogenous ones. It's
only when dealing with third party

<AG-UK>  tools (often written in other languages under the  hood) that the
need for an array becomes useful 

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

I think it goes deeper than that, Alan. Yes, other than efficiency
considerations, I fully agree that a list data structure can do a superset
of what a uniform data structure can do. So can a tuple if you want
immutability. In a sense you could argue that vectors or arrays or whatever
name a language uses for some data structures that only can contain one kind
of thing are old-school and based on the ideas and technology of an earlier
time. Mind you, it is not that simple. Old arrays typically were of fixed
length upon creation and usually took work to extend by creating a new one
and often led to memory faults or leaks if you followed them too far. But
when I look at some implementation in say R, they have no fixed length and
lots of details are handled behind the scenes for you. 

What I was talking about may be subtle. There are times you want to
guarantee things or perhaps have automatic conversions. You can build a
class, of course, that internally maintains both a list and the right TYPE
it accepts and access methods that enforce that anything changed or added is
only allowed if it either is the right type, or perhaps can be coerced to
that type. Or, perhaps, that if a new type is added that cannot mingle, then
change everything else to the new type. R is built on something like that. A
vector can hold one or more (or zero if you know how) contents of the same
type. It can expand and contract and even flip the content of all its parts
to a new one. I can start with a vector of integers and add or change a
float and they all become floats. I can do the same with a character string
and they all become character strings. But they are pretty much guaranteed
to all be the same type (or an NA, albeit there are type specific NA
variables under the hood).

This become useful because R encourages use of data structures like
data.frames in which it is necessary (or used to be necessary) for columns
in such tables to all reflect the same kind of thing. And, yes, it now
allows you to use lists which are technically a kind of vector too. I have
created some rather bizarre data structures this way including taking a
larger data.frame, grouping it on selected columns, folding up the remaining
columns to be smaller data.frames embedded in such a list column, doing
statistical analyses on it and saving the results in another list column,
extracting some of the results from that column to explode out into more
individual columns, and so on, including sometimes taking the smaller
data.frames and re-expanding them back into the main data.frame. The
structures can be quite convoluted, and in some sense resemble LISP
constructs where you used functions like CADDAR(.) to traverse a complex
graph, as many "classes" I R are made of named lists nested within .

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 of structures so everything was in some sense the same type.
Languages like JAVA and others  can really play the game using tricks like
inheriting from a common ancestor or just claim to implement the same
interface, to allow some generic ideas that let you ride comfortably enough
together.

In a sense, Python just did away with much of that and allowed you to hold
anything in a list or tuple, and perhaps not quite everything in hashable
constructs like a dictionary. 

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. I like that you can extend the core language in many ways including
with so many modules out there that are tailored to make some chores easier
- including oodles of specialized or general objects.

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. If you said Abyssinia and they asked what that was
and you answered it is now mostly Ethiopia across the Red Sea then they want
to know what that is or why it is called Red. If you explain it may be more
about a misunderstanding of Reed, and get into the Exodus story you find
words and idea you have to explain and so on until you wonder when they will
learn all this stuff and be able to have a real conversation!!!!

So there is always one kid in a class where you are teaching fairly basic
stuff who wants to know why you are using a loop rather than a comprehension
or not doing it recursively or using itertools and how many times can you
keep saying that is more advanced and some will be covered later and others
are beyond this intro course so ask me AFTER class or look it up yourself?

<AG-US> a major focus on OOP is to hide how it is done

<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 and the same for hiding an implementation so if it
changes, it does not cause problems. The idea is the object is a sort of
black box that only does what it says in the documentation and can only be
accessed exactly as it says. Some languages allow you to make all kinds of
things private and if they are compiled, it is not easy to make changes.
Some languages use fixed slots in classes to hold data while python allows
any object to pick up attributes so something like a function can create
memory attached to itself sort of on the outside outside and so can any
object. Someone posted some Python code recently that did things in ways
often discouraged such as changing a variable within an object directly and
was shown ways to not allow that in cases where it is a calculated value
that should change when another value changes but remain in sync.

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 views are not based o one
formal course in the abstract but maybe I should read a recent book on the
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. Calling a member function is not a general message
passing method, nor is being called while asleep on a queue and being told
nothing except that it is tie to wake up. 

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.

-----Original Message-----
From: Tutor <tutor-bounces+avi.e.gross=gmail.com at python.org> On Behalf Of
Alan Gauld via Tutor
Sent: Monday, July 25, 2022 7:54 PM
To: tutor at python.org
Subject: Re: [Tutor] Volunteer teacher

On 25/07/2022 20:58,  <mailto:avi.e.gross at gmail.com> avi.e.gross at gmail.com
wrote:

> I can't say the FIRST thing I look at in a language is OOP. LOL!

I didn't say it was the first thing I looked at, just one of the things I
looked at.

Although as someone who learned to design code (and indeed analyse

problems) using OOP I probably do look at OOP features earlier than most.

> I stopped counting languages long ago and many did not have anything 

> like OOP then,

As I said in an earlier post you can do OOP in most any language.

I've used in in Assembler, COBOL and vanilla C as well as many OOPLs.

> life to be the accumulation of lots of little tricks and techniques 

> that often allow you to use them to solve many kinds of problems, 

> often in association with others.

Absolutely and especially at the small scale level.

I hardly ever use OOP when I'm programming things with less than 1000 lines
of code. But as the code count goes up so does the likelihood of my using
OOP. But on the little projects I will use any number of tools from Lisp to
awk to nroff and SQL.

> ranging from echo and cat to cut and sed and grep and awk that could 

> be combined in pipelines

Indeed. And even in Windows NT I wrote a suite of small programs (using awk,
cut and sed from the cygwin package for NT) that were combined together via
a DOS batch file to create the distribution media for a project which had to
be installed in over 30 sites each with very specific network
configurations.

(And eventually that suite was rewritten entirely in VBA as an Excel
spreadsheet macro!)

>  rewritten in more  than one-liners in C or awk or PERL or whatever.

At work my main use of Python (actually Jython) was to write little
prototype objects to demonstrate concepts to our offshore developers who
then turned them into working strength Java. [Jython had the wonderful
feature of allowing my to import our industrial strength Java code and
create objects and call Java methods from my Python prototypes.]

But I've also worked on large projects where there is no coding done by
humans at all. These are mostly real-time projects such as telephone
exchange control systems and a speech recognition platform where the design
was done using SDL (Specification & Design Language) and the design tool
generated C code (that was all but unreadable by humans).

But if you didn't like C you could flip a configuration option and it would
spew out ADA or Modula3 instead... it didn't matter to the developers they
only worked at the SDL level.

> If you look at Python, it has some glaring gaps as they considered 

> heterogeneous lists to be the most abstract and neglected to make 

> something basic in other languages like an array/vector.

But that's something I've never found a need for in my 20 years of using
Python. I can fill a list with homogenous objects as easily as with
hereogenous ones. It's only when dealing with third party tools (often
written in other languages under the hood) that the need for an array
becomes useful IME. I'm not saying that nobody has a genuine use for a
strictly homogenous container, just that I've never needed such a thing
personally.

> I do not know why people say python is simple. 

Python used to be simple (compared to almost every other general purpose
language) but it is not so today. So many bells and whistles and abstract
mechanisms have been added that Python is quite a complex language. (In the
same way

C++ went from a few simple add-ons to C to being a

compeletly different, and vastly complex, animal!) Last time I updated my
programming tutorial I seriously considered choosing a different language,
but when I went looking I could find nothing simpler that offered all of the
real-world usefulness of Python! But it is a much more difficult language to
learn now than it was 25 years ago wen I first found it.

> It may be that the deliberate use of indentation rather than braces, 

> for grouping, makes it look simpler.

Simpler for beginners to understand. Remember Python came about largely as a
response to Guido's experience teaching programming with ABC. So it took the
features that students found helpful.

Block delimiters have always been a major cause of bugs for beginners.

> ...Copying code from one place to another is trivial

This is one of the strongest arguments for them.

and there are others too, however, as a language deliberately targeted at
beginners (but with potential use by experts too) Python (ie Guido) chose
ease of learning over ease of copying.

> So back to first appearances, I look for themes and differences. Does 

> the language require something special such as a semicolon to 

> terminate an instruction, or a colon to denote the beginning of a body 

> of text. What are the meanings of symbols I use elsewhere and are they
different.

I confess I don't look at those kinds of things at all. They are just part
of the inevitable noise of learning a language but I don't care whether they
are there or not. I just accept it whatever it is.

But then, I rarely choose a language, I usually have it thrust upon me as a
necessity for some project or other. The only languages I've ever chosen to
teach myself are Python, Eiffel, Prolog, Haskell and Logo.

The other 20 or 30 that I know have been learned to complete some task or
other. (However I do intend to teach myself Erlang, Lua and Clojure, and am
currently studying Swift so the list will get longer!)

> a major focus on OOP is to hide how it is done

That's not OOP, it's information hiding and predates OOP by quite a way. But
it's a good example of how language implementations of OOP have obscured the
whole point of OOP which is purely and simply about objects communicating
via messages. Information hiding is a nice thing to include and OOP
implementation details like classes can provide a vehicle to enforce it. But
its not part of the essence of OOP.

> and to allow existing objects to change how they do it as long as the 

> outside view is the same.

But that is polymorphism and a fundamental part of OOP.

The fact that you can send a message to an object and the object itself is
responsible for figuring out the method of processing that message is
absolutely key to OOP.

--

Alan G

Author of the Learn to Program web site

 <http://www.alan-g.me.uk/> http://www.alan-g.me.uk/

 <http://www.amazon.com/author/alan_gauld>
http://www.amazon.com/author/alan_gauld

Follow my photo-blog on Flickr at:

 <http://www.flickr.com/photos/alangauldphotos>
http://www.flickr.com/photos/alangauldphotos

_______________________________________________

Tutor maillist  -   <mailto:Tutor at python.org> Tutor at python.org

To unsubscribe or change subscription options:

 <https://mail.python.org/mailman/listinfo/tutor>
https://mail.python.org/mailman/listinfo/tutor