OOP vs procedural programming - page 22

 
Nikolay Ivanov:

The fact that all modern systems use OOP is not proof of superiority ? You're just not ready to understand, you ask simple questions and can't take a complex answer... and you think there is no answer... Well that's not right...


The mindset changes, yes, and at first it seems like what for? But when the project becomes a lot of thousands of code lines, you begin to reap the benefits)) and understand why and for what it was all for).


If a project is difficult and expensive to maintain and update, and expensive and expensive to extend, and another one is quick and easy, the first one will die - it is a natural selection.

There are many thousands of lines of code in my program too. The lack of unnecessary entities is a salvation for me. I couldn't have developed it any other way. It's the purest practice.

But enough of that. I am leaving this thread.

 
Nikolay Ivanov:

1. the fact that all modern systems use OOP is not proof of superiority?

2. You're just not ready to understand, you ask simple questions and can't grasp the complex answer... and you think there is no answer... That's not right.


When your mindset changes, yes, and at first you wonder what for. But when the project becomes a lot of thousands of code lines, you begin to reap the benefits)) and understand why and for what it was all for).


If a project is difficult and expensive to maintain and update, and another is quick and easy to extend, the first one will die - this is natural selection


1) Everybody here is so cool, that it will not prove to them, but on the contrary, that they are all so cool of themselves, and all around are sad suckers - they fell for OOP.

2. very anecdotal, but they don't realise it.

 
Alexey Volchanskiy:


Similarly to this topic )) A long time ago I subscribed to Popular Mechanics magazine, there was a page of humour

Leo was on the warpath one day. So he's walking along, all blatant. He meets a fox. Fox, quick, who's the king of beasts?

- Leva, of course you are!

Satisfied, he went on.

He met the hare, the same result.

Met the elephant. And the elephant was hot, he just waved his trunk from the flies and the lion flew away.

And you know what he said to the departing elephant, sitting in the bushes?

- And don't get mad if you don't know the answers.)


About the hedgehog:

"The hedgehog is standing in the clearing, posing, flexing his biceps: - I'm strong, I'm brave, I'm agile, I'm strong, I'm brave, I'm agile...

A bear walks by - kicks him once, the hedgehog flies behind the tree, gets up and shakes himself off:

- I'm strong, I'm brave, I'm agile... But I'm easy...

 
Реter Konow:

But enough about that. I leave this topic.


The fact that you do not trust others and want to understand for yourself is even good, others may be wrong, some things are easier to get to yourself


Dmitry Fedoseev:

1. Everyone here is so cool that this will not be a proof for them, but rather a confirmation that they are all so cool of themselves, know how, and all around sad suckers - fell for the PLO.

2) Very anecdotally, but they do not realize it.


))) It's funny how people who don't understand a lot sell Market Expert Advisors for $10K or signals with 2k subscribers and get really big money )

 
Dmitry Fedoseev:

This is not the main argument.

There is no analog of polymorphism in procedural programming.

How is it not there, if you yourself several pages earlier mentioned function pointers? This is the very analogue of polymorphism, and with much wider possibilities, because you can change it dynamically.

 

Looks like you missed the chatter :-) the moderators have clamped down on flaming topics ... but here it's OOP vs.

By the way, 99% of @Peter Konow's uses OOP, but he's not aware of it :-) OOP is not necessarily "class & template"

and vice versa too...the presence of objects and classes in a program is not indicative of OOP

 
Alexey Navoykov:

How not, when you yourself mentioned function pointers a few pages earlier? This is the very analogue of polymorphism, and with much wider possibilities, because it can be changed dynamically.

That was yesterday, while I had a better opinion of the opposition. Pointers to functions in MQL have recently appeared, but today it turned out that for all the arguers they don't exist at all. Turns out they don't know what they're arguing about at all. I'm sure they just missed the words"polymorphism" and "pointers" in their eyes and ears. They have only one argument - "you haven't cited any proof", even if they see 1000 proofs here.

You can change pointers to classes dynamically too, the only thing simpler with functions is that you don't have to create them first.

 
Реter Konow:

By solution effectiveness, I mean the quality of the solution at which the mechanism - and software is undoubtedly a mechanism - will work in the most stable way. The mechanism must be clear, coherent and productive. The functionality of the engine should implement all the tasks assigned to it. The mechanism does not accept the superfluous and in the development of this mechanism, the superfluous should be cut off.

Only in your case this "unnecessary" is type control and other fundamental things that are meant to protect the code from accidental programming errors. That's why your code becomes very unreliable. There is no stability whatsoever. Even if you have debugged it now and cleaned it up, but further modifications will cause hard-to-find errors that are very hard to clean up.

 

There is no doubt that OOP contains a lot of additional tools that a developer can use. However, one should understand the price to be paid for using these tools. Namely, you should immerse yourself into the OOP paradigm and code structuring corresponding to it. Using the whole OOP toolkit and creating many objects. The main price is in the sharp complication of the code. However, practice shows that from the viewpoint of efficiency of the created mechanisms they should be simple and the presence of any entities in them should be absolutely proved by increase of efficiency and nothing more.

 
Alexey Navoykov:

Only in your case this "extra" is type control and other fundamental things designed to keep your code safe from accidental programming errors. That's why your code becomes very unreliable. There is no stability whatsoever. Even if you have debugged it now and cleaned it up, but further modifications will cause hard-to-find errors that are very hard to clean up.

It may be. We'll see. So far there have been no such difficulties.