Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!yale!bunker!ppi!cox From: cox@ppi.UUCP (Brad Cox) Newsgroups: comp.lang.misc,comp.lang.smalltalk,comp.lang.c++ Subject: Re: C++ vs Objective-C Message-ID: <1661@ppi.UUCP> Date: Tue, 20-Oct-87 14:14:50 EDT Article-I.D.: ppi.1661 Posted: Tue Oct 20 14:14:50 1987 Date-Received: Fri, 23-Oct-87 07:22:23 EDT References: <3405@ece-csc.UUCP> <638@its63b.ed.ac.uk> <1811@watcgl.waterloo.edu> <1549@pdn.UUCP> Organization: Productivity Products Int'l, Sandy Hook, CT Lines: 114 Summary: Is Objective-C a compiler? (ppi!cox; long!) Xref: mnetor comp.lang.misc:762 comp.lang.smalltalk:368 comp.lang.c++:527 In article <1549@pdn.UUCP>, bob@pdn.UUCP (Bob Hickle) writes: > In article <185@geovision.UUCP>, alastair@geovision.UUCP(Alastair Mayer) writes: > > Sorry, no. Objective-C is indeed a preprocessor, but C++ is a C > > superset and the C++ 'program' is actually a *compiler* for the language > > C++. It is C++ (specifically the 'cfront' pass) that does the syntactic > > and semantic analysis. > > Wait a minute here! The Objective-C COMPILER is just as much a compiler > as the C++ compiler. The Objective-C compiler does parsing, syntactic and > semantic analysis of the Objective-C language. It builds parse trees, etc > just like other compilers do. > > > The release version of C++ does happen to use your existing C compiler > > as a code-generator. However, the output from C++ is a C-language version > > of the internal parse tree, ie new code, not the old code with the C++ > > extensions translated. I understand that the C++ compiler used internally > > at Bell Labs bypasses this step. > > > Well heck, the output of ANY (working) compiler is some concrete > representation of the internal parse tree. Anyway, I believe (but may > be wrong here) that the Objective-C compiler also compiles the ordinary > C code in an Objective-C program. It just happens to produce output > which is the same C code. That does not mean that it has not been > compiled (ie. parsed, syntax checked, etc). > > I see that PPI (the vendor of Objective-C) is now on the net. > Any comments from them? The distinction between a compiler and a preprocessor is not crisp enough to argue about. For one thing, the debate is not about the two LANGUAGES, but techniques for IMPLEMENTING the two languages. Both languages have more than one implementation, and many of these do not involve a backend C compiler at all. Before tackling your question, a proviso about the debate itself. I find language debates relatively uninteresting. Each time a new language has appeared over the years (assembler language, Fortran, Pascal, C, Ada), there was a lot of excitement initially, and certainly some improvement in programmer productivity. But the improvement has always turned out to be arithmetic in impact. The geometric improvements needed to bring our productivity in line with that of hardware engineers will not result from better programming languages, but by focusing our attention outside the language. For example, by learning to program by producing and reusing components from large libraries of pre-tested Software-ICs. Yes, these libraries are hard to build, and expensive. But each well-tested, well-documented library component provides a geometrical improvement to the productivity of each of its users, and the improvement is open-ended, unlike the productivity enhancement of features that are hardwired into a new programming language. Accordingly, there is little to be excited by in the new syntactic features of Objective-C, the language. The excitement is entirely in the Software-IC concept itself that the extensions enable, and in the large Software-IC libraries where most of PPI's effort has been focused. Objective-C, the LANGUAGE, is merely C, the LANGUAGE, plus several extensions to provide object-oriented programming techniques to the C programmer's toolkit needed for suppliers and consumers of Software-ICs to collaborate in a loosely coupled fashion. The extensions are parimarily an additional type-name, 'id', analogous to the old C type-names like `char' or `int', and an additional kind of expression, the `message expression', analogous to old C expressions like the addition expression, +, or the function-call expression, (, ...). Several other extensions provide syntax for defining new classes (Software-ICs) and their methods. The extensions are syntactically minimal, but uncompromising in their support for loosely-coupled development. The philosophical differences between C++ and Objective-C revolve around how strong the coupling should be between suppliers and consumers of code. C++ provides better support for strongly-coupled development than C, (better static binding, strong type checking, etc), while Objective-C retains C's support for strongly-coupled development tasks. Its extensions are entirely to provide tools for supporting loosely-coupled development. Regarding the original topic of the debate, Objective-C language can be, and has been, implemented in many ways. For example, our Objective-C interpreter implements Objective-C language in a fully interactive fashion, without invoking any part of the traditional C tools chain (preprocessor, compiler, assembler, linker, loader, etc), by using traditional language implementation techniques (lexical analysis, parsing, code generation, etc) to perform all of these steps itself. The advantage of this implementation is rapid edit-debug turnaround, and the cost is slower execution speed. By contrast, our Objective-C compiler implements Objective-C language by relying on a backend C compiler for code generation. The frontend performs all of the traditional tasks of any compiler (e.g. lexical analysis, parsing, expression tree building, symbol table management, typing, etc), but it generates a portable representation of the code by generating C source code rather than some non-portable representation like assembly language or machine code. The advantages of generating C code is nearly automatic portability across different machine environments (we don't need to reimplement a machine-dependent code generation pass for every target environment). The advantage of the compiler over the interpreter is execution speed, while the cost is the slow edit-debug turnaround time of traditional C development tools. Luckily, the compiler and interpreter compliment each other. When my code is young and unstable, I process it exclusively with the interpreter to minimize turnaround time. As it begins to mature and stabilize, it pays to process it with the compiler and link the compiled code into the interpreter to make it run faster while serving as substrate for other parts of my system that might still be under development (e.g. as interpreted code). When my system stabilizes and is ready to ship, I merely remove the interpeter and ship only the compiled code. Or if my system is a linkable library of components instead of a fully linked application, I might even chose to provide a demo version of the library as compiled code linked into the interpreter so that our customers can learn the components by trying them out online. Brad Cox Vice President Productivity Products International 75 Glen Road Sandy Hook, CT 06482 (203) 426-1875