Objects Have Failed

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 "SoftwareEngineers" 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.

"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. LanguageDesigners 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 CrossCuttingConcerns as the core language itself, such as concurrency and security) via standard libraries. Without the RightTools, 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.}

{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 CrossCuttingConcerns while avoiding LanguageIdiomClutter. The job of LanguageDesign and API design is to eliminate SoftwareDesignPatterns and FrameWorks 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

EditText of this page (last edited March 11, 2014) or FindPage with title or text search