Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: Objective C: Flame Fodder
Message-ID: <6590108@hplsla.HP.COM>
Date: 28 Apr 89 16:55:05 GMT
References: <5007@tekgvs.LABS.TEK.COM>
Organization: HP Lake Stevens, WA
Lines: 28

> Some of the demo code has source with it, and is most certainly Objective C.  
> This leads me to think that, well sure, the implementation of C++ is optimized 
> for execution efficiency, but who cares?  The NeXT user interface puts X11 to 
> shame -- is that the result of Objective C having better efficiency in the 
> *coding* phase, versus the *execution* phase?
> 
> Does anyone know to what degree the NeXT graphics system code is written in 
> Objective C?  If a large proportion of it is Objective C, then I think the 
> relative performance issue is a non-issue.

I think what you will find is that ObjC is being used as a veneer over some
very fast code written in asm and standard C.  If an ObjC message causes
the execution of a few thousand asm or straight-C statements, as can easily
happen in the execution of a high level graphics call, then the messaging 
overhead becomes a don't-care.

Other approaches that work just as fast in the same situation are: purely
interpreted languages [which have the advantage of not mixing two syntaxes
together], applications that make window environments interactively, etc.

The goal of C++ is to make OOP affordable across the whole range of
programming activities, not just "high level" programming.  For very
high level programming, C++ is presently at some disadvantage for not
having an integrated development environment.  It may make up for this
disadvantage by being the fastest OOPL, and the most widely available.
It may be worthwhile to put up with less in the way of a development 
environment in order to have the code that runs the fastest, and is
available on more machines than anyone else.