some problems for an introductory python test

[Chris Angelico]

On Thu, Aug 12, 2021 at 5:00 AM Hope Rouselle <hrouselle at jevedi.com> wrote:
>
> Chris Angelico <rosuav at gmail.com> writes:
>
> > On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle <hrouselle at jevedi.xotimo> wrote:
> >>
> >> Chris Angelico <rosuav at gmail.com> writes:
> >>
> >> [...]
> >>
> >> >> not disagreeing... and yeah I could have thought deeper about the
> >> >> answer, but I still think "notthing has been OOP" -> "yes it has, they
> >> >> just didn't realize it"  was worth mentioning
> >> >
> >> > Oh yes, absolutely agree.
> >>
> >> At the same time, inside the machine nothing is OOP --- so all the OOP
> >> is no OOP at all and they just didn't realize it?  This seems to show
> >> that OOP is about perspective.  An essential thing for OOP is the
> >> keeping of states.  Closures can keep state, so having procedures as
> >> first-class values allows us to say we are doing OOP too.  (Arguments of
> >> procedures are messages and function application is message passing,
> >> with closures keeping a state --- and all the rest of OOP can be
> >> implemented with enough such functional technology.)  In summary, OOP
> >> should not be defined as some special syntax, otherwise there is no OOP
> >> in ``2 + 2''.
> >>
> >> Having said that, I totally agree with all the nitpicking.
> >
> > Object orientation is a particular abstraction concept. It's not a
> > feature of the machine, it's a feature of the language that you write
> > your source code in. I've done OOP using IDL and CORBA, writing my
> > code in C and able to subclass someone else's code that might have
> > been written in some other language. [1] Central tenets of OOP
> > (polymorphism, inheritance, etc) can be implemented at a lower level
> > using whatever makes sense, but *at the level that you're writing*,
> > they exist, and are useful.
> >
> > Data types, variables, control flow, these are all abstractions. But
> > they're such useful abstractions that we prefer to think that way in
> > our code. So, *to us*, those are features of our code. To the
> > computer, of course, they're just text that gets processed into
> > actually-executable code, but that's not a problem.
>
> Total agreement.
>
> > So I would say that (in Python) there IS object orientation in "2 +
> > 2", and even in the Python C API, there is object orientation, despite
> > C not normally being considered an object-oriented language.
>
> But would you say that 2 + 2 is also an illustration of object
> orientation in any other language too?

In some languages it is; in others, it's not. For instance, REXX
doesn't have polymorphism. You can add two numbers together using x+y,
or you can concatenate two strings with x||y. There's no concept of
doing the same operation (spelled the same way) on different data
types. (Partly that's because REXX doesn't actually *have* data types,
but it does a pretty good job of simulating strings, bignums, floats,
arrays, mappings, etc.)

But in many modern programming languages, yes, it would be a
demonstration of some of the object orientation features.

> Regarding C, I have many times said that myself.  If I wrote assembly,
> I'm sure I would do my best to create things like procedures --- a label
> and some bureaucracy to get arguments in and a return value out.

Oh absolutely. But you'd also have the option to shortcut things if
you wanted to. For better or for worse.

> > [1] And boy oh boy was that good fun. The OS/2 Presentation Manager
> > had a wealth of power available. Good times, sad that's history now.
>
> I know OS/2 only by name.  I never had the pleasure of using it.  In
> fact, I don't even know how it looks.  I must be a little younger than
> you are.  But not too younger because I kinda remember its name.  Was it
> a system that might have thought of competing against Microsoft Windows?
> :-) That's what my memory tells me about it.

History lesson!

Once upon a time, IBM and Microsoft looked at what Intel was
producing, and went, hey, we need to design an operating system that
can take advantage of the fancy features of this 80286 thing. So they
collaborate on this plan to make a 16-bit protected mode OS.
Unfortunately, things didn't work out too well, partly because this
was when Microsoft was at its most monopolistic, and they ended up
parting company. IBM continued to make OS/2, but Microsoft took their
part of the code and made Windows NT out of it.

(Aside: Windows NT's 16-bit applications and OS/2's 16-bit
applications were actually identical and compatible. Unfortunately,
Win32 introduced a very new API, so as soon as everyone moved to
32-bit everything, the schism became problematic. But it was actually
possible to package up a single .EXE file with a 16-bit MS-DOS loader,
a Win32 loader, and an OS/2 32-bit loader, all happily coexisting.
PKZIP, the original definition of the zip file format, did exactly
that, or at least had two out of the three (I don't quite remember if
it went the whole way), making it extremely convenient to zip and
unzip files on different computers.)

In the latter half of the 1990s, Windows came in three broad flavours:
the 16-bit Windows 3.x line, which ran purely on top of DOS; the
32-bit Windows 95 line, which was the "home" OS and had to be heavily
compatible with Windows 3, but still doing more things; and the
Windows NT line, which was aimed at businesses. OS/2 was a viable
option for businesses, but almost nobody took it seriously as a home
OS. And Microsoft was using its marketing machine to push Windows
fairly hard, so most people went that way.

OS/2 had all kinds of amazing features (for its time). The default
file system, HPFS ("High Performance File System"... IBM was good at
many things, but imaginative naming wasn't one of them), did a
spectacular job of maintaining reliability and performance on the
ever-growing hard disks of the time. Yes, it coped remarkably well,
even on *gigantic* drives that could carry, ooh, an entire gigabyte of
data! I'm not kidding! We even had a drive that had TWO gigabytes of
space, and HPFS managed it beautifully! Plus, it had this fancy
concept of "extended attributes"; on older systems (like MS-DOS's
"FAT" family), a file might be Read-Only, Hidden, a System file, or
needing to be Archived, and that was it - but on HPFS, you could
attach arbitrary data like "File type: DeScribe Word Processor" or
"Double click action: Run CASMake.cmd". This allowed the GUI to store
all kinds of information *on the file itself* instead of needing
hidden files (or, in Windows' case, the registry) to track that kind
of thing.

The default command interpreter and shell on OS/2 was fairly primitive
by today's standards, and was highly compatible with the MS-DOS one,
but it also had the ability to run REXX scripts. REXX was *way* ahead
of its time. It's a shell language but remarkably well suited to
building GUIs and other tools (seriously, can you imagine designing a
GUI entirely in a bash script??). It had features that we'd consider
fairly normal or even primitive by Python's standards, but back then,
Python was extremely new and didn't really have very much mindshare.
REXX offered arbitrary-precision arithmetic, good databasing support,
a solid C API that made it easy to extend, integrations with a variety
of other systems... this was good stuff for its day. (REXX is still
around, but these days, I'd rather use Python.)

I mentioned the Presentation Manager, because it was one of the best
parts of running OS/2. The kernel was decent, but it was the graphical
shell that was the real pleasure to work with. Probably the most
notable feature, by today's standards, was that it had a single input
queue. If you press a series of keys, they'd go into a global queue,
and the application that has focus would get the first one. When that
key has been handled, the application that has focus would get the
next key from the queue. This means that, if the response to a
keystroke is to change focus, then *even in a slow and lagged out
system*, subsequent keys WOULD be sent to the new target window. That
was AWESOME, and I really miss it. Except that I also don't. Because
if a single application is having issues, now your entire keyboard and
mouse is locked up... which kinda slightly sucks. Good luck resolving
that problem. (We had some neat tools like WatchCat that could get
around the single input queue via interrupt signals, and regain
control. But it was still problematic.)

So, yeah. It was spectacular in its day.... but it kinda got left
behind as the world moved on. These days, instead of running REXX code
on OS/2 in a system that uses eight-bit text for most things, I use
Python on Linux and full Unicode. But OS/2 was an important part of
history, both my own personal journey, and the history of the world of
PCs.

ChrisA