Re: Thought experiment: what would you remove from Lua

[Coda Highland <chighland@...>]

On Wed, Sep 19, 2018 at 1:27 AM, Petri Häkkinen <petrih3@gmail.com> wrote:
>
>> On 18 Sep 2018, at 22.32, Coda Highland <chighland@gmail.com> wrote:
>>
>> Not all OOP looks like C++ or Java. Carrying callbacks in your data is
>> still OOP.
>>
>> Having an object with optional event handlers is a form of OOP that's
>> actually OLDER than C++.
>
> I disagree. Using function pointers does not automatically mean that it’s OO. Especially since with the callbacks there’s no direct correlation between functions and data (the callbacks may not even get the pointer to the data, for example with continuations). I’m pretty sure jump tables & function ptrs predate OOP by at least a decade, so saying that any code that uses function pointers is automatically OO sounds weird.
>
> Petri
>

I didn't say "using function pointers." I said "carrying callbacks in
your data." And on the assumption that your data is structured and the
callback always has a consistent semantic meaning concerning the data
carrying it, then that is at least rudimentarily object-oriented code.
Obviously the rest of the program might not be structured in such a
way that the object-oriented nature of that structure is relevant at
all, so I wouldn't go so far as to say the code is automatically OO,
but the kernel is there and it can certainly be beneficial to make use
of that nature when it's the right tool for the job.

(In particular I was actually talking about Smalltalk, which uses
message passing, not function pointers.)

Because central to the idea of object-oriented programming is the
concept of polymorphism: the notion that objects that obey a certain
contract can be treated interchangeably even though their
implementation details differ. Languages like C++ and Java define
these contracts statically, requiring that the programmer teach the
compiler how to enforce this. Languages like Lua allow the contract to
be defined informally. But as long as that contract has the object
itself providing the implementation details of some operation, you can
meaningfully call it object-oriented.

This is obviously not the right choice for many kinds of applications.
If your data is always the same structure anyway, then flat functions
have some clear advantages -- namely, it's a lot easier to describe
some properties about the functions, such as whether or not they're
pure.

The biggest problem with OO is, as I mentioned previously, opinionated
frameworks. "When all you have is a hammer," as the saying goes: Java
engineers in particular have a tendency to try to build frameworks
that are generic enough to tackle anything without thinking about
whether or not it's actually the best idea. (C++ engineers do the same
thing but instead of making a zillion interfaces that require you to
define dozens of tiny classes, they make a zillion templates.)

This isn't the fault of the object-oriented paradigm, though, because
you'll see the same failures in the functional programming community:
a rigidly narrow focus on defining everything in terms of pure
functions, higher-order functions, and function composition, inventing
schemas and frameworks and patterns that they swear will make your
code better if only you follow the rules. And if your application fits
the kind of ideas where that structure makes sense, it does. And if
your application doesn't quite fit that mold, you end up having to
hack around it, making a mess where you might have been able to
express the same thing in a few obvious lines of code.

In short: Use the right tool for the job. Sometimes OOP is the right
tool. Sometimes FP is the right tool. Sometimes good old-fashioned
structural/procedural code is the right tool. Sometimes it works best
to use a hybrid of the techniques. (There's a functional-OO hybrid
that I'm particularly fond of that I've seen a few different sources
discuss but there's no consensus on what to call it because there's
not yet a large body of formal theory around it.) No programming
paradigm is inherently bad, and you shouldn't dismiss them just
because you've had bad experiences -- odds are, your bad experiences
were the result of it not being the right tool for the task you were
doing at the time.

/s/ Adam