The RIse and Fall of OO
-
In a perfect world where every function operated properly on every object, the generic idea would work just fine. However, we don't live in a perfect world. All to often, when working with STL, I am wasting my time trying to figure out how to do traditional operations on such things as strings. But since STL is pushing that even more methods be removed from STL classes, I end up having to roll my own little widgets to operate on STL objects. The world is full or morons who think that OO, generic programming or template meta-programming will save the world as a complete programming methodology. But none of them really do by themselves. What I use in my day-to-day development: Functional programming - OMG remove the devil spirit.... Give me a break, there are many thing that work great in functional programming that are harder in such things as OOP. I have seen more sins against OOP where people felt that it wouldn't be right to have a bit of functional programming. Placing functional programming in a class just so you can call it OOP usually results in such silly things as classes with nothing but static methods or cases where you have in create an instance of a class without variables just to execute the FP methods. OOP - Majority of my work is done in OOPs. Generics - Even when an algorithm can't be implemented generically to operate on everything, generics can be very very powerful. Hell, qsort existed in C for very many yars and it was a form of a generic algorithm when the language lacked to syntax to do it well. Template meta-programming - Used it once. Very hard to write, very hard to debug. Wouldn't want to wish it on my worse enemy. However, there are a very small set or programming problems that work well. But in general, I think the "bugs" the TMP tries to avoid are far overshadowed by the complexity of the TMP implementation. Tim Smith I'm going to patent thought. I have yet to see any prior art.
Tim Smith wrote:
Functional programming - OMG remove the devil spirit....
Are you sure you mean functional[^] programming (Haskell, ML, Scheme,...) and not procedural programming[^] (C, Pascal, Fortran, ...)?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
So... if OO is falling, what's next? :omg:
Super Lloyd wrote:
if OO is falling, what's next?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
Tim Smith wrote:
Functional programming - OMG remove the devil spirit....
Are you sure you mean functional[^] programming (Haskell, ML, Scheme,...) and not procedural programming[^] (C, Pascal, Fortran, ...)?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
An interesting article[^] I ran into today. While I don't agree on every detail, I surely share the sentiment: "classic" OOP is simply not good enough for 21st century software. Opinions?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
I fully agree with Marc's comments earlier. I find the failure of STL to properly do and allow inheritence to be one of its most annoying "features". Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
An interesting article[^] I ran into today. While I don't agree on every detail, I surely share the sentiment: "classic" OOP is simply not good enough for 21st century software. Opinions?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
This is quite true. The best example is STL containers: Algorithms are separated from containers via iterators. This is very non object oriented, in a classic OO design the algorithms would be part of the container. This divergence from a bind adherence to OO is also what gives the STL container architecture its power. I think programmers, like the rest of the world, are inclined to fall for the "magic bullet". There is no such thing. Steve
-
An interesting article[^] I ran into today. While I don't agree on every detail, I surely share the sentiment: "classic" OOP is simply not good enough for 21st century software. Opinions?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
"Rumors of my death have been greatly exaggerated." -- Mark Twain I read the first article like this in 1982. So I stayed away from OOP, because it was obviously on its way out. As I continued reading these articles over the next twenty years, I stayed away from OOP, which was obviously on its way out. I finally figured out what was going on about four years ago. Glad to hear OOP is obviously still on its way out. IMHO, a lot of the stuff in that article looked like it was from 1982, so maybe it did go out. Well-factored OOP, along the lines of the GoF, must be what's obviously going out now.:laugh: David Veeneman www.veeneman.com
-
"Rumors of my death have been greatly exaggerated." -- Mark Twain I read the first article like this in 1982. So I stayed away from OOP, because it was obviously on its way out. As I continued reading these articles over the next twenty years, I stayed away from OOP, which was obviously on its way out. I finally figured out what was going on about four years ago. Glad to hear OOP is obviously still on its way out. IMHO, a lot of the stuff in that article looked like it was from 1982, so maybe it did go out. Well-factored OOP, along the lines of the GoF, must be what's obviously going out now.:laugh: David Veeneman www.veeneman.com
The guy who did most to "invent" object-oriented programming, Alan Kay, once remarked that C++ and Java were certainly not what he had in mind when he thought of object-orientation. I take that to mean that the major objective of O-O was to find a way to tie together what many C++ programmers term "the problem domain" (known to the rest of us as "the real world") with the artificial world/narrative created inside the code itself. Both C++ and Java impose a series of articial barriers that make this difficult. I'm still surprised today at the number of people who believe they are using O-O processes but have never, for example, held a series of CRC sessions. Used correctly, the great benefit of these processes is that they cease to privilege the programmer. If the issue is the real world, then the real experts in that "domain" are the users and clients. The best O-O processes bring this out, and make it a dominant feature of development. I program in Ruby, Cocoa/Obj-C and Smalltalk. In those languages what constitutes O-O seems totally different from how O-O is viewed in C++ and Java. The primary purpose of O-O is not efficiency in coding, it's efficiency in thought. Probably the best approach is that of David Taylor, who "invented" convergent engineering, a process whereby you begin to model the actual problem situation, then build that model in code. In the end, though, it seems to me that O-O is one of those things that either suits your personal coding style and approach to life or does not. To prophecy the end of O-O is like suggesting that Christianity will soon replace Judaism. Surely if we have learned anything in software it is that accommodating a broad church of ideas and approaches is a good thing. TSLEWIS "the best way to predict the future is to invent it" Alan Kay
-
An interesting article[^] I ran into today. While I don't agree on every detail, I surely share the sentiment: "classic" OOP is simply not good enough for 21st century software. Opinions?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
The article you mention has some good ideas but makes a very big gaffe with respect to class member functions. A naive implementation of size() on a vector would turn an order 1 operation into an order N operation. I used the glockenspiel C++ compiler in late 1980's and at that time was being converted from procedural programming into an object oriented programmer. However, as C++ and my understanding have evolved, I have come to the conclusion that OO tends to force the programmer to think in terms of OO concepts rather than thinking in terms the problem to be solved. C++ with its templates, member functions, and template specialization, etc allow the programmer to match the problem with an implementation specific to it. Given a programming problem, it is very tempting to start designing classes but it has been my experience that it is more important to develop a mental model of the problem before trying to code the solution. Yourdon structured design methodology as it was taught in the 1980's, anyway, encouraged a recursive decomposition of the programming task into processes whose inputs and outputs were clearly defined. That is, the final system was described as a process bubble with inputs and outputs. Inside that big bubble were little bubbles with their own inputs and outputs -- and so forth. Once the problem is well understood in this fashion, the exact implementation technique -- whether OO or procedural is of secondary importance. C++ is a great implementation platform for any or all of these bubbles because you can use OO where appropriate, or generic programming, or procedural as needed. I don't think that OO is dying by any stretch of the imagingation -- its just not the be all and end all of techniques and cause as much trouble as any other technique if you focus first on the technique and then on the problem. Lowell Boggs
-
His reference to Herb Sutter's coding standards book bothers me though. I found Sutter's view on "Proper" C++ programming turns C++ into an unpractical language. He limits the vast capabilities and promotes too much self protection at the cost of effectiveness and simplicity. Meyer's is much more practical as he views C++ as a "Federation of Languages" and does not abandon any one of them in development. Instead, he encourages "proper usage" of each respective of the problem that needs to be overcome. Their are many similarities to what both authors state, but Sutter tends to restrict the language and shifts the paradigm, as Meyer's tends to broaden the paradigm to include subcategories. C++ would not be necessary (nor as powerful) if the shift was to exclude those categories. Interestingly, (ironically???) Bjarne Stroustrup's book on his language also seems rather restrictive (in terms of his recommendations of usage versus what's available in the language). However, he left some items intact against his better judgement because he admits that it's just his opinion. He deserves admiration for reminding himself at the end of the day that there are many schools of thought. The author of the article is naive to usage of the language outside of his own personal experience methinks.
Stroustrup and Sutter are writing to an academic audience. Most of what they say isn't worth the paper it's printed on in the real world. Such is life. What we learn in school prepares us for the real world, but it doesn't mean squat on the surface.
-
You're absolutely right -- use the best tool for the job. That's what software architects and systems engineers do. Heck, I still interface with legacy FORTRAN code, but you know what: it works! Not only does it work, but refactoring with C++/OOP would be a waste of $$ because the interface would still need to be the same and the FORTRAN code has ~15-17 yrs of debugging and optimization under it's belt. To someone with only a hammer, I guess everything's a nail. ~Nitron.
ññòòïðïðB A
startI think you are confusing two things: OOP in itself and the need to replace an existing system. In this case, there is no need.