cox@ppi.UUCP (Brad Cox) (10/19/87)
This is a reposting. My (numerous) earlier attempts to get this on the air failed because of Usenet/NFS gremlins too numerous to mention. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is a (long!) reply from Brad Cox, the originator of Objective-C, in response to >> csrdi@its63b.ed.ac.uk (Rick Innis, CS4) >>... I'd also like C++ and may well end up porting that myself, but I've >> been told that Objective-C is a better language.... > > Doug Moen (U Waterloo CGL) replies > Strange...My understanding is that C++ is a better language. > ... > I'd be interested in seeing the opinions of people who have had > non-trivial experience with both languages ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ C++ is an ambitious programming language. Objective-C is the language component of an ambitious programming environment. The two languages have remarkably little in common except that some of their implementations invoke the native C compiler to assist in code generation. For example, our Objective-C Compiler does generate C code, but our Objective-C Interpreter does not; it implements Objective-C entirely on its own. C++ and Objective-C are different tools for different jobs and it is tough to compare them without being specific about the jobs you intend to use them for. > Objective-C is apparently C with Smalltalk code embedded using escape > sequences Objective-C language is a hybrid between C and Smalltalk in precisely the same sense that C++ is a hybrid between C and Simula. Their differences stem from the fact that we've focused our energies outwards, towards building a comprehensive programming environment, rather than inwards, towards building a more comprehensive programming language. > The problem with Objective-C is that you deal with two universes; the > C universe and the Smalltalk universe. Why is this a problem and not a virtue? Multiple tool universes seem necessary and desirable for activities as complex as production system-building. It is not a problem that the tools in my woodworking workshop `force' me to think in separate universes for drilling, sawing, and planing, or that Unix `forces' me to deal in a C universe for some things and a shell universe for others. On the contrary, each tool leaps to hand in a twinkling, and I can pick them up or lay them aside according to the job on hand. In Objective-C, I move smoothly between conventional C tools (functions, data, macros) for micro-granularity problems, classes and objects for ordinary work-a-day granularity, and other tools (lex, yacc, pipes and filters) for macro-granularity. Multiple tool universes also means that ambitious features can be added to support higher (object-oriented) levels without impacting lower levels. For example, we've implemented automatic garbage collection for the object-oriented level of the system while not impacting lower-level issues like ANSII standards and the predicatable fast response times of ordinary C. Although I like the integration of support that C++ provides for the small granularity problems of program-building, Objective-C focuses on providing better coarse-granularity support for large-scale system-building. C++ has made a number of compromises in the interest of efficiency that compromise system-building objectives, such as the lack of a central messager, not preserving information about types into the run-time environment, and a limited interpretation of dynamic binding, a vestiage of its Simula roots. What do I mean by `programming environment'? At present, we don't yet provide a fully iconic programming environment like Smalltalk's. But we're certainly building incrementally in that direction. The ICpak-201 discussion to follow should make this clear. Unix and its suite of reusable tools are an environment, and Objective-C's environment is presently of the Unix flavor. In addition to Unix tools, the Objective-C environment includes 1) Two implementations of the language, a compiler AND an interpreter. Only the compiler generates C code. The interpreter fully implements Objective-C language (and ALL of C) on its own. The interpreter supports the front end of the development process by allowing code to be developed, tested and repaired with instantaneous turnaround. The compiler supports the back end of the development process by building fast, compact code suitable for production system-building. The compiled and interpreted environments are compatible. My normal way of working is to develop totally inside the interpreter. Occasionally, to optimize execution speed, I compile the code thus developed, link the resulting code into the interpreter, then override it with interpreted code as I uncover bugs or make extensions. And my normal way of publishing compiled code so that others in my shop can use it is to distribute an interpreter with the code linked inside it along with relatively concise documents about how to explore the new code's facilities. This is a real improvement over the alternative; the conventional encyclopedic reference manual. My users can explore the code and learn it on their own, rather than having to absorb the information through a reference manual. Furthermore, the most recent version of the interpreter (which isn't available to me yet; Real Soon Now!) supports dynamic linking and checkpointing thus eliminating the need to periodically shut down and to link with compiled code. The lack of similar support for prototyping and debugging is a major shortcoming of C++. 2) Comprehensive and fully-supported foundation libraries: We think that radical improvements in programming technology (comparable to those that the silicon chip technology brought to the hardware industry) will not come from better programming languages, except insofar as those languages help to foster widespread code reusability and loosely-coupled cooperation between diverse developers. Our energies have been spent on building ambitious libraries. For example, our Object class implements the Objective-C memory model that all other classes inherit. This class implements two methods, storeOn:aFileDescriptor and readFrom:aFileDescriptor, that let any object convert itself from object-oriented form (reference-intensive) to packet-oriented form (value-intensive), and back again. This puts generic support for distributed and/or persistent object systems into every object, whether built by PPI or its customers, now or in the future. Furthermore Objective-C uses a central message function to dispatch messages between objects. This function is written in C and its source is automatically provided for customers to enhance as they choose; for example, by enlisting the storeOn:/readFrom: services in their own distributed or persistent object system. A comprehensive library of Collection classes is also provided. They are fully supported parts of the Objective-C environment because we felt that providing a conherent and stable foundation was essential to foster the loosely-coupled cooperation between diverse developers I alluded to before. 3) ICpak-201; iconic user interface library We have just announced an ambitious library of Software-ICs for building iconic user interfaces that are portable across diverse windowing environments including X-Windows, SunWindows, and others. This library is our first step towards creating a comprehensive program development environment for Objective-C analogous to Smalltalk, MacIntosh, etc. For details, see my article in Byte Magazine, August 1986, or Chapter 9 of my book, Object-oriented Programming, An Evolutionary Approach, Addison Wesley, 1986. 4) The Producer software that I recently released to net.sources.misc (August 1987) is also part of the environment. Producer is a tool for translating Smalltalk-80 code to Objective-C so that Smalltalk-80 can serve as an extension of the Objective-C programming environment in support of the rapid-prototyping end of the program development lifecycle. 5) Coming soon: automatic garbage collection, dynamic linking, multiple inheritance, more static binding, inline procedures, coroutining, distributed computation, persistent objects, exception handling, blocks, ProcessInspector, automated testing procedures, ... These are not pie-in-the-sky ideas. Nearly all of these are at least in advanced development and should begin releasing starting early next year. This is much too long already. Contact me directly for details. Brad Cox Vice President and Chief Technical Officer Productivity Products International 75 Glen Road Sandy Hook, CT 06482 (203) 426-1875