Language Efficiency

Language Efficiency

[Robert C. Bethel]

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.Bethel@CBIS.Com 

Re: Language Efficiency

[Harold P Zbiegien]

In a previous article, robertb@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.Bethel@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.
A

D
C
C
A
C
Harold

Re: Language Efficiency

[Kennel]

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

> In a previous article, robertb@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.Bethel@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.

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

Re: Language Efficiency

[Ray Toal]

In article <3ls7u0$3v1@stc06.ctd.ornl.gov> mbk@jt3ws1.etd.ornl.gov (Kennel) writes:

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

>> In a previous article, robertb@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.Bethel@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

Re: Language Efficiency

[Robert Dewar]

Please substantiate the "heresy" that different languages make a big
difference in generated code efficiency.

Re: Language Efficiency

[Adam Beneschan]

In article <dewar.797512974@gnat> dewar@cs.nyu.edu (Robert Dewar) writes:

> 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
> 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.

In a slightly later article, Robert writes:
 
> With regard to the "unexpected penalty" for (others => (others => 0)),
> aggregates certainly generate pretty horrible code in Ada. . . .
                                                     ^^^^^^
not

> aggregates certainly generate pretty horrible code in some
> particular implementations of Ada. . . .

Hmmmmmm . . .

                                -- Adam

Re: Language Efficiency

[Robert Dewar]

Adam notes the following curious quotes from this inconsistent guy dewar:

> With regard to the "unexpected penalty" for (others => (others => 0)),
> aggregates certainly generate pretty horrible code in Ada. . . .
                                                     ^^^^^^
not

> aggregates certainly generate pretty horrible code in some
> particular implementations of Ada. . . .


OOPS!,  quite right, just shows how easy it is to fall into the ways
of sin :-) :-)
I meant of course the second (although I think I have to say nearly all,
instead of some particular :-)

Re: Multiple dispatch (was Re: C++ not OOP?)

[Robert I. Eachus]

In article <3n1als$ksi@no-names.nerdc.ufl.edu> kem@prl.ufl.edu (Kelly Murray) writes:

 > But we have a device that can do a draw-line real fast, so we want to
 > use it when we can, for example, on a square shape.  We must know that
 > a shape can provide the line information.  Thus, the draw method is
 > really specialized for not a square, but a lined-shaped object which
 > a square should inherit from, and return

 >  (defmethod draw ((dev line-device) (shape lined-shape))
 >    (dolist (line (shape-lines shape))
 >     (draw-line dev line)))

 > I believe this is basically the same strategy that Robert Eachus
 > has outlined.  I don't see how it could fit easily into a 
 > single-dispatch model.  Which object is doing the dispatching?
 > Do we make the device explicitely ask the shape at run-time 
 > if it can support a given operation? :

   No.  I may not have explained it well.  Let me see if I can use
your example to elucidate.  First, in Ada 95--and in some other
OO-languages--objects may be passed as non-dispatching parameters,
then used internal to the called procedure to dispatch on.  So you can
end up doing two-level dispatching, in this case first on the shape,
then on the device.

   If you specified drawing a square in terms of drawing four lines:

   procedure Draw(S: Square; L: Location; D: Device) is
   begin
      Draw_Line(Make_Line(S.Side,Horizontal),L, D);
      Draw_Line(Make_Line(S.Side,Vertical),L, D);
      Draw_Line(Make_Line(S.Side,Vertical),L+Horizontal_Displacement(S.Side),
           D);
      Draw_Line(Make_Line(S.Side,Horizontal),L+Vertical_Displacement(S.Side),
           D);
   end Draw;

   If we defined Line and Point as part of the primitive set of
operations for all devices, this is all we have to do to add drawing
squares.  (Notice that in Ada 95, the dispatching parameter can be
located anywhere in the parameter list.) Regular pentagons might be a
bit more work, but the principle is the same.

   (Note that to make things neater, you probably have some
definitions of the form:

   procedure Draw(S: Line; L: Location; D: Device) is
   begin Draw_Line(S,L,D); end Draw;

   to do the outer dispatch where the shape to be drawn is a run-time
parameter.  This is the "extra" bookkeeping required by not having
multiple dispatch in the language.) 

   Now when adding a new device, the requirements might be to provide
definitions for Point, Line, Circle, and Cubic_Spline.  Other
primitives could be provided if easily supported--say Ellipse,
Parabola, and Polygon, and even possibly Square and Rectangle--but
these would have default definitions in terms of the other primitives.
The definitions would be overridden if there was a more efficient
direct implementation for some device, and then only if you wanted the
extra efficiency.

  > Or make the shapes explicitely check for the fast operations?

    No, that should be implicit in the call tree.  In the above
example, Draw for a Square calls Line.  If for some device, Line
calls Point, that will occur within Line.  If there was a default
Square definition and it was overridden for some device, fine.

    An alternative is to have two ways to draw some shape, and have a
nested case statement to choose the "better" method based on the
device.  Seems like a maintenance nightmare, but the only damage done
if version control fails is that the less efficient method will be
used.

  > To add a device or shape, create a new index, and a bigger table.

   Arrrgh!  In my model you should never have to "recompile the
world."



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Multiple dispatch (was Re: C++ not OOP?)

[Kenneth Almquist]

Robert Eachus interpreted the example problem slightly differently than
I did.  I assumed that (1) the system might have to support shapes and
devices which were very different than those anticipated when the system
was designed and (2) to achieve adequate drawing speeds it is necessary
to do a fairly good job of adapting to the capabilities of the various
devices.  Under these assumptions, Robert's design no longer guarantees
the O(1) subroutine counts he intended.

If a new shape is added, along with some devices which support an
operation specificly designed to support that shape, then to achieve
adequate efficiency (see assumption 2) it may be necessary to add a
new optional operation to Robert's design.

More seriously, suppose that there is a shape which approximates a
complex curve using a series of arc drawing operations.  Then a device
appears which can efficiently draw parabola segments but not arcs
Drawing the complex curve by generating a series of arcs which are in
turn translated into parabola segments will result in more parabola
segments than optimal.  If the result doesn't meet our performance
requirements, we have to modify the definition of the shape to query
the device and use either arcs or parabola segments as appropriate.
The design may avoid this particular problem, but assumption 1 implies
that something similar will eventually happen.

The design presented by Robert is still usable even with my assumptions.
The failure to achieve development effort proportional to the number
of features is inherent in the problem.[1]  However, it is sometimes
necessary to modify exiting shape routines rather than just add new
routines.  This is undesirable but certainly not fatal.

The problem I see with multiple dispatch is this:  Frequently it is
easy to express a high level description of a problem in terms of
multiple dispatch, but multiple dispatch normally requires you to
write too many routines.  The solution that I have been toying with is
application specific dispatch.  The idea is that you write the minimum
number of implementations of an abstract routine required to solve a
problem, and then develop an application-specific method of selecting
which implementation to call in a specific instance.  This minimizes
the number of instances at the cost of increasing the complexity of
determining which instance to call.

I think that a case can be made for the use of application-specific
multiple dispatch is the best approach for the shape-displaying
problem because it allows you to avoid modifying (as opposed to
adding) implementations of routines.  However, it is a weak case
because the application specific dispatching code may have to be
modified.
				Kenneth Almquist



[1] It might be possible to write a program which read descriptions
    of the shapes and devices, and generate code to display each
    shape on each device.  Once this program was written, the
    programmer cost to implement a feature would be O(1).  My guess
    is that this approach is not very practical.

Re: Language Efficiency

[Paul Graham]

Here's an example of language-based inefficiency.  Suppose I want to allocate
a structure and initialize its fields to some safe value, say 0.  In C I
would write

	ptr = malloc(sizeof(struct_type));
	memset(ptr, '\0', sizeof(struct_type));

In Ada I would write

	ptr := new struct_type'(others => 0);

or

	ptr := new struct_type;		-- assuming I want the default values

The call to memset in the C example can be quite inefficient.  memset does
not know that ptr is a word-aligned address, so it must fill in the
structure using byte moves.  I suppose memset could be clever and check for
the alignment of ptr and the value of sizeof(struct_type), and jump to an
appropriate loop which uses byte moves, word moves, longword moves, etc.

The Ada code should know that ptr will be word-aligned.  Assuming that it
doesn't first create a temporary aggregate, it should be able to fill in
ptr's fields efficiently using word moves.

I could achieve the same effect in C by writing

	ptr = malloc(sizeof(struct_type));
	ptr->x = 0;
	ptr->y = 0;
	...

but this style of initialization breaks easily if I ever add a new field to
struct_type.

Paul
--
Paul Graham 	graham@compass-da.com	Compass Design Automation, Inc.
(speaking only for myself)	"Cekoslovakyalilastiramadiklarimizdanmissiniz."

Re: Language Efficiency

[Robert Dewar]

Paul, in your example or initializing a malloc'ed variable, very trivial
value tracing would allow the compiler to know that the argument is
malloc (i..e. maximally) aligned. Yes, I know you can construct an example
where it is undecidable what the alignment is, but in fact value and
pointer type tracing in C can give remarkably accurate information.

Re: C++ not OOP? (Was: Language Efficiency

[Fernando Mato Mira]

In article <3n0uvi$8jt@atlantis.utmb.edu>, Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:

> > hear from a reliable source that it is a "pure OOPL". What conclusions 
> > can you draw about this language that would tell you whether it is 
> > better suited to your purposes than, say, C+$, which is not a "pure 
> > OOPL"?
> 
> The conclusions that I would draw are:
> 
>    #1. All code must be attached to objects.
> 
>       i. I will not be able to write a procedure that
>          is independent -- it must be attached to an object

No. This is Single-dispatch Fallacy #1.
Encapsulation problem is now solved, thanks to Craig Chambers..

>    #2. All data must be encapsulated within objects.

Hm. Must be encapsulated, maybe. Within objects, I dunno..

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

Re: C++ not OOP? (Was: Language Efficiency

[Curtis Bass]

matomira@di.epfl.ch (Fernando Mato Mira) wrote:

-- snip --

> >       i. I will not be able to write a procedure that
> >          is independent -- it must be attached to an object
> 
> No. This is Single-dispatch Fallacy #1.
> Encapsulation problem is now solved, thanks to Craig Chambers..

If I can write a procedure that is NOT attached to an object,
then I am NOT using a "PURE" OOPL.

-- snip --

> F.D. Mato Mira           http://ligwww.epfl.ch/matomira.html                  


				Curtis Bass
				Software Systems Specialist II
				University of Texas Medical Branch

Re: C++ not OOP? (Was: Language Efficiency

[David Weller]

In article <3n3o9c$cud@atlantis.utmb.edu>,
Curtis Bass  <cbass%intmeds1.utmb@mhost.utmb.edu> wrote:
>If I can write a procedure that is NOT attached to an object,
>then I am NOT using a "PURE" OOPL.
>
Curtis, please cite the references you have used to gain this silly
notion.


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

Re: C++ not OOP? (Was: Language Efficiency

[Curtis Bass]

dweller@Starbase.NeoSoft.COM (David Weller) wrote:
>
> In article <3n3o9c$cud@atlantis.utmb.edu>,
> Curtis Bass  <cbass%intmeds1.utmb@mhost.utmb.edu> wrote:
> >If I can write a procedure that is NOT attached to an object,
> >then I am NOT using a "PURE" OOPL.
> >
> Curtis, please cite the references you have used to gain this silly
> notion.

#1. The fact that you dismiss this "notion" as "silly" proves
    to me that your mind is made up, and that you are not
    willing to listen, learn, or expand your horizons in any
    way. If you wish to remain ignorant, then, obviously, I
    cannot prevent it.

#2. I know what "pure" means, and I know what "object-oriented"
    means. Also, I know what "paradigm," "structured," and
    "model" mean. Ergo, I can state what "pure object-oriented
    programming language" means, based on the definitional
    building-blocks I already have at my disposal.

#3. I have seen the term "pure" used to describe languages
    such as Actor, Smalltalk, and Eiffel in printed articles
    in widely available trade magazines. However, I have no
    intention of rummaging through all of my Dr. Dobbs and
    Computer Language back issues in order to pacify you. I
    don't remember which article or column, out of the hundreds
    that are in those magazines, actually contain the reference,
    nor do I care. I know what I know. If you decide to reject
    it, then I couldn't care less. There are others in this
    newsgroup who think that the distinction between "pure"
    and "impure" OOPL's is minor. I do not. Who is right?
    We ALL are. Or, in other words, Who Cares?

    Someone asked, "Why is C++ an 'impure' OOPL?" I simply
    answered his question. If you have problems with this,
    then I am sorry. Really.

#4. What I WILL do is refer you to Grady Booch's FIRST edition
    of "Object-Oriented Design with Applications," appendix A2,
    page 474. I will NOT reprint the relevant text. Go look it
    up yourself.


				Curtis Bass
				Software Systems Specialist II
				University of Texas Medical Branch

Re: C++ not OOP? (Was: Language Efficiency

[David Weller]

In article <3n5oup$g2s@atlantis.utmb.edu>,
Curtis Bass  <cbass%intmeds1.utmb@mhost.utmb.edu> wrote:
>dweller@Starbase.NeoSoft.COM (David Weller) wrote:
>>
>> In article <3n3o9c$cud@atlantis.utmb.edu>,
>> Curtis Bass  <cbass%intmeds1.utmb@mhost.utmb.edu> wrote:
>> >If I can write a procedure that is NOT attached to an object,
>> >then I am NOT using a "PURE" OOPL.
>> >
>> Curtis, please cite the references you have used to gain this silly
>> notion.
>
>[Moderate flames deleted]

Um, was it just me, or did Curtis shed more heat than light?  All I"m
asking is for you to answer the question.  I saw Grady's comments,
but I'd hardly consider that some kind of philosophical foundation.
I certainly wouldn't build a house on it (or even a doghouse :-)

Perhaps a better way to formulate it is: How do you defend syntactic
differences as somehow rendering something more "pure" than another?
-- 
      Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	  For all sorts of interesting Ada95 tidbits, run the command:
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
		if u cn rd ths, u r gd enuf to chg to Ada   :-)

Re: C++ not OOP? (Was: Language Efficiency

[Curtis Bass]

dweller@Starbase.NeoSoft.COM (David Weller) wrote:
>
> In article <3n5oup$g2s@atlantis.utmb.edu>,
> Curtis Bass  <cbass%intmeds1.utmb@mhost.utmb.edu> wrote:
> >dweller@Starbase.NeoSoft.COM (David Weller) wrote:
> >>
> >> In article <3n3o9c$cud@atlantis.utmb.edu>,
> >> Curtis Bass  <cbass%intmeds1.utmb@mhost.utmb.edu> wrote:
> >> >If I can write a procedure that is NOT attached to an object,
> >> >then I am NOT using a "PURE" OOPL.
> >> >
> >> Curtis, please cite the references you have used to gain this silly
> >> notion.
> >
> >[Moderate flames deleted]
> 
> Um, was it just me, or did Curtis shed more heat than light?  All I"m
> asking is for you to answer the question.  I saw Grady's comments,
> but I'd hardly consider that some kind of philosophical foundation.
> I certainly wouldn't build a house on it (or even a doghouse :-)

Had you avoided the word "silly," you would have avoided the
heat. I don't like having my intelligence questioned. You can
question my views and opinions all you want, but if you start
condescending toward my intelligence level, you'd better be
wearing asbestos.

We are not discussing a "philosophical foundation," but simply
the difference(s) between "pure" and "hybrid" OOPL's. As I said
in my previous post, I was just answering another poster's
question re: why C++ is not "pure" in the OOP sense. You
obviously have a problem with this, and there is obviously
nothing I can do about it.

> Perhaps a better way to formulate it is: How do you defend syntactic
> differences as somehow rendering something more "pure" than another?

Listen, "pure" does NOT necessarily mean "good" or "holy" or
"righteous." Saying that C++ is not a "pure" OOPL is NOT
saying that C++ is "sinful" or "evil." No, pure (in this
context) simply means homogeneous, and "impure" simple means
heterogeneous, and this is WRT the programming model(s).
C++ DIRECTLY supports TWO models; Structured and Object-
Oriented, ergo, it is heterogenous, ergo, it is not purely
an OOPL. Smalltalk directly supports ONLY ONE paradigm:
Object-Oriented programming, ergo, it is homogeneous, ergo,
it is purely an OOPL. What I cannot fathom is why this
offends people, as if I am committing some sort of religious
heresy by saying these things.

Yes, yes, YES. I KNOW that you can "do procedural programming"
in Smalltalk. Who cares? Smalltalk STILL only supports the
Object-Oriented model directly. If you want to do procedural
programming, you should NOT use Smalltalk -- other languages
are better suited. If you INSIST on doing procdural programming
in Smalltalk, you can do it, but only by fighting the language
and not by working with the language. You have to attach your
procedures to an object -- there is no way around this. As Booch
says, "everything is an object" in Smalltalk -- there are no
procedures, only methods. You CAN do structured programming in
old-fashioned BASIC, but there are other languages that are
better suited. You can do spaghetti programming in Pascal,
but there are other languages that are better suited. All this
rambling means is this: Doing "procedural" programming in a
"pure" OOPL does NOT invalidate the definition of "pure," nor
does it make the distinction between "pure" and "hybrid" invalid.

If you had bothered to read my previous post, I admitted that
the distinction between "pure" and "hybrid" OOPL's may or may
not have any value to a person, and that I couldn't care less
one way or the other.

So, basically, there is nothing to "defend."


				Curtis Bass
				Software Systems Specialist II
				University of Texas Medical Branch

Re: C++ not OOP? (Was: Language Efficiency

[Fernando Mato Mira]

In article <3n60kc$gki@atlantis.utmb.edu>, Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:

> says, "everything is an object" in Smalltalk -- there are no
         ^^^^^^^^^^^^^^^^^^^^^^^

You got it. This is the definition of pure OO. Even your
control structures are objects.

If you look at Lisp, for example, it is definitely not pure because you have
normal non-virtual functions, control structures are not objects, etc.

However, all functions (even `dirty ones') are objects. Methods are objects
stored in a generic function. Methods contain specializer lists (objects),
which contain references to classes (or `eql specializers).

As you can see, in some sense the classes are `inside' the methods. Note
that this does not happen in a language like C or Pascal. So, in some
sense, it's a reverse world, and very object-oriented.

Also, CLOS can be even considered `not really object-oriented' because
of the lack of encapsulation. This has nothing to do with all the stuff
above, but with the lack of a better module system. 
Cecil looks at object-orientedness very much like Ada, and CLOS, and
has solved the encapsulation problem in a great way.

You seem to be very concerned about philosophical issues, so if
you haven't done it yet, I would recommend you to take a look at CLOS and Cecil;
not necessarily to use them, but you should find it very stimulating 
and I'm sure it'll open your mind to whole new perspectives on OO..

Regards,

PS: I'm not saying that Cecil is `pure'. But the same argument holds..

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

Re: C++ not OOP? (Was: Language Efficiency

[Robert Martin]

Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:

>Listen, "pure" does NOT necessarily mean "good" or "holy" or
>"righteous." 

Do you really believe that?  Come now.  The word "pure" will always
have the connotation of "goodness".  That's why it is used so often to
advertise toilet paper and douches.

>Saying that C++ is not a "pure" OOPL is NOT saying that C++ is
>"sinful" or "evil."

But that is the way it will be interpreted.


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

Re: C++ not OOP? (Was: Language Efficiency

[Ed Osinski]

In article <1995Apr21.192110.7609@rcmcon.com>, rmartin@rcmcon.com (Robert Martin) writes:
|> Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:
|> 
|> >Listen, "pure" does NOT necessarily mean "good" or "holy" or
|> >"righteous." 
|> 
|> Do you really believe that?  Come now.  The word "pure" will always
|> have the connotation of "goodness".  That's why it is used so often to
|> advertise toilet paper and douches.
|> 
|> >Saying that C++ is not a "pure" OOPL is NOT saying that C++ is
|> >"sinful" or "evil."
|> 
|> But that is the way it will be interpreted.

I would have to agree.  I wonder how strongly people would argue about 
how something is "a pure object-oriented language" if "a pure" is replaced
with "just an".

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

-- 
---------------------------------------------------------------------
 Ed Osinski                  
 Computer Science Department, New York University         
 E-mail:  osinski@cs.nyu.edu 
---------------------------------------------------------------------
In the early years of the 16th century, to combat the rising tide of
religious unorthodoxy, the Pope gave Cardinal Ximinez of Spain leave
to move without let or hindrance throughout the land, in a reign of
violence, terror and torture that makes a smashing film.  This was
the Spanish Inquisition...
				-- Monty Python's Flying Circus

Re: C++ not OOP? (Was: Language Efficiency

[Robert Dewar]

when people argue about whether something is pure or not, they must have
ulterior motives. You can't believe that people put this much energy into
arguing about something that is just terminology.

what is going on here is the underlying reasoning

  x is pure
  pure is good
  therefore x is good

at least this syllogism doesn't have a divided middle, but it's really
pretty thin! Why not argue about specific technical features, whose presence
or absence is objectively determinable, and then discuss why or why not
you think the features is a GOOD THING!

Re: C++ not OOP? (Was: Language Efficiency

[Curtis Bass]

dewar@cs.nyu.edu (Robert Dewar) wrote:
>
> when people argue about whether something is pure or not, they must have
> ulterior motives.

Yeah, like setting the record straight . . .

Look, person A said that C++ wasn't a "pure" OOPL.

Person B asked "Why?"

Person C (me) answered person B's question -- CORRECTLY.

Everybody gets offended at this, as if person C blasphemed
against someone's god(s).

Why?

> ulterior motives. You can't believe that people put this much energy into
> arguing about something that is just terminology.
> 
> what is going on here is the underlying reasoning
> 
>   x is pure
>   pure is good
>   therefore x is good

Nope, nope, nope, a thousand times, nope.

It's more like:

	X is pure

	Y is not pure

	Therefore, it may be easier to do some
	things in Y than it would in X. You CAN
	do these things in X, but the result is
	a bad implementation of X's paradigm.
	You may be better off using Y. If you
	need to use X's paradigm, then there
	may be advantages to using X instead of
	Y, but maybe not.

I repeat: Why do people take offense at this?

> at least this syllogism doesn't have a divided middle, but it's really
> pretty thin! Why not argue about specific technical features, whose presence
> or absence is objectively determinable, and then discuss why or why not
> you think the features is a GOOD THING!

The fact that Y directly supports multiple programming
paradigms IS a "technical feature." The fact that X does
NOT is ALSO a "technical feature."

There are pros and cons to both:

			PRO:			CON:

	PURE:		generally cleaner	somewhat rigid,
			implementation		since only one
						paradigm is
						supported

			simpler, more		may require
			consistent syntax	retraining,
						minimal skillset
						reuse

	IMPURE:		allows the use of	implementation
			current paradigm	may be complex,
			skillset		inelegant

			generally more		synatx is less
			flexible		consistent

	etc.

Like all such issues, simply saying that "pure is good
and impure is bad" is simplistic and reveals ignorance
on the part of anyone making such a statement. It may
be useful to distinguish between the two, and it may
not, depending on the situation. Saying that the
distinction is universally useless is just as simplistic
and ignorant as saying "pure is good and impure is bad."


				Curtis Bass
				Software Systems Specialist II
				University of Texas Medical Branch

Re: C++ not OOP? (Was: Language Efficiency

[Robert Dewar]

OK Curtis, then since we are just talking terminology, with no other kind
of motives, let's choose an unloaded word (you could after all choose a
loaded word on the other side, like restrictive). how about something
like "centered", which seems pretty neutral. 

But somehow, I don't think people would put nearly as much energy into the
debate on either side if we were just asking whether C++ was object-centered
...

Re: C++ not OOP? (Was: Language Efficiency

[Robert Martin]

>> Curtis Bass  <cbass%intmeds1.utmb@mhost.utmb.edu> wrote:
>> >If I can write a procedure that is NOT attached to an object,
>> >then I am NOT using a "PURE" OOPL.
>> >

>dweller@Starbase.NeoSoft.COM (David Weller) wrote:
>> Curtis, please cite the references you have used to gain this silly
>> notion.

Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:
>#4. What I WILL do is refer you to Grady Booch's FIRST edition
>    of "Object-Oriented Design with Applications," appendix A2,
>    page 474. I will NOT reprint the relevant text. Go look it
>    up yourself.

Here it is:

    [Speaking of Smalltalk] 'It is a "pure" object oriented
    programming language, in that everything is viewed as an object -
    even integers and classes.'

------

Notice how much emotion has been shed over this argument?  The reason
is that "pure" is an emotionally charged word.    The argument has
been made in this group, many times, that students would be better off
learning a "pure" OOPL, or that applications are better if programmed
in a "pure" OOPL.  

What these arguments do not do, is what Grady did above.  He defined
the term.  

As it happens, I don't much care for Grady's definition.  For one
thing, I don't understand the benefit of 'purity' as he describes it.
In fact, he was not claiming any such benefit to exist.  For another,
I don't like coupling that definition with a word that carries such
emotional baggage.


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

Re: C++ not OOP? (Was: Language Efficiency

[Matt Austern]

In article <3n43p0$ehs@Starbase.NeoSoft.COM> dweller@Starbase.NeoSoft.COM (David Weller) writes:

> >If I can write a procedure that is NOT attached to an object,
> >then I am NOT using a "PURE" OOPL.
> >
> Curtis, please cite the references you have used to gain this silly
> notion.

Who needs a definition?  It's apparently his definition of the word
"pure".  Definitions are arbitrary; he can define the phrase
"pure object-oriented language" however he feels like.

The rest of us, of course, don't have to accept that the way he
distinguishes between "pure" and "impure" languages is a particularly
useful distinction.  Personally, I don't.  I think that this
distinction is almost completely trivial: whether or not functions
must always be attached to classes is an essentially syntactic issue.
--
Matt Austern				      matt@physics.berkeley.edu
http://dogbert.lbl.gov/~matt

Re: C++ not OOP? (Was: Language Efficiency

[Robert Martin]

Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:

>     iv. Since it is a pure OOPL, there is a great
>         likelihood that the language itself is of
>         a fairly simple and elegant design. OTOH,
>         C+$ will probably be a very complex language,
>         since it supports two different programming
>         paradigms (structured and OO). 

Then you think that Objective_C is "very complex" and Eiffel is "very
simple".   

I submit that you are, without saying so, assuming that all hybrids
must be as complex as C++, and all non-hybrids must be as simple as
Smalltalk.  That is quite a big assumption.

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

Re: C++ not OOP? (Was: Language Efficiency

[Curtis Bass]

rmartin@rcmcon.com (Robert Martin) wrote:

-- [post deleted] --

This is degenerating into testosterone-crazed posturing. All
I did was correctly answer someone's question. Why do you get
offended at this? Why do you strut around, trying to say that
YOUR view of the world is "better" than mine?

For the record, Grady Booch calls Smalltalk a "pure" OOPL.
Frankly, I prefer to adopt his view of the world rather than
yours.

> Robert Martin       | Design Consulting   | Training courses offered:


			Curtis Bass

Re: C++ not OOP? (Was: Language Efficiency

[Matt Austern]

In article <1995Apr21.190040.7332@rcmcon.com> rmartin@rcmcon.com (Robert Martin) writes:

> What these arguments do not do, is what Grady did above.  He defined
> the term.  
> 
> As it happens, I don't much care for Grady's definition.  For one
> thing, I don't understand the benefit of 'purity' as he describes it.

What's really interesting is that the definition Curtis quoted isn't
the same as the one he's (implicitly) using!  The definition he's
using is that a "pure" OOL is one in which it's impossible to define
functions that don't belong to objects.  The one he quoted, though, is
that a "pure" OOL is one in which everything is an object.

I agree that "pure" is a loaded word and that we should stop using it.
However, I do see the benefits of having a language where classes and
basic built-in types and operating system resources are objects;
languages like that make it much easier to treat things consistently.
A well-designed class hierarchy that includes the basic types and
that's rooted in some class like Object or ANY can sometimes be quite
useful.

It's not foolish to make a distinction between languages that have
that sort of hierarchy and that have a base class from which all
classes inherit, and languages that don't.  "Pure" is probably the
wrong word to use for that distinction; can anyone suggest a better?
--
Matt Austern				      matt@physics.berkeley.edu
http://dogbert.lbl.gov/~matt

Re: C++ not OOP? (Was: Language Efficiency

[David Weller]

In article <MATT.95Apr21124916@physics2.berkeley.edu>,
Matt Austern <matt@physics.berkeley.edu> wrote:
>It's not foolish to make a distinction between languages that have
>that sort of hierarchy and that have a base class from which all
>classes inherit, and languages that don't.  "Pure" is probably the
>wrong word to use for that distinction; can anyone suggest a better?
>--

How about something that gives a relative sense of how much the
language is centered around accessing both data and operations around
encapsulated declarations of objects...  object-oriented, in other
words. :-)

One nice thing about adopting the concept of "scale" of
"object-oriented" is that we can be dispassionate about it, since
there are many, many other scales to consider when using or selecting
a language (flexibility comes to mind as one example...there is very
little correlation between the flexibility of a language and it's
OO-ness).


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

Re: C++ not OOP? (Was: Language Efficiency

[Robert Martin]

matt@physics2.berkeley.edu (Matt Austern) writes:

>I agree that "pure" is a loaded word and that we should stop using it.
>However, I do see the benefits of having a language where classes and
>basic built-in types and operating system resources are objects;
>languages like that make it much easier to treat things consistently.

Do you agree that a language in which *everything* is an object is
intrinsically more limited than a language in which the programmer
gets to decide what to put in an object and what to keep out?  Do you
also agree that programs designed for the first type of language can
be implemented in the second type, more easily that vice versa?  If
so, do you agree that the benefits of the first type automatically
transfer to the second type?

>A well-designed class hierarchy that includes the basic types and
>that's rooted in some class like Object or ANY can sometimes be quite
>useful.

Sometimes, although I generally prefer not to have a single root to
the inheritance tree.

>It's not foolish to make a distinction between languages that have
>that sort of hierarchy and that have a base class from which all
>classes inherit, and languages that don't.

Agreed.  

"Pure" is probably the
>wrong word to use for that distinction; can anyone suggest a better?

Sure.  Tree model languages have all objects rooted at some top level
object.  Forest model language can have many independent disconnected
inheritance hierarchies.

This is a nomenclature that has been used to describe class libraries.
I think it covers languages quite nicely too.

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

OOAD courses by Object Mentor

[cjames]

In article <1995Apr22.171719.4120@rcmcon.com>, <rmartin@rcmcon.com> 
writes:
:
:
> 
> -- 
> Robert Martin       | Design Consulting   | Training courses offered:
>Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
>2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
>Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++
> 

Mr Martin:

Does Object Mentor Assoc address what is below in training courses, 
and what is your opinion on the following:

1.  Bertrand Meyer writes in the Series Editor's Preface, page xii, to 
"Seamless object-oriented software architecture : analysis and design 
fo reliable systems" by Kim Walen and Jean-Marc Nerson, 1995, Prentice 
Hall (UK), ISBN: 0-13-031303-3:

     "From now on, no one will be able to claim knowledge of 
object-oriented analysis and design who has not read Kim Walden and 
Jean-Marc Nerson.", namely, the instant textbook.

2.  Grady Booch's method is one-dimensional, and hence is not useful 
for complicated projects.

3.  Jim Rumbaugh's OMT method is ambiguous, and hence can not be 
verified correct at the design level.


cjames@envisionet.net

Colin James III
CEC Services
2080 Kipling St
Lakewood, CO  80215-1502  U S A

303.231.9437  Voice
303.231.9438  Facsimile

Re: C++ not OOP? (Was: Language Efficiency

[Ed Osinski]

In article <3n0uvi$8jt@atlantis.utmb.edu>, Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:
|> pete@borland.com (Pete Becker) wrote:
|> 
|> -- snip --
|> 
|> > 	Suppose you are evaluating a new language, say, C+#, and you 
|> > hear from a reliable source that it is a "pure OOPL". What conclusions 
|> > can you draw about this language that would tell you whether it is 
|> > better suited to your purposes than, say, C+$, which is not a "pure 
|> > OOPL"?
|> 
|> The conclusions that I would draw are:
|> 
|>    #1. All code must be attached to objects.

	- snip -

|>      iv. Since it is a pure OOPL, there is a great
|>          likelihood that the language itself is of
|>          a fairly simple and elegant design. OTOH,
|>          C+$ will probably be a very complex language,
|>          since it supports two different programming
|>          paradigms (structured and OO). Also, with
|>          C+#, I can rest assured that the syntax is
|>          uniform (all procedures will have an object
|>          ID prefix). C+$ would allow me to have SOME
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|>          procedures WITH an object ID prefix, and some
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|>          WITHOUT one. This could lead to confusion for
            ^^^^^^^^^^^^

I just want to point out that this is not necessarily true.  
Ada95 is an example where *all* procedure calls, whether they 
are 'methods' or not, look the same.

|>          the maintenance programmers. Also, such code
|>          would represent a rather messy, inelegant
|>          design, which would be less of an option in C+#.

	- snip -

|> 				Curtis Bass
|> 				Software Systems Specialist II
|> 				University of Texas Medical Branch

-- 
---------------------------------------------------------------------
 Ed Osinski                  
 Computer Science Department, New York University         
 E-mail:  osinski@cs.nyu.edu 
---------------------------------------------------------------------
In the early years of the 16th century, to combat the rising tide of
religious unorthodoxy, the Pope gave Cardinal Ximinez of Spain leave
to move without let or hindrance throughout the land, in a reign of
violence, terror and torture that makes a smashing film.  This was
the Spanish Inquisition...
				-- Monty Python's Flying Circus

Re: C++ not OOP? (Was: Language Efficiency

[Robert Martin]

>pete@borland.com (Pete Becker) wrote:

>> 	Suppose you are evaluating a new language, say, C+#, and you 
>> hear from a reliable source that it is a "pure OOPL". What conclusions 
>> can you draw about this language that would tell you whether it is 
>> better suited to your purposes than, say, C+$, which is not a "pure 
>> OOPL"?

Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:

>The conclusions that I would draw are:

>   #1. All code must be attached to objects.

>      i. I will not be able to write a procedure that
>         is independent -- it must be attached to an object

This does not guarantee that the stucture of your procedures or your
objects will be in any way superior to those written in C+$.  So of
what use it it?

>     ii. It would behoove me to have an Object-Oriented
>         Design (as opposed to a Structured Design) of
>         the system before I start coding in C+#, because
>         writing structured code will not be an option.
>         (Yes, I can kludge it by having just one object,
>         and attaching all of the code to that object, but
>         the result technically would still not be an
>         example of "structured programming," but would
>         rather be an example of BAD OO programming). 

Saying that it is BAD doesn't eliminate it as an option.  In any case,
you could make the identical argument about C+$.  It would behoove you
to have an object oriented design!

>    iii. My programming team had better be fluent in OO
>         concepts before using C+#, because there is no
>         mechanism for writing structured C+# today, and
>         gradually growing into Object-Oriented C+#
>         tomorrow.

This is the same argument as number ii, just rephrased.  In any case
it is just as true for C+$.  Your programming team had better be
fluent in OO if they are going to implement an OOD.

>     iv. Since it is a pure OOPL, there is a great
>         likelihood that the language itself is of
>         a fairly simple and elegant design. OTOH,
>         C+$ will probably be a very complex language,
>         since it supports two different programming
>         paradigms (structured and OO). 

I am sure that you cannot substantiate this claim.

>         Also, with
>         C+#, I can rest assured that the syntax is
>         uniform (all procedures will have an object
>         ID prefix). 

What do you mean?  A prefix?  Do you mean that all procedures will
belong to an object?  Isn't this your point i above?

>         C+$ would allow me to have SOME
>         procedures WITH an object ID prefix, and some
>         WITHOUT one. This could lead to confusion for
>         the maintenance programmers. 

How?  

>         Also, such code
>         would represent a rather messy, inelegant
>         design, which would be less of an option in C+#.

Why?  Are designs with nothing but objects always cleaner than designs
that sometimes have global functions?  I'd like to see the proof of that.

>   #2. All data must be encapsulated within objects.

>      i. There will not be any variables that are global
>         to the application, unless they reside in a
>         "root" object. Even in this case, we can have
>         more control over their scope and accessability
>         than would be avalable in C+$. In C+$, any global
>         variable we have would be accessable by ANY
>         procedure we write. In C+#, this would not be
>         the case.

Unless all procedures and data were in the same object.  Then there is
no control at all.

>     ii. I can create new data types more easiliy, by
>         deriving them from existing data types, then
>         changing only that which needs to be changed,
>         and inhereting the rest of the functionality
>         from the parent data type. Since C+$ is not
>         a pure OOPL, then variables are not objects,
>         and therefore I would not have this capability.

In C+$ you would have this ability with any kind of variable you
desired to have it with.


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

Re: C++ not OOP? (Was: Language Efficiency

[Curtis Bass]

rmartin@rcmcon.com (Robert Martin) wrote:

-- [post deleted] --

You are simply, perhaps deliberately, missing the point.

> Robert Martin       | Design Consulting   | Training courses offered:


				Curtis Bass

Re: Multiple dispatch (was Re: C++ not OOP?)

[Fernando Mato Mira]

In article <3n1als$ksi@no-names.nerdc.ufl.edu>, kem@prl.ufl.edu (Kelly Murray) writes:

> One could do it using a NO OBJECT DISPATCH too, using a two-dimensional
> array where each shape and device is given a unique index.
> Then we can define functions for each pairing filling the table
> initially with default primitives.
> 
> (defun draw (any-dev any-shape)
>   (funcall (aref *draw-table (device-index any-dev) 
>                              (shape-index any-shape))))
> 
> To add a device or shape, create a new index, and a bigger table.
                                                             ^^^^^
There's a kind of two-level dispatch in IRIS Inventor 
(first one is a table lookup) because of C++'s limitations
(eg: impossibility of adding virtuals to a class without
access to its sources).


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

Re: C++ not OOP? (Was: Language Efficiency

[James McKim]

In article <1995Apr13.152104@di.epfl.ch> Stephane.Barbey@di.epfl.ch (Stephane Barbey) writes:
>In article <3mg45s$5r7@disunms.epfl.ch>, matomira@di.epfl.ch (Fernando Mato Mira) writes:
>: 
>: 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.
>: 
>
>I'm not Dewar, but you could take a look at 
>
>  William Harrison and Harold Ossher, "Subject-oriented Programming (A
>  critique of pure objects)", in the proceedings of OOPSLA '94, p.
							     ^^
>  411-428.

Quick correction. That's OOPSLA '93.

>
>
>
>
>-Stephane

Hope this helps,
-- Jim

>
>
>--
>Stephane Barbey				"It's not easy getting real wings"	
>INJ-335, barbey@di.epfl.ch


-- 

*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458     Co-editor of Eiffel Outlook 
Internet:  jcm@hgc.edu        Subscribe early and often!

Re: C++ not OOP? (Was: Language Efficiency

[Norman H. Cohen]

In article <3muavq$46u@atlantis.utmb.edu>, Curtis Bass
<cbass%intmeds1.utmb@mhost.utmb.edu> writes: 

|> ncohen@watson.ibm.com (Norman H. Cohen) wrote: 
...
|> >            It is easy to do a straightforward transliteration of a
|> > Fortran IV program into Smalltalk, for example.
|>
|> Perhaps. However, I maintain that the result is NOT "purely
|> procedural." It has to be Object-Oriented, even if all of
|> your code is attached to only one object. This would be
|> like writing a single procedure in Pascal -- the resulting
|> program is not "unstructured," is it? The structure is not
|> "good," but it's better than spaghetti code.
|>
|> The bottom line is that your "straightforward transliteration
|> of a Fortran IV program into Smalltalk" will STILL result in
|> an Object-Oriented program, although it will have bad OO
|> Design. There is no way around it -- your procedures cannot
|> exist as independent entities; they must be attached to an
|> object.

That's a pretty superficial definition of what constitutes OOP.
Given that all-encompassing definition, there's no point in wasting time
discussing what attributes OO programs might or might not possess.

Mechanically applying labels is a silly exercise.  Suppose I were to
write a new language named Bigtalk.  Its reference manual is identical to
the Smalltalk manual, except that all occurrences of the word "object"
have been replaced by "egg salad" (after which the sentence "Some
computer scientists egg salad to this approach," has been restored to its
original form).  Would you say that if the Fortran transliteration is fed
to a Bigtalk interpreter instead of a Smalltalk interpreter, it now
consitutes an egg-salad-oriented program instead of an object-oriented
program, because all procedures are attached to egg salads?

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: C++ not OOP? (Was: Language Efficiency

[Curtis Bass]

ncohen@watson.ibm.com (Norman H. Cohen) wrote:
>
> In article <3muavq$46u@atlantis.utmb.edu>, Curtis Bass
> <cbass%intmeds1.utmb@mhost.utmb.edu> writes: 
> 
> |> ncohen@watson.ibm.com (Norman H. Cohen) wrote: 
> ....
> |> >            It is easy to do a straightforward transliteration of a
> |> > Fortran IV program into Smalltalk, for example.

-- snip --

> |> The bottom line is that your "straightforward transliteration
> |> of a Fortran IV program into Smalltalk" will STILL result in
> |> an Object-Oriented program, although it will have bad OO
> |> Design. There is no way around it -- your procedures cannot
> |> exist as independent entities; they must be attached to an
> |> object.
> 
> That's a pretty superficial definition of what constitutes OOP.
> Given that all-encompassing definition, there's no point in wasting time
> discussing what attributes OO programs might or might not possess.

You missed the point. Plain and simple. I guess you are one
of the many who simply don't WANT to get it.

I don't understand why this is, and why people INSIST on
being offended by all of this.

> Mechanically applying labels is a silly exercise.  Suppose I were to
> write a new language named Bigtalk.  Its reference manual is identical to
> the Smalltalk manual, except that all occurrences of the word "object"
> have been replaced by "egg salad" (after which the sentence "Some
> computer scientists egg salad to this approach," has been restored to its
> original form).  Would you say that if the Fortran transliteration is fed
> to a Bigtalk interpreter instead of a Smalltalk interpreter, it now
> consitutes an egg-salad-oriented program instead of an object-oriented
> program, because all procedures are attached to egg salads?

Technically, the answer to your question is "yes." So what?
If you want to think that "object-oriented" is as meaningless
as "egg salad," as a definition of a paradigm, then that's
your business. Just don't tell me that I have to think the
way you do. Decreeing that your opinion on this matter must be
treated as the universal truth is ill-advised. Besides, as I
have stated, this misses the point entirely.

It appears that those who object to the term "object-oriented"
are not aware of what is is, what it means, or what benefits
it provides.

> Norman H. Cohen    ncohen@watson.ibm.com



				Curtis Bass
				Software Systems Specialist II
				University of Texas Medical Branch

Re: C++ not OOP? (Was: Language Efficiency

[Robert Martin]

rmartin said:
>> Would that 'twere so.  Actually, all OOPLs are conducive to the
>> implementation of structured programs.   This must be so.  Consider
>> that a structure program is an amalgam of data structures and
>> functions.  In an OOPL we could create a single object which contains
>> all these data structures and functions.  Voila, a structured program
>> implemented in a OOPL.

Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:

>I maintain that this is STILL not a "strictly procedural" model,
>but is rather a very BAD OO model. 

Now wait.  I can implement a structured design in both C and
Smalltalk.  The semantics of the design will be identical in both
languages.   Are you saying that some mysterious attribute of the
language (which you call "purity) transforms this design from
"structured" to "object oriented" just because it happens to be
implemented in Smalltalk?  If so, then I submit that this mysterious
attribute is utterly useless since it cannot disambiguate a structure
design from an object oriented design.

>The bottom line is that all that your example illustrates is bad OO
>programming practice

It illustrates more than that.  It illustrates that the attribute that
you call "purity" does not enforce object oriented design, or good OO
programming practice.  So, of what value is this attribute?  What does
this attribute help us to do? 

>The term DOES have useful a definition, and I have provided
>one that's perfectly valid.

Validity is not the same as usefulness.  Defining a "pure OOPL" as "a
language in which everything is an object" is perfectly valid, but not
very useful.  The question that comes to mind is: "so what?" 

>As far as what I am saying" is concerned, what I am saying is
>simply this: C++ IS Object-Oriented, but not in the "pure" sense.
>Smalltalk IS "purely" Object-Oriented. You can write strictly
>procedural code in C++, You CANNOT in Smalltalk -- the best
>you can do in Smalltalk (or other "purely OOPL's) is to have
>just ONE object with all of your procedural code attached to it.
>THIS IS STILL OBJECT-ORIENTED, although very poorly so. 

Well, that is quite a stretch.  You are saying that any code written
in Smalltalk must be object oriented.  Of what use is this definition?


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

Re: C++ not OOP? (Was: Language Efficiency

[Curtis Bass]

rmartin@rcmcon.com (Robert Martin) wrote:

-- [post deleted] --

This is degenerating into testosterone-crazed posturing. All
I did was correctly answer someone's question. Why do you get
offended at this? Why do you strut around, trying to say that
YOUR view of the world is "better" than mine?

For the record, Grady Booch calls Smalltalk a "pure" OOPL.
Frankly, I prefer to adopt his view of the world rather than
yours.

> Robert Martin       | Design Consulting   | Training courses offered:


				Curtis Bass

Re: C++ not OOP? (Was: Language Efficiency

[Robert Dewar]

Am I confused by who is saying what at this stage:

"This is degenerating into testosterone-crazed posturing. All
I did was correctly answer someone's question. Why do you get
offended at this? Why do you strut around, trying to say that
YOUR view of the world is "better" than mine?"

Is this Curtis replying to someone else, or someone talking to Curtis,
or perhaps Curtis talking to himself? :-)

Re: C++ not OOP? (Was: Language Efficiency

[Robert Martin]

Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:

>rmartin@rcmcon.com (Robert Martin) wrote:

>-- [post deleted] --

>This is degenerating into testosterone-crazed posturing. 

Net rule #1,934,512.332

   When you don't have any more substance to fling at your opponent,
   then refer to his/her hormones.

>For the record, Grady Booch calls Smalltalk a "pure" OOPL.
>Frankly, I prefer to adopt his view of the world rather than
>yours.

I don't think his point of view and your point of view are very close.
He, at least would dicuss the matter with me, and would do me the
honor of considering that my point of view was based upon rational
thought rather than gonadal reaction.

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

Re: C++ not OOP? (Was: Language Efficiency

[Harley Davis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

In article <3n0tk9$149v@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:

   |> Question:  Using single dispatch, how does one code a subroutine to display
   |> a given shape on a given device?
   |>
   |> Answer:  Well, you have to pick either the shape object or the device object
   |> to control dispatch.  The methods, then, will contain big cases around the
   |> type of the other object supplied.  For example, each device could act
   |> differently according to the shape given it (via some ugly case or switch type
   |> construction), or each shape could act differently according to the device
   |> given it (via another ugly case or switch type construction).

   This is obviously a poorly designed solution.  The right approach
   is to come up with an "abstract device" with concrete
   implementations corresponding to each actual device.  The routine
   to write a given shape on a given device dispatches based on the
   shape, passing the device object as a parameter.  The routine to
   write a given shape issues calls on the abstract device interface,
   and these calls dispatch based on the underlying concrete device.

This approach is not contradictory with the multiple dispatch
approach.  Multiple dispatch can enhance your solution.

Start with an abstract interface to devices.  Write routines for all
shapes which use this abstract interface.  Then, for speed critical
shape/device pairs, write more specific multimethods which use
underlying device implementation information for optimization.
Indeed, I believe this is the textbook approach to using multimethods.

-- Harley Davis
-- 

------------------------------------------------------------------------------
Harley Davis                            net: davis@ilog.fr
ILOG S.A.                               tel: +33 1 46 63 66 66
2 Avenue Galli�ni, BP 85                fax: +33 1 46 63 15 82
94253 Gentilly Cedex, France            url: http://www.ilog.com/

           Ilog Talk information: info@ilog.com

Re: C++ not OOP? (Was: Language Efficiency

[ron house]

Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:

>matt@physics10.berkeley.edu (Matt Austern) wrote:
>>
>> That's the distinction between "pure" and "hybrid" object-oriented
>> language?  The distinction is simply whether it's possible to define
>> routines that don't belong to objects?
>> 
>> That strikes me as a really minor issue; it never would have occurred
>> to me, in fact, to use that one feature as the basis for a whole
>> distinction.  (And yes, I have used both languages where such routines
>> may exist and languages where they may not.)  This is more a matter of
>> syntax than anything else, and it has no significant effect on
>> programming style or organization.

>In a pure OOPL, it is virtually impossible to avoid encapsulation.
>All procedures must be attached to a data structure, and the data
>in that structure can only be accessed by the attached procedures.
>Global variables don't exist as such, which means that all data
>MUST be a apart of an object.

>In a hybrid, data and procedures can exist as separate entities.
>Encapsulation is not enforced, and can be abandoned entirely.

>If you want to think of these as "minor" issues, I obviously
>cannot stop you. Personally, I don't think they're minor at all.

I think the original point was that we can define a single huge
object that contains all the procedures of an erstwhile nonOO
program. The erstwhile globals become the data of the object and
the procedures the methods. Thus, with absolutely no change in
process during software design, the OO language can be used to
produce something that has an identical structure as before. So
I would agree with Matt: this is really a minor issue. Therefore
I don't class this as the OO distinction. OO is a design method
which languages can support or not. OO is not a language
property. The design method is to find datatypes with well-
defined behavioural properties and make them into abstract
data types, and to design similar things by inheritance relations,
which will in turn allow polyporphism via method overriding.

--

Ron House.         USQ                   | A nonviolent diet is the
(house@usq.edu.au) Toowoomba, Australia. | foundation for a nonviolent world.

Re: C++ not OOP? (Was: Language Efficiency

[Robert Martin]

Curtis Bass <cbass%intmeds1.utmb@mhost.utmb.edu> writes:

>In a pure OOPL, it is virtually impossible to avoid encapsulation.
>In a hybrid, data and procedures can exist as separate entities.
>Encapsulation is not enforced, and can be abandoned entirely.

If, in Smalltalk, I put all the procedures and all the data structures
into a single object, then I have avoided and abandoned encapsulation
for all intents and purposes.  The data are just as encapsulated as
they would be in C.

Oh I agree that there is still an object that encapsulates all that
data and procedure; but nobody references it, so the data is not
encaspulated away from anyone.  i.e. if I put a fence around the
universe, I am not really doing anything useful.

>Also, this has a MAJOR affect on program organization.

But it doesn't, and you have agreed with that.  A procedural design
can be implemnented in smalltalk; thus smalltalk need have no affect
at all on program organization.

Now, this is the crux, is OO a matter of language syntax, or a matter
of program organization?  I presume that most people would agree that
the benfits of OO accrue because of the program structure; i.e. it is
the program structure that is object oriented, and not the language
syntax.  I submit that the definition of OO, should be related more
to the program structure than a language syntax.


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

Re: C++ not OOP? (Was: Language Efficiency

[Curtis Bass]

rmartin@rcmcon.com (Robert Martin) wrote:

-- [post deleted] --

This is degenerating into testosterone-crazed posturing. All
I did was correctly answer someone's question. Why do you get
offended at this? Why do you strut around, trying to say that
YOUR view of the world is "better" than mine?

For the record, Grady Booch calls Smalltalk a "pure" OOPL.
Frankly, I prefer to adopt his view of the world rather than
yours.

> -- 


				Curtis Bass

Re: Multiple dispatch (was Re: C++ not OOP?)

[Robert I. Eachus]

In article <D79o2K.K0o@nntpa.cb.att.com> ka@socrates.hr.att.com (Kenneth Almquist) writes:

 > Robert Eachus interpreted the example problem slightly differently than
 > I did.  I assumed that (1) the system might have to support shapes and
 > devices which were very different than those anticipated when the system
 > was designed and (2) to achieve adequate drawing speeds it is necessary
 > to do a fairly good job of adapting to the capabilities of the various
 > devices.  Under these assumptions, Robert's design no longer guarantees
 > the O(1) subroutine counts he intended.

    Hmmm.  I certainly agree with (1), I'll argure from practical
experience that my approach does deal with (2).  You just need a "rich"
enough set of optional primitives to cover the set of possible engines.

 > If a new shape is added, along with some devices which support an
 > operation specificly designed to support that shape, then to achieve
 > adequate efficiency (see assumption 2) it may be necessary to add a
 > new optional operation to Robert's design.

   Agreed, but this is not a limitation.  If you look at what you are
saying, it is that evolving requirements may result in an evolving
design.  But there is no need for massive restructuring in this
case--you add the new shape, and the "optional" primitive that you
need to define it, say Bessel functions, and a (base) implementation
in terms of other primitives.  At this point in Ada 95 you need to do
a "global" recompile because you have added a dispatching operation.
Then add each new device as usual.  Of course given the stated
assumptions you have additional work on each one because you want to
map the Bessel operation specially for each of these devices.

 > The problem I see with multiple dispatch is this:  Frequently it is
 > easy to express a high level description of a problem in terms of
 > multiple dispatch, but multiple dispatch normally requires you to
 > write too many routines.

   I totally agree.  During the Ada 9X development process, I actually
looked at the advantages and disadvantages of supporting multiple
dispatch.  It could have been done, but there are precious few cases
where the additional generality buys anything, and the educational
overhead is there forever.

 > The solution that I have been toying with is application specific
 > dispatch.  The idea is that you write the minimum number of
 > implementations of an abstract routine required to solve a problem,
 > and then develop an application-specific method of selecting which
 > implementation to call in a specific instance.  This minimizes the
 > number of instances at the cost of increasing the complexity of
 > determining which instance to call.

   Don't do that! ;-)  Seriously, in Ada the best way of satisfying
this need is with generic instantiation.  I can (and do) have a
library of several sorts with the same generic interface.  But rather
than letting some AI routine select the best one, I, as the designer,
choose the best sort for this application.

 > [1] It might be possible to write a program which read descriptions
 >     of the shapes and devices, and generate code to display each
 >     shape on each device.  Once this program was written, the
 >     programmer cost to implement a feature would be O(1).  My guess
 >     is that this approach is not very practical.

     Depends on your definition of practical.  It looks like a pretty
good description of how curses works, except that curses does it more
dynamically.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: C++ not OOP? (Was: Language Efficiency

[Norman H. Cohen]

In article <DAVIS.95Apr19112448@passy.ilog.fr>, davis@ilog.fr (Harley Davis)
writes: 

|> Start with an abstract interface to devices.  Write routines for all
|> shapes which use this abstract interface.  Then, for speed critical
|> shape/device pairs, write more specific multimethods which use
|> underlying device implementation information for optimization.
|> Indeed, I believe this is the textbook approach to using multimethods.

Yes, this is a far more compelling argument.

Of course this approach should only be used with one's eyes wide open
about the tradeoff between efficiency and maintainability: If the
implementation of a device is changed, it is no longer sufficient to
modify the method providing the standard interface.  You have to (1)
track down and (2) modify each of the specific multimethods.  (1) is the
hard part, since an interim solution for (2) is just to delete the
specialized multimethod and revert to the general method.

It should be noted that even in languages without direct linguistic
support for multiple dispatch, the same effect can be achieved in a
straightforward way by redispatching.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: C++ not OOP? (Was: Language Efficiency

[Fernando Mato Mira]

In article <3n8jdv$jer@watnews1.watson.ibm.com>, ncohen@watson.ibm.com (Norman H. Cohen) writes:

> It should be noted that even in languages without direct linguistic
> support for multiple dispatch, the same effect can be achieved in a
> straightforward way by redispatching.

Of course. And you can achieve the same effect as single-dispatch by
using function pointers in a C program..

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

Re: C++ not OOP? (Was: Language Efficiency

[Erik Naggum]

[Fernando Mato Mira]

|   In article <3n8jdv$jer@watnews1.watson.ibm.com>, ncohen@watson.ibm.com (Norman H. Cohen) writes:
|   
|   > It should be noted that even in languages without direct linguistic
|   > support for multiple dispatch, the same effect can be achieved in a
|   > straightforward way by redispatching.
|   
|   Of course. And you can achieve the same effect as single-dispatch by
|   using function pointers in a C program..

unless I have missed something crucial, I think both of you may have missed
something crucial.

your idea seems to be to have Grand Unifying Classes from which devices and
shapes inherit Grand Unifying Methods, such that all shapes are implemented
using a set of abstract methods that all devices implement.  I object to
the very idea of Grand Unifying Classes, on the grounds that abstraction
that achieves a Unifying Abstraction over devices (in particular) will have
great cost in both the abstraction process and the implementation, more
notably the abstraction process.  whereas it is nearly trivial to design
and implement drawing a shape on a device using device-specific code, it is
exceedingly hard to design the Abstract Device that will capture sufficient
power of real devices, not to mention ways to optimize the Grand Unifying
Methods for a particular device.

one of the reasons that I found "object-oriented" programming in C++ to be
exceedingly hard was the requirement to make counter-intuitive and overly
abstract abstractions only to conform to the lack of ability to dispatch to
the proper classes.  I have only experimented with CLOS and Dylan, but what
I found was indeed that I could write better code to do specific tasks, and
that I could intuit the abstract classes, if and when appropriate _after_ I
had the necessary experience to talk about them, and _after_ I had a chance
to decide whether they were indeed appropriate.  for me, programming is a
learning process, and I found that C++ was actively hindering that process,
whereas both CLOS and Dylan encourage me to make abstractions when I have a
greater understanding, an understanding that could not exist prior to
design and implementation of individual subclasses of some Unknown Grand
Unifying Class.

maybe I'm doing something wrong, but premature abstraction seems as bad as
or worse than premature optimization, both of which are encouraged by C++
and discouraged by both CLOS and Dylan.

(I'd appreciate if someone more experienced in either language would let me
know if I'm wandering off in the wrong direction.)

#<Erik>
--
sufficiently advanced political correctness is indistinguishable from irony

Re: Language Efficiency

[Fergus Henderson]

ka@socrates.hr.att.com (Kenneth Almquist) writes:

>Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:
>> 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.
>
>The Icon compiler from the University of Arizona does global type
>inference as part of translating Icon to C.  The type inference is
>certainly not "trivial," but the compiler as a whole is relatively
>simple.

What does the Icon compiler do when a variable can have more than one
type depending on the input to the program?

-- 
Fergus Henderson            | Tell you what: go write a 100x100 matrix multiply
fjh@cs.mu.oz.au             | of integers in both languages and then let's talk
http://www.cs.mu.oz.au/~fjh | about speed, ok? - Tom Christiansen.

Re: Language Efficiency

[Kenneth Almquist]

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) asks:
> What does the Icon compiler do when a variable can have more than one
> type depending on the input to the program?

It generates code that checks the type at run time and performs
operations appropriate for the type.
					Kenneth Almquist

Re: Language Efficiency

[Fergus Henderson]

dewar@cs.nyu.edu (Robert Dewar) writes:

>Please substantiate the "heresy" that different languages make a big
>difference in generated code efficiency.

Sure.  There's a language called Prolog, which has been around
for a decade or two now.  Lots of effort has been put into optimizing it.
Hundreds of papers have been written.  Dozens of implementations have
been developed.

I and a couple of others have developed a new language called Mercury
over the last year or two.  Mercury is similar to a subset of
Prolog with additional declarations.

We've done quite a bit of benchmarking, and the Mercury compiler
produces code that is on average about 70% faster than the code
produced by the best optimizing Prolog compiler, Aquarius Prolog, for a
set of small benchmarks.  (For real-world code the difference is almost
certainly _larger_ than 70%, since the techniques used in the Mercury
compiler scale better to large programs than those used in Aquarius Prolog.)

This difference in efficiency is precisely because Mercury was deliberately
designed to make it much easier to generate efficient code.

Note that in it's most optimizing mode, Aquarius Prolog does not
support certain features of Prolog, because they prevent some optimizations.
If you invoke Aquarius Prolog in a mode which supports those features,
the generated code is about a factor of two slower.  So if you compare
Mercury to that, we're about 3.4 times faster.
(The feature in question is the ability to write `read(X), call(X)',
which can call any predicate with any arguments depending on the input.)

For more details, including detailed performance tables, see

	The execution algorithm of Mercury: an efficient purely
	declarative logic programming language.  Zoltan Somogyi, Fergus
	James Henderson and Thomas Charles Conway.

available from http://www.cs.mu.oz.au/~zs/mercury.html.

-- 
Fergus Henderson            | As practiced by computer science, the study of
fjh@cs.mu.oz.au             | programming is an unholy mixture of mathematics,
http://www.cs.mu.oz.au/~fjh | literary criticism, and folklore. - B. A. Sheil

Re: Language Efficiency

[Robert Dewar]

Fergus notes the comparison of peformance of Prolog and Mercury, and states
that Mercury is up to 70% faster:

(The feature in question is the ability to write `read(X), call(X)',
which can call any predicate with any arguments depending on the input.)

But how can forbidding a feature POSSIBLY mean that you can compile faster.
If it is possible to compile faster if read(x) and call(x) are avoided, then
surely a prolog compiler can just look at your program, see if you use these
features, and use one of two totally different compilation strategies
depending on the answer.

Of course I understand that this makes implementation harder, and it is
indeed true that you have to work very hard to deal with difficult
problems, but you often can deal with them  much better than you might
imagine.

Another example from SNOBOL-4

In SNOBOL-4, when you access any variable by name, as in the access to 
Q in  the assignment

 	R = Q

you have to check if Q is input associated (and if so, read from a file), and
if it is trace associated (and if so, call a user defined trace routine).
Similarly the assignment to R may write to a file or call a userdefined
trace procedure. The I/O associations and trace associations are completely
dynamic, and it is impossible to tell at compile time whether any given
reference needs the extra tests.

Yes, without ANY loss of dynamic flexibility, the 370 SPITBOL compiler
does these tests with precisely ZERO overhead in the most common case
where the variables R and Q are never associated. ZERO doesn't just mean
small, it means ZERO!

Re: Language Efficiency

[Kennel]

Robert Dewar (dewar@cs.nyu.edu) wrote:
> But how can forbidding a feature POSSIBLY mean that you can compile faster.
> If it is possible to compile faster if read(x) and call(x) are avoided, then
> surely a prolog compiler can just look at your program, see if you use these
> features, and use one of two totally different compilation strategies
> depending on the answer.

If the compiler can see the whole program at once! And you have to
write two compilers. :-O

I find this difference rather odd:

	* It's dogma that the choice of theoretical processor
	  architecture {hardware language}
	  makes a big difference in the eventual speed
	  of its implementation.  Note, not the "maximum possible given
          any technology imaginable" but the realistic "likely given
          economic constraints."  Proven by empirical example. 

	* But it's very controversial that the choice of software language 
          design can make a big difference in eventual speed of its
	  implementation, given reasonable economic constraints.
	  {Personally I think this is also demonstrated by empirical
	   example.}

cheers
matt

Re: Language Efficiency

[Robert Dewar]

matt says:

"If the compiler can see the whole program at once! And you have to
write two compilers. :-O

I find this difference rather odd:

        * It's dogma that the choice of theoretical processor
          architecture {hardware language}
          makes a big difference in the eventual speed
          of its implementation.  Note, not the "maximum possible given
          any technology imaginable" but the realistic "likely given
          economic constraints."  Proven by empirical example."

Yes indeed (see the whole program at once, and you have to write two
compilers). To argue that language features make it easier or more
difficult to achieve X is one thing, to argue that these differences
are fundamental is another.

one should always be hesitatnt to accept "dogma", and one should be
especially hesitant to accept the allegation that something is "dogma"
as a substitute for effective technical argument. Things that are
"obvious" and which "everyone knows" are not always what they seem
(the G&S song from Pinafore is applicable to a wide range of environments :-)

"Proven by empirical example"

Hm? Sure most compilers do little out of the ordinary, and normal expected
behavior is much as one might expect, but there are plenty of examples
which point in the opposite direction from "dogma".

I will give just one: Jim Boyle has for many years worked on the
transformational compilation of high level LISP programs. He starts with
a high level abstract statement of the numerical algorithm written in
nice high level idiomatic Lisp. Out of the end of a (complex!) set of
compilation processes comes efficient generated fortran code that runs
at comparable speed to hand generated fortran for the same problem.

Re: Language Efficiency

[Larry Kilgallen]

In article <3lrrqk$kbj@usenet.INS.CWRU.Edu>, bb206@cleveland.Freenet.Edu (Harold P Zbiegien) writes:
> 
> In a previous article, robertb@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.Bethel@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

Re: Language Efficiency

[Robert Dewar]

"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.

Re: Language Efficiency

[Matt Austern]

In article <dewar.798342918@gnat> dewar@cs.nyu.edu (Robert Dewar) writes:

> Yes indeed (see the whole program at once, and you have to write two
> compilers). To argue that language features make it easier or more
> difficult to achieve X is one thing, to argue that these differences
> are fundamental is another.

I think everybody agress about what's going on, we're just choosing to
emphasize different things.

If certain optimizations are possible in principle in two different
languages, but if they are vastly more difficult in one language than
in the other, then it is both correct and misleading to say that
efficiency differences between the two languages are purely issues of
implementation.

"Possible in principle" and "possible" are two different concepts.
--
Matt Austern				      matt@physics.berkeley.edu
http://dogbert.lbl.gov/~matt

Re: Language Efficiency

[Robert I. Eachus]

In article <MATT.95Apr20113010@physics10.berkeley.edu> matt@physics10.berkeley.edu (Matt Austern) writes:

  > If certain optimizations are possible in principle in two different
  > languages, but if they are vastly more difficult in one language than
  > in the other, then it is both correct and misleading to say that
  > efficiency differences between the two languages are purely issues of
  > implementation.

    I have worked on two different compilers which adopted the same
approach to optimization and gotos.  Normal compilation assumed that
there were no gotos in scope.  If a goto was encountered, a switch was
set and compillation restarted from the beginning.  An elegent
technique for languages where gotos are rare in practice but legal.
(The compilers mentioned above were for Pascal and Ada, and developed
by different companies.)

    In addition I know of at least one Ada compiler which lays out a
record during processing of the declaration, and if it later
encounters rep clauses, it just repeats the work from scratch.

    So, yes, in practice many compilers do ignore language features
which make compilation or optimization more difficult, and have a
completely different mode or routine when those features are
encountered.  With the Pascal compiler mentioned above, since it
supported multiple compilation units, it was a "known rule" that you
should put any gotos in the smallest possible compilation.  An awful
lot of optimization got turned off.  The Ada compiler was much better
behaved, about the only thing affected was spilling of register
variables.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Language Efficiency

[Bob Kitzberger]

Robert C. Bethel (robertb@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	        rlk@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

Re: Language Efficiency

[Mike Wilson]

> 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                                      mrw@oasis.icl.co.uk
ICL Medical Portfolio, Kings House, Kings Road, Reading, RG1 3PX, UK

Re: Language Efficiency

[David Weller]

In article <D6K812.7w8@oasis.icl.co.uk>,
Mike Wilson <mrw@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 dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
		if u cn rd ths, u r gd enuf to chg to Ada   :-)

Re: Language Efficiency

[Larry Kilgallen]

In article <D6K812.7w8@oasis.icl.co.uk>, mrw@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

Re: Language Efficiency

[Mitch Gart]

Robert C. Bethel (robertb@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

Re: Language Efficiency

[Lawrence Free/ A.F. Software Services]

Robert C. Bethel (robertb@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.Bethel@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: free@mcs.com
A.F.Software Services, Inc. | Your MS/DOS, UNIX
(708) 232-0790              | business software developer

Re: Language Efficiency

[Ken Leidner]

In article <3lmt64$stt@dplanet.p2k.cbis.com>, robertb@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
kleidner@earthlink.net 

Re: Language Efficiency

[Larry Kilgallen]

In article <3lvru0$bv5@mars.earthlink.net>, kleidner@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