The problem with the Object Oriented Programing

General discussion for topics related to the FreeBASIC project or its community.
c-sanchez
Posts: 145
Joined: Dec 06, 2012 0:38

The problem with the Object Oriented Programing

Post by c-sanchez »

csanchez wrote: Hi guys, what do you think about Object Oriented Programming? (OOP)
Is it right to use it? Is it wrong?
Neil wrote: It depends on the amount of complexity to reach a certain goal.
OOP on itself is a powerful tool but the way that is taught in schools
(and often the internet) make it something harmful for
the industry as it often adds unneeded complexity;
Usually, the way that they teach you introduces the next problems:
- it makes the code harder to write
- it makes the code harder to process (by human and/or machine)
- it makes the code harder to maintain

The thing is that often those people are taught that the only way to make
readable and good code is to use OOP, and not just normal OOP but entire
dependency trees that end up in painful situations.
They're taught that directly writing and/or reading data is complicated and
easy to get yourself in trouble, so they write huge abstractions with all sorts
of crazy overengineering only to make things SEEM simpler.
Like, instead of a Dog class depending on an Animal class, you have a _protoAnimal
class, an Animal class, a Canine class, and classes like Legs and Eyes which go inside
other classes.

Asides from that, OOP gets a bad rep for all the problems I mentioned, while actual
OOP isn't as near as complicated if you know how to do it right, it can be a neat
tool to simplify things, it's just that overengineering is a standard.
Mysoft wrote: My problem with OOP is not the paradigm, but with the language features around that, for example:
dim as MyObject A
would cause a "function" to be called and if you would do:
A += B
another function would be called and other implicit stuff like that.
First case is a constructor, Second case is an operator overload

Anyway I think Neil's lines make sense.
But another thing about it is when a language forces you to use classes and OOP stuff,
where it goes bonkers, because it removes the choice, with the extra complexity.
That is more for the compiler to handle, and as result less the programmer knows, dumber it gets.

So if one would use OOP without having "automatic" facilities, to the point that
they still have to manually call the constructor (or the function that the create
the object that will implicit initialize it there) and etc... stuff that forces
you to see/handle the inners of the object, then you would end with code that you
wouldnt want to deal with it; and if that happens it means you're doing wrong using OOP

Its like the economy of the world.
That relies on "slaves" doing the hard work to make it easy for the powerful people
you see the problem there?
csanchez wrote: quotation marks?
Mysoft wrote: Yeah because the slave point where the abuse happens is the computer and hardware,
but it does not change the picture

In my opinion just like a good leader is the one that sets the example,
A good leading programmer is the one that code setting the example,
instead of passing the responsability to the hardware.
csanchez wrote: But they are not Slaves, they are Constructors, heh.
Mysoft wrote: Slave is the hardware that is forced to comply with this $%#@.
Constructor is just the current title made to give them some value while being forced to the dirty job.

Another analogy would be with full metal alchemist.
When he almost made the stone using live humans, thinking they were
just that red water, because the actual work was hidden.
Neil wrote: As I am reading this right now, I agree with Mysoft as he said that languages that
enforce OOP tend to overcomplicate things as they lead the developer to follow
harmful ideas I mentioned already in my argument.

I disagree that the compiler handling everything makes the developer dumber, but rather,
it makes the developer not know what's happening at the core of their code.
It's not about lack of intelligence, but rather, lack of knowledge of what your program is
even doing (which also affects newbies as they mislearn how things work, on where Mysoft IS right).
Compilers should NOT guide the user to writing complex code, instead, compilers should guide the
developer to handle things properly, to know what their code is doing at all times, to know
that the code might be doing something extremely cursed and even lead the developer to write
direct and thus efficient code which does not rely on massive amounts of abstraction for the
sake of abstraction; alongside protecting the program's integrity by handling errors and possible
problems properly.

And I don't think abstraction is inherently wrong either, we all use abstraction.
I just think that in several examples of state-of-the-art software, we can see that they're
flooded with weird ideas about how software must be written AROUND abstraction instead of
writing necessary abstraction AROUND fixing a real problem for what your code NEEDS;

It becomes a distraction.

I am not against constructors either, but I do think that they do offer a layer of abstraction
that hides away what the code is intending to do and/or the data it's processing. they exist since
before C even existed and they're okay as long as they're fairly explicit with what they're meant
to do in more complex data structures; though sincerely this last point is just my personal preference.

Oh, forgot to mention that depending on hardware for certain tasks is actually a better idea than not.
As an Example, OpenGL is known for being very slow and unefficient in most hardware as it's abstracted
in a way that makes things hard to track on and hard to process for both the CPU and GPU when compared
to Vulkan, DirectX, Metal, etc.
I am not saying that software should be written to only support updated hardware but rather have
actual care about the target demographic and focus on optimization for the hardware the software is
meant to be ran on, instead of just forcing consumerism and making people pay for new hardware.
(I heavily recommend BGFX for this kind of task as it abstracts both old and new rendering pipelines
so it always has the best performance in any hardware that it runs on, at the point of having negative
overhead in most cases compared to using pure rendering APIs while also saving you from the pain lol)

It's pretty funny how MacOS' apps tend to be covered in OOP yet the bare frameworks
that make them are purely imperative and data oriented (like Accelerate)
Chris wrote: Indeed there are very good programmers that reject OOP and most of the time the rejection will be related
on how it is implemented, bloatware and the current trend of anti-pattern practices against the objects.

I believe OOP must be used on memory persistent apps with interfaces, that will apply to any windows app
with user interface, linux GUI, or whatever you can imagine with an interface with a running process, for
a programmer is very easy to understand all parts involved as objects because is natural.

I reject the new trend about CLOSURES that allow to manipulate a private class member from the outside
or any other trendy method to create anti-pattern practices on OOP, function injection and such must be
avoided.

On the other side you have stateless apps, these are created to output some code and then die, the best
example is the Webservices, UNIX scripts, text parsers, PHP Backend, Python Backend..etc, so for this kind
of environment I will always try the simplest code with a minimal approach that is also easy to read and
the best for this is a functional / procedural approach, the problem with OOP is that most of the time you
will be creating objects that at the end will be destroyed just to output JSON or HTML.

Most of the time OOP will involve a ORM to manipulate a database, for the web this is overkill, you don't
need these layers of abstraction, you don't need to abstract the database, you don't need to create an
object representing a row in the database, writing your own optimized SQL and using arrays will be better
in every way.

So at the end I am against over-architecture, bloated code and current way of doing things.

Full stack developers? they need them because they are using many tools (third party tools) that they
barely know how to use or maintain, at some point the final product will become abandon-ware if a small
part of their stack is deprecated.

Developers talking about DEPENDENCY? they care so much about it because a hello world app will have many
of them and they don't even know why..

Think about any software out there, in the 90's you could fit big apps in a floppy disk of less than
1mb, now they eat gigabytes like there is no tomorrow, developers needed to code in a very optimal way
to fit the app in memory, now they don't care, why? because we all have supercomputers compared to what
we had years ago.

So for a guy like me looking at current "tech" is like, WTF, what they are smoking, also I have the same
feeling for the current way of living, I am not even that old but the today's world is crazy..

Just taking a look to an average "smart phone" out there with a 2Ghz CPU and 4 cores, how they can be
so slow? the problem is not the hardware, the problem is the software, it is getting worse every day and
they don't even care, they just fill the OS with crap-ware and bloat-ware and smile..

Hoa this was fun!!!
Interest links:
https://thenewstack.io/why-are-so-many- ... ogramming/
c-sanchez
Posts: 145
Joined: Dec 06, 2012 0:38

Re: The problem with the Object Oriented Programing

Post by c-sanchez »

I am not an expert in the area, not even a programmer, however in my personal tests
and talking to some programmers (that I personally consider very talented) I have
realized that they usually agree on one point, "object oriented programming is not good".

Personally, I have tried to use some libraries for FreeBASIC and encountered problems
when trying to use them.
And from their opinion, it seems that it is the habit, which comes from
the "good recommendation" that there is currently around OOP.

On the other hand, I've seen a lot of comments wishing x thing related to OOP, but I've
almost never seen opinions exposing the problems of talking well only about this.

Many times, whoever expresses a contrary opinion, does it in a way that is "extreme" or
"insulting", and because of this, the reason that someone may have to criticize him, even
if he does it in an "aggressive" way, is ignored.

For all this I decided to gather the conversation/comments of some programmers on the
subject, and publish them for those who are interested to read them :)

Although it may be a bit long, they have comments and opinions that in my opinion are
interesting to say the least, and in my opinion probably very accurate.

In closing, my heartfelt thanks to Chris, Neil and Mysoft for their time and comments,

I leave you with a video of raylib 4 binding by WIITD and fixed by Mysoft.
https://youtu.be/312khy8XB1Y
I do not do it with any intention to belittle the work of anyone, just to show the problem found.

I won't say more, I hope you enjoy reading it.
And maybe change the way you use OOP a little bit? heh
c-sanchez
Posts: 145
Joined: Dec 06, 2012 0:38

Re: The problem with the Object Oriented Programing

Post by c-sanchez »

raylib 4 by WIITD
Image

raylib 4 by WIITD, fixed by Mysoft
Image
paul doe
Moderator
Posts: 1730
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: The problem with the Object Oriented Programing

Post by paul doe »

c-sanchez wrote: ...
raylib 4 by WIITD, fixed by Mysoft
I don't see where the 'fix' lies. He just removed the constructors, forcing you to do the cumbersome work. Yeah, that's quite the fix...

Why not just declare some memory, allocate it, zero it, and fill it with valid values? And then, after we're done, release it? Because that's how real coders do it, no?

The real problem I see here is that none of the above coders know what Object-Oriented Programming really is. They focus their arguments and criticism on pure conveniences (constructors), instead of the real gist of it (decoupling interfaces from implementations). As a fun aside fact, you can't do 'real' OOP in FreeBasic (or C++, for that matter).

So no, I don't find the discussion interesting. I find it cringeworthy.

Oh, and kudos for the video showing a half-baked, pseudo-OOP header that doesn't compile for reasons, versus a header heroically fixed by Mysoft, removing all the conveniences to make you a better coder, and spare you from the horrors of OOP XD
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: The problem with the Object Oriented Programing

Post by caseih »

paul doe wrote:As a fun aside fact, you can't do 'real' OOP in FreeBasic (or C++, for that matter).
That's okay as not everyone agrees on what OOP is even. Certainly the inventor of OOP and the Smalltalk language would argue that C++ and Java (in particular) took it in an entirely wrong and not-always-helpful direction. It's a bit sad that a couple of generations of programmers have been ruined by Java shoe-horning everything into a class structure.

But when I see FB or C++ classes containing dozens of attributes, I feel like such code probably needs a re-think and a re-factor!
Last edited by caseih on Jan 10, 2022 4:05, edited 1 time in total.
paul doe
Moderator
Posts: 1730
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: The problem with the Object Oriented Programing

Post by paul doe »

caseih wrote:That's okay as not everyone agrees on what OOP is even.
...
Alan Kay himself stated that the whole point of it was 'message passing', hence, decoupling the interfaces from their implementations (ie polymorphism). All the rest (including inheritance) is mere convenience.
...
But for sure when your class contains dozens of attributes, you need to rethink what you're doing there.
You can certainly make a mess (read: overengineer) with any paradigm. Unfortunately, as powerful as OOP can be, it's also very easy to shoot yourself in the foot. But then we blame it on our tools. The whole point of stating that 'OOP isn't good' is moot, since it's basically the same thing as stating that 'a hammer is not good'. Of course a hammer is not good to bolt a screw. When people learn how to use a hammer, suddenly everything is a nail...
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: The problem with the Object Oriented Programing

Post by caseih »

To me a good application of OOP, the type espoused by C++ or FB, would be certain GUI toolkits like GTK+ or Qt. Widget hierarchies lend themselves well to a class structure. And the event systems they use are a handy, natural extension of OOP as they allow this very decoupling of which you speak. For example, I can build a widget (well an object of any kind actually) in isolation and test all of its functionality through the use of emitting events (messages), which can be captured by a test harness or by some other widget in a real application. I'm a bit surprised that this stuff, although part of the Boost C++ library, still has not made it into the C++ standard library. This makes it so much easier to do top-down design but bottom-up coding. It's a more natural way of doing things in my opinion. Focus on the protocol that components use to speak to each other. As long as the protocol lines up and the messages are passed and understood, it doesn't matter about a class hierarchy nearly as much.

I recently worked on a C# code base that had several classes for organization and due to how C# seems to work, was full of circular references. Class A referred to attributes of class B and vice versa. C++ has a means of doing this with partial class definitions and pointers, but compiling is very slow as incremental builds are impossible. I solved that by replacing calls into the other class with an event that was emitted. That way each class could be build independently without knowledge of each other. Of course this requires code outside of both classes to connect them at runtime, but this is a one-way dependency which is totally acceptable. Anyway, it was a neat application of the message-passing ideal of OOP to solve this tricky circular reference problem.
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: The problem with the Object Oriented Programing

Post by Munair »

paul doe wrote:The whole point of stating that 'OOP isn't good' is moot, since it's basically the same thing as stating that 'a hammer is not good'. Of course a hammer is not good to bolt a screw. When people learn how to use a hammer, suddenly everything is a nail...
Bad comparison because a hammer does not make work complicated. Even if it's misused, the problem is immediately clear. But with OOP, especially larger projects get complicated and more difficult to maintain. While OOP was initially marketed as an efficient way of programming (code re-usability) and began to dominate the industry, the reality turned out to be very different. Brian Will explains this very well in a 44min video. But there are also very good articles out there from programmers who were initially very enthusiastic about the promises that OOP would deliver, now explaining the fundamental problems of it.
paul doe
Moderator
Posts: 1730
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: The problem with the Object Oriented Programing

Post by paul doe »

Munair wrote:Bad comparison because a hammer does not make work complicated. Even if it's misused, the problem is immediately clear.
...
Missed the point by miles. A good OO design is no more difficult to work with than a good procedural design, provided the programmer is competent in both.
...
But with OOP, especially larger projects get complicated and more difficult to maintain.
Larger project will get complicated and difficult to maintain anyway, no matter what paradigm you use. This is not exclusive to OOP. I had to work on huge projects, coded entirely in procedural, and they were a nightmare to maintain, not to mention changing requirements. The same with OOP systems. As a matter of fact, I saw no difference when the systems were badly coded.
...
While OOP was initially marketed as an efficient way of programming (code re-usability) and began to dominate the industry, the reality turned out to be very different. Brian Will explains this very well in a 44min video. But there are also very good articles out there from programmers who were initially very enthusiastic about the promises that OOP would deliver, now explaining the fundamental problems of it.
We're well-aware of the problems of OOP now, as the tech was being used extensively for 40+ years. Some advocates of good Object-Oriented design, like Robert C. Martin (Uncle Bob) also explained the problems of it, but also how to solve them (see Agile Programming). As is almost always the case, blindly following the hype bandwagon is not without consecuences.

@c-sanchez: care to explain what the point of this topic is, besides wasting everybody's time?
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: The problem with the Object Oriented Programing

Post by Munair »

paul doe wrote:@c-sanchez: care to explain what the point of this topic is, besides wasting everybody's time?
I don't think this topic is a waste of time. In recent years there has been a growing trend of professionals turning away from OOP and advocating a mix of procedural (imperative) and functional programming. It might herald a fundamental shift in the world of programming (some predict that in about 10 years time, functional programming will become the standard in high level languages). Either way, this topic is quite relevant.
paul doe
Moderator
Posts: 1730
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: The problem with the Object Oriented Programing

Post by paul doe »

Munair wrote:...
In recent years there has been a growing trend of professionals turning away from OOP and advocating a mix of procedural (imperative) and functional programming. It might herald a fundamental shift in the world of programming (some predict that in about 10 years time, functional programming will become the standard in high level languages)
...
Yeah yeah. Where did I saw this before? Functional was one of the first paradigms used (besides procedural), so it is also well-known (and comes with his own set of well-known problems as well! Yay!).

If humanity made any sense, we would all be coding in Lisp and Forth. Every other language/paradigm is just redundant XD
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: The problem with the Object Oriented Programing

Post by caseih »

Actually functional programming is still unknown to most conventional programmers today, and functional languages like Erlang, Haskell, Clojure have remained somewhat niche. How many programmers know how to properly use Monads[1]? That could be partly because academics in the ivory towers look down on real programmers actually trying to solve every day problems using their crude procedural and OOP tools, while in the tower they use their more pure, elegant tools to do whatever it is they do. That said, functional programming languages are getting more accessible, and many languages have added some parts of the paradigm with great success, such as lambda closures, anonymous functions, etc.

I certainly would not argue that functional programming was common practice in the past. It was firmly rooted in the theoretical maths, and although Turing proved it was equivalent to turing machines many years ago, that doesn't mean it was of actual practical value any more than turing machines were. Functional programming has really only become a viable thing in the last couple of decades.

[1] I've read the wikipedia article multiple times and still don't really understand it.
badidea
Posts: 2586
Joined: May 24, 2007 22:10
Location: The Netherlands

Re: The problem with the Object Oriented Programing

Post by badidea »

caseih wrote:How many programmers know how to properly use Monads[1]?
It did not ring a bell here, until I checked the wikipedia page and I thought "Hey, this looks like Rust".
I am trying a learn the Rust language at a slow peace. I bought a paper copy of this book: https://doc.rust-lang.org/book/ch17-01-what-is-oo.html
Currently at 1/3 of the book. I read it to fall asleep quickly :-)

The Monads examples in rust I have seen so far are typically like: Normally (not rust), you have a function that allocates some memory and returns a pointer to it. But, the allocation can fail and a 0-pointer is returned (or worse, some random pointer, ignoring that for now). I you forget to handle the case where the pointer points to 0, bad things can happen. I rust, you are forced (at compile time) to first check if the pointer is valid. But not by like looking at the pointer value itself. You first have to ask 'did you succeed?' with e.g. 2 possible answer 'no, nothing' and 'yes, something' and then (2nd case) you say: 'ok, give me that something (the pointer)'. Note that memory allocation is only 1 example, there are other uses for this concept.

Also, speaking of Rust (and OOP), it is a fairly new language but not really object-oriented. See link above.

So far, my experience with rust is:
- It is a complex language, but interesting
- It has great development tools (cargo)
- The compilation is extremely slow (compared to freebasic)
- The size of the compiled code is huge. My rust folder with 7 examples project downloaded from github is already 4 times larger than my freebasic folder with programs I have written and collected in the last 10 to 15 years (12.7 vs 3.1 GB). And I have not yet written a single line of rust code myself yet!

In freebasic I am still trying to find the right balance between 'warping stuff in types' and 'keeping things simple'. Especially when trying to write games, just to declare some global data can often be so much easier. The problems increase when projects get bigger: In which file did I put what code? How does this thing get information from that other object? So far, everything seems to become a mess after a while whether I try the object oriented approach or not. The cause could very well lie elsewehere.
caseih
Posts: 2157
Joined: Feb 26, 2007 5:32

Re: The problem with the Object Oriented Programing

Post by caseih »

Pretty interesting. You're ahead of me!
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: The problem with the Object Oriented Programing

Post by Munair »

badidea wrote:The problems increase when projects get bigger: In which file did I put what code? How does this thing get information from that other object?
The only thing that helps here is commenting, heavy commenting. I take my time doing that because otherwise after some months or years it may take a lot of time finding and understanding your code. No programming technique, whether procedural, functional or OOP can replace commenting.
Post Reply