Language Efficiency

11 views
Skip to first unread message

Robert C. Bethel

unread,
Apr 2, 1995, 4:00:00 AM4/2/95
to
Anyone know of research papers that deal with the subject
of language efficiency? By efficiency I mean the quality
of machine binaries (code space, execution time, etc.)
given an identical program coded in several languages.

Thanks
--
Robert...@CBIS.Com

Harold P Zbiegien

unread,
Apr 4, 1995, 3:00:00 AM4/4/95
to

Shouldn't this be labeled "compiler efficiency" There may not be anything
inherent between the efficiency of one language and another, but there sure
is differences between the generated code coming out of compilers.

Harold
American Greetings Corp.
A

D
C
C
A
C
Harold

Kennel

unread,
Apr 4, 1995, 3:00:00 AM4/4/95
to

This is heresy but I disagree.

Different languages make fundamentally different choices resulting
in very different kinds and amounts of knowledge that is provided to the
compiler.

Assuming an approximately constant level of knowledge and resources
between compiler groups this can make a huge difference in the speed
of executable code.


Bob Kitzberger

unread,
Apr 4, 1995, 3:00:00 AM4/4/95
to
Robert C. Bethel (rob...@cbis.com) wrote:
: Anyone know of research papers that deal with the subject

: of language efficiency? By efficiency I mean the quality
: of machine binaries (code space, execution time, etc.)
: given an identical program coded in several languages.

If there were such papers, they would be suspect. A _language_ is
merely a paper definition of syntax and semantics; you must compare
language translation _implementations_ (i.e. compilers). And compiler
versions, coding styles, idioms, target platforms, etc.

--
Bob Kitzberger +1 (916) 274-3075 r...@rational.com
Rational Software Corp., 10565 Brunswick Rd. #11, Grass Valley, CA 95945
"...the solution to the problem is usually to pee on it" -- Dave Barry

Larry Kilgallen

unread,
Apr 4, 1995, 3:00:00 AM4/4/95
to
In article <3lrrqk$k...@usenet.INS.CWRU.Edu>, bb...@cleveland.Freenet.Edu (Harold P Zbiegien) writes:
>
> In a previous article, rob...@cbis.com (Robert C. Bethel) says:
>
>>Anyone know of research papers that deal with the subject
>>of language efficiency? By efficiency I mean the quality
>>of machine binaries (code space, execution time, etc.)
>>given an identical program coded in several languages.
>>
>>Thanks
>>--
>>Robert...@CBIS.Com
>>
> Shouldn't this be labeled "compiler efficiency" There may not be anything
> inherent between the efficiency of one language and another, but there sure
> is differences between the generated code coming out of compilers.
>
> Harold
> American Greetings Corp.

Although efficiency of compilers is the controlling issue for most
environments (due to the low state of optimization for most widely
used compilers), language efficiency is a separate issue which would
be of interest if compilers were not masking the effects.

One opinion is that "higher level" languages with strong type checking
give the compiler a better chance to understand what the programmer
really intended and optimize accordingly.

Of course this also depends on the programmer having coded what was
really intended.

Finally, let me note that the two specific examples given by Robert,
"code space" and "execution time" are often at odds with each other,
so a robust compiler will let the user indicate a preference.

Larry Kilgallen

Mitch Gart

unread,
Apr 5, 1995, 3:00:00 AM4/5/95
to
Robert C. Bethel (rob...@cbis.com) wrote:
: Anyone know of research papers that deal with the subject

: of language efficiency? By efficiency I mean the quality
: of machine binaries (code space, execution time, etc.)
: given an identical program coded in several languages.

About 10 years ago I wrote an article on "Benchmarking Ada, C,
and Pascal". I translated a set of small programs called
the Hennessy Benchmarks from Pascal to Ada and C, and then
compared the execution time efficiency of the programs when
compiled and run on a PC. The results looked good for Ada:
a few programs were a little faster in Ada, a few others were
a little faster in C, but overall there were no large differences
that made one language look more or less efficient than the
others.

I could dig out the paper if anyone wants to see it.

But as other people posting responses to this question have
noted, comparisons like this compare compilers as much as
languages. My paper compared Alsys Ada to Lattice C and
Turbo Pascal on an old 16-bit Intel 286 PC-AT machine. At the time
the PC-AT was the most advanced PC, and Lattice C was one of
the best C compilers for the PC. Technology has changed a lot
since then. In particular, I think C compiler vendors have made
dramatic improvements in their optimizers in the last ten years.

Mitch Gart

David Weller

unread,
Apr 5, 1995, 3:00:00 AM4/5/95
to
In article <D6K81...@oasis.icl.co.uk>,

Mike Wilson <m...@oasis.icl.co.uk> wrote:
>> If there were such papers, they would be suspect. A _language_ is
>> merely a paper definition of syntax and semantics; you must compare
>> language translation _implementations_ (i.e. compilers). And compiler
>> versions, coding styles, idioms, target platforms, etc.
>
>Yes, but I could generalise and say that some languages such as 'C'
>were designed with efficiency in mind. That's not to say a rotten
>compiler wouldn't produce huge, slow code. There _are_ very efficient
>COBOL compilers around. I've heard ICL's VME COBOL compiler produces
>very efficient code (but I don't have any first-hand knowledge of it).
>

C was designed to be quite efficient for machines in the late 70's.
I'd hardly say it has a lock on the "efficiency" bag anymore. Then
again, I would never claim that _any_ language has a lead on
efficiency. Some languages have constructs that can "assist"
efficient compiler implementations (array slicing comes to mind, and
it's not in C), but that doesn't mean the compiler _writer_ has to
choose an efficient implementation.

Bottom line: It's _not_ the language, but the language _can_ give
hints :-)

However, to end the argument once-and-for-all, I did a comparison of
Ada and C++. I ran both sources on top of a Pentuim system.....

All it did was make the source listings a little warmer :-)

--
Frustrated with C, C++, Pascal, Fortran? Ada95 _might_ be for you!
For all sorts of interesting Ada95 tidbits, run the command:
"finger dwe...@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
if u cn rd ths, u r gd enuf to chg to Ada :-)

Larry Kilgallen

unread,
Apr 5, 1995, 3:00:00 AM4/5/95
to
In article <D6K81...@oasis.icl.co.uk>, m...@oasis.icl.co.uk (Mike Wilson) writes:

> Yes, but I could generalise and say that some languages such as 'C'
> were designed with efficiency in mind. That's not to say a rotten
> compiler wouldn't produce huge, slow code. There _are_ very efficient
> COBOL compilers around. I've heard ICL's VME COBOL compiler produces
> very efficient code (but I don't have any first-hand knowledge of it).

Actually, as I understand it efficiency works the other way around.
As a low level language, C lets a programmer considerably affect the
generated code when a non-optimizing compiler is used. Switch to a
different compiler or move to a different instruction set and what
was formerly optimal is no longer optimal.

Likewise, if you use optimizing compilers high level languages will
produce better results than C.

Obviously the lowest level languages processors which directly express
machine instructions to be used leave the least opportunity for any
optimization of what the programmer has provided. (Although for
Alpha VMS, DEC did have to build a compiler for the VAX assembly
language, and I think there is at least one optimization which can
be enabled.)

Larry Kilgallen

Mike Wilson

unread,
Apr 5, 1995, 3:00:00 AM4/5/95
to
> If there were such papers, they would be suspect. A _language_ is
> merely a paper definition of syntax and semantics; you must compare
> language translation _implementations_ (i.e. compilers). And compiler
> versions, coding styles, idioms, target platforms, etc.

Yes, but I could generalise and say that some languages such as 'C'


were designed with efficiency in mind. That's not to say a rotten
compiler wouldn't produce huge, slow code. There _are_ very efficient
COBOL compilers around. I've heard ICL's VME COBOL compiler produces
very efficient code (but I don't have any first-hand knowledge of it).

--------------------------------------------------------------------
Mike Wilson m...@oasis.icl.co.uk
ICL Medical Portfolio, Kings House, Kings Road, Reading, RG1 3PX, UK

Lawrence Free/ A.F. Software Services

unread,
Apr 5, 1995, 3:00:00 AM4/5/95
to
Robert C. Bethel (rob...@cbis.com) wrote:
: Anyone know of research papers that deal with the subject
: of language efficiency? By efficiency I mean the quality
: of machine binaries (code space, execution time, etc.)
: given an identical program coded in several languages.

: Thanks
: --
: Robert...@CBIS.Com

A problem with language efficiency also deals with the programmer's skills.
I had a customer who asked how I changed the COBOL to have my application
run 5 - 10 times faster than the equivalent from another vendor. I informed
him that the language and compiler were the same, the programming different.

Lawrence A. Free | Email: fr...@mcs.com
A.F.Software Services, Inc. | Your MS/DOS, UNIX
(708) 232-0790 | business software developer


Ray Toal

unread,
Apr 5, 1995, 3:00:00 AM4/5/95
to
In article <3ls7u0$3...@stc06.ctd.ornl.gov> m...@jt3ws1.etd.ornl.gov (Kennel) writes:

>Harold P Zbiegien (bb...@cleveland.Freenet.Edu) wrote:

>> In a previous article, rob...@cbis.com (Robert C. Bethel) says:

>> >Anyone know of research papers that deal with the subject
>> >of language efficiency? By efficiency I mean the quality
>> >of machine binaries (code space, execution time, etc.)
>> >given an identical program coded in several languages.
>> >
>> >Thanks
>> >--
>> >Robert...@CBIS.Com
>> >

>> Shouldn't this be labeled "compiler efficiency" There may not be anything
>> inherent between the efficiency of one language and another,
>> but there sure
>> is differences between the generated code coming out of compilers.

>This is heresy but I disagree.

>Different languages make fundamentally different choices resulting
>in very different kinds and amounts of knowledge that is provided to the
>compiler.

Actually what is *more* important is what the language definitions *allow*
compilers to get away with. Fortran compilers are allowed to assume that
two arrays passed to the same subroutine/function do not alias each
other (even if they do). So you'll have fast running code but you'll
have to "trust the programmer". I'm not really sure why there would
(in principle) be a difference in execution time between a Fortran
program that was compiled without assuming "noalias" and an Ada program
in which all checks were supressed. Alas, 30+ years of Fortran compiler
technology shows that in practice there usually is...

>Assuming an approximately constant level of knowledge and resources
>between compiler groups this can make a huge difference in the speed
>of executable code.

Strong typing, and for that matter good uses of subtyping in Ada, of course
help a good compiler optimize away checks. But when you compare Ada
runtimes to those with languages that are essentially unchecked there
are differences.

Ray Toal


Ruthifren

unread,
Apr 6, 1995, 3:00:00 AM4/6/95
to
> Likewise, if you use optimizing compilers high level languages will
> produce better results than C.

Is it just me or is our perception of compiler technology far beyond the
reality?

___________________________________________________________
Jon Gamble: lowly CS student UAH

Larry Kilgallen

unread,
Apr 6, 1995, 3:00:00 AM4/6/95
to
In article <3lvru0$b...@mars.earthlink.net>, klei...@earthlink.net (Ken
Leidner) writes:

> I think that a "good" programmer in a given language has more to do with it
> than what the language is, unless the language just can't support the
> problem at all. An understanding of what the compiler is going to do has a
> lot to do with what the code comming out of the back side looks like.

Unfortunately that is true for a lot of compilers, but if a
programmer actually writes a high level language program (as
distinguished from writing a low level language program with
a high level language compiler), a good optimizing compiler
should be able to make up for any lack of knowledge which
the programmer has about compiler behaviour.

Not to pick on Fortran, but just to pick on Fortran programmers :-),
it has been said that someone with 20 years of experience just
programming Fortran can readily adapt to _any_ computer language
and write working programs that still look like Fortran.

Larry Kilgallen

--
| Fidonet: Larry Kilgallen 1:270/211...@fidonet.org
| Internet: 270-211-777!Larry.K...@mdtnbbs.com
| Standard disclaimer: The views of this user are strictly his own.
| From Mdtn_BBS 1 717 944-9653 [ In the Heart of Three Mile Island ]

Ken Leidner

unread,
Apr 6, 1995, 3:00:00 AM4/6/95
to
In article <3lmt64$s...@dplanet.p2k.cbis.com>, rob...@cbis.com says...
>Language Efficiency

A part of this question that people seemed to miss is that some languages
are better to code a type of program than the same program in a different
lanaguage. Its part of the reason why we have more that one language. Each
lanaguage was designed to allow the programmer to define a set of "problems"
easily. FORTRAN to translate mathematical formulas, COBOL for bussines,
SOBOL for text searching ...

I think that a "good" programmer in a given language has more to do with it
than what the language is, unless the language just can't support the
problem at all. An understanding of what the compiler is going to do has a
lot to do with what the code comming out of the back side looks like.

Ken Leidner
Systems Progammer
klei...@earthlink.net

Robert Dewar

unread,
Apr 6, 1995, 3:00:00 AM4/6/95
to
"Finally, let me note that the two specific examples given by Robert,
"code space" and "execution time" are often at odds with each other,
so a robust compiler will let the user indicate a preference."

yes, people often say this, but in my experience it is much less true
than people expect. The pragma Optimize (Space|Time) of Ada has very
seldom had much effect.

Most modern highly optimizing compilers do NOT in fact have a selection
for time vs space. That's because in practice, reducing the number of
instructions reduces the execution speed on modern RISC machines.

Sure you can find examples, e.g. pulling things out of loops, where this
is theoretically the case, but I still think that in practice, over a big
chunk of code, there is not the kind of dichotomy that the quote above
suggests.


Larry Kilgallen

unread,
Apr 6, 1995, 3:00:00 AM4/6/95
to
In article <3lvru0$b...@mars.earthlink.net>, klei...@earthlink.net (Ken Leidner) writes:

> I think that a "good" programmer in a given language has more to do with it
> than what the language is, unless the language just can't support the
> problem at all. An understanding of what the compiler is going to do has a
> lot to do with what the code comming out of the back side looks like.

Unfortunately that is true for a lot of compilers, but if a

Robert Dewar

unread,
Apr 7, 1995, 3:00:00 AM4/7/95
to
Please substantiate the "heresy" that different languages make a big
difference in generated code efficiency.


Ross Driedger

unread,
Apr 9, 1995, 3:00:00 AM4/9/95
to
Crookie <g...@mfltd.co.uk> wrote:
>>de...@cs.nyu.edu (Robert Dewar) wrote:
>>
>>>Ross Driedger says:
>>>
>>>"All I need to do is load my Smalltalk enviroment, type "2 + 2" in the
>>>transcript and invoke the 'Show It' command. Three seconds later, I get
>>>an answer."
>>>
>>>That is completely irrelevant, what you see in a particular implementation
>>>of a particular language does not necessarily have anything whatsoever to
>>>do with the languages involved.
>>>

Nonsense. Smalltalk being a true OOL and small integer being 4 layers of
lineage from Object has everything to do with the matter. If all I want to
do is move the number 2 into the EAX and add a memory address that contains
the value 2 and output it, then the concepts of the language make all the
difference. I don't even want to know the steps involved in doing this in
Smalltalk -- life's too damn short. Do you have any guesses on how long it
takes in C or Assembler or Pascal or Lisp, even?

>>>TO make the argument that there is some inherent difference in language
>>>efficiency, you have to give very specific examples of semantic features
>>>and argue that it is impossible to implement comparable features with
>>>comparable efficiency. What any particular implementations happen to do
>>>is not part of the discussion.

Just did. I have personal experience on this, too. I worked on a Smalltalk
project that was cancelled because the client's 486 took 3 minutes to load
the image in demo. A comparable app in C++ would have been up in less than
5 seconds.

>>er, i thought the inherent difference in S/T (as opposed to Object COBOL
>>or C++) is that it does _everything_ by messages. even 2+2.

Precisely.

This is not to say the Smalltalk can be a useful language under the proper
circumstances (high powered hardware, optimized OS and compiler and an
app that is not computationally intensive), but I cannot think of application
where C++ will end up with less efficient machine code than Smalltalk.

This thread reminds me those on comp.lang.smalltalk where every now and then
a few weenies try to convince everyone that Smalltalk can produce code that
is as fast as C++ (or C, even!). There are a few realists who come
out with a reality check.

If I need computational speed I won't use Smalltalk _because_ it is an OOL.
I might use C++ because I can revert to C or Assembler if I need to. (besides
it is not an OOL in the pure sense)

Ross Driedger
cs4g...@maccs.dcss.mcmaster.ca


"The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts." (B. Russell)

Kennel

unread,
Apr 9, 1995, 3:00:00 AM4/9/95
to
Ruthifren (ruth...@aol.com) wrote:
> > Likewise, if you use optimizing compilers high level languages will
> > produce better results than C.

> Is it just me or is our perception of compiler technology far beyond the
> reality?

Fortran.

In this respect, Fortran *is* high level in the important notion
that its pointers are nonexistent (in f77) or well controlled (Fortran 90).

Fortran arrays are indexed through integers, and no other way.

This restriction vs. C allows more optimization, because the compiler
can assume more. As in all mathematics, more assumptions lead to more
powerful and specific theorems.

The theorem here is "this object code is an implementation of this
source", assumptions are 'element A(i) is not at the same location
as B(j) for i .ne. j', which holds not for C.

matt


Kennel

unread,
Apr 9, 1995, 3:00:00 AM4/9/95
to
Robert Dewar (de...@cs.nyu.edu) wrote:
> Please substantiate the "heresy" that different languages make a big
> difference in generated code efficiency.

Different assumptions built into one language vs. another make some
implementation strategies that are simple and easy in one language either
uneconomically difficult {usually} or outright impossible.

mbk

Robert Dewar

unread,
Apr 9, 1995, 3:00:00 AM4/9/95
to
Kennel says:

"Different assumptions built into one language vs. another make some
implementation strategies that are simple and easy in one language either
uneconomically difficult {usually} or outright impossible."

This isn't substantiation, it is just vague expression of opinion with
no substance. Can you give SPECIFIC examples of what you mean. While I
can think of marginal instances of the above principle, I think as a
general statement of the situation it is completely WRONG!

I obviously can't give examples of the absence of a phenomenon, so really
you need to give some examples of its presence!


Ross Driedger

unread,
Apr 9, 1995, 3:00:00 AM4/9/95
to
m...@jt3ws1.etd.ornl.gov (Kennel) wrote:
>>Robert Dewar (de...@cs.nyu.edu) wrote:
>>> Please substantiate the "heresy" that different languages make a big
>>> difference in generated code efficiency.
>>
>>Different assumptions built into one language vs. another make some
>>implementation strategies that are simple and easy in one language either
>>uneconomically difficult {usually} or outright impossible.

All I need to do is load my Smalltalk enviroment, type "2 + 2" in the


transcript and invoke the 'Show It' command. Three seconds later, I get
an answer.

Good thing I'm not doing fractal calculations in Smalltalk.

Robert Dewar

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
Ross Driedger says:

"All I need to do is load my Smalltalk enviroment, type "2 + 2" in the
transcript and invoke the 'Show It' command. Three seconds later, I get
an answer."

That is completely irrelevant, what you see in a particular implementation


of a particular language does not necessarily have anything whatsoever to
do with the languages involved.

TO make the argument that there is some inherent difference in language

Robert Dewar

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
Robb Nebbe says:

Compare Smalltalk with Ada. There are choices made in Smalltalk that
introduce an overhead that is not present in Ada. On the otherhand
if you compare C++ and Ada the langauges are close enough that the
quality of the implementation is likely to dominate rather than
any differences in the language.

Again, a general statement with no specifics. Sure the easiest place to look
for differences of the kind we are talking about is to compare languages
that are generally implemented with interpretors with languages that are
generally compiled. However such comparisons are misleading, an interpreted
C can be much slower than compiled Lisp, to take examples of things that
exist.

Current Smalltalk implementations are dreadfully inefficient, it would
certainly be possible to compile MCUH more effcient code in Smalltalk than
is currently done. Note that the fluid environment of a Smalltalk system
is an artifact of the implementation, desirable for development and
debugging, but antagonistic to efficiency.

(P.S. this is an old area for me, you may not be aware that I developed the
SPITBOL implementations of fast compiled SNOBOL4, which showed that many
assumptions about what can and cannot be compiled efficiently are not
always correct).

Anyway, Robb, again, general statements that there ARE differences don't
contribute to the discussion unless you give specific examples. I can't
give specific examples of something that I think does not exist!


David Weller

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
In article <dewar.797513130@gnat>, Robert Dewar <de...@cs.nyu.edu> wrote:
>Current Smalltalk implementations are dreadfully inefficient, it would
>certainly be possible to compile MCUH more effcient code in Smalltalk than
>is currently done. Note that the fluid environment of a Smalltalk system
>is an artifact of the implementation, desirable for development and
>debugging, but antagonistic to efficiency.
>
As you've pointed out, Robert, don't make assumptions about
implementations :-) Envy's solution to Smalltalk compacts the
runtime down to an efficient executable image. They tend to blow
away people's perception of Smalltalk's efficienty. I wouldn't claim
it's ready for "real-time" yet (though others do!), but it's
certainly snappy.

>(P.S. this is an old area for me, you may not be aware that I developed the
>SPITBOL implementations of fast compiled SNOBOL4, which showed that many
>assumptions about what can and cannot be compiled efficiently are not
>always correct).
>

Or that you had a pretty firm hand in the compiler for CA-Realia
COBOL :-)

Robb Nebbe

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
In article <dewar.797513130@gnat>, de...@cs.nyu.edu (Robert Dewar) writes:

|> Again, a general statement with no specifics. Sure the easiest place to look
|> for differences of the kind we are talking about is to compare languages
|> that are generally implemented with interpretors with languages that are
|> generally compiled. However such comparisons are misleading, an interpreted
|> C can be much slower than compiled Lisp, to take examples of things that
|> exist.

Among other things type information is very useful for optimization. In
the context of separate compilation the lack of type information in
Smalltalk creates overhead that you don't have enough information to
get rid of. Obviously if you have the entire program then, at least
theoretically, you could produce the same code since you could propagate
type information (after having infered it) but I would expect that to
be far from trivial.

Robb Nebbe


Crookie

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
er, i thought the inherent difference in S/T (as opposed to Object COBOL
or C++) is that it does _everything_ by messages. even 2+2.

--
Crookie
g...@mfltd.co.uk

Robert Dewar

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
Ross, your four levels are what you see in *your* Smalltalk, rest assured,
it is *not* impossible to implement integer addition efficiently in
Smalltalk. No guesses are needed, the strategy is straightforward. Sure
it is more work than in Pascal, but that is about all you can say.


Robert Dewar

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
Look if Ross Driedger wants to define OOL as not including C++, why argue
the point. People can make words mean anything they want. Of course if they
choose a peculiar definition, like this, they had better make people sure
that they understand the unusual usage (as Ross did).

Arguing about the meaning of technical terms is silly.

Now of course there can be a hidden agenda here

OOL languages are good
C++ is not an OOL language
Therefore C++ is bad

This logic is of course doubly flawed :-)


Robert Dewar

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
In smalltalk it is true that everything is done by messages at the semantic
level, but that does not mean you have to implement 2+2 that way!

After all in Ada, if A and B are of type integer, then the official semantics
says that

A := B;

requires a constraint check to make sure that the value B is in range of
type Integer. Well we certainly don't expect to see *code* for such a check
generated in a decent Ada compiler.

Similarly in COBOL

MOVE A TO B

semantically requires all sorts of things that a good compiler can shortcut.

Lawrence Free/ A.F. Software Services

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
Richard Ladd Kirkham (gt2...@prism.gatech.edu) wrote:
: In article <D6uA7...@mcshub.dcss.mcmaster.ca> cs4g...@maccs.dcss.mcmaster.ca (Ross Driedger) writes:
: >
: > C++ . . . is not an OOL in the pure sense)

: Why?

: --
: Richard Ladd Kirkham
: Georgia Institute of Technology, Atlanta Georgia, 30332
: uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt2782a
: Internet: gt2...@prism.gatech.edu

I'm not sure about the original poster's reasoning but 1. You can do
object oriented programming in both C and C++, and 2. You can avoid doing
object oriented programming in both C and C++. I have not dealt with a
language that forces the issue (there may be some). You can use object
oriented techniques in most computer languages. In COBOL it's efficient,
in C it's recommended, in assembler, we call it survival.

Richard Ladd Kirkham

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
(Lawrence Free/ A.F. Software Services) writes:
>Richard Ladd Kirkham (gt2...@prism.gatech.edu) wrote:
>: Ross Drieger (spell?) wrote:
>: >
>: > C++ . . . is not an OOL in the pure sense)
>
>: Why?
>
>I'm not sure about the original poster's reasoning but 1. You can do
>object oriented programming in both C and C++, and 2. You can avoid doing
>object oriented programming in both C and C++. I have not dealt with a
>language that forces the issue (there may be some). You can use object
>oriented techniques in most computer languages. In COBOL it's efficient,
>in C it's recommended, in assembler, we call it survival.
>
Now I'm more confused. If there's really a difference between OOP and
mere structural, then there are damned few object oriented techniques
that can be used in "most computer languages". To mention just one
example, does COBOL have generic functions, what C++ calls templates?
Does plain C?

David Weller

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
In article <3mcfbf$p...@acmez.gatech.edu>,

Richard Ladd Kirkham <gt2...@prism.gatech.edu> wrote:
>In article <D6uA7...@mcshub.dcss.mcmaster.ca> cs4g...@maccs.dcss.mcmaster.ca (Ross Driedger) writes:
>>
>> C++ . . . is not an OOL in the pure sense)
>
>Why?
>

I vote we kill this thread before we even start it. I've watched
this whole silly thing about "pure" vs. "impure" languages so much in
comp.object I just wanna puke. The phrase "<X> language is not an
OOL in the pure sense" is only nonsense. IMHO, it reveals the
poster's ignorance of the history of programming languages.

<Walking away, grumbling>

Richard Ladd Kirkham

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
In article <D6uA7...@mcshub.dcss.mcmaster.ca> cs4g...@maccs.dcss.mcmaster.ca (Ross Driedger) writes:
>
> C++ . . . is not an OOL in the pure sense)

Why?

--

Robb Nebbe

unread,
Apr 10, 1995, 3:00:00 AM4/10/95
to
In article <dewar.797469506@gnat>, de...@cs.nyu.edu (Robert Dewar) writes:

|> Kennel says:
|>
|> "Different assumptions built into one language vs. another make some
|> implementation strategies that are simple and easy in one language either
|> uneconomically difficult {usually} or outright impossible."
|>
...

|>
|> I obviously can't give examples of the absence of a phenomenon, so really
|> you need to give some examples of its presence!

Compare Smalltalk with Ada. There are choices made in Smalltalk that


introduce an overhead that is not present in Ada. On the otherhand
if you compare C++ and Ada the langauges are close enough that the
quality of the implementation is likely to dominate rather than
any differences in the language.

Robb Nebbe

Fernando Mato Mira

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to
In article <3mcoh6$a...@Starbase.NeoSoft.COM>, dwe...@Starbase.NeoSoft.COM (David Weller) writes:
> In article <3mcfbf$p...@acmez.gatech.edu>,
> Richard Ladd Kirkham <gt2...@prism.gatech.edu> wrote:
> >In article <D6uA7...@mcshub.dcss.mcmaster.ca> cs4g...@maccs.dcss.mcmaster.ca (Ross Driedger) writes:
> >>
> >> C++ . . . is not an OOL in the pure sense)
> >
> >Why?
> >
>
> I vote we kill this thread before we even start it. I've watched
> this whole silly thing about "pure" vs. "impure" languages so much in
> comp.object I just wanna puke. The phrase "<X> language is not an
> OOL in the pure sense" is only nonsense. IMHO, it reveals the
> poster's ignorance of the history of programming languages.

Good point. Purity is irrelevant. However, I would be tempted
to call all single-dispatch languages `subject-oriented', and
only those with multi-methods `object-oriented'.

--
F.D. Mato Mira http://ligwww.epfl.ch/matomira.html
Computer Graphics Lab mato...@epfl.ch
EPFL FAX: +41 (21) 693-5328


Ross Driedger

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to
de...@cs.nyu.edu (Robert Dewar) wrote:
>>In smalltalk it is true that everything is done by messages at the semantic
>>level, but that does not mean you have to implement 2+2 that way!

Even Smalltalk's proponents, if they have any credibility, admit that there
is a major performance hit. I'm not going to buy a Pentium just so I can
pretend I am using 486 with Smalltalk.

After the last few posts I checked into my documents from the OOPSLA conference
in '92 regarding writing efficient Smalltalk. The author claims at best that
well written Smalltalk ranges from half to one fifteenth the speed of C.

But I am suspicious of this because all his 'examples' were well written Smalltalk
vs. C that had some major problems: there were bugs or there was a lack of
good C libraries. Never was well implemented C or C++ discussed.

I know this post doesn't represent any authoritative discussion on the subject;
it is just my experience that Smalltalk doesn't produce the nice crisp executable
that properly implemented C++ does. Clients notice when screen redraws are mushy
or the load times seem long. Language purists might care about matters such as
whether the inheritance is multiple or not -- clients don't and ultimately it is
the client that is going to pay me. If the language I use is an ugly mongrel
that still produces a good quality image and is relatively safe if I use common
sense and self discipline, I will consider its use.

Smalltalk, as implemented for the PC, doesn't qualify at this time. Why? Just
add 2 + 2 in a transcript and ask yourself if you can live with the time it took
to evaluate it. I can't.

Larry Kilgallen

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to
In article <dewar.797512974@gnat>, de...@cs.nyu.edu (Robert Dewar) writes:

> TO make the argument that there is some inherent difference in language
> efficiency, you have to give very specific examples of semantic features
> and argue that it is impossible to implement comparable features with
> comparable efficiency. What any particular implementations happen to do
> is not part of the discussion.

Consider a type of number ranging from 0 to 17 in Ada and also
some other language. In Ada, the programmer has specified the
range of the number, whereas for the sake of discussion presume
the other language does not have that ability.

The programmer has thus given the Ada compiler "more information"
(not her fault) about the nature of the application.

If both compilers target a RISC processor where 32 bits is the
smallest multiply available, the Ada compiler can multiply two
such numbers without fear of hardware arithmetic overflow, only
checking the _result_ for legality. On many processors, hardware
exceptions are much more difficult to handle, but because the Ada
program had _more_information_ about what the programmer _really_
wanted, waiting until things get to the hardware exception stage
is not required.

I am not a compiler expert, but the general idea is that the more
data given to a compiler, the better it is able to implement
efficiently. A language may provide more or less ability to express
exact desires to a machine.

Does that make machine language programming most efficient? Only
in cases where the programmer in question can faultlessly take into
account all of the instruction scheduling nuances of a particular
processor. And doing by hand what machines (compilers) can do faster
is no fun.

Larry Kilgallen

Bill Winn

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to
In article <3mcior$b...@Mars.mcs.com>, fr...@MCS.COM wrote...
<snip>

>I'm not sure about the original poster's reasoning but 1. You can do
>object oriented programming in both C and C++,

Technically speaking object oriented programming requires inheritance
(amoung other things), which C does not support, but C++ does. Therefore
one cannot do OOP in C.


Bill Winn
Software Engineer - Analysts International Corporation
-------------------------------
wjw...@kocrsv01.delcoelect.com
ww...@klingon.iupucs.iupui.edu
My views do not express the views of anyone except my alter-ego.
Janet! Brad! Janet! Dr. Scott! Rocky! Uhh!
- Brad, Janet, Dr. Scott, Janet, Dr. Frankenfurter, Rocky
"Rocky Horror Picture Show"


Ross Driedger

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to

Fine! The interior compiler details are hidden from my view, because
that's the way the enviroment is implemented.

What I do know for certain is that the steps that are undertaken to do
a simple addition of two small integers is far more complex than what derives
from Assembly, C or C++. If I want an integer object and can afford the
cycles, then I'm happy to use what I'm provided. But sometimes I just want to
add 2 to 2 and I want to do it with much less overhead than Smalltalk provides.

C++'s strength is that it doesn't force me into an overhead laden method when
I can't afford it. I prefer the pragmatic approach; C++ gives me the option
of doing things in ways that are appropriate for the situation. My pragmatism
doesn't stop there; I'll use Smalltalk when its weaknesses are not exploited
by the problem.

It's just unrealistic to think that intrinsic problems with any language can
be 'optimized out'. Smalltalk's major problem is computational inefficiency.

Ross Driedger

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to
de...@cs.nyu.edu (Robert Dewar) wrote:
>>Look if Ross Driedger wants to define OOL as not including C++, why argue
>>the point. People can make words mean anything they want. Of course if they
>>choose a peculiar definition, like this, they had better make people sure
>>that they understand the unusual usage (as Ross did).

Hey, dude, chill! What I'm saying is not much different than what Meyer
or Lalonde say when talking about their 'pet' languages. My view differs
with these two gents in that I believe:
(1) it is not necessary to use a 'pure' language,
(2) it is important to choose an appropriate tool for a problem,
(ex: C is not my language of choice to implement an RDB)
(3) go with what works best for you.

>>Arguing about the meaning of technical terms is silly.

My God! We actually agree on something! ;-)

>>Now of course there can be a hidden agenda here

What 'hidden agenda'? I'm on this group to gain from others' experience in C++.

>>OOL languages are good
>>C++ is not an OOL language
>>Therefore C++ is bad

Oh, please! Don't go interpolating things that are not there. I rate the
'goodness' or 'badness' of a language by how much cash I can potentially make by
slinging its code. By that standard, C++ is a pretty good language.

>>This logic is of course doubly flawed :-)

In view of my feelings on the three previous statments you interpolated on me,
this one is garbage if it is also directed at me. I'll give you the benefit of
the doubt and believe the smiley was sincere....

Bill Winn

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to
I forgot something important in my last posting:

Although one cannot do OOP in C or Ada83, one can do OO Analysis and Design
and capture that in C or Ada83 via object-based coding (analogous to
programming with ADTs).

Sorry about the C intrusion (and Ada83 for you C++'ers)...Now back to your
scheduled language discussions

Bill Winn
Software Engineer - Analysts International Corporation
-------------------------------
wjw...@kocrsv01.delcoelect.com
ww...@klingon.iupucs.iupui.edu

My views do not express the views of anyone except my alter-ego.

"Where ever you go, there you are."
- Buckaroo Bonzai


Robert Dewar

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to
"Good point. Purity is irrelevant. However, I would be tempted
to call all single-dispatch languages `subject-oriented', and
only those with multi-methods `object-oriented'."

You can be tempted (and indeed go ahead and use) any old peculiar
terminology you want, but arguing about terminology is totally
irrelevant.

Unless again, you are using this invalid argument technique of
implying quality by terminology:

object oriented is good
single dispatch languages are not OO
therefore single dispatch languages are not god

(interesting mistype in last word, I think I will leave it in :-)

Obviously this implied logic is bogus, so we will assume that the total
content of your post was simply about terminology. But that's pointless
to discuss.

So what is your *technical* point here, if any?


Matt Austern

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to
In article <3meiee$8...@kocrsv08.delcoelect.com> wjw...@kocrsv01.delcoelect.com (Bill Winn) writes:

> Technically speaking object oriented programming requires inheritance
> (amoung other things), which C does not support, but C++ does. Therefore

> one cannot do OOP in C.

C doesn't have inheritance built in, but it is possible to do it
manually. That's also true of polymorphism and dynamic type
dispatching. I have seen object oriented C code.

I like to make the distinction between object oriented design (a
method of design that focuses on object identity and relationships
rather than on algorithms), object oriented programming (a programming
style, used to implement object oriented designs, that involves
encapsulation, data abstraction, inheritance, and polymorphism), and
object oriented languages (languages which provide specific built-in
support for object oriented programming).

Sometimes it's also useful to distinguish between languages that
provide direct support for object oriented programming as well as
other styles of programming, and languages that try to encourage
object oriented programming above all other styles. C++ is clearly
one of the former.

--

--matt

Robert Dewar

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to
"Although one cannot do OOP in C or Ada 83"

a peculiar statement, but I guess you can manage to define OOP in a narrow
way that makes this a true, but not particularly useful, statement.


Robert Dewar

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to
Ross, you still talk about your Smalltalk *implementation* as though it
provided definitive answers on the efficienty of the *language* (please note
the title of this thread). It does not, it merely tells you about how
efficiently your vendor has implemented Smalltalk -- most interesting if
you have to use that implementation, but not really relevant to this
thread of discussion.


Robert Martin

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to
cs4g...@maccs.dcss.mcmaster.ca (Ross Driedger) writes:

>If I need computational speed I won't use Smalltalk _because_ it is an OOL.
>I might use C++ because I can revert to C or Assembler if I need to. (besides
>it is not an OOL in the pure sense)

Being an OOPL is irrelevant to speed. Smalltalk is slow (relatively
speaking) because it is interpreted, and because messages are looked
up in hash tables (or the equivalent).

Purity of OO (Whatever that may be) also has nothing to do with speed.
Messages, after all, are really just function calls. Polymorphic
messages need be nothing more than calls to functions via function
pointers. In C++, this is exaclty what they are.

Whether C++ is pure or not is irrelevant. It is not it's impurity
that makes it faster. Rather it is the mechanism behind virtual
member function dispatch.

--
Robert Martin | Design Consulting | Training courses offered:
Object Mentor Assoc.| rma...@rcmcon.com | Object Oriented Analysis
2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 | C++

Robert Martin

unread,
Apr 11, 1995, 3:00:00 AM4/11/95
to
Crookie <g...@mfltd.co.uk> writes:

>er, i thought the inherent difference in S/T (as opposed to Object COBOL
>or C++) is that it does _everything_ by messages. even 2+2.

The notion that in Smalltalk everything is objects and messages is
often touted as the justification for calling it a pure OOPL. But the
concept is nonsense. Methods are just functions. Messages are just
function calls. Polymorphic message dispatch is just calling
functions through pointers.

The difference between an OO language and a non OO language is that an
OO language provides facilities for managing polymorphic dispatch and
for encapsulating functions and data structures.

Fernando Mato Mira

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to

I didn't mean to imply that single-dispatch languages are not good.
The terminology might be `peculiar' but would probably be more exact
(too late to change, I guess).

The point is, a lot of people have no idea of the existence of
multiple dispatch, and that's why you find the typical `peculiar'
reverse OO syntax in most OO languages.
And then you find yourself with things like CORBA, were it seems
that no thought whatsoever was put about this issue.

As I said before, Ada scored by keeping a
traditional procedural (functional) syntax, IMHO.
Combine this with the above and what I am saying
is that `Ada is both good and right'

Of course, that doesn't mean that I don't think that
having multiple dispatch in Ada wouldn't be better
and that the constraining rule isn't more complicated
than a simple multiple-dispatch rule, and consequently, wrong (the rule) :-)

Ada folks, the point was not to go head-banging about this.
This was a general ontological crosspost, answering to somebody
who is trying to get a good conceptual base about 00P..

PS: Dewar, you said `old peculiar terminology'. I don't
know what's up with USENET, but it often happens that
a subject will appear just a couple of days I start meditating
about some issue. I couldn't determine if I had heard
this `subject-oriented' term before. Got any references?
Thanks.

PS2 (yuck :-)) : Oh, yeah, I got email from a couple of
CLOS fans who _love_ the peculiar terminology (but alas,
they also like peculiar languages, it seems.. ;-) )

Ross Driedger

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to

I have hope for this thread, considering the last three posts.

I never thought I would have started such a thread by commenting,
in a very offhand way, about the 'purity' of C++ in regards to OOness.
The important thing that Matt and Bill have pointed out is the design
and view of the implementers that make or break a project's OO nature.

Too often, and I'm sure many of you have seen it, someone with a tenuous
grasp of C++ syntax will think (s)he is doing OO programming just because
it is C++.

David Weller

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
In article <1995Apr11....@eisner.decus.org>,

Larry Kilgallen <kilg...@eisner.decus.org> wrote:
>
>I am not a compiler expert, but the general idea is that the more
>data given to a compiler, the better it is able to implement
>efficiently. A language may provide more or less ability to express
>exact desires to a machine.
>
Sadly, this is exactly the opposite of the "popular" perception.
Seems that most people think that terse words and symbols, coupled
with types that "fit" (int, float, long float) is what one needs to
be "efficient".

Curtis Bass

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
gt2...@prism.gatech.edu (Richard Ladd Kirkham) wrote:
>
> In article <D6uA7...@mcshub.dcss.mcmaster.ca> cs4g...@maccs.dcss.mcmaster.ca (Ross Driedger) writes:
> >
> > C++ . . . is not an OOL in the pure sense)
>
> Why?

Well, C++ does directly support all the mechanisms necessary
for object-orientation (encapsulation, abstraction, polymorphism,
and inheritance), but it still allows you to write procedural
(i.e. structured) code without requiring an object-oriented
design or implementation. In a "pure" OOPL, such as Smalltalk,
EVERYTHING is an object, and the object-oriented paradigm is
the ONLY one supported -- you cannot write strictly procedural
code in a 'pure" OOPL.

So, C++ is definitely an OOPL, but IS "impure" in that it is
also structured/procedural.

It's sort of like BASIC -- you CAN write structured code in
most modern BASIC dialects, using procedures and parameter-
passing mechanisms with local variables, but you can also
write old-fashioned, unstructured spaghetti BASIC, using
GOTO's, GOSUBS, line numbers, and all global variables. So,
we can say that BASIC is not a "structured" language in the
"pure" sense.

> --
> Richard Ladd Kirkham
> Georgia Institute of Technology, Atlanta Georgia, 30332
> uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt2782a
> Internet: gt2...@prism.gatech.edu


Curtis Bass
Software Systems Specialist II
University of Texas Medical Branch


Ross Driedger

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
rma...@rcmcon.com (Robert Martin) wrote:

>>Being an OOPL is irrelevant to speed. Smalltalk is slow (relatively
>>speaking) because it is interpreted, and because messages are looked
>>up in hash tables (or the equivalent).

Does that include when the image has been stripped of the extraneous
classes? My experience is with the incremental compilers of the
PC world. Is even the finished .exe considered an interpreted program?

>>Purity of OO (Whatever that may be) also has nothing to do with speed.

I'd like to believe that (Really, I would). My experience tells me
otherwise. Even the '++' adds some overhead. The question to be asked
is whether that overhead is acceptable in a given situation.

>>Messages, after all, are really just function calls. Polymorphic
>>messages need be nothing more than calls to functions via function
>>pointers. In C++, this is exaclty what they are.

Look, I don't want to get into an involved discussion on OO theory.
It is something for those who don't have real lives to begin with. ;-)
I am very pragmatic about the tools I use and in many cases C++ seems
to be a good choice.

>>Whether C++ is pure or not is irrelevant.

I would disagree with you on this in one way: the ability to drop
down to a functional, imperative or low level disqualifies it as a
'pure' OOL but it is what gives it this flexibility, usefulness
and popularity.

Ross Driedger

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
de...@cs.nyu.edu (Robert Dewar) wrote:
>>Ross, you still talk about your Smalltalk *implementation* as though it
>>provided definitive answers on the efficienty of the *language* (please note
>>the title of this thread).

Granted that there are good and not so good implementations of Smalltalk.
Even the best has levels of abstraction that must be fought through to get
from source code to machine code.

All languages do that to one extent or another and in many circumstances
(language/application) the levels are not obvious to the user because the
overhead is eaten up in otherwise wasted cycles. If the relative size of
that overhead cause perceptible delays in program execution, the problem
goes beyond the implementation and enters the realm of language design.

>>It does not, it merely tells you about how efficiently your vendor has
>>implemented Smalltalk -- most interesting if you have to use that
>>implementation, but not really relevant to this thread of discussion.

Hmmm. Suppose you had a Smalltalk, Eiffel or Sather implementation that
contatined a class that would allow you to directly maipulate CPU registers.
Would you use that language to write a device driver? Or an OS kernel?
I don't think you would because the design of the language would not allow the
kind of performance expected by the users.

Now, if the subject is programmer efficency, that is a whole different ballgame.

Robert Dewar

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
Robert Martin's posts on S/T vs C++ efficiency are absolutely on target.
It is surprising how much trouble people have in distinguishing between
languages and their implementations.

The confusion leads to two kinds of error:

1. Writing non-portable programs, because the programmer does not
understand the difference between the semantics of the
language and the behavior of the compiler in use.

2. Making claims about what is good/bad in a language based on
implementation:

Ada has storage leaks
Ada takes ages to compile
Ada generates ineffient code
etc.

Crookie

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
rma...@rcmcon.com (Robert Martin) wrote:
>Crookie <g...@mfltd.co.uk> writes:
>
>>er, i thought the inherent difference in S/T (as opposed to Object COBOL
>>or C++) is that it does _everything_ by messages. even 2+2.
>
>The notion that in Smalltalk everything is objects and messages is
>often touted as the justification for calling it a pure OOPL. But the
>concept is nonsense. Methods are just functions. Messages are just
>function calls. Polymorphic message dispatch is just calling
>functions through pointers.
>
>The difference between an OO language and a non OO language is that an
>OO language provides facilities for managing polymorphic dispatch and
>for encapsulating functions and data structures.

i'm not sure i understand your response to my post...looks like you've
got something to say and you're just going to say it...

i'm simply saying that if a language implements 2+2 as a "function call"
with parameters (and is then interpreted) it is inherently slower than
a language that implements it using native (compiled) machine code.

--
Crookie
g...@mfltd.co.uk

Robert Martin

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
wjw...@kocrsv01.delcoelect.com (Bill Winn) writes:

>In article <3mcior$b...@Mars.mcs.com>, fr...@MCS.COM wrote...
><snip>
>>I'm not sure about the original poster's reasoning but 1. You can do
>>object oriented programming in both C and C++,

>Technically speaking object oriented programming requires inheritance

>(amoung other things), which C does not support, but C++ does. Therefore
>one cannot do OOP in C.

It is possible to emulate inheritance in C. (After all, many c++
compilers translate down to C.) However, the techniques difficult and
error prone.

Yes, you *can* do OO in any procedural language that supports pointers
to functions, or the equivalent. But you probably would not want to.

Robert Martin

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
cs4g...@maccs.dcss.mcmaster.ca (Ross Driedger) writes:

>ma...@physics2.berkeley.edu (Matt Austern) wrote:
>>>C doesn't have inheritance built in, but it is possible to do it
>>>manually. That's also true of polymorphism and dynamic type
>>>dispatching. I have seen object oriented C code.

>>>I like to make the distinction between object oriented design (a
>>>method of design that focuses on object identity and relationships
>>>rather than on algorithms), object oriented programming (a programming
>>>style, used to implement object oriented designs, that involves
>>>encapsulation, data abstraction, inheritance, and polymorphism), and
>>>object oriented languages (languages which provide specific built-in
>>>support for object oriented programming).

>I have hope for this thread, considering the last three posts.

>I never thought I would have started such a thread by commenting,
>in a very offhand way, about the 'purity' of C++ in regards to OOness.
>The important thing that Matt and Bill have pointed out is the design
>and view of the implementers that make or break a project's OO nature.

All this is true. You *can* perform OOD and then implement in a
procedural language (given that the procedural language has something
equivalent to pointer to functions.) But I would not want to do it.

The primary tools of OOD are abstract polymorphic interfaces that
break dependencies between clients and servers. In order to implement
these, we need indirection of function call (pointers to functions).
In C, we can get this by creating structures that contain a bunch of
pointers to the appropriate functions.

The point is that this style of programming is full of ad-hoc
conventions, is very error prone, and very difficult to maintain. An
OOPL like C++ takes away the clerical overhead, and the need for error
prone conventions.

Tore Joergensen

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
Ross Driedger (cs4g...@maccs.dcss.mcmaster.ca) wrote:
: rma...@rcmcon.com (Robert Martin) wrote:

: >>Being an OOPL is irrelevant to speed. Smalltalk is slow (relatively
: >>speaking) because it is interpreted, and because messages are looked
: >>up in hash tables (or the equivalent).

: Does that include when the image has been stripped of the extraneous
: classes? My experience is with the incremental compilers of the
: PC world. Is even the finished .exe considered an interpreted program?

Sometimes it is :-) It is not impossibel to pack the interpreter and
the (more or less translated) code in an exe-file. I used Visual Basic
for a project, and was very dissapointed with the speed. I made a simple
test running a loop with some calculations. Making an exe gave no
improvements in speed. I don't know if VB compiles the code, but I doubt
it.
--
______________________________________________________________________
Tore B. Joergensen, | e-mail: to...@lis.pitt.edu
a norwegian student | snail-mail: 2201 Pittockstr.
a long way from home. | Pittsburgh, 15217 PA
| web: http://www.pitt.edu/~tojst1

Guy Marentette

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
In a previous posting, Tore Joergensen (to...@lis.pitt.edu) writes:
> Ross Driedger (cs4g...@maccs.dcss.mcmaster.ca) wrote:
> : rma...@rcmcon.com (Robert Martin) wrote:
>
> : >>Being an OOPL is irrelevant to speed. Smalltalk is slow (relatively
> : >>speaking) because it is interpreted, and because messages are looked
> : >>up in hash tables (or the equivalent).
>
> : Does that include when the image has been stripped of the extraneous
> : classes? My experience is with the incremental compilers of the
> : PC world. Is even the finished .exe considered an interpreted program?
>

Digitalk's and ParkPlace's (and possibly other vendor's) latest versions
of Smalltalk no longer interpret the method code. The first time a method
is invoked, its byte code is compiled to machine code for execution. The
machine code is cached and used in subsequent invokations.


--
---------------------------------------------
Guy Marentette
aa...@Freenet.carleton.ca
Ottawa, Canada

Robert Dewar

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
Fine Ross, if you don't want to get into a theoretical discussion of
language efficiency that's perfectly reasonable, but they why post under
this thread, whose original purpose, now unfortunately somewhat blurred
by confused posts, is precisely to discuss the theoretical issue of
language efficiency, as opposed to implementation efficiency. In other
words we are interested not in what your compiler or any one else's
compiler currently may or may not do, but rather whether languages
have fundamental differences that limit what can be achieved in
*any* implementation. The (rather bogus) comments about OOL purity are
also irrelevant to this discussion.


Robert Dewar

unread,
Apr 12, 1995, 3:00:00 AM4/12/95
to
"I don't think you would because the design of the language would not allow the
kind of performance expected by the users."

You keep making unsubstantiated claims like this, and when challenged to
back up these claims, you simply quote observations about the behavior of
your particular compiler.

What is an example of an aspect of "the design of the language" that
fudnamentally restricts performance. Please don't tell me any more about
what your compiler can or cannot do. Instead quote a particular feature
and explain at a theoretical level why you think that it restrics the
maximum achievable performance.