🚀 go-pugleaf

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,
<expression>+<expression>, or the function-call expression,
<expression>(<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