OOP vs procedural programming - page 40

 
Andrei:

Exactly, from a specific person. Why would a programmer who is not suffering from schizophrenia strenuously hide access to some part of his own code from himself which he is debugging? Wouldn't you rather tie your own hands? :)

Well, as I said, try working with the structure file that Peter gave above. "Fetch" the data you need from there, and then put it back in the right place.

And compare it to getting the data you need from a "trimmed" interface that gives you a tiny bit of the same structure. With an interface, there's simply no way to get something else, or to write something "wrong".

No, it's understandable that if you're a titan of memory with atrophied forgetting ability - then you're lucky, and you don't need OOP. But not everyone is so lucky.

SanSanych offers to replace OOP by documentation - in principle, it is also an option, in fact, it is much closer to the structures proposed by Peter. But with Peter all documentation is "in mind" and with SanSanych - on paper (or on electronic media).

 
Andrei:

I wonder what this "horror" is.

By the way, Renat Fatkhullin, it would indeed be interesting to look at examples...

 
George Merts:

No, it's understandable that if you're a titan of memorisation with an atrophied capacity for forgetting, then you're lucky, and you don't need OOP. But not everyone is so lucky.

So, SanSanych suggests replacing OOP with documentation, which is also an option, in principle, much closer to the structures proposed by Peter. It's just that Peter's documentation is "in mind" and SanSanych's is on paper (or on electronic media).

The meaning of a variable must be known in any case, but it is not necessary to remember - you can write a comment if the context is unclear. It seems obvious.

With OOP you have to remember and document much more, namely, what is created and destroyed when and at what moment, through which interfaces flows at what moment and other absolutely useless for the final result mouse fuss - just from that alone any sane person can go crazy and break his brain.

 

By the way, to all opponents of OOP - it would be good to remember the times when programs were written in assembly language.

And in particular - working with files using BIOS and DOS.

To my mind, the difference between procedural and OOP approaches is just the same as in disk handling with BIOS and DOS tools.

Both BIOS and DOS have all the functions needed to work with the disk.

However, creating a file with BIOS features and writing "Hello, world !" there is quite a big problem even for FAT drives. I used to do it on a bet, and it wasn't easy for me. In DOS it's easy to do with just one function.

I can imagine how difficult it would be to create such a file for NTFS system using BIOS...

 
Andrei:

Read carefully, it's about the class, not the class constructor.

In addition, you again suggest to make a monkey's job - to plant a field on a plot, if we can have access to parameters without doing ANYTHING in case of external variables or passing them directly, without any unnecessary headaches with constructors-destructors and all the attendant memory leaks.


Yeah, I need to get in and you're showing me the door here. You probably don't know what a class constructor is.

Just general parameters - they are already visible inside the class, but using them is not good, OOP is good for the ability to escape from the common space.

And directly how? If not through a door, then a wall? Through the constructor is just like passing directly. You can pass parameters immediately when creating an object, even without new. So you are too lazy to describe the parameters the class must accept? Aren't you too lazy to write functions and declare variables?

You obviously haven't understood anything I've written)).

 

Dmitry Fedoseev:

Aren't you too lazy to write functions and declare variables?

You have to write functions and declare variables everywhere and in OOP too. Only with OOP there will be much more fuss with it, and that is if you foresee in advance everything prophetically, what will be the data structure at the end of the project, so that you don't have to rewrite it a hundred times. It seems obvious.

 
Andrei:

You have to write functions and declare variables everywhere and in OOP too. Only in OOP it will be much more fussy, and that is if you foresee in advance everything prophetically, what data structure will be there at the end of the project, so that you don't have to rewrite it a hundred times. It seems obvious.


It's more of a hassle, but there are plenty of cases where it's worth it. In general, it is not fatal.

 
Dmitry Fedoseev:

It's more of a hassle, but there are plenty of cases where it's worth it. It's not fatal in general.

You know, when it's worth the trouble - when you pay by the hour, because then the more fuss the more profitable. :)
 
Dmitry Fedoseev:

How long have you been working on this library of yours?

Two years of uninterrupted work.

The GUI kernel (by the way, there is also a proto-kernel containing prototype elements. It occupies 2 megabytes. It consists of such tables as the one I've cited) and contains thousands of variables. Do you think if I didn't use the kernel as a centre and scattered variables over classes and structures and set up communication between them via various access restrictions, I would have coped with my task? - Never on my own. I would have multiplied the number of entities in my program. The links within the code between functions and classes would become so complex that I simply wouldn't be able to continue working on my own. The efficiency of the whole mechanism would have plummeted.

I would have reached my limit much earlier and stopped.

Many times I asked myself "what would I have achieved if I had used OOP?" and each time, based on daily practice, I realised that I would not have been able to go that far on my own.

Also, my thinking is structured as it is and therefore I have no need for OOP in this regard.

 
Renat Fatkhullin:

For the sake of glee - R is written in an absolutely disgusting "all in one garbage can with no differentiation of access" mode. An old-school approach from twenty years ago with no areas of visibility, protection or multisession. I write as if I were the only one. Yes, the project was born under one person by unprofessional developers. It must be rewritten from scratch. At least once.

I had an idea to make a normal interface in R from MQL5, but after digging deeper into it I immediately decided not to integrate it. The system is categorically unable to protect data and sessions.

Until a programmer works in normal development teams with strict requirements (banging his hands for a couple of years at least) he will not become a developer in a normal sense. We grab our heads 90% of the time when we look at test jobs when considering candidates. Total horror throughout the development industry.

So once again - the opponents of OOP are displaying some sort of buffoonery here.

Sorry again.


Renat, please don't be nervous. I'm not a supporter of R myself. You are an excellent manager and programmer, don't take shouting from the forum to heart.

I wish you and Rashid and your team good health and creative success!