OOP vs procedural programming - page 12
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
How can I use OOP if I can't even fit classes in? I simply don't need them. I don't need structures. It's an artificial division, which is not justified by self-development of my program. Exactly - self-development. There is no other word for it.
So, in this process, the code blocks themselves are divided by necessity which is born in the process of improving them and adding new functions. First, functions are created, and then they are gradually combined into larger blocks, which are polished and updated with new features. Over time, these blocks disintegrate and new blocks emerge. Everything happens naturally. I only "spin" the new functionality to acquire new features, and then grind it down to a quality state. At the same time, the code structure is constantly changing and transforming. I don't keep any clear-cut scheme and everything develops in unpredictable directions. Suddenly, in this process, I find opportunities for a qualitative leap forward. And I make this leap.
That's how my programme evolves. It expands, then shrinks, collapses, and emerges transformed. There are global changes, qualitative leaps, but there are also long-term stable states.
In this process, any unnecessary rules and alien language syntax will only slow things down.
How can I use OOP if I can't even fit classes in? I simply don't need them. I don't need structures. It's an artificial division, which is not justified by self-development of my program. Exactly - self-development. There is no other name for it.
So, in this process, the code blocks themselves are divided by necessity which is born in the process of improving them and adding new functions. First, functions are created, and then they are gradually combined into larger blocks, which are polished and updated with new features. Over time, these blocks disintegrate and new blocks emerge. Everything happens naturally. I only "spin" the new functionality to acquire new features, and then grind it down to a quality state. At the same time, the code structure is constantly changing and transforming. I don't keep any clear-cut scheme and everything develops in unpredictable directions. Suddenly, in this process, I find opportunities for a qualitative leap forward. And I make this leap.
That's how my programme evolves. It expands, then shrinks, collapses, and emerges transformed. There are global changes, qualitative leaps, but there are also long-term stable states.
In this process, any unnecessary rules and syntax with someone else's language will only slow things down.
It might be worth spending a week, though, to sort out the structures. The statement "I don't need structures" looks really stupid. The only conclusion is that you don't know what it is at all.
There are tasks that cannot be solved in an optimal way procedurally.
It depends on what you mean by "optimally" )
As far as I'm concerned, OOP is just a convenient wrapper, not a solution to any problems. That's why the argument is at a standstill here.
On the whole everyone seems to agree that any task will be solved much faster and more compactly using structured-procedural approach. And more time is spent on wrapping into classes than on coding itself. Sometimes you get carried away, mess up a bunch of classes, and then think, why bother with it all...
One more thing about "procedural programming with function pointers" - why should it be put in a separate category? I think function pointers are just a structural-procedural style.
It depends on what you mean by 'optimal way' )
As far as I'm concerned, OOP is just a convenient wrapper, not a solution to any problem. That's why the argument is at a standstill here.
On the whole everyone seems to agree that any task will be solved much faster and more compactly using structured-procedural approach. And more time is spent on wrapping into classes than on coding itself. Sometimes you get carried away, mess up a bunch of classes, and then think, why bother with it all...
One more thing about "procedural programming with function pointers" - why should it be put in a separate category? I believe that function pointers are just structural-procedural style.
Polymorphism is in no way feasible by procedural means, except for function pointers. OOP is definitively polymorphism, while in procedural programming there are not necessarily pointers to functions.
One should not wrap everything into classes.
Shouldn't we spend a week at least dealing with the structures? The statement "I don't need structures" looks really stupid. The only conclusion is that you don't know what it is at all.
Structure is a self-explanatory thing. It combines a named set of variables of different types. The main type in my program is int. I use double only in a few places. string only in one particular block.
Why do I need structures in the context of OOP?
I have one structure that belongs to the kernel. That is, the structure of the kernel itself within it. That's all I need.
The structure is self-explanatory. It combines a named set of variables of different types. The main type in my program is int. I only use double in a few places. string only in one particular block.
Why do I need structures in the context of OOP?
I have one structure that belongs to the kernel. That is, the structure of the kernel itself within it. That's all I need.
You must have been writing one program for yourself for three years.
You can, but with different efficiencies of operation. Support is not the issue here, it is too relative.
There are tasks that procedurally you can't solve in an optimal way.
I'm a supporter of OOP, but in fact, the processor knows nothing about the existence of OOP, it can execute machine code, that's all. At the dawn of the computer they wrote programs in this way, directly in machine code.
That is why there were so many women programmers. Because men would get drunk and go crazy because of this work).
After all, agree - it is the efficiency of the solution that counts.
Overloading of syntax and complexity of rules has never contributed to keeping solutions efficient. It was simplicity and brevity expressed in conciseness, universality and readability of code blocks that helped.
And what is meant by efficient solutions?
My programming rules are: less code, less rules, less syntax...
I'm not a fan of OOP.
But in terms of maintainability, scalability and ease of use by third parties, what TC (Peter, not Karputov) is pushing is just stone age.
I have a strong opinion that every programmer should work in a team, ideally more than 4 people, just to understand that efficiency and universality of code does not mean that this code is good.
I am a supporter of OOP, but in fact, the processor knows nothing about the existence of OOP, it can execute machine code, that's all. In the early days of the computer, that's how you wrote programs, directly in machine code.
That is why there were so many women programmers. Because men drank a lot and became crazy because of this work.)
What of it? So far one conclusion is that at the beginning you had to write a lot of programs in machine code))