次の方法で共有

OOPs, I did it again*

  • [アーティクル]

Not content to let sleeping blogs die, Nick roasts yours truly in a further attempt to show how deeply we Just Don't Get It. Man, this is, like, turning into one of those cool, 1990s era, east coast - west coast rapper wars. Except we're two nerdy software guys from Seattle and Minneapolis. And both utterly lacking in bling. And we're not rapping. Other than that, it's totally the east - coast west coast rapper war thing. Fo shizzle. Anyway, back to my point...

While Nick dissects my opinion on several points with the enthusiasm of an 8-year-old with a pocket full of tokens at Chuck E. Cheese, my feeling is that he's missing the forest though the trees. Or perhaps I didn't adequately express my primary point in my earlier post. Either way, I'll be more pithy here so as to keep focused.

The point I was trying to get across is this: All commercial OOP frameworks have warts. It's much more difficult to tie one's shoe than it is to pick apart the niggling anti-OOP patterns in a given framework, let alone one of the breadth and depth of FCL.

In my previous post, I chose to take the "aw, it ain't so bad" tack in response to Nick's charges. I could have chosen a different tack, perhaps an article called "Microsoft ain't the only one that doesn't get OOP," waving the dirty laundry of Nick's apparent framework of choice, VCL (of which I am an author, by the way), and other commercial frameworks. However, this would be neither polite nor productive. Again, there is a lot of OOP badness out there, so that wouldn't exactly be a challenge. Recognizing that all frameworks of their shortcomings and occasional design issues, the most important things are whether a framework is consistently and predictably designed and whether it makes you more productive.

Despite my effort to take the high road here, I can't resist calling out one point from Nick's post that particularly sticks in my craw:

"Steve does argue a few points in favor of sealed -- that a class may need to be sealed to help the compiler. I counter that OOPishness knows not, and should not know, of compilers."

This is a remarkably idealistic point of view -- ideal and also quite impractical. What a truly beautiful world it would be when everything could be an object and developers were free to extend primitive types with impunity. The problem is, this has been done in the past (e.g., Smalltalk) and it has failed to achieve commercial success, largely because it's impossible (today, anyway) to make a language perform at a level acceptable for most applications without primitive strings, ints, bools, etc. Modern OOP languages try to blend the ideal and the practical to deal with this problem. Java has both primitive and object varieties of ints, strings, etc. C# uses boxing and unboxing to work around this issue in an arguably more elegant way.

It's very easy to stand on the sidelines and point out the flaws in this or that framework, but the fact that every commercial framework has flaws would seem to indicate that OOP perfection is difficult or impossible to achieve in a world where performance trade-offs must be made and schedules make it impossible for absolutely every feature to be of perfect, pure design and implementation.

*If you get the double entendre, you should, like me, feel shame for your simultaneous grasp of software development and bad pop culture.

Comments

  • Anonymous
    July 25, 2005
    The comment has been removed
  • Anonymous
    August 09, 2005
    Well, thanks for reminding me that I've been developing in an impossible language for the last 5 years or so. I think you are totally wrong about the lack of commercial success for Smalltalk, but it'd take too long to explain here. Performance problems aren't one of them (at least not during the last decade, roughly).
  • Anonymous
    August 09, 2005
    I haven't used Smalltalk in years, so it's good to hear some of the perfomance issues have been addressed. There's no doubting that performance used to be a major issue, and the market had probably already moved on by the time they were addressed.

    Interestingly I had trouble finding meaningful benchmarks to educate myself on where Smalltalk is today in terms of performance. The only things I could find were very directed benchmarks by Smalltalk fans (e.g., "look, message passing and memory management are fast in Smalltalk"), but nothing that seemed to impartially compare with other languages for common benchmarking algorithms, etc. Pointers to such data would be appreciated.

    That aside, though, there's no getting around Smalltalk commercial failures. The TIOBE numbers bear that out: http://www.tiobe.com/tiobe_index/tekst.htm
  • Anonymous
    August 09, 2005
    You fallen victim to the classic blunder, the most well known of which is don't get involved in a land war in Asia. But only slightly less well known is this: Never mistake a product's commercial viability with its technical viability. For years, you watched Delphi languish compared to wildly inferior products based largely on the company BEHIND the product.

    In other words, Steve, that is sooooo 1998.

    When IBM was backing Smalltalk in the early-to-mid '90s, it did pretty darn well. As it would were Sun or Microsoft (or IBM, for that matter) to pick it up now. And nobody would question whether or not its developers "got" objects. <s>

    (See, I can make pop references with the best of 'em.)
  • Anonymous
    August 10, 2005
    >>You fallen victim to the classic blunder, the most well known of which is don't get involved in a land war in Asia.<<

    Good advice. I'm going to unconditionally retreat from this one before this language border skirmish becomes an all-out shooting war.

    But I can't be held responsible for the fact that yet another domino has fallen, according to the infamous Smalltalk domino theory. ;)
  • Anonymous
    June 12, 2009
    PingBack from http://insomniacuresite.info/story.php?id=8313