Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!swrinde!mips!pacbell.com!pacbell!osc!tma
From: tma@osc.COM (Tim Atkins)
Newsgroups: comp.object
Subject: Re: What is Objective C?
Message-ID: <3787@osc.COM>
Date: 11 Sep 90 05:15:21 GMT
References: <3864@bingvaxu.cc.binghamton.edu> <2700002@hpspkla.spk.hp.com> <5524@stpstn.UUCP> <1990Sep4.034131.532@cbnewsl.att.com>
Reply-To: tma@osc.UUCP (Tim Atkins)
Organization: Versant Object Technology, Menlo Park, CA
Lines: 93

In article <1990Sep4.034131.532@cbnewsl.att.com> psrc@mtunq.att.com (Paul S. R. Chisholm) writes:
>In article <401@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
>> It is always surprising to see so many people confusing programming
>> languages and their implementations. . . .  Why is that so?
>
>In article <5524@stpstn.UUCP>, cox@stpstn.UUCP (Brad Cox) writes:
>> I've wondered the same thing, Bertrand . . .
>
>I will try to post this entire article without giggling.  Let me start
>out by pointing out that eiffel.uucp and stpstn.uucp are the Usenet
>systems of two companies which (currently) provide the sole
>implementations of their founders' respective object-oriented
>programming languages and/or environments.  In these two cases, if one
>wants to use the one of the languages and/or environments in question,
>one will find that *the* (singular) implementation is tied very tightly
>to the language and/or environment.

Wrong in at least the Objective C case.  I know Next has their own implemen-
tation and have heard that IBM does also.  In addition Objective-C covers at
least as great a range of platforms as C++.  I do not know of any Eiffel
implementations outside the one by Interactive Systems but they also have
fair platform coverage.  The plus sides of single vendor languages are:

  a) you know the vendor has a stake in all aspects of language use and
     issues as in the cases above their very lives as companies are at
     stake;

  b) portability among supported platforms is much less of an issue when
     only a single consistent version is in existence;

  c) the vendor is much more likely to supply a decent supporting set of tools;

  d) applications that need low level access to the internals do not face
     the incompatibility issues they would in the multi-vendor case.


>
>There *are* languages with multiple implementations.  C++ has been
>implemented by AT&T, Zortech, Oregon, GNU, and Borland, just to name
>companies that are reachable via the Internet.  Parc Place Systems,
>Digitalk, and GNU all have Smalltalk implementations; they're all
>reachable electronically, though Digitalk hangs out on BIX, not the
>Internet or Usenet.  (No, I don't have specific contacts for any of
>these guys!)

Smalltalk has the library and tools issues well in hand for at least 
the "programming in the small domain".  C++ to date, IMHO, does not.
In addition I challenge you to simply recompile without modification 
any but the most trivial application on all the listed C++ products.

>...
>HOWEVER!  C++ was designed so "in theory and with enough work" requires
>very simple theory, and relatively little work.  

How so?  The language is not very well behaved as far as formal language
theory goes.  The amount of traffic on comp.lang.c++ that requires the
intervention of language lawyers would seem to indicate that it is also
not that easy to understand and use.


>So . . . will a program that, by the language definition, must do
>garbage collection, run as quickly as a program where the "user" (the
>programmer in the language in question) must manage memory?  Probably
>not, unless the language implementor has done a terrific job, and the
>"user" has botched it.  

Will a program without GC guarantee the avoidance of mistakes that are
next to impossible to catch by hand particularly in a multiple programmer
environment?   

>Will a program that, by the language
>definition, must do an additional memory indirection, or even a table
>look up at run time, run as quickly as a program where subroutine calls
>can be translated straightforwardly into a subroutine call instruction?
>Same answer.

I don't know which OO does not do this indirection to some degree.  C++ 
certainly does, both for virtual function binding and for finding the
base class portion of an object in the case of virtual inheritance.  Which
language does not allow late binding when that is called for and imposes 
lack of type checking and space overheads for use of MI in an environment
requiring polymorphic container classes?

In short I think there is very little for you to giggle about.

>
>Paul S. R. Chisholm, AT&T Bell Laboratories
>att!mtunq!psrc, psrc@mtunq.att.com, AT&T Mail !psrchisholm
>I'm not speaking for the company, I'm just speaking my mind.

- Tim Atkins

-- ditto on the disclaimer