Slashdot Mirror
The Post-OOP Paradigm
Kallahar writes "American Scientist has an article up about Computing Science: The Post-OOP Paradigm. The article has a great overview of how OOP works, and then goes on to a brief outline of the possible successors to OOP such as Aspect, Pattern, and Extreme Programming. Also a pretty picture of OOP Spaghetti."
Patterns don't rest on OO. The meta-pattern is as follows:
1) Describe a sticky situation
2) Describe a way to solve that sticky situation
That's it. OO has nothing to do with patterns.
If tits were wings it'd be flying around.
Please read the article before you post.
The article states:
Most of the post-OOP initiatives do not aim to supplant object-oriented programming; they seek to refine or improve or reinvigorate it. A case in point is aspect-oriented programming, or AOP.
Beat me to the punch. I had the exact same notion. Aspect is a new idea that is going around. Patterns are basically a 'way to code' OOP (being general, here). And putting XP makes me think the author of the article or the submitter has absolutely no idea what they are talking about (site is /.'ed so I can't tell you which).
Tablizer, however, has ideas to an alternative to OOP that are quite interesting.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
The example that is brought up with all the shapes turns out to have a fault. Inheritence might not be a good way to model those relationships.
So, all this article has done is show that the P-OOP thing is better than a octopus inheritance tree. Of course it is. Inheritence tends to get used way too much anyway.
Consider the famous example that we have all seen: an employee class is derived from a person class. That example appears in countless books, and probably countless systems in actual production today. But is it correct? The challenge of designing a system is to make it flexible enough to stand in the future.
Suppose we have a person who is an employee and a student at the same time. Should we use multiple inheritence? That would be screwy, and also not natural to implement in a language like Java. It turns out that breaking the problem apart into an inheritence type arrangement isn't the best or most flexible way to approach the problem.
In short, the article has made a good case why inheritence is sometimes not the right tool to use. But remember that OOP is three things: 1) inheritence 2) encapsulation and 3) polymorphism. And a language like C++ (and Java soon) has the notion of *generic programming* which the article didn't talk about.
If tits were wings it'd be flying around.
This is meaningless logic. You might as well say, "A motorcycle is worse than a car because it doesn't have four wheels." No. If it had 4 wheels, it would BE a car. A paradigm that competes with OO is not weaker just by virtue of not BEING OO.
/syle
Or another way of looking at this is that the GoF had a limited imagination and didn't describe any patterns that don't involve OO. This can actually contribute to the problem by naming some OO patterns when there are tons of ways to do things non-OO that work perfectly well.
t
I would even argue that you don't really need inheritance. In theory it's good, but as with over-OO'ing everything it quickly becomes complicated. And the more complicated it is the more spaghetti-like it feels and the less likely a programmer will reuse the code.
I've seen some very complex software written in functional languages that was very easy to follow even though the had no real OO concepts (usually some sort of module system and the equivalent of C's structs).
Sometimes the most straightforward approach is the clearest and OO is anything but straightforward when you think about all the layers that go into it. Now, I'm not saying OO is all bad, it has good features. I feel a powerful programming language should strike a balance between the different programming methodologies.
In the past I have made some comments on what I think plain old C could become if it incorporated some modulization features.
The ratio of people to cake is too big
Where I disagree is on the relative proportions of these two things. I firmly believe that we're still at the point where well over half of what a programmer does fight with tools, rather than solve new problems. I'd go so far as to say I think it's about 90% accidental complexity, which implies that the ideal programming language could allow a given development team to produce systems that are ten times more elaborate/powerful/complex/etc than today's.
So I think the language designers still have a lot of work ahead of them.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Similarly Aspect, Pattern and XP won't probably replace OOP but rather extend it, if any of them really catch on. Perhaps the functional approach will replace OO at some point in time, but I'd rather bet on some form of OO/functional mix. Python already is a bit like that - it has the functional tools like lambda, filter, map and reduce plus of course objects.
There are so many obvious glaring problems with this article I'm surprised it got published. XP as a "replacement" for OOP? Goodness, one is a methodology for building software, the other is a programming mechanism. Patterns? They are applicable in areas other than OOP. Like... architecture for instance . AOP? That's just a fancy way of inserting code into a class. Same principle as using #define in C or C++, though certainly more powerful.
Most of the 'problems' of OOP are the same as the 'problems' with older languages and practices. Simply put, once you weed out the people who aren't very good at design or programming, the lazy, the stress-cases under schedule pressure, etc. etc., you have a small group of people left who are building "good" software. (Measured by the quality of the code itself, not the success of the product.)
One of the biggest impediments to good software IMO is that the current crop of languages and tools don't punish laziness up-front. Using a magic number (or string) in a dozen places? No compiler will complain. Got a method that is calling myFoo.getList().calculateMarbleSize().insertInto( table )? No problem! Got a class that's importing classes from two dozen packages? Hey, it compiles, it must be good.
All of these examples are well-understood problems which can be avoided or fixed with very little effort. But until we have languages and tools that actively encourage good practices, we'll keep writing crap.
(Insert a rant about methodologies here -- I'm not going to go on anymore.)
-Thomas
What you're saying is that "Bad OOP (pOOP) is not the answer" which I agree with.
However, the idea behind object oriented programming is to break repeated tasks down to a general algorythm that can be reused at 1000 different places in the code without having to write 1000 different, but similar, pieces of code. This is always a good idea.
Bad OOP is when some jackass writes a 600 line "Swiss-Army Object" and insists on including it everywhere instead of doing any new coding.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Until management and HR get it through their head that programming is about hiring the "right people", building software will still be spaghetti. Crappy programmers who can't think beyond the line they are currently typing is the main cause of a lot of problems. In the worse cases, it's programmers who refuse to listen and understand the functional requirements before they code. Not enough programmers take a humble approach and take time to listen closely and think ahead.
Not everyone can and even the best programmers can't think of everything. It's all about finding the right balance to build a team that compliments each other.
Let's remember that, once you compile a program, you are left with the same thing no matter what language you used: instructions and data. Because all you really have to work with is memory and processors (and I/O, but you can treat that like the other two).
I am far more interested in the progress of automating the development of programs than in the formalization of How Not to Do Stupid Things (TM). I choose languages and tools which save me time and repetition, because tedious (and mindless) repetition is a sure way to increase the probability of human error. Silly ideas of aesthetics and tradition are of no use to me.
Perhaps the new frontier of programming is not the language, but the development environment. Then again, that's really what a language is: an environment for managing the production of machine code. But environments are more than languages now, so why not exert some serious effort, and do some serious studies, of the impact of the whole environment?
--
My blog: The Bored Astronaut
Stand back. I've got a brain and I'm not afraid to use it.
There is plenty of room for OOP to evolve.
Go in the pattern direction, and add language support to make good practice easy.
C# has already started this process, by including event schemes and automatic get/setters.
Now what we need is language support to be able to remap functions from member objects.
That frees you up from having to inherit when you don't want to, and allows you to make really good
cuts of functionality cheaply.
There are so many good object structures that are just totally impractical to write, because 99% of your code would look like:
ThisObject::MethodA(all-the-params) { return mySubObject::MethodA( all-the-params ); }
If you could remap quickly and easily, we'd be in the Haranya Loka of design.
Wrong wrong wrong.
What you are identifying is misuse of an OO language, not an inherent shortcoming in an OO system.
Your StrTok is an interesting example. StrTok is not part of any language (true, it's part of the C Standard Library but not an inherent part of the language itself). Thus, if you had to write the tokenizer yourself I would expect basically similiar amounts of C code when compared with the C++ equivalent. The properly modelled OO system would have slightly more code to deal with the class related 'stuff', but in the end they are basically equivalent.
Your initial example of 'students (who) objectize everything' is also flawed. Part of the trick to OO programming is that you must place more emphasis on arriving at proper abstractions. In general a properly abstracted system will require quite a bit less work than the equivalent procedural one. The resulting program MIGHT be slower, but that's more of a language reality than paradigm shortcoming. Properly designed and abstracted OO systems are easy to maintain and much more accomodating of change when compared with similiarly designed procedural systems.
I completely agree that we should always strive to use the tool that gives us the best results. One inherent problem is that we have to answer 2 questions, however. Is this the right tool for NOW... AND is this the right tool to help me design the system that I may need in the future.
Some times the answer is obvious. I'll generally write a shell script of some kind to deal with daily admin types of tasks (IE: Sed to split delimited files for other procesing), but most of my product development tasks require me to look to future flexibility. I find that higher level languages, and OO languages in particular, allow me to design proper systems that can handle the addition of new features and new concepts much better than lower level counter-parts.
NOTE: This is not a discussion of the relative merits of C++ vs. C. Before people start blasting into this saying 'I can design any system in C that you can in C++..' and I would agree. It's certainly more cumbersome, but at some point expressive languages (like C) are able to be utilized using new paradigms (like OO). In other words, C CAN be a OO language if you use it like one.
Turn s60 photos into awesome videos with mScrapbook for all S60 3rd edition phones!
It pisses me off every time somebody comes along and thinks they can shoe-horn all possible solutions to all possible problems into a single programming style. So for everybody who's a newbie, let me impart a little wisdom to you so you don't have to learn it the hard way.
Use the right tool for the right job. Sometimes, a functional style is useful (especially when one's teaching programming language concepts and higher-order mathematics). Sometimes, procedural tools with abstract data types are useful. And sometimes, functional, procedural, and object-oriented styles can work together to solve a problem (such as the machine simulator I'm writing in Lisp).
Rant mode off.
I'm proud of my Northern Tibetian Heritage
Often, I wonder how often code is actually re-used, and adapted later on.
Both conditions will have to be met to make the big idea behing OOP work. I'm sort-of an P/R fan and programmer, and I see no reason to assume that OO as a whole has been a good thing.
Lets just get rid of it, never speak the words or acronym again, and revert to P/R programming. If someone could think up a great acronym for this process, I am convinced corporate management is quite willing to accept it.
Don't lay this sin solely at OOP's door. We learned it from Structured Programmers, and are smugly pleased that Generic Programmers are knee deep in this iniquity as well.
Any formalized process can be taken to an extreme. And you yourself are arguing for a formalized process as well: "And never write OO when procedural programming can do the same trick in less space." Sometimes it might actually make sense to write it in OO, because other things may be more important than less space! Programming isn't a field of morality where you must choose a particular code of ethics to abide by no matter what.
A Government Is a Body of People, Usually Notably Ungoverned
That's not necessarily a bad thing: it may be indicative of an attempt to generate automatic serializers/deserialiers for objects by providing sufficient compile-time type meta-information.
Unfortunately, the resulting code gets littered with the helper classes and remnants of the hierarchy you describe. A traditional (or non-traditional) IDL representation with a pre-processing step that generates class declarations and marshelling code (or tables) tends to be a bit cleaner, though then you run into the issue of having to program in "yet another language".
You could've hired me.
Hammers pound? I don't think so. Hammers don't do anything.
You soon learn that it should be:
Worker.UseTool(Hammer, Nail);
Then you realize that OOP is just a nice way to organize things, and that it's all just a prettier procedural anyway.
The "spaghetti" problem of multiple inheritance or of even multiple taxonomies is not really a problem in languages supporting type inference (I am sure about Haskell, perhaps OCAML as well).
I don't think OOP is a problem. In fact, OOP is a useful paradigm. The problem is that OOP should not be the only useful paradigm to be used. Type constructors, recursion, constraint programming, pattern matching, and of course type inference are other useful ones.
But what's even more important, OOP paradigm should be mixed with very dangerous paradigms, such as distructive assignment. Do you want your code being capable to change itself in an arbitrary way? No one loves buffer overflow. But why most of programmers are ok with destructive assignment? Variable value is a part of the (run-time) program code, it should not be modified - only created.
Interestingly, while mathematically educated programmers do already (how many decades) know that the future is for FP, programmers without good math background keep re-inventing the wheel involving structured programming, OOP, AOP (what next? TOP as taxonomy-oriented programming?) - all what was already existed in FP (and/or LP). How many more billions they will flush to toilet before realizing that?
Less is more !
The Kx guys? Promoting OO++? I'd like to see where. The Kx guys are as anti-OO as any professional can be these days without risking being laughed at by the uninformed community (that thinks OO is a silver bullet).
This was back when Arthur was working at UBS in New York - maybe 6 or 7 years ago, and had a core K development team of a dozen or so. They were very anti-OO, but lost quite a lot of credibility through putting up straw man OO arguments and knocking them down - such as the example I gave above, and claiming these proved the "fundamental flaws of the OO approach". It was one of the core team who then showed another solution, and claimed this as his new technique to be called "OO++".
Don't get me wrong, I quite like some features of K, and I had quite a bit of respect for Arthur and some of the K internals... it was just some of the hype and deliberate obfuscation of arguments from the crowd that was sour.
--
T
I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best
Fuzzy membership seems to be a component that could be expanded upon and refined to help solve this problem. BTW, this problem happens all the time not just in software but I am sure everyone here knows of that. Fuzzy sets can be a bitch unless you setup either heavy restrictions (ouch) or setup a very robust system of processes and procedures that can be adopted and they themselves be combined, inherited and abstracted. Otherwise you get such a wide variety of classifications and categories that you might as well have never even used any paradigm. Seems to me we should focus on the meta aspects of the paradigms, methods, processes and encapsulations (categorization and classification). Instead of saying, "Hmmm, OOP has some flaws... lets just start all over with something incompatable" you should treat it as EVOLUTIONARY.