On Thu, Aug 12, 2021 at 5:00 AM Hope Rouselle <hrouse...@jevedi.com> wrote: > > Chris Angelico <ros...@gmail.com> writes: > > > On Wed, Aug 11, 2021 at 4:18 AM Hope Rouselle <hrouselle@jevedi.xotimo> > > wrote: > >> > >> Chris Angelico <ros...@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 -- https://mail.python.org/mailman/listinfo/python-list