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."
Of the 3 'paradigms' mentioned as alternatives to OOP, only aspect oriented programming is even on the same order as OOP. Patterns are a design methodology and XP is a workflow.
Aspect is best used in conjunction with OOP. In fact I would say that anyone that uses Objective-C's categories has been doing aspect all along.
Which industry?
Most commercial code now is written in C++, followed by Java, and then sadly VB.
To be honest, for most of the work they do they are better off. For most of that they would be even better off in a higher level language like Python (if addicted to OO-procedural), Lisp or
Haskell.
C is unfortunately considered backwards by a lot of code grinders. It gets most use in the embedded systems and OSS worlds....
Yes, OOP is about to be not replaced, but seriously eclipsed. It will become just another tool in a (good) programmer's bag. A quiet revolution is happening as we speak (write), and it will rock the software world.
Sadly, the article is completely missing it: I am talking about Generic Programming and templates.
The constructs possible using it are truly staggering. It is changing the way we THINK about our programs. And the tools it is producing are breath-taking.
Developers who used Loki, Boost, STL or WTL know what I am talking about. Read the Andrei Alexandrescu's book and prepare to be amazed.
Sadly, Java will miss it entirely as well. No, the added support for generics in 1.5 does NOT count. It can't hold a candle to CPP's templates and it too much of an aftertought.
But it's not for everybody. Not all developers are ready for the revolution. The one-language code monkeys for example, will be left behind (they're the guys with the "Java/C++/C rocks! and everything else sux"). Also the scripters (aka sysadmins) won't care: they are not even the target audience.
But the real programmers, the ones of us who see the language as a tool for the task at hand, not a religion, are ready.
Viva la revolucion!
XP is heavily influenced by TDD -- Test Driven Development. The idea is that you only write code when you have a failing test. You write the test, it fails, you write the code to make the test pass. Then you go back to the requirements, write another test specified by the requirements, run it, it fails, so you write the code to fix it. Repeat until all tests (unit and functional) pass. When all your functional tests pass, you've met the requirements for the app (because the functional tests represent the use cases) and you're done.
Coding in this fashion does two things. It ensures that you've got a safety net at all times, and it forces your code to be loosely coupled and modular. Because you have 100% coverage, you're not afraid to change the code, because if you break something, you'll get a failing test. If you make a change and all your tests pass, you have the confidence that you didn't inadvertently break something in your code.
Additionally, your code needs to be modular and loosely coupled because it's tough to test if it isn't. If you have a God Class with lots of dependencies, you won't be able to unit test it because of all the dependencies. That's to say, you won't be able to test it as a unit. If you have a method that's doing lots of things, you'll have to write lots of tests to verify every path of execution. So instead, you're strongly encouraged to write simple methods that do one thing well for ease of testing.
A real OO guru knows all sorts of things about coupling and cohesion and patterns and when to use composition and when to use inheritance. They always obey the Law of Demeter and consistently separate the implementation from the interface. And to be able to do this, they've got a dog's life of OO experience under their belt. Here's the kicker. The XP evangelists say that using XP and TDD, in particular, gives you the benefits of all this experience as an emergent property of the methodology.
You obey the Law of Demeter because testing a class that breaks it isn't a unit test -- it's a subsystem test. You use interfaces because it allows you to substitute mock objects for the objects that your object under test interacts with. You use composition and inheritance appropriately because your tests will fail if you don't. Oh, and by the way, if you start with inheritance and move to composition, it's not a problem because all your tests will insure you don't leave something broken.
The point is that a programmer really only needs to learn how to write good tests in order to be a good programmer. TDD gives you all the stuff that you would normally have to have gained through experience.
So, that's why I think it's similar to AOP. They both produce higher quality and more maintainable software. However, TDD is a social solution, while AOP is a technical one. And, as long as I'm on my soapbox, I'll just mention that many patterns are compensations for things that more powerful languages do easily. For example, lisp's map procedure is an example of Visitor. Generally, languages that support higher order functions, or that treat functions as first class types, don't require as much pattern silly-walking. Also, AOP is old. Lisp has had it for a long time. In fact, the main architect of AspectJ, Gregor Kiczales, worked on the Common Lisp Object System (CLOS) with Richard Gabriel. Plus ca change, plus ca meme chose, innit. Here's a link to some thoughtful writings on the subject.
One other point -- for those inclined towards genetic programming. I think that the XP TDD way of programming suffers from the same problems as the hill climbing algorithm. It tends to produce quality, but I think it's easy to get stuck at a local minimum.
Refactoring is not the same thing as code maintenance. It's actually more akin to code meddling, but done in well-defined, discrete steps, coupled with unit tests so as to minimize the risk.
At the risk of stating the obvious, the ability to do generic programming (in the sense of working with arbitrary interfaces without needing the inheritance/OOP angle to specify that they're met) has been around for decades in many languages.
There's nothing inherently special about generic code. From a certain point of view, the very fact that generic algorithms and data structures are regarded as anything but the obvious default is just indicative of a flaw in the underlying models of languages that need templates etc.
I appreciate your enthusiasm, and generic programming is a fine idea, but if you think things like the STL and expression templates are original, you need to read up on things like functional programming, where vastly more powerful versions of the same concepts are routine. These libraries are very useful tools for languages that don't support the concepts natively, without a doubt, but magical they ain't.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
There are two language groups that cover what you want, and have been around since at least the early seventies; you should look at Lucid and its derivatives (GLu and Lustre being the most interesting), and derivatives of CSP such as newsqueak and limbo
There is a need for VB. VB is a great way to prototype a new product interface or set one up for a one shot tool. If you want the project to be truly useful however, you need to consider OOP or structured programming techniques during the design. I don't know how many times I have been handed somebody's little "VB" tool that has become indispensable to company operations, but needs "one more feature" and found out that code reuse to this person means yet another copy of the same 20 lines of code attached to every frickin object in the project. There in lies the inherent danger of VB. Anyone can learn enough to be dangerous. But when they start drowning, they call for the software guys to bail them out, and then the finger pointing begins.
"I went on a diet, swore off drinking and heavy eating. And in fourteen days, I had lost exactly two weeks. Joe E. Lewis