lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Mon, Sep 17, 2018 at 12:24 PM, Petri Häkkinen <petrih3@gmail.com> wrote:
>
>> On 7 Sep 2018, at 23.41, Sean Conner <sean@conman.org> wrote:
>>
>> It was thus said that the Great Petri Häkkinen once stated:
>>>
>>> I would remove ’:’ and ’self’. I never use them in my code and they support bad habits.
>>
>>  What bad habbits?  The excessive use of OOP?
>>
>>  -spc
>
> I’m sorry, I somehow forgot to check back on this.
>
> I’m talking about OOP in general. Every OO codebase I’ve worked with has been an overdesigned, hard to maintain mess. In my opinion, the invention of OOP was a misstep, leading to analysis paralysis (so many ways to model the program as classes) and poor performance (caused by too much emphasis on abstractions and code reuse rather than efficient data flow — see Data Oriented Design).
>
> Luckily more and more programmers are beginning to realize this (including pretty much all experienced programmers I personally know).
>
> For me it took almost two decades in C++ land to realize it. After that I wrote a pretty substantial OO codebase in Lua, still OO because classes was all I could see back then. Now I’ve been working on a Lua codebase with only free functions for 2+ years and it feels much cleaner and easier to work with than any of the OO stuff I’ve done before.
>
> Especially with a powerful dynamic language such as Lua I see no need for rigid classes & inheritance.
>
> Petri

There's nothing wrong with OOP in general. There is a tendency for
some engineers to overengineer, this is true, and some tools end up
demanding overengineering (Java, I'm looking at you), but nothing
about the paradigm in and of itself is necessarily bad.

As with everything, it's always a question of having the right tool
for the job. There are some domains where an object-oriented modeling
is the obvious fit. There are some domains where trying to crystallize
up an object model ends up making more of a mess than it solves. And
the most egregious source of trouble is when you're forced to use
SOMEONE ELSE'S object model because the underlying framework demands
it even when it doesn't make sense for your needs. And on the flip
side, having a bunch of free functions means that you expect all of
your things to behave the same way all the time -- which is a
perfectly reasonable design for some applications, and a dangerously
bad design for others.

That said, I agree with the conclusion that Lua doesn't need rigid
classes and inheritance built-in. Dynamic languages have their roles
just like static languages do. If your problem is one that would be
better served by a static language, then you should use something
besides Lua instead of trying to force Lua to conform to what you're
looking for.

Lua's implementation of OO is a very good balance for a dynamic
language. It allows grouping related data together in a container, it
allows that data to carry around the functions that it expects you to
use on it, and it gives objects the ability to share a set of
predefined behaviors. None of these are required if they don't fit
your purposes, but they're sufficiently lightweight and unopinionated
that they can deal with most use cases.

/s/ Adam