The Post-OOP Paradigm 453
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."
Analysis (Score:2, Insightful)
Aspect programming doesn't have inheritance (that I am aware of) so it is a weaker model than OO. Although we should "...favor composition over inheritance", it doesn't mean we should do away with it! Also, where the polymorphic method behavior of Aspect?
Pattern design's foundation rests on OO. Take away OO and Pattern can't exist.
Extreme Programming has nothing to do with any of the above. It's not even an architecture.
Re:Analysis (Score:2)
Ah yes. Are we discussing software design or economics. Did you ever wonder if we were often trying to solve the same problems?
I know this is going to get me modded down to no end, but It's kind of fun to take a phrase out of context for a minute.
Re: Analysis (Score:4, Interesting)
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.
Re: Analysis (Score:4, Funny)
This was contained in the body of the submission, which certainly would imply that the submitter hadn't read the article, either.
Re:Analysis (Score:3, Interesting)
Tablizer [slashdot.org], however, has ideas to an alternative to OOP [geocities.com] that are quite interesting.
Re:Analysis (Score:2, Insightful)
OO is a concept, not an implementation... as is XP... they are not mutually exclusive (and concepts/languages are often complimentary) so how can one replace the other? Is this supposed to be a flamebait article?
SMALLTALK FOREVER! man, i hate C++, but still use it every day... POOP surely is a misguided notion
Re:Analysis (Score:2)
It's all a question of which buzzwords people are concentrating on and more importantly thinking in terms of.
Re:Analysis (Score:5, Interesting)
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.
Re:Analysis (Score:2)
Whether you agree with that or not is up to you, but "surely" you can't speak for everybody. (and please stop calling me Shirley).
Re:Analysis (Score:2)
Re:Analysis (Score:2)
Re:Analysis (Score:5, Insightful)
Aspect programming doesn't have inheritance (that I am aware of) so it is a weaker model than OO.
No, there are AOP systems which do have inheritance; but in that sense it's just another way of doing OOP. AOP itself doesn't have or need inheritance, and you simply can't judge it on that basis; it's NOT OOP, so lacking a single feature of OOP is irrelevant.
AOP, I suppose, could replace OOP. But it won't, because OO is a handy way for dealing with aspects.
Pattern design's foundation rests on OO. Take away OO and Pattern can't exist.
No. Patterns can be found and documented in everything, objects or not. The original book is about patterns in an OO language, but there are patterns in other paradigms as well.
But patterns alone won't replace OOP, because patterns merely document the order found in a system -- you still have to build the system somehow.
Extreme Programming has nothing to do with any of the above. It's not even an architecture.
Correct. It didn't belong in the article; and in fact, the author showed no knowledge of any kind about XP.
It lives under the misguided notion that since team-analysis works well, team-programming must work well too.
No, that's not one of the notions under which XP lives; and XP does work very well. At least for me and those I've worked with.
-Billy
Re:Analysis (Score:3, Informative)
Actually, the true original book about patterns is about architecture (as in physical buildings), so you are even more right than you know.
Re:Analysis (Score:2, Insightful)
However, it's not true that design patterns can't exist without OOP. Patterns are simply that -- common elements of a design that you find in a wide variety of software. You don't necessarily need OOP to implement them. For example, you can have user-interface design patterns that pr
Re:Analysis (Score:2, Insightful)
CMMI (Score:4, Insightful)
1. Keep development at or under cost. This is both in time and money.
2. Keep defects to a minimum.
This is to maintain a predictable and acceptible level of quality and project accountability. And Quality and accountablility are buzzwords for keeping metrics on your performance so you can use statistics to more accurately estimate how many klocs (how long) a project or module will take and how many defects will be in it.
Capability Maturity Model Integration [cmu.edu] is a system for software engineering. It uses OO.
Since the gov/mil space endorses this, and my personal experience is that CMMI can make life much easier for you once you adopt it, I don't see OO going away anytime soon. From this experience and observation in the gov/mil space, nything beside the nuts and bolts to keep performance metrics and reduce defects is just fun and games.
Having said that, its not glamorous, its more like programming/accounting. But it IS effective and does reduce development risk significantly.
this is probably why open source is so popular. Of all the things open source dev does, it lets people who work in a rigorous environment blow off some steam and do some freeform coding the way they want to do it, when they want to do it.
Re:Analysis (Score:2)
"Most of the post-OOP initiatives do not aim to supplant object-oriented programming; they seek to refine or improve or reinvigorate it."
Re:Analysis (Score:4, Informative)
If we are talking about AOP then we are talking about two languages, the OO language and the Aspect language. The apspect language is an extention to OO language and doesn't alter anythig on the rules of the oo language.
AOP is really powerfull and fun to program with. There are several AOP languages. I know some of them; including (which I've belive the strongest ones) AspectJ(Xerox park) and Composition Filters (developed by Mehmet Aksit).
If any one wants to learn something about AOP plaese visit Apsectj's web site.
You can also visit our course web site:
http://www.cs.bilkent.edu.tr/~bedir/CS586-
Re:Analysis (Score:2)
Indeed, XP replacing OOP? Heh. Patterns replacing OOP, Ha!
This just in! Scissors will replace any sort of sharp-metal blade for cutting in the near future!
Re:Analysis (Score:3, Informative)
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....
Re:Analysis (Score:2)
Re:Analysis (Score:2)
In other words, while what you say is true, the clearest and best manifestation of Patterns is done through OO.
Re:Analysis (Score:2, Interesting)
Re:Analysis (Score:3, Funny)
How about Bridge? That's meaningless in a non-polymorphic language like COBOL.
Offtopic post about terminology (Score:3, Insightful)
Everywhere I turn right now someone is yapping about "Patterns": No longer is it simply standard best practices, but rather now it's the new age "Patterns". No longer do you do code maintenance: Now you "Refactor". No longer do you wing it, now you do "Agile Development". It almost makes the speaker sound ridiculously naive hanging onto whatever terminology they hear, as if it's something new when it's mere
Re:Offtopic post about terminology (Score:4, Informative)
Re:Offtopic post about terminology (Score:3, Funny)
something like about shepherding?
Re:Isn't "Extreme" programming simply... (Score:2)
In other words... (Score:2, Insightful)
Re:Analysis (Score:3, Interesting)
A better analogy would be OO vs structural programming. OO didn't replace it - you still have the ifs, whiles & one entry point per procedure (ok, it's usually called method in OO).
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 p
great new acronym (Score:5, Funny)
Re:great new acronym (Score:5, Funny)
What do crabby patties have to do with software development?
Re:great new acronym (Score:2)
Re:great new acronym (Score:2)
OOP Spaghetti? (Score:2)
The phrase Sounds almost like an annoying kid's toy.
(Annoying Gingle) ... OOPS Spaghetti
Re:OOP Spaghetti? (Score:5, Insightful)
I've seen nice C code.
I've seen nice Java/C++ code.
I've seen god aweful C code.
I've seen god aweful Java/C++ code.
The OOP example picture and why it sucks :-) (Score:4, Insightful)
Looking at that diagram, I think it does a good job of illustrating why OOP isn't always as good as it should be. I would submit that the example in question is a standard one, and it's as silly as the standard Fibonacci example of recursion: looks very pretty, but sucks in practice. OOP is harmed by the use of such examples in teaching and advocacy and the sooner we get rid of them in favour of something that demonstrates where OOP's features are actually helpful, the better.
I would suggest that pretty much all of the properties given to the shapes in that example would be better represented as part of a single Polygon class's state. The article suggests that there are algorithms that are only applicable to, say, a convex polygon, but if that's the case, how would they come to be called on a non-convex shape in the first place?
Inheritance doesn't help here. What would your base class implementation of the algorithm be? Or are you going to test the object's type dynamically and branch if it requires such an algorithm to be run? In that case, why not use (in C++ terms)
rather than
??
The example simply doesn't make good use of inheritance. Unless you're interested in polymorphism -- which you're not here, if your algorithms are subtype specific -- then it's easier and more flexible to extend your classes by adding properties via state, and to test for those properties where your logic requires. This is just the same as in the non-OOP world, where you would another field to your structure and test that before processing the structure in a particular way.
You'd never guess I spent all day manipulating geometries in C++, wouldya? :-)
Great new Acronym - POOP (Score:3, Funny)
I didn't read the article but I will be giggling like a schoolgirl every time I hear someone talk about it.
Re:Great new Acronym - POOP (Score:2, Funny)
XP and Pattern are not paradigms (Score:5, Informative)
Re:XP and Pattern are not paradigms (Score:5, Insightful)
Server is rapidly choking - Article text (Score:4, Informative)
March-April 2003
The Post-OOP Paradigm
Brian Hayes
Note: This document is available in other formats.
Every generation has to reinvent the practice of computer programming. In the 1950s the key innovations were programming languages such as Fortran and Lisp. The 1960s and '70s saw a crusade to root out "spaghetti code" and replace it with "structured programming." Since the 1980s software development has been dominated by a methodology known as object-oriented programming, or OOP. Now there are signs that OOP may be running out of oomph, and discontented programmers are once again casting about for the next big idea. It's time to look at what might await us in the post-OOP era (apart from an unfortunate acronym).
The Tar Pit
The architects of the earliest computer systems gave little thought to software. (The very word was still a decade in the future.) Building the machine itself was the serious intellectual challenge; converting mathematical formulas into program statements looked like a routine clerical task. The awful truth came out soon enough. Maurice V. Wilkes, who wrote what may have been the first working computer program, had his personal epiphany in 1949, when "the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs." Half a century later, we're still debugging.
The very first programs were written in pure binary notation: Both data and instructions had to be encoded in long, featureless strings of 1s and 0s. Moreover, it was up to the programmer to keep track of where everything was stored in the machine's memory. Before you could call a subroutine, you had to calculate its address.
The technology that lifted these burdens from the programmer was assembly language, in which raw binary codes were replaced by symbols such as load, store, add, sub. The symbols were translated into binary by a program called an assembler, which also calculated addresses. This was the first of many instances in which the computer was recruited to help with its own programming.
Assembly language was a crucial early advance, but still the programmer had to keep in mind all the minutiae in the instruction set of a specific computer. Evaluating a short mathematical expression such as x2+y2 might require dozens of assembly-language instructions. Higher-level languages freed the programmer to think in terms of variables and equations rather than registers and addresses. In Fortran, for example, x2+y2 would be written simply as X**2+Y**2. Expressions of this kind are translated into binary form by a program called a compiler.
With Fortran and the languages that followed, programmers finally had the tools they needed to get into really serious trouble. By the 1960s large software projects were notorious for being late, overbudget and buggy; soon came the appalling news that the cost of software was overtaking that of hardware. Frederick P. Brooks, Jr., who managed the OS/360 software program at IBM, called large-system programming a "tar pit" and remarked, "Everyone seems to have been surprised by the stickiness of the problem."
One response to this crisis was structured programming, a reform movement whose manifesto was Edsger W. Dijkstra's brief letter to the editor titled "Go to statement considered harmful." Structured programs were to be built out of subunits that have a single entrance point and a single exit (eschewing the goto command, which allows jumps into or out of the middle of a routine). Three such constructs were recommended: sequencing (do A, then B, then C), alternation (either do A or do B) and iteration (repeat A until some condition is satisfied). Corrado Böhm and Giuseppe Jacopini proved that these three idioms are sufficient to express essentially all programs.
Structured programming came packaged with a number of related principles and imperatives. Top-down design and stepwise refinement urged the programmer to se
Re:Server is rapidly choking - Article text (Score:3, Insightful)
Have you ever noticed how people single out software development to ostracize for late projects? I'm not sure what world they live in, but in my world this is a massive project management problem in general, regardless of whether software is involved. About the only industry that has any sort of complex engineering down to a project management science is the housing industry, but outside of that time and cost overruns
Re:Server is rapidly choking - Article text (Score:5, Interesting)
Dude, I've known programmers in their mid 30's who have been working on various projects and different companies since undergraduate school, but for some reason or another, every single project, module, subsystem, etc., that they've worked on has been cancelled. In other words, nothing they've done for more than 10-15 years has gone into production or made it to customers. Imagine that.
Re:Server is rapidly choking - Article text (Score:3, Insightful)
Usually, the software is the last stage of the project. You obviously have initial specifications, and then you often have some hardware implementation phases, and then the software comes at the end. Even if you have an in-house testing stage, when you come to the big rollout you will probably have some problems, and you will expect software to fix them (because it os too damned late to fix the hardware).
So s
OOP Spaghetti... (Score:4, Funny)
The phrase sounds like a noddy training model for message passing using an italian resteraunt as a metaphor.
Hell, for HLA training I went through the Food Fight program, and the Sushi Bar, this sounded for a minute like the final exam.
Huh? (Score:2, Informative)
Aspect-oriented programming isn't designed to supplant OOP, Patterns are largely oriented around OOP and Extreme Programming isn't a programming paradigm - it's a programming methodology that's completely independent of the underlying paradigm.
OOP is frequently the wrong answer (Score:5, Insightful)
However most OOP programmers try to over-OO everything. This is a problem from day one - their instructors show them how to make an object and how cool it is to have the object do something on its own. Thereafter, the students objectize everything. This leads to situations where you've got horribly bloated code that runs slow as hell.
It's this kind of instruction that leads to programmers writing whole object-oriented interfaces to things that can be very easily manipulated without all the overhead. For example I had a consultant working (briefly) with me who wrote several thousand lines of code that would edit colon delimited files (like /etc/passwd, for example) when a simple strtok in C or split() in perl would have done the trick in a few lines, without all that code to debug.
People need to always take a step back and see if the language contstructs they plan to use are appropriate for the task at hand. More often than not, they'll find that they higher level languages are too much. Don't write a C program when you can write it in shell. Don't write daemonizing code in your app if it can run from /etc/inittab. Don't write a scheduler when you can do it in cron. And never write OO when procedural programming can do the same trick in less space.
Re:OOP is frequently the wrong answer (Score:2)
Re:OOP is frequently the wrong answer (Score:3, Interesting)
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-tradit
Re:OOP is frequently the wrong answer (Score:5, Insightful)
A good OO design would of encapsulated the functionality in a small class. not thousands of lines, just a few more.
Re:OOP is frequently the wrong answer (Score:3, Insightful)
I'm not sure if the problem stems from instructors reluctance to admit that there is "too much of a good thing", or if it stems from students having never been introduced to anything else.
One big problem I have seen in my own classes is that you have a class full of students, and maybe 1 or 2 of them have any programming experience at all. They go in a
I agree. (Score:2, Interesting)
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
on the definition of *need* (Score:4, Insightful)
The statment "... OO is anything but straightforward when you think about all the layers that go into it." is a hint at the underlying problem, I think. If you have to think about the layers, your model has some problems.
The functional system you describe with the module system sounds like it is building some very nice layers. I'm not saying it can't be done without OO.
What I am saying is that OO (and OO languages like Java) encourage you to do it "the right way". You can write spaghetti code in Java, but it takes some doing. You have to sprinkle a lot of static keywords around, and make a lot of classes that don't make sense.
Coversely, to write clean, modularized code in most fuctional languages, you have to be more "disciplined" and stay out of things that you shouldn't be in.
I suppose, in conclusion, I would say that OO leads to very clean, straightforward code when the concepts are well understood and applied. Understanding and applying these concepts is not a simple task, however, and I'll admit that in the time I've been doing it (~7 years) I don't have it cold.
Just my $.02
-Zipwow
Re:I agree. (Score:4, Interesting)
Consider a simple GUI. In this GUI you have a button, a checkbox, a label and an edit box. All of these things are widgets. Does it not make sense to use a base widget class instead of rewriting all the common related functionality they all have? Now add a radio button. It's related to a checkbox. Perhaps it also makes sense to have the checkbox and radio button share a common ancestor as well.
I can hear people say "that's what functions are for!". True, that is what they are for. But if a function is only useful for a widget related structure, doesn't it make sense to encapsulate that function with that structure?
No, you don't need inheritance. But sometimes it's damned useful.
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
So have I. But no one here is arguing that OOP is the only appropriate paradigm for all problem domains.
In the past I have made some comments on what I think plain old C could become if it incorporated some modulization features.
Be careful with this. If you don't watch yourself it could end up becoming Objective C
True of most fresh programmers (Score:5, Insightful)
Re:OOP is frequently the wrong answer (Score:3, Insightful)
I use to work for a company were only c++ and java could be used. This includes unix scripting. Its the standard and managment actually thought having programmers like yours writting thousands of lines of code was saving them due to support costs. Incredible. I wonder if standards obbsessions are hurting IT more then helping it.
I disagree. (Score:4, Interesting)
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.
Re:OOP is frequently the wrong answer (Score:4, Interesting)
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.
Re:OOP is frequently the wrong answer (Score:3, Interesting)
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 fi
Re:OOP is frequently the wrong answer (Score:3, Insightful)
I'm confused... Languages?
The article discusses paradigms, approaches to programming. And then makes sure to clarify that modern "paradigm shifts", unlike the drastic jump to structured programming, are complementary to OOP rather than replacements.
Besides that, I don't think inheritance and code re-use are the "good features" of OOP.
Su
Re: Give them a hammer and.... (Score:3, Interesting)
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.
Refinements, not successors (Score:3, Insightful)
Rather, there are refinements and additions to OOP, and they cover subjects that have not been addressed before. It is not that they address the same issues with a new set of solutions.
Tor
OOP Spaghetti ... (Score:4, Funny)
Re:OOP Spaghetti ... (Score:3, Funny)
I daresay that OOP can make a plate of spaghetti look relatively uncomplicated.
The spaghetti analogy to OOP works better if the spaghetti is overcooked, so that pulling a single strand causes an enormous giant squid-like multi-noodle to emerge from the depths.
To make the analogy really complete, though, you would need to mix in some other topologically-interesting pasta shapes, maybe even a few Klein bottles.
To top it off, when you dredge up a strand of spaghetti with a fork, if you started to pull out
OOP is always has its place (Score:3, Insightful)
Same thing with OOP, there are tasks which lends themselves better to OOP vs functional programming, and vice versa.
Every technique will have its place.
We have the same mix-conception about XML replacing everything else. e.g.
<actor name="Martin" show="Simpsons">
<sprach volume="high">ha ha!</sprach>
</actor>
Fake old BS interview... :) (Score:5, Funny)
I tried to paste the interview here but the lameness filter did not think that it was a good idea... so here goes the link [vcu.edu]
--krahd
The Post OOP Paradigm (Score:4, Funny)
Instead of developing deep scientific insights, innovative programming concepts and technological advacement the IT industry switched to producing incoherent PR babble mixed with ridiculous claim which contradict basic common sense.
This leads to zillions of book with topics from "Javanetaspdcomaolrotlfuckoff in 21 days" to "Extreme goatse coding: open asses for innovative efficiency in a dynamic network-aware business world with autonomous agents". Additionally we get larger programms with much more errors which run only on liquid nitrogen cooled Pentium IV at 5 GHz.
It's an open secret that the NASA won't do any manned Moon missions these days because the rocket would explode 2 seconds after launch in a rain shower of 3000 Pentium IV processors due to a software failure in the EBJ on Java on C# on
How do they rate the prospects of... (Score:3, Funny)
Broken OOP Model (Score:5, Insightful)
A real shape library would have methods like isConvex() and numberOfSides() instead of implementing the number of sides as an infinite number of subclasses (triangle, quadrilateral, etc.)
Perhaps these guys should have read Antipatterns [amazon.com] or Pitfalls of Object Oriented Development [amazon.com] instead of wasting their time with this article.
Re:Broken OOP Model (Score:3, Insightful)
This very example tends to lend credibility to the group describedin the article as "craft" programmers.
Showing that slate isn't the proper material by building a wall and seeing it fall sounds like a good proof until the stonemason comes and says, "don't stack it against the grain... see?" and builds one that stands just fine.
-Zipwow
Faulty assumption (Score:5, Interesting)
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.
Re:Faulty assumption (Score:2)
It is very natural to do in Java. Implement it using interfaces, and then use composition to supply the implementation for each particular interface. Each part satisfies the is-a test, the person is an employee, and the person is a student.
Eiffel-like multiple inheritance might be better, but Java interfaces are a
Re:Faulty assumption (Score:2)
"If Fortran can be compiled into machine code, then why not transform some higher-level description or specification directly into a ready-to-run program? This is an old dream. It lives on under names such as generative programming, metaprogramming and intentional programming."
Generic programming is a form of metaprogramming; in fact, they've got a lot of stuff about template-based metaprogramming at the C/C++ Users' Journal these days.
Aspect complements OOP (Score:5, Informative)
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.
Thanks a bunch, a-holes (Score:4, Funny)
Obligatory OOP is dead post (Score:2)
Shell scripts and .bat files are the wave of the future. . .
Declarative languages (Score:2)
The "flow chart model" of computing is and will always be error prone.
Re:Declarative languages (Score:2)
I'm not sure if this is intended as a joke, but it may actually be true.
I like programming in Prolog, since SLD derivation mirrors better the way I think than an imperative language, but I doubt it will be fast enough for mainstream use for quite a few years (by which time we'll have found more complicated things to do, which will slow it down...).
Functional languages, on the other hand, are different. A program in a functional l
Re:Declarative languages (Score:4, Insightful)
Silver bullets (Score:4, Interesting)
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.
Interesting Acronyms (Score:2)
Don't believe the hype (Score:4, Insightful)
Second: this reminds of when the K [kx.com] boys did a big rant about "I prove OO is flawed because if you have a class Person and derive from it Customer and Staff classes then you break stuff when a staff member quits his job and walks into the shop and buys stuff as you need to get the object to mutate classes". They claimed to instead invent "OO++" (they called it that). The correct OO answer is that you've got a poor design, you need to revisit it (and aspects or attributes or roles as concepts may help you think about this), but that doesn't break or replace OO (ie straw man argument).
Now meta-programming, such as the (now rather old but still a head-fuck for those who program in one language only) Meta Object Protocol [franz.com] is the direction that I see code structure moving: more Lisp-like structures and flexibility to change your object protocol on the fly, losing strong typing as a fundamental mechanism for OO, these are ways to let you manipulate the larger level structure of your code whilst keeping the lowest level of syntax constant . You let people write their OO code as they like, but as an over-coordinator you can suddenly change the way inheritance works, or the way method-dispatch works to get different effects. It's what I like about Perl (which is making me realise what all those Lisp hackers were raving about for so long, but I prefer the pragmatic approach of perl over the rather purist lisp).
--
T
Re:Don't believe the hype (Score:3, Interesting)
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,
Naive Article; Ignorant Writeup (Score:2)
Embarassing (Score:5, Interesting)
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
we already have the successors (Score:3, Interesting)
But even OOP doesn't have to be as horrid as it is in Java, C++, or Eiffel. Those systems took a simple object system that worked reasonably well in a dynamically typed context and messed it up by trying to squeeze it into a static type system. Languages like Smalltalk and Python are far better for OOP because with dynamic typing, the simplicity of their object systems is far less of a straightjacket. And systems like CLOS are considerably more flexible. It is kind of ironic to blame OOP for the specific design problems in the object systems of languages like C++ and Java. (Note: C++ is a pretty decent language these days, but mostly because the non-OO parts of it have become very powerful.)
Aspects, XP, and patterns, while not stricly speaking specific to OOP, are really workarounds for limitations of OOP. The problems they try to fix don't exist in that form in many non-OOP approaches. In different words, those systems and approaches add complexity of already messy and complex object systems; that isn't the path to better software development.
OOP Spaghetti and Object Taxonomies (Score:3, Insightful)
#1. Observe that there's no benefit in Convex and Simple inheriting from Polygon. They are abstract classes of polygons classes for which instances cannot reasonably be constructed (because polygons need a number of sides) and, presumably, cannot implement many of the base operations of Polygon that they're inheriting. Thus, the hierarchy can be simplified by making Convex and Simple interfaces.
#2. Another solution to the above observation is to make Convex and Simple mix-ins (if your OOP language supports them).
#3. Don't try to account for two separate properties in a single taxonomy. Make either the number of sides or the type of polygon an instance attribute, rather than part of its type. For instance, we might decide that all polygons, regardless of number of sides, have the same basic set of operations, and so only work with Convex and Simple classes.
Another distinct problem with the diagram is that it mixes what we assume to be instances (a star) with what we assume are classes (Pentagon). From what I've seen, the article deals with class-based OOP, so this is an odd confusion. In fact, the problem it illustrates is perhaps mitigated, if not eliminated, in moving to a prototype-based system.
Re:OOP Spaghetti and Object Taxonomies (Score:3, Insightful)
Correct answer: #4: There is no absolute taxonomy. Every class hierarchy must be designed with due consideration for the application, that is, the manner in which it is to be used. Speculating about possibly representations is meaningless without such a context.
XP as a way of programming (Score:5, Informative)
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 [dreamsongs.com] 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.
Re:XP as a way of programming (Score:3, Insightful)
I have to disagree. It's unlikely that a programmer who can write good test won't write good code. TDD isn't about traditional testing. Its about expressing design through testing. In that environment, if you are writing good tests it means that you have correctly and completely expressed the d
Evolved OOP (Score:3, Interesting)
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.
No silver f-ing bullet, people! (Score:5, Interesting)
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.
Re:No silver f-ing bullet, people! (Score:3, Funny)
Of course there is. In fact, a new entry for the JCP to create a class AnythingDoer is being worked on as I write. From J2SE 1.6 onwards, you will be able to write a program to do anything you want as follows.
type inference from Haskell (Score:3, Interesting)
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?
Why FP isn't much used in reality (Score:3, Insightful)
I'm all for a more declarative programming style where it's appropriate, but some data structures and algorithms are simply much more efficient if you change them in-place.
#include <std_iteration_vs_recursion_arguments.h>
Re:Ok, I see now (Score:2)
Oh well, at least you have the "flame first, then read article" bit down pat.
(Note for future reference: Sometimes even the editors *gasp* misrepresent the articles.)
Re:15min and its down? (Score:2)
Ok, look at how Mozilla's Bugzilla [mozilla.org] usually handles the /. effect (eg. a separate page for /. referals). Setup a simple static page giving people permission to mirror when refered from a /. page. Maybe even have a static copy of your site available as a .torrent and encourage people to use that and start the mirroring process.
True it would be nice if the editors gave these sites some warning, but maybe the webmasters should make some preparations ahead of time.
Re:stupid managers and stupid HR (Score:4, Interesting)
I have to say that, after a few years of reading Slashdot, it seems like programmers have a perpetual thirtysomething syndrome going on--the perception that our problems are somehow unique. They're not. Reread the Hacker FAQ for Managers, and every time the word "hacker", "coder", or "programmer" appears, mentally substitute "employee" and see if you don't get a general management guide that makes sense.
Revolution = coming around again (Score:3, Informative)
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