Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!brutus.cs.uiuc.edu!apple!well!mitsu
From: mitsu@well.UUCP (Mitsuharu Hadeishi)
Newsgroups: comp.lang.smalltalk
Subject: Re: Questions from a novice on development environments...
Message-ID: <14373@well.UUCP>
Date: 31 Oct 89 00:33:57 GMT
References: <6023@tekgvs.LABS.TEK.COM> <9987@alice.UUCP> <6038@tekgvs.LABS.TEK.COM>
Reply-To: mitsu@well.UUCP (Mitsuharu Hadeishi)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 106


	Yet I disagree that the gap between C++ and Smalltalk is so
unbridgeable.  Consider the following design, which I implemented as
an advanced development project at Electronic Arts last year (what
follows includes some improvements on what we did, and I should note
that I no longer work for EA as an employee so I cannot speak for that
company, and though my company is now considering implementing another
version of the system, we may not have the adequate resources or time to
do so, and if anyone out there is interested in funding such a project
please contact us!):

	One replaces the virtual function table method lookup system with
some type of fast hash message selector scheme.  One then creates a
system which is a hybrid of C++ and Smalltalk: an interpreter which
uses dynamic typing, though also includes compile-time type checking,
and a compiler which uses static typing, though uses the hash table
method-lookup scheme if a method is marked "virtual" (or whatever term
you choose).  You set up the system so that a compiled method may call
an interpreted method and visa-versa, and if a compiled method calls
a compiled method, it is either a direct C function call or a method-lookup
followed by a C functional call indirect via a function pointer.

	The upshot is you have a system with compiled speed but
interpreted flexibility.  You can change or add interpreted methods
even while the application is running, and you can change compiled
methods to interpreted if they are marked virtual (i.e., if they are
called via a message lookup, which means the system can replace the
compiled method's entries in the lookup tables with the interpreted
method).  Since message lookup is via a true hash table lookup scheme
(of whatever sort you prefer to implement) you have full dynamic typing
for those objects you wish to treat dynamically.

	For those objects you wish to not have the overhead of a pointer
to a lookup table, since they are completely statically typed and are
never treated polymorphically, the interpreter simply keeps around some
"fixed-type" lookup tables for these types.  They can still have interpreted
methods, but there is no polymorphism for these types.

	Well, actually, not quite none.  In some cases you may wish to
write completely generic code which can even handle these "fixed" types,
in which case you simply pass the lookup table pointer and the object
value separately.  For example, one can implement a generic Dictionary
that could associate numbers (i.e., a C int) and objects OR objects
and objects with no difficulty.  One could distinguish the arguments
to these methods by calling the argument type "Generic*" (or whatever)
instead of "Object*".  That is, a Generic* is really a lookup table
and a value (either a pointer or a numeric value) and an Object* is
simply a pointer.

	Now, what do we have here?  We have a system with all of the
potential efficiency of a C++ (i.e., one could write a straight C-like
program in it, whatever the syntax you choose, not necessarily C)
but with the potential flexibility of an immediate feedback
polymorphic system like Smalltalk.  I prefer C++ memory management
(with some changes and cleaning up here and there) so no garbage
collector, and I prefer the separation of the environment from the
application for C++, so I'd keep these.  Of course, if you write the
program editor *in* itself, you'd be able to edit *it* while editing
your application (you'd probably need two running, one editing the
application and one editing the editor, whew!).

	Is it all possible?  Well, in a word, yes.  Like I said
my group at EA already implemented one version of it, and it worked
fine (though it didn't have some of the enhancements I mentioned in
this article, it did have the compiled/interpreted flexibility and
the ability edit programs while they were running).  Efficient as C++?
In a phrase, very close:

	We wrote a prototype adventure game complete with tiled
graphics, input windows, user interface classes, and so forth.
When doing a performance analysis, we found the message send code
usually didn't even show up on the profiler, and when it did it was
taking up about 1% of overall execution time, hardly noticeable.
As for the interpreted code?  Well, most of the high-level user-
interface code was written in interpreted code, since we were changing THAT
a lot.  The thing spent from 3% to 7%, averaging about 5% of its time
in the interpreter.  The point being, the stuff you needed to change
the *MOST* was also the stuff that was being run the *LEAST*.  Most
of the time was being spent moving bits around on the screen or
doing low-level user interface stuff, like spitting text into the text window.
Once that stuff had been debugged, it was locked down and compiled
and ran perfectly fast, yet was still fully accessible to be called
by the interpreter.

	Memory use?  LESS.  That is, though method lookup tables are
an overhead, bytecoded interpreted code typically took up about
HALF the space of compiled 8086 code.  Thus overall we used LESS memory
than a typical C++ implementation.

	What does this mean?  It means you can have your cake and eat
it, too.  Fast, and without getting overweight.

	As I say, Electronic Arts owns that original implementation,
which is why I'd like to see the different version mentioned above
implemented.  Either by myself or someone else (like I said, our
company is willing to work with others to help get this thing accomplished!)
Logical platforms for implementation would be the Macintosh, Windows,
OS/2 Presentation Manager, OpenLook, and OSF Motif.

	Mitsu Hadeishi
	Open Mind
	1460 W. 182nd Street
	Gardena, CA 90248
	(213) 532-1654
	mitsu@well.sf.ca.us
	{apple,ucbvax,lll-lcc}!well!mitsu