🚀 go-pugleaf

Alex Martelli (martelli@cadlab.cadlab.it) wrote:
> nagle@netcom.com (John Nagle) writes:
> 	...
> >     It's interesting to compare Java with C++.  Java is semantically
> >closer to Delphi, though; it's one of those all-objects-on-the-heap,
> >strongly typed, reference semantics, OOP languages.  Although Java
> >has C syntax, it really is closer to some of the Object Pascal
> >type OOPs.

> Exactly my thoughts!  Like Sather, Eiffel, or Modula-3, to name three
> other "all-objects-on-heap, strongly-typed, reference-semantics OOP
> languages" for which good freeware or shareware implementations with
> reasonably rich and useful libraries are easily available from the net
> (I suspect Oberon, and several other no doubt excellent languages, 
> also fall under this broad category, but have no first-hand experience
> of them and their implementations).

I know this is picking nits, but at least Sather and Eiffel do not
require "all-objects-on-heap and reference-semantics" for all objects.

(My omission of other languages is only because I do not know the answer,
 not an implication of a difference)

That would lead to inefficient code when performing involved 
iterations and computations elementary data types (you want an array of 
value-floats just like Fortran).  Still it's desirable to keep elementary
types inside the normal object system thus Sather and Eiffel have simple
ways of explicitly declaring types to work "in value style" and with the
obvious efficient implementation.  Eiffel uses the keyword "expanded"
when declaring the variables and Sather uses the keyword "value" when
declaring the class.

This scheme gives the programmer clear and explicit choice over the semantics
and thus doesn't force you to "step beyond the bounds" of the normal language
in order to do something fast such as involved numerical calculation.

You get elemetary types like INT, and BIT et cetera inside the
normal typing scheme, and high performance when needed. (In Sather you can 
declare an abstract superclass over elementary types, say $RING_ELEMENT) 

Variables typed with value classes and expanded classes also do not allow
dispatching so that a big array of these objects does not include any
excess space for 'type tags' or 'vtables'. (there is one type tag per
array, but none per element).  When they are used in a context of an
abstract type, they gain them so they can be a 'possible substitution'. 

> I _suspect_ 90% or more of actual programs being written to not need
> the multi-paradigmic character of C++, or, to be more precise, do not
> really need the huge potential it offers for optimization _enough_ to
> make it worth paying the cost of the "boilerplate" etc that one has
> to pay for it. 

Actually I object somewhat to the characterization of "C++ as offering
huge potential for optimization"---at least in the numerical realm
this is not true as a result of a few interlocking design consequences
of C++; it's not easy to write native C++ matrix classes which get as 
sufficiently optimized as native C or Fortran.  (I've posted the reasons
here before).  The Sather group at ICSI is putting in specific optimizations
to support fast matrix computations (without special casing any specific
matrix class!) that ought to yield performance equal to idiomatic C. 
These optimizations would be much more difficult in C++ without a very
high performance and sophisticated implementation (at minimum one that
does not compile .cc to .o files separately but considers the program
'in toto').

There is a short recent article in Computers in Physics discussing
Sather by David Stoutamire and M.K., as well as one a year or so ago 
discussing C++ in numerical programming. 

cheers
Matt