[Tutor] Volunteer teacher

[Alan Gauld]

On 25/07/2022 20:58, 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.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos