A: But much of the OOP stuff distracts from Table Oriented Programming and other possible approaches. I don't think it is realistic to try to make a programming language be everything to everybody. The language becomes bloated, hard to learn, and hard to read if everything plus the kitchen sink is thrown in. However, I would not mind OOP features in a TOP language, as long as OOP does not get most of the attention by the compiler and language makers.
A: The current relational table model can already handle large objects using a familiar construct: a file. A field in a table would store the name of the file that contains the large or multimedia object. This file "object" is free to expand to whatever size it needs. Perhaps a good TOP system would have built-in constructs to automatically assign unique file names when a record is created and to automatically delete the file when the corresponding record is deleted. There are plenty of ways to use or improve existing wheels instead of inventing new, untested ones like OODBMS. (I don't mind experiments, just don't make the whole industry the Ginny pig.)
A: In the short term, these tools may be helpful. However, what happens when the wizard or component vendor goes out of business, releases a buggy product, or stops supporting it? Also, what happens when you need to modify the code generated by the wizard? Wizard code is rarely easy to maintain because it needs to be general purpose, and thus has a lot of conditionals that your project will never use. Wizards and add-ons may supply instant gratification, but delay the inevitable. Some add-ons are a necessity in many cases, but the fewer the better. Also, add-ons use API type syntax. Sometimes common features should be built directly into the language syntax. Some features, like evaluate-able expressions (strings) that can reference internal variables and functions cannot be provided by add-ons and API's if the root language does not support it. (Click here for more syntax examples.)
A: It would of course be impractical to include EVERY programming construct in a language. Thus, when building a language, one should rank the usefulness of constructs and only include a realistic subset of all possible constructs. I perhaps would not mind OOP constructs in a general business language, but OOP is permeating more than just language constructs. Almost all new add-on's and utility libraries are written in OOP, whether OO is the best way to do the particular operations or not. The vendors do it because in the mind's of many, "OOP = modern". Focusing too much on OOP tends to lessen support for other approaches.
A: True, much of it is a philosophy. But, the OOP philosophy is not always the best philosophy for many types of applications (See "OOP's Niche" above). Also a language philosophy dictates the built-in functions and operations provided. If neither the syntax nor the built-in functions are optimized for what you are working on, then you are wasting a lot of time.
A: True, many OOP languages can detect more of certain problems at compile time than other approaches. However, there are tradeoffs in this, and many of what it helps rely on suspect OO practices like dividing things into mutually-exclusive sub-categories (sub-entities).
The debate about compile-time binding versus run-time binding has long raged in computer science. Compile-time binding offers more protection from programming boo-boo's, but generally offers less flexibility than run-time binding. Note that there can be "Lint-like" utilities that check for suspicious operations in script-like languages. Commented markers could also be used to indicate "safety features". There is a lot that was never really explored or promoted in this area. Perhaps because it is not the huge problem that OOPer's make it, at least not compared to more practical problems.
A: I think Expert Systems and CASE are better comparisons. However, structured programming is relatively easy to verify, and thus easy to enforce. Bad OOT is hard to tell from good OOT without understanding the application domain (business) being implemented. A ten-minute glance at OOP code will tell you very little about OOT misuse and planning.
See also Goto Lessons.
A: You assume that it is a natural step in some sort of programming evolution. However, even if one accepts your claim that OOP is a "natural step" (we don't), there may be a point of diminishing or no returns. Eliminating GOTO's was at a base level. It is roughly at the level of going from assembly language to FORTRAN.
Just because some "forced structure" works, does not mean that more forced structure will progressively work better. Some iron in your diet is good; too much is poison.
You cannot extrapolate going from the simple to complex into going from complex to more complex. I believe that beyond a point, all the spanking, prevention, and protection mechanisms start to confuse and/or bloat up the code. Also, good design comes mainly from understanding the topic and predicting where change is most likely to happen, not from making more programming rules that are blind to the outside world and that can be bypassed anyhow. OOP cannot serve as plug-and-play organization nor plug-and-play discipline.
I would have to see side-by-side code examples to be convinced.
A: Common where? Goto's used to be common. Some concepts may indeed have good intentions behind them, but that does not necessarily make them better. Good design is about balance, not taking a specific something and running away willy nilly with it.
A: I think that the application type is more of an issue. However, for anything to succeed in the real world, it must do just that: succeed in the real world. In other words, the best rocket science is of no use unless people are actually going to use it properly. If proper training is not going to happen, then investing in OOP may be a waste and a distraction. After all, car makers have to make their cars based on how people actually drive, not how ideal, properly informed drivers drive. Wishful thinking brings nothing. Computer Scientists often forget the "people factor", which is more important than an (allegedly) good technical idea in many cases.
A: I am the product of the same education process that most of the other programmers out there get. Most OOP books focus on GUI's, shapes, animals, device driver examples, etc. Plus, there are very few good business-oriented OO design books. When they cover data handling, they fail to show how OOP is an improvement over table-oriented procedural or other methods. The few that dare to compare have many holes. If I am uninformed, then so are most OOP programmers. If you agree with this, then OOP is doomed because the industry is not presenting (training) OOP properly and most people will not spend 5 years on a mountain top with gurus to get there. My alleged ignorance may simply be a mirror to a much larger problem.