Linked by Jared White on Thu 24th Apr 2003 17:49 UTC
General Development There are two major varieties of Cocoa available. The first variety, possibly the more well known of the two, is the kind that you can use to make a nice warm cup of chocolate milk. While tasty, it's hardly proper subject matter for an operating systems information site. The second variety is far more on-topic: a programming environment for Apple Mac OS X that is the modern evolution of of the original NeXTSTEP frameworks. That's what I'm here to talk about today.
Permalink for comment
To read all comments associated with this story, please click here.

As a long time Smalltalk (20+ years) and NeXT/OpenStep (12+ years) user/developer, who currently uses BOTH systems, I find that they each have their advantages and attractions. Certainly Smalltalk code is easier to read and just as certainly the OpenStep GUI is amazing (Win95 was cloned/devolved from it).

Objective-C is an excellent language with it's well known merging of C and a variant of Smalltalk syntax, however since it lacks true automatic memory management I find my programming style must change significantly to take this into account. While programming in Smalltalk one can simply forget about memory issue, for the most part. This definitly affects style, effort, complexity and other factors in developing software.

The real pleasure of Objective-C on the OpenStep platform is the library of objects in the Application Kit Framework. These are simply designed very well and pack a mean punch. The compact size and potent density of the frameworks are comprehensible to most programmers thus they are very usable. One can write very powerful applications with it, as evidenced by the many awesome NeXT/OpenStep/Coca applications that have been written.

Any language with full automatic memory management has it's advantages over those without. In this regards Java joins Smalltalk, Lisp and others in being "better" than C, C++ and Objective-C.

Languages that make the name of "parameters" in a method part of the method name seem to make the programs much easier to read. This is especially important for large teams. Smalltalk and Objective-C programs are amoung the easiest to read as they have "literate programming" principles built in.

It's also important to have access to the source code or documentation via "browsing" tools while reading the source code of large and unfamilar systems. This is even more important for langauges like C++, C, Java, etc.. where the function names are not so readable

The differences in the lanuages and their supporting libraries make a difference, including a significant difference, in the outcome and the path taken to get there.

I for one, prefer languages like Smalltalk, where the syntax is as easy to write as it is to read. While I can program in lanaguages like Java, C++, Perl, Python, Objective-C, C, Assembly Language, etc, they are much harder due to their "syntax".

It really depends on what you are trying to accomplish. The technicial success of the Objective-C based OpenStep/Coca applications and systems shows how even a few of the principles of Smalltalk can have a huge impact upon the outcome.

The libraries of objects in the many dialects of Smalltalk have variation and have evolved to meet the needs of the various their target markets. Smalltalk and it's libary of objects, while powerful, aren't perfect, which tool is?

The GNUStep effort offers a complelling opportunity with the merging of Smalltalk within the OpenStep standard. Good looks with a good language. It's worth tracking, using and contributing to.

There are features of languages that can make significant differences in readablity, ease of use, performance, cost, maintainablity and overall results. I'm most interested in and my choices motivated by the features of languages that take over some of the burden from programmers (and shift it to the machine leading to a reduction in cost of development and overall development time). This is the purpose of progress after all, isn't it?

There are tradeoffs with each language feature. For example, automatic memory management makes a huge difference in productivity with a tiny cost in run time performance.

Un-typed data/objects, as in Smalltalk, make a huge improvement in productivity. Some "every data item must be typed" aderants are concerned about run-time bugs. In practice, bugs occuring in untyped systems have more to do with the "architecture" and "design" than with the "untyped" characteristic. There are some situations where having types is important and it may well be that a typed language is better suited to the task.

Regardless of which language you use it's obvious that architecture and design of the supporting object, data and code libraries playes a significant difference.

The success of the architecture and design of OpenStep reveals this. While Smalltalk is a better language and it's core object library beats OpenStep's/Coca's hands down, OpenStep has an excellent feather weight Application Framework that goes a long way towards success. NeXT put their design attention on what people SEE after all!

The bottom line is computer languages are tools and tool selection for any particular job is an important aspect in many, but not all, projects. There is more than one road to Rome, after all. The tower of babel is the reality in the landscape of computer languages. Interoperation systems such as XML are paving a way for systems created in most, if not all, languages to be able to communicate. At last applications and systems developers are freed from many of the constraints placed upon them by others who prefer different choices. Overall architecture and design influence systems as much as - if not more than - which language you happen to choose to utter the prgram in.

May you choose your tools well for the task at hand, which by the way includes the choice of language for building operating systems. The language of choice for the operating systems project that I'm working on is a language that is evolving from Smalltalk and Assembly languages and advanced application frameworks such as OpenStep. There are enough cpu cycles now to raise the importance of architecture and design above that of simple raw performance. The computer age has just begun and the future is wide open for the systems of your dreams.