I'm asking for proof. It can be direct or indirect, it can be inductive or combinatorial or experimental in a laboratory. It doesn't matter. As long as proof is presented.
Great !! ask and you shall get. My only concern is that is off topic in this thread. I invite you to create a new thread for that purpose.
Also, so that you are not caught by surprise, the way I intend to prove it is by comparing parts of the code of ZydisInfoC to whatever OOP version, you or anyone else can produce that is at least as easy to understand and maintain while not using significantly more resources.
IOW, I present non-OOP code that I've already written and challenge you or anyone else who cares to participate to either do as well or better with OOP.
I state that neither you nor anyone else will be able to produce a result of similar quality using OOP.
For the record, ZydisInfoC is just POC code. I could improve it quite a bit but I submit it as-is with complete confidence it will not be matched using OOP.
Suppose I were to write such code. And let's also assume for a moment (purely hypothetically, just for the purposes of case study) that this program written as OOP was slightly more efficient than the one you wrote procedurally-structurally. What would that prove? Well, nothing! What's an experiment based on 2 cases worth? Any statistician would laugh at that. Such experiments would need to be performed on many different programs, performing different calculations and using different data structures. Comparative research must be carried out on a sample of such size that it is representative of the population under study. Then you can try to prove something.
However, statistical issues aside, this is still wrong thinking. Let us now take a case where we compare two programs, written in a procedural-structural way, which they:
- perform the same tasks,
- are not trivial programming exercises (e.g. calculating factorials or solving quadratic equations),
- were compiled with the same compiler (language, version) and run on the same OS and computer (identical experiment conditions),
- are written by different developers (so they have different implementations and may use different data structures).
There will probably still be a difference in speed and memory usage. On the surface, there is only one factor: the developer. But these developers can:
- use different data structures,
- arrange instructions in the program differently,
- have different knowledge and experience and this will translate into the quality of the code.
So there are actually 3 factors, not one, that should be considered in this type of study. Now let's go back to comparing 2 codes written: procedural-structural and OOP. There is a 4th factor in this situation: the difference in the programming paradigm. But the 3 factors mentioned earlier will still affect the differences in the code. How to test this? You can use multifactorial analysis of variance. But then we won't get an answer that one paradigm is more efficient than the other. Only such an answer that (for example) there is an interaction between factors 2 and 3 and 4 or 1, 2 and 4.
Now let's go back to the comparison of proc-struct vs OOP paradigms. OOP is used in various programming languages, sometimes designed completely differently, operating in different environments: CPU (C++, Object Pascal), VM (C#, Java) or interpreter (Python, Ruby). There is a big difference between them in the OOP implementation itself. In addition, there is a big difference in the execution environment. Therefore, the concept of OOP itself is so broad and fuzzy that it can only be discussed as a concept. But the differences in implementation are too big to completely exalt or completely condemn this concept. It's these details that are important (even crucial). The concept of OOP itself is secondary. All the more so because you can emulate OOP even in C (without too much code bloating, although this is "ploughing on a stony field").
OOP is a religion. People just want to believe in it, facts and logic are absent in that realm.
I fully stand by what I said.
And I maintain my opinion that such statements are just drivel laced with ordinary obsession. But… I have nothing against it. Everyone can have their own opinion, even if it is an oddity (provided that it does no harm to anyone).
The lack of proof will mean that all this talk like "OOP is a religion" is just blabbering nonsense and has nothing to do with facts and logic.
I like a proof-man, now prove me wrong. Show me an OOP version of ZydisInfoC that improves upon it.
Otherwise, you're just preaching what you believe while failing to provide a foundation for it.
I'm the one who has to prove that your statements (or rather: opinions) about OOP are nonsense? You're the one who brought them out. I just asked for proof of your claims. Nothing more. I did not put forward any counter-thesis. So why should I prove anything?
"The "private", "protected", etc are just crutches needed by OOP to accomplish what decently designed code accomplishes automatically.
How does he achieve this? Proof please. Otherwise it's just bullshit.
You're the OOP man. Show me how you use use that stuff to improve upon my code.
I can be an "OPP man". I have much bigger flaws. For example, I "ungodly" criticize a certain "important" open source project
So being an "OPP man" is not so bad
It's just a convention in naming identifiers. In procedural-structured programming it's also useful and used.
I might have missed it but, I've never seen non-OOP code _blanket_ prefix local variables with "F". Prove me wrong, link to an example of non-OOP code, created more than 2 years ago, that uses that.
Who said it has to be the letter F? It can be another letter. For example, it can be "scarlet A
As a well known programmer says "talk is cheap, show me the code"...
Is it really a good idea to refer to THIS programmer's statements?
Yes, it's good idea because he's got a point.
Now, I'm going to paraphrase you and him: The proof is in the code.
I've seen all your criticism, now show me the code/proof.
Depends when. Sometimes he "speaks nonsense".
...On the contrary, they seem to purposely ignore/cover them up (they have that in common with some OOP proponents.)
That what are the so-called "OOP advocates" hiding? That they are reptilians? And they "shove OOP down the throats" of poor procedural-structural programmers
What some (I should say "many" but I'm going to be kind) OOP proponents work really hard at sweeping under the rug is the loss of quality due to OOP.
E, worse. OOP supporters give bribes to anyone who is not yet convinced of OOP. And if such a programmer does not want to use OOP, they scare him that they will kill his hamster or fish, using a cat
That loss is evident in the larger executable size, higher use of resources (memory, CPU and O/S related) but not only it is often conveniently ignored but sometimes even denied. Not to mention code that is much harder to maintain due to the gross abuse of polymorphism and exceptions. OOP really is like religion, if you ignore all its problems then it's great. Hallelujah or it alleluia ? if Sender is Hallelujah then ...
But if only procedural code is "stuffed" into the executable file, the files are always small? Even when the code consisting of 100 procedures grows to 1000 procedures? What magic
In OOP the copy/paste method "graduated" to inheritance which is one of the reasons OOP programs are much bigger than a reasonably well designed pure procedural program.
Such a statement rather shows a lack of knowledge about how inheritance in OOP is implemented (at least in Object Pascal). There is no "copy/paste" here. So Joanna is right.
Sorry... nope, you and Joanna are both wrong. I didn't state there was copy/paste going on, I said there is inheritance going on which can be a lot worse than simple copy/paste.
OK, I was wrong. You said even more nonsense
Using libraries that use only procedures and structures (e.g. WinAPI, libc, LAPACK, etc.) "allows people with limited knowledge to feel more productive, very often at the expense of the quality of the final product.". That's why programs should be written only in assembler, written only by yourself
with that and the Assembly comment you got your "need to get silly" fix out of the way
In fact, it is most correct to write the program directly in machine code
Start a new thread, show me I'm wrong about OOP.
As the well known programmer said: talk is cheap, show me the code.
I won't do it on purpose so that you continue to be wrong
Recent
