PureBasic Forums - English

Further to OOP discussions!!

https://medium.com/@cscalfani/goodbye-o ... .lbs3rlwp0

Well, this was one uninformed article...

The author is looking for obvious "problems" and then tries to show case them,
forgetting the fact that nobody is using it that way. I'll just address a few points
and give my thoughts on them:

Inheritance
Inheritance is an extremely powerful feature designed to solve specific problems;
and these aren't the problems the author is showing. Overusing inheritance is a
rookie mistake that's eventually going to bite them, both performance-wise and conceptually.

Instead of using deeply nested inheritance structures, one uses composition and delegation.
Combined with dependency injection, the "Banana Monkey Jungle Problem" can be solved as well,
leading to maintainable and especially testable code.
However, the author seems to forget that a class is nothing more than a structure and the
procedures manipulating that structure. So in a PureBasic scenario, if you are going to use
procedure A() that is calling procedure B() which in turn is calling C(), of course you have
to XIncludeFile all previous procedures as well. There is a reason it's called dependency.

The Triangle "Problem"
This is not a problem but a logical consequence. It cannot work properly in most cases
and is thus not used. The way you'd solve the PoweredDevice / Scanner / Printer / Copier
problem is through composition, not inheritance. In contrast to the authors "solution",
you'd use dependency injection again and not instanciate the objects directly.
Most modern languages don't support multiple inheritance as it is simply not needed.

The Fragile Base Class "Problem"
Now, I don't know what the author expected. This is exactly why unit tests should be used.
A simple unit test would have caught that error immediately and notified the author
that he is introducing a breaking change that has to be addressed before the code is
committed. Again, to bring this to a procedural style: If you have a structure S and procecdures
A() and B() that operate on that data, you will experience the exact same problem if you
introduce this change in B().

The Hierarchy "Problem"
There is no problem with hierarchy, it is the problem. Properly structuring application code
is difficult, and parts can't simply be put into "folders". Also, the rumor that OOP is designed
to model the real world is something that comes from beginner's books that try to teach
the basics of inheritance with things like Animal -> Cow / Horse. It's not that easy.


Encapsulation
Again here, same "problem" with non-OOP languages. To solve this, code contracts and
invariants are applied. The component which breaches these contracts is not working
properly and must be fixed. Regarding copying: CPUs are pretty darn good at copying,
it's basically what they are designed to do (fun fact: the x86 mov (i.e. copy) instruction
is turing complete. Google it, if you are interested).


Polymorphism
I think the author is referring to inclusion polymorphism, i.e. subtyping. I'm not really
sure what he is trying to say in this paragraph. You don't need object orientation for this
because polymorphism can simply be function overloading or generics. Implementing
such functionality through interfaces is exactly how it works in OOP languages. The
author said this feature is not a problem so why would it be a problem of OOP?


Broken Promises

And these promises are still being made to naive programmers sitting in classrooms, reading blogs and taking online courses.

I agree. However, the problem doesn't lie with OOP but with the classes and the students. It takes a long time to get proficient at programming in whatever language or paradigm you're choosing. Programming is hard.


Functional Programming
Wow, that was anticlimactic. Just a single buzzword with now explanation on why it is better.
Probably because it isn't better because it is different. It all depends on the type of application
you're creating. Functional programming is indeed great, but that doesn't mean that other
paradigms have no purpose anymore. Using the strengths of each is where the advantages
are. I personally love to combine object oriented concepts with functional concepts, and
this is exactly the direction where the big OOP languages (i.e. C++, C#, and Java) are headed.

Just some thoughts.

In a nutshell, abstraction is the boon and bane of OOP.

Yes, just as the flexibility and lowlevelability (:lol:) of C++ is also its weakness
or that you can hit yourself in the thumb with a hammer head...
wouldn't wanna bang in those nails without it, though.

TI-994A wrote:In a nutshell, abstraction is the boon and bane of OOP.

lol i think you nailed it, because it seems people either love the abstraction or hate it - seemingly with very little middle ground!? me I hate OOP because it acts as OBSCURITY between the source code and the resulting asm (i know obscurity isnt its purpose but its still an end result, and it doesnt seem to be an obscurity that provides security against crackers either), whereas with procedural everything in my world just makes sense, lol. Also all the overhead with classes and destructors and constructors and stuff ... I just wanna get from A to B but not via C++! Really great work to the coders who've written routines to bring some level of OOP to PB to make their personal coding more comfortable for them, but with all due respect i'll stick to purely procedural PB thanks, as it's just what makes the most sense to my head and allows for the smoothest coding. Each to their own of course!

Tool support is the most used "feature" of OOP.

With tool support You get help inside of an IDE/editor.

So, entering "Hello, world!". (dot) would show up a list of possible things to do with the string.
Of course, very often that does not work with a literal (btw, why?).

I don't know if that is a lot of help as I also work with JavaScript without auto completion.

Very often, that kind of "intellisense" (Microsoft) does support 'hacking' instead of programming...

The only reason why OOP exists is to protect stupid coder from himself. Another reason is to speed-up commercial program stamping, so some monkey sitting in office can bring more shit than always for same price, and even not shoot off his legs and other parts while doing this ^^

And yes, I thinked similar way even when coded in OOP myself, which was far before I liked PB and C. Just in past was too lazy and not enough skilled to write true clear code and real projects without OOP, for example that Chipmunk in pure C. (btw I really enjoyed much while was learning it's sources, they are just great and like true piece of art [lol]. Concurrent engines written in C++, like Box2D are not even close and never will be, nor for code/architecture beauty nor performance and other working params).

The same with other OOP I've seen and used in past (vb, java, .net), they are totally ugly even comparing with C++. I can't even call that or some web-stuff "programming", it's closer to writing some kid scripts.
And it is ridiculous, but by fact they are despised "BASIC" languages in 2016 -- not something like PB with pointers and relatively low-level stuff, requiring enough knowledges to do something more or less complex good, or at least working stable.

However, I still like the idea to add "class modules" to a PB ^^
Because their concept introduced in VB is really cool and makes lot of things clearer, without allowing you to relax and get drown in true POO.

So you basically want OOP support for PB...*facepalm (?)*

Shield wrote:So you basically want OOP support for PB...*facepalm (?)*

It is already present far ago, I just like to see it usable and practical, not like some interfaces with VTables (which is even worst and more dirty than C style, using only function pointers/prototypes and structures. Currently I'm using that C style in my stuff if need some OOP, but "class module" concept would be really much better to be supported by compiler).

Sure, but what I don't get is why you're saying all modern languages are "ugly" because they are
using class based object orientation while at the same time wishing these features for PB.

The triangle problem could be easily resolved by using something like this.
But of course it's better not ever to use it and design new languages exactly like the old ones, so that they'll inherit the problem as well...

Shield wrote:Sure, but what I don't get is why you're saying all modern languages are "ugly" because they are
using class based object orientation while at the same time wishing these features for PB.

The code of those languages becomes ugly because they are forcing OOP usage everywhere, and in most cases this really makes code extremely ugly and unclear. Why the **ck some damn temp string must be used as a separated class? Or why I should declare another damn class just to have entry point to my program? What idiot ever wished to make his life so much more complex on level ground? Because of some Strousasshole proclaimed so, to allow army of "professional" codemonkeys not to shoot off their legs trying to produce something in C?

Athough If OOP used wisely and rarely, only when it is really needed and is better than messing with structures on low-level (neural networks, some complicated stuff to work with graphics, or some subsystem of in-game logic, etc), it is OK.

But the only language where I've seen such cool balance keeped was VB6 (most of code writen on it for all time is done in procedural style, and classes used only when it was needed to make several instances of object, etc, where OOP is justified). Nothing stopped developers to use classes in all other cases, but they almost never doing that, just because procedural code is much simplere and clearer in almost all cases (both your code and someone's else).

Thus, the only form of OOP which can be "not ugly and bureaucratic" and even becomes very helpful, is dramatically limited and pared down OOP support, like those "class modules" in VB6 ^^ Any of mentioned things (neural networks, so on) can be done on it with full comfort, no higher level of POO support is required.
And Purebasic is just in one step of this, as It already has necessary functional, just still won't give handy way to use it, like well-designed VB6 provided.

And surely there are no well-known modern languages declared as "OOP" doing things this way. They are in better cases OOP-languages with partial support of procedural programming, not the "procedural languages with wisely limited OOP". So obviously, it almost always results in very ugly code written using them. Recently I've learned Tesseract sources (C++) and just tired of never-ending and intersecting class bullshit I've seen inside -- despite the fact that it was written by good coders from Google. It is much more painful to read classes-based code from some average OOP-monkey, even if that code will be much smaller and simplier by main functional. Nothing close to any of large C project code I've seen.


PS. Seems that I have nothing to do today, if sitting here and writing so long posts ^^

Derren wrote:The triangle problem could be easily resolved by using something like this.

That doesn't solve the problem. Consider the classes Animal, Rabbit, Antelope, and Jackrabbit,
where Rabbit and Antelope inherit from Animal and Jackrabbit inherits from both Rabbit and Antelope.

According to the substitution principle, you must be able to do this:
@Lunasole:
These programs are "ugly" because they are huge and complex. OOP is one of the most popular paradigm nowadays
because it is the best attempt at solving maintenance nightmares. There is a good reason why not all software is written in C.

Shield wrote: There is a good reason why not all software is written in C.

Surely, and I've mentioned it already -- because most of coders are true codemonkeys, having no ability to write something more complex than helloworld without shooting off their legs. It is of course too dangerous to gather 20-30 such monkeys into single team and give them C (also paying lot of money) ^^ In such cases even if there are a good coders in team, they can't do anything, because monkey will come and break it all. That is a reason of OOP birth.
And here come OOP, all is isolated, monkeys playing with their child tasks in separated classes and all rescued.

But what is the point of that OOP bureaucracy for a coder who doesn't work and doesn't planning to work in such typical monkey-teams? (or for a small coder teams?) You like to make your life harder? (me like for example, but not in such stupid ways, lol)


Also, there anyway are in 2016 ways to organize coding wisely without any OOP. So it was actual maybe up to 2007 or about it, now it is useless for it's main purpose, because there are svn and all such stuff doing the same with less beurocracy and code writing overhead. And other aux tools evolved greatly too, for C there are lot of static code analyzers, advanced debuggers, IDES, kind of purifiers and so on, which may be easily bought and used if writing on it professionally. It's pretty easy to be a C coder nowadays and write stable soft on it.

> These programs are "ugly" because they are huge and complex.
No, they are "ugly" right because they are done in OOP. Go and read several C projects and compare then their code to alternatives on C++ and maybe then you will get what I'm talking about.