Starting to veer way off topic, but… 

On Feb 26, 2010, at 7:03 PM, Max Taylor wrote:

> People don't use OOP because they simple don't understand the thought process that goes along with it. Apple lays it out there free for us to use, but they aren't holding a gun to anyones head here. Once you grasp a few basic principles or thought patterns then the light comes on you go "WOW"

I have no problem with the concepts and doubt many here do. What is the challenge is investment in exiting code for many people. 

What I believe is that OOP has not been the magical elixir too many programming "gurus" and industry pundits imagined. (You could date this back to Ed Yourdon's various books on programming theory and the nature of enterprise development.)

The idea of not having to rewrite code is not far removed from various includes and reuse that have been possible since the earliest high-level languages. The problem is that reuse has never quite lived up to the promise for a variety of reasons. Those are academic and business issues that have been studied at length in computer science and IT fields. Apple, with Cocoa, is the closest to the promise I have seen. 

When I use Delphi, I use several purchased component libraries. Unfortunately, as with Apple, when Delphi would change I would need to purchase all new versions of the VCLs I owned. Sometimes, an update to one VCL (Woll-2-Woll's InfoPower come to mind) would crush others that seemed to have no direct relation to the data controls. I'd end up having to track down which "reusable" objects were broken and why. Thankfully, the VCLs came with source code. 

(For all my gripes, nothing beats Torry's Delphi Page: http://www.torry.net/ for components and proof of what Apple could do with Objective-C.)

Not having to write code is more an aspect of the framework and/or the UI API on a platform. A good (or bad) framework can exist in any language. Combined with a RAD IDE, you can cut coding down substantially. The most common example are "RTF Editors" in any number of languages / IDEs. Drop TRichTextEdit on a form and magically you have every feature you'd ever want in a text editor. That has nothing to do with object orientation, though. OOP would be the ability to create a subclass of TRichTextEdit and add new features, then create yet more subclasses of that… and on and on… 

You can write very little code and get great features if you master Xcode and Objective-C. However, that's more a matter of how tightly Apple has wedded Interface Builder (and nibs) to Objective-C / Cocoa. (You can do a "Text Editor" in Xcode without writing any code, technically.)

Also, there are different forms of OOP implementation. Objective-C relies heavily on a Smalltalk model, while I would argue C# takes a different model. Similar, certainly, but these can confuse people switching from one to the other. (I think C# is somewhat elegant, though that's probably because it resembles my own habits and not for any technical reason.)

> You are right here. ObjectiveC is just a means to an end. Cocoa is the culprit here and the toughest part of the process with so many classes and methods. The advantages are that if we learn to use those classes and methods then any updates Apple adds to any of those methods we get for free and do not have to modify our code to get.

Cocoa has changed, as has Objective-C, with every OS update. Usually, only a few things break, but so far each new Cocoa revision has meant you can only target one or two versions of the OS if you use new features. This deals with dynamic libraries and other things, some far beyond my knowledge of how Apple  is doing things.

Programming is an art, science, and even psychological mirror. 

For me, I love to try most languages and tools to explore their philosophies. However, I'm not convinced that OOP is "better" or even "best" for some tasks. At the same time, a procedural language might not be ideal for projects that benefit from multiple, similar "objects." 

If someone said you can only use one, and only one, language, I'd certainly say Java is the clear path right now. But, thankfully, I can use a half-dozen languages and several tools for different dialects. 

Ideally, FB remains an option on the Mac. 

Anyway, topic beaten to death… Hopefully others try some of the tools out there and see what they like/dislike about each. I just do not want Apple to be the one and only arbiter of compiler tools on the Mac for OS X desktop development. (Note: I write "desktop" because other languages embraced by OS X: Ruby, Python, Perl, etc.)

I don't think we have a major disagreement -- I'm simply worried to see any one tool dominate a platform so thoroughly. Apple has a history of switching things on developers without warning.

- C. S. Wyatt