OOP vs procedural programming - page 26
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
There's not much to think about.
OOP is a mechanism that allows us to pass a lot of checks and approvals to the compiler. However, we have to spend some extra effort to use it.
But if we don't need all those checks and fits, there's no sense in using OOP.
For example, I would be wary of working with a multidimensional array of graphical kernel - because it has too many unnecessary entities that are not needed at the moment. They are distracting and provoke hard to compute errors. I would replace it with a set of objects, which I would access with simple compact interfaces. By getting an interface - I don't have to remember anything - the interface itself limits me, and prevents me from, say, accessing the wrong field or object. In case of a graphical kernel array, such handling is very possible.
That is, in the case where a block receives an interface, the compiler itself "cuts off" all unnecessary entities and prevents the user from making a mistake. But in case of a graphical kernel array, the user has a lot of unnecessary information where he/she can easily make a mistake.
In my experience I know that I'm much better off when the compiler itself is watching over me to make sure I don't go where I shouldn't go in the current block. And with a graphical kernel array - I have to remember that. The minus of my system is an extension of the plus. If I suddenly need something in a block that goes beyond the current task, with a graphical kernel array it's easy - you just take the needed data and work with it. But with OOP interfaces, you will either have to request the necessary data in an additional interface, or (which is much more unpleasant) modify the existing interface.
There's not much to think about.
OOP is a mechanism that allows us to pass a lot of checks and approvals to the compiler. However, we have to spend some extra effort to use it.
But if we don't need all those checks and fits - there's no sense in OOP.
But why simplify it so much? And what about clarity and readability? And simplicity of error detection and correction? And portability? And ease of upgrading? etc., etc. ....
Well, then the theme should sound different. Something like: "A new toolkit in programming" or "A new programming paradigm"...
If it's true that you created something cooler than OOP, then will you autograph yours when you become famous?
No problem! No expense spared for an autograph for your friends. ))))
You're kidding, but in my imagination, I have such an outlook on this approach that it's a real bummer. It seems that with time I will be able to start the mechanism of self-improvement of the system. If I make a logical kernel and make it randomly generate different mechanisms. Then just do some selection and select the right ones. Then grind them out a little bit... thanks to the kernel, incredible things can be done.
Why simplify things so much. And the clarity and readability? And ease of error detection and correction? What about portability? And ease of upgrading? etc., etc. ....
nice banner ad :-) "buy our elephants."
all these theses are equally applicable to OOP and non-OOP and FP and everywhere else
There's not much to think about.
OOP is a mechanism that allows us to pass a lot of checks and approvals to the compiler. However, we have to spend some extra effort to use it.
But if we don't need all those checks and fits, there's no sense in using OOP.
For example, I would be wary of working with a multidimensional array of graphical kernel - because it has too many unnecessary entities that are not needed at the moment. They are distracting and provoke hard to compute errors. I would replace it with a set of objects, which I would access with simple compact interfaces. By getting an interface - I don't have to remember anything - the interface itself limits me, and prevents me from, say, accessing the wrong field or object. In case of a graphical kernel array, such handling is very possible.
That is, in the case where a block receives an interface, the compiler itself "cuts off" all unnecessary entities and prevents the user from making a mistake. But in case of a graphical kernel array, the user has a lot of unnecessary information where he/she can easily make a mistake.
In my experience, I'm much better off when the compiler itself will keep track of things I shouldn't tamper with in current block. And with a graphical kernel array - I have to remember that. The minus of my system is an extension of the plus. If I suddenly need something in a block that goes beyond the current task, with a graphical kernel array it's easy - you just take the needed data and work with it. But with OOP interfaces, you will either have to request the necessary data in an additional interface, or (which is much more unpleasant) modify the existing interface.
You are wrong to think that there is something unnecessary in the kernel. And it is very easy to remember its entities because they are clothed in human words through defines. Everything is collected there, but this content has a clear and unchanging order. The properties of objects, windows and elements are directly accessible at any point in the program. And what wonders you can do with the kernel in loops...
You are completely wrong to think that there is anything extra in the kernel. And remembering its entities is very easy, because they are clothed in human words through defines. Everything is collected there, but this content has a clear and unchanging order. The properties of objects, windows and elements are directly accessible at any point in the program. And what wonders you can do thanks to the kernel in loops...
I didn't say that "the kernel is redundant", I said "unnecessary at the moment". If I'm working with a graph line - I shouldn't be able to access window properties.
Just the fact that all these properties are directly accessible anywhere in the program is the main disadvantage of your approach. At any place of the program, only those elements that are needed at this point in time should be accessible. Everything else should be unavailable. This - allows you to automatically avoid many errors.
All the "wonders that can be performed due to the accessibility of the whole kernel" are, in my opinion, a potential source of hard-to-find errors and problems of understanding the code. One should try to avoid all these tricks.
This approach reminds me of very silly tasks when pointers, increments and references are written in one line in a jumble which is perhaps correct from the language viewpoint but unreadable at all. I cited my own function above, which also looks absolutely crazy, but I figured compactness is more important in this case.
Well, why simplify it so much? And clearness and readability? And ease of detecting and correcting errors? And portability? And ease of upgrading? etc., etc. ....
Fantastic!
1. Before the oop, we were all constructing everything from Bespoke components with exceptionally complex tools
2. Before OOP, programs were an exceptionally well-mixed compote
3. Before OOP we had NOT heard about data and code localization and it caused terrible maintenance.
4. Data protection between different parts of the same program was a nightmare!
5. Before OOP, no one ever extended systems.
This is a complete failure.
I sit and think that perhaps this very OOP grew out of me because I applied all this back in the late 70-s and many other things relating to the programming culture.
I didn't say "there's something unnecessary in the kernel", I said "unnecessary at the moment". If I'm working with a graph line - I shouldn't be able to access window properties.
Just the fact that all these properties are directly accessible anywhere in the program is the main disadvantage of your approach. At any place of the program, only those elements that are needed at this point in time should be accessible. Everything else should be unavailable. This - allows you to automatically avoid many errors.
All the "wonders that can be performed due to the accessibility of the whole kernel" are, in my opinion, a potential source of hard-to-find errors and problems of understanding the code. One should try to avoid all these tricks.
This approach reminds me of the most silly tasks when pointers, increments and references are written in one line in a mess which may be correct from the language viewpoint but is absolutely unreadable. I cited my own function above, which also looks absolutely crazy, but I figured compactness is more important in this case.
You're reasoning about the kernel based on momentary theoretical notions based on your experience, which has nothing to do with the technology you're talking about. Hence some problems with access, remembering entities...
I'm reasoning from practical experience with this technology, and I'm saying there are no such problems with access or limiting it. Honestly, I don't know what access issues you're talking about at all. There are no such problems and there never have been any.
Please elaborate on what access issues you're referring to.
What makes you think access must be restricted if it would cause errors? This is something new to me.
Can direct access to a global array in a procedure code cause hard-to-find errors by itself?
You're talking about the kernel based on immediate theoretical notions based on your experience, which has nothing to do with the technology you're talking about. Hence some problems with access, remembering entities...
I'm reasoning from practical experience with this technology, and I'm saying there are no such problems with access or limiting it. Honestly, I don't know what access issues you're talking about at all. There are no and never have been any such difficulties.
What do you mean "no problem" when you say "everything can be accessed from anywhere"?
That's the main problem ! It shouldn't be accessible !
The point is to shift the task of access control onto the compiler. Everything is open, and the programmer controls access.
There were no complications because you remember everything. You're used to it now. Well, eventually you'll find that your memory is starting to fail, and then you will appreciate the compiler's ability to control access. I don't remember. And I suspect that most people also periodically forget how something written months ago works. It is in these circumstances that access control becomes a boon.
Let's say if you're inside the block that's responsible for placing orders - you only have the ability to place orders. And you do not have the ability to draw a chart. If you are in a block that is responsible for drawing a chart, you cannot place an order from there. This greatly simplifies the work. And when in the function of chart drawing you suddenly see a request to place an order, you will have to remember for a long time why you did that. It would be nice if there were a detailed comment explaining why this decision was made... But it is better when the orders are placed in a single, dedicated block.
How can there be "no problem" if you say "everything is accessible from anywhere"?
That is the main problem ! It must not be accessible !
The point is just to shift the task of access control to the compiler. Everything is open, and the programmer controls access.
There were no complications because you remember everything. You're used to it now. Well, eventually you'll find that your memory is starting to fail, and then you will appreciate the compiler's ability to control access. I don't remember. And I suspect that most people also periodically forget how something written months ago works. It is in these circumstances that access control becomes a boon.
Say, if you're inside the block that's responsible for placing orders - you only have the ability to place orders. And you do not have the ability to draw a chart. If you are in a block that is responsible for drawing a chart, you cannot place an order from there. This greatly simplifies the work. And when in the function of chart drawing you suddenly see a request to place an order, you will have to remember for a long time why you did that. It would be nice if there were a detailed comment explaining why this decision was made... But it is better when the orders are placed in a single, dedicated block.