Re: TeX and Pascal [was Re: The joy of FORTRAN]

On 30 Sep 2024 21:10:33 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

I see. So, it seems to me that what you discovered was more about
Smalltalk specifically than about OOP concepts in general. I thought
maybe you could give some insights about what OOP is and what any
advantages or disadvantages of it might be because in your "I finally
*got* it", I assumed that "it" referred to "OOP".

It's a bit both, and it's hard to separate in my head because I don't
think I've seen it applied as naturally anywhere *other* than in ST.

OOP got wrapped up in all kinds of trendy buzzwords back in the '80s/
'90s depending on who was selling it to whom and which problem it was
being proposed as a cure-all for - "code reuse" for the corporate suits
who saw programmers as monkeys grinding out fungible "code product" by
hammering on typewriters and wanted to maximize hammerage-per-monkey
(and minimize monkey headcount, natch,) "information hiding" for the
security freaks, etc.

But basically, when you strip away all the marketing BS, I think the
true appeal of OOP (as I see it) is that it's an extension of the
*concept* of data structures; that is, it's a way of organizing data
into discrete structures that (when designed well, anyway) map neatly
to entities in the model of the problem the program is meant to solve.
But in addition to raw data, OOP allows the programmer to package the
*operations* inherent to an entity right along with it - and to adapt
them to one particular flavor of entity or another, as needed, so that
rather than having to remember the distinction between:

void sliceApple(apple * f)

and:

void slicePear(pear * f)

one could simply write:

fruitPile[i++].slice();

and trust that the Right Thing will be done. In this way (in a perfect
world,) a cleaner and (hopefully) more flexible model of the problem
can be built.

Now, *contrary* to what the marketroids of the '90s would've had us
believe, it's *not* magic pixie dust that makes everything better, it
does *not* obviate the need for intelligence and understanding of the
problem on the part of the programmer, and it has its own pitfalls to
be wary of (in particular, the distinction between operations which can
be appropriately classified as *methods of an object* and those which
are part of larger algorithms within the problem is both critical for
good OOP design and also somewhat fuzzy and requiring of careful
consideration and good judgement.) But as I see it, that's what the
draw is - a different way of modelling problems that (ideally) makes
the process clearer and simpler than doing it some other way.