At OOPSLA 2002 (OopslaOhTwo), there is a grand debate on the failure of objects.  The panelists are:

"Objects Have Failed": RichardGabriel and BrianFoote

"Objects Have Not Failed": GuySteele and JamesNoble

The audience was encouraged to provide various comments and/or questions for the panelists before Friday's vote. 

-------------
See VariousIdeasOnWhyObjectsHaveNotFailed. 
----
Was it intentional on the part of the organizers that the "Not Failed" pair were neat-as-a-pin conventionally conservative in appearance, and the "Have Failed" pair were of the long-hair casually dressed type?
----
Good eye.  Yes, that was entirely premeditated. In fact, I thought Guy was dressed more
casually than had been planned.  The idea was to subtly imply that objects have
been good for tweedy academics and have made a few people a lot of money, but
perhaps have left the hackers and idealists behind. Evidently we succeeded
on at least a subliminal level. The lengthy resume recitations for the
team opposing the resolution were supposed to stand in contrast to
the relatively humble pedigrees of the failed side, and hence reenforce
this implication --BrianFoote

''I thought the panel would be half over by the time GuySteele's resume recitation was finished <wink>''
-----
"objects have been good for tweedy academics and have made a few people a lot of money, but perhaps have left the hackers and idealists behind"

Interesting thought.  Anecdotally it does seem that the programmers using objects are more likely to be "SoftwareEngineer''''''s" in traditional business and academia of the buttoned-up sort, and that the programs written by hackers and idealists are less likely to make use of objects.  A good quantitative measure could be taken by looking at a sampling of projects on SourceForge and seeing how many are object-oriented, for some definition of that term, and how many are organized along other programming principles.  A comparison then with commercially-developed and in-house software would be in order as well, although getting the source to those would be a challenge.  If one looks at games programmers as among the hackers and idealists -- a reasonable proposition -- then there is a clear aversion to objects. --StevenNewton

--------
I think it's safe now to say it's '''failed to be a panacea'''. It has found some nice niches and makes a handy tool to have in your tool-box for certain API's, but "everything objects" is dead except from the most dedicated fans. --top

''In reality, object oriented programming (though perhaps not in a "pure" SmalltalkLanguage sense, alas, and perhaps not "good" OO but OO nontheless) is pervasive in the software development world.  Job openings demand C#, C++, or Java.  Though games developers once shunned object orientation, C++ is now ubiquitous in the entertainment software industry.  The vast majority of new in-house applications for end-user deployment in virtually any organisation are written in popular OO languages.  Popular programming languages are almost invariably highly (albeit static) OO (e.g., C#, Java), or at least have OO capability (PHP).  "Everything is objects" is the default teaching position in a large number of colleges and universities, and the average CodeMonkey embraces the notion without question.  Certainly OO has failed to be a panacea, but what in IT is ''ever'' a panacea?  However, OO is so prevalent that understanding it in depth -- even if your programming job is non-OO (like writing shell scripts or code for embedded controllers) -- is vital in order to be considered a knowledgeable professional.''

{It's a good thing for at least one person here who doesn't understand it in depth if ''"not understanding it in depth [...] is vital" [sic]''. ;) [Oops! Fixed :)] Anyhow, EverythingIsa <pick your poison> is going to fail, somewhere. OOP in particular is weak for the problems towards which reactive and logic programming styles are strong, and vice versa. Even if programmers are stuck with C++ or Java or C# at work, knowing a variety of paradigms helps one understand and formulate SoftwareDesignPatterns. Of course, SoftwareDesignPatterns attempt to cure a symptom, rather than the cause (they're a MissingFeatureSmell). A language with the right primitives, supporting a broader range of orthogonal concepts (e.g. OOP+reactive, push and pull respectively) may avoid the need for many design patterns and be more readily optimized for many common problems. }

What the language supports and actual usage are two different things. Vendor libraries indeed tend to be OOP, but production code is often just procedural code in OOP clothing.

''In-house developers have always demonstrated mixed abilities.  Some will be good at OOP, and some will be bad at it.  Of course, some will be good at procedural programming and some will be bad at it.  (Good programmers, it seems, are good at everything and it doesn't really matter what paradigm they use; bad programmers are bad at everything and no paradigm helps...)  Indeed, any job has folks who are good at it and folks who are bad at it.  I suspect this is no worse in IT than, say, cabinetry, cookery, carpentry, plumbing, auto repair, medicine, journalism, writing, cleaning, fishing, hunting, painting, politics, prostitution, sales, marketing, etc.''

* There is an implication above that the non-OO designs are the non-skilled designs. I'm not sure I agree with that. People can and do mis-use OOP, but it's difficult to describe to them why it's a case of mis-use because the metrics for "good code" are difficult to objectively document. DisciplineEnvy. OOP seems fairly good at making the WalledGarden that a vendor wants to present. But when it comes to integration of many interrelated and often-changing business rules in domain work, a WalledGarden is often a bottleneck. -t

* ''Can you show an example of procedural code being superior to object-oriented code, when both have been written by a skilled developer?  Can you provide evidence for the notion that "OOP seems fairly good at making the WalledGarden that a vendor wants to present."  Also, could you explain what that means?''

* Moved rest of discussion to "Mutually-Exclusive Status Change Example" under PolymorphismLimits.

"Good" and "bad" is often relative. I've seen people who write spaghetti code fast and other people who think like them can figure it out fast. I don't know how; they both must be Martians. Hopefully people at least follow the basics: comment well but not redundantly, break things up into functions or units where it's prudent, document the interfaces and dependencies well, choose clean design over fads, and try to spend some up-front design time to keep it simple but easy-to-change rather than just code the first design that comes to mind. The paradigm or language choice is secondary to doing the basics.

''I agree.''

''Oh, stop weeping.  There's no need to get emotional; you '''knew''' we were going to agree on something eventually.''

{Well, I disagree on two points. First, outside of SystemsSoftware development (i.e. developing APIs and languages that will be used by developers outside your team), up-front design is of questionable value. So long as there are no code-ownership boundaries to cross one may always RefactorMercilessly, later, and doing so 'later' will offer the developers much better information about what needs doing and (simultaneously) support more RapidApplicationDevelopment since one may focus on the features needed 'now'. Second, you cannot simply ask developers to 'be prudent'. Even excellent programmers need the right tools, lest they end up writing boiler-plate, spaghetti-SoftwareDesignPatterns, and reinvent tools of the ''ad-hoc, informally specified, bug-ridden, slow'' variety. LanguageDesigner''''''s are prudent to identify as many of these repeated reinventions as possible and ensure they are addressed via language primitives or in a composable manner (one that ''minimally'' addresses all the same CrossCuttingConcern''''''s as the core language itself, such as concurrency and security) via standard libraries. Without the R''''''ightTools, doing the RightThing - the 'prudent' thing - is often no easier than building a castle in the clouds.} 

{OOP is perhaps ''a'' right tool - it addresses a few concerns quite well (dynamic configuration, capability security, and reifying protocols and services in a manner that supports multi-instance concurrency). But the concepts of OOP fail to address many other concerns - including external resource and data integration, data management, and data processing, error handling, concurrency, synchronization, persistence, distribution, disruption tolerance, resilience and self-healing, data-flow security (i.e. ensuring passwords don't cross trusted lines), ProcessAccounting, DependencyInjection, declarative (goal-based) application/service description, domain-safety (real-time, energy management, noise management), planning (forward and backward chaining), and so on.}

* Oh oh, I've heard this list before. Shields on stand-by! -t

{EverythingIsa is a poisonous concept, albeit an alluring one due to the whole TheoryOfEverything angle and all the MentalMasturbation and arrogance behind it. But pragmatic LanguageDesign ''must'' take OOP for exactly what it is - a small set of concepts (dynamic instantiation and linking of names that can receive messages and behave in opaque manners upon receiving them) that support a small set of orthogonal concerns - and carefully add many more concepts to support programmers in CrossCuttingConcern''''''s while avoiding LanguageIdiomClutter. The job of LanguageDesign and API design is to eliminate SoftwareDesignPattern''''''s and FrameWork''''''s and BoilerPlateCode, or at least keep it shallow.} 

EverythingIsa applies inside a paradigm and not across paradigms, right? It is just a point of view that can be conveniently applied to solve specific problems. --LuizEsmiralha

{Appealing to SelfDiscipline and prudence is reasonable once you're stuck with an unsuitable tool, but should be an appeal of last resort. A ''language'' should appeal to LazinessImpatienceHubris, even encourage it, supporting programmers in achieving "good" results in a very wide range of use-cases even without SelfDiscipline or wisdom. ExploratoryProgramming, iterating via progressive refactoring from 'get it done quick' solutions by programmers who are initially clueless about which abstractions they need (and, likely, initially clueless about which abstractions are available) should be the 'default' mode for development. The LanguageDesigner, not the developer, is the one who should step up and be 'prudent'.}

Discussion continued at SelfDisciplineDiscussion.

----
First you have to ask for clarification: "failed at what?"....
----

See VariousIdeasOnWhyObjectsHaveNotFailed, ArgumentsAgainstOop
----
NovemberZeroNine