[comp.lang.smalltalk] Objective-C vs C++

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