The only good OOP code is the OOP code that remains unwritten. That's the OOP code that's really good. 
I will not engage in a discussion about OOP but, I will re-state what I've already said too often: procedural programming can _always_ produce greater quality code than OOP.
Whoever makes categorical statements must prove his point if he wants others to agree with him. So I won't enter into the discussion about OOP, but I will repeat what I have said too often: "how can procedural programming _always_ produce better quality code than OOP"? 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.
OOP is a religion. People just want to believe in it, facts and logic are absent in that realm.
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.
So we, "procedurally-structurally unaware" and "ideologically-religiously blinded in OOP", are waiting for the "thesis" about the superiority of Proc-Struct over OOP to be proven.
...the thing I fear most is a monoculture filled with a bunch of miserable fake choices and irrelevant hype. Kind of like going into a grocery store and there being 20 types of cooked orange juice and no chance of finding fresh orange juice.
For example, for decades in IT, it was a C/C++ monoculture. For some, it was an industry standard, and for others, a monoculture. When standards are abused, they become monocultures. This would not be so burdensome perhaps if the most painful deficiencies and shortcomings of both languages had been removed. However, this did not happen.
Now, for some time now, the Python-JavaScript monoculture has been nesting.
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.
Just like the convention to prefix fields with "F" is a poor idea to mitigate bad design inherent in OOP code and data structures.
It's just a convention in naming identifiers. In procedural-structured programming it's also useful and used.
440bx that Explanation is a bit vague. I know nothing about your code and it would be just as counterproductive for me to ask you how to rewrite all the Lazarus lcl libraries without oop. 
I want to learn more about how you survive without using oop purely out of curiosity.
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?
He has often mixed sensible statements with complete nonsense. In addition, he has an obsession with the abuse of “historical-museum solutions” in the IT industry
This is getting off topic, it was about AI, now about programming paradigms...
Not the first time
Maybe it's because the topic is too general (and broad).
I have a number of problems with A.I, among them:
1. It has no problem solving ability whatsoever.
2. It is unable to evaluate the correctness of the "solutions" it offers.
3. It seems to be little more than a plagiarism engine which, at least in some cases, could have some undesirable legal implications and it does not seem to ever credit the original authors (which, at least by some standards, is unethical.)
4. the financial interests peddling A.I rarely, if ever, disclose the above problems....
I think so too. These are very serious flaws in current AI solutions.
...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
One of the saddest side effects of A.I is that it seems to have somewhat (mostly?) replaced expert systems.
Unlike A.I, well implemented expert systems could not only provide an answer but fully justify the answer by exposing the decision tree that lead to it. Also, a good expert system can learn _but_ its newly acquired knowledge must normally be reviewed and validated by human experts before it can become part of the internal decision tree.
Also, a well implemented expert system could say "I don't know" and show the undecidable points in the decision tree.
A.I does not seem to have any guard rails of any kind. That is not a good thing.
I agree with that. I guess we have to wait until current AI solutions hit the wall, as was the case with previous "AI waves". Then all this harmful hype will die down. And programmers will go back to writing utility and engineering software. Because:
To develop, setup and maintain a serious expert system there is need to invest in knowledge and time.
And the despots currently managing the largest IT companies do not feel like creating useful solutions (concrete tools). They prefer the vague promises of programmers-magicians. Maybe because these despots "don't have knowledge" of the field in which their companies operate.
@TRon, I understand your concern. However, there is no reason to suspect all scientific groups working in this area of dishonesty or a willingness to profit at any cost.
This is not about suspecting pure dishonesty (as sometimes happens in the case of "scrounging up" money for useless junk). This is more about people involved in AI promising (to others and themselves) something that does not exist yet. They hope that they are close to the solution and will soon achieve it. So they are also deceiving themselves. It's more of a type of naivety that leads to unintentional deception. It is a bit like the case of biochemists looking for a cure for cancer, who study various plants and fungi in the hope that they are already close to the final solution. Meanwhile, each subsequent step shows that the problem being studied is much more complicated than it seemed before.
I doubt it. Oop doesn’t work well with copy paste programmers it’s too complicated.
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.
One of the similarities between A.I and OOP, is the extensive use of "prefabricated" blocks glued together. Initial productivity is higher but the quality is _much_ lower. Like a prefab house.
Prefabrication is used in many areas. What is important is the internal details of this prefabrication. Because, as the saying goes, "the devil is in the details.". Not only in AI and OOP. Also outside of IT. And are all AI libraries written as OOP? Or maybe some (or even most) of them are written in C and Fortan?
You criticize A.I as I do but, unlike me, you refuse to see that the reason(s) A.I is being used are much the same as the reason OOP has become popular. It allows people often with limited knowledge to feel more productive, very often at the expense of the final product's quality.
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
Procedural programming like in C is possible to do all kind of programs. Everything so I agree with 440bx.
Objects are just sugar, but I must admit I use objects because I'm used to do that way, but that doesn't mean that Procedural programming can't do anything I do with objects.
Assembly programming allows you to do all kinds of programs. Everything, so I disagree with... Procedures and structures are just sugar, but I have to admit that I use procedures and structures because I'm used to it, but that doesn't mean that assembly programming can't do anything that I do with procedures and structures.
They have no inheritance or virtual methods.
That's precisely why they exist. Inheritance and polymorphism aren't always necessary...
Yes. As in every case, you should not overuse certain solutions. Unfortunately, people overuse them because they either do not understand everything or they do it deliberately. For example, they write a program as a collection of several thousand procedures and several thousand structures. And they could write it as a collection of several ten classes. But no, because OOP is evil incarnate. And then the forums "burst at the seams" with questions about how to use these procedures and in what order to call them.
Recent
