Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (JAMES ADCOCK)
Newsgroups: comp.object
Subject: Re: Evaluating "Object-Oriented" Programming Languages
Keywords: object-oriented, programming languages, evaluation, bibliography
Message-ID: <10132@microsoft.UUCP>
Date: 3 Jan 90 18:34:17 GMT
References: <638@ajpo.sei.cmu.edu>
Reply-To: jimad@microsoft.UUCP (JAMES ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 56

While the previous suggestions regarding evaluating OO Languages I found
generally good, here is a list of things I think us grunts down in the
trenches would pragmatically like to know about a language before spending
too much time on it:

-> Message dispatch times in a variety of schenerios [static vs dynamic
   binding, single vs multiple inheritence, etc] relative to function
   call times in a specific traditional language such as C or Pascal.
   Timing comparisons should specify what compilers on what machines are
   being compared, using what compile and link options [if any.]
   Do not specify what performance *may* be achieved with a better compiler.
   Rather, specify what performance *is* being acheived with *today's*
   compiler.  Use the most-speed-optimized compiler options.

-> Dynamic object creation time for a typical small object.  Give absolute
   time in microseconds for a specific machine, and compare to malloc times
   on that system.

-> Specify "hello world" minimum stand-alone run-time executable size,
   where that size would be the total number of bytes that must be transported
   to a system that never saw anything in this language before.  Compare
   to a minimal C or Pascal "hello world" executable on that system 
   for comparison.

-> Include at least some simple common timing and size comparisons that
   people have experience with -- such as an "Object-Oriented" version
   of Ackerman's function.  Compare to timings in a traditional language
   such as C or Pascal.  Use most-speed-optimized compiler options -- specify
   what compilers and options are used.  Don't use just the 
   "traditional language" subset of your language -- we can already guess
   that Ackerman's function implemented in a C subset of C++ is going to
   run as fast as a K&R C version, and we can guess that most OO Languages
   include provisions for importing an assembly language version of Ackerman's.
   Rather, implement a simple, straight-forward version, using many of the
   features of the language you are advertising as being "good."

-> Include a list of traditional language features such as found in C
   or Pascal that are *not* in this language [not to imply such a lack
   is *bad* or *good*]

-> Specify what compilers are generally available for what machines
   at what costs and restrictions.  *Try* to be accurate.  Are there
   different costs for commercial vs educational users?  Are there
   restrictions on what one can do with executables built from this
   system?  Restrictions on linking libraries?  etc.

-> Specify what books or documentation [if any] are generally available
   for this language.

-> What does it take to use modules written in other languages with this
   language?  What does it take to use modules written in this language
   with other languages?  Yes, there was a time when C couldn't easily
   call Pascal couldn't easily call Fortran.  Now many Object Oriented 
   Languages have at least some ability *to call* routines/modules from 
   other languages.  Sadly, few Object Oriented Languages offer much 
   ability to allow their routines/modules *to be called* from other languages.