Re: What is wrong with OO ?

Re: What is wrong with OO ?

[Ell]

Jon S Anthony (jsa@alexandria) wrote:
: ell@access5.digex.net (Ell) writes:
: 
: > Ian Joyner (i.joyner@acm.org) wrote:
: > : Ell wrote:
: > : > 
: > : > Ian Joyner (i.joyner@acm.org) wrote:
: > : > 
: >: > : What made me think of this was that Bill Gates stated in his book that
: >: > : Boeng designed the entire 777 aircraft using one gigantic electronic
: >: > : document! Physical engineering disciplines have made good use of
: >: > : computing technology, it's about time software engineers followed
: >: > : the same path... better and more productive languages and environments,
: >: > : and stop defending archaic 25 year old languages from another era.
  
: > : > I find some 25 year languages like C++ very useful even today.  A lot of
: > : > following a good OO paradigm is in how tools are used and approached.
  
: > : And people can still drive model T Fords, and fly WWI planes. 
 
: > I find the key aspects of C++ to be within the parameters of the
: > _progressive_ OO paradigm and practice.  In many ways C++ has led and
: > still leads in the expression and implementation of many significantly
: > useful OO concepts.
 
: With respect to this "led/leads" claim: Such as?????  I can't think of
: _any_ where this is true.  Though I can think of at least one
: important _implementation_ aspect where this seems to be true.

Led (first or second) wrt the OO paradigm: Private data members, static
resolution of overloaded functions, protected members, and multiple
inheritance. Correct me if I'm wrong.  Remember this is wrt the early
'80's.

Elliott

Re: What is wrong with OO ?

[Jon S Anthony]

In article <5acjtn$5uj@news3.digex.net> ell@access1.digex.net (Ell) writes:

> Jon S Anthony (jsa@alexandria) wrote:
> : With respect to this "led/leads" claim: Such as?????  I can't think of
> : _any_ where this is true.  Though I can think of at least one
> : important _implementation_ aspect where this seems to be true.
> 
> Led (first or second) wrt the OO paradigm: Private data members, static
> resolution of overloaded functions, protected members, and multiple
> inheritance. Correct me if I'm wrong.  Remember this is wrt the early
> '80's.


Recheck your facts.  Led/lead means "first" to me and certainly
carries that connotation around with it even if you want to pull a
Humpty Dumpty.  Private data member stuff was in various languages
before "C with classes" was even conceived (e.g., CLU, Ada83).  It
certainly existed in Eiffel before C++ was christened.  Protected
capability was certainly in Eiffel-1 which predates C++.  Same with
overload resolution (e.g., Algol68 had this as did Ada 83 compilers
that were in the field before CWC or C++).  MI was in Eiffel from the
start and that predates its appearance in C++ for sure.

Next I suppose you will be trying to tell me it was the first to have
generics (templates) or namespaces or assignment attempt or RTTI or...

C++ was and is a _follower_.  That is not necessarily a bad thing, but
it is anything _but_ innovative.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Robert C. Martin]

In article <JSA.97Jan1181506@alexandria>, jsa@alexandria (Jon S Anthony) wrote:

> 
> C++ was and is a _follower_.  That is not necessarily a bad thing, but
> it is anything _but_ innovative.
> 

WRT technology I agree with you.  But C++ *does* show innovation in a
completely different vein.  C++ is one of the first of the industrial OO
languages that was created for the engineer instead of for the paradigm.  
C++ was not created to be "pure" or "right" or "correct".  It was created
to be *used*.  And in that regard it represents an innovation wrt industrial
OO languages.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Eirik Mangseth]

Robert C. Martin wrote:
> 
> In article <JSA.97Jan1181506@alexandria>, jsa@alexandria (Jon S Anthony) wrote:
> 
> >
> > C++ was and is a _follower_.  That is not necessarily a bad thing, but
> > it is anything _but_ innovative.
> >
> 
> WRT technology I agree with you.  But C++ *does* show innovation in a
> completely different vein.  C++ is one of the first of the industrial OO
> languages that was created for the engineer instead of for the paradigm.
> C++ was not created to be "pure" or "right" or "correct".  It was created
> to be *used*.  And in that regard it represents an innovation wrt industrial
> OO languages.
> 
> --
> Robert C. Martin    | Design Consulting   | Training courses offered:
> Object Mentor       | rmartin@oma.com     |   Object Oriented Design
> 14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
> Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
> 
> "One of the great commandments of science is:
>     'Mistrust arguments from authority.'" -- Carl Sagan

Sorry, but you are wrong. This is one of the many myths that surrounds
C++. No engineer I know would use any tool pertaining to his or her
profession that was as badly designed and implemented as C++. "Pure"
pragmatism is not an option with respect to language design, something
even Mr. Stroustrup himself acknowledges.

If any language was designed for engineers (software engineers that is),
it must be Eiffel.

/Eirik Mangseth/emangset@online.no/United Consultants, Oslo Office,
Norway/

-All opinions expressed are my own and does not necessarily reflect the
views of my employer.

Re: What is wrong with OO O X g

[Greg Comeau]

In article <32CCE4ED.6A21@online.no> emangset@online.no writes:
>Robert C. Martin wrote:
>> 
>> In article <JSA.97Jan1181506@alexandria>, jsa@alexandria (Jon S Anthony) wrote:
>> 
>> >
>> > C++ was and is a _follower_.  That is not necessarily a bad thing, but
>> > it is anything _but_ innovative.
>> >
>> 
>> WRT technology I agree with you.  But C++ *does* show innovation in a
>> completely different vein.  C++ is one of the first of the industrial OO
>> languages that was created for the engineer instead of for the paradigm.
>> C++ was not created to be "pure" or "right" or "correct".  It was created
>> to be *used*.  And in that regard it represents an innovation wrt industrial
>> OO languages.
>> 
>> --
>> Robert C. Martin    | Design Consulting   | Training courses offered:
>> Object Mentor       | rmartin@oma.com     |   Object Oriented Design
>> 14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
>> Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
>> 
>> "One of the great commandments of science is:
>>     'Mistrust arguments from authority.'" -- Carl Sagan
>
>Sorry, but you are wrong. This is one of the many myths that surrounds
>C++. No engineer I know would use any tool pertaining to his or her
>profession that was as badly designed and implemented as C++. "Pure"
>pragmatism is not an option with respect to language design, something
>even Mr. Stroustrup himself acknowledges.

I have not a clue what you are talking about.  Indeed, the beauty
of C++ is that it is a hybrid and that it does not lock you into one
particular thing.  Robert is indeed correct about its flexibility
and avoidance of so-called political correctness.  Since when are
pragmatics not important in design, decisions, engineering?

You mention myths but only defend it by claiming something closing
into the notion of outrageous that you know of no engineer who
programs in C++.  You say he is wrong -- then counter his 1/2 dozen or
so claims.  Re Stroustrup, I'm not clear what you claim he acknowledges,
so it would also be nice to provide the source for any such information.

- Greg
-- 
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421

Re: What is wrong with OO ?

[Jon S Anthony]

In article <rmartin-0201971129150001@pool11-018.wwa.com> rmartin@oma.com (Robert C. Martin) writes:

> In article <JSA.97Jan1181506@alexandria>, jsa@alexandria (Jon S Anthony) wrote:
> 
> > 
> > C++ was and is a _follower_.  That is not necessarily a bad thing, but
> > it is anything _but_ innovative.
> > 
> 
> WRT technology I agree with you.  But C++ *does* show innovation in a
> completely different vein.  C++ is one of the first of the industrial OO
> languages that was created for the engineer instead of for the paradigm.  
> C++ was not created to be "pure" or "right" or "correct".  It was created
> to be *used*.  And in that regard it represents an innovation wrt industrial
> OO languages.

Oh, I don't know.  I think C++ was created simply because BS was
saddled with C (at ATT) and wanted _something_ that had a least _some_
abstraction capabilities in it.  Voila.  C++.  Whether it is any more
"usable" than several other options is highly open to question.  And
in fact, in general I would say the answer is "no".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Matt Austern]

jsa@alexandria (Jon S Anthony) writes:

> Oh, I don't know.  I think C++ was created simply because BS was
> saddled with C (at ATT) and wanted _something_ that had a least _some_
> abstraction capabilities in it.  Voila.  C++.  Whether it is any more
> "usable" than several other options is highly open to question.  And
> in fact, in general I would say the answer is "no".

It's not necessary to speculate on why Bjarne Stroustrup made the
design decisions that he did: he discusses them, in a fair amount
of detail, in _The Design and Evolution of C++_.

I probably shouldn't try to summarize an entire book in a single
sentence.  One thing he makes very clear in his book, though, is that
he was trying to create a language that, like C, made it possible to
write low-level programs, but that also, like Simula, included
high-level abstraction facilities.  

This combination is, if not unique to C++, at least rare.  It's also
quite clear that it was a design goal from the very beginning.

Re: OO, C++, and something much better!

[Pieter Schoenmakers]

In article <32ce7009.280817694@news.zip.com.au> skaller@maxtal.com.au (John (Max) Skaller) writes:

   Is C++ innovative? Of course it is. It was one of the FIRST mainsteam
   language to provide ...

Shouldn't that be `first MAINSTREAM'?  --Tiggr

Re: What is wrong with OO ?

[Valerie Torres]

Jon S Anthony (jsa@alexandria) writes:

 > In article <5acjtn$5uj@news3.digex.net> ell@access1.digex.net (Ell) writes:
 > 
 > > Jon S Anthony (jsa@alexandria) wrote:
 > > : With respect to this "led/leads" claim: Such as?????  I can't think of
 > > : _any_ where this is true.  Though I can think of at least one
 > > : important _implementation_ aspect where this seems to be true.
 > > 
 > > Led (first or second) wrt the OO paradigm: Private data members, static
 > > resolution of overloaded functions, protected members, and multiple
 > > inheritance. Correct me if I'm wrong.  Remember this is wrt the early
 > > '80's.
 > 
 > Recheck your facts.  Led/lead means "first" to me and certainly
 > carries that connotation around with it even if you want to pull a
 > Humpty Dumpty.

It is very important getting the fact straight on a topic like this where
many seem keen on confusing the question "is C++ innovative and if so
compared to what and in which ways?" with "is C++ my favorite programming
language?"  or or even "is C++ perfect?" (my opinion: it is in some ways,
it is for many things, it is not).

The origins of C++ and the reasoning behind the various design decisions
are well documented:

	Bjarne Stroustrup: A History of C++: 1979-1991.
	Proc ACM History of Programming Languages conference (HOPL-2).
	ACM Sigplan Notices. Vol 28 No 3, pp 271-298. March 1993.
	Also in History of Programming languages
	(editors T.J.Begin and R.G.Gibson)
	Addison-Wesley, ISBN 1-201-89502-1. 1996.

	Bjarne Stroustrup: The Design and Evolution of C++.
	Addison-Wesley. 1994. ISBN 0-201-54330-3.

Note that the paper went through HOPL2's strict peer review process so
that the likelyhood that what is claimed to be a fact really is a fact
is much higher than in a net posting, in an unrefereed paper, or in a
paper from a commercial journal.

To the best of my abilities, the D&E book agrees with the HOPL paper on
issues covered in both but provides much more information and context.

It would have been nice if comparable information existed on the origins
of most major languages. That would have made it easier to understand
the different languages in context and see how ideas moved through the
programming communities. The HOPL papers is a good start, but they differ
too much in what kind of information they supply and tend not to be
sufficiently detailed for my taste. Also, HOPL covers only a few languages.


 > Private data member stuff was in various languages
 > before "C with classes" was even conceived (e.g., CLU, Ada83).  It
 > certainly existed in Eiffel before C++ was christened.  Protected
 > capability was certainly in Eiffel-1 which predates C++.  Same with
 > overload resolution (e.g., Algol68 had this as did Ada 83 compilers
 > that were in the field before CWC or C++).  MI was in Eiffel from the
 > start and that predates its appearance in C++ for sure.

First of all, we must be careful about dates. C with classes had "private"
in 1979 and protected around 1981. Data abstraction language (such as Ada83)
tends to have private only (you need inheritance for the private/protected
distinction to be meaningful) whereas OO language (such as Smalltalk) tends
to have protected only (whatever it may be called).

I don't know if any language having both before C++ and I don't know of
any earlier language expressing the dinction between implementation
inheritance (private base) and interface inheritance (public base,
subtyping). This pre-dates Liskov's formulation of her substitution
principle by about 8 years. It is of course possible that some language
had equivalent facilities at the time I designed those features for
CwithClasses/C++ or that someone somewhere wrote a paper discussing
the issues, but I didn't know of one so the protection facilities
of C++ are independently developed. In addition to private, protected,
and public, C++ offers the mechanism for selectively including names
from a base in the interface of a derived class. That too may have been
an innovation, but I don't really know.

C++ introduced constructors with the possibility of having several as
well as destructors (around 1980). All languages that support information
hiding provides some form of initialization (and certainly Simula did),
but I think the C++ mechanism provides a degree of flexibility that was
novel.

It is hard to really pin down what is innovative and what is not. For
example, I credited Algol68 with C++'s ability to have declarations
in conditions so that you can declare, initialize, and test in one
place. However, I was (later) told by one of the people involved in the
Algol68 design that although Algol68 logically ought to have had that feature,
they didn't think of that in the right way at the right time, so Algol68
doesn't allow declarations in conditions. In other words. I had deduced
that feature from the structure of Algol68 and failed to verify.

There are literally hundreds of details that one could examine to try
to determine their exact antecedence and give credit where credit is
due. I do some of that in the history paper and in D&E, but here I'd
like to point to a couple of bigger issues.

C++ was designed to allow design and programming techniques from Simula
to be used in the context of systems programming and other applications
where run-time and space were critical. On way of looking at the task
I set myself was to make data abstraction and object-oriented techniques
affordable and accepted in a community that mostly didn't know of them
and to the extent it did couldn't afford to apply those techniques
given the languages available.

To the extent that C++ succeeded at that, C++ was ahead of the wave,
``a leader'' borrowing the phrase from the original posting. It has
always been my opinion that making something comprehensible and affordable
is a worthwhile, innovative, and socially useful activity. I think producing
14 million volkswagen's or Ford Ts is at least as innovative as building
a few thousands Rolls Royces or a few hundred formula-1 cars - even though
the vast majority of the individual features first appear in the luxury
and speciality cars. I think that the majority of areas where C++ has
contributed have to do with economy and scale.

C++ was designed to be useful rather than to be innovative. Wherever
possible, I tried to follow a well-tested precedence. Thus, you can
find ideas from Algol68, ML, Ada, Clu, and even BCPL in C++. The main
ideas came from C and Simula, of course. Only where I couldn't find a
solution that fitted in C++'s general framework and met my criteria for
run-time efficiency, ease of implementation, ease of teaching, etc.
(see D&E Chapter 4), did I feel compelled to try to invent something. 

Much of C++'s success has to do with fitting into existing environments
and being compact and fast (yes, I know that these are not the aspects
of C++ that are currently emphasized in the MS Windows world). The speed
and compactness of code generated from C++ depends on a few fundamental
design decisions that I think were novel at the time:

	The ability to easily link to existing languages and have C++
	code used from other languages. (This is done through the linkage
	model and it is directly supported in the C++ grammar).

	The ability to use user-defined types and built-in types in the
	same way. In Simula - as in most data abstraction and OO language -
	every object of a user-defined type must be on the heap; this
	leads to overheads compared to stack-allocated objects. Similarly,
	C++ pointers work uniformly for both user-defined and built-in
	types.

	C++ offers objects of user-defined types with zero space overhead
	compared to C structs.

	C++ offers calls of member functions with zero time overhead
	compared to C functions.

	C++ offers inline member and non-member functions with zero
	overhead compared to macros.

	C++ offers its form of dynamic (run-time) resolution, virtual
	functions, with low and fixed overhead compared to ordinary
	function calls (20% to 100% dependent of implementation).

	C++ can be used without a significant run-time-support system
	and without significant libraries.

These features were introduced in the 1979 to 1983 timeframe (virtual
functions last!) and described in journals and at conferences from
about 1981.

This combination of feature was - and to some extent still is - unique
and important to many. This efficiency is a large part of the reason
why C++ was able to blaze a trail into areas where data abstraction
and object-oriented languages had made essentially no headway.

By demonstrating applicability and efficiency in new application areas
and in new communities C++ opened opportunities to other languages
with a different balance of tradeoffs. Both where C++ was successfully
used and where problems were found, it opened a door to alternatives.

People who didn't try to use OO and abstraction languages in the early
days (say 1967 to 1989) typically seriously underestimate the obstacles
to getting these languages and programming techniques into non-research
use. Most would also be shocked at the state of their favorite language
- as compared to its current state - in its early years. When comparing
languages in a historical context we must consider not only if a language
has a feature, but also when it had it, when it was published, when it
was implemented, and whether those implementations were good enough for
production use.


 > Next I suppose you will be trying to tell me it was the first to have
 > generics (templates) or namespaces or assignment attempt or RTTI or...

Please refrain from making conjectures about what someone in a debate
might claim. It adds no facts and can fuel flamewars.


 > C++ was and is a _follower_.  That is not necessarily a bad thing, but
 > it is anything _but_ innovative.
 > 
 > /Jon
 > -- 
 > Jon Anthony
 > Organon Motives, Inc.
 > Belmont, MA 02178
 > 617.484.3383
 > jsa@organon.com

Over the years, C++ has evolved within a framework that was reasonably
well understood early on. During this evolution, C++ has borrowed from
several languages (always with acknowledgements), but it has never been
in the position of slavishly following fashion or systematically borrowing
from a perceived competitor. C++ evolved within its own framework to
meet the needs of its users. I don't think that can be fairly labelled
"being a follower."

As far as I know, Simula was the first language with structured RTTI
(INSPECT and QUA). Some studies I made of Simula programs convinced me
that the less RTTI was used the better the structure of an average program
(INSPECT was commonly used in ways that precluded modularity). The C++
RTTI (primarily dynamic_cast) was introduced to handle the few cases
where it is necessary and in a form that hopefully minimizes problems.

Multiple inheritance is sometimes mentioned as innovative in C++.
It existed in different - more powerful, but slower - forms in
several Lisp dialects. I considered it for C++ from about 1981 and
introduced it into C++ in a more static and type-safe form in 1987
after a couple of years of experimentation (a brief mention of C++ MI
can be found in my "What is Object-oriented programming?" paper from
1985). The form of multiple inheritance in C++ may be innovative, the
fundamental idea is quite old. I now consider MI essential for a
language relying on static type checking. You can do without it of
course (just like you can do without single inheritance and without
classes), but the resulting code is contorted.

In the area of exceptions, C++ may have added something important:
C++ exceptions can be of arbitrary type and inheritance is taken
into account when catching an exception. This provides important
possibilities for grouping exceptions that I don't know precedence
for (though the need for grouping has been known for decades).

Templates are an interesting case. Naturally, many languages have provided
macros, generics, type inference, etc. for decades. However, templates
grew out of the needs of C++ programmers and seem to have a combination
of features that provide a surprising expressive power. The (relatively
new) C++ standard library of containers and algorithms seems to me to
provide a unique combination of generality and efficiency. Naturally,
the algorithms are not new (most can be found in Knuth), most languages
provide containers which roughly correspond to what the STL offers,
and many of the programming techniques used are borrowed (with thanks
and acknowledgement) from the functional programming community.

Should something like this be considered innovative? Would it be fair
to say that it leads hundreds of thousands of programmers into areas
of programming where they haven't been and would have been unlikely
to reach for many more years? I think so.

	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html

OO, C++, and something much better!

[John (Max) Skaller]

On 3 Jan 1997 14:56:25 -0500, comeau@panix.com (Greg Comeau) wrote:

>In article <32CCE4ED.6A21@online.no> emangset@online.no writes:
>>Robert C. Martin wrote:
>>> > C++ was and is a _follower_.  That is not necessarily a bad thing, but
>> > it is anything _but_ innovative.
>>> 
>>> WRT technology I agree with you.  But C++ *does* show innovation in a
>>> completely different vein.  C++ is one of the first of the industrial OO
>>> languages that was created for the engineer instead of for the paradigm.
>>> C++ was not created to be "pure" or "right" or "correct".  It was created
>>> to be *used*.  And in that regard it represents an innovation wrt industrial
>>> OO languages.

>>> Robert C. Martin    
>>
>>Sorry, but you are wrong. This is one of the many myths that surrounds
>>C++. No engineer I know would use any tool pertaining to his or her
>>profession that was as badly designed and implemented as C++. "Pure"
>>pragmatism is not an option with respect to language design, something
>>even Mr. Stroustrup himself acknowledges.
>
>I have not a clue what you are talking about.  Indeed, the beauty
>of C++ is that it is a hybrid and that it does not lock you into one
>particular thing.  Robert is indeed correct about its flexibility
>and avoidance of so-called political correctness.  Since when are
>pragmatics not important in design, decisions, engineering?

Here' my opinion. Stroustrup is to be applauded for making a powerful
"non-religious" language available to everyone. C++ is not a clean
language. It's quite messy and hard to use. But it is available.
No one knows how to design a quality system -- and _also_ make
is widely available. Bjarne decided "having better than what we have"
was better than some intangible thing no one had.

Is C++ innovative? Too right it is. 
It has the most powerful support for genericity available
in any widely used commercial language. (Sorry, Ada doesn't count,
Eiffel is borderline, current Java is a backward step. If there
is any competition it is from Smalltalk [which uses 
dynamism instead]).

Is it "pure OO"? No. Thank goodness. It has something
much better -- a vague and not very good appoximation
to a new methodology which provides vastly superior
reusability, categorical progamming. The evidence
is in Standard (Template) Library which is one of the 
most reusable commercial libraries available for any system.

There is hardly any inheritance at all in the C++ Standard Library.
It is not an "Object Oriented" library. 80 or so members of the C++
committee, however, thought it was the best choice for C++.

Is C++ innovative? Of course it is. It was one of the FIRST mainsteam
language to provide class based object orientation and go on 
to something much better before standardisation has been completed.

Modern C++ has made TWO paradigm shifts. Most people
haven't made the first (to OO) yet it is already being
replaced.

Re: OO, C++, and something much better!

[vlad]

skaller@maxtal.com.au (John (Max) Skaller) wrote:
>Here' my opinion. Stroustrup is to be applauded for making a powerful
>"non-religious" language available to everyone. C++ is not a clean
>language. It's quite messy and hard to use. But it is available.
>No one knows how to design a quality system -- and _also_ make
>is widely available. Bjarne decided "having better than what we have"
>was better than some intangible thing no one had.

>Is C++ innovative? Too right it is. 
>It has the most powerful support for genericity available
>in any widely used commercial language. (Sorry, Ada doesn't count,
>Eiffel is borderline, current Java is a backward step. If there
>is any competition it is from Smalltalk [which uses 
>dynamism instead]).

>Is it "pure OO"? No. Thank goodness. It has something
>much better -- a vague and not very good appoximation
>to a new methodology which provides vastly superior
>reusability, categorical progamming. The evidence
>is in Standard (Template) Library which is one of the 
>most reusable commercial libraries available for any system.

>There is hardly any inheritance at all in the C++ Standard Library.
>It is not an "Object Oriented" library. 80 or so members of the C++
>committee, however, thought it was the best choice for C++.

>Is C++ innovative? Of course it is. It was one of the FIRST mainsteam
>language to provide class based object orientation and go on 
>to something much better before standardisation has been completed.

>Modern C++ has made TWO paradigm shifts. Most people
>haven't made the first (to OO) yet it is already being
>replaced.

Funny, I wanted to write almost the same think. I want to express my support to
your ideas, so you will be not alone when religious OO fanatics will be spitting
on you.

   

 Vlastimil Adamovsky
 ** C++ and Smalltalk consultant **
 * http://www.stepweb.com *

Re: OO, C++, and something much better!

[Mike Anderson]

I have some questions/comments about this (my words are preceeded by
"MA":)

John (Max) Skaller wrote:
> Stroustrup is to be applauded for making a powerful
> "non-religious" language available to everyone.

MA: What's "non-religious"?

> C++ is not a clean language. It's quite messy and hard to use. But it is available.

MA: So what?  There are plenty of available languages like that.

> No one knows how to design a quality system -- and _also_ make
> is widely available. Bjarne decided "having better than what we have"
> was better than some intangible thing no one had.

MA:  I don't understand that and won't comment on it.

> Is C++ innovative? Too right it is.
> It has the most powerful support for genericity available
> in any widely used commercial language. (Sorry, Ada doesn't count,
> Eiffel is borderline, current Java is a backward step. If there
> is any competition it is from Smalltalk [which uses
> dynamism instead]).

MA:  Why doesn't Ada count; why is Eiffel borderline, and why is current
Java a backword step?

> Is it "pure OO"? No. Thank goodness. It has something
> much better -- a vague and not very good appoximation
> to a new methodology which provides vastly superior
> reusability, categorical progamming. The evidence
> is in Standard (Template) Library which is one of the
> most reusable commercial libraries available for any system.

MA:  The above is utter nonsense (well, someone's got to say it).  I
don't usually rant but the sentences
	'Is it "pure OO"? No. Thank goodness.'
pisses me off because I firmly believe I in pure OO.  (Hey, I've got
some religion, but don't tell anybody.)  As far as "a vague and not very
good appoximation to a new methodology which provides vastly superior
reusability" ...are you being sarcastic or what?

....Mike

Re: OO, C++, and something much better!

[Stanley Allen]

John (Max) Skaller wrote:

> Is C++ innovative? Too right it is.
> It has the most powerful support for genericity available
> in any widely used commercial language. (Sorry, Ada doesn't count,
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You loaded the question, and therefore your dismissal of
Ada is the act of knocking down a strawman.

Let me engage in some debuking here, and point out that Ada
*is* widely used, just not in the PC/GUI world.  Ada is also
very much a "commercial" language; in fact, many of the
companies using Ada today for commercial projects consider
it to be a success factor in their software efforts.

To hear that C++'s template mechanism is "innovative" and
"powerful" comes as a surprise.  Parts of the C++ template
mechanism look like a borrowing of Ada's "generic" facility
(Stroustrup attributes this to Alex Stepanov, who had done
a great deal of work with Ada generics before designing the
C++ Standard Template Library).  Unfortunately, the type
system in C++ is too weak to support anything as powerful
as Ada's generic facility.  The C++ "template argument"
(which corresponds to Ada's "generic formal parameter") for
a type can only be of the form "class T".  In Ada terms,
this would be like having all generic formals be
"type T is private".

In C++, there is no way to 1) specify the kinds of types that
may be used to make an instance of the template (for example,
to specify that the template may only be instantiated with
integer types), or 2) to assume a particular set of operations
will be available within the template for the type argument
(for example, to assume that integer operations will be
availible for a variable of type T).

These two issues are the heart and soul of Ada generics
(derived as they are from Ada's type system), and provide
a powerful tool for specifying complete "contracts" between
the generic developer and user.  The C++ mechanism boils
down in practice to a "macro-expansion" tool.

--
Stanley Allen
mailto:sallen@hso.link.com

Re: OO, C++, and something much better!

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <32D0CA27.44C2@ghgcorp.com> Stanley Allen <sallen@ghgcorp.com> writes:


   John (Max) Skaller wrote:

   > Is C++ innovative? Too right it is.
   > It has the most powerful support for genericity available
   > in any widely used commercial language. (Sorry, Ada doesn't count,
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   You loaded the question, and therefore your dismissal of
   Ada is the act of knocking down a strawman.

   Let me engage in some debuking here, and point out that Ada
   *is* widely used, just not in the PC/GUI world.  Ada is also
   very much a "commercial" language; in fact, many of the
   companies using Ada today for commercial projects consider
   it to be a success factor in their software efforts.

   To hear that C++'s template mechanism is "innovative" and
   "powerful" comes as a surprise.  Parts of the C++ template
   mechanism look like a borrowing of Ada's "generic" facility
   (Stroustrup attributes this to Alex Stepanov, who had done
   a great deal of work with Ada generics before designing the
   C++ Standard Template Library).  Unfortunately, the type
   system in C++ is too weak to support anything as powerful
   as Ada's generic facility.  The C++ "template argument"
   (which corresponds to Ada's "generic formal parameter") for
   a type can only be of the form "class T".  In Ada terms,
   this would be like having all generic formals be
   "type T is private".

<stuff deleted>


   --
   Stanley Allen
   mailto:sallen@hso.link.com


I would tend to agree. Another point is that C++ templates tend to be
implemented differently in every compiler, so a program which uses
templates heavily is often less portable.

However, if I remember correctly, Alex Stepanov had earlier tried to
implement a library like the C++ STL in Ada, but was incapable of
doing it. This would indicate that the C++ template mechanism is more
flexible than the Ada generics.
Any comments?

Re: What is wrong with OO ?

[Bart Samwel]

Bjarne Stroustrup wrote:

> Only where I couldn't find a solution that fitted in C++'s general
> framework and met my criteria for run-time efficiency, ease of
> implementation, ease of teaching, etc. (see D&E Chapter 4), did I
> feel compelled to try to invent something.

When I read this, a lot of questions pop up in my head. I'll ask only
one: You've only included features that didn't compromise ease of
teaching (at least, that's my interpretation of what you wrote). Why is
it then, that C++ contains so many hidden 'features' (or rather,
non-explicit rules) that confuse people, at least at my university?

As far as I'm concerned, C++ is not a language for teaching. It has too
many of these implicit rules to be logical, and the fact that it
doesn't have garbage collection and does have pointers really makes it
error-prone; especially for beginning programmers, this is not a good
thing. They should be writing WHAT should be done, and ALL that should
be done; they shouldn't be bothered with the 'how' part of programming,
like (with alternatives): memory management (garbage collection),
pointers (references), virtual functions (can be detected by the
compiler). They should not be bothered with implicit rules (like the
multiple inheritance rules, for instance) that they have to know of,
before using multiple inheritance.

C++ is an excellent language as an extension to C, but C is altogether
obsolete and much too low-level, except for systems programming, and
other languages are now available for writing high-level software.
Many people make the (IMO huge) mistake of using C++ for high-level
software projects, leading to buggy results and, often, lots of core
dumps. Programmers are not perfect, and C++ expects them to be so by
providing too many ways of making mistakes.

Languages like Eiffel (my personal favorite) are much more suitable for
high-level projects; Eiffel, for instance, does not burden the
programmer more than needed, and has a clean, clear syntax that can
even be immediately understood by people that don't know the language.

> Much of C++'s success has to do with fitting into existing
> environments and being compact and fast (yes, I know that these are
> not the aspects of C++ that are currently emphasized in the
> MS Windows world). The speed and compactness of code generated from
> C++ depends on a few fundamental design decisions that I think were
> novel at the time:

Speed and compactness is certainly a goal that C++ has achieved. But it
did not achieve one major goal: ease of use.

>         C++ offers inline member and non-member functions with zero
>         overhead compared to macros.

You shouldn't bother programmers with inlining. Inlining can be done
automatically by the compiler.

>         C++ offers its form of dynamic (run-time) resolution, virtual
>         functions, with low and fixed overhead compared to ordinary
>         function calls (20% to 100% dependent of implementation).

Virtual functions must be explicitly specified. This can be done by the
compiler. And, virtual functions must be specified in the ancestor
class; this means that when a class designer forgot to put that in
(and this happens often), I can't redefine the function correctly.

> Over the years, C++ has evolved within a framework that was reasonably
> well understood early on.

Well understood, yes. But the framework is now obsolete, and it has
some serious design flaws that also bother C++ users.


   Bart Samwel  (bsamwel@wi.leidenuniv.nl)

Re: OO, C++, and something much better!

[Chris Brand]

John (Max) Skaller wrote:
> 
[cut]
> 
> Is C++ innovative? Too right it is.
> It has the most powerful support for genericity available
> in any widely used commercial language. (Sorry, Ada doesn't count,
> Eiffel is borderline, current Java is a backward step. If there
> is any competition it is from Smalltalk [which uses
> dynamism instead]).
> 
[cut]

Great argument.

To paraphrase:
"Is C++ innovative? Yes. Its got something other languages had first but
it's more widely used."

Perhaps I've got the wrong definition of innovative...

-- 
Chris
Stating my own opinions, not those of my company.

Re: OO, C++, and something much better!

[Michael F Brenner]

Yes, there is some added flexibility in C++ templates over Ada generics,
and vice versa too. The added flexibility in C++ templates comes from the
ability to expand them at compile time without losing optimizations, unlike
Ada generics whose paradigm is to expand at run-time and remove staticness
from expressions. The added flexibility in Ada templates comes from the
added flexibility in Ada packages, which can have BOTH types and functions.
An ideal generic would have all of the Ada features plus the following:
(a) anything that was static in the package while you were testing it, that
is, before you made it generic, remains static after you genericized the
package; (b) there is a standard pragma that tells the compiler to 
expand the generic at compile time, (c) there is a formal generic
parameter type that works on EITHER modular or twos complement types,
and (d) generates the kind of code for each instantiation that keeps
track of the line numbers in generic source code, so unhandled exceptions
would generate a useful traceback of source code lines through generic
packages.

Re: OO, C++, and something much better!

[Tucker Taft]

Michael F Brenner (mfb@mbunix.mitre.org) wrote:

: Yes, there is some added flexibility in C++ templates over Ada generics,
: and vice versa too. The added flexibility in C++ templates comes from the
: ability to expand them at compile time without losing optimizations, unlike
: Ada generics whose paradigm is to expand at run-time and remove staticness
: from expressions. 

It is true that Ada considers some expressions inside a generic as
non-static, but that has no necessary effect on optimization.
Many non-static expressions are computed at compile-time.  There
are certain places where the language requires static expressions,
such as an expression in a case alternative, but compilers can and do
still evaluate expressions that are not "officially" static at
compile-time.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: What is wrong with OO ?

[Jon S Anthony]

In article <fxtu3oysbzp.fsf@isolde.mti.sgi.com> Matt Austern <austern@isolde.mti.sgi.com> writes:

> jsa@alexandria (Jon S Anthony) writes:
> 
> > Oh, I don't know.  I think C++ was created simply because BS was
> > saddled with C (at ATT) and wanted _something_ that had a least _some_
> > abstraction capabilities in it.  Voila.  C++.  Whether it is any more
> > "usable" than several other options is highly open to question.  And
> > in fact, in general I would say the answer is "no".
> 
> It's not necessary to speculate on why Bjarne Stroustrup made the
> design decisions that he did: he discusses them, in a fair amount
> of detail, in _The Design and Evolution of C++_.

He also gave various descriptions of this process while it was
happening cira 87-89 and I happened to attend some of these.


> he was trying to create a language that, like C, made it possible to
> write low-level programs, but that also, like Simula, included
> high-level abstraction facilities.  

Exactly.  This came from his direct experience of having to recode a
Simula program for his thesis into BCPL.  The resulting nightmare was
not something he wished to have to go through again.  When getting to
ATT and seeing that it was C or nothing, he decided to "fix it" before
suffering the same experience.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Jon S Anthony]

In article <E3I8GL.AuH@research.att.com> bs@research.att.com (Valerie Torres) writes:

> Jon S Anthony (jsa@alexandria) writes:
>  > Private data member stuff was in various languages
>  > before "C with classes" was even conceived (e.g., CLU, Ada83).  It
>  > certainly existed in Eiffel before C++ was christened.  Protected
>  > capability was certainly in Eiffel-1 which predates C++.  Same with
>  > overload resolution (e.g., Algol68 had this as did Ada 83 compilers
>  > that were in the field before CWC or C++).  MI was in Eiffel from the
>  > start and that predates its appearance in C++ for sure.

> First of all, we must be careful about dates. C with classes had "private"
> in 1979 and protected around 1981. Data abstraction language (such as Ada83)
> tends to have private only (you need inheritance for the private/protected
> distinction to be meaningful) whereas OO language (such as Smalltalk) tends
> to have protected only (whatever it may be called).

Fair enough and I certainly can basically agree with this.  It is also
no big deal IMO if the features are _not_ "innovative" or new.  If
they are good and correct and well integrated - who cares (well some
do, but from many points of view, it just doesn't matter).  For
example, private stuff is basically captured in M2 by opaque types,
which according to Wirth was around '77-'78.  As you point out,
Smalltalk had the equivalent of protected and that was early '70s.
Shrug...


> I don't know if any language having both before C++ and I don't know of
> any earlier language expressing the dinction between implementation
> inheritance (private base) and interface inheritance (public base,
> subtyping).

You talking C++ or "C with Classes"?


> This pre-dates Liskov's formulation of her substitution
> principle by about 8 years. It is of course possible that some language
> had equivalent facilities at the time I designed those features for
> CwithClasses/C++ or that someone somewhere wrote a paper discussing

Well, what time frame are you really refering to here?  The
79-early-8x stuff of CwithClasses or the latter 80's C++?


[Various other stuff snipped on co/independent discovery etc.]

Well, sure, all this sounds perfectly sensible and believable.


> There are literally hundreds of details that one could examine to try
> to determine their exact antecedence and give credit where credit is
> due.

Absolutely.


> C++ was designed to allow design and programming techniques from Simula
> to be used in the context of systems programming and other applications
> where run-time and space were critical. On way of looking at the task
> I set myself was to make data abstraction and object-oriented techniques
> affordable and accepted in a community that mostly didn't know of them
> and to the extent it did couldn't afford to apply those techniques
> given the languages available.
> 
> To the extent that C++ succeeded at that, C++ was ahead of the wave,

Ah, this is the "_implementation_ innovation" aspect that I originally
refered to as something that I would acknowledge C++ "leading" in the
"OO world"...


> of C++ that are currently emphasized in the MS Windows world). The speed
> and compactness of code generated from C++ depends on a few fundamental
> design decisions that I think were novel at the time:

Some of these are novel (in a very narrow context - existing C) but
most are not.


> 	The ability to use user-defined types and built-in types in the
> 	same way. In Simula - as in most data abstraction and OO language -
> 	every object of a user-defined type must be on the heap; this
> 	leads to overheads compared to stack-allocated objects. Similarly,
> 	C++ pointers work uniformly for both user-defined and built-in
> 	types.

This certainly exists in Ada83 (sans virtual stuff).


> 	C++ offers objects of user-defined types with zero space overhead
> 	compared to C structs.

Same here.


> 	C++ offers calls of member functions with zero time overhead
> 	compared to C functions.

Same here.


> 	C++ offers inline member and non-member functions with zero
> 	overhead compared to macros.

Same here.


> 	C++ offers its form of dynamic (run-time) resolution, virtual
> 	functions, with low and fixed overhead compared to ordinary
> 	function calls (20% to 100% dependent of implementation).

This is a very good example - quite possibly the most important one.


> 	C++ can be used without a significant run-time-support system
            ^^^
> 	and without significant libraries.

Most statically compiled languages could and can be so used - it
"just" requires intelligent binders (not necessarily linkers...)


> This combination of feature was - and to some extent still is - unique
> and important to many.

This is not currently believable.  However, in the past, the efficient
runtime dispatch ability was at one point clearly a plus.


> This efficiency is a large part of the reason why C++ was able to
> blaze a trail into areas where data abstraction and object-oriented
> languages had made essentially no headway.

This is not particularly clear or believable.  It probably did have
something to do with it, but how much is not obvious.  The C heritage
(and its _presumed_ efficiency by association) is still the single
most likely reason for the demonstrated popularity.  Of course, in
those early days, there was no reason to believe that this would be a
real factor.  Sort of like having the insight/luck to buy into MS
before they were anything.


> By demonstrating applicability and efficiency in new application areas
> and in new communities C++ opened opportunities to other languages
> with a different balance of tradeoffs. Both where C++ was successfully
> used and where problems were found, it opened a door to alternatives.

Actually, I think a closer reading would be that people started out
thinking, "hey, we C folk can get on this <hated> OO/abstraction
bandwagon with our own C++!  It's basically just a better C which you
can sometimes use for OO stuff if you want.  Heck, you can even
compile most of your old C stuff with a C++ compiler."  What happened
next was that some of the more savvy realized that there really _was_
some good in this sort of approach after all - irrespective of any
language issue.  These folks no longer are wedded to the C++ language
and in fact many have moved on to, shall we say, more pleasent just as
capable/efficient alternatives.


> from a perceived competitor. C++ evolved within its own framework to
> meet the needs of its users. I don't think that can be fairly labelled
> "being a follower."

OK, but don't think it can be fairly labelled a "leader" either.  I
suppose we can say that it just "is"...


> language relying on static type checking. You can do without it of
> course (just like you can do without single inheritance and without
> classes), but the resulting code is contorted.

I don't want to go into this, suffice to say we can simply agree to
disagree.


> In the area of exceptions, C++ may have added something important:
> C++ exceptions can be of arbitrary type and inheritance is taken
> into account when catching an exception.

I see this as an approach or refinement to an already known and
(reasonably) understood facility.  I suppose that means I have a
somewhat more stringent notion of "innovation".


> Templates are an interesting case. Naturally, many languages have provided

Same here.  Note that in both of these cases you don't get something
for nothing.  Both exceptions and templates are IMO rather more
convoluted in C++ than the (more or less) equivalents in alternatives.

> Should something like this be considered innovative? Would it be fair

Depends on your point of view.  Some would probably say "yes" - for
example, you - I would tend to say "no".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Stanley Allen]

Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:

> However, if I remember correctly, Alex Stepanov had earlier tried to
> implement a library like the C++ STL in Ada, but was incapable of
> doing it. This would indicate that the C++ template mechanism is more
> flexible than the Ada generics.
> Any comments?

My history may be a bit rusty, but I believe that
Alex Stepanov's work in Ada was successful, just not
widely used.  He had some published material about
the Ada work, which I have not seen directly.  It
is listed in the references of his on-line paper
"Algorithm-Oriented Generic Libraries":

    http://www.cs.rpi.edu/~kennyz/www/ADS/Algor/Algor.html

Stepanov's work was done using Ada83; it would
certainly be different if it were done today with
Ada95.

--
Stanley Allen
mailto:sallen@ghgcorp.com

Re: OO, C++, and something much better!

[Robert Dewar]

Tucker said

"It is true that Ada considers some expressions inside a generic as
non-static, but that has no necessary effect on optimization.
Many non-static expressions are computed at compile-time.  There
are certain places where the language requires static expressions,
such as an expression in a case alternative, but compilers can and do
still evaluate expressions that are not "officially" static at
compile-time."


One of the mistakes made in some Ada 83 compilers was to assume that the
concepts of "evaluable at compile time" and "static expression" could be
equated, but this was not true in Ada 83 and is not true in Ada 95. The
set of static expressions is a subset of the expressions that can be
evaluated at compile time, and compilers should treat them differently.

To see how GNAT handles this, look at the unit Sem_Eval, and note that
the section on "Compile-Time Known Values" addresses this issue.

Ada Generics (was Re: OO, C++, and something much better!)

[Bob Gilbert]

In article <5arhb0$d4e@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:
> Yes, there is some added flexibility in C++ templates over Ada generics,
> and vice versa too. The added flexibility in C++ templates comes from the
> ability to expand them at compile time without losing optimizations, unlike
> Ada generics whose paradigm is to expand at run-time and remove staticness
> from expressions. 

Most of the Ada comilers I've used do expand the generic instantiation at
compile time.  Could somebody offer up an example of where this would not
be possible?

-Bob

Re: OO, C++, and something much better!

[Robert Dewar]

Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:

> However, if I remember correctly, Alex Stepanov had earlier tried to
> implement a library like the C++ STL in Ada, but was incapable of
> doing it. This would indicate that the C++ template mechanism is more
> flexible than the Ada generics.
> Any comments?

Actually, when I talked to Alex, he indicated that there were critical
features in Ada 95 that were missing in C and C++ for this kind of
work. In particular, he noted that C lacks a general address comparison
operation, useful for hashing data structures, whereas Ada does have such
an operation (in System.Storage_Elements on type Integer_Address). It is
a bit ironic to identify this particular feature as crucial (since most
people mistakenly think that C has such a feature and Ada doesn't!)

He did also discuss problems in Ada 95, most notably the fact that generics
are less flexible than templates (that is to be expected, the flexibility
of templates comes of course at the expense of compile time checkability),
and also the lack of automatic instantiation in Ada.

Automatic instantiation is of course a dangerous tool, but in the hands
of those writing libraries of this type (Alex said to me that he thought
there were only about six people who should be writing such libraries and
he did not know who the other five were :-) :-) dangerous tools can be
put to good use, with the danger being insulated from the eventual client
at least in some cases.

There is a team at Rensaleer which has been working on duplicating STL
in Ada 95. The preliminary results looked very encouraging, I do not
know the status of this work.

Re: OO, C++, and something much better!

[Jay Martin]

ohk@ultra.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB) writes:

>However, if I remember correctly, Alex Stepanov had earlier tried to
>implement a library like the C++ STL in Ada, but was incapable of
>doing it. This would indicate that the C++ template mechanism is more
>flexible than the Ada generics.
>Any comments?

I think this is with Ada83 (I actually have his unimpressive book "The
Ada(83) Generic Library").  It took literally minutes to smash into
braindead limitations of Ada83 which made elegant data structure
libraries infeasable.  Since the standard was locked, it took 12 years
before any of these problems were corrected.  To me this proved the
need for timely evolution of computer languages.

Jay

Re: Ada Generics (was Re: OO, C++, and something much better!)

[Robert Dewar]

Bob Gilbert asks

"Most of the Ada comilers I've used do expand the generic instantiation at
compile time.  Could somebody offer up an example of where this would not
be possible?"

No one can give you an example, because there are none. GNAT demonstrates
that it is possible to do all generic instantiation at compile time.

Note however that in a classical library model, as opposed to the source
model of GNAT, there are cases of circular instantiations which may require
some trickery to do at compile time, so one can imagine compilers with
restrictions on what can be done at compile time (by circular instantiations
here I do not mean truly circuluar, which is of course illegal), but just
mutually recursive references, e.g. two packages, each of which instantiates
from the other.

Re: OO, C++, and something much better!

[Bertrand Meyer]

In my opinion neither Ada (83 or 95) nor C++ has the combination
of mechanisms making it possible to have the full power of
generics in an object-oriented language, as present in Eiffel:

	- Unconstrained genericity, to declare a class
	  as e.g. LIST [G], where G represents an arbitrary
	  type, so that you can then use LIST [SOME_TYPE] regardless
	  of what SOME_TYPE is.

	- Constrained genericity, as in e.g. 
	  SORTED_LIST [G -> COMPARABLE], to require that
	  some operations be applicable to all actual
	  generic parameters. The rule is that
	  SORTED_LIST [SOME_TYPE] is permitted if and only
	  if SOME_TYPE inherits, directly or indirectly from
	  COMPARABLE. The -> symbol is evocative of the symbol
	  for inheritance used in class diagrams in e.g. B.O.N.
	  Within the class SORTED_LIST, any operation (feature, method)
	  of class COMPARABLE, such as infix "<" etc., is then applicable
	  to entities of type G.

	- A completely consistent type structure, in which 
	  even basic types such as INTEGER are classes,
	  present in the general inheritance structure.
	  (In C++ or Java, for example, the basic types
	  are completely separate from the class and inheritance
	  structure.)

	- True static typing (with no cast a la C++).

So in the constrained genericity case SORTED_LIST [INTEGER]
will be permitted, since COMPARABLE is indeed an existing class,
describing order relations and part of the Eiffel Library
Kernel Standard, and INTEGER (also part of ELKS) does inherit
from COMPARABLE.

SORTED_LIST [TENNIS_PLAYER] will also be
valid, assuming the user-defined class TENNIS_PLAYER inherits
from COMPARABLE. But something like SORTED_LIST [COMPLEX]
will be rejected by the compiler, assuming COMPLEX is not
a descendant of COMPARABLE.

In the unconstrained case, a declaration such as LIST [G]
is understood as an abbreviation for LIST [G -> ANY], where
ANY is the ELKS class inherited by all classes. This makes
it possible to apply objects of type G a wide range of operations
applicable to all objects: equality comparison (redefinable
in any class as long as it satisfies the original assertions),
copying, cloning, even (in the latest version of ELKS) hash
coding.

Without going into the details, I should add that Eiffel's design
for generics avoids the grave problems that one reads about in
connection with C++ templates: the need in C++ to  generate code
separately
for each generic derivation (each new actual generic parameter), with
its
rather bad effect on compilation time ("template instantiation problem")
and, as a result, the advice regularly given in the C++ literature
to avoid using templates too much. In Eiffel, you can generate
code just once (with some specific optimizations for basic types),
without having to pay any performance overhead either at compile
time or at run time. So you can use genericity as much as you like.
The ISE Eiffel libraries, for example, are generic throughout.

 
In comparison with Eiffel, not even mentioning Java with its total lack
of genericity, the other attempts at generic mechanisms that I have seen
in an O-O context look to me rather half-hearted.

I think Eiffel's consistent and complete treatment of genericity and
inheritance is one of the reasons why some of the biggest successful
industrial O-O projects have been produced in Eiffel. When the goal is
not just to play around, but to build large, mission-critical systems,
one needs the right combination of mechanisms, not just a partial
attempt.

For details about the Eiffel mechanism see the Eiffel language tutorial
at
http://www.eiffel.com.


-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com (WITH FRAMES)
	or http://www.eiffel.com/noframes.html

Re: OO, C++, and something much better!

[Andrew Koenig]

In article <OHK.97Jan6132731@ultra.tfdt-o.nta.no> ohk@ultra.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB) writes:

> However, if I remember correctly, Alex Stepanov had earlier tried to
> implement a library like the C++ STL in Ada, but was incapable of
> doing it. This would indicate that the C++ template mechanism is more
> flexible than the Ada generics.

What Alex told me about that effort was that he was unable to find
a single Ada compiler that implemented the standard accurately enough
to enable him to do what he wanted to do with his library.
-- 
				--Andrew Koenig
				  ark@research.att.com

Re: OO, C++, and something much better!

[Ken Garlington]

Jay Martin wrote:
> 
> Since the standard was locked, it took 12 years
> before any of these problems were corrected.

Actually, back with Ada was a MIL-STD, there was a requirement to review
it
every _five_ years for updates. As I recall, no one wanted to do an
update
on the first cycle, in order to give implementations a chance to mature.
The
second cycle ended with Ada 95.

What rule (if any) is there for ISO standard review cycles?

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Ken Garlington]

Bertrand Meyer wrote:
> 
> In my opinion neither Ada (83 or 95) nor C++ has the combination
> of mechanisms making it possible to have the full power of
> generics in an object-oriented language, as present in Eiffel:
> 
>         - Unconstrained genericity, to declare a class
>           as e.g. LIST [G], where G represents an arbitrary
>           type, so that you can then use LIST [SOME_TYPE] regardless
>           of what SOME_TYPE is.

I've seen Mr. Meyer mention this in various articles, but I've never
understood it.
What's the distinction between an Ada generic with a limited private
type as a
parameter, and an "unconstrained" generic?

>         - Constrained genericity, as in e.g.
>           SORTED_LIST [G -> COMPARABLE], to require that
>           some operations be applicable to all actual
>           generic parameters. The rule is that
>           SORTED_LIST [SOME_TYPE] is permitted if and only
>           if SOME_TYPE inherits, directly or indirectly from
>           COMPARABLE. The -> symbol is evocative of the symbol
>           for inheritance used in class diagrams in e.g. B.O.N.
>           Within the class SORTED_LIST, any operation (feature, method)
>           of class COMPARABLE, such as infix "<" etc., is then applicable
>           to entities of type G.

Isn't this also available in Ada? In particular, can't you require the
user to
provide the needed operations in the absence of visible defaults?

>         - A completely consistent type structure, in which
>           even basic types such as INTEGER are classes,
>           present in the general inheritance structure.
>           (In C++ or Java, for example, the basic types
>           are completely separate from the class and inheritance
>           structure.)

I also thought this was true of Ada. Isn't Integer actually considered
part of
the general inheritance structure of the root_integer class? [LRM
3.5.4:14?]

>         - True static typing (with no cast a la C++).


> 
> So in the constrained genericity case SORTED_LIST [INTEGER]
> will be permitted, since COMPARABLE is indeed an existing class,
> describing order relations and part of the Eiffel Library
> Kernel Standard, and INTEGER (also part of ELKS) does inherit
> from COMPARABLE.
> 
> SORTED_LIST [TENNIS_PLAYER] will also be
> valid, assuming the user-defined class TENNIS_PLAYER inherits
> from COMPARABLE. But something like SORTED_LIST [COMPLEX]
> will be rejected by the compiler, assuming COMPLEX is not
> a descendant of COMPARABLE.
> 
> In the unconstrained case, a declaration such as LIST [G]
> is understood as an abbreviation for LIST [G -> ANY], where
> ANY is the ELKS class inherited by all classes. This makes
> it possible to apply objects of type G a wide range of operations
> applicable to all objects: equality comparison (redefinable
> in any class as long as it satisfies the original assertions),
> copying, cloning, even (in the latest version of ELKS) hash
> coding.
> 
> Without going into the details, I should add that Eiffel's design
> for generics avoids the grave problems that one reads about in
> connection with C++ templates: the need in C++ to  generate code
> separately
> for each generic derivation (each new actual generic parameter), with
> its
> rather bad effect on compilation time ("template instantiation problem")
> and, as a result, the advice regularly given in the C++ literature
> to avoid using templates too much. In Eiffel, you can generate
> code just once (with some specific optimizations for basic types),
> without having to pay any performance overhead either at compile
> time or at run time. So you can use genericity as much as you like.
> The ISE Eiffel libraries, for example, are generic throughout.
> 
> 
> In comparison with Eiffel, not even mentioning Java with its total lack
> of genericity, the other attempts at generic mechanisms that I have seen
> in an O-O context look to me rather half-hearted.
> 
> I think Eiffel's consistent and complete treatment of genericity and
> inheritance is one of the reasons why some of the biggest successful
> industrial O-O projects have been produced in Eiffel. When the goal is
> not just to play around, but to build large, mission-critical systems,
> one needs the right combination of mechanisms, not just a partial
> attempt.
> 
> For details about the Eiffel mechanism see the Eiffel language tutorial
> at
> http://www.eiffel.com.
> 
> --
> Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
> 805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
> ftp://ftp.eiffel.com
> Visit our Web page: http://www.eiffel.com (WITH FRAMES)
>         or http://www.eiffel.com/noframes.html

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[David Emery]

>> 	- A completely consistent type structure, in which 
>> 	  even basic types such as INTEGER are classes,
>> 	  present in the general inheritance structure.
>> 	  (In C++ or Java, for example, the basic types
>> 	  are completely separate from the class and inheritance
>> 	  structure.)
>
>OK, here you have me.  But, Eiffel hedges a bit here as well with its
>"expanded types".

I think that there is not a clear consensus on this as A Good Thing.
From a practical perspective, there seems to be a significant price to
pay for 'full generality' (e.g. integers are classes just like
user-defined record types.)  Java, for instance, has primitive integer
types, and my understanding that the reason for this is performance,
pure and simple.  Making 'int' a class would result in unacceptable
performance, both compile-time and runtime, for simple things like
"a[i++] := b + c;" (for int a, b, c).

Language engineering design is a series of compromises between expressiveness
and efficiency (among other compromises).  Pure 'class-hood' for all
types in the system is one area where there are serious tradeoffs between
expressiveness and efficiency.

				dave
-- 
<.sig is away on vacation>

Re: OO, C++, and something much better!

[Mark A Biggar]

In article <JSA.97Jan8123334@alexandria> jsa@alexandria (Jon S Anthony) writes:
>In article <32D2E6C8.13728473@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:
>> So in the constrained genericity case SORTED_LIST [INTEGER]
>> will be permitted, since COMPARABLE is indeed an existing class,
>
>Good point.  Lost a Minbari Cruiser on this one...

Not really as you can always say:

generic
	type G is private;
	with function "<"(L,R: G) return Boolean is <>;
package SORTED_LIST is ...

This requires that either the Type G have a "<" defined or that you provide 
one at the time of instanitation.  Of course there is nothing that requires 
that the provided function realy be a less-than function (which is usefull
as providing a ">" instead reverses the order of the list) but Eiffel has the
same problem and there is no guarentee that a class derived from COMPARABLE
hasn't redefined "<" to do something else either.

--
Mark Biggar
mab@wdl.lmco.com

Re: What is wrong with OO ?

[Richard A. O'Keefe]

ell@access1.digex.net (Ell) writes:

>Led (first or second) wrt the OO paradigm: Private data members, static
>resolution of overloaded functions, protected members, and multiple
>inheritance.

Aren't the keywords 'private' and 'protected' copied from Simula?
(The old "Common Base Language" definition didn't have them, but
they were in Simula before they were in C++.)  As for multiple
inheritance, there was a multiple-inheritance version of Smalltalk
before C++ got it.

As for static resolution of overloaded *functions*, Algol 68 had _that_
long before C was dreamed of, let alone C++.

C++ deserves the credit for getting some of these things into the hands
of the programmer on the street.  

-- 
My tertiary education cost a quarter of a million in lost income
(assuming close-to-minimum wage); why make students pay even more?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Robert I. Eachus]

 
      Bertrand Meyer said:

   > In my opinion neither Ada (83 or 95) nor C++ has the combination
   > of mechanisms making it possible to have the full power of
   > generics in an object-oriented language, as present in Eiffel...

     And then listed four properties, all of which are in Ada 95!

     There are differences between Ada 95 and Eiffel, for example in
the way multiple inheritance is handled.  The biggest difference
though is that the type system is normally viewed as a forest rather
than a single tree.  These differences do affect the way in which
these things are usually implemented, but they do lead to major
differences in the way the features are normally used.  (To avoid
flames from both sides: see "normally viewed" and "usually
implemented" above.  I'm talking about how generics tend to be used,
not about limitations--in either language.)

     For example, in Ada you would not require a class to be derived
from COMPARABLE if you wanted to insure that comparisons work, you
would more likely require the comparison operations directly.  (See
below.) This is usually the "right" way to do it in Ada for technical
reasons, but the real reason is that the Ada mindset sees classes as
not strictly hierarchical but as a set of non-exclusive groupings.
i.e. Just as it is sensible to ask if type A is in class B, it is also
sensible in Ada to ask or specify if a type has discriminants or if a
subtype is definite.

    A good working definition of a class in Ada is the set of all
types that match a particular generic formal part:

           type Foo is range <>; -- integer class

           type Fubar(<>) is limited private; -- The class of all classes.

           type Bar is new Foob with private; -- Foob'CLASS (for
           -- non-Ada programmers, Foob, a tagged type, or any type
           -- derived directly or indirectly from it.)
   
           -- for completeness:
           type Barf is new Foobar; -- same as above, but Barf must
           -- be definite.
       
           type Element is private;
           with function "<" (L,R: Element) return Boolean is <>;
           -- Any ordered type with assignment and equality.

     And so on...
--

					Robert I. Eachus

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

Re: OO, C++, and something much better!

[Kohler Markus]

>>>>> "Bertrand" == Bertrand Meyer <bertrand@eiffel.com> writes:

    Bertrand> In my opinion neither Ada (83 or 95) nor C++ has the
    Bertrand> combination of mechanisms making it possible to have the
    Bertrand> full power of generics in an object-oriented language,
    Bertrand> as present in Eiffel:

In my opinion and not only in my opinion Eiffel has NOT the full power of generics. 

Let me cite David L. Shang :

     "Unlike Eiffel, Transframe does not require runtime type checks to eliminate
     holes (a hole is defined as a leak in the specification through which an argument
     can pass the check but the type of the argument is actually wrong) in the
     supertype's interface. Instead it requires a runtime type check merely for
     flexibility in heterogeneous programming, which is exactly the case forbidden by
     some other approaches. 

     Class parameters can be used to express type dependencies. And thanks to the
     type dependency check via type assurance, a compiled Transframe program will
     never report a runtime type error. 

     Eiffel allows fields/methods in subclasses to be redefined by subtypes, which is a
     more flexible type system than that of C++. Eiffel allows covariant changes to
     types of instance variables and, as a result, it is not statically type-safe. A
     system-level type check is required but only works with a closed-world
     assumption. It seems that Eiffel's newly proposed type checking rule is too
     conservative to include a useful usage of covariance. "

See http://www.sigs.com/publications/docs/oc/9608/oc9608.c.shang.html
for  more information. 

    Bertrand> 	- Unconstrained genericity, to declare a class as
    Bertrand> e.g. LIST [G], where G represents an arbitrary type, so
    Bertrand> that you can then use LIST [SOME_TYPE] regardless of
    Bertrand> what SOME_TYPE is.

    Bertrand> 	- Constrained genericity, as in e.g.  SORTED_LIST [G
    Bertrand> -> COMPARABLE], to require that some operations be
    Bertrand> applicable to all actual generic parameters. The rule is
    Bertrand> that SORTED_LIST [SOME_TYPE] is permitted if and only if
    Bertrand> SOME_TYPE inherits, directly or indirectly from
    Bertrand> COMPARABLE. The -> symbol is evocative of the symbol for
    Bertrand> inheritance used in class diagrams in e.g. B.O.N.
    Bertrand> Within the class SORTED_LIST, any operation (feature,
    Bertrand> method) of class COMPARABLE, such as infix "<" etc., is
    Bertrand> then applicable to entities of type G.

    Bertrand> 	- A completely consistent type structure, in which
    Bertrand> even basic types such as INTEGER are classes, present in
    Bertrand> the general inheritance structure.  (In C++ or Java, for
    Bertrand> example, the basic types are completely separate from
    Bertrand> the class and inheritance structure.)

    Bertrand> 	- True static typing (with no cast a la C++).

    Bertrand> So in the constrained genericity case SORTED_LIST
    Bertrand> [INTEGER] will be permitted, since COMPARABLE is indeed
    Bertrand> an existing class, describing order relations and part
    Bertrand> of the Eiffel Library Kernel Standard, and INTEGER (also
    Bertrand> part of ELKS) does inherit from COMPARABLE.

    Bertrand> SORTED_LIST [TENNIS_PLAYER] will also be valid, assuming
    Bertrand> the user-defined class TENNIS_PLAYER inherits from
    Bertrand> COMPARABLE. But something like SORTED_LIST [COMPLEX]
    Bertrand> will be rejected by the compiler, assuming COMPLEX is
    Bertrand> not a descendant of COMPARABLE.

    Bertrand> In the unconstrained case, a declaration such as LIST
    Bertrand> [G] is understood as an abbreviation for LIST [G ->
    Bertrand> ANY], where ANY is the ELKS class inherited by all
    Bertrand> classes. This makes it possible to apply objects of type
    Bertrand> G a wide range of operations applicable to all objects:
    Bertrand> equality comparison (redefinable in any class as long as
    Bertrand> it satisfies the original assertions), copying, cloning,
    Bertrand> even (in the latest version of ELKS) hash coding.

    Bertrand> Without going into the details, I should add that
    Bertrand> Eiffel's design for generics avoids the grave problems
    Bertrand> that one reads about in connection with C++ templates:

C++ templates are far from beeing perfect, that's true.  

    Bertrand> the need in C++ to generate code separately for each
    Bertrand> generic derivation (each new actual generic parameter),
    Bertrand> with its rather bad effect on compilation time
    Bertrand> ("template instantiation problem") and, as a result, the
    Bertrand> advice regularly given in the C++ literature to avoid
    Bertrand> using templates too much. In Eiffel, you can generate
    Bertrand> code just once (with some specific optimizations for
    Bertrand> basic types), without having to pay any performance
    Bertrand> overhead either at compile time or at run time. So you
    Bertrand> can use genericity as much as you like.  The ISE Eiffel
    Bertrand> libraries, for example, are generic throughout.

 
    Bertrand> In comparison with Eiffel, not even mentioning Java with
    Bertrand> its total lack of genericity, the other attempts at
    Bertrand> generic mechanisms that I have seen in an O-O context
    Bertrand> look to me rather half-hearted.

    Bertrand> I think Eiffel's consistent and complete treatment of
    Bertrand> genericity and inheritance is one of the reasons why
    Bertrand> some of the biggest successful industrial O-O projects
    Bertrand> have been produced in Eiffel. When the goal is not just
    Bertrand> to play around, but to build large, mission-critical
    Bertrand> systems, one needs the right combination of mechanisms,
    Bertrand> not just a partial attempt.

    Bertrand> For details about the Eiffel mechanism see the Eiffel
    Bertrand> language tutorial at http://www.eiffel.com.


    Bertrand> -- Bertrand Meyer, President, ISE Inc., Santa Barbara
    Bertrand> (California) 805-685-1006, fax 805-685-6869,
    Bertrand> <bertrand@eiffel.com> - ftp://ftp.eiffel.com Visit our
    Bertrand> Web page: http://www.eiffel.com (WITH FRAMES) or
    Bertrand> http://www.eiffel.com/noframes.html



Markus
-- 
+----------------------------------------------------------------------------+
| Markus Kohler                          Hewlett-Packard GmbH                |
| Software Engineer                      Network & System Management Division| 
|                                        IT/E Success Team                   |
+----------------------------------------------------------------------------+

Re: OO, C++, and something much better!

[Matthew Heaney]

In article <32D2E6C8.13728473@eiffel.com>, Bertrand Meyer
<bertrand@eiffel.com> wrote:

>In my opinion neither Ada (83 or 95) nor C++ has the combination
>of mechanisms making it possible to have the full power of
>generics in an object-oriented language, as present in Eiffel:
>
>        - Unconstrained genericity, to declare a class
>          as e.g. LIST [G], where G represents an arbitrary
>          type, so that you can then use LIST [SOME_TYPE] regardless
>          of what SOME_TYPE is.

Ada has had that ability since the original standard:

generic
   type List_Item is private;
package Lists is
   type List is private;
   procedure Add (Item : in List_Item; To : in out List);
...


>
>        - Constrained genericity, as in e.g. 
>          SORTED_LIST [G -> COMPARABLE], to require that
>          some operations be applicable to all actual
>          generic parameters. The rule is that
>          SORTED_LIST [SOME_TYPE] is permitted if and only
>          if SOME_TYPE inherits, directly or indirectly from
>          COMPARABLE. The -> symbol is evocative of the symbol
>          for inheritance used in class diagrams in e.g. B.O.N.
>          Within the class SORTED_LIST, any operation (feature, method)
>          of class COMPARABLE, such as infix "<" etc., is then applicable
>          to entities of type G.

There are 2 ways of doing that in Ada 95.

The first (what you could already do in Ada 83) is to require that the type
have a comparison operator:

generic
   type List_Item is private;
   with function "<" (Left, Right : List_Item) return Boolean is <>;
package Sorted_Lists is
   type List is private;
...

The second (new to Ada 95) is to require that the type inherit from another:

package P is
   type T is tagged private;
   function "<" (L, R : T) return Boolean;
...
end P;

with P;
generic
   type List_Item is new P.T;
package Sorted_Lists is
   type List is private;
...

>So in the constrained genericity case SORTED_LIST [INTEGER]
>will be permitted, since COMPARABLE is indeed an existing class,
>describing order relations and part of the Eiffel Library
>Kernel Standard, and INTEGER (also part of ELKS) does inherit
>from COMPARABLE.

I can instantiate my first sorted list package, because type Integer comes
predefined with a comparison operator.

with Sorted_Lists;
package Integer_Sorted_Lists is new Sorted_Lists (Integer);


>
>SORTED_LIST [TENNIS_PLAYER] will also be
>valid, assuming the user-defined class TENNIS_PLAYER inherits
>from COMPARABLE. But something like SORTED_LIST [COMPLEX]
>will be rejected by the compiler, assuming COMPLEX is not
>a descendant of COMPARABLE.

If tennis player has a comparison operator, then I can use sorted_list
version 1.

If tennis player derives from P.T, and I can use either sorted list version
1 or 2.

>In the unconstrained case, a declaration such as LIST [G]
>is understood as an abbreviation for LIST [G -> ANY], where
>ANY is the ELKS class inherited by all classes. This makes
>it possible to apply objects of type G a wide range of operations
>applicable to all objects: equality comparison (redefinable
>in any class as long as it satisfies the original assertions),
>copying, cloning, even (in the latest version of ELKS) hash
>coding.

Technically, I should modify the sorted list as follows:

generic
   type List_Item is private;
   with function "=" (L, R : List_Item) return Boolean is <>;
   with function "<" (L, R : List_Item) return Boolean is <>;
package Sorted_Lists is ...;

That way I can let the client pass in his "=" method that replaced the
predefined one for unlimited (private) types.


>In Eiffel, you can generate
>code just once (with some specific optimizations for basic types),
>without having to pay any performance overhead either at compile
>time or at run time. So you can use genericity as much as you like.

As you can in Ada.

>In comparison with Eiffel, not even mentioning Java with its total lack
>of genericity, the other attempts at generic mechanisms that I have seen
>in an O-O context look to me rather half-hearted.

P.J. Plauger once refered to C++ as having "ugly pragmatism."  I would say
about Ada 95 that it has "beautiful pragmatism."  We humans bandy about
terms like "purity," but there's no such thing in Nature; she only cares
about what works.  I think there's room for pragmatism, though C++ probably
pushes that argument a bit too far.  N'est-ce pas?

matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: OO, C++, and something much better!

[Robert Dewar]

Michael says

"ability to expand them at compile time without losing optimizations, unlike
Ada generics whose paradigm is to expand at run-time and remove staticness
from expressions."

incomprehensible confusion. there is no "run-time" expansion of generics'
in Ada, and there is no issue of losing optimizations ...

Re: OO, C++, and something much better!

[Robert Dewar]

iKen says

""Actually, back with Ada was a MIL-STD, there was a requirement to review
it
every _five_ years for updates."


Also it was an ANSI requirement, not a MIL-STD rqeuirement to initiate
review of the standard at a five year interval.

Re: What is wrong with OO ?

[Robert Dewar]

Bart said

"You shouldn't bother programmers with inlining. Inlining can be done
automatically by the compiler."

I don't see this is possible across modules without violating the integrity
of separation of specs and implementations.

Re: OO, C++, and something much better!

[Robert Dewar]

Ken writes

"Actually, back with Ada was a MIL-STD, there was a requirement to review
it
every _five_ years for updates. As I recall, no one wanted to do an
update
on the first cycle, in order to give implementations a chance to mature.
The
second cycle ended with Ada 95."

(Ken can you keep your lines from folding, makes it hard to read your posts)

This is rewriting history. Ada was standardized in 1983, and it is definitely
NOT the case that no one thought about a revision till 1993. On the contrary,
what happened is that people *did* start thinking about a revision in the
time period consistent with the five year rule -- this rule does not say
you need a standard every five years, just that you should start to think
about it. But the process from starting to think to standardizing Ada 95
was a very long process (6-7 years, I don't have the exact starting point).

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32D2E6C8.13728473@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

Wow.  The big folk are coming out.  Add in a couple others and the
whole thing might start looking like the Vorlons and Shadows! :-)

I'll play a Ranger (representing Ada, of course, ;-)


> In my opinion neither Ada (83 or 95) nor C++ has the combination
> of mechanisms making it possible to have the full power of
> generics in an object-oriented language, as present in Eiffel:

This is not surprising, ;-)

But,

> 	- Unconstrained genericity, to declare a class
> 	  as e.g. LIST [G], where G represents an arbitrary
> 	  type, so that you can then use LIST [SOME_TYPE] regardless
> 	  of what SOME_TYPE is.

This is in Ada95:
generic
    type G is private;
package List is...


> 	- Constrained genericity, as in e.g. 
> 	  SORTED_LIST [G -> COMPARABLE], to require that
> 	  some operations be applicable to all actual
> 	  generic parameters. The rule is that
> 	  SORTED_LIST [SOME_TYPE] is permitted if and only
> 	  if SOME_TYPE inherits, directly or indirectly from
> 	  COMPARABLE.

This too is in Ada95:

generic
    type G is new Comparable with private;
package Sorted_List is ...

Same instantiation constraints as in the Eiffel case...


> 	- True static typing (with no cast a la C++).

Yes, this is in Ada95 too.  In fact it is better in Ada95 since it
does not have system validity problems.


> 	- A completely consistent type structure, in which 
> 	  even basic types such as INTEGER are classes,
> 	  present in the general inheritance structure.
> 	  (In C++ or Java, for example, the basic types
> 	  are completely separate from the class and inheritance
> 	  structure.)

OK, here you have me.  But, Eiffel hedges a bit here as well with its
"expanded types".


> So in the constrained genericity case SORTED_LIST [INTEGER]
> will be permitted, since COMPARABLE is indeed an existing class,

Good point.  Lost a Minbari Cruiser on this one...


> In the unconstrained case, a declaration such as LIST [G]
> is understood as an abbreviation for LIST [G -> ANY], where
> ANY is the ELKS class inherited by all classes. This makes

Same as in Ada.


> it possible to apply objects of type G a wide range of operations
> applicable to all objects: equality comparison (redefinable
> in any class as long as it satisfies the original assertions),
> copying, cloning, even (in the latest version of ELKS) hash
> coding.

Here is where you actually get some more flexibility with Ada as you
can parameterize your generic (either the constrained or unconstrained
type) with more than just types.  You can specify complete signatures
including operations and/or packages as well.  What's more, these can
have constraints on them as well.  Of course, it doesn't have real
assertions, so I suppose this is kind of a wash...


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Sazonov Cyril]

I'm absollutely agree with Stanley Allen ! Just to say more: C++ doesn't
suggest _ANY_ new ideas or tools in comparison with Ada !

> John (Max) Skaller wrote:

>> Is C++ innovative? Too right it is.
>> It has the most powerful support for genericity available
>> in any widely used commercial language. (Sorry, Ada doesn't count,
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> You loaded the question, and therefore your dismissal of
> Ada is the act of knocking down a strawman.

> To hear that C++'s template mechanism is "innovative" and
> "powerful" comes as a surprise.  Parts of the C++ template
> mechanism look like a borrowing of Ada's "generic" facility
> (Stroustrup attributes this to Alex Stepanov, who had done
> a great deal of work with Ada generics before designing the
> C++ Standard Template Library).  Unfortunately, the type
> system in C++ is too weak to support anything as powerful
> as Ada's generic facility.  The C++ "template argument"
> (which corresponds to Ada's "generic formal parameter") for
> a type can only be of the form "class T".  In Ada terms,
> this would be like having all generic formals be
> "type T is private".

At all talks of 'new word', 'revolutionary technology' etc in the context of
OOP and C++ especially seems to be strange for the ones who know  Ada since,
for example, 1989. All the ideas of the OOP had been implemented in Ada, even
though they seamed to classic in the time of the language design. Triumphant
march of the OOP and C++ is caused by some kind of lazyness and illiteracy.
The ones who find that technology to be new simply aren't familiar with the
Algol-family languages history.

Ada delivers the programmer/developer a well built complex of neat, strict,
clear and _orthogonal_ means. Its clear structure makes it very easy to study,
'immensity' of the language is nothing else but myth. As all Algol-family
languages Ada assumes that the compiler will do _all_ the 'dirty' work.
Surelly, this doesn't make anyone to fill him a 'real' programmer, as C/C++
do. And this language is really hard -- not for programmer, but for
implementor only. The money saved for compiler production could be used for
advertizing -- this is one more point of the commersial success of the C/C++.
But mind the money saved by the implementors are saved by your hands, you are
to do all what they didn't like to do ( just recollect and compare the type
systems of Ada and C++ ! ).

The very important thing is that Ada _forces_ you to _design_ your programms,
even very small and simple, without it you will not do just a step with Ada.

As for me I haven't seen nothing better than Ada.

Best wishes from Russia for all of you and especially for Stanley Allen.

8 jan 97                                                      Cyril Sazonov

Re: What is wrong with OO ?

[Robert Dewar]

Jay, in typical fulminating mode says

 "It seems to me need for "pragma inline" and "inline" is/was social.
 It came from compiler writers continually slacking off since the 60's
 and not implementing inlining."

nonsense, all decent compilers implement inlining today, it is a more
vital optimization than ever because of icache considerations (particularly
in direct addressed caches).

The pragma inline in Ada is simply a permission to create a dependence
on the body, it has nothing to do with what you think of informally as
inlining.

In a large project it is essential not to accidentally create interunit
dependences so that a small change to one unit causes millions of lines
to need to be recompiled.

There is of course no problem in implementing automatic inlining within
a unit. As I said earlier, virtually all production compilers do this,
including of course GCC.

The problem is that you definitely do NOT want the compiler rushing off
and creating unlimited body dependencies (think interunit dependencies
if you don't want to think Ada specifically) by doing automatic interunit
inlining.

Still some interunit inlining is highly desirable especially with
heavy layering of abstractions. But you want to give the programmer
some control, to avoid the problem of inter-unit dependencies running
amok!

Re: What is wrong with OO ?

[Bjarne Stroustrup]

Bart Samwel <bsamwel@wi.leidenuniv.nl> writes:

 > 
 > Bjarne Stroustrup wrote:
 > 
 > > Only where I couldn't find a solution that fitted in C++'s general
 > > framework and met my criteria for run-time efficiency, ease of
 > > implementation, ease of teaching, etc. (see D&E Chapter 4), did I
 > > feel compelled to try to invent something.
 > 
 > When I read this, a lot of questions pop up in my head. I'll ask only
 > one: You've only included features that didn't compromise ease of
 > teaching (at least, that's my interpretation of what you wrote). Why is
 > it then, that C++ contains so many hidden 'features' (or rather,
 > non-explicit rules) that confuse people, at least at my university?

In addition to giving an answer to you ``only one'' question, I will
comment on some of the pretty strong statement you made afterwards -
lest silence should be taken for agreement, lack of counter arguments,
or arrogance.

I'm not sure which hidden_features/non-explicit_rules you are referring
to, but I do have some experience with the teaching, learning, and use
of C++ that might be relevant.


First, here is the way I phrased the "learning" criteria in "The Design
and Evolution of C++":

	If in doubt, pick the variant of a feature that is easiest to teach

	This is a secondary rule for choosing between alternatives.
	It is tricky to apply because it can be an argument for logical
	beauty and also for sticking to the familiar. Writing tutorials
	and reference manual descriptions to see how easy they are for
	people to understand is a practical application of this rule.
	One intent is to ease the task for educators and support personnel.
	It is important to remember that programmers are not stupid;
	simplicity mustn't be achieved at the expense of important
	functionality.

It is one of about twenty such rules of thumb I rely on.


C++ is a language primarily aimed at creating production software. Like
all such languages, it together with its associated libraries, tools, and
programming techniques is too large to learn quickly (unless you happen
to be experienced in rather similar languages and techniques - and most
students and programmers are not when they first encounter C++).
Consequently, it must be learned in stages starting with some suitable
subset (and a suitable subset of tools, libraries, programming techniques).

Many are too ambitious and try to learn too much too fast. In particular,
many programmers focus on learning every obscure language detail rather
than overall principles because mastery of programming language details
is what has traditionally been valued in many programming communities.
That way, people get lost in details.

That, together with the common mistake of chosing "all of C" as the
initial subset of C++ to learn have led many into trouble. These problems
are avoidable. In particular, only a relatively small part of the common
C and C++ subset needs to be understood before one can approach the
abstraction mechanisms that are the essential part of C++.

Traditionally, C++ has been blessed with a mass of useful libraries, and
cursed by the absence of a good standard library. The lack of a standard
library supplying basic types (such as string, list, and map) reinforced
the bias of some teachers and some teaching materials towards low-level
features and techniques that don't rely on standard library facilities.

C++ now has a nice standard library and most implementation now are shipped
with a reasonable approximation to it. However, the effects of its initial
absence (primarily my fault) still lingers in teaching methods and teaching
materials.

C++ caught on very fast. This led to people "joining the bandwagon"
without actually understanding what the important ideas were. Many times,
I have cringed seeing what riduculous statements were made about C++
and its proper use. For example, an early textbook proudly gave an
airplane derived from an engine as its first example of object-oriented
programming. Naturally, that author had never written a real C++ program
in his life or a real program in any other programming language supporting
object-oriented programming. Fortunately, he later jumped on another
bandwagon and is now pushing some other OO language.

I have no idea if any of this apply at your university, but I have seen
all of those phenomena repeatedly. Usually, people manage in the end, and
if not they try something else - which they may or may not find more
suitable.

I provide more details about learning and teaching C++ in "The Design
and Evolution of C++" (D&E) and on my homepages. C++ can be - and often
is - taught effectively to people of a wide variety of backgrounds and
with widely varying needs.


 > As far as I'm concerned, C++ is not a language for teaching. It has too
 > many of these implicit rules to be logical, and the fact that it
 > doesn't have garbage collection and does have pointers really makes it
 > error-prone; especially for beginning programmers, this is not a good
 > thing. They should be writing WHAT should be done, and ALL that should
 > be done; they shouldn't be bothered with the 'how' part of programming,
 > like (with alternatives): memory management (garbage collection),
 > pointers (references), virtual functions (can be detected by the
 > compiler). They should not be bothered with implicit rules (like the
 > multiple inheritance rules, for instance) that they have to know of,
 > before using multiple inheritance.
 > 
 > C++ is an excellent language as an extension to C, but C is altogether
 > obsolete and much too low-level, except for systems programming, and
 > other languages are now available for writing high-level software.
 > Many people make the (IMO huge) mistake of using C++ for high-level
 > software projects, leading to buggy results and, often, lots of core
 > dumps. Programmers are not perfect, and C++ expects them to be so by
 > providing too many ways of making mistakes.

I'm not sure about what you call a "high-level software project" but
C++ has been applied successfully often enough for your description
of the results of using C++ to be a carricature. There has been failures
involving every programming language that has ever been used for
production code. Since there has been more use of C++ than for any
other comparable language, I would expect there to have been more
with C++. However, I use C++ software daily that doesn't dump. There
are many C++ programs out there that works correctly month in and month
out. Reliability and mainatainability can be eased by a programming
language (such as C++) but is the result of a more comprehensive
process.

C++ is a programming language, so it doesn't have expectations, but I
- as its designer - never suffered from the delution that programmers
were anywhere near perfect. Nor did I suffer from the delusion that
I knew enough to put restrictions in place to constrain every programmer
without exception or escape.


 > Languages like Eiffel (my personal favorite) are much more suitable for
 > high-level projects; Eiffel, for instance, does not burden the
 > programmer more than needed, and has a clean, clear syntax that can
 > even be immediately understood by people that don't know the language.

I do not personally find it so, and such claims reminds me unpleasently
of the similar claims made for COBOL. A non-programmer can sometimes be
convinced that he/she can read simple code, but it is far from obvious
that this is relevant - or ever true - for production code (that will only
be seen by programmers anyway). 


 > > Much of C++'s success has to do with fitting into existing
 > > environments and being compact and fast (yes, I know that these are
 > > not the aspects of C++ that are currently emphasized in the
 > > MS Windows world). The speed and compactness of code generated from
 > > C++ depends on a few fundamental design decisions that I think were
 > > novel at the time:
 > 
 > Speed and compactness is certainly a goal that C++ has achieved. But it
 > did not achieve one major goal: ease of use.

I wonder how you would measure ``ease of use'' objectively. For starters:
``ease of doing what kind of work?'' ``ease for whom?'' C++ isn't the
easiest programming language to learn and to use, but for a rather large
range of systems, a large range of applications, and a large range of
developer communities, it seems to be the easiest language out of those
that can actually help get the work done.

Had C++ not been relatively easy to learn and use reasonably well, it
would have disappeared long ago. By relative I mean the amount of effort
needed compared to the amount of benefit gained.


 > >         C++ offers inline member and non-member functions with zero
 > >         overhead compared to macros.
 > 
 > You shouldn't bother programmers with inlining. Inlining can be done
 > automatically by the compiler.

Not really. Some compilers can do some inlining well, but for larger
programs the compiler is hampered by having incomplete information
and by not having a particularly good idea of what optimizations are
relevant in various part of the code. Explicit inlining is a pretty
good way of giving programmers some control for the common cases where
a compiler isn't smart enough without tying users up with proprietary
and non-standard control features. Used well, inlining can make a major
difference in speed and code compactness.


 > >         C++ offers its form of dynamic (run-time) resolution, virtual
 > >         functions, with low and fixed overhead compared to ordinary
 > >         function calls (20% to 100% dependent of implementation).
 > 
 > Virtual functions must be explicitly specified. This can be done by the
 > compiler. And, virtual functions must be specified in the ancestor
 > class; this means that when a class designer forgot to put that in
 > (and this happens often), I can't redefine the function correctly.

Deciding which member functions should be virtual is a design decision,
not an optimization. If a designer has provided a poor base class, you
will typically have problems beyond what can be fixed by overriding.


 > > Over the years, C++ has evolved within a framework that was reasonably
 > > well understood early on.
 > 
 > Well understood, yes. But the framework is now obsolete, and it has
 > some serious design flaws that also bother C++ users.

Certainly there are flaws - I don't know of a language that doesn't have
flaws, and I consider the idea of a widely-used flawless language nonsense.

Once a language is used by diverse user communities, one person's serious
flaw becomes another's essential feature. Some of the aspects of C++ that
I dislike most are deemed essential by very competent system builders.
However, C++ has no flaw and no feature lacking that is so serious that
it cannot be managed with reasonable effort in a project - even if they
can be a bother and experienced programmers recognize them as such.

I do not consider C++ or its basic conceptual framework obsolete nor
do I know an alternative that could replace it in the next few years.
Like it or not, programming languages have lifecycles that span decades,
and "obsolete" often means little more than "not in accordance with the
latest fad." For most builders of real-world software a ten-year-old
language is a newborn. ``OO'' itself is more than 25 years old and we
are still learning about it - even those of us who have been part of the
process through most of those years.

The world is a whole lot messier than we would like it to be, and some of
that messiness is reflected in every successful programming language.

Good luck with your projects and the language you favor, and remember
that the world is more complicated that any of us can imagine and that
there are ways of succeeding that we would not personally have chosen.

	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html
	
 
 >    Bart Samwel  (bsamwel@wi.leidenuniv.nl)
 > 
 > 

Re: OO, C++, and something much better!

[Don Harrison]

Jon S Anthony writes:

:In article <32D2E6C8.13728473@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:
:
:Wow.  The big folk are coming out. 

:)

:> 	- Unconstrained genericity, to declare a class
:> 	  as e.g. LIST [G], where G represents an arbitrary
:> 	  type, so that you can then use LIST [SOME_TYPE] regardless
:> 	  of what SOME_TYPE is.
:
:This is in Ada95:
:generic
:    type G is private;
:package List is...

Yes.

:> 	- Constrained genericity, as in e.g. 
:> 	  SORTED_LIST [G -> COMPARABLE], to require that
:> 	  some operations be applicable to all actual
:> 	  generic parameters. The rule is that
:> 	  SORTED_LIST [SOME_TYPE] is permitted if and only
:> 	  if SOME_TYPE inherits, directly or indirectly from
:> 	  COMPARABLE.
:
:This too is in Ada95:
:
:generic
:    type G is new Comparable with private;
:package Sorted_List is ...
:
:Same instantiation constraints as in the Eiffel case...

Yes. However, I'm not sure whether you lose some of the power of combining 
genericity with inheritance through Ada's module-type distinction. Since 
genericity in Ada is essentially module-based and inheritance is type-based,
I suspect you may lose something here.

:> 	- True static typing (with no cast a la C++).
:
:Yes, this is in Ada95 too.  

No. Ada offers type casting in a couple of ways:

  1) UNCHECKED_CONVERSION and
  2) Address representation clauses (overlays).

Eiffel, by contrast, has no such thing in the standard language. That isn't 
to say it isn't needed for some things (and is why some vendors do provide 
type conversion between basic types and bits, for example). 

I have been trying to think of a safe way of doing this sort of thing but
thus far haven't thought of any. :) 

:In fact it is better in Ada95 since it
:does not have system validity problems.

Perhaps not the same kind of problems. But it's dead easy to write 'system
invalid' Ada which will result in runtime errors. For example, by using the 
value of a parent type where a subrange value is required.

[...]

:> it possible to apply objects of type G a wide range of operations
:> applicable to all objects: equality comparison (redefinable
:> in any class as long as it satisfies the original assertions),
:> copying, cloning, even (in the latest version of ELKS) hash
:> coding.
:
:Here is where you actually get some more flexibility with Ada as you
:can parameterize your generic (either the constrained or unconstrained
:type) with more than just types.  You can specify complete signatures
:including operations and/or packages as well.  What's more, these can
:have constraints on them as well.  

Yes. However, these kinds of formal parameters are only needed in Ada because
it distinguishes between module and type. Eiffel's unification of module and
type obviates the need for them. :)  Eiffel's genericity mechanism is also
simpler because it is a *pure* OOPL compared to hybrid Ada.

:Of course, it doesn't have real
:assertions, so I suppose this is kind of a wash...


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Fergus Henderson]

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

>Bart said
>
>"You shouldn't bother programmers with inlining. Inlining can be done
>automatically by the compiler."
>
>I don't see this is possible across modules without violating the integrity
>of separation of specs and implementations.

So?  Why is it so important to preserve the "integrity of separation"?

I prefer compilers that provides a full range of trade-offs between
(re)compilation speed and the efficiency of the generated code.  In
most circumstances, programmers are best served by a compiler that
compiles fast during development (when you want to avoid cross-module
inlining, to avoid unnecessary recompilation) but that can pull out all
stops for the optimized version.

There are times when you want optimizations yet you want to avoid
cross-module optimizations, but those should be exceptions;
automatic cross-module inlining ought to be the norm.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Richie Bielak]

Fergus Henderson wrote:

[...]
 
> I prefer compilers that provides a full range of trade-offs between
> (re)compilation speed and the efficiency of the generated code.  In
> most circumstances, programmers are best served by a compiler that
> compiles fast during development (when you want to avoid cross-module
> inlining, to avoid unnecessary recompilation) but that can pull out all
> stops for the optimized version.
> 
> There are times when you want optimizations yet you want to avoid
> cross-module optimizations, but those should be exceptions;
> automatic cross-module inlining ought to be the norm.
> 

Optimizations that require global analysis of all the classes
of a program at compile time do not work if we need dynamic loading
of classes at runtime, because adding a new class to a running system
may invalidate optimizer's assumptions.

...richie

-- 
* richieb@netlabs.net       - at home |  Richie Bielak             *
* richieb@calfp.com         - at work |                            *
*          Home page:   http://www.netlabs.net/hp/richieb          *
*        "Fight software piracy, use free software!" (me)          *

Re: What is wrong with OO ?

[William Clodius]

Robert Dewar wrote:
> 
> Bart said
> 
> "You shouldn't bother programmers with inlining. Inlining can be done
> automatically by the compiler."
> 
> I don't see this is possible across modules without violating the integrity
> of separation of specs and implementations.

There are two aspects of the concept of integrity logical and physical.
Inlining disobeys physical integrity, but obeys logical integrity if the
final result of the computation does not ("significantly") affect the
final result of a computation. Under the "as if" rules of most
standards, the compiler writer should primarilly concerned with logical
consistency. However, as the inlining can result in intermodule
dependencies that, on modification of the module containing the inlined
code, can result in a chain of recompilations, I would probably not
recomend that such inlining be the default for the compiler, but it is
certainly allowable (perhaps advisable) as an optional switch in the
compilation process.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: What is wrong with OO ?

[Simon Willcocks]

In article <dewar.852772995@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) says:
>
>Bart said
>
>"You shouldn't bother programmers with inlining. Inlining can be done
>automatically by the compiler."
>
>I don't see this is possible across modules without violating the integrity
>of separation of specs and implementations.
>
I take it you're coming from an Ada perspective, where each package can
be separately compiled without any information from other packages'
implementations?

I think that even in this case inlining could be done by a suitable linker,
provided the compiler could mark parts of object code as suitable for inlining.
The linker could insert the relevant code in place of the call statement,
rather than just setting the location to be called.

Simon Willcocks

Re: OO, C++, and something much better!

[Ted Dennison]

Robert Dewar wrote:
> 
> Ken writes
> 
> "Actually, back with Ada was a MIL-STD, there was a requirement to review
> it
> every _five_ years for updates. As I recall, no one wanted to do an
> update
> on the first cycle, in order to give implementations a chance to mature.
> The
> second cycle ended with Ada 95."
> 
> (Ken can you keep your lines from folding, makes it hard to read your posts)

In particular, when your newsposter automaticly wraps text for you, you
really have no choice but to let it. Trying to terminate lines manually
will just lead to tough to read text. But its a damn tough habit to get
out of, once you are used to hitting that return key at the end of the
line.

> This is rewriting history. Ada was standardized in 1983, and it is
> definitely NOT the case that no one thought about a revision till
> 1993. On the contrary, what happened is that people *did* start 
> thinking about a revision in the time period consistent with the five

Does that mean that they ALSO started thinking about the revision again
in 1993, even though the Ada 95 effort was well underway?  ;-)




-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: What is wrong with OO ?

[Bertrand Meyer]

Robert Dewar wrote:
> 
> Bart said
> 
> "You shouldn't bother programmers with inlining. Inlining can be done
> automatically by the compiler."
> 
> I don't see this is possible across modules without violating the integrity
> of separation of specs and implementations.


The ISE Eiffel compiler performs inlining completely automatically.
There is no "pragma inline" or comparable programmer intervention,
since it is not the programmer's job to worry about whether a routine
is inlinable or not. This is a job for a compiler.

(In addition, for an object-oriented language, inlining is only
possible for a routine that is never subject to dynamic binding.
This requires extensive analysis of the software. If the programmer
requests
inlining but it is semantically wrong, the compiler should ignore
the request. But then if the compiler is capable of doing this analysis
it should take care of the inlining too, without bothering the
programmer!)

ISE Eiffel does give the user a degree of parameterization:
a compilation option specifies the size threshold beyond which
a routine will not be inlined. This is measured in internal units
(number of bytecode words), but easy to relate to number of
instructions. This option provides a way to control space-time
tradeoffs. In practice, however, most users are happy with the
default, which inlines small, frequently called routines.

This automatic optimization is crucial because the object-oriented
style of development, with its emphasis on  abstraction, naturally
tends to yield many small routines. With ISE Eiffel, you can write the
software as it should be, not asking yourself all the time "should
I violate abstraction here and avoid writing a small routine because
of the effect on performance?". You just leave this kind of concern
to the compiler. ("Inline" pragmas would be almost worse here, because
you would have to perform yourself the analysis of what is inlinable
and what is not. The incrementality problem is particularly nasty:
change a single line somewhere in a large system, and a routine that was
inlinable,
far away in the software text, now becomes  non-inlinable! This
kind of systematic, exhaustive  work, error-prone when done
by humans, is what computers are for.)

I also think that the Eiffel view of "separation of specs and
implementations"
is more sophisticated than Ada's one (which I assume is the one Robert
Dewar has in mind), but that will be the topic for another debate...



-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com  or
http://www.eiffel.com/noframes.html
	(includes instructions for downloading ISE Eiffel 4 for Windows)

Re: OO, C++, and something much better!

[Bertrand Meyer]

Robert I. Eachus wrote:
> 
> 
>       Bertrand Meyer said:
> 
>    > In my opinion neither Ada (83 or 95) nor C++ has the combination
>    > of mechanisms making it possible to have the full power of
>    > generics in an object-oriented language, as present in Eiffel...
> 
>      And then listed four properties, all of which are in Ada 95!

I disagree. What Mr. Eachus showed in his message is ways to achieve
in Ada 95 the effect of the object-oriented mechanisms I described,
as implemented in Eiffel. And he is correct that one can use Ada 95
to obtain many of the same goals. (This would not be true, for example,
of C++ and even less of Java.) But this does not mean the "four
properties" that I listed are in Ada 95. Anyone who checks my
message and the Ada 95 language definition will see that.


To the four properties listed in my original I should also add two
just as essential requirements: true multiple inheritance, for combining
different abstractions (and with the right mechanisms to avoid any
ambiguity or conflict); and, most importantly, Design by Contract
and the rules on how assertions combine with inheritance. As someone
remarked, it is really impossible to understand inheritance without
understanding Design by Contract.


At some point, of course, one runs into matters of taste. I will
again contend, however, that a rational, systematic analysis of
O-O principles and how they combine with genericity, information hiding
and other software engineering concerns almost inevitably lead to the
Eiffel mechanisms.

-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: What is wrong with OO ?

[Ken Garlington]

Robert Dewar wrote:
> 
> Bart said
> 
> "You shouldn't bother programmers with inlining. Inlining can be done
> automatically by the compiler."
> 
> I don't see this is possible across modules without violating the integrity
> of separation of specs and implementations.

Actually, with some Ada compilers, you _can_ do inlining automatically,
by
setting the optimization level high enough.
--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: What is wrong with OO ?

[Robert Dewar]

Simon said

'I take it you're coming from an Ada perspective, where each package can
be separately compiled without any information from other packages'
implementations?

I think that even in this case inlining could be done by a suitable linker,
provided the compiler could mark parts of object code as suitable for inlining.
The linker could insert the relevant code in place of the call statement,
rather than just setting the location to be called."


Right (Ada persepective, and indeed C is the same, where you see the headers
and not bodies of other units).

Inlining is MUCH more than just sticking in the code at the point of call
and cannot be done at all by a stupid linker. The whole point of inlining
is that you optimize the code that is inserted, minimally by increasing
scheduling opportunities, but in the presence of global optimization, knowing
what the body of a procedure does and does not do can buy a great deal. The
elimination of the call itself is small stuff compared to the other gains.

Re: OO, C++, and something much better!

[Don Harrison]

David Emery writes:

:>> 	- A completely consistent type structure, in which 
:>> 	  even basic types such as INTEGER are classes,
:>> 	  present in the general inheritance structure.
:>> 	  (In C++ or Java, for example, the basic types
:>> 	  are completely separate from the class and inheritance
:>> 	  structure.)
:>
:>OK, here you have me.  But, Eiffel hedges a bit here as well with its
:>"expanded types".
:
:I think that there is not a clear consensus on this as A Good Thing.
:From a practical perspective, there seems to be a significant price to
:pay for 'full generality' (e.g. integers are classes just like
:user-defined record types.)  Java, for instance, has primitive integer
:types, and my understanding that the reason for this is performance,
:pure and simple.  Making 'int' a class would result in unacceptable
:performance, both compile-time and runtime, for simple things like
:"a[i++] := b + c;" (for int a, b, c).

Eiffel expanded types (one of which is class INTEGER) are not accessed via
references so do not carry that overhead. Hence, they can be implemented as 
efficiently as Ada/C++ integers.

However, if you *do* need to define a more specific integer type, you can
inherit from the parent (reference) type, INTEGER_REF.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Jay Martin]

Bertrand Meyer <bertrand@eiffel.com> writes:

>Robert Dewar wrote:
>> 
>> Bart said
>> 
>> "You shouldn't bother programmers with inlining. Inlining can be done
>> automatically by the compiler."
>> 
>> I don't see this is possible across modules without violating the integrity
>> of separation of specs and implementations.


>The ISE Eiffel compiler performs inlining completely automatically.
>There is no "pragma inline" or comparable programmer intervention,
...

It seems to me need for "pragma inline" and "inline" is/was social.
It came from compiler writers continually slacking off since the 60's
and not implementing inlining.  Its hard to blame them as it didn't
seem a market priority due a totally irresponsible and incompetent
Computer Science Academia which produced a generation of programmers
who think "C" is Computer Science and had the attitude that it was the
job of programmers not compilers to do optimizations and said such
things as "I do low level pointer arithmetic so that my COMPILER runs
faster (a top UC Berkeley Graduate).  Pragma inline gave us a hammer
to which to pound the compiler writers into submission.

Jay

Re: What is wrong with OO ?

[Robert Dewar]

"So?  Why is it so important to preserve the "integrity of separation"?"

  No comment, let's just say that there are those of us who think the
  separation at an abstract level between specification and implementation
  is important. I am quite aware that there lots of C programmers who not
  only don't agree, they don't even understand what I am talking about!!

There are times when you want optimizations yet you want to avoid
cross-module optimizations, but those should be exceptions;
automatic cross-module inlining ought to be the norm.

  I think not. You can only do cross-module inlining if every compilation
  potentially recompiles code for the entire application. This seems out
  of the question in large applications.

  It seems to me here that the Ada approach is just right. Fergus, if you
  are aware of the Ada approach, what would you change?

Re: OO, C++, and something much better!

[Robert Dewar]

Don Harrison says

"No. Ada offers type casting in a couple of ways:

  1) UNCHECKED_CONVERSION and
  2) Address representation clauses (overlays).

Eiffel, by contrast, has no such thing in the standard language. That isn't
to say it isn't needed for some things (and is why some vendors do provide
type conversion between basic types and bits, for example).

I have been trying to think of a safe way of doing this sort of thing but
thus far haven't thought of any. :)"


Well there obviously is no safe way of doing something whose entire purpose
is to allow unsafe operations!

Still I would not characterize these as "type casting" in Ada. Rather I 
would think of them as loopholes, equivalent to calling a C or assembly
routine. Any formal analysis or discussion of the type system of Ada
has to ignore these features, and of course any real language to be used
for low level systems programming needs such features, but I don't think
it is a useful excercise to include these features in the type analysis.

If you like, consider Ada *minus* these two features as the interesting
language to be analyzed. Then understand that in real life programs can
break the bounds of this analysis to the extent they need to.

Note that it is not actually the unchecked conversion that is nasty, since
the fundamental conversion can be modeled as simply a random mapping between
values of one type to values of another type. It is that these operations
can generate abnormal values. 

This may still not be a problem, given that uninitialized values can also
be abnormal, thus:

  a := nasty_unchecked_conversion (b);

is no worse that not assigning to a at all if a is uninitialized.

Re: What is wrong with OO ?

[Robert Dewar]

Bertrand says

"This automatic optimization is crucial because the object-oriented
style of development, with its emphasis on  abstraction, naturally
tends to yield many small routines. With ISE Eiffel, you can write the
software as it should be, not asking yourself all the time "should
I violate abstraction here and avoid writing a small routine because
of the effect on performance?". You just leave this kind of concern
to the compiler. ("Inline" pragmas would be almost worse here, because
you would have to perform yourself the analysis of what is inlinable
and what is not. The incrementality problem is particularly nasty:
change a single line somewhere in a large system, and a routine that was
inlinable,
far away in the software text, now becomes  non-inlinable! This
kind of systematic, exhaustive  work, error-prone when done
by humans, is what computers are for.)"


This misunderstands the function of pragma Inline in Ada. This is NOT
a directive that the compiler should inline the function, not at all,
it is simply a permission to establish a compilation dependency on the
body, an obvious prerequisite for permitting the inlining.

If you want to let the compiler do unlimited automatic inlining, then 
you simply label every visible function as being pragma Inlined. Then
the compiler has complete freedom to inline anything. Of course it will
still only inline things if it makes sense to do so, which is something
that requires a lot of low level input (just measuring the number of
bytes of code is far too crude).

If it was consdered useful to allow unlimited inlining in Ada, it would
be trivial, and very much within the spirit of the language to add a
configuration pragma Inline_All (implementations of Ada are allowed to
add such configuration pragmas, or it could simply be a compiler switch).

To implement such a switch would be about thirty minutes work in GNAT, but
I doubt it would be found to be of much use in practice, certainly no one
has indicated an interest in such a switch. On the contrary, in large 
programs, people are VERY concerned about compilation dependencies. If
any change to any unit requires recompiling ten million lines of code,
then even with a fast compiler, the impact on development productivity
is worrisome.

Re: OO, C++, and something much better!

[Don Harrison]

Mark A Biggar writes:

:Of course there is nothing that requires 
:that the provided function realy be a less-than function (which is usefull
:as providing a ">" instead reverses the order of the list) but Eiffel has the
:same problem and there is no guarentee that a class derived from COMPARABLE
:hasn't redefined "<" to do something else either.

While it wouldn't be possible in this case, a level of confidence can be 
provided in other situations using Eiffel postconditions.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Ken Garlington]

Bertrand Meyer wrote:
> 
> ISE Eiffel does give the user a degree of parameterization:
> a compilation option specifies the size threshold beyond which
> a routine will not be inlined. This is measured in internal units
> (number of bytecode words), but easy to relate to number of
> instructions. This option provides a way to control space-time
> tradeoffs. In practice, however, most users are happy with the
> default, which inlines small, frequently called routines.

This is the way the Ada compilers we use work as well. Here is an
excerpt from one of the compiler manuals:

Optimize=<argument>, where <argument> is:

minimum  - pragma Inlines are not obeyed.
low      - pragma Inlines are not obeyed.
standard - some inline expansion
time     - aggressive inline expansion
space    - inline expansion only if smaller code results

This is, of course, compiler specific (outside the language standard).
I assume this is the case for Eiffel as well, since you called out a
specific compiler implementation?

> This automatic optimization is crucial because the object-oriented
> style of development, with its emphasis on  abstraction, naturally
> tends to yield many small routines. With ISE Eiffel, you can write the
> software as it should be, not asking yourself all the time "should
> I violate abstraction here and avoid writing a small routine because
> of the effect on performance?". You just leave this kind of concern
> to the compiler. ("Inline" pragmas would be almost worse here, because
> you would have to perform yourself the analysis of what is inlinable
> and what is not. The incrementality problem is particularly nasty:
> change a single line somewhere in a large system, and a routine that was
> inlinable,
> far away in the software text, now becomes  non-inlinable! This
> kind of systematic, exhaustive  work, error-prone when done
> by humans, is what computers are for.)

This is the way we approach our Ada software, as well. We generally use
pragma
Inline for extreme cases, where we know that our choice is smarter than
the
compiler's...

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E3nFFy.C17@research.att.com> ark@research.att.com (Andrew Koenig) writes:

> > However, if I remember correctly, Alex Stepanov had earlier tried to
> > implement a library like the C++ STL in Ada, but was incapable of
> > doing it. This would indicate that the C++ template mechanism is more
> > flexible than the Ada generics.
> 
> What Alex told me about that effort was that he was unable to find
> a single Ada compiler that implemented the standard accurately enough
> to enable him to do what he wanted to do with his library.

 10+ years ago...  I wonder how well then he would have been able to
get a C++ compiler to do anything with any kind template ...  AFATG,
_today's_ C++ compilers have had more than their share of trouble with
these - and with the STL too.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Robb Nebbe]

Bertrand Meyer wrote:
> 
> Robert I. Eachus wrote:
> >
> >
> >       Bertrand Meyer said:
> >
> >    > In my opinion neither Ada (83 or 95) nor C++ has the combination
> >    > of mechanisms making it possible to have the full power of
> >    > generics in an object-oriented language, as present in Eiffel...
> >
> >      And then listed four properties, all of which are in Ada 95!
> 
> I disagree. What Mr. Eachus showed in his message is ways to achieve
> in Ada 95 the effect of the object-oriented mechanisms I described,
> as implemented in Eiffel. And he is correct that one can use Ada 95
> to obtain many of the same goals. (This would not be true, for example,
> of C++ and even less of Java.) But this does not mean the "four
> properties" that I listed are in Ada 95. Anyone who checks my
> message and the Ada 95 language definition will see that.

Actually anyone who checks your message and the Ada language definition
will see that Ada provides direct support for the four properties you
listed but of course it doesn't use the same terminology (constrained
and unconstrained genericity) as Eiffel. 

Robb Nebbe

Re: OO, C++, and something much better!

[Matt Austern]

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


kst@aonix.com (Keith Thompson) writes:

> In <dewar.852652911@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> > Actually, when I talked to Alex, he indicated that there were critical
> > features in Ada 95 that were missing in C and C++ for this kind of
> > work. In particular, he noted that C lacks a general address comparison
> > operation, useful for hashing data structures, whereas Ada does have such
> > an operation (in System.Storage_Elements on type Integer_Address). It is
> > a bit ironic to identify this particular feature as crucial (since most
> > people mistakenly think that C has such a feature and Ada doesn't!)
> 
> Well, sort of.
> 
> It's true that C pointer comparison is undefined unless the pointers being
> compared point into the same object (or one past the end of an array).
> However, any real-world C implementation isn't going to go out of its
> way to make such comparisons invalid.  If pointers "look like" integers
> at the hardware level, pointer comparison is almost certainly going to be
> implemented as integer comparison.  It may be signed or unsigned, but it's
> almost certainly going to be consistent within a given implementation.

Since this article is posted to several different groups, including 
comp.lang.c++, I'd like to point out that the situation in C and in 
C++ is somewhat different.

Keith's description is correct in the case of C.  In C++, though, it's
only part of the story.  Pointer comparison in C++ using the <
operator does work just the way that he says; C++ didn't change the
meaning of the < operator.  However, C++ includes another way of
comparing the magnitude of two values: the standard library function
object less<T>.  

Operator< isn't necessarily a total ordering on pointers, but less<T>
is.  To quote the draft standard (section 20.3.3): "For templates
greater, less, greater_equal, and less_equal, the specializations for
any pointer type yield a total order, even if the built�in operators
<, >, <=, >= do not."

Re: OO, C++, and something much better!

[Marky Mark]

Don Harrison <donh@syd.csa.com.au> wrote in article
<E3rDu6.7AJ@syd.csa.com.au>...
> David Emery writes:
> 
> :>> 	- A completely consistent type structure, in which 
> :>> 	  even basic types such as INTEGER are classes,
> :>> 	  present in the general inheritance structure.
> :>> 	  (In C++ or Java, for example, the basic types
> :>> 	  are completely separate from the class and inheritance

Besides, in a hybrid language like C++ you could always have the best of
both worlds - encapsulating integers as classes or using the intrinsics as
you'd like.

Re: What is wrong with OO ?

[Marky Mark]

All you guys are talking about is inlining some code!!  Is it really worth
this long thread?

Re: What is wrong with OO ?

[Ken Garlington]

Fergus Henderson wrote:

> Hence this control should normally be expressed via
> compiler options, rather than being embedded in the source code.

However, you can't usually specify compiler options in a language
definition.
In practice, many of the capabilities expressed in the Ada language spec
as
pragmas are often available as compiler options, including pragma
Inline.

> 
> --
> Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
> WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
> PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E3q536.31D@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Jon S Anthony writes:
> 
> :This too is in Ada95:
> :
> :generic
> :    type G is new Comparable with private;
> :package Sorted_List is ...
> :
> :Same instantiation constraints as in the Eiffel case...
> 
> Yes. However, I'm not sure whether you lose some of the power of combining 
> genericity with inheritance through Ada's module-type distinction.

I have never seen any example supporting your "unease" - by you or
anyone else.

> genericity in Ada is essentially module-based and inheritance is type-based,
> I suspect you may lose something here.

Presumably you forgot to add "only" to "inheritance is type-based".
But this is just plain false.  Counter-examples are everywhere.


> :> 	- True static typing (with no cast a la C++).
> :
> :Yes, this is in Ada95 too.  
> 
> No. Ada offers type casting in a couple of ways:
> 
>   1) UNCHECKED_CONVERSION and
>   2) Address representation clauses (overlays).

1. This is not "casting"
2. It's irrelevant anyway as these are type system trap doors (outside
   the type system).
3. Ada _is_ statically safer than Eiffel as it avoids broken polymorphism.

> Eiffel, by contrast, has no such thing in the standard language. That isn't 

Irrelevant.

> :In fact it is better in Ada95 since it
> :does not have system validity problems.
> 
> Perhaps not the same kind of problems. But it's dead easy to write 'system
> invalid' Ada which will result in runtime errors.

Only if you _intentionally_ do so - by using UC in a dodgy way.  You
won't get it "by accident".


> For example, by using the value of a parent type where a subrange
> value is required.

Give an example.  This sort of thing will be statically checked.


> :Here is where you actually get some more flexibility with Ada as you
> :can parameterize your generic (either the constrained or unconstrained
> :type) with more than just types.  You can specify complete signatures
> :including operations and/or packages as well.  What's more, these can
> :have constraints on them as well.  
> 
> Yes. However, these kinds of formal parameters are only needed in Ada because
> it distinguishes between module and type.

Nah.  That's irrelevant to why they are there.  They are there, as
Rober Eachus points out, because you have the flexibility of not
_only_ organizing your structures strictly hierarchically.  Or _only_
on type.


> simpler because it is a *pure* OOPL compared to hybrid Ada.

Pure, schmure.  No programming language is "pure" in my estimation.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Robert Dewar]

Keith says

"On the other hand, for Ada 95, RM95-13.7.1(16) says that "Operations that
do not make sense should raise Program_Error".  The AARM (Annotated Ada
Reference Manual) gives the examples of X < Y and conversions between
Integer_Address and Address on a segmented architecture.  (Note also that
it's not necessary to use System.Storage_Elements; relational operators
on type Address are provided in System.)"

Nope, you are reading too much into the RM here. Also reading the AARM
is always a risky business (remember it is just opinion, nothing more :-)

Let's take the case of a segmented architecture. It is common for C
compilers in such environments (Large mode on the 8086) to limit objects
to 64K bytes and to compare ONLY the offset parts of the addresses
so that address comparison onlly works when it is defined to work, and
gives silent junk answers when used between different objects. One neither
expects nor encounters Keith's supposed "reasonable" behavior where this
is likely to work.

If we look at the corresponding Ada case, I cannot see any justification
whatsoever for not properly allowing conversoin of any possible segmented
address to an integer address. Such an operation makes perfect sense in
this environment and is therefore REQUIRED TO BE SUPPORTED! You are only
allowed to raise PE for things that do not make sense. Since this machine
has a well define notion of linear address, it is clear to me that (a) any
implementor on this environment would provide the obvious conversion and
(b) that if they did not, they could not seek refuge in the RM.

Let's actually look at the AARM wording, it says, if we quote it in full,
rather than paraphrase as Keith did:

        16.a   Discussion:  For example, on a segmented architecture, X < Y
        might raise Program_Error if X and Y do not point at the same segment
        (assuming segments are unordered).  Similarly, on a segmented
        architecture, the conversions between Integer_Address and Address
        might not make sense for some values, and so might raise Program_
        Error.

Why this "for some values", that's becuse the conversoin in the opposite
direction from Integer_Address to Address is indeed problematical, and
one might well decide to raise Program_Error for some values in this
direction.

Keith's point that there is a comparison operation on addresses directly
is true, but it is not a good idea to use these operations, since it is
indeed sensible to decide that certain comparisons are not meaningful
when performed directly on segmented addresses.

So, to summarize (and explain Alex's legitimate point), an implementation
of data structures in Ada which converts Address values to Integer_Address
and then compares the Integer_Address values will work on all likely
architectures including segmented architectures, and is from a formal
point of view defined to either work as expected or raise Program_Error.

By contrast, if you compare addresses in a corresponding C program, the
address comparison will in fact produce meaningless results silently
in the case of segmented architectures, and from a formal point of view
nothing at all can be said about the semantics of the comparison operation.

*quite* a difference, and enough for Alex to decide quite reasonably, that
a standard implementation of libraries for C++ (which has the same semantics
as C here) could not legitimately use these undefined comparison operations,
whereas in the Ada 95 case, they could reasonably used. 

Yes, in the Ada 95 case, one could perhaps imagine a machine in which
there was no sensible linearization of addresses, but I certainly don't
know of any such machine, so such considerations are of a purely
theoretical nature.

In the C case, many programmers have been burned by the "unexpected"
behavior of address comparisons on a segmented machine. For example,
if you have

    int p [10];

then ((p-1) < p) can be false, so a loop that works by pointing one before
the array to initialize can fail. equally if you do something like

   (x = p; x < &p[10]; p += 3)

you can find you have an infinite loop, all quite in accordance with the
C semantics, although somewhat surprising.

Re: OO, C++, and something much better!

[Roy Phillips]

Don Harrison wrote:
> Mark A Biggar writes:
> 
> :Of course there is nothing that requires
> :that the provided function realy be a less-than function (which is usefull
> :as providing a ">" instead reverses the order of the list) but Eiffel has the
> :same problem and there is no guarentee that a class derived from COMPARABLE
> :hasn't redefined "<" to do something else either.
> 
> While it wouldn't be possible in this case, a level of confidence can be
> provided in other situations using Eiffel postconditions.

   The problem with this approach is not really the deliberate
substitution
of the ">" with a "<": as stated, this can be a useful technique (I'd
hate
to have to maintain that code, all the same!).  More problematical is
the
accidental substitution, for example of an operation with same name but
an
entirely differant meaning (for example, the terms 'interest' (financial
domain) and 'interest' (marketing domain)) - blame the English language
if
you will, but without semantic specification (i.e., Eiffel assertions)
the
whole thing is a can of worms.

- Roy

Re: What is wrong with OO ?

[Fergus Henderson]

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

>There are times when you want optimizations yet you want to avoid
>cross-module optimizations, but those should be exceptions;
>automatic cross-module inlining ought to be the norm.
>
>  I think not. You can only do cross-module inlining if every compilation
>  potentially recompiles code for the entire application. This seems out
>  of the question in large applications.

During the edit-compile-debug cycle, you want rapid turn-around, and so
you don't want optimizations (except for those that actually speed up
the turn-around time).

Then when you're doing integration testing, when you can afford to
compile with optimization, you can usually also afford cross-module
inlining.

>  It seems to me here that the Ada approach is just right. Fergus, if you
>  are aware of the Ada approach, what would you change?

The Ada language design is OK; I consider having "private" sections
in package specifications to be a fairly low-level, implementation-oriented,
and inelegant approach, but I understand its advantages.

What I would change is the implementations: specifically, I'd like to
see a cross module inlining option for GNAT.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

Richie Bielak <richieb@calfp.com> writes:

>Optimizations that require global analysis of all the classes
>of a program at compile time do not work if we need dynamic loading
>of classes at runtime, because adding a new class to a running system
>may invalidate optimizer's assumptions.

True, but there are plenty of cross-module optimizations (such as
cross-module inlining) that require the compiler to use information
from more than one module but don't require analysis of *all* parts of
a program.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Keith Thompson]

In <dewar.852652911@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Actually, when I talked to Alex, he indicated that there were critical
> features in Ada 95 that were missing in C and C++ for this kind of
> work. In particular, he noted that C lacks a general address comparison
> operation, useful for hashing data structures, whereas Ada does have such
> an operation (in System.Storage_Elements on type Integer_Address). It is
> a bit ironic to identify this particular feature as crucial (since most
> people mistakenly think that C has such a feature and Ada doesn't!)

Well, sort of.

It's true that C pointer comparison is undefined unless the pointers being
compared point into the same object (or one past the end of an array).
However, any real-world C implementation isn't going to go out of its
way to make such comparisons invalid.  If pointers "look like" integers
at the hardware level, pointer comparison is almost certainly going to be
implemented as integer comparison.  It may be signed or unsigned, but it's
almost certainly going to be consistent within a given implementation.

On the other hand, for Ada 95, RM95-13.7.1(16) says that "Operations that
do not make sense should raise Program_Error".  The AARM (Annotated Ada
Reference Manual) gives the examples of X < Y and conversions between
Integer_Address and Address on a segmented architecture.  (Note also that
it's not necessary to use System.Storage_Elements; relational operators
on type Address are provided in System.)

The use of the word "should" means that an Ada implementation is not
*required* to raise Program_Error.  Thus it's permissible for address
comparisons to behave inconsistently.

To summarize, both C and Ada provide relational operations on addresses.
Both require such operations to be well-behaved only in certain cases,
and leave them more or less undefined in other cases.  Both are defined
in such a way that any reasonable real-world implementation will almost
certainly implement address comparison in the obvious manner, which
should be useful for hashing data structures.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: What is wrong with OO ?

[Jay Martin]

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

>Jay, in typical fulminating mode says

> "It seems to me need for "pragma inline" and "inline" is/was social.
> It came from compiler writers continually slacking off since the 60's
> and not implementing inlining."

>nonsense, all decent compilers implement inlining today, it is a more
>vital optimization than ever because of icache considerations (particularly
>in direct addressed caches).

Gee I don't remember fully general inter-unit automatic/intellegent
global analysis procedure inlining in the early 80's when "pragma
inline" and "C++ inline" features were created.  Maybe I just used
lame compilers.

But then I remembered I was just parroting Stroustrup: "I had had poor
experiences with languages that left the job of inlining to compilers
"because clearly the compiler knows best" The compiler only knows best
when if it has been programmed to inline and it has a notion of
time/space optimization that agrees with mine.  My experience with
other languages was that only "the next release" would actually
inline, and it would do so according to an internal logic that a
programmer couldn't effectively control."  (Design Evolution C++ pg
33)


>In a large project it is essential not to accidentally create interunit
>dependences so that a small change to one unit causes millions of lines
>to need to be recompiled.

>The problem is that you definitely do NOT want the compiler rushing off
>and creating unlimited body dependencies (think interunit dependencies
>if you don't want to think Ada specifically) by doing automatic interunit
>inlining.

>Still some interunit inlining is highly desirable especially with
>heavy layering of abstractions. But you want to give the programmer
>some control, to avoid the problem of inter-unit dependencies running
>amok!

Here's an ignorant question: Why would inlining or extensive
optimations be turned on for frequent builds of a quickly changing
large software project.  It seems testing of optimized builds could be
done less frequently and in parallel.  I mean if you don't inline
quickly changing source by using compiler controls, then you don't get
these sort of dependencies.  I must be missing something here.

Here is an even more ignorant question: Why is compilation time still
a driving factor? (excluding hardcore optimizations) Obviously it
still is as I watched large systems compile lately.  But wait, wasn't
Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC
faster than VC++ on my P5-100.  For fun I compiled old programs with
vintage a Turbo Pascal Compiler and it seems to compile these suckers
instantanously!  It doesn't seem to me that current system build times
are keeping pace with processor speed improvements.  I mean shouldn't
a Pentium Pro 200 be compiling like a million lines a second or
something?  If its not, then how about the eventual P7-600Mhz or the
P8-2000Mhz-16(processors per chip).  I mean I can write N lines of
code a day and that is not going to change much, but computer speeds
are increasing exponentially.

Jay

Re: What is wrong with OO ?

[Simon Willcocks]

In article <dewar.852833957@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) says:

>Simon said

>"[...]
>I think that even in [Ada] inlining could be done by a suitable linker,
>provided the compiler could mark parts of object code as suitable for inlining.
>The linker could insert the relevant code in place of the call statement,
>rather than just setting the location to be called."

>[...]

>Inlining is MUCH more than just sticking in the code at the point of call
>and cannot be done at all by a stupid linker. The whole point of inlining
>is that you optimize the code that is inserted, minimally by increasing
>scheduling opportunities, but in the presence of global optimization, knowing
>what the body of a procedure does and does not do can buy a great deal. The
>elimination of the call itself is small stuff compared to the other gains.

I agree it can't be done with a stupid linker, but I was just pointing out
that inlining can be done in Ada without affecting the programmer.

You just have to leave the jobs of optimisation and (machine) code generation
to a later stage.

Simon

Re: What is wrong with OO ?

[Robert Dewar]

Fergus said

"What I would change is the implementations: specifically, I'd like to
see a cross module inlining option for GNAT."

If you mean that you want every possible opportunity for cross-module
inlining to be attempted, that is easily achieved, just write a little
tool that generates pragma Inline's for all visible subprograms in all
package specs. Then turn on the usual -O2 -gnatn switches.

It certainly would be easy to implement a compiler option to force this
treatment, but so far none of our customers has suggested this as a
requirement.

Re: What is wrong with OO ?

[Bart Samwel]

Robert wrote:

> "You shouldn't bother programmers with inlining. Inlining can be done
> automatically by the compiler."
> 
> I don't see this is possible across modules without violating the
> integrity of separation of specs and implementations.

In C++, it's not possible, that's true. This is because C++ uses a
modular model that completely separates different parts of the system.
When compiling one module, the compiler doesn't know anything about the
other modules other than that they are there and their specifications.
This makes automatic inlining very hard, because the implementation is
just _not available_ to the compiler!

The problem here is that C++ honours the principle of modularity, which
is a Good Thing, but fails to recognize the fact that many modules
form a System as a whole. This results in C++ not doing any global
analysis of programs, so that it cannot automatically detect functions
which need dynamic binding ("virtual"), it cannot choose to inline
functions which were not designated by their writer to be inlined,
and it cannot perform optimizations that cross module boundaries (these
optimizations would be valid only within the system they were performed
on, so that when you use some of the modules in another system, other
optimizations might be chosen).

In languages like Eiffel, which provide for global analysis of the
system, automatic inlining is possible. It is even possible to inline
one call to a function (for instance, within a loop), and not to inline
another call in the same function, only a few lines later.

As for separation of specs and implementations: C++ violates this too,
by forcing inline functions to be defined in the class INTERFACE
specification. With global analysis, you can still keep this separate,
and even better, because you don't have to put the inline function in
the interface: the global analysis has access to the implementation
anyway, so you don't need that anymore.

The point I have here is that the fact that the implementation is
visible to the compiler does not directly imply it should visible to
the programmer.

   Bart

Re: What is wrong with OO ?

[Fergus Henderson]

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

>If it was consdered useful to allow unlimited inlining in Ada, it would
>be trivial, and very much within the spirit of the language to add a
>configuration pragma Inline_All (implementations of Ada are allowed to
>add such configuration pragmas, or it could simply be a compiler switch).
>
>To implement such a switch would be about thirty minutes work in GNAT, but
>I doubt it would be found to be of much use in practice, certainly no one
>has indicated an interest in such a switch.

Let me hereby indicate interest in such a switch!
I think it would be quite useful in practice.

>On the contrary, in large 
>programs, people are VERY concerned about compilation dependencies. If
>any change to any unit requires recompiling ten million lines of code,
>then even with a fast compiler, the impact on development productivity
>is worrisome.

My (non-Ada) experience is that many programs consist of between a few
thousand and a few hundred thousand lines of code, and that often I am
interested in building the fastest possible executable and not
particularly concerned with compilation speed (since I'm building it in
the background) and entirely unconcerned with recompilation speed
(since I am just doing `make && make install && make clean').

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Robert Dewar]

Simon says

"I agree it can't be done with a stupid linker, but I was just pointing out
that inlining can be done in Ada without affecting the programmer.

You just have to leave the jobs of optimisation and (machine) code generation
to a later stage."


Let's look at that carefully. The second paragaph implies that the link
step redoes optimization and compilations for the entire program. Even
with fast machines and fast compilers, I think that this is definitely
something that would "affect the programmer".

As I have pointed out before, it is of course a trivial adjustment
to an Ada compiler to make it automatically check for inlining everywhere
(it is in fact a one line change to the GNAT compiler). But it is not
clear that this is a useful option in practice, although maybe this
discussion will suddenly make one of our customers suggest it :-)

Re: OO, C++, and something much better!

[Bart Samwel]

Robert Dewar wrote:

> values of one type to values of another type. It is that these
> operations can generate abnormal values.

I just thought of a way to implement safe type (read: class) casting
in Eiffel:

Use the Attempted Assignment operator ?= to try to assign, as in:

   local
      object1 : CLASS1
      object2 : CLASS2

   do
      !!object1.make (whatever)
      object2 ?= object1         -- this is what I mean
      if object2 /= Void then
        ...
   end

This operation makes object2 a reference to object1, but belonging to
class CLASS2, but only if, after conversion, object2 satisfies the
class invariant of CLASS2. Otherwise, object2 will be Void.

Oh, by the way, this is meant to be interpreted as humour, not as
a serious proposal. ;-)

Re: What is wrong with OO ?

[Robert Dewar]

Fergus said

"library?).  Hence this control should normally be expressed via
compiler options, rather than being embedded in the source code."

Are you using GNAT? I would guess not, because you seem to assume that
is not the case, but in fact inlining is controlled by compiler options
in GNAT. The pragma inlines merely enable the establishment of interunit
dependences. The extent to which inlining takes place depends on 
compiler switches -- see the GNAT documentation for details.
n

Re: What is wrong with OO ?

[Jay Martin]

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

>Jay, in typical fulminating mode says

> "It seems to me need for "pragma inline" and "inline" is/was social.
> It came from compiler writers continually slacking off since the 60's
> and not implementing inlining."

>nonsense, all decent compilers implement inlining today, it is a more
>vital optimization than ever because of icache considerations (particularly
>in direct addressed caches).

An example of inlining getting the shaft by compiler writers is G++
which does not support the normal inlining of templated class methods.
There is a "G++ only" workaround (source code hack) in the latest
compiler but again you have to wait for the real fix until "the next
release".

Re: What is wrong with OO ?

[Michael Malak]

In article <32D64931.167E@wi.leidenuniv.nl>,
Bart Samwel  <bsamwel@wi.leidenuniv.nl> wrote:
>
>In C++, it's not possible, that's true. This is because C++ uses a
>modular model that completely separates different parts of the system.
>When compiling one module, the compiler doesn't know anything about the
>other modules other than that they are there and their specifications.
>This makes automatic inlining very hard, because the implementation is
>just _not available_ to the compiler!

Yet, Microsoft Visual C++ does exactly that.  In fact, it has since
version 1.5 (early 1994).  MSVC++ performs "auto-inlining" (Microsoft's
terminology) by compiling all the source modules all at once.  That's
why it exhibits the curious behavior during compilation where it says
"Compiling...", then lists the modules one by one, then says
"Generating code...", then lists the modules all over again.

-- 
Michael Malak         Magic forwarding e-mail address:
Washington, DC        malak@acm.org

Re: What is wrong with OO ?

[Robert Dewar]

Fergus said, responding to me

">To implement such a switch would be about thirty minutes work in GNAT, but
>I doubt it would be found to be of much use in practice, certainly no one
>has indicated an interest in such a switch.

Let me hereby indicate interest in such a switch!
I think it would be quite useful in practice."


Well of course people are interested if it costs them nothing to be
interested :-)

It will be interesting to see if any of our customers picks up on this
as something that might be useful to them. Right now, we have lots of
things to do that definitely *are* of interest to our customers, so
these certainly have higher priority.

Actually, not many people in practice are even using -gnatn to activate
interunit inlining (which works fine, and we use it in the compiler itself).
Relatively few applications are at the level where they are worrying about
performance that much, but of course for those that do, it helps a lot.

Also if you have efective inlining, you tend to design with this
expectation. The GNAT compiler is certainly written this way. So far,
all released compilers have had full debugging assertions turned on,
and no inlining, but the compiler we recently shipped for the second
phase of the DEC field test for the VMS Alpha port is the fast compiler
with assertions off, and full inlining, and it does make quite a
difference in speed.

I don't know if the 3.09 releases will be the fast compiler or not, we have
not decided yet ...

Robert Dewar
Ada Core Technologies

Re: OO, C++, and something much better!

[Robert Dewar]

Bart says

"This operation makes object2 a reference to object1, but belonging to
class CLASS2, but only if, after conversion, object2 satisfies the
class invariant of CLASS2. Otherwise, object2 will be Void.

Oh, by the way, this is meant to be interpreted as humour, not as
a serious proposal. ;-)"


If we are doing design at this level, we should make it clear that when
you say "the class invariant of CLASS2", you also include all the 
unstated invariants that are in the mind of the programmer only :-)

Re: What is wrong with OO ?

[Robert Dewar]

Bart said

"In languages like Eiffel, which provide for global analysis of the
system, automatic inlining is possible. It is even possible to inline
one call to a function (for instance, within a loop), and not to inline
another call in the same function, only a few lines later."

Such discrimination is typical of modern compiler technology, and has 
nothing to do with whether the "language provide[s] for global analysis
of the system", whatever that might mean. Certainly any language allows
an implementation in which you delay some or all of code generation until
link time (for example, the old MIPS C compilers used to do global
register allocation at link time).

Whether you want to do this global recompilation, with dynamic adjustment
of inlining depends on the size of the system, the speed of the compiler,
and the extent to which you worry about things not working any more if
they have been recompiled in a different inlining environment.

Re: What is wrong with OO ?

[Pieter Schoenmakers]

In article <5b4f6l$aeq@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

   Richie Bielak <richieb@calfp.com> writes:

   >Optimizations that require global analysis of all the classes
   >of a program at compile time do not work if we need dynamic loading
   >of classes at runtime, because adding a new class to a running system
   >may invalidate optimizer's assumptions.

   True, but there are plenty of cross-module optimizations (such as
   cross-module inlining) that require the compiler to use information
   from more than one module but don't require analysis of *all* parts of
   a program.

With any kind of static binding (and inlining is the summum in static
binding), the possibilities of dynamically loaded code are limited.  What
to do if a dynamically loaded class redefines some feature causing that
feature to no longer be statically bindable?  Recompile the whole
executable?  --Tiggr

Re: OO, C++, and something much better!

[Ken Garlington]

Robert Dewar wrote:
> 
> If you like, consider Ada *minus* these two features as the interesting
> language to be analyzed. Then understand that in real life programs can
> break the bounds of this analysis to the extent they need to.

I think the other interestings aspects of the Ada approach are (1) the
language
makes it clear when something potentially nasty is being done -- both in
terms
of the language definition, and in terms of the syntax making the
operation
clear in the source code -- and (2) there is at least some attempt,
through
features such as 'Valid, to try to mitigate these effects where
possible. This
won't necessarily help with formal analysis, but it is useful in "real
life"
programs.



--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: What is wrong with OO ?

[Bart Samwel]

Michael Malak wrote:
> Yet, Microsoft Visual C++ does exactly that.  In fact, it has since
> version 1.5 (early 1994).  MSVC++ performs "auto-inlining"
> (Microsoft's terminology) by compiling all the source modules all at
> once.  That's why it exhibits the curious behavior during compilation
> where it says "Compiling...", then lists the modules one by one, then
> says "Generating code...", then lists the modules all over again.

This is a pro for VC++. However, most compilers still use the old make-
based model, especially on Unix, where compilers must comply to this
model because almost all unix software not distributed as binaries is
distributed using make projects. That VC++ does do automatic inlining
does not imply that my argument is invalid, only that there are
exceptions to the general situation I described. And it still is true
that C++ doesn't exactly invite compiler writers to implement automatic
inlining.

Re: What is wrong with OO ?

[Joe Buck]

jmartin@cs.ucla.edu (Jay Martin) writes:
>An example of inlining getting the shaft by compiler writers is G++
>which does not support the normal inlining of templated class methods.

Not quite true: only the first occurrence of a template function, the
one that causes the expansion of the template cannot be inlined.  This
is a problem with the design of the template expansion code and long
recognized by the maintainers as a bug.

This problem is fixed in the 2.8.0 snapshots, which has a new template
implementation.

>There is a "G++ only" workaround (source code hack) in the latest
>compiler

No, the workaround (explicit template expansion) is to write standard
(draft ANSI/ISO standard) code to explicitly expand the template; all
occurrences will then be inlined.





-- 
-- Joe Buck	http://www.synopsys.com/pubs/research/people/jbuck.html

Help stamp out Internet spam: see http://www.vix.com/spam/

Re: OO, C++, and something much better!

[Norman H. Cohen]

(This note, concerned only with a esoteric nit about Ada, is posted only
to comp.lang.ada.)

Robert Dewar wrote:

> Note that it is not actually the unchecked conversion that is nasty, since
> the fundamental conversion can be modeled as simply a random mapping between
> values of one type to values of another type. It is that these operations
> can generate abnormal values.
> 
> This may still not be a problem, given that uninitialized values can also
> be abnormal, thus:
> 
>   a := nasty_unchecked_conversion (b);
> 
> is no worse that not assigning to a at all if a is uninitialized.

No, uninitialized variables may be "invalid", but not "abnormal". 
Abnormal is worse than invalid.  Even uninitialized objects of a
composite type might satsify certain conditions (e.g. gaps between
record components set to zero, dope vectors properly initialized, etc.)
that an abnormal value violates.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Robert I. Eachus]

In article <32D51BC8.41C67EA6@escmail.orl.lmco.com> Ted Dennison <dennison@escmail.orl.lmco.com> writes:

  > Does that mean that they ALSO started thinking about the revision
  > again in 1993, even though the Ada 95 effort was well underway?
  > ;-)

    I wouldn't have responded, but it is a funny story.

    First, there was a decision by the Ada Board in 1988 to recommend
revision of the Ada standard, and for the next revision to be the last
to use the government funded contractor approach.  I hope an
electronic copy of that report is around somewhere, but if not I may
still have it on a (Macintosh) disk.

    However, the ISO standard was not approved until 1987 due to
procedural and other problems--even though the ISO standard was a one
page document pointing to the ANSI and French standards.  (Alsys did
the French translation with a lot of involvement from Jean and Mike,
so it was very faithful to the original.)

    So at Zandvoort, after a long discussion at the WG9 meeting of
slipping the schedule for Ada 9X six months, with detailed debate on
dates for committee drafts, ISO standards processes, etc. Bob Mathis
announced during the "new business" part of the meeting that ISO had
asked him as WG9 convener if we were planning to revise the Ada 87
standard.

    And finally, the real requirement is to revisit every standard at
least every five years to take action on it: keep it, revise it or
abandon it.  After 10 years most standards organizations automatically
abandon a standard if no action has been taken.  There was a lot of
discussion about whether to take explicit action on the ANSI Ada 83,
or to let it disappear. (For most purposes it was technically already
superceded by the identical ISO standard, which wouldn't expire until
1997.)  This was resolved by the Memorandum of Agreement between the
DoD, ANSI and ISO.  All three basically agreed to approve Ada 9X
together, and that Ada 83/87 would be in force until then.

    Since Ada 95 was actually approved in January 1995, we have until
December 2005 to amend it or whatever.  At this point I hope we can
have a nice little fold in the fixes to minor gotchas revision, and
leave any major revision for Ada 10X.  (If you want to think of it as
a fix the annexes revision, fine.  Most of the problems the ARG has
discussed so far are either chapter 13 issues or related to one or
another annexes.  The core language apparently got lots of attention
during the revision process, but the annexes were trying to track a
moving target.)



--

					Robert I. Eachus

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

Re: What is wrong with OO ?

[Robert I. Eachus]

In article <32D53473.4DAA423A@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

  > The ISE Eiffel compiler performs inlining completely automatically.
  > There is no "pragma inline" or comparable programmer intervention,
  > since it is not the programmer's job to worry about whether a routine
  > is inlinable or not. This is a job for a compiler.

   For some things this works, but Bertrand then says:

  > (In addition, for an object-oriented language, inlining is only
  > possible for a routine that is never subject to dynamic binding.
  > This requires extensive analysis of the software. If the
  > programmer requests inlining but it is semantically wrong, the
  > compiler should ignore the request. But then if the compiler is
  > capable of doing this analysis it should take care of the inlining
  > too, without bothering the programmer!)

  This is where the problem arises.  If you compile everyting in one
big batch, this is possible.  But if you don't then the user needs to
be able to say:

  "I don't expect any later subclass to override this method.  If I do
that (or some other programmer does), I'm willing to take a big
recompilation hit."

  Add to this the fact that a lot of apparently dynamic links in Ada
are actually resolvable at compile or link time, and you want the
ability to mark methods this way.  

  For instance, you can have a call on a method of a specific type
which dispatches to an inherited method which then makes many other
calls on methods of the type.  If the outer call is inlined, then all
the inner calls dispatch statically as well.  Often these inner calls
are to placeholder routines which contain no code, or to routines
which are only a few machine instructions in most static cases.

  > ISE Eiffel does give the user a degree of parameterization:
  > a compilation option specifies the size threshold beyond which
  > a routine will not be inlined. This is measured in internal units
  > (number of bytecode words), but easy to relate to number of
  > instructions. This option provides a way to control space-time
  > tradeoffs. In practice, however, most users are happy with the
  > default, which inlines small, frequently called routines.

   Ah, most Ada compilers do this as well.  But occasionally there is
a big payoff from inlining an otherwise large routine.  One case is
that you know that it is only called in one place.  Another is
mentioned above--inlining a "big" routine may result in further
automatic optimizations so that the final code is very small.

  > This automatic optimization is crucial because the object-oriented
  > style of development, with its emphasis on  abstraction, naturally
  > tends to yield many small routines. With ISE Eiffel, you can write the
  > software as it should be, not asking yourself all the time "should
  > I violate abstraction here and avoid writing a small routine because
  > of the effect on performance?"...

  Same in Ada.

  > You just leave this kind of concern to the compiler. ("Inline"
  > pragmas would be almost worse here, because you would have to
  > perform yourself the analysis of what is inlinable and what is
  > not. The incrementality problem is particularly nasty: change a
  > single line somewhere in a large system, and a routine that was
  > inlinable, far away in the software text, now becomes
  > non-inlinable! This kind of systematic, exhaustive work,
  > error-prone when done by humans, is what computers are for.)

  This is why the Ada pragma is ADVICE.  If the compiler can no longer
follow the advice, it has to go back and recompile things.
(Technically, the compiler can just tell the user which items are
obsolete, but all Ada compilers I'm aware of do this automagically or
through a make facility.)  The important thing is that pragma INLINE
can affect speed, executable size and/or compilation time, but it can
never affect correctness.

  > I also think that the Eiffel view of "separation of specs and
  > implementations" is more sophisticated than Ada's one (which I
  > assume is the one Robert Dewar has in mind), but that will be the
  > topic for another debate...

    If a classical debate, one well worth following.  But please don't
frame it that way.  It is not a feature war.  Both Eiffel and Ada had
models in mind when the languages were developed, but the set of
models supported in each case is richer, and overlapping.  AFAIK, the
"pure" Eiffel and Ada models are supported in both languages.
However, there are design models that work in Ada but not Eiffel and
vice-versa.  Also there are features in both languages that make
impure versions of their design models much easier to work with.

    For example, in the previous discussion, we have seen a case where
the user wants to limit a generic to one with comparisions.  Ada can
follow the Eiffel model:

    generic
      type Foo is new Comparable with private;
      ...

    But more normally in Ada this will be done as:

    generic
      type Foo (<>) is private;
      with function ">" (L,R: Foo) return Boolean;
      ...

    As I pointed out, this is because the Ada type model sees classes
as sets of types all having a specific set of operations.  Therefore
it is more normal (in Ada) to specify a class by specifying the
required operations.  The fact that a class is hierarchical is
expressed by/visible because of the available type conversion
operations.  Two types are members of the the same class if an object
of one type can be explicitly converted to an object of the other, or
both can be converted to a third type.  (To make that "if only if" is
complex since I can't specify the third type to class mapping in less
than a page. For example all discrete types can be converted to
_universal_integer_ by 'Pos.)  In a hierarchical class all objects can
be converted to / passed as a parameter of the type at the top.

    In Eiffel, even though the actual concept of class is very
similar, the model is explicitly hierarchical.  (You can implement the
Ada number class in Eiffel by adding explicit conversions which break
the hierarchy.)  As I said, it is not that it is not possible in
Eiffel, it is more that it is not done.

--

					Robert I. Eachus

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

Re: OO, C++, and something much better!

[Robert Dewar]

oops, my last example of surprising C code

   (x = p; x < &p[10]; p += 3)

should of course be

   (x = p; x < &p[10]; x += 3)

Re: OO, C++, and something much better!

[Norman H. Cohen]

Andrew Koenig wrote:

> What Alex told me about that effort was that he was unable to find
> a single Ada compiler that implemented the standard accurately enough
> to enable him to do what he wanted to do with his library.

Alex Stepanov's Ada project took place nine years ago.  A lot of early
Ada compilers had trouble with intricate uses of generics, particularly
with such things as generics nested within generics.  However, most Ada
compilers have been much more reliable than that for many years now.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32D536C6.64880EEB@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

> Robert I. Eachus wrote:
> > 
> > 
> >       Bertrand Meyer said:
> > 
> >    > In my opinion neither Ada (83 or 95) nor C++ has the combination
> >    > of mechanisms making it possible to have the full power of
> >    > generics in an object-oriented language, as present in Eiffel...
> > 
> >      And then listed four properties, all of which are in Ada 95!
> 
> I disagree. What Mr. Eachus showed in his message is ways to achieve
> in Ada 95 the effect of the object-oriented mechanisms I described,
> as implemented in Eiffel. And he is correct that one can use Ada 95
> to obtain many of the same goals. (This would not be true, for example,
> of C++ and even less of Java.) But this does not mean the "four
> properties" that I listed are in Ada 95. Anyone who checks my
> message and the Ada 95 language definition will see that.

I am willing to buy this - more or less - as I noted in my original
reply.  But, your original post (with the relevant part right up there
just above) does not SAY this.  It certainly _reads_ like you are
saying that Ada 95 has none of these properties - and that is just
plain outright indisputably FALSE.  In fact, the _only_ one that it
does not have at the level you suggest is the so called "completely
consistent type system" which seems to really mean "an Eiffel style
type system".  The other three are there and actually are rather
better done in Ada, IMO, than the equivalent Eiffel.


> At some point, of course, one runs into matters of taste. I will
> again contend, however, that a rational, systematic analysis of
> O-O principles and how they combine with genericity, information hiding
> and other software engineering concerns almost inevitably lead to the
> Eiffel mechanism

Well, the big problem here is that there are so many "loaded" terms in
this without any universally accepted definitions and certainly no
universally accepted _value_ judgements and absolutely no objective
series of studies supporting anything one way or the other, that it
just doesn't say anything more than: "In my reasoned view, Eiffel is
better, and I have listed various reasons for my belief."

Fair enough.  But having done the above so called "rational,
systematic analysis" of so called "O-O principles", I've arrived at
rather a different conclusion and have listed reasons for this in the
past as well.  In particular, MI useage, in my perusals, is nearly
universally conceptually confused.  It is not a very good way of
"modeling" things.  It _can_ be a decent way of "code reuse" - but it
is not worth the conceptual price given readily available
alternatives.

Shrug.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Robert Dewar]

Marky said

"All you guys are talking about is inlining some code!!  Is it really worth
this long thread?"

Inlining is an important optimization, and becoming more so for two reasons.

  1. In pipelined machines, especially those with small primary direct
     addressed caches, inlining calls in a loop can avoid nasty effects
     due to cache address clashes.

  2. layered development, particularly the style associated with layered
     abstract data structures or objects, can result in lots of trivial
     subprograms being called, which can severely affect performance, again
     because of I-cache effects, this gets worse in modern machines.

Re: What is wrong with OO ?

[Fergus Henderson]

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

>... some interunit inlining is highly desirable especially with
>heavy layering of abstractions.

I'm glad you agree.

>But you want to give the programmer
>some control, to avoid the problem of inter-unit dependencies running
>amok!

Yes, you should give the programmer some control.  But the degree to
which inter-unit dependencies and recompilation speed are important
varies considerably between different situations, even for the same
source code (e.g. How fast is the computer you are compiling it on? 
Do you plan to modify the code and recompile, or are you just doing a
build and install?  Are you building an executable or a shared
library?).  Hence this control should normally be expressed via
compiler options, rather than being embedded in the source code.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Jay Martin]

jbuck@synopsys.com (Joe Buck) writes:

>jmartin@cs.ucla.edu (Jay Martin) writes:
>>An example of inlining getting the shaft by compiler writers is G++
>>which does not support the normal inlining of templated class methods.

>Not quite true: only the first occurrence of a template function, the
>one that causes the expansion of the template cannot be inlined.  This
>is a problem with the design of the template expansion code and long
>recognized by the maintainers as a bug.

>This problem is fixed in the 2.8.0 snapshots, which has a new template
>implementation.

As I said the "next release".

>>There is a "G++ only" workaround (source code hack) in the latest
>>compiler

>No, the workaround (explicit template expansion) is to write standard
>(draft ANSI/ISO standard) code to explicitly expand the template; all
>occurrences will then be inlined.

Well gee if I have to insert "explicit template expansion" lines not
needed by any other C++ compiler or the standard that sounds like "G++
only source code hack" to me.  Of course, since I might also use an
older C++ compiler on my code that doesn't yet recognize expansions,
then I am going to have to put "#ifdefs" around these expansions.
Yee Haw!

This "bug" (lack of inlining) has been in G++ for YEARS, it just shows
how much priority (Zero) that so many programmers give to basic data
abstraction (you can't efficiency implement abstract data-structures
like "smart pointers" in C++ without inlining).

Jay

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "bertrand" == Bertrand Meyer <bertrand@eiffel.com> writes:

bertrand> The ISE Eiffel compiler performs inlining completely
bertrand> automatically.  There is no "pragma inline" or comparable
bertrand> programmer intervention, since it is not the programmer's job
bertrand> to worry about whether a routine is inlinable or not. This is
bertrand> a job for a compiler.

It seems contrary to reasonabless: there are many contexts where
inlining is not necessary and others in which it is important, *even for
the same procedure*. Thus there is (usually) a space/time tradeoff, but
*at each call site*. It sounds astonishing to me an argument that the
compiler should try to second guess or infer space/time tradeoffs
(except perhaps in the simplest cases), in addition to doing its job of
compiling valid translations of a source.

bertrand> (In addition, for an object-oriented language, inlining is
bertrand> only possible for a routine that is never subject to dynamic
bertrand> binding.

This is not quite the whole story. It all depends on call sites: at some
call sites a procedure can well be inlined, if at those call sites the
procedure implementation invoked can be identified statically. If it is
*also* invoked at call sites where this cannot be done, then an
out-of-line version must also be generated.

A lot of people forget that overloading resolution *and* procedure
implementation call/inlining are crucially dependent, both as to
validity and desirability, on specific call sites. Call sites that are
part of inner loops tend to make inlining more desirable (there are
often opportunity for code reorganizations of various sorts), for
example. Static resolution and perhaps inlining can also be possible at
some call sites but not others.

bertrand> This requires extensive analysis of the software. If the
bertrand> programmer requests inlining but it is semantically wrong, the
bertrand> compiler should ignore the request. But then if the compiler
bertrand> is capable of doing this analysis it should take care of the
bertrand> inlining too, without bothering the programmer!)

Here is a confusion two very different concepts: whether inlining is
*useful* and whether it is *possible* (valid). It may be a job for the
compiler to check whether inlining a procedure at a given call site is
*possible*, as claimed here; but it may require a lot harder work for
the compiler to determine whether that inlining is also *useful*. A
programmer's suggestion as to the *usefulness* of inlining a procedure
at a given call site (or all call sites, much more coarsely and rather
less desirably) is not replaceable by the a compiler check on the
*possibility* of inlining it.

Ideally a compiler would use profiling feedback to evaluate whether it
is worth inlining a procedure at a given call site, by running the
program with an without (this check ought to be done for each procedure
at each call site for which is is possible, and every combination
thereof :->).

Cruder hints may be used:

bertrand> ISE Eiffel does give the user a degree of parameterization: a
bertrand> compilation option specifies the size threshold beyond which a
bertrand> routine will not be inlined. This is measured in internal
bertrand> units (number of bytecode words), but easy to relate to number
bertrand> of instructions. This option provides a way to control
bertrand> space-time tradeoffs.

but, just like the 'inline' keyword of ``C++'', it does not quite
recognize that hinting for inlining a procedure at *all* call sites is
not quite as useful as hinting for it to be inlined at particular call
sites. However probably simple compiler heuristics can be useful, like:

bertrand> In practice, however, most users are happy with the default,
bertrand> which inlines small, frequently called routines.

As to this some Ada compilers do allow selective inlining at call site,
or at least at call sites thru a region of code only (if I remember
well).

bertrand> This automatic optimization is crucial because the
bertrand> object-oriented style of development, with its emphasis on
bertrand> abstraction, naturally tends to yield many small
bertrand> routines.

Where have I heard some of those word already? Ah, yes, those are the
words used by Ken Thomson and Dennis Ritchie about the C procedure
calling conventions. Then people instead started using '#define'. :-)

bertrand> With ISE Eiffel, you can write the software as it should be,
bertrand> not asking yourself all the time "should I violate abstraction
bertrand> here and avoid writing a small routine because of the effect
bertrand> on performance?". You just leave this kind of concern to the
bertrand> compiler. ("Inline" pragmas would be almost worse here,
bertrand> because you would have to perform yourself the analysis of
bertrand> what is inlinable and what is not. The incrementality problem
bertrand> is particularly nasty: change a single line somewhere in a
bertrand> large system, and a routine that was inlinable, far away in
bertrand> the software text, now becomes non-inlinable! This kind of
bertrand> systematic, exhaustive work, error-prone when done by humans,
bertrand> is what computers are for.)

Exactly! As to the *possibility* of inlining. On the other hand
complexity analysis to determine where it is *useful* to inline is not
quite what programs are very good at.

[ ... ]

Re: What is wrong with OO ?

[Robert Dewar]

Bjarne, in the middle of a very nice extended discussion of C++, says

"Had C++ not been relatively easy to learn and use reasonably well, it
would have disappeared long ago. By relative I mean the amount of effort
needed compared to the amount of benefit gained."


Hmmm! I don't think I buy that. People will learn what is at hand pretty
much regardless of whether something is easy to learn and use. After all
I am sure that far more programs are written using macro languages of
spread sheets, most of which are truly awful, very difficult to use, and
pretty difficult to learn. Nevertheless people do at least "sort of"
learn something regardless. Actually elsewhere in his article, Bjarne
complains of this phenomenon :-)

By the way just a quick note on spreadsheet languages. I saw a couple of
years ago a fairly comprehensive study of spread sheet programs (if you
don't think of spread sheets as a programming language, then you don't
know what people are trying to do with these programs :-) It showed that
over 50% of production spread sheets in use at Fortune 500 companies
that were studied contained serious errors. Now of course any such survey
is subject to concerns about sampling stablity. Still one would think that
such a result would spread wide alarm, but as far as I can tell everyone
shrugged and continued ("it must be the other guy who has all the errors,
I am sure my spreadsheets are fine!")

Going back to the main subject, which is the allegation that popularity
indicates ease of learning and use, I think the point is that such
popularity indicates accesibility more than anything else. By accessibility
I mean that something is available, viewed as hot, and can be learned well
enough to do *something*. Consider the situation today, students want to
learn Java, not C++, they see C++ as yesterday's language, and Java as
the language of tomorrow. Just from the incredible rate at which Java books
are cascading into bookstores, I have to guess that the rate of learning of
Java far exceeds the rate of learning of C++. But I would NOT conclude from
this that Java is easier to learn or use than C++. Maybe it is, but you
cannot conclude anything just from popularity.

Ada folks have never played the game of claiming popularity as an indicator
of any kind of quality, because they have not been able to. I realize that
C++ is in a position to make such claims, but I recommend against it, because
I think you will find that your arguments will backfire as Java becomes
the next hot language, at least for a while :-)

Robert

Re: What is wrong with OO ?

[Robert Dewar]

Chris said

"If it's that easy we would like to try it (customer #133) :-)"

Well, as I noted to him, if people have suggestions for GNAT enhancements
they should be sent to report@gnat.com with a very clear suggestion of
what feature is needed, and why it is important for a given application.

Note that the fact that something is easy to do is not in itself a good
justification for adding a feature to a language or compiler implementation.
Every feature you add adds complexity, so you have to be conservative in
adding new features and switches.

Chris, if you are really interested in trying this out, do it the simple
way first. Write an edit script that adds pragma Inline statements to all
subprograms in all specs, then recompile the program. That way you can
get some data as to whether this option would be worthwhile.

Re: What is wrong with OO ?

[Bjarne Stroustrup]

jsa@alexandria (Jon S Anthony) writes:

 > 
 > In article <fxtu3oysbzp.fsf@isolde.mti.sgi.com> Matt Austern <austern@isolde.mti.sgi.com> writes:
 > 
 > > jsa@alexandria (Jon S Anthony) writes:
 > > 
 > > > Oh, I don't know.  I think C++ was created simply because BS was
 > > > saddled with C (at ATT) and wanted _something_ that had a least _some_
 > > > abstraction capabilities in it.  Voila.  C++.  Whether it is any more
 > > > "usable" than several other options is highly open to question.  And
 > > > in fact, in general I would say the answer is "no".
 > > 
 > > It's not necessary to speculate on why Bjarne Stroustrup made the
 > > design decisions that he did: he discusses them, in a fair amount
 > > of detail, in _The Design and Evolution of C++_.
 > 
 > He also gave various descriptions of this process while it was
 > happening cira 87-89 and I happened to attend some of these.

What was happening circa 87-89 was the refinements of C++ version 2
(abstract classes, multiple inheritance, etc.) and beyond (templates,
exceptions, etc.). The initial work was much earlier (1979-1983).


 > > he was trying to create a language that, like C, made it possible to
 > > write low-level programs, but that also, like Simula, included
 > > high-level abstraction facilities.  
 > 
 > Exactly.  This came from his direct experience of having to recode a
 > Simula program for his thesis into BCPL.  The resulting nightmare was
 > not something he wished to have to go through again.  When getting to
 > ATT and seeing that it was C or nothing, he decided to "fix it" before
 > suffering the same experience.
 
This description is misleading on two counts:

(1)	I wanted something from both Simula and BCPL. Both have strengths
	and weaknesses relatively to my needs.

		Simula, had classes and a (much) stronger type system.

		BCPL had speed, easy porting of implementations, and the
		ability to easily cooperate with code fragments written
		in other languages (it was ``open'').

	The issue was not as simple as ``Simula was ideal except for
	efficiency concerns.'' That was the case for my Cambridge
	simulations, but not for the work I wanted to do later.

	The lessons I drew from my experiences in Cambridge was that I
	needed both sets of "good aspects" (and that there were "bad
	aspects" to both that I'd rather do without) NOT that one was
	strictly better than the other. This is documented in D&E and
	in papers written earlier than '87-'89. What I synthesized from
	my Cambridge rogramming experience was an initial set of criteria
	for a tool for higher-level systems programming.

(2) It was not "C or nothing" at AT&T. I was in a research organization
	that did not dictate what languages to use and several languages
	were used in various parts of AT&T at the time. The alternatives
	I knew of during the first years included C, Simula, Algol68, BCPL,
	Pascal, Modula-2, and Lisp. Naturally, I knew of more languages,
	but not every language I knew was an alternative for the work I
	was doing.

	I chose C because I rated it the best systems programming language
	at the time. It had obvious flaws, but I rated them secondary and
	manageable, whereas I considered the other alternatives to have
	more fundamental flaws relative to my needs. Being in THE hotbed
	of C at the time of course helped me appreciate the strengths of
	C and taught me how the experts compensated for its weaknesses,
	but that is a far cry from "C or nothing."


Why is any of this relevant now? Why do I bother with this debate on
"innovation?" Because some of what is said related directly to what C++
is and should be, and that again affects where it is reasonable to use
it and how it is best used. If you misunderstand some of the fundamentals
of a language, the code you write in it is going to be suboptimal in several
ways.
	
	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html

Re: OO, C++, and something much better!

[Bjarne Stroustrup]

From: Sazonov Cyril <cyril@geol.spb.su> writes:

 >  > I'm absollutely agree with Stanley Allen ! Just to say more: C++ doesn't
 >  > suggest _ANY_ new ideas or tools in comparison with Ada !
 > 
 >  > <<quote from John Skaller not containing the phrases 'new word' or
 >  > 'revolutionary technology' deleted - bs>>
 > 
 > At all talks of 'new word', 'revolutionary technology' etc in the context of
 > OOP and C++ especially seems to be strange for the ones who know  Ada since,
 > for example, 1989. All the ideas of the OOP had been implemented in Ada, even
 > though they seamed to classic in the time of the language design. Triumphant
 > march of the OOP and C++ is caused by some kind of lazyness and illiteracy.
 > The ones who find that technology to be new simply aren't familiar with the
 > Algol-family languages history.

As far as I know, this discussion started with some assertions about the
degree to which C++ was innovative. Naturally, some people couldn't resist
the temptation to start a minor flamewar in favor of their favorite languages.
However, let us try to stick to facts. Nothing good will come of calling
someone "lazy and illiterate." Ignorance of the Algol family of Languages
is not common among the part of the C and C++ community that I am most
acqainted with (including John Skaller) - essentially everyone is multi-lingual.

Early versions of C++ were - under the name C with Classes - in use from
1980, and C++ much as we know it was in commercial use from late 1985.

For my needs, Ada83 was too restrictive and too expensive. In particular,
C++ provided virtual functions which Ada83 lacked - and the Ada95 designers
agreed with me in the sense that they added the equivalent. I understand the
restraint of the Ada83 designers, but that didn't help me at the time.
Object-oriented programming - as most commonly defined - needs the support
of virtual functions (unless you are willing to simulate them using pointers
to functions - which would be hard in Ada83).

And 'no' I do not claim that virtual functions originated in C++. I borrowed
that concept - with proper thanks and acknowledgements - from Simula.
In my opinion, Simula is a good candidate for the title of "the most
innovative language ever."

Ada83 provided generics, and at the time I acknowledged that C++ suffered
from the lack of an equivalent. However, simple grafting of features from
one language onto another doesn't work too well. I think that templates
serve C++ better than a simple transplant of Ada generics would have.

For a view of 1985 vintage C++ see my "What is Object-Oriented Programming?"
paper, or better yet see "The Design and Evolution of C++" (Addison-Wesley)
for a more detailed view of C++ from a current perspective.

	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html

Re: What is wrong with OO ?

[Robert Dewar]

Jay said

"Here is an even more ignorant question: Why is compilation time still
a driving factor? (excluding hardcore optimizations) Obviously it
still is as I watched large systems compile lately.  But wait, wasn't
Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC
faster than VC++ on my P5-100.  For fun I compiled old programs with
vintage a Turbo Pascal Compiler and it seems to compile these suckers
instantanously!"

Yes, but the quality of code turned out by your "vintage Turbo pascal
compiler" is truly horrible. If you don't mind that then fine, it is
certainly possible to turn out compilers that compile lousy code
fast. It is even possible to make compilers that generate pretty good
code locally and are very fast (e.g. Realia COBOL).

But almost in the same breath you were talking about intelligent global
optimziation, and interunit IGO at that!

Global optimization, even at the level of simply worrying about good
global register allocation and good scheduling across basic blocks,
is non-trivial, and tends to eat up large amounts of computing resources.
Furthermore, anything approximating optimal algorithms tends to be
super-linear --- at least quadratic sometimes worse -- we know of
course that truly optimal code generators are NP complete in time
complexity -- but we don't go that far).

Still this super-linear behavior means that if you try doing global
optimziation across the entire program, you are liable to use very
large amounts of computing resources. The MIPS compiler did link time
register allocation, and even just doing that resulted in very long
link times.

Of course this thread is NOT about intellignemt global optimziation, it is
about something much more trivial, which is simply doing inlining. I won't
comment on the issue of "parroting" BS on inlining in the past, but the
fact of the matter is that all compilers today implement inlining, and
that was true when Ada 83 was designed. As I have repeatedly pointed out,
the pragma Inline of Ada 83 is not about asking the compiler to inline,
it is about *permitting* the compiler to establish the body dependency
necssary to inline.

Doing all possible inlining is certainly not that hard, but it is likely
to be time consuming, since it creates a large number of body dependencies.
In a million line program, there is a lot of stuff to wade through to
find out lots of cases where inlining will NOT work, and I still suspect
that the benefits of such unrestricted searching for inlining opportunities
are dubious, especially given normal Ada style in which people do write
pragma Inlines where there is some possibility of interunit inlining
being useful.

Note that interunit inlining is not one iota more difficult than
intraunit inlining. The issue here is simply one of restricting how
much stuff the compiler must look at.

Re: What is wrong with OO ?

[Fergus Henderson]

Bart Samwel <bsamwel@wi.leidenuniv.nl> writes:

>Michael Malak wrote:
>> Yet, Microsoft Visual C++ does exactly that.  In fact, it has since
>> version 1.5 (early 1994).  MSVC++ performs "auto-inlining"
>> (Microsoft's terminology) by compiling all the source modules all at
>> once.
>
>This is a pro for VC++. However, most compilers still use the old make-
>based model, especially on Unix,

Which Unix are you thinking of?  The C++ compilers from Sun (Solaris),
SGI (IRIX), and DEC (Alpha/OSF) are all capable of automatic
cross-module inlining.

Oh, I guess you must have been thinking of Linux ;-)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

tiggr@es.ele.tue.nl (Pieter Schoenmakers) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>   Richie Bielak <richieb@calfp.com> writes:
>
>   >Optimizations that require global analysis of all the classes
>   >of a program at compile time do not work if we need dynamic loading
>   >of classes at runtime, because adding a new class to a running system
>   >may invalidate optimizer's assumptions.
>
>   True, but there are plenty of cross-module optimizations (such as
>   cross-module inlining) that require the compiler to use information
>   from more than one module but don't require analysis of *all* parts of
>   a program.
>
>With any kind of static binding (and inlining is the summum in static
>binding), the possibilities of dynamically loaded code are limited.  What
>to do if a dynamically loaded class redefines some feature causing that
>feature to no longer be statically bindable?  Recompile the whole
>executable?  --Tiggr

If you allow new classes to be dynamically loaded, then the compiler
can't statically bind features of objects whose dynamic type is unknown,
but it can still statically bind features of objects whose dynamic type
is known.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

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

>Fergus said
>
>"Hence this control should normally be expressed via
>compiler options, rather than being embedded in the source code."
>
>Are you using GNAT?

Nope, not at the moment, although I have used it in the past.

>I would guess not, because you seem to assume that
>is not the case, but in fact inlining is controlled by compiler options
>in GNAT.

I know that -- in fact, I don't know of any compiler that does any
inlining for which you can't control the inlining with compiler options.

But in Ada with gnat/gnatmake, the control is normally specified using
a mixture of compiler options and embedded pragmas, and there is no
way of getting maximum inlining without scattering pragmas throughout
your code.

This contrasts with e.g. SGI C++, which has command-line options
that allow you to do full cross-module inlining without a single
`inline' or pragma in your source code.

>The pragma inlines merely enable the establishment of interunit
>dependences.

But the real interunit dependencies depend on the compiler options.
If you're compiling with gnat/gnatmake without inlining enabled, but
you have the pragmas scattered throughout your source code, then you
will get some unnecessary recompilation, won't you?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Josh Stern]

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote:

>Perhaps the most important advantage of inlining is that it creates
>opportunities for other optimizations, such as constant propagation,
>strength reduction, dead code elimination, common sub-expression
>elimination, and hoisting code out of loops.  The advantage of inlining
>comes not just from avoiding the call/return, but also from being able
>to specialize the subroutines's code for each particular invocation.

Agreed!  And I would go one step further to add that when
a programmer can assume that these sort of optimizations
will take place, then it is possible to produce code at
a given level of performance efficiency that is much
more readable and maintainable than otherwise.
And it will also be faster to write this code.

-Josh

Re: OO, C++, and something much better!

[Richard Riehle]

On 6 Jan 1997, Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:

> However, if I remember correctly, Alex Stepanov had earlier tried to
> implement a library like the C++ STL in Ada, but was incapable of
> doing it. This would indicate that the C++ template mechanism is more
> flexible than the Ada generics.
> Any comments?

  In an in-depth interview published in Dr. Dobbs (I do not recall the
  date) Stepanov was both complimentary of Ada and critical of it. His
  primary criticsim was the inability to create generic packages in which
  he could use generic formal package parameters.  C++ and Eiffel both
  allow something analogous to this.

  This was perceived by many as a problem in Ada 83, and "fixed" in 
  Ada 95.  ISO Standard 8652:1995 Ada does include generic formal 
  package parameters, though the model seems, to some, a little more 
  awkward to use than the same mechanism in C++ or Eiffel. STL could be
  implemented in Ada 95 if anyone wanted to take the time to do it.

  Probably a better approach than STL, for Ada 95, would be that by
  Bertrand Meyer as published in his book, "Reusable Software" from
  Prentice-Hall. 

  At a Tri-Ada conference in Los Angeles, Mr. Stepanov re-visited
  this Ada 83 criticism while on a panel discussion with Tucker Taft.
  At that time, Tucker made it clear to Mr. Stepanov that Ada 95 does
  include generic formal package parameters. 

  Richard Riehle

Re: What is wrong with OO ?

[Robert Dewar]

iFergus said

"But the real interunit dependencies depend on the compiler options.
If you're compiling with gnat/gnatmake without inlining enabled, but
you have the pragmas scattered throughout your source code, then you
will get some unnecessary recompilation, won't you?"

No, of course not. The pragma Inline's represent *permission* to create
dependencies, not a requirement to do so, and as clearly documented in 
the gnat users guide, if you do not use -gnatn, then pragma Inline is
ignored.

Re: What is wrong with OO ?

[Slavik Zorin]

Inlining in Smalltalk is a pain in the ass, esspecially when the
compiler bluntly chooses to do it for you.  Message like >>isNil which
is automatically inlined by the compiler wreeks all kinds of havoc when
one uses proxies which are subclasses of nil.  When I initialize an
instance variable with some semantic proxy which gets dereferenced when
it receives its first message (goes to DB and caches the real object in
its place), the message >>isNil to this proxy should return true, that
is the message isNil should be overriden!  But, since the compiler
rudely ignores it (how can it not, Smalltalk has not types, so there is
now way the compiler knows the expression "obj isNil" should not be
precompiled), one must replace all isNil messages to = or ~=; what a
pain!!!

How about:
	Compiler
		doNotInlineSelectors: someSelectorArray
		forMeta: aClassOrMetaclass

If Smalltalk icludes a compiler, its time to include some public
compiler APIs as well.

Slavik Zorin

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "eachus" == Robert I Eachus <eachus@spectre.mitre.org> writes:

[ ... interesting discussion on Ada generics and inling and OO ... ]

eachus>     As I pointed out, this is because the Ada type model sees classes
eachus> as sets of types all having a specific set of operations. [
eachus> ... ]
eachus>     In Eiffel, even though the actual concept of class is very
eachus> similar, the model is explicitly hierarchical. [ ... ]

Let me put here a warning to the reader: this is true only in a certain
sense that is apparent to those familiar with the Ada 95 usage of the
word "class"; in Ada 95 the word "class" denotes something more like
what is called a "protocol", for example in ``Smalltalk''-like
languages, or rather the classes that share a protocol, while "class" in
most OO languages means a single instantiable module/type.

Re: What is wrong with OO ?

[Martin ELLISON]

Robert Dewar wrote:
> 
> Simon says
> 
> "I agree it can't be done with a stupid linker, but I was just pointing out
> that inlining can be done in Ada without affecting the programmer.
> 
> You just have to leave the jobs of optimisation and (machine) code generation
> to a later stage."
> 
> Let's look at that carefully. The second paragaph implies that the link
> step redoes optimization and compilations for the entire program. Even
> with fast machines and fast compilers, I think that this is definitely
> something that would "affect the programmer".

Why can't the compiler optimise the whole program? (Assuming that it is
all written in the same language). Who says that you have to compile and
generate code for each module and then link them together? Doing so may
be quicker for a development version, but surely a production compile
can be optimised across the whole system.
---------------------------------------------------
Martin Ellison                  		mailto:martin@mpce.mq.edu.au  
				    		http://www.jrcase.mq.edu.au/~martin/

Re: What is wrong with OO ?

[Matt Telles]

Bjarne Stroustrup <bs@research.att.com> wrote in article 
> 
> First, here is the way I phrased the "learning" criteria in "The Design
> and Evolution of C++":
> 
> 	If in doubt, pick the variant of a feature that is easiest to teach

I certainly agree with this statement.

> C++ is a language primarily aimed at creating production software. Like
> all such languages, it together with its associated libraries, tools, and
> programming techniques is too large to learn quickly (unless you happen
> to be experienced in rather similar languages and techniques - and most
> students and programmers are not when they first encounter C++).
> Consequently, it must be learned in stages starting with some suitable
> subset (and a suitable subset of tools, libraries, programming
techniques).

I am curious. Does this imply that you think people should learn another
language before C++? Or is it simply that C++ is taught without the proper
emphasis on techniques. In my experience, the language is taught
syntactically, with little regard for the OO behind it. 
> 
> Many are too ambitious and try to learn too much too fast. In particular,
> many programmers focus on learning every obscure language detail rather
> than overall principles because mastery of programming language details
> is what has traditionally been valued in many programming communities.
> That way, people get lost in details.

True. Isn't it important then to emphasize the aspects of the language
which make it 
a) Maintainable and
b) Reusable?

> Traditionally, C++ has been blessed with a mass of useful libraries, and
> cursed by the absence of a good standard library. The lack of a standard
> library supplying basic types (such as string, list, and map) reinforced
> the bias of some teachers and some teaching materials towards low-level
> features and techniques that don't rely on standard library facilities.

Agreed. But where else to begin? If you are teaching C++, they say, learn
to write a linked list class, learn to write a string class. I annoyed one
of my professors long ago by handing in a linked list class that said
simply "refer to chapter xxx in the text". After all, wasn't reuse the
point we were trying to stress? How would you teach C++ without emphasizing
the low-level functions?

> I have no idea if any of this apply at your university, but I have seen
> all of those phenomena repeatedly. Usually, people manage in the end, and
> if not they try something else - which they may or may not find more
> suitable.

This is really less of an issue that the "Object Oriented Programming can
save the company" bandwagon, in my estimation.

>  > Languages like Eiffel (my personal favorite) are much more suitable
for
>  > high-level projects; Eiffel, for instance, does not burden the
>  > programmer more than needed, and has a clean, clear syntax that can
>  > even be immediately understood by people that don't know the language.
> 
> I do not personally find it so, and such claims reminds me unpleasently
> of the similar claims made for COBOL. A non-programmer can sometimes be
> convinced that he/she can read simple code, but it is far from obvious
> that this is relevant - or ever true - for production code (that will
only
> be seen by programmers anyway). 

My question is: Does the tool matter? Or is it simply an extension of the
concepts behind it. I can write object-oriented code in FORTRAN. It is
harder, but it can be done. The amount of work doesn't necessarily make it
less possible.

> Had C++ not been relatively easy to learn and use reasonably well, it
> would have disappeared long ago. By relative I mean the amount of effort
> needed compared to the amount of benefit gained.

Tell that to COBOL programmers. Or Pascal, or any of the other languages
that I have learned at one point or another in my life. The amount of
effort to learn the language becomes secondary when the boss tells you to
learn it. Why use the Microsoft compiler over the Borland compiler? Because
the company standardizes on it...

> Once a language is used by diverse user communities, one person's serious
> flaw becomes another's essential feature. Some of the aspects of C++ that
> I dislike most are deemed essential by very competent system builders.
> However, C++ has no flaw and no feature lacking that is so serious that
> it cannot be managed with reasonable effort in a project - even if they
> can be a bother and experienced programmers recognize them as such.

I have a problem here, but it is not with C++. There are certainly flaws in
the language. No serious programmer would argue that there are languages
which are flawless. The problem is that C++ lets me shoot myself in the
foot. In some cases, it aids in loading the gun and aiming it for me. The
issue is not the language, but the poor programming practices which
encourage it. Why, for example, allow the continued use of void pointers
when they lead to nothing but pain and agony in the long run (this is an
example, I understand why they were necessary). Why let me use
uninitialized pointers? Do you have any idea how many programs I have
debugged for hours because someone failed to write something as basic as:

char *p = NULL;

> 
> 
> Good luck with your projects and the language you favor, and remember
> that the world is more complicated that any of us can imagine and that
> there are ways of succeeding that we would not personally have chosen.
> 
> 	- Bjarne
> 
> Bjarne Stroustrup, AT&T Research,
http://www.research.att.com/~bs/homepage.html

I certainly won't argue with someone who created the language. My point is
simply that until we solve the problem of programmers believing they are
artists, rather than engineers, we will never have quality software.

Matt Telles

Re: What is wrong with OO ?

[Chris Morgan]

In article <dewar.852893729@merv> dewar@merv.cs.nyu.edu (Robert Dewar)
writes (regarding an "attempt automatic inline" switch :

> It certainly would be easy to implement a compiler option to force this
> treatment, but so far none of our customers has suggested this as a
> requirement.

If it's that easy we would like to try it (customer #133) :-)

Chris
-- 
Never run with scissors.

Re: What is wrong with OO ?

[Chris Morgan]

In article <01bbff25$8b1fa3c0$26170880@annex9-38.dial.umd.edu> "Marky
Mark" <mrox@wam.umd.edu> writes:

> All you guys are talking about is inlining some code!!  Is it really worth
> this long thread?

Hint :

Yes!

Chris
-- 
Never run with scissors.

Re: What is wrong with OO ?

[Thierry Goubier]

On 11 Jan 1997, Piercarlo Grandi wrote:

[On the subject of inlining by the compiler, with B. Meyer]

> Ideally a compiler would use profiling feedback to evaluate whether it
> is worth inlining a procedure at a given call site, by running the
> program with an without (this check ought to be done for each procedure
> at each call site for which is is possible, and every combination
> thereof :->).

I believe this technology already exists, for example in the Self 3.0 and
4.0 inlining compilers. Things like polymorphic inline caches may be used
as a tool to record profiling information for the compiler.

But I should let interested people look the Cecil/Vortex project to see
how this may be used in static compilation. What Chambers describes seems
to be relevant to this thread. A pointer is :

http://www.cs.washington.edu/research/projects/cecil/www/Overview/overview_1.html

Thierry.
___________________Thierry.Goubier@enst-bretagne.fr__________________
    Je ne suis pas un patriote car je n'ai pas peur de l'etranger
        I'm not a patriot because I don't fear foreigners
http://www-info.enst-bretagne.fr/~goubier/                    

Re: What is wrong with OO ?

[Fergus Henderson]

bs@research.att.com (Bjarne Stroustrup) writes:

>C++ is a language primarily aimed at creating production software. Like
>all such languages, it together with its associated libraries, tools, and
>programming techniques is too large to learn quickly (unless you happen
>to be experienced in rather similar languages and techniques - and most
>students and programmers are not when they first encounter C++).
>Consequently, it must be learned in stages starting with some suitable
>subset (and a suitable subset of tools, libraries, programming techniques).
>
>Many are too ambitious and try to learn too much too fast. In particular,
>many programmers focus on learning every obscure language detail rather
>than overall principles because mastery of programming language details
>is what has traditionally been valued in many programming communities.
>That way, people get lost in details.

It's not important to learn every obscure language detail, but it is
important to know all the language rules that govern the behaviour of
the subset of language features that you do use.  Without that
knowledge, it is very easy to accidentally write programs that are
non-portable or buggy.

Most C++ programmers make use of class libraries (e.g. the C++ standard
library) that use a broad range of C++ language features.  Correct use
of such class libraries may require knowledge of a large number of
those obscure details. 

(See, for example, the thread on "operator delete and template
instantiation" in comp.std.c++, or consider the many discussions in
comp.lang.c++(.moderated) on how to write "exception-safe" code.)

>Usually, people manage in the end, and
>if not they try something else - which they may or may not find more
>suitable.

Usually, people do manage in the end, but then again most software
produced today is full of bugs.  Usually it works well enough only
because it has been carefully tested and debugged, but usually it will
fail when exercised in novel ways.  Choice of programming language is
certainly not the only or the most important factor in this, but I do
think that it can make a significant difference.

>Reliability and mainatainability can be eased by a programming
>language (such as C++) but is the result of a more comprehensive
>process.

Yes, but I think one part of that comprehensive process should be
ensuring that programmers do know the language rules that govern the
behaviour of the language features that they use.  (It's not too
important for a programmer to know about the tricky cases if the
compiler will catch them, but it is important to know about possible
pitfalls that would not be caught by the compiler and would instead
result in undefined or implementation-dependent behaviour at runtime.)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

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

>Fergus said, responding to me
>
>">To implement such a switch would be about thirty minutes work in GNAT, but
>>I doubt it would be found to be of much use in practice, certainly no one
>>has indicated an interest in such a switch.
>
>Let me hereby indicate interest in such a switch!
>I think it would be quite useful in practice."
>
>Well of course people are interested if it costs them nothing to be
>interested :-)

We were interested enough to implement this in the Mercury compiler.

Compiling the Mercury compiler with inter-module inlining enabled
improved performance by about 10%.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

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

>Marky said
>
>"All you guys are talking about is inlining some code!!  Is it really worth
>this long thread?"
>
>Inlining is an important optimization, and becoming more so for two reasons.
[...]

Perhaps the most important advantage of inlining is that it creates
opportunities for other optimizations, such as constant propagation,
strength reduction, dead code elimination, common sub-expression
elimination, and hoisting code out of loops.  The advantage of inlining
comes not just from avoiding the call/return, but also from being able
to specialize the subroutines's code for each particular invocation.

Increasing amounts of code reuse is making this effect more important.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Pieter Schoenmakers]

In article <5bbcom$gc7@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

   tiggr@es.ele.tue.nl (Pieter Schoenmakers) writes:

   >With any kind of static binding (and inlining is the summum in static
   >binding), the possibilities of dynamically loaded code are limited.  What
   >to do if a dynamically loaded class redefines some feature causing that
   >feature to no longer be statically bindable?  Recompile the whole
   >executable?  --Tiggr

   If you allow new classes to be dynamically loaded, then the compiler
   can't statically bind features of objects whose dynamic type is unknown,
   but it can still statically bind features of objects whose dynamic type
   is known.

If a class B can be dynamically loaded, and B is a subclass of the
statically loaded (i.e. known to the compiler) class A, then every feature
invocation of an object accessed through a variable of type A, where the
actual object could just as well be a B, can not be statically bound or
inlined.  If, in that situation, you inline the feature implementation of
A, and B redefines that feature, the wrong code is executed if the actual
object (still denoted by the variable with type A) is a B and not an A.
--Tiggr

Re: OO, C++, and something much better!

[Don Harrison]

Jon S Anthony writes:

:> Yes. However, I'm not sure whether you lose some of the power of combining 
:> genericity with inheritance through Ada's module-type distinction.
:
:I have never seen any example supporting your "unease" - by you or
:anyone else.

Oh well. 
 
:> genericity in Ada is essentially module-based and inheritance is type-based,
:> I suspect you may lose something here.
:
:Presumably you forgot to add "only" to "inheritance is type-based".

No.

:> No. Ada offers type casting in a couple of ways:
:> 
:>   1) UNCHECKED_CONVERSION and
:>   2) Address representation clauses (overlays).
:
:1. This is not "casting"

1) is; 2) isn't. But both violate safe typing.

:2. It's irrelevant anyway as these are type system trap doors (outside
:   the type system).

Yes. They're loopholes.

:> For example, by using the value of a parent type where a subrange
:> value is required.
:
:Give an example.

Would like to. There's something wrong with the system here at the moment.
If I get an example running, I'll send it to you.

:This sort of thing will be statically checked.

I agree it ought to be.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Don Harrison]

Robert Dewar writes:

:I have been trying to think of a safe way of doing this sort of thing but
:thus far haven't thought of any. :)"
:
:
:Well there obviously is no safe way of doing something whose entire purpose
:is to allow unsafe operations!

Yes, these mechanisms are inherently unsafe but their purpose is to allow 
different views of the same data. There are different ways of acheiving 
that and some ways are safer than others. For example, UNCHECKED_CONVERSION 
is safer than overlaying because the data is copied thus protecting the 
original object.

As you suggest, there's no completely safe scheme of allowing alternate
views.

:Still I would not characterize these as "type casting" in Ada. Rather I 
:would think of them as loopholes, equivalent to calling a C or assembly
:routine. Any formal analysis or discussion of the type system of Ada
:has to ignore these features, and of course any real language to be used
:for low level systems programming needs such features, but I don't think
:it is a useful excercise to include these features in the type analysis.
:
:If you like, consider Ada *minus* these two features as the interesting
:language to be analyzed. Then understand that in real life programs can
:break the bounds of this analysis to the extent they need to.

Agree.

:Note that it is not actually the unchecked conversion that is nasty, since
:the fundamental conversion can be modeled as simply a random mapping between
:values of one type to values of another type. It is that these operations
:can generate abnormal values. 
:
:This may still not be a problem, given that uninitialized values can also
:be abnormal, thus:
:
:  a := nasty_unchecked_conversion (b);
:
:is no worse that not assigning to a at all if a is uninitialized.

True.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Bart Samwel]

Fergus Henderson wrote:

> Usually, people do manage in the end, but then again most software
> produced today is full of bugs.  Usually it works well enough only
> because it has been carefully tested and debugged, but usually it will
> fail when exercised in novel ways.  Choice of programming language is
> certainly not the only or the most important factor in this, but I do
> think that it can make a significant difference.

I certainly agree! The reason I like Eiffel so much is that it has
language support for pre- and postconditions, class invariants, loop
variants and invariants and in-code assertions, which are closely linked
to the exception mechanism. In alpha, beta and gamma releases,
one can compile with a specific subset of these assertions tested at
run time, so that when a program is used in a way it didn't expect and
wasn't prepared for, the program generates an exception. With the
compilers I've seen so far, this results (when no exception handler is
installed) in displaying of the call stack and the precise class and
feature name in which the exception occurred, and the name of the
assertion that failed.

Because of this language support, many of the Eiffel programmers use
these assertions throughout all of their code. They do this because
they know that when something goes wrong, they will more often know
exactly _where_ things went wrong, and _what_ went wrong, without
debugging.

> Yes, but I think one part of that comprehensive process should be
> ensuring that programmers do know the language rules that govern the
> behaviour of the language features that they use.  (It's not too
> important for a programmer to know about the tricky cases if the
> compiler will catch them, but it is important to know about possible
> pitfalls that would not be caught by the compiler and would instead
> result in undefined or implementation-dependent behaviour at runtime.)

And indeed, C++ does have many of these pitfalls, IMHO anyway. There
are languages available that are able to catch many more of these
pitfalls. One of the reasons these languages can catch these pitfalls
better than C++ can is that they are a bit more constrained than C++,
which is not necessarily a Bad Thing.


   Bart

Re: OO, C++, and something much better!

[Robert Dewar]

Don Harrison said

"Yes, these mechanisms are inherently unsafe but their purpose is to allow
different views of the same data. There are different ways of acheiving
that and some ways are safer than others. For example, UNCHECKED_CONVERSION
is safer than overlaying because the data is copied thus protecting the
original object."


That is a misconception. Unchecked_Conversion does not require the data
to be copied. The whole point of 13.9(12) is to remove this requirement:

12   An implementation may return the result of an unchecked conversion by
reference, if the Source type is not a by-copy type.  In this case, the
result of the unchecked conversion represents simply a different (read-only)
view of the operand of the conversion.



The design principle here is that since this is a d0-it-at-your-own-risk
and make-sure-you-know-what-you-are-doing operation, it is inappropriate
to waste time trying to increase the safety of the operation. If you
want to ensure that a copy is made, you must make the copy. Note that
in the common case of:

   a := unchecked_convert (b);

the assignment makes a copy anyway (and this is the case where avoiding
the requirement for unchecked_conversion to make a copy of its own 
improves efficiency -- well to be fair the compiler can optimize this
case since it is transparent, but encouraging return by reference will
generally improve efficiency, and is unlikely to be noticeable.

GNAT does take advantage of this permission where appropriate, and UC
for large objects works by pointer punning if the alignments are
compatible (if the alignments don't match, or more specifically if the
target has a stricter alignment than the source, then of course you have
no choice but to make a copy.

Re: OO, C++, and something much better!

[Ken Garlington]

Don Harrison wrote:
> 
> Robert Dewar writes:
> 
> :I have been trying to think of a safe way of doing this sort of thing but
> :thus far haven't thought of any. :)"
> :
> :
> :Well there obviously is no safe way of doing something whose entire purpose
> :is to allow unsafe operations!
> 
> Yes, these mechanisms are inherently unsafe but their purpose is to allow
> different views of the same data. There are different ways of acheiving
> that and some ways are safer than others. For example, UNCHECKED_CONVERSION
> is safer than overlaying because the data is copied thus protecting the
> original object.

Why does UC require copying? The following code works fine with my copy
of
GNAT, and I've used the same technique on Ada 83 compilers as well...

  with Unchecked_Conversion;
  with Ada.Text_IO;
  procedure Test_UC is

    type My_Integer is new Integer;    
    function To_Int is new Unchecked_Conversion ( My_Integer, Integer );
  
    Foo : My_Integer := 7;
    Bar : constant Integer := 0; 

  begin

    To_Int(Foo) := Bar;
    Ada.Text_IO.Put_Line(My_Integer'Image(Foo));
  
  end;

Re: What is wrong with OO ?

[ak]

Chris Morgan wrote:
> 
> Mark" <mrox@wam.umd.edu> writes:
> 
> > All you guys are talking about is inlining some code!!  Is it really worth
> > this long thread?
> 
> Hint :  Yes!

If so, then please give it a proper subject name that describe 
the case instead of "what is wrong with OO"
This will help the readers to realise the content of the post ..
and anybody not interested should simply skip it

Cheers
   Ak

Re: OO, C++, and something much better!

[Robert I. Eachus]

In article <E3xprM.4pB@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

  > :> No. Ada offers type casting in a couple of ways:
  > :> 
  > :>   1) UNCHECKED_CONVERSION and
  > :>   2) Address representation clauses (overlays).
  > :
  > :1. This is not "casting"

  > 1) is; 2) isn't. But both violate safe typing.

   Casting in C normally maps to type conversions in Ada:

   foo a;
   bar b;
   ...
   b = bar(a);

   Should be translated as:

   A: Foo;
   B: Bar;
   ...
   B := Bar(A);
   -- The case changes are due to standard Ada and C style.

   This in Ada is a completely type safe conversion.  If you want to
go outside the compilers type checking, you can use
Unchecked_Conversion.  But interpret what you are doing correctly.
You the programmer are taking responsibility for doing type checking
which the compiler is unable to do.  There are many uses for
Unchecked_Conversion where this is exactly what is going on...  For
example, in one version of the ADAR components, to preserve the
visible (to the user of the components) type hierarchy, I had to do an
Unchecked_Conversion in the body of one unit--from a derived type to
its parent, but the actual derivation wasn't visible at that point in
the code.

   Doing "punning" using Unchecked_Conversion from the formal point of
view is an error, and Ada compilers are allowed (but not able in all
cases) to detect such violations and raise Program_Error.  For
example, someone was just asking how to do a boolean or on two Ada
strings.  The answer posted was more complex than necessary because it
used Unchecked_Conversion.  An Ada character can be converted to a
(universal) integer type, and "or" exists for unsigned integer types
in Ada 95.  So a better approach would be:

    function "or"(L,R: Character) return Character is
      type Byte is mod 256;
    begin return Character'Val(Byte(Character'Pos(L)) or
                               Byte(Character'Pos(R))); 
    end "or";

    function "or"(L,R: String) return String is
      Result: String(1..L'Length) := L;
    begin
      if L'Length /= R'Length then raise Constraint_Error; end if;
      for I in Result'Range loop
        Result(I) := Result(I) or R(I-R'First+1);
      end loop;
      return Result;
    end "or";

    With appropriate compiler inlining ;-) this should give results as
good or better than the non-portable version, but that is another subject.


--

					Robert I. Eachus

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

Re: OO, C++, and something much better!

[Norman H. Cohen]

Ken Garlington wrote:

> Why does UC require copying? The following code works fine with my copy
> of
> GNAT, and I've used the same technique on Ada 83 compilers as well...
> 
>   with Unchecked_Conversion;
>   with Ada.Text_IO;
>   procedure Test_UC is
> 
>     type My_Integer is new Integer;
>     function To_Int is new Unchecked_Conversion ( My_Integer, Integer );
> 
>     Foo : My_Integer := 7;
>     Bar : constant Integer := 0;
> 
>   begin
> 
>     To_Int(Foo) := Bar;
>     Ada.Text_IO.Put_Line(My_Integer'Image(Foo));
> 
>   end;

I can confirm that this works on my copy of GNAT too.  The only problem
is that this should NOT work!  (To_Int(Foo) is a function call, not a
variable.)  

RM 13.9(12) mentions that an instance of Unchecked_Conversion can return
its result by reference, meaning that the result is just another view of
the argument (i.e., there is no copying), but it is specifically stated
that this is a read-only view.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Don Harrison]

Jon S Anthony writes:

:> For example, by using the value of a parent type where a subrange
:> value is required.
:
:Give an example.

The following is a valid Ada83 program (and presumably valid Ada95):

procedure Test_Type_Hole is
  subtype Sub_Integer is Integer range 1 .. 10;
  I: Integer;
  S: Sub_Integer;

  procedure Use_Subtype (S: Sub_Integer) is
  begin
    null;
  end;

begin
  I := 1000;
  Use_Subtype (I);       -- System Invalid call - raises 
                         -- Constraint_Error at runtime.
end Test_Type_Hole;

So, contrary to your claim, Ada *does* permit a form of broken polymorphism.


:Don.
:=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
:Don Harrison             donh@syd.csa.com.au
:
:



-- 
Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Chris Morgan]

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

> Chris, if you are really interested in trying this out, do it the simple
> way first. Write an edit script that adds pragma Inline statements to all
> subprograms in all specs, then recompile the program. That way you can
> get some data as to whether this option would be worthwhile.

Robert has told me how to try this out either the above method or a
local gnat tweak, either of which will be fine until (and if) we
identify a firm need for this facility.

We have found manual control of inlining using pragma inline and the
-gnatn option can offer very good performance increases, but I agree
that a brainless "attempt to inline everything" facility is a rather
marginal extra (but I will probably try it when our project gets built).

Chris
-- 
Never run with scissors.

Re: What is wrong with OO ?

[Fergus Henderson]

tiggr@es.ele.tue.nl (Pieter Schoenmakers) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>   If you allow new classes to be dynamically loaded, then the compiler
>   can't statically bind features of objects whose dynamic type is unknown,
>   but it can still statically bind features of objects whose dynamic type
>   is known.
>
>If a class B can be dynamically loaded, and B is a subclass of the
>statically loaded (i.e. known to the compiler) class A, then every feature
>invocation of an object accessed through a variable of type A, where the
>actual object could just as well be a B, can not be statically bound or
>inlined.

Yes, but often the compiler can prove that the actual object type
must be A, not B.  Some languages, e.g. Ada, allow the programmer to
distinguish between something of type A (meaning just type A, nothing
else) and something of type A'class (meaning something of type A
or some type that inherits from A).  Even if the language doesn't
distinguish, the compiler can often see the type used when an object
is created.

(All I'm trying to say is that you _can_ do useful inter-module
optimization even in the presence of dynamic loading.  Sheesh!)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Robert Dewar]

Ken Garlington wrote

"    type My_Integer is new Integer;
    function To_Int is new Unchecked_Conversion ( My_Integer, Integer );"


Why on earth use an unchecked conversion here when a perfectly ordinary,
and completely safe type conversion will work just fine?

Re: OO, C++, and something much better!

[Don Harrison]

Marky Mark writes:

:Don Harrison <donh@syd.csa.com.au> wrote in article
 ^^^^^^^^^^^^
No, it was Bertrand Meyer.

:> :>> 	- A completely consistent type structure, in which 
:> :>> 	  even basic types such as INTEGER are classes,
:> :>> 	  present in the general inheritance structure.
:> :>> 	  (In C++ or Java, for example, the basic types
:> :>> 	  are completely separate from the class and inheritance
:
:Besides, in a hybrid language like C++ you could always have the best of
:both worlds - encapsulating integers as classes or using the intrinsics as
:you'd like.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Don Harrison]

Robert Dewar writes:

:Don Harrison said
:
:"Yes, these mechanisms are inherently unsafe but their purpose is to allow
:different views of the same data. There are different ways of acheiving
:that and some ways are safer than others. For example, UNCHECKED_CONVERSION
:is safer than overlaying because the data is copied thus protecting the
:original object."
:
:
:That is a misconception. Unchecked_Conversion does not require the data
:to be copied. The whole point of 13.9(12) is to remove this requirement:
:
:12   An implementation may return the result of an unchecked conversion by
:reference, if the Source type is not a by-copy type.  In this case, the
:result of the unchecked conversion represents simply a different (read-only)
:view of the operand of the conversion.

Okay. So, in both cases - whether a copy or a reference is returned -  the
source object is protected. Correct? If so, I don't follow why you might
bother making a copy:

:The design principle here is that since this is a d0-it-at-your-own-risk
:and make-sure-you-know-what-you-are-doing operation, it is inappropriate
:to waste time trying to increase the safety of the operation. If you
:want to ensure that a copy is made, you must make the copy.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Jeff Carter]

Don Harrison wrote:
> 
> The following is a valid Ada83 program (and presumably valid Ada95):
> 
> procedure Test_Type_Hole is
>   subtype Sub_Integer is Integer range 1 .. 10;
>   I: Integer;
>   S: Sub_Integer;
> 
>   procedure Use_Subtype (S: Sub_Integer) is
>   begin
>     null;
>   end;
> 
> begin
>   I := 1000;
>   Use_Subtype (I);       -- System Invalid call - raises
>                          -- Constraint_Error at runtime.
> end Test_Type_Hole;
> 
> So, contrary to your claim, Ada *does* permit a form of broken polymorphism.
> 
Nonsense. This is a violation of an explicit precondition (that the
actual value associated with S be in the range of Sub_Integer).
-- 
Jeff Carter
Innovative Concepts, Inc.

Re: What is wrong with OO ?

[Vos nom et pr�nom]

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


Bjarne Stroustrup <bs@research.att.com> a �crit dans l'article
<E3pzy4.DHE@research.att.com>...
...
> Had C++ not been relatively easy to learn and use reasonably well, it
> would have disappeared long ago. By relative I mean the amount of effort
> needed compared to the amount of benefit gained.

In an absolute way, surely C++ is harder to learn than a lot of other
languages.

Now, let's talk about the "relatively easy to learn". Another way that
effort vs benefit to relativise is language's complexity vs the complexity
of the job to do.
An exemple : if you want to display the "hello world", C++ is not the
better language. 

Conclusion : More and more complex becomes the job to do, the less and less
the language is hard to learn (still talking relatively).
...
> Deciding which member functions should be virtual is a design decision,
> not an optimization. If a designer has provided a poor base class, you
> will typically have problems beyond what can be fixed by overriding.
Just a question about it (I just posted a new thread about this) : when a
member function is better as non virtual ?


-- 
Chris
"The nail pulling up calls the hammer"
                                     zen proverb

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "goubier" == Thierry Goubier <goubier@palmarella.enst-bretagne.fr> writes:

goubier> On 11 Jan 1997, Piercarlo Grandi wrote:
goubier> [On the subject of inlining by the compiler, with B. Meyer]

piercarl> Ideally a compiler would use profiling feedback to evaluate
piercarl> whether it is worth inlining a procedure at a given call site,
piercarl> by running the program with an without (this check ought to be
piercarl> done for each procedure at each call site for which is is
piercarl> possible, and every combination thereof :->).

goubier> I believe this technology already exists, for example in the
goubier> Self 3.0 and 4.0 inlining compilers. Things like polymorphic
goubier> inline caches may be used as a tool to record profiling
goubier> information for the compiler.

From what I have read I haven't the impression that the Self compiler
actually decides _whether_ to inline an implementation using the
profiles/inference used to decide _which_ implementation *can* be
inlined.

In other words, my impression is that Self implementations use
profiles/inference to find out whetherit is _possible_ to inline at some
cal site and which implementatin(s) may be inlined, not whether it is
_useful_ to inline them, and as the latter they use heuristics not
dissimilar from those used in ``Eiffel'' or ``C++'' compilers, such as
the size of the implementation.

Perhaps somebody more familiar with the innards of the Self
implementation can throw some light on this.

BTW, the point I was making above is that one of the great worths of
inlining is that it allows merging the code of the callee in the
caller, and those provides significantly greater/easier opportunities
for optimization. However if there are several call sites of several
different potentially inlinable callees in a given caller procedure,
*which* of these calles at which call sites are worth inlining is not so
obvious for not only merging in the code at each call site with that of
the caller produces _different_ opportunities for optimization, it also
results in merging the codes of the callees as well. *Which* combination
of inlinings is optimal is thus an intricate problem.

Consider the following example (in something like C, so we have that
each implementation has exactly one interface and overload resolution,
offline and inline, does not complicate the picture)

  p(a,b,c)
  {
    .... q1(a); ....
    .... q2(b); ....
    .... q3(c); ....
    .... q1(42); ....
  }

Now each of the four calls to the three implementations might or might
now be worth inlining seaprately; for example 'q1(a)' may not be worth
inlining, but 'q1(42)' later on may well be, because it is passed a
statically know argument. Inlining each of these call sites may produce
positive interactions with the code of their caller. But it may well
happen that inling 'q2(b)' merges in code that then makes the merged in
code of 'q3(c)' significantly more optimizable, but neither call is
worth merging into 'p' on its own.

This effect actually _might_ well be important; after all if there are
several call sites of several procedures in a block it is because they
supposedly cooperate in establishing some result and are thus related,
and this perhaps could well provide good optimizations.

Thus in theory one should verify the possibility for optimization for
every possibly combination of call site inlinings... :-)

What I really think should be done, and this is not a new idea, but one
that is rarely considered, is to do compilers as symbolic reduction
engines, which operate in the domain of instances (that is operate as
intepreters) when such are known and in the domain of abstractions (that
is operate as compilers) when they are not; then inlining would become a
mere byproduct of symbolic reduction between dependent modules.

goubier> But I should let interested people look the Cecil/Vortex
goubier> project to see how this may be used in static compilation. [
goubier> ... ]

That's very interesting work. I also hope that Sun be deploying their
Self technology towards the Java compiler, for it is claimed rather
convincingly that the Self compiler technology can result in Self or
``Smalltalk'' code that runs only twice as slow as C code. Given that
Java is a more constrained sort of language than Self or ``Smalltalk'',
the same technology should get it to deliver much the same performance
as statically compiled C, while instead being dynamically compiled.

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "martin" == Martin ELLISON <martin@mpce.mq.edu.au> writes:

martin> Why can't the compiler optimise the whole program? (Assuming
martin> that it is all written in the same language). Who says that you
martin> have to compile and generate code for each module and then link
martin> them together? Doing so may be quicker for a development
martin> version, but surely a production compile can be optimised across
martin> the whole system.

This is more or less what Ole Agesen has done for type inference in Self
for the production of shrink wrapped applications...

The problem with type inference and OO is that OO modules are supposedly
designed to be as resuable as possible, that is as generic as
possible. Thus type inference returns wide sets of types for
constraints; consider for example a stack class: you can infer that all
variables in it will have a type constraint like 'Object', that is
anything.

Unfortunately such tyep inference is next to useless, for type ifnerence
results in significant safety advantages when type constraints are
narrower, and in optimization when type constrains are narrowest, that
is about a single type.

Since supposedly an OO program is composed mostly of reusable modules,
which are written to be as generic as possible, the situation seems
hopeless.

What Oleg Agesen has done for Self is a kind of type-based ``tree
shaker''; it is base don the idea that if one infers type on reusable
modules *in the context of each application in which they are reused*
then type inference can become significantly stronger (the price of
course one payus to take advantage of it is then code duplication).

So for example a matrix package which is otherwise totally generic can
in the context of a numerical application to be about matrixes of
floats, and in the context of a graphics application to be about
matrixes of integers/pixels.

What then happens is that the whole source of the application is
examined at the same time, and the type constraints of the application,
which are usually quite specific, are propagates across call sites back
to the generic reuable modules that i t references, and these are
specialized for those type constraints. The specialized modules are then
optimized mercilessly as a whole.

This technique naturally has some severe limitations; in practice it is
only useful to develop shrink wrapped, standalone applications, for it
involves a stark tradeoff between code replication and slowness.

Very vaguely similar techniques are used in recent versions of some
``C++'' implementations where template instantion/inlining is in effect
done by the linker in a somewhat clumsy iterative way; or the programmer
does inference by hand listing which templates instances are neded, like
in ``Ada''.

I may be wrong, but the Sather compiler does much the same automatic
process (less clumsily) of global inference and instantiation; in this
is is significantly helped by the rather regrettable limitation which
still exists AFAIK that Sather does not allow separate compilation, so
all modules are merged as _sources_, and (possibly slow) compilation
then on the full source (application plus reusable modules).

Re: OO, C++, and something much better!

[Michael F Brenner]

   > Why does unchecked_conversion require copying? The following 
   > code works fine with my copy of GNAT, and I've used the same 
   > technique on Ada 83 compilers as well...

First, the code in that post gets the following error message
under gnat:

    spectre% gnatmake test_uc
    gcc -c test_uc.adb
    test_uc.adb:13:12: left hand side of assignment must be a variable
    gnatmake: "test_uc.adb" compilation error

Second, unless the code generator in the compiler includes specific
copy optimizations to eliminate the copy, unchecked_conversion is
in the form of a function which logically returns a copy of the 
argument. Unless the compiler has this optimization the code will
make a copy. This is in contrast to the situation where you use
address clauses to overlay variables. Then the two variables are
permanent aliases to each other, and you do not have to copy
the value from one to the other. 

There are many algorithms in mathematics that require an object of 
one type to be considered as an object of another type, for example,
fast Fourier transforms, set membership, ASCII to numerical conversion,
braid group conjugacy, floating point normalization, integer square
root, extracting bits from binary numbers, binary radix exchange
sorting, hash codes, multiple precision integer division, parity bits,
garbage collectores, cyclical redundancy checks, segmenting, and 
pixel maps. In each of these cases, an ordinary exact number (which
happens to be a twos complement on every CPU that survived the
IBM PC era), needs to be viewed as an algebraic integer with
Addition, Subtraction, Multiplication, and Division, YET at the
same time, as a bit string to do And, Or, Xor, Substr, Set_bit,
Set_substr, First_nonzero_bit, Impl, Nand, Nor, Next_bit, and
Bit_merge sequentially according to a bit_pattern_vector. In 
all of these algorithms there is one choice of representing
the <Number As Bitstring> two different memory addresses
with an unchecked_conversion to get the data from one address
to the other. And there is another choice to represent it
as two objects of different types at the same memory
address with an address clause. Without a copy optimization
to remove the copy implied by the output of the function
unchecked_conversion (or any other function), the algorithms
which use unchecked_conversion will run slower than those
using the address overlay technique.

In some cases, such as FFTs and hash codes, that copy time can
occur several times and add up to more than the rest of the
algorithm, so there is evidence for requiring support for
address overlays, and for asking vendors to improve the  
code generation of their compilers to automatically alias
the addresses of objects being converted through unchecked
conversion to their targets address, when this can be done,
so that no copy has to take place. 

Purists sometimes forbid explicit aliasing via addressing overlays.
But that can be short-sighted for the above algorithms, because
aliasing in the address dimension also occurs whenever
a variable has more than one name: equivalences, renames, overlays, 
common variables, objects with tags or discriminants, polymorphisms, 
external objects shared with other languages, parameters passed by 
reference, and pointers. The last three are more troublesome
than the rest (for analysis tools) because they potentially 
involve multiple copies of pointers. Aliasing also occurs in 
the name dimension when a name can refer to two different objects, 
e.g., array elements, homonyms, and inheritance. 

Re: OO, C++, and something much better!

[Don Harrison]

Ken Garlington writes:

:> Yes, these mechanisms are inherently unsafe but their purpose is to allow
:> different views of the same data. There are different ways of acheiving
:> that and some ways are safer than others. For example, UNCHECKED_CONVERSION
:> is safer than overlaying because the data is copied thus protecting the
:> original object.
:
:Why does UC require copying? 

It may not, as Robert Dewar suggests. However, IMO, the source object should
be protected from corruption by any alternative view of its data. One way is
by copying it.

BTW, your program contains an illegal assignment to a function! :)

:    To_Int(Foo) := Bar;
                 ^^


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Vos nom et pr�nom]

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


Piercarlo Grandi <piercarl@sabi.demon.co.uk> a �crit dans l'article
<yf3afqg12ho.fsf@sabi.demon.co.uk>...
> >>> "bertrand" == Bertrand Meyer <bertrand@eiffel.com> writes:
> 
> bertrand> The ISE Eiffel compiler performs inlining completely
> bertrand> automatically.  There is no "pragma inline" or comparable
> bertrand> programmer intervention, since it is not the programmer's job
> bertrand> to worry about whether a routine is inlinable or not. This is
> bertrand> a job for a compiler.
> 
> It seems contrary to reasonabless: there are many contexts where
> inlining is not necessary and others in which it is important, *even for
> the same procedure*. Thus there is (usually) a space/time tradeoff, but
> *at each call site*. It sounds astonishing to me an argument that the
> compiler should try to second guess or infer space/time tradeoffs
> (except perhaps in the simplest cases), in addition to doing its job of
> compiling valid translations of a source.
etc...

Here's my 2cts...
If the function is very short, it's obvious for the compiler to
automatically inline it.
When it's long, it's also obvious not to make it inline.
But where is the point where the short function becomes a long function ?
For all these cases, it's the programmer's responsability to inline or not
regarding size vs speed.

-- 
Chris
"The nail pulling up calls the hammer"
                                     zen proverb

Re: What is wrong with OO ?

[Jay Martin]

lga@sma.ch (Laurent Gasser) writes:

>In article <dewar.853091062@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>> Jay said
>> 
>> "Here is an even more ignorant question: Why is compilation time still
>> a driving factor? (excluding hardcore optimizations) Obviously it
>> still is as I watched large systems compile lately.  But wait, wasn't
>> Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC
>> faster than VC++ on my P5-100.  For fun I compiled old programs with
>> vintage a Turbo Pascal Compiler and it seems to compile these suckers
>> instantanously!"
>> 
>> Yes, but the quality of code turned out by your "vintage Turbo pascal
>> compiler" is truly horrible. 
>[ sound arguments about global optimization and inlining deleted ]

>I am no more sure about the fact for Turbo Pascal.  But it may had used 
>the same strategy than Think Pascal on Mac (once a Lightspeed product, 
>still sold by Symantech today, a record sale life span).  The compilation 
>was extra speedy because the syntax tree building was embodied in the editor.

>While you typed down the source, the syntax was checked and the front
>part of the compilation (decorated syntax tree) was done.

Turbo Pascal was a normal compiler.  

Going back to the original question: I understand that a compiler can
spend an practically infinite time optimizing, but when optimizations
are disabled or restricted to the typical simple ones it still seems
to me that compilers have not kept up with processor speeds.  Its as
if compilers are parallelling the code bloat practices of other
software areas, eating processor cycles as they come available.
Suppose optimizations give a factor of 2X-3X, why would I bother
turning on the time consuming optimizations early in a project needing
a rapid development cycle?  (Though optimized builds could be continiously
be built as a background task)  

Jay

Re: OO, C++, and something much better!

[Don Harrison]

Jeff Carter writes:

:> So, contrary to your claim, Ada *does* permit a form of broken polymorphism.
:> 
:Nonsense. This is a violation of an explicit precondition (that the
:actual value associated with S be in the range of Sub_Integer).

It's both and it shows that Ada is not typesafe.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Bjarne Stroustrup]

"Matt Telles" <matttelles@sprynet.com> writes:

 > Bjarne Stroustrup <bs@research.att.com> wrote in article 
 > > 
 > > First, here is the way I phrased the "learning" criteria in "The Design
 > > and Evolution of C++":
 > > 
 > > 	If in doubt, pick the variant of a feature that is easiest to teach
 > 
 > I certainly agree with this statement.
 > 
 > > C++ is a language primarily aimed at creating production software. Like
 > > all such languages, it together with its associated libraries, tools, and
 > > programming techniques is too large to learn quickly (unless you happen
 > > to be experienced in rather similar languages and techniques - and most
 > > students and programmers are not when they first encounter C++).
 > > Consequently, it must be learned in stages starting with some suitable
 > > subset (and a suitable subset of tools, libraries, programming
 > techniques).
 > 
 > I am curious. Does this imply that you think people should learn another
 > language before C++? Or is it simply that C++ is taught without the proper
 > emphasis on techniques. In my experience, the language is taught
 > syntactically, with little regard for the OO behind it. 

I don't really mind, you can learn C++ as a first language - and use it
as a vehicle for learning sound concepts, principles, and techniques
- or learn it later. I have seen both paths work well - and I have seen
both fail. I have a natural bias for "C++ first" especially for people
who aims at becoming professional software developers, but I am strongly
of the opinion that every programmer should be comfortable in more than
one language.

I do object to the "toy approach" to teaching programming: Give people
a tool that is great for writing little demos, let them produce a few
of those without hitting any hard conceptual barriers, any efficiency
problems, and any limitations of the tool/language. Then let them go
on to something else - such as "high-level design" or management.

That is the way to produce non-programmers with unrealistic estimates
of their own ability and a total lack of understanding of the problems
faced by people who produce production code.

The "the language is taught syntactically, with little regard for
the OO behind it" is exactly what I'm arguing against - as I have
done consistently over the years.


 > > Many are too ambitious and try to learn too much too fast. In particular,
 > > many programmers focus on learning every obscure language detail rather
 > > than overall principles because mastery of programming language details
 > > is what has traditionally been valued in many programming communities.
 > > That way, people get lost in details.
 > 
 > True. Isn't it important then to emphasize the aspects of the language
 > which make it 
 > a) Maintainable and
 > b) Reusable?

I think I do.


 > > Traditionally, C++ has been blessed with a mass of useful libraries, and
 > > cursed by the absence of a good standard library. The lack of a standard
 > > library supplying basic types (such as string, list, and map) reinforced
 > > the bias of some teachers and some teaching materials towards low-level
 > > features and techniques that don't rely on standard library facilities.
 > 
 > Agreed. But where else to begin? If you are teaching C++, they say, learn
 > to write a linked list class, learn to write a string class. I annoyed one
 > of my professors long ago by handing in a linked list class that said
 > simply "refer to chapter xxx in the text". After all, wasn't reuse the
 > point we were trying to stress? How would you teach C++ without emphasizing
 > the low-level functions?


Here is one way:

Initially, you supply people with a good set of basic classes: vector,
list, map, string, iostreams, simple graphics. Nothing too fancy or
daunting. Based on that, you teach the basics of writing small programs
using variables, constants, loops, functions. Then teach how to write
simple classes - such as dates and strings. Then teach how to add classes
to a class hierarchy and how to build a class hierarchy.

Templates are first simply used where needed, and defining new ones is done
wherever the examples need parameterization. The initial set of classes
provides a good set of examples for "dissecting" to understand class design
and implementation. During that "dissection" you introduce the lower-level
facilities as needed to explain the implementation.


 > > I have no idea if any of this apply at your university, but I have seen
 > > all of those phenomena repeatedly. Usually, people manage in the end, and
 > > if not they try something else - which they may or may not find more
 > > suitable.
 > 
 > This is really less of an issue that the "Object Oriented Programming can
 > save the company" bandwagon, in my estimation.
 > 
 > >  > Languages like Eiffel (my personal favorite) are much more suitable
 > for
 > >  > high-level projects; Eiffel, for instance, does not burden the
 > >  > programmer more than needed, and has a clean, clear syntax that can
 > >  > even be immediately understood by people that don't know the language.
 > > 
 > > I do not personally find it so, and such claims reminds me unpleasently
 > > of the similar claims made for COBOL. A non-programmer can sometimes be
 > > convinced that he/she can read simple code, but it is far from obvious
 > > that this is relevant - or ever true - for production code (that will
 > only
 > > be seen by programmers anyway). 
 > 
 > My question is: Does the tool matter? Or is it simply an extension of the
 > concepts behind it. I can write object-oriented code in FORTRAN. It is
 > harder, but it can be done. The amount of work doesn't necessarily make it
 > less possible.

Tools matter. Languages matter. If I didn't think I was seeing evidence of
significant improvements I would have stopped working on C++ years ago.

A good language helps solve some of our problems building good systems,
but it is only part of a solution. This is one reason that there has been
much more good software written in languages deemed bad than in languages
proclaimed great. Often people who focus on language issues are blindsided
by the non-language issues.


 > > Had C++ not been relatively easy to learn and use reasonably well, it
 > > would have disappeared long ago. By relative I mean the amount of effort
 > > needed compared to the amount of benefit gained.
 > 
 > Tell that to COBOL programmers. Or Pascal, or any of the other languages
 > that I have learned at one point or another in my life.

Actually, I have. I have taught C++ to people with COBOL and Pascal
backgrounds (it is easier to those with Pascal background - on average
as easy as to teach it to people with a C background though the problems
faced by Pascal and C programmers tend to differ in interesting ways).

However, it is important to remember the difference between learning
enough to write a student exercise and enough to write a piece of code
to be used by others. I tend to be strongly focussed on the latter -
and sometimes underestimate the importance of the former.


 > The amount of
 > effort to learn the language becomes secondary when the boss tells you to
 > learn it. Why use the Microsoft compiler over the Borland compiler? Because
 > the company standardizes on it...

In an ideal world, people would choose their own languages and their own
tools. I have had the priviledge to deal primarily with people who did
have a choice. There are more of those than is sometimes claimed. Often,
the problem is not lack of choice but that the choice is conditioned by
what others are doing (or what others are perceived to be doing or what
other people are perceived to soon be doing ...).

To be useful, a piece of software has to fit into a very complicated mesh
of real-world concerns - of which the choice of programming langauge is
typically not the most important.


 > > Once a language is used by diverse user communities, one person's serious
 > > flaw becomes another's essential feature. Some of the aspects of C++ that
 > > I dislike most are deemed essential by very competent system builders.
 > > However, C++ has no flaw and no feature lacking that is so serious that
 > > it cannot be managed with reasonable effort in a project - even if they
 > > can be a bother and experienced programmers recognize them as such.
 > 
 > I have a problem here, but it is not with C++. There are certainly flaws in
 > the language. No serious programmer would argue that there are languages
 > which are flawless. The problem is that C++ lets me shoot myself in the
 > foot. In some cases, it aids in loading the gun and aiming it for me. The
 > issue is not the language, but the poor programming practices which
 > encourage it. Why, for example, allow the continued use of void pointers
 > when they lead to nothing but pain and agony in the long run (this is an
 > example, I understand why they were necessary).

As you point out, they are unavoidable so how could I ban them without
saying "go and use C whenever you need to do low-level stuff?" I do not
believe in making a language prettier by making it incomplete and leaving
programmers to write significant parts of their code in a language with
no support for abstraction.


 > Why let me use
 > uninitialized pointers? Do you have any idea how many programs I have
 > debugged for hours because someone failed to write something as basic as:
 > 
 > char *p = NULL;

If I had designed C++ today, every variable that did not have a default
constructor would have to be initialized. When I wrote the first C++
compiler, I had it issue a warning whenever you tried to use an uninitialized
variable. However, I could not ban uninitialized variables without getting
into an unwinnable fight with the C community. I have been quite annoyed
that the quality of warnings against legal but almost certainly wrong
constructs have on average declined. I can hope that they will improve
again now we (almost) have a standard but there is typically no way of
forcing people to do what they really don't want to do.

See "The Design and Evolution of C++" for a discussion of such issues.


 > > Good luck with your projects and the language you favor, and remember
 > > that the world is more complicated that any of us can imagine and that
 > > there are ways of succeeding that we would not personally have chosen.
 > > 
 > > 	- Bjarne
 > > 
 > > Bjarne Stroustrup, AT&T Research,
 > http://www.research.att.com/~bs/homepage.html
 > 
 > I certainly won't argue with someone who created the language. My point is
 > simply that until we solve the problem of programmers believing they are
 > artists, rather than engineers, we will never have quality software.

Maybe, more programmers believe that they are artists than actually are,
and more programmers believe they are engineers than actually are.

I suspect that I'll take the artist and the engineer any time I can find
them, but the real issue is than many aren't even craftsmen yet. We are
seeing progress, but we have a long way to go. In my opiion, education
has to be major part of any solution. This may sound obvious, but there
seems to be no shortage of people in industry who would prefer to reduce
software production to a semi-skilled activity - in which case we would
have to reduce the amount of education and replace most current programmers
with people with less education and more training in following rules.

	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html

Re: What is wrong with OO ?

[Bjarne Stroustrup]

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

 > Bjarne, in the middle of a very nice extended discussion of C++, says
 > 
 > "Had C++ not been relatively easy to learn and use reasonably well, it
 > would have disappeared long ago. By relative I mean the amount of effort
 > needed compared to the amount of benefit gained."
 > 
 > Hmmm! I don't think I buy that. People will learn what is at hand pretty
 > much regardless of whether something is easy to learn and use.
 > ...
 > Going back to the main subject, which is the allegation that popularity
 > indicates ease of learning and use,

I don't think I claimed that, and I don't think that I have to. C++ use grew
very nicely for years without hype. I base my statement on years of looking
at C++ use, teching, and learning - many of those years were before anyone
was given time off from their day job to learn C++.

I think that if C++ was as hard to understand and use as some people claim,
it would have failed to become popular in the first place and would have
vanished under the continuous barrage of fair and unfair criticism - despite
its (eventual) popularity.

 >  I think the point is that such
 > popularity indicates accesibility more than anything else. By accessibility
 > I mean that something is available, viewed as hot, and can be learned well
 > enough to do *something*. Consider the situation today, students want to
 > learn Java, not C++, they see C++ as yesterday's language, and Java as
 > the language of tomorrow. Just from the incredible rate at which Java books
 > are cascading into bookstores, I have to guess that the rate of learning of
 > Java far exceeds the rate of learning of C++. But I would NOT conclude from
 > this that Java is easier to learn or use than C++. Maybe it is, but you
 > cannot conclude anything just from popularity.

It is amazing what hype and serious marketing dollars can do, but what
little objective data I can lay my hands on indicates that C++ use is
still increasing very nicely. However, I have my doubts whether all of
those books will actually help the Java community. 

I have often found myself wondering if the C++ wouldn't have been much better
for all concered had there (just) been two dozen good C++ books instead of
the 400+ books that mostly fail to teach the basic principles and mostly
lead students and programmers astray. The snag, of course, is that we have
no mechanism of separating the good from the bad. I doubt such a mechanism
could exist - at least while things change as fast as they do in our industry
and we have little agreement on what is good and bad.

 > Ada folks have never played the game of claiming popularity as an indicator
 > of any kind of quality, because they have not been able to. I realize that
 > C++ is in a position to make such claims, but I recommend against it, because
 > I think you will find that your arguments will backfire as Java becomes
 > the next hot language, at least for a while :-)

Thanks for the advice. The furthest I go is to claim that unless C++
had at least some of the virtues I claim for it, it would have died during
the early years where there were essentially no C++ marketing and alternatives
languages with marketing dollars behind them existed.

Naturally, even that is invariably mistaken for the disreputable "5 million
morons cannot be wrong" argument :-(

	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html

Re: OO, C++, and something much better!

[Don Harrison]

Robert I. Eachus writes:

:   Casting in C normally maps to type conversions in Ada:

Okay.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Laurent Gasser]

In article <dewar.853091062@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Jay said
> 
> "Here is an even more ignorant question: Why is compilation time still
> a driving factor? (excluding hardcore optimizations) Obviously it
> still is as I watched large systems compile lately.  But wait, wasn't
> Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC
> faster than VC++ on my P5-100.  For fun I compiled old programs with
> vintage a Turbo Pascal Compiler and it seems to compile these suckers
> instantanously!"
> 
> Yes, but the quality of code turned out by your "vintage Turbo pascal
> compiler" is truly horrible. 
[ sound arguments about global optimization and inlining deleted ]

I am no more sure about the fact for Turbo Pascal.  But it may had used 
the same strategy than Think Pascal on Mac (once a Lightspeed product, 
still sold by Symantech today, a record sale life span).  The compilation 
was extra speedy because the syntax tree building was embodied in the editor.

While you typed down the source, the syntax was checked and the front
part of the compilation (decorated syntax tree) was done.

So, when you finally decided to see it running, it only had to generate
the object code and link.

The strategy seemd to be one cause of the abandon of Think Pascal (it still 
only generates 68K, and never did the PowerPC leap).  Today, compiler favor 
a much clearer separation with text editors.

-- 
Laurent Gasser (lga@sma.ch)
Computers do not solve problems, they execute solutions.

Re: What is wrong with OO ?

[Jonas Nygren]

Laurent Gasser wrote:
> 
> I am no more sure about the fact for Turbo Pascal.  But it may had used
> the same strategy than Think Pascal on Mac (once a Lightspeed product,
> still sold by Symantech today, a record sale life span).  The compilation
> was extra speedy because the syntax tree building was embodied in the editor.
> 
> While you typed down the source, the syntax was checked and the front
> part of the compilation (decorated syntax tree) was done.
> 
> So, when you finally decided to see it running, it only had to generate
> the object code and link.
> 

Ah yes, Lightspeed, in my case C, defines what an IDE should be.
Lightning
fast compilation, as Laurent stated, but also linking. LC did not really
link the application when it was inside the IDE, only if you wanted to 
generate a standalone app. The '.o' files were kept linked together in
memory 
and after a file had been compiled these linked '.o' files were patched
up
to link in the new '.o' file, and then the IDE executed the image given
by the
linked '.o' files.

I remember I had a GUI app on my MacPlus where the cycle 'stop testing -
fix something small - compile - link - ready to test again' was under 30
secs,
with a M68000 ~7 MHz!!

I still haven't found anything as fast :-( 

/jonas

Re: OO, C++, and something much better!

[Richard Kenner]

In article <dewar.852928982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>equally if you do something like
>
>   (x = p; x < &p[10]; p += 3)
>
>you can find you have an infinite loop, all quite in accordance with the
>C semantics, although somewhat surprising.

This case must work.  Such a reference to the end of an object is required
to be treated like a reference within the object.

Re: OO, C++, and something much better!

[Ken Garlington]

Robert Dewar wrote:
> 
> Ken Garlington wrote
> 
> "    type My_Integer is new Integer;
>     function To_Int is new Unchecked_Conversion ( My_Integer, Integer );"
> 
> Why on earth use an unchecked conversion here when a perfectly ordinary,
> and completely safe type conversion will work just fine?

Because then it wouldn't demonstrate the use of an unchecked conversion,
would it?
(I _knew_ someone was going to ask that. :)

Anyway, if it didn't already get posted, the example is wrong. It works
with GNAT 3.05,
but is flagged as a compile-time error in 3.07. However, via access
values, an
unchecked conversion could still be used without creating a copy, so the
comment is
still valid: using address specs to create an overlay should not be
significantly less/more safe than unchecked_conversion, at least not for
the reason originally given...

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <5bie2d$eat$1@news.nyu.edu> kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

   In article <dewar.852928982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
   >equally if you do something like
   >
   >   (x = p; x < &p[10]; p += 3)
   >
   >you can find you have an infinite loop, all quite in accordance with the
   >C semantics, although somewhat surprising.

   This case must work.  Such a reference to the end of an object is required
   to be treated like a reference within the object.

Yes, indeed it must work, and it does, but it IS an infinite loop.
So it is probably not what you wanted the program to do....

Ole-Hj. Kristensen

Re: OO, C++, and something much better!

[Fergus Henderson]

kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

>In article <dewar.852928982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>>equally if you do something like
>>
>>   (x = p; x < &p[10]; p += 3)
>>
>>you can find you have an infinite loop, all quite in accordance with the
>>C semantics, although somewhat surprising.
>
>This case must work.  Such a reference to the end of an object is required
>to be treated like a reference within the object.

No, you missed the subtle point of Robert Dewar's example.
(Robert could obviously get a job advertising PC-LINT if he wanted ;-)
If it was `p++' rather than `p += 3', you would be right, but
since it is `p += 3', the behaviour is undefined -- ANSI/ISO C
only allows a reference to one past the end of an object, not
two past the end.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Ken Garlington]

Keith Thompson wrote:
> 
> In <dewar.853194201@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> > Ken Garlington wrote
> >
> > "    type My_Integer is new Integer;
> >     function To_Int is new Unchecked_Conversion ( My_Integer, Integer );"
> >
> >
> > Why on earth use an unchecked conversion here when a perfectly ordinary,
> > and completely safe type conversion will work just fine?
> 
> 1. I think it was meant to be a simple example of what you can do
>    Ada.Unchecked_Conversion, not a useful program.
> 
> 2. A simple conversion wouldn't work; you can't assign to a conversion
>    (unless passing it as an "out" or "in out" parameter is considered
>    assignment).
> 
> 3. Actually, Unchecked_Conversion won't work either; an earlier version
>    of GNAT incorrectly allowed assignment to an Unchecked_Conversion.

As do various Ada83 compilers (which is why I tried it in the first
place!)

> If you really want a writable view of an object with a type other than the
> object's declared type, you can use 'Access and Unchecked_Conversion on
> access types, though it's generally simpler to do an Unchecked_Conversion
> on the type itself in the opposite direction.  Be careful; it's really
> easy to get erroneous execution this way.
> 
> --
> Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
> TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
> 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
> "SPOON!" -- The Tick

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Keith Thompson]

In <dewar.853194201@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Ken Garlington wrote
> 
> "    type My_Integer is new Integer;
>     function To_Int is new Unchecked_Conversion ( My_Integer, Integer );"
> 
> 
> Why on earth use an unchecked conversion here when a perfectly ordinary,
> and completely safe type conversion will work just fine?

1. I think it was meant to be a simple example of what you can do
   Ada.Unchecked_Conversion, not a useful program.

2. A simple conversion wouldn't work; you can't assign to a conversion
   (unless passing it as an "out" or "in out" parameter is considered
   assignment).

3. Actually, Unchecked_Conversion won't work either; an earlier version
   of GNAT incorrectly allowed assignment to an Unchecked_Conversion.

If you really want a writable view of an object with a type other than the
object's declared type, you can use 'Access and Unchecked_Conversion on
access types, though it's generally simpler to do an Unchecked_Conversion
on the type itself in the opposite direction.  Be careful; it's really
easy to get erroneous execution this way.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: What is wrong with OO ?

[Patrick Doyle]

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


In article <01bbd23a$5b667cc0$LocalHost@christophe-leph>,
Vos nom et pr�nom <gaijin@infonie.fr> wrote:
>Just a question about it (I just posted a new thread about this) : when a
>member function is better as non virtual ?

  Suppose a function does some important manipulation of private data
members.  If it were virtual, then an heir class could override this
function without ever calling it, and the data manipulation would never
happen.  This could leave the object in an invalid state.  In C++, the
only way to prevent this is by NOT declaring the function virtual.

  In Eiffel, I presume, this could be prevented using postconditions?


-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: What is wrong with OO ?

[Patrick Doyle]

In article <01bc03db$2de477c0$ba1e1990@ap352pc.us.oracle.com>,
Risto Lankinen <rlankine@us.oracle.com> wrote:
>
>Patrick Doyle <doylep@ecf.toronto.edu> wrote in article
><E440xD.Lu0@ecf.toronto.edu>...
>> 
>>   Suppose a function does some important manipulation of private data
>> members.  If it were virtual, then an heir class could override this
>> function without ever calling it, and the data manipulation would never
>> happen.  This could leave the object in an invalid state.  In C++, the
>> only way to prevent this is by NOT declaring the function virtual.
>
>This is true.  I would like to add, that if *both* the important data
>manipulation *and* virtualness are needed, then there is still a way
>to do it.  Here's how:
>
>--------------------------------------------------
>class Base
>{
>private:
>   virtual void Function_imp()

  I was not aware that private virtual functions existed.  Can a descendant
class override this function even though it does not have access to it?

>Note that *IF* the Java keyword 'final' was also in C++ (in Java
>it means that a member function cannot be overridden, or a class
>cannot be derived) then in the example, 'Base::Function()' could
>itself be a virtual function derived from yet-another-base, but
>then overridden and declared as 'final'.  Obviously this would
>make it possible to stack postcondition checks by doing the same
>'final'-trick to 'Derived::Function_imp()' and have it call, say,
>private virtual 'Function_imp_imp()' that *its* derived classes
>can override...

  Woah, sorry, you lost me here.  Do you have an example of what you're
thinking of?

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: What is wrong with OO ?

[Risto Lankinen]

Hi!

Patrick Doyle <doylep@ecf.toronto.edu> wrote in article
<E440xD.Lu0@ecf.toronto.edu>...
> 
>   Suppose a function does some important manipulation of private data
> members.  If it were virtual, then an heir class could override this
> function without ever calling it, and the data manipulation would never
> happen.  This could leave the object in an invalid state.  In C++, the
> only way to prevent this is by NOT declaring the function virtual.

This is true.  I would like to add, that if *both* the important data
manipulation *and* virtualness are needed, then there is still a way
to do it.  Here's how:

--------------------------------------------------
class Base
{
private:
   virtual void Function_imp()
   {
      // enforce preconditions
      // do 'Base' stuff
   }

public:
   void Function();
   {
      // do some important manipulation of private data
      Function_imp();
      // do more important manipulation of private data
      // enforce postconditions
};

class Derived : public Base
{
private:
   virtual void Function_imp()
   {
      // enforce preconditions
      // do 'Derived' stuff
   }
};
--------------------------------------------------

Then, any derived class can override the implementation, while
the public interface remains the same (hence the postconditions
are checked whenever the method is called, and the integrity of
the object becomes easier to maintain).

Note that *IF* the Java keyword 'final' was also in C++ (in Java
it means that a member function cannot be overridden, or a class
cannot be derived) then in the example, 'Base::Function()' could
itself be a virtual function derived from yet-another-base, but
then overridden and declared as 'final'.  Obviously this would
make it possible to stack postcondition checks by doing the same
'final'-trick to 'Derived::Function_imp()' and have it call, say,
private virtual 'Function_imp_imp()' that *its* derived classes
can override...

terv: Risto

Re: What is wrong with OO ?

[Risto Lankinen]

Hi!

Patrick Doyle <doylep@ecf.toronto.edu> wrote in article
<E448IK.4qI@ecf.toronto.edu>...
> In article <01bc03db$2de477c0$ba1e1990@ap352pc.us.oracle.com>,
> 
>   I was not aware that private virtual functions existed.  Can a
descendant
> class override this function even though it does not have access to it?

Sure can.  The descendant cannot, however, *call* the base version.
Also, the descendant is responsible for using the proper protection
for its own version: 'Derived::Function_imp' can be made public if
that is desired.

> >Note that *IF* the Java keyword 'final' was also in C++ (in Java
[blah blah blah]
> >can override...
> 
>   Woah, sorry, you lost me here.  Do you have an example of what you're
> thinking of?

Here is (in a hypothetical language that looks like C++ but has a
keyword 'final' to declare a class that cannot be derived from; or
a class method that cannot be overridden by a method in a derived
class):

---------------------------------------------
class Bottom
{
public:
   virtual void do()
   {
      // do what bottom objects do
   }
};

class Middle : public Bottom
{
private:
   virtual void do_imp()
   {
      // do what middle objects do
   }

public:
   final void do() // <<<<<<<<<<<< see below (#)
   {
      // middle preconditions
      do_imp();
      // middle postconditions
   }
};

class Top
{
private:
   virtual void do_imp()
   {
      // do what top objects do
   }
};
---------------------------------------------

Note (#):
In original example this function was a non-virtual.  Here, it is
an inherited virtual.  Alas, declaring it 'final' prevents it from
being overridden by any derived class.

If 'Middle::do()' was non-final, the programmer of class 'Top' may
be tempted to override that instead of 'do_imp()', shortcutting the
integrity maintenance performed by 'Middle::do()'.

Furthermore, if class 'Top' has a reason to make its postcondition
more strict, it can declare 'do_imp()' as 'final', and have its own
implementation call a private virtual 'do_imp_imp()'.  Here is such
modified definition of class 'Top' (note how it looks like 'Middle'
in previous example):

---------------------------------------------
class Top
{
private:
   virtual do_imp_imp()
   {
      // do what top objects do
   }

   final void do_imp()
   {
      // top preconditions
      do_imp_imp();
      // top postconditions
   }
};
---------------------------------------------

When a 'Top' object is passed to a function as a 'Base' pointer
or a reference, it performs the following calls, when 'do()' is
called:

   do() [Middle]
    + // middle preconditions
    + do_imp() [Top]
    |  + // top preconditions
    |  + do_imp_imp() [Top]
    |  |  + // do what top objects do <<<<<<<< see below (@)
    |  + // top postconditions
    + // middle postconditions

Note (@):
Because 'Middle::do()' and 'Top::do_imp()' would be final, the
only function that could be overridden is do_imp_imp().  Note,
that doing so cannot by-pass any of the integrity maintenance
that are performed by some of its base classes.

terv: Risto L.

Re: What is wrong with OO ?

[Mark Woodruff]

Vos nom et pr�nom wrote:

> If the function is very short, it's obvious for the compiler to
> automatically inline it.
> When it's long, it's also obvious not to make it inline.

When should a call to Ackerman() be inlined? Or exit()?

Key questions seem to be: 

What information is required to make the decision?
Can the information be represented programatically?
Can an algorithm be written to make the decision?

I'm not convinced it's decidable because performance criteria frequently can't be 
determined in advance. Should a function be inlined if the resultant code pushes 
code onto a new page and causes page faults?
-- 
My views may reflect the presence of the company I'm in
but don't reflect my company's views nor my clients.

Re: OO, C++, and something much better!

[Jon S Anthony]

Don writes:

> Jon S Anthony writes:							    
> 									      
> :> For example, by using the value of a parent type where a subrange	    
> :> value is required.							    
> :									    
> :Give an example.							    
> 									      
> The following is a valid Ada83 program (and presumably valid Ada95):	    
> 									      
> procedure Test_Type_Hole is						    
>   subtype Sub_Integer is Integer range 1 .. 10;				    
>   I: Integer;								    
>   S: Sub_Integer;							    
> 									      
>   procedure Use_Subtype (S: Sub_Integer) is				    
>   begin									    
>     null;								    
>   end;									    
> 									      
> begin									    
>   I := 1000;								    
>   Use_Subtype (I);       -- System Invalid call - raises 		    
> 			   -- Constraint_Error at runtime.		    
> end Test_Type_Hole;							    
> 									      
> So, contrary to your claim, Ada *does* permit a form of broken polymorphism.

Don.  What in the world are you talking about???  This is just plain
wrong and even borders on outright silly.  Where's the polymorphism of
any form here?  Subtypes are ways of defining constraints (simple
"assertions") on the possible values of the type.  Sub_Integer is not
a new type and is not a type derivation.  So, you only have one type
here (Re: RM: 3.2(8))

The CE, is simply stating that you have violated the constraint
(assertion).  No polymorphism broken or otherwise involved.

Also, while it is certainly not necessary, this case is so simple (for
DFA) I am a little surprised that GNAT did not give a warning about
this at compile time.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Matthew Heaney]

In article <E44u82.6uB@syd.csa.com.au>, donh@syd.csa.com.au wrote:

>:Where's the polymorphism of
>:any form here?  Subtypes are ways of defining constraints (simple
>:"assertions") on the possible values of the type.  Sub_Integer is not
>:a new type and is not a type derivation.  So, you only have one type
>:here (Re: RM: 3.2(8))
>:
>:The CE, is simply stating that you have violated the constraint
>:(assertion).  No polymorphism broken or otherwise involved.
>
>Yes, if you define subtypes as such, then I concede it may be more reasonable 
>to regard this as simply an assertion violation and declare the type system
>free of holes. It's a question of definition.

Precisely, Don.  It *is* question of definition, and we're comparing apples
and oranges.  You may want to read any of Peter Wegner's papers, where he
explains the difference between a "type" and a "class."

A type has "range" semantics.  Subtypes of the type constrain the range of
values objects of the type can have.

A class has "template" semantics.  A subclass specializes the behavior of
the parent.

Jon is correct in pointing out that the example you gave is an example of
the former.  Sub_Integer is a subtype (in the Wegner sense) that denotes a
subset of the values of its parent.  There is no polymorphism, because we
aren't dealing with classes (in the Wegner sense).

(Note that the term class as used by Wegner is not the same as the Ada 95
meaning.  In Ada, a class refers to a family of types.)

And as far as your example "proving" that Ada is not type-safe: that is
incorrect.  In fact the behavior proves just the opposite.

Constraint_Error was raised because the range constraint was violated. 
This behavior is similar to the Eiffel behavior when a precondition is not
satisfied.  The terms of the contract between the client (the caller) and
server (the subprogram) were violated by the client, so an exception was
raised.  Isn't that what you would expect to happen?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: What is wrong with OO ?

[Lawrence G. Mayka]

bs@research.att.com (Valerie Torres) wrote:

>In the area of exceptions, C++ may have added something important:
>C++ exceptions can be of arbitrary type and inheritance is taken
>into account when catching an exception. This provides important
>possibilities for grouping exceptions that I don't know precedence
>for (though the need for grouping has been known for decades).

The use of inheritance in defining and handling conditions dates at
least back to Symbolics' New Error System, circa 1984, which was the
forerunner of the Pittman Condition System, circa 1985.  The latter
quickly found its way into the other commercial Common Lisp
implementations and was incorporated into ANSI Common Lisp.


Lawrence G. Mayka
lgmayka@sprynet.com

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "gaijin" =3D=3D Vos nom et pr=E9nom <gaijin@infonie.fr> writes:

piercarl> It seems contrary to reasonabless: there are many contexts
piercarl> where inlining is not necessary and others in which it is
piercarl> important, *even for the same procedure*. Thus there is
piercarl> (usually) a space/time tradeoff, but *at each call site*. It
piercarl> sounds astonishing to me an argument that the compiler should
piercarl> try to second guess or infer space/time tradeoffs (except
piercarl> perhaps in the simplest cases), in addition to doing its job
piercarl> of compiling valid translations of a source.

gaijin> Here's my 2cts...  If the function is very short, it's obvious
gaijin> for the compiler to automatically inline it.  When it's long,
gaijin> it's also obvious not to make it inline.  But where is the point
gaijin> where the short function becomes a long function ?  For all
gaijin> these cases, it's the programmer's responsability to inline or
gaijin> not regarding size vs speed.

Those are good points, but not necessarily true. The situation is
*really* subtler than most people think.

Consider the two extremes:

Should we always inline very short functions?

  Not necessarily, because this makes a number of activities, from
  profiling to debugging/backtracing rather harder, for it breaks simple
  correspondences between the structure of the source and that of the
  generated code. Also, it is not always worth doing it, and by default
  it should not be done unless there is a clear advantage; consider for
  example an inline functione like:

    vs(x) { return (x > 0) ? take_a_long_time : also_take_along_time)() ; }

Should we always leave outofline very long functions?

  Not necessarily, because when they are inlined they might shrink
  dramatically. Consider:

    vl(x) { if (x < 0) return 0; else { ... /*lots of lines*/ }; }
    ....
    vl(-23); // this is worth inlining

Again the choice depends often on the context of the call site.

Re: What is wrong with OO ?

[Michael Malak]

In article <5bo7nq$b8b@news.istar.ca>,
Tom Bushell <tbushell@fox.nstn.ns.ca> wrote:
>
>As I believe someone else already pointed out, the C++ compiler
>convention of creating an optimized, native code, standalone
>executable file on disk is ass backwards - this should be a batch
>operation that is performed once to create the production version of
>the program.  The rest of the time, it is much more important to allow
>rapid turnaround for modifications, at the expense of execution speed
>if necessary.

The reason C++ is not interpreted is because there don't even exist
correct C++ _compilers_ that conform to the ANSI Draft Working Paper.
And the reason for that, of course, is because C++ is a complicated,
quickly evolving (mutating?) language.

-- 
Michael Malak         Magic forwarding e-mail address:
Washington, DC        malak@acm.org

Re: What is wrong with OO ?

[Tom Bushell]

On Wed, 15 Jan 1997 14:13:05 +0100, Jonas Nygren
<ehsjony@ehs.ericsson.se> wrote:

>
>I remember I had a GUI app on my MacPlus where the cycle 'stop testing -
>fix something small - compile - link - ready to test again' was under 30
>secs,
>with a M68000 ~7 MHz!!

30 seconds seems like a lifetime after you get used to RAD languages
like Smalltalk, VB, or Prograph.  Turnaround is instant, and you can
usually fix the program _while it is running_ - no need to even
restart.  This allows the programmer to much more easily stay in an
immersive state of "flow", and probably accounts for a large portion
of the productivity gains possible with these language/environments.

As I believe someone else already pointed out, the C++ compiler
convention of creating an optimized, native code, standalone
executable file on disk is ass backwards - this should be a batch
operation that is performed once to create the production version of
the program.  The rest of the time, it is much more important to allow
rapid turnaround for modifications, at the expense of execution speed
if necessary.

I was impressed by the description of Eiffel's approach to this -
sounds exactly right to me.

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E42nv9.LL7@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Jeff Carter writes:
> 
> :> So, contrary to your claim, Ada *does* permit a form of broken polymorphism.
> :> 
> :Nonsense. This is a violation of an explicit precondition (that the
> :actual value associated with S be in the range of Sub_Integer).
> 
> It's both and it shows that Ada is not typesafe.

Sorry, Don.  You are in the weeds.  It shows absolutely nothing of the
kind.  Ada may or may not be "type safe" but your absurd example has
nothing to say on the matter.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Eirik Mangseth]

Tom Bushell wrote:
> 
> On Wed, 15 Jan 1997 14:13:05 +0100, Jonas Nygren
> <ehsjony@ehs.ericsson.se> wrote:
> 
> >
> >I remember I had a GUI app on my MacPlus where the cycle 'stop testing -
> >fix something small - compile - link - ready to test again' was under 30
> >secs,
> >with a M68000 ~7 MHz!!
> 
> 30 seconds seems like a lifetime after you get used to RAD languages
> like Smalltalk, VB, or Prograph.  Turnaround is instant, and you can
> usually fix the program _while it is running_ - no need to even
> restart.  This allows the programmer to much more easily stay in an
> immersive state of "flow", and probably accounts for a large portion
> of the productivity gains possible with these language/environments.
> 
> As I believe someone else already pointed out, the C++ compiler
> convention of creating an optimized, native code, standalone
> executable file on disk is ass backwards - this should be a batch
> operation that is performed once to create the production version of
> the program.  The rest of the time, it is much more important to allow
> rapid turnaround for modifications, at the expense of execution speed
> if necessary.
> 
> I was impressed by the description of Eiffel's approach to this -
> sounds exactly right to me.

Check out Bertrand Meyer's article regarding the work ISE is doing on
concurrency in Eiffel. It's a gem and Mr. Meyer is just impressive.

(Just hope he signs my copy of the OOSC 2nd ed. book)

> 
> -Tom
> 
> ----------------------------------------------------------
> Tom Bushell           * Custom Software Development
> Telekinetics            * Process Improvement Consulting
> 2653 Highway 202          * Technical Writing
> RR#1, Elmsdale, NS
> B0N 1M0
> (902)632-2772         Email: tbushell@fox.nstn.ns.ca
> ----------------------------------------------------------

Eirik M.

/Eirik Mangseth			United Consultants A/S, Oslo Office, Norway
ema@uc-unitedconsultants.com	"Quality Software Through Quality People"
(TM)
emangset@online.no								/

Re: OO, C++, and something much better!

[Norman H. Cohen]

Don Harrison, referring to the fact that Ada subtype constraints are
checked at run time, wrote:

> ... it shows that Ada is not typesafe.

Wrong.  It shows that Ada is not subtype-safe.  Anyone who expects
otherwise does not understand how the term "subtype" is used in Ada.

Long before Luca Cardelli used the term "subtype" to mean a type bearing
a certain relationship to some other type, Ada used the term to mean a
subset of the values of a given type, consisting of those values of the
type obeying a particular constraint.  In Ada, a subtype is not a kind
of type, and distinctions between subtypes are qualitatively different
from distinctions between types.  It can be determined at compile time
that the value of an expression belongs to a particular type, but it
cannot in general be determined until run time whether the value of an
expression obeys the constraint of a particular subtype.  (Indeed, the
answer may be different for different evaluations of the expression.) 
One cannot, in general, deduce from the fact that A and B belong to a
particular subtype that A+B will as well.

Ada subtypes are specifically meant to express assertions beyond those
implicit in the type of an expression.  These are assertions about
values, assertions that cannot, in general, be checked until those
values are generated.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: What is wrong with OO ?

[Kent Budge, sandia,]

Michael Malak wrote:
...
> The reason C++ is not interpreted is because there don't even exist
> correct C++ _compilers_ that conform to the ANSI Draft Working Paper.
> And the reason for that, of course, is because C++ is a complicated,
> quickly evolving (mutating?) language.
> 
...
But there is at least one C++ interpreter out there -- CenterLine C++.
Of course, it's not fully consistent with the latest ANSI working paper, 
for the reasons you mention.

-- 

-Kent

-------------------------------------------------------------------------------
					   
     _/_/_/  _/    _/  _/          SANDIA NATIONAL LABORATORIES    
_/_/_/    
   _/       _/_/  _/  _/          Department 9231                   
_/_/    
  _/_/_/   _/ _/ _/  _/          Albuquerque, NM 87185-0819    
_/_/_/_/_/_/
       /  _/  _/_/  _/          tel: 505 284 3825              _/  _/_/ 
_/
_/_/_/   _/    _/  _/_/_/_/    fax: 505 844 0918              _/  _/_/ 
_/
                                                                _/_/_/ 
  Computational Physics Research             
 and Development Department               Kent G. Budge -
kgbudge@sandia.gov
-------------------------------------------------------------------------------

(usual disclaimer)
Return address hacked to foil junk mail; edit before replying.

Re: OO, C++, and something much better!

[Keith Thompson]

In <32DCFB78.605A@lmtas.lmco.com> Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
[...]
> However, via access values, an unchecked conversion could still be used
> without creating a copy, so the comment is still valid: using address
> specs to create an overlay should not be significantly less/more safe
> than unchecked_conversion, at least not for the reason originally
> given...

Personally, I'd still be more comfortable using Unchecked_Conversion
rather than overlays.  Part of this is a remnant of Ada-83-think; Ada
83 specifically stated that overlays are erroneous.  Also, it's not
necessarily guaranteed that updating one of the overlaid objects will
update the other; one of the objects may be cached in a register when
the other is updated.

I believe that applying pragma Volatile to one or both objects will
solve this problem (though there may still be some problems I'm missing).

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: OO, C++, and something much better!

[Don Harrison]

Jon S Anthony writes:

:Where's the polymorphism of
:any form here?  Subtypes are ways of defining constraints (simple
:"assertions") on the possible values of the type.  Sub_Integer is not
:a new type and is not a type derivation.  So, you only have one type
:here (Re: RM: 3.2(8))
:
:The CE, is simply stating that you have violated the constraint
:(assertion).  No polymorphism broken or otherwise involved.

Yes, if you define subtypes as such, then I concede it may be more reasonable 
to regard this as simply an assertion violation and declare the type system
free of holes. It's a question of definition.

:Also, while it is certainly not necessary, this case is so simple (for
:DFA) I am a little surprised that GNAT did not give a warning about
:this at compile time.

I compiled it with the Sun Ada 1.1(f) Ada83 compiler. I agree it ought to
give a warning.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Alan Lovejoy]

Matthew Heaney wrote:
> 
> In article <E44u82.6uB@syd.csa.com.au>, donh@syd.csa.com.au wrote:
> 
> >:Where's the polymorphism of
> >:any form here?  Subtypes are ways of defining constraints (simple
> >:"assertions") on the possible values of the type.  Sub_Integer is not
> >:a new type and is not a type derivation.  So, you only have one type
> >:here (Re: RM: 3.2(8))
> >:
> >:The CE, is simply stating that you have violated the constraint
> >:(assertion).  No polymorphism broken or otherwise involved.
> >
> >Yes, if you define subtypes as such, then I concede it may be more reasonable
> >to regard this as simply an assertion violation and declare the type system
> >free of holes. It's a question of definition.
> 
> Precisely, Don.  It *is* question of definition, and we're comparing apples
> and oranges.  You may want to read any of Peter Wegner's papers, where he
> explains the difference between a "type" and a "class."
> 
> A type has "range" semantics.  Subtypes of the type constrain the range of
> values objects of the type can have.
> 
> A class has "template" semantics.  A subclass specializes the behavior of
> the parent.

There was a pretty big fight in c.l.st and comp.object over whether a Smalltalk 
class is a "type" about a year ago. Most profesional Smalltalkers maintained
that the two concepts are different.  A few others made the opposite case.

Of course, one is free to select any definition one cares to for the terms
"type" and "class."  The two sides were using different definitions for BOTH
terms, it turned out.  Wegner's definition of type is different than that 
used by either side in last year's debate.  Wegner's definition appears to
be based on type theory (nothing wrong with that).  

However, the type-theoretic notion of type is not the same as that commonly 
used in computer science and most programming language texts, where it is short 
for "data type." A data type defines the structure and interpretation of a section 
of computer memory, which indirectly defines a set or range of representable 
values--which may vary depending on the compiler/flags and CPU architecture used 
to compile and run the program (similarly, floating point numbers are not really 
the same thing as real numbers in mathematics--even though the former is meant 
to simulate the latter).  

The term "type" is also sometimes used instead of "abstract data type."  An 
abstract data type includes the concepts of information hiding and interface.  
The ADT still specifies the structure and interpretation of a section of computer 
memory--but it does so in such a way that the specification is hidden from all 
clients of the ADT, permitting the specification to change, perhaps even dynamically.
It does this by separating the specification of the interface to the ADT from
the specification of its implementation (both parts must exist in order to 
actually instantiate and use values of the ADT).

Also, an ADT specifies the interface of values of the type.  That is, it specifies
what functions/operators can be applied to values of the ADT.

I contend that classes in C++ (for example) are pseudo-ADTs with inheritance, a 
limited form of dynamic dispatching (virtual functions), but imperfect information
hiding.  Hence, a C++ class is effectively a type if one uses "type" as an alias
for "data type"/"abstract data type".

In contrast, a Java "interface" is a true ADT that also supports inheritance and
a less-limited form of dynamic dispatching.  A Java interface conforms to a
Smalltalker's concept of "type": the interface to an object (what messages one
can send and what will visibly happen as a result).

As for Smalltalk classes...well, we already had that debate last year :-).  But
I will say that a Smalltalk class resembles the hidden part of an ADT that specifies
a particular implmentation of the ADT.  Of course, more than one class can implement
that same interface--and the classes don't have to be related by inheritance...

> Jon is correct in pointing out that the example you gave is an example of
> the former.  Sub_Integer is a subtype (in the Wegner sense) that denotes a
> subset of the values of its parent.  There is no polymorphism, because we
> aren't dealing with classes (in the Wegner sense).

Good point.

> (Note that the term class as used by Wegner is not the same as the Ada 95
> meaning.  In Ada, a class refers to a family of types.)
> 
> And as far as your example "proving" that Ada is not type-safe: that is
> incorrect.  In fact the behavior proves just the opposite.
> 
> Constraint_Error was raised because the range constraint was violated.
> This behavior is similar to the Eiffel behavior when a precondition is not
> satisfied.  The terms of the contract between the client (the caller) and
> server (the subprogram) were violated by the client, so an exception was
> raised.  Isn't that what you would expect to happen?

Yep.  Just like what happens in a dynamically-typed language: a "message not
understood" exception is raised when an object with the wrong value is sent
a message it can't handle (the class of an object is part of its value in
a dynamically-typed language).

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Norman H. Cohen]

Alan Lovejoy wrote:
> 
> Matthew Heaney wrote:
...

> > Constraint_Error was raised because the range constraint was violated.
> > This behavior is similar to the Eiffel behavior when a precondition is not
> > satisfied.  The terms of the contract between the client (the caller) and
> > server (the subprogram) were violated by the client, so an exception was
> > raised.  Isn't that what you would expect to happen?
> 
> Yep.  Just like what happens in a dynamically-typed language: a "message not
> understood" exception is raised when an object with the wrong value is sent
> a message it can't handle (the class of an object is part of its value in
> a dynamically-typed language).

Or, to put it another way, the types of a dynamically typed language are
like the subtypes (subsets of types defined by constraints checked at
run time) of a statically typed language with one type.  

The advantage of a statically typed language is that it enables the
designer to divide the objects the program will be using into groups, so
that those objects "understanding a particular message" are in the same
group, to adopt the convention that certain variables will only be used
for objects in a certain group, and to send messages only to objects in
groups that are known to understand them--and to have the compiler
enforce these conventions and catch errors before a program is ever
executed.  (In a strongly-typed language with class-based polymprohism,
these groups need not be disjoint, but instead may be nested.)

There is ample evidence that errors caught at compile time are less
costly to identify and eliminate than errors caught only when a certain
point is reached in execution.  Furthermore, the greater the number of
errors that are caught independent of any particular execution path
being taken, the smaller the number of errors that will be present in a
delivered product.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Alan Lovejoy]

Norman H. Cohen wrote:
> 
> Alan Lovejoy wrote:
> >
> > Matthew Heaney wrote:
> ...
> 
> > > Constraint_Error was raised because the range constraint was violated.
> > > This behavior is similar to the Eiffel behavior when a precondition is not
> > > satisfied.  The terms of the contract between the client (the caller) and
> > > server (the subprogram) were violated by the client, so an exception was
> > > raised.  Isn't that what you would expect to happen?
> >
> > Yep.  Just like what happens in a dynamically-typed language: a "message not
> > understood" exception is raised when an object with the wrong value is sent
> > a message it can't handle (the class of an object is part of its value in
> > a dynamically-typed language).
> 
> Or, to put it another way, the types of a dynamically typed language are
> like the subtypes (subsets of types defined by constraints checked at
> run time) of a statically typed language with one type.

The analogy can certainly be made (wether it's a perfect one or not is
another question--one which is probably not worth considering on USENET).

> The advantage of a statically typed language is that it enables the
> designer to divide the objects the program will be using into groups, so
> that those objects "understanding a particular message" are in the same
> group, to adopt the convention that certain variables will only be used
> for objects in a certain group, and to send messages only to objects in
> groups that are known to understand them--and to have the compiler
> enforce these conventions and catch errors before a program is ever
> executed.  (In a strongly-typed language with class-based polymprohism,
> these groups need not be disjoint, but instead may be nested.)

Static typing has both advantages and disadvantages with respect to dynamic
typing.   The question is which is better in particular circimstances.

There is some execution speed penalty for dynamic typing, so that may rule
out its use.  Program correctness may be so much more critical than development
time--and the product is not in danger of being shipped when some deadline
occurs, whether it's ready or not--that static typing would clearly be the
preferred approach.

> There is ample evidence that errors caught at compile time are less
> costly to identify and eliminate than errors caught only when a certain
> point is reached in execution.  Furthermore, the greater the number of
> errors that are caught independent of any particular execution path
> being taken, the smaller the number of errors that will be present in a
> delivered product.

Sure.  Everyone agrees that catching errors at compile time is less costly.

However, dynamic typing results in signficantly faster development time.
So as long as the number of typing errors that occur in practice are low
enough, dynamic typing is still a net win.  In my experience, the frequency
of occurrence of such errors is about 2% of all errors--which is much lower
than the break-even point.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Alan Lovejoy]

Fergus Henderson wrote:
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> >Sure.  Everyone agrees that catching errors at compile time is less costly.
> >
> >However, dynamic typing results in signficantly faster development time.
> 
> That is highly debatable.  My experience is that static typing results
> in faster development time.

Really?

So then, why have so many investment banks adopted Smalltalk as the language
of choice for doing securities trading applications?  The reason typically
given is that development speed in Smalltalk is so much faster--which boils
down to big bucks on the trading floor.  Could the financial people be wrong?  

Ok, some of them use OpenStep/Objective-C instead--but Objective-C is dynamically
typed (if the value is an object), so that doesn't change anything.

Perhaps you should go to J P Morgan and try to convince them that the bank would 
be better off using C++?  Ha!  I can just see that conversation... :-)  (Actually, 
they do use C, C++ and Galaxy in some projects where it makes sense).

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Patrick Doyle]

In article <E3z0zy.9qL@syd.csa.com.au>,
Don Harrison <donh@syd.csa.com.au> wrote:
>
>The following is a valid Ada83 program (and presumably valid Ada95):
>
>procedure Test_Type_Hole is
>  subtype Sub_Integer is Integer range 1 .. 10;
>  I: Integer;
>  S: Sub_Integer;
>
>  procedure Use_Subtype (S: Sub_Integer) is
>  begin
>    null;
>  end;
>
>begin
>  I := 1000;
>  Use_Subtype (I);       -- System Invalid call - raises 
>                         -- Constraint_Error at runtime.
>end Test_Type_Hole;
>
>So, contrary to your claim, Ada *does* permit a form of broken polymorphism.

  To me, this seems more of a broken assertion than broken polymorphism.

  (However, I've never use Ada in my life... :-)

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: What is wrong with OO ?

[Robert C. Martin]

In article <E448IK.4qI@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
Doyle) wrote:

>   I was not aware that private virtual functions existed.  Can a descendant
> class override this function even though it does not have access to it?
> 

Yes.  Visibility is not the same as accessibility.  You can override anything
that is visible, even if it is unaccessable.

If a class D overrides a private function F of its base B, the functions of 
D still cannot access B::f, but they *can* access D::f.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: OO, C++, and something much better!

[Fergus Henderson]

Alan Lovejoy <alovejoy@concentric.net> writes:

>Sure.  Everyone agrees that catching errors at compile time is less costly.
>
>However, dynamic typing results in signficantly faster development time.

That is highly debatable.  My experience is that static typing results
in faster development time.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "lgmayka" == Lawrence G Mayka <lgmayka@sprynet.com> writes:

lgmayka> bs@research.att.com (Valerie Torres) wrote:

bs> In the area of exceptions, C++ may have added something important:
bs> C++ exceptions can be of arbitrary type and inheritance is taken
bs> into account when catching an exception. This provides important
bs> possibilities for grouping exceptions that I don't know precedence
bs> for (though the need for grouping has been known for decades).

lgmayka> The use of inheritance in defining and handling conditions
lgmayka> dates at least back to Symbolics' New Error System, circa 1984,
lgmayka> which was the forerunner of the Pittman Condition System, circa
lgmayka> 1985.  The latter quickly found its way into the other
lgmayka> commercial Common Lisp implementations and was incorporated
lgmayka> into ANSI Common Lisp.

Unfortunately exceptions-as-object is a bad idea, and claiming priority
for bad ideas is hardly a sport worth engaging into. :-)

Re: What is wrong with OO ?

[Matthew Heaney]

In article <E424x4.5A3@research.att.com>, bs@research.att.com (Bjarne
Stroustrup) wrote:


> > Why let me use
> > uninitialized pointers? Do you have any idea how many programs I have
> > debugged for hours because someone failed to write something as basic as:
> > 
> > char *p = NULL;
>
>If I had designed C++ today, every variable that did not have a default
>constructor would have to be initialized.

Perhaps it has already been stated elsewhere in this thread, but in Ada,
access objects are by default initialized to null.  An attempt to
dereference a null access value raises Constraint_Error.

I see C++, Ada, and Eiffel being on a scale of safety with respect to
pointers (and other things, too).

Eiffel takes the attitude that pointers are unsafe (they can be), so
removes them from the language.  This is the approach taken by Java, too.

C++ is pragmatic, and given its C and systems-programming roots, has
pointers, and you can basically do anything you want.  In fact, a pointers
are often used to do a typeless kind of programming; this is the norm, for
example, in making UNIX system calls.  But there is little safety in that
approach, and your example proves the point that perhaps some built-in
support for pointer-safe programming is called for.

Ada is in the middle: it's pragmatic *and* safe.  You are free to use
pointers, but pointer type "casting" is not allowed.  Pointers to
statically declared objects are safe too, because you are only allowed to
point to an object that has a longer life than you.  "Reference" variables
are made safe by parameterizing the object with a reference to a
longer-lived object.

Of course, if you really do want to leave the type system in Ada, you can
do so by explicitly marking the conversion or dereference as "unchecked." 
So you can have your cake and eat it too.

I have said it before: I like Eiffel, and don't disagree with its
philosophy, but I think there's room for pragmatism.  I think Bjarne would
agree that it's important to give programmers all the tools they need to do
their job, and that includes pointers.  Ada's philosophy is give them
pointers, but make pointer manipulation safe.

If you are frustrated by repairing code that is broken because of
non-initialized pointers, then perhaps you should give Ada a try. 
Programming is a lot more productive then debugging, and a lot less
frustrating.

-matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Exceptions as objects (was Re: What is wrong with OO ?)

[Patrick Doyle]

In article <yf3sp3y9ur6.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>
>Unfortunately exceptions-as-object is a bad idea, and claiming priority
>for bad ideas is hardly a sport worth engaging into. :-)

  Could you elaborate on why that is a bad idea?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: What is wrong with OO ?

[Jay Martin]

bs@research.att.com (Bjarne Stroustrup) writes:


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

> > Bjarne, in the middle of a very nice extended discussion of C++, says
> > 
> > "Had C++ not been relatively easy to learn and use reasonably well, it
> > would have disappeared long ago. By relative I mean the amount of effort
> > needed compared to the amount of benefit gained."
> > 
> > Hmmm! I don't think I buy that. People will learn what is at hand pretty
> > much regardless of whether something is easy to learn and use.
> > ...
> > Going back to the main subject, which is the allegation that popularity
> > indicates ease of learning and use,

>I don't think I claimed that, and I don't think that I have to. C++ use grew
>very nicely for years without hype. I base my statement on years of looking
>at C++ use, teching, and learning - many of those years were before anyone
>was given time off from their day job to learn C++.

>I think that if C++ was as hard to understand and use as some people claim,
>it would have failed to become popular in the first place and would have
>vanished under the continuous barrage of fair and unfair criticism - despite
>its (eventual) popularity.

I find this incredibly naive.  C++ is popular because it is perceived
as "C version 2" or "C 8X-9X".  You pretty much automatically get
usage by a large number of C programmers.  That it came from Bell Labs
pretty much guaranteed its success over Objective C which came from
some pint size "is it out of business yet" company.  Since C
programmers are notorously ignorant of computer language design, the
audience is not too discerning.  Suppose instead that you had chosen
to do an almost identical language except with a clean well designed
syntax that was not syntactically upward compatible from C.  I believe
this "alternate reality C++" would have failed miserably.  I thought
it was brilliant the way you appealed to the anti-SE neanderthal
dark-side of C programmers with the "No nanny-ism, any safety checks
would be "dangerous" and demeaning".  You see there is a huge segment
of programmers who love the arcane, the complex and the hard to
understand.  This is because they are smart and they know that hard to
learn tools that require alot of special expertise will give them a
competive advantage in the programming marketplace because it limits
the number of programmers that can do the work thus guaranting high
salaries and job security!  Thus "high learning curve" tools leads to
daydreams of speeding down the freeway in your high powered BMW
convertable with an adoring and beautiful big titted blond bimbo at
your side.

Is their any wonder why the software field is not "rational"?

Still I find C++ a remarkable job given that you had to stay upward
compatible (syntax/sematically and philosophy-wise) with a turd.

> >  I think the point is that such
> > popularity indicates accesibility more than anything else. By accessibility
> > I mean that something is available, viewed as hot, and can be learned well
> > enough to do *something*. Consider the situation today, students want to
> > learn Java, not C++, they see C++ as yesterday's language, and Java as
> > the language of tomorrow. Just from the incredible rate at which Java books
> > are cascading into bookstores, I have to guess that the rate of learning of
> > Java far exceeds the rate of learning of C++. But I would NOT conclude from
> > this that Java is easier to learn or use than C++. Maybe it is, but you
> > cannot conclude anything just from popularity.

>It is amazing what hype and serious marketing dollars can do, but what
>little objective data I can lay my hands on indicates that C++ use is
>still increasing very nicely. However, I have my doubts whether all of
>those books will actually help the Java community. 

This field is driven by marketing and rational behavior is at a
minimum.  Sometimes I wish a rational force like some academic
scholars would actually study the field in an objective fashion.
Alas, CS Academia is total failure (I will restrain myself from the
usual explicative strewn rant).  Anyway, any argument based
on the rationality of field "like it must be good because people
use it" is nonsense.  There are just too many non-SE factors
in these decisions.
  

I think though Java may turn out to be a better software engineering
language than C++ and Ada95 as it contains two extra design
philosophies which I deem necessary for good language design:

                                 C++      Ada95     Java
1. Simplicity                    No        No        Yes
2. Programmers are morons.       No        Yes       Yes


> > Ada folks have never played the game of claiming popularity as an indicator
> > of any kind of quality, because they have not been able to. I realize that
> > C++ is in a position to make such claims, but I recommend against it, because
> > I think you will find that your arguments will backfire as Java becomes
> > the next hot language, at least for a while :-)

>Thanks for the advice. The furthest I go is to claim that unless C++
>had at least some of the virtues I claim for it, it would have died during
>the early years where there were essentially no C++ marketing and alternatives
>languages with marketing dollars behind them existed.

>Naturally, even that is invariably mistaken for the disreputable "5 million
>morons cannot be wrong" argument :-(

Of course programmers are morons, just look at them!

Jay

Re: OO, C++, and something much better!

[Soren Skogstad Nielsen]

Fergus Henderson wrote:
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> >Sure.  Everyone agrees that catching errors at compile time is less costly.
> >
> >However, dynamic typing results in signficantly faster development time.
> 
> That is highly debatable.  My experience is that static typing results
> in faster development time.
> 
  Yes but some of the debate should include how the development
environment helps with the pitfalls of dynamic typing.
Some Smalltalk environments can catch all messages with no implementer
and symbols undefined. Furthemore it is easy (a few minutes) to test
each non trivial method to ensure that it does activate other methods
with the correct typing of the argument in all cases, the trivial ones,
two lines or so you can test just by looking. In this way you will
create small trustable building blocks to build your large trustable
building blocks by. And further more catch application
misunderstandings.

If you code for a few hours without verifying in a dynamic typing
environment, then your habits is not matching its behaviour, as well as
coding a few hours in PASCAL without compiling is a bad habit too.

Soren Skogstad Nielsen
Soren.s.nielsen@ddf.dk

Re: OO, C++, and something much better!

[Alan Lovejoy]

Fergus Henderson wrote:
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> >Could the financial people be wrong?
> 
> Gee, I guess you must be right, the idea that the financial people
> could be wrong is obviously unthinkable.

Oh, anyone can be wrong.  Even you or me :-).

But how likely is it that the financial people would choose Smalltalk, of all 
things, purely on a whim?    Financial people tend to be conservative.  They 
are NOT early adopters.  They do NOT consider it their business to try out new 
technology for the fun of it.  They prefer to go with the tried and true, with 
the in thing, with the conventional wisdom--unless there is a damn good reason 
to do otherwise.

Dynamic typing is by no means in accord with the "conventional wisdom."  And
it is well known that there are far more C++ programmers than there are
Smalltalk programmers.  Even so, many a bank has switched from C++ to Smalltalk
or Objective-C/OpenStep for trading applications--and often for many other
things, too.

Do you really think that someone can go to Citibank, JP Morgan, Morgan Stanley
or Merryl Lynch, and claim than language X is better, and have most of them
take you at your word and adopt language X as their new standard?  Don't you
think they would at least ask for some references?  For some other users that
they could interview? Wouldn't they do a pilot project?  Wouldn't they switch
slowly, project by project, and then only if language X actually showed itself 
to be significantly better?

Of course that's how they'd do it.  It's standard busisness practice.  It's
what was done.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Alan Lovejoy]

Damon Feldman wrote:
> 
> In article <32E05FAF.47BA@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> wrote:
> >Fergus Henderson wrote:
> >>  My experience is that static typing results
> >> in faster development time.
> 
> >Really?
> >
> >So then, why have so many investment banks adopted Smalltalk as the language
> >of choice for doing securities trading applications?  The reason typically
> >given is that development speed in Smalltalk is so much faster
> 
> >try to convince them that the bank
> > would be better off using C++?  Ha!  I can just see that conversation... :-)
> 
> This seems like an unfair comparison.  It's like saying, "why don't they all
> use PL/I if they like static typing so much?"  PL/I sucks, is why.

Who said anyting about PL/I?  Introducing such an extraneity is "unfair."

But replace "PL/I" with "any statically-typed language," and then you can see
the truth: "because any statically-typed language sucks, is why."  (Actually,
statically-typed langauges have a useful niche, but that niche does not encompass
all of programming).

> If they had _SmallTalk_ with static typing, would they use it instead of
> SmallTalk?  Since Java is just such a product, and is the hottest thing out
> there right now, it could be that people *are* convinced that OO w/ static
> typing is the way to go.

Ever heard of StrongTalk?  It's Smalltalk with static typing.  It was a failure
in the marketplace.  I conclude that static typing succeeds when marketed to
those who believe in static typing, and that dynamic typing succeeds when
marketed to those who belieive in dynamic typing.  And dynamic typing also succeeds 
when marketed to people who want the fastest development times, and have no religious
axe to grind over the issue.

Why would Prudential choose Smalltalk as a replacement for COBOL, when they could
choose whatever they wanted (http://www.software.ibm.com/ad/stmvs/stpru.htm)?

Why would Chrysler hire Kent Beck to oversee the rewriting of their payroll
system in Smalltalk?  They could have chosen C++, Eiffel, Java or Ada95, or
just stayed with COBOL. Why didn't they?  Why choose Smalltalk, when there are 
so much fewer programmers than would be available for C++?  Why choose Smalltalk, 
when there is such a wide-spread bias against dynamic typing?  

Why has the use of Smalltalk been growing at 60% per year?  In spite of the
absence of any Java-style marketing campain?  

Smalltalk offers many times faster development times--and much greater robustness
in the face of changing requirements.  That's a strategic advantage, especially
in businesses and industries (like securities trading) where time is not just
money, but big, big money.

> Also, can't you just send everything flying around the system as an Object
> (root of the whole class tree) in those situations when you want dynamic
> typing?

Not in Java.  Java won't let you send any message that the compiler doesn't
know will be valid.  And there is no equivalant of #perform: (which sends
a message chosen at run time).

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Keith Thompson]

(The References: header is probably incorrect.  I saw Robert's response
on the info-ada mailing list; it never appeared here in comp.lang.ada.)

(Newsgroups trimmed to comp.lang.ada.  Quoted text reformatted slightly.)

Robert Dewar <dewar@MERV.CS.NYU.EDU> wrote:
> Keith says
> > On the other hand, for Ada 95, RM95-13.7.1(16) says that "Operations that
> > do not make sense should raise Program_Error".  The AARM (Annotated Ada
> > Reference Manual) gives the examples of X < Y and conversions between
> > Integer_Address and Address on a segmented architecture.  (Note also that
> > it's not necessary to use System.Storage_Elements; relational operators
> > on type Address are provided in System.)
> 
> Nope, you are reading too much into the RM here. Also reading the AARM
> is always a risky business (remember it is just opinion, nothing more :-)

Of course, but the AARM can be a perfectly good source of examples,
which is all I used it for in this case.

> Let's take the case of a segmented architecture. It is common for C
> compilers in such environments (Large mode on the 8086) to limit objects
> to 64K bytes and to compare ONLY the offset parts of the addresses
> so that address comparison onlly works when it is defined to work, and
> gives silent junk answers when used between different objects.

Ok, no problem.

> If we look at the corresponding Ada case, I cannot see any justification
> whatsoever for not properly allowing conversoin of any possible segmented
> address to an integer address. Such an operation makes perfect sense in
> this environment and is therefore REQUIRED TO BE SUPPORTED! You are only
> allowed to raise PE for things that do not make sense. Since this machine
> has a well define notion of linear address, it is clear to me that (a) any
> implementor on this environment would provide the obvious conversion and
> (b) that if they did not, they could not seek refuge in the RM.

Assuming that there's an integer type big enough to hold a full address
(yes, this is probably a perfectly reasonable assumption).

> Let's actually look at the AARM wording, it says, if we quote it in full,
> rather than paraphrase as Keith did:
>  
>         16.a   Discussion:  For example, on a segmented architecture, X < Y
>         might raise Program_Error if X and Y do not point at the same segment
>         (assuming segments are unordered).  Similarly, on a segmented
>         architecture, the conversions between Integer_Address and Address
>         might not make sense for some values, and so might raise Program_
>         Error.

Note the phrase "assuming segments are unordered".  On a segmented
architecture of the kind you describe, segments are ordered (if I
understand correctly).

> Keith's point that there is a comparison operation on addresses directly
> is true, but it is not a good idea to use these operations, since it is
> indeed sensible to decide that certain comparisons are not meaningful
> when performed directly on segmented addresses.

That argument makes sense for C, but I don't think it does for Ada.
If addresses can be converted to integers, and the resulting integers can
be meaningfully compared, why on Earth would the relational operators
in System not be implemented that way?  How would you justify having
System."<" compare only the offset parts of its operands?

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: What is wrong with OO ?

[Richard A. O'Keefe]

bs@research.att.com (Bjarne Stroustrup) writes:
>I think that if C++ was as hard to understand and use as some people claim,
>it would have failed to become popular in the first place and would have
>vanished under the continuous barrage of fair and unfair criticism - despite
>its (eventual) popularity.

Speaking as someone who bought the first C++ book to come out,
the C++ that became popular in the first place
is not the C++ that people discuss now.
To start with, it didn't have multiple inheritance, templates,
exceptions, or RTTI.

It follows that claims about the difficulty of understanding
about C++ *AS IT IS NOW* cannot fairly be founded on its
acceptance *AT FIRST*, just as arguments about the difficulty
or otherwise of learning or teaching Ada 95 cannot be directly
founded on the acceptance or otherwise of Ada 83 (ditto with
Fortran 90 and Fortran 66).

>I have often found myself wondering if the C++ wouldn't have been much better
>for all concered had there (just) been two dozen good C++ books instead of
>the 400+ books that mostly fail to teach the basic principles and mostly
>lead students and programmers astray.

Here of course it is very important to separate out the books from the
language.  The marked prevalance of trash books about C++ says nothing
about C++ except that it is popular.

>Thanks for the advice. The furthest I go is to claim that unless C++
>had at least some of the virtues I claim for it, it would have died during
>the early years where there were essentially no C++ marketing and alternatives
>languages with marketing dollars behind them existed.

Hmm.  When I learned about C++ in the mid-80s, the only available
alternatives _that I was aware of_ were some sort of Lisp (Common
Lisp not then being available) with some sort of home brew Flavors
lookalike (CLOS not then being available) or Smalltalk.  Simula 67
_may_ have been available for VAX & Sun but if there were marketing
dollars behind it they never managed to put a mention of it where I
could see it.  What _were_ the VAX, Sun, Apollo alternatives to C++
a decade ago?

-- 
My tertiary education cost a quarter of a million in lost income
(assuming close-to-minimum wage); why make students pay even more?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E47rDG.AC8@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> In article <E3z0zy.9qL@syd.csa.com.au>,
> Don Harrison <donh@syd.csa.com.au> wrote:
> >
> >The following is a valid Ada83 program (and presumably valid Ada95):
> >
> >procedure Test_Type_Hole is
> >  subtype Sub_Integer is Integer range 1 .. 10;
> >  I: Integer;
> >  S: Sub_Integer;
> >
> >  procedure Use_Subtype (S: Sub_Integer) is
> >  begin
> >    null;
> >  end;
> >
> >begin
> >  I := 1000;
> >  Use_Subtype (I);       -- System Invalid call - raises 
> >                         -- Constraint_Error at runtime.
> >end Test_Type_Hole;
> >
> >So, contrary to your claim, Ada *does* permit a form of broken polymorphism.
> 
>   To me, this seems more of a broken assertion than broken polymorphism.
> 
>   (However, I've never use Ada in my life... :-)

Well, now this is amusing.  Patrick here states he's never used Ada
in his life, but he gets it _right_!  Nice little piece of anecdotal
evidence for the readability of Ada... :-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[David Emery]

With many OO languages, including C++ and SmallTalk, I've observed that
it seems to be easy to get familiar with the language, but it's much 
harder to become fluent/expert in it.  I suspect we'll see a similar
pattern with Java.  This is certainly my personal experience learning
Java.  

Thus I'd suspect that the initial popularity of C++ was due to the 
following: (no ranking)

	*  popularity of C
	*  price
	*  ease/intuition for the basic OO concepts.  

So, once Joe/Jane Programmer has reached the "familiarity" stage, the
real issue is the amount of time it takes to get to the "fluent"
stage.  

Thus I think that a more appropriate way at looking at this is not
popularity or familiarity, but rather time to reach expertise.  I'll
leave it to others to define "expertise" for a given language.  At the
minimum, I'd expect "expertise" to include the ability to avoid common
syntax/semantic mistakes, the ability to read/reason about and
maintain code written by others, and at least passing familiarity with
the distinction between "the language specifies..." and "this
implementation does...".

If you are going to be a practicing/professional programmer, producing
real code, "familiarity" is not good enough.  Expertise is required. 

				dave
-- 
<.sig is away on vacation>

Re: OO, C++, and something much better!

[Andrew Koenig]

In article <5bie2d$eat$1@news.nyu.edu> kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

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

> >equally if you do something like

> >   (x = p; x < &p[10]; p += 3)

> >you can find you have an infinite loop, all quite in accordance with the
> >C semantics, although somewhat surprising.

> This case must work.  Such a reference to the end of an object is required
> to be treated like a reference within the object.

I haven't seen the original of this, but the fragment above appears
to contain at least three mistakes (not counting the missing `for'
as a mistake):

	1. It probably should have said `x += 3' instead of `p += 3';
	   as it is, the loop will just keep incrementing p until something
	   dire happens.

	2. If we change `x += 3' to `p += 3,' it still won't work,
	   because p will take on the value of &x[9], and then
	   &x[12], which is undefined, assuming that p has 10 elements.

	3. If p is indeed the name of a 10-element array, then
	   &p[10] is undefined in C.  Really!  The reason is that
	   it is defined as equivalent to *(p+10), and, although it
	   is legal to create p+10, the effect of dereferencing it
	   is undefined.  So, formally speaking, &p[10] is supposed
	   to be written as p+10.

I hope I haven't derailed the discussion too much.
-- 
				--Andrew Koenig
				  ark@research.att.com
				  http://www.research.att.com/info/ark

Re: OO, C++, and something much better!

[Bill Gooch]

Alan Lovejoy wrote:
> ....
> Damon Feldman wrote:
> > ....
> > Also, can't you just send everything flying around the system as an Object
> > (root of the whole class tree) in those situations when you want dynamic
> > typing?
> 
> Not in Java.  Java won't let you send any message that the compiler doesn't
> know will be valid.  And there is no equivalant of #perform: (which sends
> a message chosen at run time).

Actually there is, as of JDK 1.1 (out now in beta).
And you can downcast from Object to get at methods
defined on subclasses, even without using invoke.
But you still don't get the flexibility of Smalltalk,
and ubiquitous downcasting is pretty inelegant (to 
put it mildly), and defeats the purpose of having
static typing in the first place.

It seems clear that one could, using Java's reflection
API, build a framework for free-form method invocation
which would work pretty much like Smalltalk, but with
a screwy syntax.  It would most likely be extremely slow 
and garbage intensive (more so than Smalltalk), and code 
using it would be fairly opaque as well.

As always, the difference between the languages is a 
collection of tradeoffs.  I've found that development
in Java takes a lot longer getting started, but the code 
is a bit less bug-prone due to static typing, so debugging
it goes a bit faster, except the development environments
aren't as good as the ones for Smalltalk yet.  But then
static typing becomes more helpful, because the compiler 
catches more of the bugs up front.  At the language level,
Java has some quirks that Smalltalk effectively avoids
(such as some of the wierdnesses of constructors, and
compile-time resolution of static references).

Overall, I prefer Smalltalk for development, but I think
Java will be a better application delivery vehicle once
the language and its IDEs mature.  Although I didn't agree
when I first read it, I now believe Jeff Sutherland's 
Smalltalk manifesto was right on the mark.  Smalltalk 
paved the way in a lot of areas, and now Java is poised
to drive down those roads at high speed.

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: OO, C++, and something much better!

[David Hanley]

Alan Lovejoy wrote:
> 
> Damon Feldman wrote:

> > If they had _SmallTalk_ with static typing, would they use it instead of
> > SmallTalk?  Since Java is just such a product, and is the hottest thing out
> > there right now, it could be that people *are* convinced that OO w/ static
> > typing is the way to go.
> 
> Ever heard of StrongTalk?  It's Smalltalk with static typing.  It was a failure
> in the marketplace.  I conclude that static typing succeeds when marketed to
> those who believe in static typing, and that dynamic typing succeeds when
> marketed to those who belieive in dynamic typing.

	That's a good start, but it avoids the issue that most people beleive
in static typing, and why this is the case.

>  And dynamic typing also succeeds
> when marketed to people who want the fastest development times, and have no religious
> axe to grind over the issue.

	This is in no way proved, and, I beleive, false.

> 
> Why would Prudential choose Smalltalk as a replacement for COBOL, when they could
> choose whatever they wanted (http://www.software.ibm.com/ad/stmvs/stpru.htm)?

	The made a bad choice.  Why did they go with cobol in the first place? 
Why do so many others go with C/C++?  


> 
> Why has the use of Smalltalk been growing at 60% per year?

	Why is it still practcally nonexistant?  Why is java growing many times
faster?


> Smalltalk offers many times faster development times-

	Than what?  And what is your proof of this?

> -and much greater robustness
> in the face of changing requirements.

	Except for when all your messages aren't working.

>   That's a strategic advantage, especially
> in businesses and industries (like securities trading) where time is not just
> money, but big, big money.

	And program problems are big, big problems. 


------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[Graham Hughes]

-----BEGIN PGP SIGNED MESSAGE-----

Looks like it's time for someone to play Devil's Advocate...

Alan Lovejoy <alovejoy@concentric.net> writes:

>But replace "PL/I" with "any statically-typed language," and then you
>can see the truth: "because any statically-typed language sucks, is
>why."  (Actually, statically-typed langauges have a useful niche, but
>that niche does not encompass all of programming).

Depends on your point of view, I suppose.  The thing that makes me most
unhappy about Smalltalk, Python, Perl, and the whole gamut of
dynamically typed OO languages is just that--they are dynamically typed.

I prefer static typing.  It's largely a matter of interface design and
subtyping; inheritance as code reuse is fine and dandy, but I prefer to
program to interface specs.  Something like the Ada package system is
close to ideal for me, where clearly defined operations on clearly
defined types are possible (although I don't use Ada much for esthetic
reasons).

Subtyping allows me to reuse this code willy-nilly; stronger, it means I
don't introduce new bugs elsewhere because I'm passing a rectangle
instead of an integer, and some module deep down was expecting the
addition to go as planned.

The enforcability of this concept is what I like about static typing and
dislike about dynamic typing.  Dynamic typing and languages have their
places, but I'd prefer to be able to guarantee that the assumptions I
made about a type are verifiable.

In Smalltalk, passing a Rectangle where the system expects an Integer
results in a runtime error (depending on a number of circumstances, of
course).  This means I won't stumble over the bug until I, or more
likely, my user, stumbles across this set of circumstances.  Why allow
for these types of bugs when they can be eliminated or at least reduced?

>Ever heard of StrongTalk?  It's Smalltalk with static typing.  It was
>a failure in the marketplace.  I conclude that static typing succeeds
>when marketed to those who believe in static typing, and that dynamic
>typing succeeds when marketed to those who belieive in dynamic typing.
>And dynamic typing also succeeds when marketed to people who want the
>fastest development times, and have no religious axe to grind over the
>issue.

I conclude that _you_ have an axe to grind.  I also conclude that one
failure is not a statistically valid sample.  I can claim that fully
100% of my development team prefers static typing, because _I_ am my
development team.  Come back with something done by a statistician
(although finding an honest statistician is often like finding an honest
lawyer... :-); isolated cases prove nothing.

<snip>

>Smalltalk offers many times faster development times--and much greater
>robustness in the face of changing requirements.  That's a strategic
>advantage, especially in businesses and industries (like securities
>trading) where time is not just money, but big, big money.

I acknoledge that Smalltalk has some advantages.  Speed of development
seems to be one.

However, I will contest robustness.  What about a system that throws a
runtime error if you try to take the sin of a rectangle can be called
robust?  This sort of thing happens, even often; much better that the
compiler check it than me, given that I'll probably overlook something
subtle.

If OO is about conceptual separation of code into independent modules,
why should the modules be concerned about what somebody else gives them?
Why should they manually check that the object is capable of the
operations demanded when the compiler can?

>Not in Java.  Java won't let you send any message that the compiler doesn't
>know will be valid.  And there is no equivalant of #perform: (which sends
>a message chosen at run time).

And #perform: is a good thing?  I can achieve a similar operation in C++
(not Java, though) with pointer-to-member-functions in a map<> or an
array or something, and it's even typesafe, so I don't have to worry
(too much) about some perverted piece of code messing with my mind.

...

Unlike yourself, I have no qualms about others using dynamic typing.
Please, go ahead; if the advantages of it outweigh the disadvantages for
your projects, by all means use Smalltalk.  I use Python, a dynamically
typed OO language, for much of my scripting because it's far easier to
get a prototype working.  For larger projects, particularly ones that I
cannot hold entirely inside my head, I prefer a statically typed
language for the reasons above.

But don't you _dare_ try to enforce your preferences upon me.
- -- 
Graham Hughes (graham.hughes@resnet.ucsb.edu)
http://A-abe.resnet.ucsb.edu/~graham/ -- MIME & PGP mail OK.
"Never attribute to malice that which can be adequately explained by 
	stupidity." -- Hanlon's Razor

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMuNgxSqNPSINiVE5AQGPPQP9GAKSt5brXZthxoc+lt+as85mcxF0qHli
cmf8IGmyy39YKATvzP4HkakkxwbBY11kZoPoG4eJCSQ3uCw0X+8F6y/7AuwjXpr/
CQSlTQcSACggTqRD39rGEl39rxGvS7nA2tZhXnaSYkFsQ9bM/I3fJJCypegy5CiM
qB7L27Mj0HU=
=tcuJ
-----END PGP SIGNATURE-----

Re: OO, C++, and something much better!

[Joachim Durchholz]

Alan wrote:

> But replace "PL/I" with "any statically-typed language," and then you can
> see the truth: "because any statically-typed language sucks, is why."

Come on, have you ever programmed in a statically-typed language?  
Seriously?
What you say sounds just like a Basic programmer whom I tried to convince  
he should try (just TRY!) Pascal. He said he had seen it at the  
University, and Pascal sucked...

> (Actually, statically-typed langauges have a useful niche, but that niche
> does not encompass all of programming).

Which?

I could state that Smalltalk has a useful niche (that doesn't encompass  
all of programming), but I don't want throw mud back.

> Ever heard of StrongTalk?  It's Smalltalk with static typing.  It was a
> failure in the marketplace.

Why? Because static typing is bad, or because it was done badly, or just  
because the Smalltalk *environment* isn't designed with static typing in  
mind, or because the Smalltalk installations didn't want to convert  
because they would have had to retrain their developers? (The latter is  
one of the main reasons why Cobol and its ugly relatives haven't died out  
yet. Technical merit is just one factor among many that decide wether a  
language lives or dies.)

> I conclude that static typing succeeds when
> marketed to those who believe in static typing, and that dynamic typing
> succeeds when marketed to those who belieive in dynamic typing.

No you can't. This is just rhetorics what you're doing.

> And dynamic
> typing also succeeds when marketed to people who want the fastest
> development times, and have no religious axe to grind over the issue.

I have heard several indicators that Smalltalk is very good at getting  
stuff done, in the quickest possible time. I'm willing to believe this  
(sounds reasonable anyway), but nobody talks about the disadvantages in  
the approach. Those who know Smalltalk program in it, so they won't tell  
me - and I can't believe there are none.
I don't want to be converted to Smalltalk. I want to know about advantages  
and disadvantages, so that I can decide which language is better for a  
given task.

> Why would Chrysler hire Kent Beck to oversee the rewriting of their payroll
> system in Smalltalk?  They could have chosen C++, Eiffel, Java or Ada95, or
> just stayed with COBOL. Why didn't they?  Why choose Smalltalk, when there
> are so much fewer programmers than would be available for C++?  Why choose
> Smalltalk, when there is such a wide-spread bias against dynamic typing?

Maybe because they are manager? Not all decisions, even in large  
companies, are based on rational arguments. There is trust in consultants  
involved, who aren't always impartial. There is also much internal  
backstabbing involved - sometimes managers influence other managers into  
bad decisions, to weaken their internal position.

Not that I'm convinced this is the case with the companies that you listed  
as examples. It's just that such success stories don't prove a thing. It  
would be much more interesting to hear about the consequences of these  
decisions, not about the decisions themselves.

> Why has the use of Smalltalk been growing at 60% per year?  In spite of the
> absence of any Java-style marketing campain?

Maybe because two companies happened to decide for Smalltalk, which makes  
a huge difference if the installed base is small.
I'm sure any proponent for any other language can make up similarly  
impressing figures.
That 60% figure is worthless - you don't say wether it's number of  
companies, number of developer seats, number of productive systems, or  
lines of code. You don't even say since when this growth started - it  
might be 1 1/2 year as well as twenty years.

> Smalltalk offers many times faster development times--and much greater
> robustness in the face of changing requirements.  That's a strategic
> advantage, especially in businesses and industries (like securities trading)
> where time is not just money, but big, big money.

I already knew this. I consider this an interesting property of Smalltalk,  
but I'm not convinced Smalltalk is best for everything. And as far as I  
know, Smalltalk can't be integrated into a multi-language environment (at  
least not with a considerable amount of work, or with serious efficiency  
problems), so I'm somewhat hesitant to recommend Smalltalk at all.

Regards,
-Joachim

--
Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

Re: OO, C++, and something much better!

[Damon Feldman]

In article <32E05FAF.47BA@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> wrote:
>Fergus Henderson wrote:
>>  My experience is that static typing results
>> in faster development time.

>Really?
>
>So then, why have so many investment banks adopted Smalltalk as the language
>of choice for doing securities trading applications?  The reason typically
>given is that development speed in Smalltalk is so much faster

>try to convince them that the bank
> would be better off using C++?  Ha!  I can just see that conversation... :-) 

This seems like an unfair comparison.  It's like saying, "why don't they all 
use PL/I if they like static typing so much?"  PL/I sucks, is why.

If they had _SmallTalk_ with static typing, would they use it instead of 
SmallTalk?  Since Java is just such a product, and is the hottest thing out 
there right now, it could be that people *are* convinced that OO w/ static 
typing is the way to go.

Also, can't you just send everything flying around the system as an Object 
(root of the whole class tree) in those situations when you want dynamic 
typing?

Damon

Re: OO, C++, and something much better!

[Fergus Henderson]

Alan Lovejoy <alovejoy@concentric.net> writes:

>Could the financial people be wrong?  

Gee, I guess you must be right, the idea that the financial people
could be wrong is obviously unthinkable.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <32E2FE79.344F@dialip.sdn.dk> Soren Skogstad Nielsen <ddf8732@dialip.sdn.dk> writes:

   Fergus Henderson wrote:
   > 
   > Alan Lovejoy <alovejoy@concentric.net> writes:
   > 
   > >Sure.  Everyone agrees that catching errors at compile time is less costly.
   > >
   > >However, dynamic typing results in signficantly faster development time.
   > 
   > That is highly debatable.  My experience is that static typing results
   > in faster development time.
   > 
     Yes but some of the debate should include how the development
   environment helps with the pitfalls of dynamic typing.
   Some Smalltalk environments can catch all messages with no implementer
   and symbols undefined. Furthemore it is easy (a few minutes) to test
   each non trivial method to ensure that it does activate other methods
   with the correct typing of the argument in all cases, the trivial ones,
   two lines or so you can test just by looking. In this way you will
   create small trustable building blocks to build your large trustable
   building blocks by. And further more catch application
   misunderstandings.

   If you code for a few hours without verifying in a dynamic typing
   environment, then your habits is not matching its behaviour, as well as
   coding a few hours in PASCAL without compiling is a bad habit too.

   Soren Skogstad Nielsen
   Soren.s.nielsen@ddf.dk

Aren't you confusing thes issue of static vs. dynamic typing with the
issuse of having an interpreter for the language, including an
integrated development environment?

Re: What is wrong with OO ?

[rharlos*cybercomm.net]

bs@research.att.com (Bjarne Stroustrup) wrote:

   << snipped the debate parts >>

| Why is any of this relevant now? Why do I bother with this debate on
| "innovation?" Because some of what is said related directly to what C++
| is and should be, and that again affects where it is reasonable to use
| it and how it is best used. If you misunderstand some of the fundamentals
| of a language, the code you write in it is going to be suboptimal in several
| ways.

PMFJI.  If there is a gem to be gleaned from this debate, it is in the above
paragraph.

Every development environment (DE) has strengths and weaknesses.  These are the
"fundamentals" of the DE.  As developers, we have a responsibility to understand
both the needs of the situation to be "solved" and the fundamentals of the
various tools which may be used to create a solution to the situation at hand.

Our ability to select the right tool for the job can make the solution several
times easier to implement, maintain and enhance than if we had selected a less
optimal DE.  Its a message that, in my experience, can never be overemphasized!

Thanks for this little gem -- it's a keeper!

  O-------------------------0   0----------------------------------0
  |  Richard C Harlos II     \ /       Software Analyst/Developer  |
  |  aka:   .:.Richard.:.     X    Logical Design Solutions, Inc.  |
  |  rharlos@cybercomm.net   / \               http://www.lds.com  |
  0-------------------------0   0----------------------------------0

  ** opinions expressed are mine, not necessarily those of LDS, Inc.

  Anit-Spam Tactic:  replace the '*' with '@' when replying to
            me via e-mail as I've been inundated with spam !!!

Re: What is wrong with OO ?

[John W. Sarkela]

Richard A. O'Keefe wrote:
> 
... text ommitted ...
> Hmm.  When I learned about C++ in the mid-80s, the only available
> alternatives _that I was aware of_ were some sort of Lisp (Common
> Lisp not then being available) with some sort of home brew Flavors
> lookalike (CLOS not then being available) or Smalltalk.  Simula 67
> _may_ have been available for VAX & Sun but if there were marketing
> dollars behind it they never managed to put a mention of it where I
> could see it.  What _were_ the VAX, Sun, Apollo alternatives to C++
> a decade ago?
> 
There were some very sound alternatives. In the days when C++ was
still in the 1.x range (ie pre multiple inheritance, pre templates,
pre exceptions, etc) the languages Trellis/OWL, Eiffel and Modula-3
were around. 

In fact, there was a protracted thread in the comp.lang.eiffel and
comp.lang.c++ groups about Eiffel v. C++. Most of the content 
revolving upon the need for multiple inheritance and genericity
(templates) in a statically typed OOP language and the need for 
exceptions for robustness. All three languages paid great homage
to the needs of software engineering. All three are worth reading
about, if only for historical perspective.

John Sarkela
jsarkela@enfish.com
-- Standard disclaimers apply.

Re: OO, C++, and something much better!

[Norman H. Cohen]

Alan Lovejoy wrote:

> However, dynamic typing results in signficantly faster development time.
> So as long as the number of typing errors that occur in practice are low 
> enough, dynamic typing is still a net win.  In my experience, the frequency 
> of occurrence of such errors is about 2% of all errors--which is much lower 
> than the break-even point.

This strikes me as "seat of the pants" guess rather than a solid
empirical result.  I'll give you the benefit of the doubt and assume
that your "2% of all errors" figure is based on methodical tracking of
the projects on which you have worked.  However, before you start to
speculate about break-even points, you need some numbers about the
degree to which dynamic typing supposedly speeds up development time,
and you need some numbers about the amount of time wasted chasing these
type errors in a debugging session rather than in response to a
compile-time error message.

Now the 2% figure may in fact be colored by the fact that you are using
a weakly typed language.  Users of strongly typed languages take
advantage of compile-time type checking to encode all sorts of
distinctions as type distinctions, so that a compiler's certification of
type consistency greatly increases confidence in a program's overall
logical consistency.

Having worked with both dynmically and statically typed languages, my
(unquantified) experience is that dynamic typing speeds up program
development about as much as touch typing.  :-)  That is,  it reduces
data entry time because you don't have to type all those declarations.
Of course this is a minuscule fraction of program development time. Once
a program has been keyed in, strong typing results in a flurry of
compile-time errors that must be addressed before the program will run.
Of course dynamic typing does not make these errors go away, it just
hides them so that you have to find them yourself instead of having them
pinpointed for you by a compile-time error message.

In my experience, a line containing a stupid mistake that would have
been caught by decent compile-time checks can easily take 50 times as
long to develop (counting the time to debug a line as part of that
line's development time) as a line without such an error.  In that case,
even if we accept the 2% figure, static typing is still a win.

Development time is of interest, of course, not in its own right, but
because of its impact on project value and cost to the customer.  The
cost of a less timely deployment of a program must be weighed against
the cost of an error that arises for the first time in the field,
because the programming language did not allow the error to be caught at
compile time and the run-time testing was incomplete.  If you are lucky,
the software merely fails, and the customer reverts to contingency
procedures while programmers working overtime rush a patch out to the
customer.  If you are unlucky, the program appears to work correctly,
but provides an incorrect result that causes your customer to lose tens
of millions of dollars on an absurd securities trade.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Matthew S. Whiting]

Matthew S. Whiting wrote:
> 
> Joachim Durchholz wrote:
> >
> > Alan wrote:
> >
> > > Why would Chrysler hire Kent Beck to oversee the rewriting of their payroll
> > > system in Smalltalk?  They could have chosen C++, Eiffel, Java or Ada95, or
> > > just stayed with COBOL. Why didn't they?  Why choose Smalltalk, when there
> > > are so much fewer programmers than would be available for C++?  Why choose
> > > Smalltalk, when there is such a wide-spread bias against dynamic typing?
> >
> > Maybe because they are manager? Not all decisions, even in large
> > companies, are based on rational arguments. There is trust in consultants
> > involved, who aren't always impartial. There is also much internal
> > backstabbing involved - sometimes managers influence other managers into
> > bad decisions, to weaken their internal position.
> >
> > Not that I'm convinced this is the case with the companies that you listed
> > as examples. It's just that such success stories don't prove a thing. It
> > would be much more interesting to hear about the consequences of these
> > decisions, not about the decisions themselves.
> >
> After 14 years in a big company I feel somewhat qualified to comment on
> this.  Most decisions are not made on rational arguments, at least not
> rational from the viewpoint of most engineers.  They are made largely
> according to the lemming principle, i.e., "everyone else is doing it."
> Look at downsizing, etc.  All it takes is one of two companies to step
> out and try something new and then the trade press and consultants pick
> it up as they need something different to justify their respective
> existences.  After that, the 98% of the companies who aren't true market
> leaders, jump on the bandwagon because every CEO reads it in Business
> Week or an airline magazine.  I'm guessing that one or two prominent
> companies gave Smalltalk a try in financial applications and either had
> success or didn't (more later) and then the masses followed.  Keep in
> mind that often failure of a product will get more press than wild
> success.  Most companies don't advertize the tools that truly give then
> competitive advantage, they keep those to themselves.  They advertize
> the tools that either were NOPs or actually made them less competitive
> in hopes that their competitors WILL pick up on such tools.
> Sure, this is a cynical vire, but I think happens more often than people
> care to admit..
> 
> Anyone, know REALLY how Smalltalk got its start in t

I found, accidentally, a control key that submits the post!  Sorry about
that.

The rest of the story is ... the financial application space?

Matt

Re: OO, C++, and something much better!

[Joachim Durchholz]

Alan wrote:

> > If OO is about conceptual separation of code into independent modules,
> > why should the modules be concerned about what somebody else gives them?
> > Why should they manually check that the object is capable of the
> > operations demanded when the compiler can?
>
> This is a non argument.  Since someone must check, there is no difference in
> principle whether that someone is the compiler or the run-time system.  It's
> an implemenation difference, not a difference in kind.

Oh yes there is a difference. The compiler will catch all errors; the run- 
time system will miss some.
In other words: I'd feel really embarrassed if the user ever saw a  
"message not understood" error.
IMHO, bugs that can be found automatically should be found automatically.  
Each 2% failure probability that's taken out will make the total system  
more stable (remember a dozen 2% failure sources give a total failure  
probability of about 22%).

So, dynamic typing has the disadvantage that it makes a set of compile- 
time checks impossible. The only issue worth discussing is wether this  
disadvantage is set off by added flexibility, or not. And the result of  
the discussion may well be different depending on circumstances - e.g. how  
much of the Smalltalk flexibility is actually due to the environment, not  
to dynamic typing?

Besides, some aspects of static typing in an OO language aren't really  
settled yet. Don't take C++ design for the whole truth on static typing!  
C++ has a working type system, but not a well-designed one.
Unfortunately, there is no consensus yet on how a well-designed OO type  
system should look like. In this light, it's no wonder that StrongTalk  
didn't succeed - I think that it was too far ahead of its time.
I'm still waiting for an Algol 60 that shows how to do static typing well.  
As soon as such a beast exists it will be sensible to build a Smalltalk- 
like system with class browsers and minimal edit-test cycles, or to extend  
Smalltalk with static typing.

> Just how do you do an AspectAdaptor or
> PluggableAdaptor in Java?

I'm not familiar with the patterns used in current Smalltalk systems. What  
do these adapters do? And what are their basic principles of operation?

Regards,
-Joachim

--
Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

Re: OO, C++, and something much better!

[Matthew S. Whiting]

Joachim Durchholz wrote:
> 
> Alan wrote:
> 
> > Why would Chrysler hire Kent Beck to oversee the rewriting of their payroll
> > system in Smalltalk?  They could have chosen C++, Eiffel, Java or Ada95, or
> > just stayed with COBOL. Why didn't they?  Why choose Smalltalk, when there
> > are so much fewer programmers than would be available for C++?  Why choose
> > Smalltalk, when there is such a wide-spread bias against dynamic typing?
> 
> Maybe because they are manager? Not all decisions, even in large
> companies, are based on rational arguments. There is trust in consultants
> involved, who aren't always impartial. There is also much internal
> backstabbing involved - sometimes managers influence other managers into
> bad decisions, to weaken their internal position.
> 
> Not that I'm convinced this is the case with the companies that you listed
> as examples. It's just that such success stories don't prove a thing. It
> would be much more interesting to hear about the consequences of these
> decisions, not about the decisions themselves.
> 
After 14 years in a big company I feel somewhat qualified to comment on
this.  Most decisions are not made on rational arguments, at least not
rational from the viewpoint of most engineers.  They are made largely
according to the lemming principle, i.e., "everyone else is doing it." 
Look at downsizing, etc.  All it takes is one of two companies to step
out and try something new and then the trade press and consultants pick
it up as they need something different to justify their respective
existences.  After that, the 98% of the companies who aren't true market
leaders, jump on the bandwagon because every CEO reads it in Business
Week or an airline magazine.  I'm guessing that one or two prominent
companies gave Smalltalk a try in financial applications and either had
success or didn't (more later) and then the masses followed.  Keep in
mind that often failure of a product will get more press than wild
success.  Most companies don't advertize the tools that truly give then
competitive advantage, they keep those to themselves.  They advertize
the tools that either were NOPs or actually made them less competitive
in hopes that their competitors WILL pick up on such tools.
Sure, this is a cynical vire, but I think happens more often than people
care to admit..

Anyone, know REALLY how Smalltalk got its start in t

Re: OO, C++, and something much better!

[Marc Robertson]

Alan Lovejoy wrote:
> 
> Graham Hughes wrote:
> >
[snip]
> 
> > If OO is about conceptual separation of code into independent modules,
> > why should the modules be concerned about what somebody else gives them?
> > Why should they manually check that the object is capable of the
> > operations demanded when the compiler can?
> 
> This is a non argument.  Since someone must check, there is no difference in
> principle whether that someone is the compiler or the run-time system.  It's
> an implemenation difference, not a difference in kind.

There is a difference in practice.  If the compiler detects an error,
the only one that has to worry about it is the developer.  If an error
is present that the run-time system has to handle, all users are
potentially affected by it.  There have been any number of studies(
unfortunately, I don't have access to them here, so I can't quote them )
that indicate that the cost to correct a problem increases dramatically
the later in the development process you detect it. The sooner problems
can be eliminated, the less it costs to eliminate them! 
-- 
All opinions expressed are my own
Marc Robertson                  email:
Principal Analyst                  marobertson@dstsystems.com
DST Technologies
Kansas City, MO USA

Re: OO, C++, and something much better!

[Matt Kennel]

Alan Lovejoy (alovejoy@concentric.net) wrote:
: If I have an axe to grind, it's against the mindless and completely unsupported 
: claim that static typing is always better than dynamic typing.  I have yet
: to see any empirical proof presented for this claim other than hearsay and
: anecdotes.  I can easily match those with with hearsay and anecdotes in support 
: of dynamic typing.

: If anyone has any stronger evidence, I'd like to see it.

There is an unjustified absence of empirical evidence with respect to many
of these sorts of topics.

Thus we can only discuss logical consequences of languages and make guesses
about their eventual importance. 

A 'statically typed' (type-constrained) language provides more assertions
about the contents of variables. 

One consequence of a "fully dynamically typed language" which appears
undesriable to many users is that a large fraction of the "library" must
often accompany the delivered code.  

Why?  Well if the contesnts of "messages" (method selectors) are mutable
run-time data, then any run-time computation might conceivably result in the
call of any part of the library.   You need the transitive closure of
anything which might possibly be called by a legal program.  Typically 
the compiler will have to be excessively conservative for lack of information. 

A system with more static type constraints can _greatly_ prune this. 
C++ is a bad example, here.  Other languages which know about the global
totality of the system (yeah, Eiffel and derivatives like Sather) tend to
be even more aggressive about eliding provably unused code.  This is feasible
because the actual program source contains many more implicit assertions
which constrain the program. 

Static type constraints permit far more aggressive inlining and fast
run-time representations which are quite important for high performance
calculations.  

A disadvantage of course is less uniform reflectivity.  It's not impossible
though. 

: > >Smalltalk offers many times faster development times--and much greater
: > >robustness in the face of changing requirements.  That's a strategic
: > >advantage, especially in businesses and industries (like securities
: > >trading) where time is not just money, but big, big money.
: > 
: > I acknoledge that Smalltalk has some advantages.  Speed of development
: > seems to be one.
: > 
: > However, I will contest robustness.  What about a system that throws a
: > runtime error if you try to take the sin of a rectangle can be called
: > robust?  This sort of thing happens, even often; much better that the
: > compiler check it than me, given that I'll probably overlook something
: > subtle.

: Smalltalk works on the "80/20" rule.  That is, it is more cost effective
: to take care of the common cases than it is to try to handle every conceivable
: case.  When typing errors only constitute 2% or less of all errors, it's time
: to check the cost of eliminating the final 2% of the problem.  The cost is
: full polymorphism.  IMHO, that's a pretty serious cost.

Remember though that what might have turned out to be a type error in 
a statically typed language might not obviously show up as an equivalent
"type error" in smalltalk or et cetera.  A goal of a 'statically typed'
langauge is to turn many sorts of 'thought errors' into mechanically
checkable type errors. 

In any case, I don't find a large logical advantage to full static
typing in initial development, when I still remember what everything is
supposed to do.  It's when I come back to a component months or years
later and try to modify it that the static type system reminds me not
to do something really stupid---often times things which I've
entirely forgotten. 

: > If OO is about conceptual separation of code into independent modules,
: > why should the modules be concerned about what somebody else gives them?
: > Why should they manually check that the object is capable of the
: > operations demanded when the compiler can?

: This is a non argument.  Since someone must check, there is no difference in
: principle whether that someone is the compiler or the run-time system.  It's
: an implemenation difference, not a difference in kind.

The difference being that a 'statically typed' langauge provides more
assertions to check against.   ISE Eiffel is still Eiffel even when you run it
in "interpreted development" mode. 

: Have you looked at Netscape's IFC library?  It's obviously similar to the 
: VisualWorks MVC classes.  But oh the kludges they have to use for want of
: a #perform: operation!  Just how do you do an AspectAdaptor or PluggableAdaptor
: in Java?

: Used wisely, #perform: is a wonderful thing.  But like any powerful tool,
: it can be seriously misused.  It's no worse than a pointer to function,
: or a BlockClosure, though.

Well a good static langauge with genericity and closures is better than
one without. 

: --
: Alan L. Lovejoy		|==============================================| 
: Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
: alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Ell]

Ole-Hjalmar Kristensen FOU.TD/DELAB (ohk@ultra.tfdt-o.nta.no) wrote:
: Aren't you confusing thes issue of static vs. dynamic typing with the
: issuse of having an interpreter for the language, including an
: integrated development environment?

But doesn't static mean 'compile time' and dynamic imply 'runtime'?  If
you never compile it is all dynamic.  Right?  :-^}

[And all of this ignores strong vs. weak typing.]

Elliott

Re: OO, C++, and something much better!

[Alan Lovejoy]

Graham Hughes wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Looks like it's time for someone to play Devil's Advocate...
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> >But replace "PL/I" with "any statically-typed language," and then you
> >can see the truth: "because any statically-typed language sucks, is
> >why."  (Actually, statically-typed langauges have a useful niche, but
> >that niche does not encompass all of programming).
> 
> Depends on your point of view, I suppose.  The thing that makes me most
> unhappy about Smalltalk, Python, Perl, and the whole gamut of
> dynamically typed OO languages is just that--they are dynamically typed.
> 
> I prefer static typing.  It's largely a matter of interface design and
> subtyping; inheritance as code reuse is fine and dandy, but I prefer to
> program to interface specs.  Something like the Ada package system is
> close to ideal for me, where clearly defined operations on clearly
> defined types are possible (although I don't use Ada much for esthetic
> reasons).
> 
> Subtyping allows me to reuse this code willy-nilly; stronger, it means I
> don't introduce new bugs elsewhere because I'm passing a rectangle
> instead of an integer, and some module deep down was expecting the
> addition to go as planned.
> 
> The enforcability of this concept is what I like about static typing and
> dislike about dynamic typing.  Dynamic typing and languages have their
> places, but I'd prefer to be able to guarantee that the assumptions I
> made about a type are verifiable.
> 
> In Smalltalk, passing a Rectangle where the system expects an Integer
> results in a runtime error (depending on a number of circumstances, of
> course).  This means I won't stumble over the bug until I, or more
> likely, my user, stumbles across this set of circumstances.  Why allow
> for these types of bugs when they can be eliminated or at least reduced?

There is a tradeoff between static typing and dynamic typing.  I sometimes
program in statically-typed languages--because of the performance differences
that strongly affect some (but not most) algorithms.

I don't experience typing errors often enough to feel any need for the crutch
of static typing--at least, not in Smalltalk.  I wouldn't dream of using dynamic
typing in any non-OO language.  I suspect those who have used LISP but not CLOS
or Smalltalk may be negatively influenced towards dyanamic typing by the 
experience.  Not having used Python, I can't comment on that.  (I've been
meaning to give it a try for a while now, but I haven't gotten around to
it yet).

> >Ever heard of StrongTalk?  It's Smalltalk with static typing.  It was
> >a failure in the marketplace.  I conclude that static typing succeeds
> >when marketed to those who believe in static typing, and that dynamic
> >typing succeeds when marketed to those who belieive in dynamic typing.
> >And dynamic typing also succeeds when marketed to people who want the
> >fastest development times, and have no religious axe to grind over the
> >issue.
> 
> I conclude that _you_ have an axe to grind.  I also conclude that one
> failure is not a statistically valid sample.  I can claim that fully
> 100% of my development team prefers static typing, because _I_ am my
> development team.  Come back with something done by a statistician
> (although finding an honest statistician is often like finding an honest
> lawyer... :-); isolated cases prove nothing.

If I have an axe to grind, it's against the mindless and completely unsupported 
claim that static typing is always better than dynamic typing.  I have yet
to see any empirical proof presented for this claim other than hearsay and
anecdotes.  I can easily match those with with hearsay and anecdotes in support 
of dynamic typing.

If anyone has any stronger evidence, I'd like to see it.

> >Smalltalk offers many times faster development times--and much greater
> >robustness in the face of changing requirements.  That's a strategic
> >advantage, especially in businesses and industries (like securities
> >trading) where time is not just money, but big, big money.
> 
> I acknoledge that Smalltalk has some advantages.  Speed of development
> seems to be one.
> 
> However, I will contest robustness.  What about a system that throws a
> runtime error if you try to take the sin of a rectangle can be called
> robust?  This sort of thing happens, even often; much better that the
> compiler check it than me, given that I'll probably overlook something
> subtle.

Smalltalk works on the "80/20" rule.  That is, it is more cost effective
to take care of the common cases than it is to try to handle every conceivable
case.  When typing errors only constitute 2% or less of all errors, it's time
to check the cost of eliminating the final 2% of the problem.  The cost is
full polymorphism.  IMHO, that's a pretty serious cost.

> If OO is about conceptual separation of code into independent modules,
> why should the modules be concerned about what somebody else gives them?
> Why should they manually check that the object is capable of the
> operations demanded when the compiler can?

This is a non argument.  Since someone must check, there is no difference in
principle whether that someone is the compiler or the run-time system.  It's
an implemenation difference, not a difference in kind.

> >Not in Java.  Java won't let you send any message that the compiler doesn't
> >know will be valid.  And there is no equivalant of #perform: (which sends
> >a message chosen at run time).
> 
> And #perform: is a good thing?  I can achieve a similar operation in C++
> (not Java, though) with pointer-to-member-functions in a map<> or an
> array or something, and it's even typesafe, so I don't have to worry
> (too much) about some perverted piece of code messing with my mind.

Have you looked at Netscape's IFC library?  It's obviously similar to the 
VisualWorks MVC classes.  But oh the kludges they have to use for want of
a #perform: operation!  Just how do you do an AspectAdaptor or PluggableAdaptor
in Java?

Used wisely, #perform: is a wonderful thing.  But like any powerful tool,
it can be seriously misused.  It's no worse than a pointer to function,
or a BlockClosure, though.
 
> ...
> 
> Unlike yourself, I have no qualms about others using dynamic typing.
> Please, go ahead; if the advantages of it outweigh the disadvantages for
> your projects, by all means use Smalltalk.  I use Python, a dynamically
> typed OO language, for much of my scripting because it's far easier to
> get a prototype working.  For larger projects, particularly ones that I
> cannot hold entirely inside my head, I prefer a statically typed
> language for the reasons above.
> 
> But don't you _dare_ try to enforce your preferences upon me.

I was defending Smalltalk and dynamic typing, not trying to force anyone to
use those if they don't care to.  Sorry if it seemed otherwise.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <5c1nst$l8o@news3.digex.net> ell@access4.digex.net (Ell) writes:

   Ole-Hjalmar Kristensen FOU.TD/DELAB (ohk@ultra.tfdt-o.nta.no) wrote:
   : Aren't you confusing thes issue of static vs. dynamic typing with the
   : issuse of having an interpreter for the language, including an
   : integrated development environment?

   But doesn't static mean 'compile time' and dynamic imply 'runtime'?  If
   you never compile it is all dynamic.  Right?  :-^}

   [And all of this ignores strong vs. weak typing.]

   Elliott

As there are interpreters for C++, I guess C++ is a dynamically typed
language? And the existence of a Scheme or Lisp compiler means that
they are statically typed? 

Re: OO, C++, and something much better!

[Alan Lovejoy]

David Hanley wrote:
> 
> Alan Lovejoy wrote:
> >
> > Damon Feldman wrote:
> 
> > > If they had _SmallTalk_ with static typing, would they use it instead of
> > > SmallTalk?  Since Java is just such a product, and is the hottest thing out
> > > there right now, it could be that people *are* convinced that OO w/ static
> > > typing is the way to go.
> >
> > Ever heard of StrongTalk?  It's Smalltalk with static typing.  It was a failure
> > in the marketplace.  I conclude that static typing succeeds when marketed to
> > those who believe in static typing, and that dynamic typing succeeds when
> > marketed to those who belieive in dynamic typing.
> 
>         That's a good start, but it avoids the issue that most people beleive
> in static typing, and why this is the case.

Ok. Why is this the case?

> >  And dynamic typing also succeeds
> > when marketed to people who want the fastest development times, and have no religious
> > axe to grind over the issue.
> 
>         This is in no way proved, and, I beleive, false.

I think it has been proven quite well.  Believe what you want.  I don't have time
to repeat the evidence--for which you have offered no refutation.

> >
> > Why would Prudential choose Smalltalk as a replacement for COBOL, when they could
> > choose whatever they wanted (http://www.software.ibm.com/ad/stmvs/stpru.htm)?
> 
>         The made a bad choice.  Why did they go with cobol in the first place?
> Why do so many others go with C/C++?

Because most follow the conventional wisdom (wrong or right)?  Many of those who are
adopting Smalltalk tried C++ first.  It's why they were open to trying something
unconventional.

> >
> > Why has the use of Smalltalk been growing at 60% per year?
> 
>         Why is it still practcally nonexistant?  Why is java growing many times
> faster?

Marketing and marketing.  None for Smalltalk, the most brilliant in the history of
computer languages for the other.  I's amazing Smalltalk survives, let alone continues
to grow, given the difference in marketing efforts.

I think posts like this bring Smalltalk to the attention of more people than all the
marketing efforts of all the Smalltalk vendors combined.  Sigh.

> > Smalltalk offers many times faster development times-
> 
>         Than what?  And what is your proof of this?

Than COBOL, C, C++, Java.

My own experience and that of many others.

Independent studies that have been done.  See, for example, the following:

	<http://www.spr.com/library/langtbl.htm>.

> > -and much greater robustness
> > in the face of changing requirements.
> 
>         Except for when all your messages aren't working.

Do you have this problem often?  I don't.  In fact, I can't remember any time
when ALL my messages weren't working.

> >   That's a strategic advantage, especially
> > in businesses and industries (like securities trading) where time is not just
> > money, but big, big money.
> 
>         And program problems are big, big problems.

Yep.  That's why the ease and rapidity with which they can be fixed in Smalltalk
is so much appreciated.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Fergus Henderson]

Alan Lovejoy <alovejoy@concentric.net> writes:

>David Hanley wrote:
>> 
>> Alan Lovejoy wrote:
>> >
>> > Smalltalk offers many times faster development times-
>> 
>>         Than what?  And what is your proof of this?
>
>Than COBOL, C, C++, Java.
[...]
>Independent studies that have been done.  See, for example, the following:
>
>	<http://www.spr.com/library/langtbl.htm>.

The quoted URL contains a table listing languages and their
corresponding "language level".  Unfortunately the data in the table is
certainly not reliable or reproducible, and indeed perhaps not even
meaningful.  The explanatory text describes how some of the data was obtained:

 |    Research was done by reading descriptions and genealogies of languages
 |    and making an educated guess as to their levels.

Our only consolation is that at least the author admits that
"... the margin of error ... can be quite high.".

Some of the data is patently ridiculous, and indeed the whole idea that
one can measure "language level" on a single scale and hope to get
meaningful results is highly suspect.

By the way, if you believe that table, then you should quickly switch
from Smalltalk to MATHCAD, since that will supposedly increase your
productivity by a factor of four.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Fergus Henderson]

I wrote:

>For a period of time I carefully recorded the cause of every error that
>I found while writing a Mercury program.  Of the 155 errors that I
>recorded, 73 were error caught by the type checker.
		   ^^^^^ <---- I meant "errors".

Of course, no doubt these figures vary from individual to individual;
no doubt there are people who make fewer of these sort of mistakes
in their both their programs and their news postings ;-)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Alan Lovejoy]

Fergus Henderson wrote:
> 
> "Matthew S. Whiting" <whiting@epix.net> writes:
> 
> >Anyone, know REALLY how Smalltalk got its start in the financial
> >application space?
> 
> I don't know how it got its start there, but I have heard that it got a
> bit of a boost after the stockmarket crash in '87.  Apparently the
> volume of shares traded was very high, and many financial programs
> failed, because the numbers involved were so large that they overflowed
> various limits, but the Smalltalk programs kept running, because
> Smalltalk quietly switches to using floating point arithmetic when
> integer arithmetic overflows.  (Well, that's the rumour anyway.  I
> don't know how much truth there is to it.)

1. I've never heard any such story before (although it could well be true).

2. Technical point: Smalltalk doesn't switch over to using Floats when the
range of SmallInteger is exceeded (typically -2^29..+2^29, although it varies).
But it does switch to using LargeIntegers (whose upper value limit is constrained
only by available memory).  It does this completely automatically. LargeIntegers
and SmallIntegers are completely interchangeable.

Similarly, Smalltalk Dates don't suffer from the Year 2000 problem. The year
is stored as an Integer (which would probably be a SmallInteger, but will
automatically convert to a LargeInteger as required).

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Eric Clayberg]

Fergus Henderson wrote:
> Alan Lovejoy <alovejoy@concentric.net> writes:
> >When typing errors only constitute 2% or less of all errors, it's time
> >to check the cost of eliminating the final 2% of the problem.
> My experience is that errors caught by type checking constitute a LOT
> more than 2% of errors.
> For a period of time I carefully recorded the cause of every error that
> I found while writing a Mercury program.  Of the 155 errors that I
> recorded, 73 were error caught by the type checker.

If anything, I think that reflects poorly on the syntax of whatever
language you were using. The more "rules" a language has, the more
involved its syntax, and the more draconian its type system, then the
more type errors are likely to be created by the developer and then
caught by the compiler. In a language like Smalltalk which has an
absurdly simple, consistent syntax, and which has a very open-mined
concept of "type", very few type errors are ever created to begin with
and thus very few actually exist to be found. The *few* real type errors
that are created tend to be caught almost immediately by Smalltalk's
superb debugging facilities.

Having been involved with commercial Smalltalk development for quite a
few years, I tend to agree with Alan that the percentage of actual type
related errors in Smalltalk programs is less that 2% - far less in my
experience. I have written over several hundred thousand lines of
commercial Smalltalk code and have been involved in several dozen large
Smalltalk projects (ranging from 100,000 lines of code and up). In all
that time, I have only run across a handful of true type errors (of the
nature that a static type checker would catch). The Smalltalk language
is very simple and very flexible and makes a lot of things perfectly
legal that would not be allowed in, say, C++. Most "message not
understood" errors, in fact, are to the nil object in Smalltalk (the
moral equivalent of a null pointer in C). These are not really type
errors, but usually problems with improper initializations or premature
discarding of data. These are logic problems; not type problems. A
static type checker would catch them no better in Smalltalk than it
would in C++.

I am amazed at the level of hubris evidence in this discussion. Folks
are jumping in and making assumptions about how Smalltalk works based
upon how their favorite statically typed language works. Smalltalk has
very different rules than what are common in most statically typed
languages. Smalltalk simply doesn't need static type checking. If you
have any doubts about that, then you should try it out yourself. You can
download Smalltalk Express (a fully function, 16-bit Windows Smalltalk
IDE) for free from http://www.objectshare.com.

-Eric

Re: OO, C++, and something much better!

[Eric Clayberg]

Fergus Henderson wrote:
> I don't know how it got its start there, but I have heard that it got a
> bit of a boost after the stockmarket crash in '87.  Apparently the
> volume of shares traded was very high, and many financial programs
> failed, because the numbers involved were so large that they overflowed
> various limits, but the Smalltalk programs kept running, because
> Smalltalk quietly switches to using floating point arithmetic when
> integer arithmetic overflows.  (Well, that's the rumour anyway.  I
> don't know how much truth there is to it.)

Actually, Smalltalk transparently switches to using "large" integers
that have no limits on size. In fact, it's actually fun to run large
factorials in Smalltalk to see how large an integer it will generate.
VisualSmalltalk will calculate the result of "1000 factorial" in a
second or two and display the results. BTW, the result of that
expression is: :-)

<encoded_portion_removed>

-Eric

Re: OO, C++, and something much better!

[Fergus Henderson]

Alan Lovejoy <alovejoy@concentric.net> writes:

>When typing errors only constitute 2% or less of all errors, it's time
>to check the cost of eliminating the final 2% of the problem.

My experience is that errors caught by type checking constitute a LOT
more than 2% of errors.

For a period of time I carefully recorded the cause of every error that
I found while writing a Mercury program.  Of the 155 errors that I
recorded, 73 were error caught by the type checker.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Eric Clayberg]

Norman H. Cohen wrote:
> Having worked with both dynmically and statically typed languages, my
> (unquantified) experience is that dynamic typing speeds up program
> development about as much as touch typing.  :-)  That is,  it reduces
> data entry time because you don't have to type all those declarations.
> Of course this is a minuscule fraction of program development time. Once
> a program has been keyed in, strong typing results in a flurry of
> compile-time errors that must be addressed before the program will run.
> Of course dynamic typing does not make these errors go away, it just
> hides them so that you have to find them yourself instead of having them
> pinpointed for you by a compile-time error message.

Not true. In a language like Smalltalk, those "errors" as you call them
are not hidden; they never existed to begin with. Having worked
extensively with several statically types languages (C, C++, Fortran,
etc.) and now having worked commercially with Smalltalk over the last
several years, I conclude that most "type" errors in statically types
languages are due to the complicated nature of their syntaxes and the
draconian rules of their type systems. Smalltalk doesn't have those
problems and doesn't lend itself to "type" errors of that nature. Almost
all "message not understood" errors are messages directed to nil (the
moral equivalent of a null pointer in C). 

> In my experience, a line containing a stupid mistake that would have
> been caught by decent compile-time checks can easily take 50 times as
> long to develop (counting the time to debug a line as part of that
> line's development time) as a line without such an error.  In that case,
> even if we accept the 2% figure, static typing is still a win.

I don't follow that logic at all. I think you are multiplying apples and
oranges together to get pears. The dubuggers commonly available with
most Smalltalk systems make finding and fixing bugs a trivial process -
certainly no harder than writing the code in the first place.

> Development time is of interest, of course, not in its own right, but
> because of its impact on project value and cost to the customer.  The
> cost of a less timely deployment of a program must be weighed against
> the cost of an error that arises for the first time in the field,
> because the programming language did not allow the error to be caught at
> compile time and the run-time testing was incomplete.  If you are lucky,
> the software merely fails, and the customer reverts to contingency
> procedures while programmers working overtime rush a patch out to the
> customer.  If you are unlucky, the program appears to work correctly,
> but provides an incorrect result that causes your customer to lose tens
> of millions of dollars on an absurd securities trade.

It's funny that you should mention securities industry. Quite a few Wall
Street investment banks use Smalltalk for their securities trading
systems. Having been involved with several securities-related Smalltalk
projects in the past, I can tell you some of the reasons why Smalltalk
is so popular there: 1) it provides much faster time to market (very
important in the securities industry), 2) it has a simple, logical and
consistent language syntax (developers can concentrate of the problem at
hand and not the vagaries of the syntax), 3) it is extremely reliable in
practice (the language features of Smalltalk help eliminate whole
classes of errors common in languages like C++), and 4) it is extremely
easy to debug when an error does occur. If you doubt that any of these
are true, then you should try it out yourself. You can download
Smalltalk Express (a fully functional, 16-bit WIndows Smalltalk IDE) for
free from http://www.objectshare.com.

-Eric

Re: OO, C++, and something much better!

[Ell]

Actually I very rarely do something like assign a char to an int, or an
object from one tree to a pointer for another tree.  Hungarian or similar
variable names help me in avoiding doing things like that.  Mostly a
compiler helps me with syntax errors which an interpreter will do. 

Elliott

Re: OO, C++, and something much better!

[Eric Clayberg]

Joachim Durchholz wrote:
> In other words: I'd feel really embarrassed if the user ever saw a
> "message not understood" error.

What about if your program crashed because you tried to address a null
pointer? Does this mean you shouldn't use C or C++? Almost all "message
not understood" errors are simply messages sent to nil (the moral
equivalent of a null pointer). This usually happens either when
something isn't initialized yet or it has been prematurely released -
certainly mot uncommon occurrences in the static typing world. Real type
errors (e.g., those that a static typing system would actually catch)
rarely ever occur in Smalltalk. The simplicity and consistency of the
language drastically reduces the scenarios where a real type error would
occur. On those rare occasions where a type error does occur,
Smalltalk's excellent debugging facilities make them very easy to
correct.

But rather that guess about Smalltalk, why not give a try and see for
yourself? You can download Smalltalk Express (a fully functional 16-bit
Windows Smalltalk IDE) for free from http://www.objectshare.com.

-Eric

Re: OO, C++, and something much better!

[Alan Lovejoy]

Fergus Henderson wrote:
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> >David Hanley wrote:
> >>
> >> Alan Lovejoy wrote:
> >> >
> >> > Smalltalk offers many times faster development times-
> >>
> >>         Than what?  And what is your proof of this?
> >
> >Than COBOL, C, C++, Java.
> [...]
> >Independent studies that have been done.  See, for example, the following:
> >
> >       <http://www.spr.com/library/langtbl.htm>.
> 
> The quoted URL contains a table listing languages and their
> corresponding "language level".  Unfortunately the data in the table is
> certainly not reliable or reproducible, and indeed perhaps not even
> meaningful.  The explanatory text describes how some of the data was obtained:
> 
>  |    Research was done by reading descriptions and genealogies of languages
>  |    and making an educated guess as to their levels.
> 
> Our only consolation is that at least the author admits that
> "... the margin of error ... can be quite high.".
> 
> Some of the data is patently ridiculous, and indeed the whole idea that
> one can measure "language level" on a single scale and hope to get
> meaningful results is highly suspect.
> 
> By the way, if you believe that table, then you should quickly switch
> from Smalltalk to MATHCAD, since that will supposedly increase your
> productivity by a factor of four.

The data are admittedly less than rigorous.

If you or anyone can find a better source, please share it.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Graham Hughes]

-----BEGIN PGP SIGNED MESSAGE-----

More preaching to the converted, it seems...

Eric Clayberg <clayberg@parcplace.com> writes:

>If anything, I think that reflects poorly on the syntax of whatever
>language you were using. The more "rules" a language has, the more
>involved its syntax, and the more draconian its type system, then the
>more type errors are likely to be created by the developer and then
>caught by the compiler. In a language like Smalltalk which has an
>absurdly simple, consistent syntax, and which has a very open-mined
>concept of "type", very few type errors are ever created to begin with
>and thus very few actually exist to be found. The *few* real type errors
>that are created tend to be caught almost immediately by Smalltalk's
>superb debugging facilities.

Bullshit.  If I pass a rectangle to something expecting an integer, no
amount of ``absurdly simple, consistent syntax'' or ``open-minded
concepts of "type"'' will prevent the ensuing carnage.  Having a type
error propogate to the user is the height of immaturity.  What makes you
think that the ``superb debugging facilities'' are going to be at the
installation site?

And before you say that no one will ever pass a rectangle to something
expecting an integer, realize that this could easily be the result of a
typo on your part, or your caller's part, and so on up the chain.  This
can be forstalled slightly by an incremental building process, but
incremental building processes don't require Smalltalk or dynamic typing
or interpreters.

>Having been involved with commercial Smalltalk development for quite a
>few years, I tend to agree with Alan that the percentage of actual type
>related errors in Smalltalk programs is less that 2% - far less in my
>experience.

You mean the percentage of actual type related errors that you have
actually _caught_, no?  There is a substantial difference.

In my own experience, most type errors are the result of typos or of
mismatches between what I _think_ is the right way to call a function
and what the right way actually is.  C's fgets() is a reasonably good
example of this.  This is a stylistic issue, and switching to named
arguments or Smalltalkish message parameters doesn't solve it, only
forstall it.

Much better that something mechanical check this than I; I have been
known to make mistakes, or overlook things.  Of course, the machine is
perfectly incapable of actually writing the software on its own, which
is where I come in.

Ada compilers, which are otherwise not my favorite things in the world
to deal with, are good examples of this philosophy.  Ada believes very
strongly in catching every error that is possible to catch at compile
time.  The result: while it's not impossible to get a buggy program
pushed through an Ada compiler, you stand a very good chance of getting
yelled at for your bonehead typos.

>I am amazed at the level of hubris evidence in this discussion. Folks
>are jumping in and making assumptions about how Smalltalk works based
>upon how their favorite statically typed language works. Smalltalk has

I _have_ used Smalltalk.  It has some interesting concepts, and the
message protocol and metaclasses are elegant in their own ways.  But I'm
not about to rely on it to catch my typos, which are the source of 90%
of my bugs these days, any more than I'm going to rely on my C++
compiler to catch logic errors for me.

Your perception of the tradeoffs are obviously different, and that's
fine; I prefer differing points of view to pushing down the party line.
I don't believe, however, that dynamic typing is the saviour from above,
or that it's going to save the world.  It's had _lots_ of time.

Incidentally, if you really care about spreading Smalltalk you might
want to attempt to get the FSF to fix their Smalltalk implementation.  I
can't fiddle around with Smalltalk anymore because that's the only
one I can get for Linux, and it doesn't work.
- -- 
Graham Hughes (graham.hughes@resnet.ucsb.edu)
http://A-abe.resnet.ucsb.edu/~graham/ -- MIME & PGP mail OK.
"Never attribute to malice that which can be adequately explained by 
	stupidity." -- Hanlon's Razor

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMuaT/SqNPSINiVE5AQFnVwP+IZZZWjclFEOM4bh5zJ50q34A5s7EWsaX
PbiSmVh4k0Wzz7sFIQqNfjzYKso8a09eVj1xPOj2Kl0lqJ1uVzqm6nHJtv4pE92U
XGEqexLs57dLdHBSZEDkXvqDw76WXqV6uSSy22hg+UDjPAcMvnERgHKghFc0ss5M
LSRrMRBx+2Q=
=vyYE
-----END PGP SIGNATURE-----

Re: OO, C++, and something much better!

[John Kuszewski]

Don Harrison wrote:
> 
> Fergus Henderson writes:
> 
> :I don't know how it got its start there, but I have heard that it got a
> :bit of a boost after the stockmarket crash in '87.  Apparently the
> :volume of shares traded was very high, and many financial programs
> :failed, because the numbers involved were so large that they overflowed
> :various limits, but the Smalltalk programs kept running, because
> :Smalltalk quietly switches to using floating point arithmetic when
> :integer arithmetic overflows.
> 
> That's a worry.

That's not a worry--that's just wrong.  Smalltalk quietly switches
to a LargeInt object when integers overflow.  The guys who write 
Smalltalk environments aren't idiots.

-- 
                                   _____________
                                   |        ___/_
                                   |        |/  /
                                   --  /\  //  /--
                                   ||  ||  /  /||
                                   ||  || /  / ||
                                   ||  ||/  /  ||
John Kuszewski                     ||  |/  /|  ||      
johnk@spasm.niddk.nih.gov          ||  /  /||  ||
                                   \/ /  / ||  \/
that's MISTER protein G to you!     |/__/|      |
                                      /_________|

My parents went to Zaire and all I got 
was this lousy retrovirus.

Re: OO, C++, and something much better!

[Don Harrison]

Fergus Henderson writes:

:I don't know how it got its start there, but I have heard that it got a
:bit of a boost after the stockmarket crash in '87.  Apparently the
:volume of shares traded was very high, and many financial programs
:failed, because the numbers involved were so large that they overflowed
:various limits, but the Smalltalk programs kept running, because
:Smalltalk quietly switches to using floating point arithmetic when
:integer arithmetic overflows.  

That's a worry.

:(Well, that's the rumour anyway.  I
:don't know how much truth there is to it.)

I guess it won't be so much of a problem in the crash of 1997 as most
hardware now uses 32 bits. :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Richard A. O'Keefe]

jhd@herold.franken.de (Joachim Durchholz) writes:
>Oh yes there is a difference. The compiler will catch all errors; the run- 
>time system will miss some.

I have seen this argument the other way around:
in a language with strong *dynamic* checking, the run time system
catches all the errors that actually happen, while a static checker
misses a lot of them.

It simply isn't true that "the compiler will catch all errors".
Or rather, it is true only if you play language games and
redefine "errors" to be things that can be checked statically
leaving run time attemps to apply operations outside their domains
looking for another name.

For example, 
	A: array (Integer range 0 .. 1) of Integer;
	I: Integer;
	...
	I := A(I);

A compiler would catch I(A) as a static type error, but not the case
where I is 2 at run time.  To someone with a dynamic typing perspective,
_both_ I(A) and A(2) are attempts to apply an operation (subscripting)
to arguments outside its domain.

Surely the answer is not to be dogmatic either way, but to accept that
 - no amount of static checking is ever going to eliminate the need
   for _all_ dynamic checking
 - dynamic checking has a run time cost; other things being equal it
   is better to move it to compile time
 - dynamic checking has a life cycle cost; other things being equal
   it is better to catch errors with a compiler than with testing
 - static checking limits expressiveness to what the language designer
   believed was feasible (the Ada 95 type system really is very limited,
   why TYPE isn't even a type!)
 - static checking has a life cycle cost; it _may_ pay off during a
   prototyping phase, for example.

>In other words: I'd feel really embarrassed if the user ever saw a  
>"message not understood" error.

Don't worry, I see enough "core dumped" messages on one system and
pretty pictures of bombs on another, and my friends see "GPF" often
enough, that we'd forgive you...

>IMHO, bugs that can be found automatically should be found automatically.  

Not all languages are used by software engineers.  For example, I am
currently working with a language called R, based on S.  It's an
interactive programming language for statistics and graphics.  S is well
regarded by its users,  If it required declarations, they wouldn't use it.
(Serious number crunching is done via a type checked interface to C and
Fortran.  S code is normally used to decide _what_ to compute rather than
_how_ to compute it.)  The things a statistician does and programs with S
are at least in part driven by what _today's_ data set turns out to be
life.  It's a very different _kind_ of life cycle.

>So, dynamic typing has the disadvantage that it makes a set of compile- 
>time checks impossible.

This is simply false.  For example, the Mycroft/O'Keefe type checker
for Prolog is a static type checker for Prolog.  Having dynamic type
checking in the underlying Prolog system in *NO* way prevents layering
a good static type checker on top.  In the same way, there are a number
of static type checkers around for Scheme; the fact that the underlying
implementation does dynamic checking in *NO* way "makes a set of
compile-time checks impossible" or even particularly difficult.  All it
means is that the static type checker will reject some Prolog or Scheme
programs that would have had no run time type errors; no limitation
_compared with other static systems_ is entailed.

>The only issue worth discussing is wether this  
>disadvantage is set off by added flexibility, or not. And the result of  
>the discussion may well be different depending on circumstances - e.g. how  
>much of the Smalltalk flexibility is actually due to the environment, not  
>to dynamic typing?

In the case of S and R, the environment is pretty limited.  It is
_definitely_ the dynamic typing which make these languages attractive
to their intended users.  For example, a common transformation is to
take slightly adjusted square roots of counts.  So let's do

	transform.count <- function (count) sqrt(count + 0.5)

Ok, now we have a function which will accept a single number, a vector,
an array with any number of subscripts, a time series, one of these
things with or without dimension labels, and so on, and it will "do the
right thing".  (Anyone who is reminded of APL ought to be.)  Oh yes, and
the numbers could be integers, single precision, double precision, or
complex.  It is not beyond human power to come up with a type system
that can handle this kind of thing, assume
	integer <: single <: complex <: double-complex
		   single <: double  <: double-complex

0.5: single

+ : dimension DL array of TL where TL <: double-complex
  x dimension DR array of TR where TR <: double-complex
 -> dimension max(DL,DR) array of lub(TL,TR)

sqrt : dimension D array of T where T <: double-complex
    -> dimension D array of lub(single, T)

from which we can infer (in a Hindley-Milner sort of way)

transform.count : dimension D array of T where T <: double-complex
               -> dimension D array of lub(T, single)

except that S values may have many other attributes.  The type system
would be fairly complex.  (The type of transform.count, for example,
even if expressed as something like
	[D,T<:double-complex,A] -> [D,lub(T, single),A]
is bigger than its code.)

-- 
My tertiary education cost a quarter of a million in lost income
(assuming close-to-minimum wage); why make students pay even more?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Don Harrison]

Matthew Heaney writes:

:In article <E44u82.6uB@syd.csa.com.au>, donh@syd.csa.com.au wrote:
:
:>:Where's the polymorphism of
:>:any form here?  Subtypes are ways of defining constraints (simple
:>:"assertions") on the possible values of the type.  Sub_Integer is not
:>:a new type and is not a type derivation.  So, you only have one type
:>:here (Re: RM: 3.2(8))
:>:
:>:The CE, is simply stating that you have violated the constraint
:>:(assertion).  No polymorphism broken or otherwise involved.
:>
:>Yes, if you define subtypes as such, then I concede it may be more reasonable 
:>to regard this as simply an assertion violation and declare the type system
:>free of holes. It's a question of definition.
:
:Precisely, Don.  It *is* question of definition, and we're comparing apples
:and oranges.  You may want to read any of Peter Wegner's papers, where he
:explains the difference between a "type" and a "class."
:
:A type has "range" semantics.  Subtypes of the type constrain the range of
:values objects of the type can have.

That's one view. Another view is to consider such 'subtypes' as types in 
their own right. This is more honest, IMO. Using this definition, neither Ada 
nor Eiffel is 'type-safe'.

:A class has "template" semantics.  A subclass specializes the behavior of
:the parent.
:
:Jon is correct in pointing out that the example you gave is an example of
:the former.  Sub_Integer is a subtype (in the Wegner sense) that denotes a
:subset of the values of its parent.  There is no polymorphism, because we
:aren't dealing with classes (in the Wegner sense).

Sure. However, I am not refering to polymorphism in the usual sense. :)
I originally wrote "a kind of broken polymorphism". In a more general sense, 
"polymorphism" means "taking many forms" which is what happens when you use 
a parent value where a value of a constrained child type (according to the 
alternative definition) is required. So, if this 'polymorphism' results in
a runtime error, then it is also broken - "a kind of broken polymorphism". 

:(Note that the term class as used by Wegner is not the same as the Ada 95
:meaning.  In Ada, a class refers to a family of types.)
:
:And as far as your example "proving" that Ada is not type-safe: that is
:incorrect.  

Correct, according to the Ada definition. As Norman Cohen put it,

: It shows that Ada is not subtype-safe.

That becomes "not type-safe" if you regard sub-types as distinct types.

:  In fact the behavior proves just the opposite.

I think you mean that the (primitive) assertion mechanism contributes to
data integrity. It certainly doesn't 'prove' type safety.

:Constraint_Error was raised because the range constraint was violated. 
:This behavior is similar to the Eiffel behavior when a precondition is not
:satisfied.  The terms of the contract between the client (the caller) and
:server (the subprogram) were violated by the client, so an exception was
:raised.  Isn't that what you would expect to happen?

Sure. However, whether or not it should happen is not the topic of discussion.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Damon Feldman]

 Alan Lovejoy <alovejoy@concentric.net> wrote:
>Damon Feldman wrote:
>>  Alan Lovejoy <alovejoy@concentric.net> wrote:
>> >Fergus Henderson wrote:

>> If they had _SmallTalk_ with static typing, would they use it instead of
>> SmallTalk?  Since Java is just such a product, and is the hottest thing out
>> there right now, it could be that people *are* convinced that OO w/ static
>> typing is the way to go.

>Ever heard of StrongTalk?  It's Smalltalk with static typing.  It was a failure
>in the marketplace.

There could be a lot of explanations for this.  Why has SmallTalk floundered 
for some 20 years (if you start w/ ST72 and go up to 4 years ago).  Success in 
the free market doesn't equate to good language design or high productivity 
all the time.  Look at all the C and COBOL out there :-).

>Why would Prudential choose Smalltalk as a replacement for COBOL,

There are many possibilities other than dynamic typing.

>> Also, can't you just send everything flying around the system as an Object
>> (root of the whole class tree) in those situations when you want dynamic
>> typing?
>
>Not in Java.  Java won't let you send any message that the compiler doesn't
>know will be valid.

This strikes me as a more valid point.

But it raises the question of exactly when you would want to send a message 
that might raise an error if you're not careful about the procedural flow that
gives rise to the message send. This task is hard enough in a procedural 
system, and OO should insulate us from all things procedural, anyway (1/2 :-).

Don't you generally *know* that the message will be handled because you know 
that only descendents of a certain class will be the reciever?  In which case 
you can declare the reciever of that type and still enjoy polymorphism without
having the programmer keep track of what flows give rise to what types for 
which objects at what times.

Damon

Re: OO, C++, and something much better!

[Fergus Henderson]

"Matthew S. Whiting" <whiting@epix.net> writes:

>Anyone, know REALLY how Smalltalk got its start in the financial
>application space?

I don't know how it got its start there, but I have heard that it got a
bit of a boost after the stockmarket crash in '87.  Apparently the
volume of shares traded was very high, and many financial programs
failed, because the numbers involved were so large that they overflowed
various limits, but the Smalltalk programs kept running, because
Smalltalk quietly switches to using floating point arithmetic when
integer arithmetic overflows.  (Well, that's the rumour anyway.  I
don't know how much truth there is to it.)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Ulrich Windl]

I guess it's just a matter of fact that short routines are most
oftenly called (If you don't manipulate your instance variables
directly).

Ulrich Windl

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "ok" == Richard A O'Keefe <ok@goanna.cs.rmit.EDU.AU> writes:

[ ... on ease of learning ``C++'' and its popularity ... ]

ok> Speaking as someone who bought the first C++ book to come out, the
ok> C++ that became popular in the first place is not the C++ that
ok> people discuss now.  To start with, it didn't have multiple
ok> inheritance, templates, exceptions, or RTTI.

Very good point! Which adds to the motivation for my oft repeated stance
that ``C++'' is a brand name, and can in effect mean any of a few quite
different (even if related by very good backwards compatibility) languages.

ok> Hmm.  When I learned about C++ in the mid-80s, the only available
ok> alternatives _that I was aware of_ were some sort of Lisp (Common
ok> Lisp not then being available) with some sort of home brew Flavors
ok> lookalike (CLOS not then being available) or Smalltalk.  Simula 67
ok> _may_ have been available for VAX & Sun but if there were marketing
ok> dollars behind it they never managed to put a mention of it where I
ok> could see it.  What _were_ the VAX, Sun, Apollo alternatives to C++
ok> a decade ago?

This is an excellent point, but one that has some (partial) answers.

Most importantly there was ``Objective-C'' which was implemented rather
portably by generating ``C'', like 'cfront' was doing for ``C++''; I
have my early copy of Brad Cox's "OOP: and evolutionary approach"
describing it dated 1986, and indeed I bout it over ten years ago.  It
was used to develop RMG, an impressive ``Smalltalk''-like graphical
environment, which would still be impressive today, never mind 10 years
ago, which was being distributed, in very good shape as well, to
universities and research institutes in 1987. It is easy to argue that
Objective-C never achieved lasting fame for a number of unfortunate
reasons; among them that Brad Cox ``cleverly'' kept its compiler
proprietary instead of more or less givin it away ("cfront" was licensed
fairly cheaply, so that even a one man company like Comeau could port it
and sell it on a variety of platforms).

But there were other alternatives, which however have remained
resolutely locked up in the research world (and some like ``Smalltalk''
have only escaped it as their sell-by-date has already expired).

Some of them originated from BTL themselves; there was a number of C
derived languages being developed at BTL concurrently with ``C++'', some
of them being good contestants. But it was ``C++'', for various not
necessarily technical reasons, that became popular within AT&T and the
world (again, easy compiler licensing was IMNHO crucial: a bit like the
sudden popularity of Pascal in Universities was due to the easy
availability of the bytecode compiler, and of the CDC sample
implementation).

Now, I personally like ``C++'' (up until 2.x, that is, more recent
features I like less), for I am a language lawyer and a system
implementor with it; but I find it abhorrent that it has become popular
as the application development language of choice by anybody, as it is
simply too sophisticated and low-level (just like C itself). If only had
Objective-C become the application development language of choice! If
only more people had seen RMG! and so on.

Re: What is wrong with OO ?

[Bertrand Meyer]

Chris Bitmead wrote:
 
[Quoting me, quotation abridged:]

> >ISE Eiffel does give the user a degree of parameterization:
> >a compilation option specifies the size threshold beyond which
> >a routine will not be inlined. 

[...]

> >Most users are happy with the
> >default, which inlines small, frequently called routines.

[Chris Bitmead:]

> How on earth does the compiler know if a routine is "frequently
> called"?

Sorry, sloppy wording on my part. I meant "called from many different
places in the code", which  does tend to correlate with the numbers of
times the routine will be called, although of course this is not always
true (as with a routine that is called from just one place, but that
place is in a loop). Just one criterion among others. Thanks for noting
the incongruity in my original message. 

-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: What is wrong with OO ?

[Bertrand Meyer]

Bjarne Stroustrup wrote:

> C++ use grew
> very nicely for years without hype. I base my statement on years of looking
> at C++ use, teching, and learning - many of those years were before anyone
> was given time off from their day job to learn C++.

[...]

> [C++] would have died during
> the early years where there were essentially no C++ marketing and alternatives
> languages with marketing dollars behind them existed.

This is really too far off the reality to let pass. Not that I think
Bjarne Stroustrup is less than forthcoming; he is undoubtedly sincere in
believing that he was a researcher led by purely intellectual motives
competing against crass commercialists. From within Bell Labs he may
have had that impression. But anyone seeing the real situation in the
software world at large could not fail to notice the gigantic amount of
both "hype" (his term in the first paragraph) and "marketing" (his term
in the second) behind C++. The mere fact that it came from AT&T and was
from the start endorsed by other billion-dollar companies was what got
the industry to listen. It does not mean that the language was bad (and
neither does it mean the reverse) - simply that the quality of the
language was, if not completely irrelevant, far secondary to the
marketing push.

In the field of advanced technology, furthermore, marketing is not just
expensive ads in magazines. It is also access of various approaches to
scientific conferences and publications. The record of OOPSLA in this
respect has been (and continues to be) less than pristine. To put it
politely, it has always been made very clear that some approaches were
more equal than others.

This has had a rather vicious consequence: that people promoting
less-hyped and less-politically-correct approaches, coming in many cases
from private industry (often precisely because they were more innovative
and could not find a hospitable environment in academia or even large
corporate research labs) had to resort to the normal, commercial forms
of "marketing", thus allowing their better endowed competitors to drape
themselves in the mantle of Pure Science and accuse the former of crass
commercialism. This is a very effective tactic, and worked quite well in
the history of O-O: keeping innovators  away from the Establishment,
forcing them to go to the commercial sector, and then frowning on them
on the grounds of academic impurity. Quite smart.

All this being said, I must add that while I am not a great fan of C++ I
agree with Bjarne Stroustrup that marketing and hype alone, on any
scale, would not by themselves have been able to bring C++ to the level
of success that it reached. Clearly, it filled for many people a
pressing need at the right time. Although Dr. Stroustrup's second
paragraph as quoted above (the point about there being no marketing for
C++) does not hold water, the first part (omitted above):

	[U]nless C++ had at least some of the virtues I claim for it,
	it would have died during the early years

is absolutely correct. To take  the first analogy that comes to mind,
the Apple Newton is yet one more example that no company, however big,
can force on the public a technology that the public does not want.


-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: What is wrong with OO ?

[Chris Bitmead]

In article <32D53473.4DAA423A@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

>ISE Eiffel does give the user a degree of parameterization:
>a compilation option specifies the size threshold beyond which
>a routine will not be inlined. This is measured in internal units
>(number of bytecode words), but easy to relate to number of
>instructions. This option provides a way to control space-time
>tradeoffs. In practice, however, most users are happy with the
>default, which inlines small, frequently called routines.

How on earth does the compiler know if a routine is "frequently
called"?

Re: OO, C++, and something much better!

[Claus Reinke]

In <32E712B2.5060@parcplace.com> Eric Clayberg <clayberg@parcplace.com> writes:

>Graham Hughes wrote:

> > Having a type error propogate to the user is the height of immaturity.

> What about propogating a null pointer exception to the user? Is that
> somehow better? Propogating *any* error to the user could be considered
> the "height of immaturity". 

So the bottom line is: Find errors as early as possible (even avoid
them if you can, but never assume you have succeeded in this attempt)
and let the software help you wherever it can. Using dynamic typing
as the default and static type inference as an additional program
analysis should not harm anyone. Whether it is useful depends on the
type systems in use but there are certainly a lot of things you would
like to know about your SmallTalk programs that are hard to find out
by testing. With static type systems getting better, static typing
can be made the default, resorting to dynamic checks only for the
tasks where this is necessary (IMHO, completely static systems are
not reasonable because of the severe restrictions they impose on the
language).

>  Having worked extensively with several
> statically types languages (C, C++, Fortran, etc.) and now having worked
> commercially with Smalltalk over the last several years, I conclude that
> most "type" errors in statically types languages are due to the
> complicated nature of their syntaxes and the draconian rules of their
> type systems.

Sorry, but you should definitely *not* base your conclusions about
statically typed languages on C,C++,Fortran, etc. (is et-c another
C-variant?-). Try something like Standard ML or Haskell (there are
probably some non-functional alternatives, but I'm working in the
functional programming area). These languages make (what I think is)
a mistake as they exclude programs that cannot be handled by the
static type systems (instead of resorting to dynamic typing for
these), but the type systems themselves (and the languages) are
definitely worth looking at (these type systems are still not the
most powerful ones known, but most other systems haven't yet been
implemented in freely available general purpose languages).

> Smalltalk doesn't have those problems and doesn't lend
> itself to "type" errors of that nature. Almost all "message not
> understood" errors are messages directed to nil (the moral equivalent of
> a null pointer in C). 

What's a (null) pointer?-) In languages with implicit memory management,
there should be no need to (mis-)use pointers directly (well, change that
to: for the majority of programs). And in pure functional languages,
there are no (accesses to) uninitialized variables.

> > Incidentally, if you really care about spreading Smalltalk you might
> > want to attempt to get the FSF to fix their Smalltalk implementation.  I
> > can't fiddle around with Smalltalk anymore because that's the only
> > one I can get for Linux, and it doesn't work.

Somebody once posted a link to Smalltalk/X (the link is still active,
though quite old, and I haven't tried the system..) which lists Linux 1.1.*

http://www.informatik.uni-stuttgart.de/stx/stx.html

> Sorry. I never heard of FSF. If you want to try out a commercial grade
> Smalltalk IDE (which appears not to describe whatever "FSF" product you
> used), 

FSF (Free Software Foundation) is not dedicated to lower standards or 
prices, just to freedom of use (eliminating restrictions on copying,
redistribution, understanding, and modification of computer programs).

http://www.gnu.ai.mit.edu/fsf/fsf.html

Hope this helps,

-- 
Claus Reinke                                University of Kiel
email: cr@informatik.uni-kiel.de            Department of Computer Science
http://www.informatik.uni-kiel.de/~cr/      Preusserstr. 1-9,   24105 Kiel

Re: OO, C++, and something much better!

[Norman H. Cohen]

Don Harrison wrote:
>
> Matthew Heaney writes:
>
...
> :
> :And as far as your example "proving" that Ada is not type-safe: that is
> :incorrect.
>
> Correct, according to the Ada definition. As Norman Cohen put it,
>
> : It shows that Ada is not subtype-safe.
>
> That becomes "not type-safe" if you regard sub-types as distinct types.

I'm reminded of the following riddle, which I've seen attributed to
Abraham Lincoln:

   Q: If you call a dog's tail a leg, how many legs does a dog have?
   A: Four.  Calling the tail a leg does not make it one.

Calling a subtype a distinct type does not make it one.  Reread that
post of mine that you quoted.  Its main point is that, according to the
Ada definition, subtypes are NOT distinct types.  Distinct types are
disjoint sets of values distinguished at compile time.  Subtypes of a
type are (possibly overlapping) sets of values in the same type,
distinguished by whether or not they obey certain constraints that can,
in general, only be checked at run time.

--
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Bob Jarvis]

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article <5c4iel$3k5@mulga.cs.mu.OZ.AU>...
> Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> >David Hanley wrote:
> >> 
> >> Alan Lovejoy wrote:
> >> >
> >> > Smalltalk offers many times faster development times-
> >> 
> >>         Than what?  And what is your proof of this?
> >
> >Than COBOL, C, C++, Java.
> [...]
> >Independent studies that have been done.  See, for example, the following:
> >
> >	<http://www.spr.com/library/langtbl.htm>.
> 
> The quoted URL contains a table listing languages and their
> corresponding "language level".  Unfortunately the data in the table is
> certainly not reliable or reproducible, and indeed perhaps not even
> meaningful.  The explanatory text describes how some of the data was obtained:
> 
>  |    Research was done by reading descriptions and genealogies of languages
>  |    and making an educated guess as to their levels.
> 
> Our only consolation is that at least the author admits that
> "... the margin of error ... can be quite high.".
> 
> Some of the data is patently ridiculous, and indeed the whole idea that
> one can measure "language level" on a single scale and hope to get
> meaningful results is highly suspect.
> 
> By the way, if you believe that table, then you should quickly switch
> from Smalltalk to MATHCAD, since that will supposedly increase your
> productivity by a factor of four.

I really love this link.  It admits that its results are full of holes, errors, and
inaccuracies, then presents the data as if they actually have value anyways.
<snort!>  They even admit that they haven't actually looked at some (many?)
of the languages they're "evaluating".  To quote

	"Research was done by reading descriptions and genealogies of
	languages and making an educated guess as to their levels. KL,
	CLOS, TWAICE, and FASBOL are examples of languages that
	were assigned tentative levels merely from descriptions of the language,
	rather than from actual counts. 

	For spreadsheets the ordinary concepts of a language do not apply. In this
	case, formulas, labels, and constants were considered to be statements."

Still, it's useful - as long as what they present happens to agree with your
prejudices and foregone conclusions.  For example:

	1.  Prejudice: COBOL is *bad*!
	2.  Prejudice: C++ is *good*!
	3.  Datum: COBOL language level = 3
	4.  Datum: C++ language level = 6
	5.  Conclusion: C++ is twice as good as COBOL.  Q.E.D.

Or does this mean that C++ is only half as bad as COBOL?  Or...twice as bad??  :-)
Now, taking it one step further...

	1.  Prejudice: I like Smalltalk
	2.  Prejudice: I don't like LOTUS 123
	3.  Datum: Smalltalk language level = 15
	4.  Datum: Lotus macros language level = 3
	5.  Conclusion: I'm right, as always.

The problem here is that LOTUS 123 for DOS is listed as having a language level of 50!
So I guess this means that LOTUS 123 is more than 3 times "better" than Smalltalk,
and more than six times better than C++!?!  Conclusion: trash the objects, folks, and
just use spreadsheets for everything!

I think that one of the problems with this "research" is that it attempts to compare fettucini to
Ferrari's.  They have special-purpose languages lumped in with general purpose languages
and packages, ad nauseum.  It's like asking the question, "Which is better - Peachtree
Accounting or C++?"  Context is important when answering such a question.  If you're trying
to do the books for a small company I'd tend to pick the accounting package.  On the other
hand, if you're trying to simulate the manufacturing processes at that same company I'd
think that C++ would be a better tool (although less than half as good/twice as bad as
Smalltalk :-).

However, as I said before, if the data shown can prove the point you want proved, it's a
great way to provide yourself with some much-needed smoke and mirrors.  And remember:

	There are lies, damn lies, and statistics.

Q.E.D.  :-)

-- 
Bob Jarvis
Mail addresses hacked to foil automailers!
Send replies to jarvisb@timken.com

Re: OO, C++, and something much better!

[Norman H. Cohen]

Eric Clayberg wrote:
> 
> Norman H. Cohen wrote:
...

> > ... Once
> > a program has been keyed in, strong typing results in a flurry of
> > compile-time errors that must be addressed before the program will run.
> > Of course dynamic typing does not make these errors go away, it just
> > hides them so that you have to find them yourself instead of having them
> > pinpointed for you by a compile-time error message.
> 
> Not true. In a language like Smalltalk, those "errors" as you call them
> are not hidden; they never existed to begin with. Having worked
> extensively with several statically types languages (C, C++, Fortran,
> etc.) and now having worked commercially with Smalltalk over the last
> several years, I conclude that most "type" errors in statically types
> languages are due to the complicated nature of their syntaxes and the
> draconian rules of their type systems. Smalltalk doesn't have those
> problems and doesn't lend itself to "type" errors of that nature. Almost
> all "message not understood" errors are messages directed to nil (the
> moral equivalent of a null pointer in C).

You seem to be confusing type errors with all other kinds of
compile-time errors.  A type error is specifically an error in a
syntactically WELL-FORMED construct that arises because the programmer
has declared his intent to use a certain object in one way, but has been
caught using it in a way inconsistent with this declared intent.

For example, suppose a program has an array of "producer companies" that
manufacture a particular product and an array of "consumer companies"
that buy that product.  Suppose the program manipulates both integers
meant to index into the first array and integers meant to index into the
second array.  Mistakenly using a variable holding an integer of the
first kind to index into the second array could produce subtle errors
that might be hard to track down, or might just silently produce
incorrect answers.  In a strongly typed language such as Ada, one could
write

   type Producer_Number is range 1 .. Max_Producer_Count; 
   type Consumer_Number is range 1 .. Max_Consumer_Count;
   Producers : array (Producer_Number) of Company;
   Consumers : array (Consumer_Number) of Company;

Producer_Number and Consumer_Number are distinct integer types whose
uses cannot be intermixed without an explicit type conversion.  (This is
a degree of type protection unavailable in C or C++).  Certain variables
can be declared to be of type Producer and others of type Consumer.  An
attempt to use a variable of type Producer_Number to index into the
array Consumers will produce a compile-time type error.

As you said, "Smalltalk does not lend itself to 'type' errors of that
nature."  Smalltalk programmers are no less likely than other
programmers to use an integer variable to index into the wrong array,
but since Smalltalk does not have the means to express such distinctions
as type distinctions, I would imagine that most Smalltalk programmers
would think of this as a "general logic error" rather than as the kind
of problem that would be caught by compile-time type checks.  (When you
don't have a hammer, none of your problems look like nails.)

> It's funny that you should mention securities industry. Quite a few Wall
> Street investment banks use Smalltalk for their securities trading
> systems.

I mentioned the securities industry specifically because Alan Lovejoy
had brought up the use of Smalltalk in that industry.  This industry has
perceived that Smalltalk speeds deployment of software, but I suspect
that few realize that this is accomplished by deferring the detection of
some errors until after deployment!  The appropriate comparison here is
not to C++ (an error-prone language whose supposedly strong typing
system is too weak to catch many of the errors that language fosters),
but to a safety-oriented language such as Ada.  Given the potential
financial impact of an incorrect program, people in this industry ought
to demand the same protection against programming errors that purchasers
of safety-critical software demand.

Then again, I suppose they wouldn't be in the securities industry if
they didn't enjoy high-stakes gambles. :-)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Robert I. Eachus]

In article <E4DvAz.G06@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

  > That's one view. Another view is to consider such 'subtypes' as
  > types in their own right. This is more honest, IMO. Using this
  > definition, neither Ada nor Eiffel is 'type-safe'.

   I'm not trying to start a flame war here but the distinctions
between types and subtypes in Ada are subtle, and semantic games like
this don't help.

   If you call a tail a leg, how many legs does a dog have?

   When it comes to computer language definitions, only the reference
manual can do redefinitions like that for technical terms.  In Ada,
subtype is a technical term, and is clearly very different from a
type: A type declaration creates an (anonymous) type, and a (named and
possibly constrained) first subtype.  A subtype declaration creates
only a name for a subtype of some already defined type.  In fact all
of the differences between:

   type Foo is new Integer range 1..10;
 
      and 

   subtype Foo is Integer range 1..10;

      are because the first declaration actually creates a type and
several operations on that type, and the second declaration creates a
shorthand for a subtype mark and possibly a constraint.  As a language
lawyer, I feel compelled to point out that a subtype declaration in
Ada can define attributes--but so can object declarations.  In the
example above, Foo'First is 1, not Integer'First.  In any case
attributes which are functions are operations of the (anonyomus) type,
not of the subtype, so a type and all its subtypes always share the
same operations:

    subtype Foo is Integer range 1..10;
    Bar: Integer := 1234;
    Bar_Image: String := Foo'Image(Bar);
   
    gives Bar_Image the value " 1234".  Yes, the subtype declaration
did declare a function Foo'Image, but its parameter is of subtype
Foo'Base.  The terminology is tricky here, Foo'Base is not a subtype
of Foo or of Integer, it is a subtype of the anonymous type created by
the declaration of Integer in Standard.  Normal (but fuzzy) usage is
to say that the type of the parameter to Foo'Image is Integer, not Foo.

    There are places in Ada where a subtype_mark is permitted but not
a subtype_indication, which is a subtype_mark with an explicit
constraint.  However, this is for stylistic reasons and to simplify
the order of elaboration.  In fact the big difference between Ada
subtypes and C macros used as type names is that in Ada the
expressions are evaluated at the point of the subtype declaration.

     In Ada it is not unusual to see subtype declarations like:

     subtype Short is Really_Long_Package_Name.Short;

     used solely as a renaming.  To quote RM95 8.5(6 & 7): "A subtype
defined without any additional constraint can be used to achieve the
effect of renaming another subtype (including a task or protected
subtype) as in

      "subtype Mode is Ada.Text_IO.File_Mode;"

--

					Robert I. Eachus

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

Re: OO, C++, and something much better!

[David Hanley]

Robb Nebbe wrote:
> 
> However, dynamic typing is mostly a stop-gap measure since static type
> systems aren't quite up to snuff yet. I expect static type systems to
> steadily improve until there is no longer any reasonable justification
> for
> dynamic typing but we aren't there yet in my opinion.

	This is pretty much what I think of dynamic typing as well; I just feel
that, for me, static typing has crossed over the point where it obviates
dynamic type checking.

	Have you every used SML?  It is fully statically typed, and it's type
system is very elegant, in my opinion.  

-- 
------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[James O'Connor]

Norman H. Cohen wrote:
> 
> Alan Lovejoy wrote:
> 
> > However, dynamic typing results in signficantly faster development time.
> > So as long as the number of typing errors that occur in practice are low
> > enough, dynamic typing is still a net win.  In my experience, the frequency
> > of occurrence of such errors is about 2% of all errors--which is much lower
> > than the break-even point.
> 
> This strikes me as "seat of the pants" guess rather than a solid
> empirical result.  I'll give you the benefit of the doubt and assume
> that your "2% of all errors" figure is based on methodical tracking of
> the projects on which you have worked.  However, before you start to
> speculate about break-even points, you need some numbers about the
> degree to which dynamic typing supposedly speeds up development time,
> and you need some numbers about the amount of time wasted chasing these
> type errors in a debugging session rather than in response to a
> compile-time error message.
> 
> Now the 2% figure may in fact be colored by the fact that you are using
> a weakly typed language.  Users of strongly typed languages take
> advantage of compile-time type checking to encode all sorts of
> distinctions as type distinctions, so that a compiler's certification of
> type consistency greatly increases confidence in a program's overall
> logical consistency.

Not really, it just means the program follows the language rules.  When
I was working in Ada(83) I found that most of the type errors that the
compiler caught were actually not logic errors but syntax errors. 
Usually I would be trying do something that logically I should have been
able to do and that my program required, but because of the typing
rules, I got a compile error.  In other words, the compiler complained
that I had type errors that were created, not by my bad programming
logic, but because I didn't follwo the rules enforced by the compiler. 
All it said was that I had violated the language rules, it didn't say
one whit about whether my program was logically correct. X + (Y* 3) Even
if X and Y and 3 are all the right type, that doesn't do me any good if
the 3 was supposed to be 2.

> Having worked with both dynmically and statically typed languages, my
> (unquantified) experience is that dynamic typing speeds up program
> development about as much as touch typing.  :-)  That is,  it reduces
> data entry time because you don't have to type all those declarations.

Then you are not properly using dynamic typing :)

	Seriously, I find myself able to build structures in Smalltalk that I
would not be able to build in statically typed langauges, at least not
very easily. Especially anytime I need an object from one class to be
able to transparently substitue for an object from another class.  (Go
to the Design Patterns book and look at the difference between the C++
implementation of a Proxy and the Smalltalk implementation).  I use
Proxies to act as placeholders for objects of classes that I do not even
know until after the Proxy has first been referenced.  I also build a
lot of objects that (for other reasons) are in one hierachy chain but
also have to act like Collections (or Streams, or whetver).  By
providing the methods needed to support the proper collection protocol,
I can use my object in any message send to anybody that expects a
Collection.  You could do this with MI, but I also build objects that
can act in place of many different objects that change at runtime.  I
have an Actor-Role structure where an Actor knows how to delagate
messages to it's various roles, which change at runtime. An actor with a
given role at runtime can be used in any situation that expects that
role.  An actor with many roles can be used in place of any of those
roles. I also am involved in working with Distributed Smalltalk where I
use Shadows to send messages over a wire to objects of classes that are
not even in my environment. (And it only takes one simple Shadow class
to represent any foreign object of any class).

	All of these techniques are very powerful and useful to me.  While you
may be able to emulate them in other languages, the lack of compile-time
typing makes the Smalltalk solutions very easy.  It would take a lot
more than just typing those declarations to do it in a static language
(partially because those declarationbs are not known until runtime).

	And that's (part of) the speed increase in development Alan was talking
about, the ability to build powerful and dynamic frameworks (and use
those frameworks in diverse areanas) that dynamic typing allows that
static typing would make much more difficult to build.

> Of course this is a minuscule fraction of program development time. Once
> a program has been keyed in, strong typing results in a flurry of
> compile-time errors that must be addressed before the program will run.

That may or may not have been real errors.  Are they errors in your
logic or errors in your obediance to the rules?

> Of course dynamic typing does not make these errors go away, it just
> hides them so that you have to find them yourself instead of having them
> pinpointed for you by a compile-time error message.

Dynamic typing makes these errors go away if they were not errors to
begin with :)
I never (strong word...almost never) get errors for accidentally sending
a Rectangle instead of an Integer.  I usually get typing errors for one
of two reasons. Either I'm sending a message to nil (this means that
either I didn't initialize something properly or I was too lasy to heck
the return value from a method). Or a method returns either a good
object or an error object and I'm only up to writing the code for the
good object and haven't put in the check for the error object.  (Like an
Ada program may blow up if you're still testing and haven't written al
the exception handlers yet).  Bottom line is that the (bery few)
'typing-errors' I get in Smalltalk are not really typing errors at all
but are symptomatic of bad program logic in the first place (and,
because of that they usually blow up *very* fast) and are of a nature
that even in a typed language, the programl logic errors would still be
there.


> In my experience, a line containing a stupid mistake that would have
> been caught by decent compile-time checks can easily take 50 times as
> long to develop (counting the time to debug a line as part of that
> line's development time) as a line without such an error.  In that case,
> even if we accept the 2% figure, static typing is still a win.
> 
> Development time is of interest, of course, not in its own right, but
> because of its impact on project value and cost to the customer.  The
> cost of a less timely deployment of a program must be weighed against
> the cost of an error that arises for the first time in the field,
> because the programming language did not allow the error to be caught at
> compile time and the run-time testing was incomplete.  If you are lucky,
> the software merely fails, and the customer reverts to contingency
> procedures while programmers working overtime rush a patch out to the
> customer.  If you are unlucky, the program appears to work correctly,
> but provides an incorrect result that causes your customer to lose tens
> of millions of dollars on an absurd securities trade.
>

	Sure, but that assumes that a stronly-typed language will ship with
less 'logic' errors than a typed one.  A typed language only guarentees
that all the variables (objects) are of the specified type, it doesn't
mean the program meets the requirements.  I actually had an Ada83
program that blew up at runtime precisely because it was strong-typed. 
The designer had put an upper limit on a type, based on real-world
conditions.  That upper limit didn't really mean anything, we didn't
care about what it was.  It just happaned to be a high enough value that
the designer thought would be sufficient.  The designer was wrong, the
real world changed, conditions were different, and the system crashed
because a totally meaningless limit was placed on a value in obediance
to the typing system.  If that had been in Smalltalk, the value would
have rolled over from Integer to LargeInteger and gone right along
without caring (because we didn't care either, and neither did the
use...until it crashed).
	That was when I stopped trusting the typing system. 

> 
> --
> Norman H. Cohen
> mailto:ncohen@watson.ibm.com
> http://www.research.ibm.com/people/n/ncohen

-- 
James O'Connor 

--------------------------------------
joconnor@jmpstart.com
http://www.jmpstart.com
--------------------------------------

Re: OO, C++, and something much better!

[Joachim Durchholz]

Eric wrote:

> What about if your program crashed because you tried to address a null
> pointer? Does this mean you shouldn't use C or C++?

Yes :)
At least on the same basis - I prefer a working Smalltalk or C/C++
environment to a perfect (but hypothetical) one any day.

> Almost all "message
> not understood" errors are simply messages sent to nil (the moral
> equivalent of a null pointer). This usually happens either when
> something isn't initialized yet or it has been prematurely released -
> certainly mot uncommon occurrences in the static typing world.

This is the reason why I favor garbage collected systems over GC-free
systems. This doesn't prevent uninitialized access, but it does take care
of dangling references.

> Real type
> errors (e.g., those that a static typing system would actually catch)
> rarely ever occur in Smalltalk. The simplicity and consistency of the
> language drastically reduces the scenarios where a real type error would
> occur.

Hm, that's an interesting claim.
Though of course your programs might have typing holes that you never got
aware of, so I'm not sure about the soliditiy of the "rarely ever" bit in
your statement.

> But rather that guess about Smalltalk, why not give a try and see for
> yourself? You can download Smalltalk Express (a fully functional 16-bit
> Windows Smalltalk IDE) for free from http://www.objectshare.com.

Well, dynamic typing isn't the only problem about Smalltalk. There's some
efficiency problems, and it's difficult to strip a program to its
essential components for distribution. (Note that dynamic typing makes
both problems hard to solve.)

Regards,
-Joachim

--
Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

Re: OO, C++, and something much better!

[Matt Kennel]

Eric Clayberg (clayberg@parcplace.com) wrote:
: Fergus Henderson wrote:
: > Alan Lovejoy <alovejoy@concentric.net> writes:
: > >When typing errors only constitute 2% or less of all errors, it's time
: > >to check the cost of eliminating the final 2% of the problem.
: > My experience is that errors caught by type checking constitute a LOT
: > more than 2% of errors.
: > For a period of time I carefully recorded the cause of every error that
: > I found while writing a Mercury program.  Of the 155 errors that I
: > recorded, 73 were error caught by the type checker.

: If anything, I think that reflects poorly on the syntax of whatever
: language you were using. The more "rules" a language has, the more
: involved its syntax, and the more draconian its type system, then the
: more type errors are likely to be created by the developer and then
: caught by the compiler. In a language like Smalltalk which has an
: absurdly simple, consistent syntax, and which has a very open-mined
: concept of "type", very few type errors are ever created to begin with
: and thus very few actually exist to be found.

Yes this indeed is the point.  With such a language most errors turn into
some form of "illegal data", a.k.a. "why is this in here?" 

The language is more homogeneous and the errors are likewise so. 

That such a thing is completely good is not at all _prima facie_ true. 

: The Smalltalk language
: is very simple and very flexible and makes a lot of things perfectly
: legal that would not be allowed in, say, C++. Most "message not
: understood" errors, in fact, are to the nil object in Smalltalk (the
: moral equivalent of a null pointer in C). These are not really type
: errors, but usually problems with improper initializations or premature
: discarding of data. These are logic problems; not type problems.

: A
: static type checker would catch them no better in Smalltalk than it
: would in C++.

This is where I disagree---a really good static language can express
interesting logical structure in the type system, and mechanically prevent
a number of "logic" errors as in other systems because they had checkable
type consequences. 

Now, I don't personally think C++ is a "really good static langauge", 
suffering from a number of faults and deficiencies against Smalltalk. 

A static type langauge need not be manifestly typed everywhere (programmer
putting specific written type annotations on all variables); a small
dose of type inference substantially increases the "prototypability" and
elides lots of stupid 'search-n-replace' busywork found in dumber static
languages. 

: I am amazed at the level of hubris evidence in this discussion. Folks
: are jumping in and making assumptions about how Smalltalk works based
: upon how their favorite statically typed language works. Smalltalk has
: very different rules than what are common in most statically typed
: languages. Smalltalk simply doesn't need static type checking. 

That ST is clean and coherent without it is not under debate.

: -Eric

cheers
Matt

Re: OO, C++, and something much better!

[Tansel Ersavas]

Don Harrison wrote:
...
> Presumably LargeInts are integers implemented as two words rather than one?
> Sounds reasonable.

LargeInts have infinite precision, they grow when they need to keep more
digits

> :The guys who write
> :Smalltalk environments aren't idiots.
> 
> No doubt you're right. There are few genuine idiots. :)

If you say so...

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: OO, C++, and something much better!

[Mark Woodruff]

Graham Hughes wrote:
> You mean the percentage of actual type related errors that you have
> actually _caught_, no?  There is a substantial difference.

Having used both Smalltalk and Rexx, both of which are largely untyped languages,  
I see the difference between typed languages and untyped largely in pragmatic 
terms: typed languages work better when the product must be correct.

Most programs can tolerate errors. Having an error message that complaining about 
an unhandled message isn't much different from throwing an exception or returning 
an error code. It's only in critical software that the difference becomes 
significant.
-- 
My views may reflect the presence of the company I'm in
but don't reflect my company's views nor my clients.

Re: OO, C++, and something much better!

[Travis Griggs]

Don Harrison wrote:
> : ...and many financial programs
> :> :failed, because the numbers involved were so large that they overflowed
> :> :various limits, but the Smalltalk programs kept running, because
> :> :Smalltalk quietly switches to using floating point arithmetic when
> :> :integer arithmetic overflows.
> :>
> :> That's a worry.
> :
> :That's not a worry--that's just wrong.  Smalltalk quietly switches
> :to a LargeInt object when integers overflow.
> 
> Presumably LargeInts are integers implemented as two words rather than one?
> Sounds reasonable.

Actually, guess again. LargeIntegers are implemented as *variable*
bytes. So they grow as you need them to. This is really cool when
combined with the Fraction class. Ever hear of infinte precision
rational numbers! I used this and a taylor series once to generate Pi
past a 1000 decimals. Kinda useless, but totally cool how easy it was.
:)

-- 
Travis or Kerrin Griggs
Key Technology   (509) 529-2161
tkc@bmi.net         (509) 527-8743

Re: OO, C++, and something much better!

[Don Harrison]

John Kuszewski writes:

: ...and many financial programs
:> :failed, because the numbers involved were so large that they overflowed
:> :various limits, but the Smalltalk programs kept running, because
:> :Smalltalk quietly switches to using floating point arithmetic when
:> :integer arithmetic overflows.
:> 
:> That's a worry.
:
:That's not a worry--that's just wrong.  Smalltalk quietly switches
:to a LargeInt object when integers overflow.  

Presumably LargeInts are integers implemented as two words rather than one?
Sounds reasonable.

:The guys who write 
:Smalltalk environments aren't idiots.

No doubt you're right. There are few genuine idiots. :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Don Harrison]

Eric Clayberg writes:

:Actually, Smalltalk transparently switches to using "large" integers
:that have no limits on size. In fact, it's actually fun to run large
:factorials in Smalltalk to see how large an integer it will generate.
:VisualSmalltalk will calculate the result of "1000 factorial" in a
:second or two and display the results. BTW, the result of that
:expression is: :-)

[some gi-normous number]

That's impressive. Might hang onto it in case it comes in handy one day. :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Robb Nebbe]

Eric Clayberg wrote:

> 
> ... The more "rules" a language has, the more
> involved its syntax, and the more draconian its type system, then the
> more type errors are likely to be created by the developer and then
> caught by the compiler.

This shows a fundamental misunderstanding about what a type system is
and what it does. Typing is a property of how you set up your model, not
of which language you use to code it.

A type system does have some influence on how a model can be expressed
but a good object-oriented type system places few constraints on how you
set up the model. Currently there are some advantages to some kind of
dynamic scheme but I would expect these advantages to disappear as
static type systems improve.

> In a language like Smalltalk which has an
> absurdly simple, consistent syntax, and which has a very open-mined
> concept of "type", very few type errors are ever created to begin with
> and thus very few actually exist to be found. The *few* real type errors
> that are created tend to be caught almost immediately by Smalltalk's
> superb debugging facilities.

Speaking of hubris ... you can argue that people tend to code
differently
in Smalltalk thus avoiding the possibility of type errors is a few cases
but just asserting that their is something magical about Smalltalk is
silly.
Obviously the lack of static typing in Smalltalk does not make it
unsuitable
for software development, a fact that some people (probably those who
have
never programmed in Smalltalk) seem to have trouble grasping.

However, dynamic typing is mostly a stop-gap measure since static type
systems aren't quite up to snuff yet. I expect static type systems to
steadily improve until there is no longer any reasonable justification
for
dynamic typing but we aren't there yet in my opinion.

Robb Nebbe

Re: OO, C++, and something much better!

[Eric Clayberg]

Graham Hughes wrote:
> Bullshit.

Right back at ya.

> Having a type error propogate to the user is the height of immaturity.

What about propogating a null pointer exception to the user? Is that
somehow better? Propogating *any* error to the user could be considered
the "height of immaturity". I have been involved in dozens of commercial
Smalltalk development efforts ranging from shrink-wrapped apps to large
mission critical MIS apps. Type errors propogated to the user of
Smalltalk apps are a *very* rare occurrence indeed. If you have some
evidence to the contrary, then present it.

> You mean the percentage of actual type related errors that you have
> actually _caught_, no?  There is a substantial difference.

No. I mean the percentage of actual type errors that are actually
introduced to begin with. Having worked extensively with several
statically types languages (C, C++, Fortran, etc.) and now having worked
commercially with Smalltalk over the last several years, I conclude that
most "type" errors in statically types languages are due to the
complicated nature of their syntaxes and the draconian rules of their
type systems. Smalltalk doesn't have those problems and doesn't lend
itself to "type" errors of that nature. Almost all "message not
understood" errors are messages directed to nil (the moral equivalent of
a null pointer in C). 

> I _have_ used Smalltalk.

Which version? How long ago? Have you used it commercially? Have you
ever propogated a type error to the user of a system you developed in
Smalltalk? 

> Incidentally, if you really care about spreading Smalltalk you might
> want to attempt to get the FSF to fix their Smalltalk implementation.  I
> can't fiddle around with Smalltalk anymore because that's the only
> one I can get for Linux, and it doesn't work.

Sorry. I never heard of FSF. If you want to try out a commercial grade
Smalltalk IDE (which appears not to describe whatever "FSF" product you
used), there are at least half a dozen available. I'm not aware of *any*
that support Linux. If you have access to Windows, then you should take
a look at Smalltalk Express. It's available free from
http://www.objectshare.com. While only 16-bit, it is a fully functional
commercial Smalltalk IDE.

-Eric

language marketing question, was Re: What is wrong with OO ?

[Tom Moran]

> But anyone seeing the real situation in the
> software world at large could not fail to notice the gigantic amount of
> both "hype" (his term in the first paragraph) and "marketing" (his term
> in the second) behind C++. 
  Does anyone know of a marketing case study of the initial growth of C
and Unix?  Both the words and the money behind them?

Re: OO, C++, and something much better!

[Fergus Henderson]

Eric Clayberg <clayberg@parcplace.com> writes:

>Fergus Henderson wrote:
>> My experience is that errors caught by type checking constitute a LOT
>> more than 2% of errors.
>> For a period of time I carefully recorded the cause of every error that
>> I found while writing a Mercury program.  Of the 155 errors that I
>> recorded, 73 were error caught by the type checker.

While reexamining my list, I noticed that I had accidentally
misclassified one class of errors containing 3 errors, so the number 73
above should have been 70.  Sorry about that.

>If anything, I think that reflects poorly on the syntax of whatever
>language you were using.

Some (14) of those 70 errors were related to the syntax, but most of
them were errors such as "wrong number of arguments", "wrong procedure
name", and so forth, that could occur in just about any language.  Note
that the number 70 does *not* include errors in the type declarations
themselves; there were an additional 13 of those.

Here's a more detailed breakdown. 

	syntax errors: 16
	type errors: 83
		- errors in type declarations: 13
		- type errors other than errors in type declarations: 70
			- syntax related: 14
			- wrong procedure name: 11
			- wrong constant name: 4
			- wrong variable name: 4
			- wrong number of arguments: 21
			- incorrect argument order: 5
			- argument has wrong type: 7
	other errors detected at compile time: 47
		- missing `import_module' declarations: 7
		- errors in mode declarations: 13
		- others: 27
	errors not detected until run time: 9

The "syntax related" errors all relate to a particular aspect of
Mercury syntax: calling and defining procedures that have implicit side
effects uses a different syntax than is used for procedures which do
not have any implicit side effects.  This is clearly an error-prone
aspect of the syntax, but it enhances readability.

Of the "syntax errors", 10 were caused by missing or additional commas;
this class would probably not occur if Mercury syntax used say `;' as
a statement terminator rather than `,' as a statement separator.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Fergus Henderson]

John Kuszewski <johnk@spork.niddk.nih.gov> writes:

>Don Harrison wrote:
>> 
>> Fergus Henderson writes:
>> 
>> :I don't know how it got its start there, but I have heard that it got a
>> :bit of a boost after the stockmarket crash in '87.  Apparently the
>> :volume of shares traded was very high, and many financial programs
>> :failed, because the numbers involved were so large that they overflowed
>> :various limits, but the Smalltalk programs kept running, because
>> :Smalltalk quietly switches to using floating point arithmetic when
>> :integer arithmetic overflows.
>> 
>> That's a worry.
>
>That's not a worry--that's just wrong.  Smalltalk quietly switches
>to a LargeInt object when integers overflow.

My apologies for spreading misinformation.

I do wish to point out, however, that in the quotes above someone
edited out the rather important part where I said that the quoted story
was all rumour and that I wasn't sure how much of it was true.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Tansel Ersavas]

Joachim Durchholz wrote:
> 
> Alan wrote:
> 
> > But replace "PL/I" with "any statically-typed language," and then you can
> > see the truth: "because any statically-typed language sucks, is why."
> 
> Come on, have you ever programmed in a statically-typed language?
> Seriously?
> What you say sounds just like a Basic programmer whom I tried to convince
> he should try (just TRY!) Pascal. He said he had seen it at the
> University, and Pascal sucked...

I used Pascal, C and C++ for more than 10 years, and developed and led
development of >500000 loc projects, and I am sorry to say that I still
think they suck. I now use Smalltalk and Self and sometimes Java if I
have to, and couldn't be happier.

About types, this segment is an appendix to a recent posting I made to
these groups.

"The exaggerated importance of type checking in OO

There is a big debate about importance of type checking in object
oriented systems. We have one camp religiously defending type checking,
and another group defending unnecessity of it. There is a merit in both
sides� arguments. This has more to do with the implementation specific
problems than a general theoretical point of view. If we ask people who
are familiar with languages based on ADTs, type checking is so
necessary,
the absence of it is total catastrophe. If we ask a Smalltalker or a
Selfer, they will tell we that type checking is not all that important. 

The problem is two edged. The more type information we put into the
objects, the more we make them dependent of these types. Any changes on
these types will have to be detected, and these parts of the programs
need to be updated, even though in compiled systems a recompilation will
suffice in many cases. The reason of inflexibility of ADT based
languages such as C++ are partly due to their reliance on type checking.
On the other hand, in the languages that we get sinful flexibility, we
actually almost never know that we may have a problem that may lie in an
untested corner, and may lurk at an unexpected moment. 

Contrary to what people say, type checking is against the nature of
object oriented systems development. Remember, in OO, we only care about
the interface of the other object. In fact it should be an OO sin to ask
the type, because, in theory, we don�t want to get intimate with objects
we are interacting apart from their interface. We only want to know the
interface. But we do check types anyway, because we do not have another
way in many of the current popular languages to guarantee that this
object has the interface that we require. Type checking is necessary in
ATD based languages because of language structure. In languages such as
Smalltalk, on the other hand, even knowing the type of an object is not
a guarantee that this object will answer a method that we use, because
we can really delete any method for that object while the system is in
operation, so even type checking is not a perfect solution. 

Then what is the solution? Common Object Requester Broker Architecture
(CORBA) makes this possible by allowing us to define only the interface
of objects. However, this approach is not much of a use of objects
within the same language. Some other languages have the notion of a
subtype, which is dependent on the interface. In the
languages which do not offer such mechanisms, one obvious solution that
comes to mind is to offer an interface signature, that will indicate
that an object really offers all the services that it is required. This
will guarantee that type of the object can change any time as long as
the public interface signature of the object does not change. Then any
object binding to this object can ask its signature rather than type to
verify that
the interface is the same as this object was created. This has run time
costs associated with it, but solves many problems that are associated
with type checking. Furthermore it is not practical for many ADT based
languages.  

In most ADT based languages type checking is done at the compile time.
This approach gives us a lot of safety, but also has an expensive price
tag in terms of flexibility and compromise of object oriented approach.
There can not be much done to increase flexibility of such languages.
One of my solutions for flexible systems such as Smalltalk is, to use
high level tools to automatically embed type or interface checking code
in development and testing phase, and after all tests are done, to
remove these checks automatically, allowing systems to run without type
checking once they are in production. This gives me best of the both
worlds."
 
> > (Actually, statically-typed langauges have a useful niche, but that niche
> > does not encompass all of programming).
> Which?
> 
> I could state that Smalltalk has a useful niche (that doesn't encompass
> all of programming), but I don't want throw mud back.
> 

... 

> I have heard several indicators that Smalltalk is very good at getting
> stuff done, in the quickest possible time. I'm willing to believe this
> (sounds reasonable anyway), but nobody talks about the disadvantages in
> the approach. Those who know Smalltalk program in it, so they won't tell
> me - and I can't believe there are none.
> I don't want to be converted to Smalltalk. I want to know about advantages
> and disadvantages, so that I can decide which language is better for a
> given task.

As a person who is developing with Smalltalk extensively I see so many
advantages, it is like working in another dimension. Development and
debugging (which I don't need to do much of debugging) becomes a joy,
rather than a burden. 

Disadvantages? Many. First, it was not easy to come to this point. I had
to spend about a year, and if I wasn't assigned to a project I wouldn't
have done it, because I didn't see a need to switch from C++ I was
enjoying. 
For starters, most Smalltalks and their tools are ridiculously
expensive. This is equivalent for the vendors to shooting themselves in
the foot, at the same time hitting us with the richocet. 
Second, it requires changes in the overall approach. For the first year,
my methods looked rather like C++ ones. Only after than I was able to
slowly embrace the entire notion and apply it. I am still sometimes
amazed with certain things I can do which I call "sickeningly simple"
solutions.   
Third, the darn class library. It takes a lot of time to digest it.
Fourth, people say absence of MI is not a problem, but it is not true.
Just look at the Streams class hierarchy and implemetation, soreness of
absence of MI is clear. 
Fifth: as I mentioned in the type checking discussion, dynamic typing
has so many advantages, but also disadvantages. 
Sixth: Lack of standardized class libraries between implementations,
especially in the GUI part. Luckily now there are graphical frameworks
such as GF/ST which give good portability between Smalltalks
Seventh: The difficulty of felivering an application (stripping,
packaging, etc), which now we have good but absurdly expensive 
Eighth: Performance. Actually this is a non-issue. I never suffered from
performance apart from screen drawing, or number crunching. In some
complex applications I was able to beat C++ applications.

You can browse some issues with Smalltalk at
http://www.rase.com/oodebate/choices.htm. 

So how do I live with these? I don't. In Smalltalk you have the power to
correct things. The open system architecture allows you to do that. For
instance, adding a simple MI by delegation took me two hours to
implement. I use it sparingly, and more on the modeling side, but I have
it when I need it. I have developed a tool with it which we will release
shortly to fix most of Smalltalk's problems. The best thing in Smalltalk
is you don't have to live with problems. You have the power to fix them.
Except speed. For number crunching I use C. Apart from that I find
Smalltalk more than adequate.
 
> > Why would Chrysler hire Kent Beck to oversee the rewriting of their payroll
> > system in Smalltalk?  They could have chosen C++, Eiffel, Java or Ada95, or
> > just stayed with COBOL. Why didn't they?  Why choose Smalltalk, when there
> > are so much fewer programmers than would be available for C++?  Why choose
> > Smalltalk, when there is such a wide-spread bias against dynamic typing?
> 
> Maybe because they are manager? Not all decisions, even in large
> companies, are based on rational arguments. There is trust in consultants
> involved, who aren't always impartial. There is also much internal
> backstabbing involved - sometimes managers influence other managers into
> bad decisions, to weaken their internal position.
>
> Not that I'm convinced this is the case with the companies that you listed
> as examples. It's just that such success stories don't prove a thing. It
> would be much more interesting to hear about the consequences of these
> decisions, not about the decisions themselves.

Why don't you come to Smalltalk Solutions 97? You may see many examples.
It is in NY at Marriot Marquis between March 10-13. 

> > Why has the use of Smalltalk been growing at 60% per year?  In spite of the
> > absence of any Java-style marketing campain?
> 
> Maybe because two companies happened to decide for Smalltalk, which makes
> a huge difference if the installed base is small.
> I'm sure any proponent for any other language can make up similarly
> impressing figures.
> That 60% figure is worthless - you don't say wether it's number of
> companies, number of developer seats, number of productive systems, or
> lines of code. You don't even say since when this growth started - it
> might be 1 1/2 year as well as twenty years.

This is not true. Smalltalk base is growing very strongly especially in
organizations such as banks. Most organizations come to a point where
maintaining the existing system becomes such a burden, they have to
change to a new system. What language will they choose for the new
system? Cobol? In some cases yes. Now there are quite different looking
languages, so called "Object oriented Cobol" in workstations. However
these are the minority. I read somewhere that 15% of banks chose
Smalltalk as their new language, which worries me, because there are not
that many Smalltalkers to develop and support these systems. I think the
problem with Smalltalk is not that there are too little of it, on the
contrary, with this speed, we don't have good people to support these
systems. So much so, I get requests to set up the "Smalltalk School of
NY", which I am considering.

> > Smalltalk offers many times faster development times--and much greater
> > robustness in the face of changing requirements.  That's a strategic
> > advantage, especially in businesses and industries (like securities trading)
> > where time is not just money, but big, big money.
> 
> I already knew this. I consider this an interesting property of Smalltalk,
> but I'm not convinced Smalltalk is best for everything. And as far as I
> know, Smalltalk can't be integrated into a multi-language environment (at
> least not with a considerable amount of work, or with serious efficiency
> problems), so I'm somewhat hesitant to recommend Smalltalk at all.

No, there are Smalltalks and class libraries with extensive multi
language support. I am internally using a tool that finds any string in
the application, sorts, finds duplicates, and prompts for each of them
to modify, without changing or recompiling code, the simplicity of that
can literally make many people "sick". These things are so trivial in
Smalltalk. 

> Regards,
> -Joachim
> 
> --
> Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

Kindest Regards
Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: OO, C++, and something much better!

[Eric Clayberg]

Don Harrison wrote:
> Gee, Eric. It seems like you versus the whole static typing community. :(

Hey, it looks like a couple of other Smalltalk developers are jumping
into the fray as well. :-)

> I don't want to argue about whether or not exceptions should be propagated
> (as others are doing a good enough job of that). I just want to encourage
> you not to use C++ as the basis for your comparison with Smalltalk.
> 
> Some of your comments seem to assume that C++ is the sterotypical statically-
> typed language. It isn't - it's merely the most popular. :(  You would be
> better off comparing Smalltalk with a statically-typed langauge with a
> coherent type system such as Eiffel, Ada or Sather.

You make a good point. I compare it to C++ as that is the language I
have the most experience in. I know a bit about Eiffel (haven't used it,
but am very impressed with what I've read about it), and very little
about the other two (the last DOD project I did was in FORTRAN and I
haven't run across other occassions where Ada was required). 

> Some of your antagonists come from those backgrounds and they would agree with
> you that C++ is the pits. :)

I'm glad we can agree on something at least! ;-)

-Eric

Re: OO, C++, and something much better!

[traymond]

In <32E788D4.4B91@watson.ibm.com>, "Norman H. Cohen" <ncohen@watson.ibm.com> writes:
[stuff deleted]
:For example, suppose a program has an array of "producer companies" that
:manufacture a particular product and an array of "consumer companies"
:that buy that product.  Suppose the program manipulates both integers
:meant to index into the first array and integers meant to index into the
:second array.  Mistakenly using a variable holding an integer of the
:first kind to index into the second array could produce subtle errors
:that might be hard to track down, or might just silently produce
:incorrect answers.  In a strongly typed language such as Ada, one could
:write
:
:   type Producer_Number is range 1 .. Max_Producer_Count; 
:   type Consumer_Number is range 1 .. Max_Consumer_Count;
:   Producers : array (Producer_Number) of Company;
:   Consumers : array (Consumer_Number) of Company;
:
:Producer_Number and Consumer_Number are distinct integer types whose
:uses cannot be intermixed without an explicit type conversion.  (This is
:a degree of type protection unavailable in C or C++).  Certain variables
:can be declared to be of type Producer and others of type Consumer.  An
:attempt to use a variable of type Producer_Number to index into the
:array Consumers will produce a compile-time type error.
:
:As you said, "Smalltalk does not lend itself to 'type' errors of that
:nature."  Smalltalk programmers are no less likely than other
:programmers to use an integer variable to index into the wrong array,
:but since Smalltalk does not have the means to express such distinctions
:as type distinctions, I would imagine that most Smalltalk programmers
:would think of this as a "general logic error" rather than as the kind
:of problem that would be caught by compile-time type checks.  (When you
:don't have a hammer, none of your problems look like nails.)

Sure, smalltalk programmers can index into the wrong array.
However, your example appears to be formulated for a procedural
style of programming.  When smalltalk programmers want to
separate consumers and producers they usually use different
objects which reduces the tendency to produce the type of
errors you refer to.

Part of the power of smalltalk is the use of interface polymorphism.
Classes do not have to inherit from the same root to be able
to use the same message interface.  When designing the
software for your problem one can compose methods that use
polymorphism so that a single method can "operate" on producers
and consumers without having to know what it is operating on.
As a matter of fact a programmer reading the method may not
even be able to tell if it processes consumers or producers
because both will work.

Smalltalk works quite differently than traditional languages.
To appreciate its power you really have to use it, studying
it is not enough.  Also, you will quite frequently hear people
say that it takes them anywhere from 6 months to a year
of using smalltalk before their mind set has changed enough
so they can really do smalltalk right.  The problem is not
learning how the library works, though it is a big learning
curve, it is changing ones perspective that takes a while.

===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk   *Breakpoints* and *Watchpoints* for
19 Tilley Ave.                  VW and ENVY/Developer 
Newport, RI  02840
(401) 846-6573      traymond@craftedsmalltalk.com
http://www.craftedsmalltalk.com
===========================================================

Re: OO, C++, and something much better!

[Eric Clayberg]

Norman H. Cohen wrote:
> You seem to be confusing type errors with all other kinds of
> compile-time errors.

I don't think so. I am well aware of what a type error is relative to
the universe of other compile-time errors.

> As you said, "Smalltalk does not lend itself to 'type' errors of that
> nature."  Smalltalk programmers are no less likely than other
> programmers to use an integer variable to index into the wrong array,
> but since Smalltalk does not have the means to express such distinctions
> as type distinctions, I would imagine that most Smalltalk programmers
> would think of this as a "general logic error" rather than as the kind
> of problem that would be caught by compile-time type checks.

Yes, I would definitely consider that a "general logic error" in the
Smalltalk (or C++) context.

> I mentioned the securities industry specifically because Alan Lovejoy
> had brought up the use of Smalltalk in that industry.  This industry has
> perceived that Smalltalk speeds deployment of software, but I suspect
> that few realize that this is accomplished by deferring the detection of
> some errors until after deployment!  

That is not a general property of Smalltalk any more so than of any
other language. Having developed commercial apps in a number of
languages, I have always been amazed at the stability of deployed
Smalltalk apps relative to apps built with other languages. If you say
that apps built with Ada are even more stable, then great. Do you have
any evidence that shows that deployed Ada apps are more stable in
practice than deployed Smalltalk apps? I have never seen anything beyond
supposition and guesses (usually offered up by folks who have never used
Smalltalk).

> The appropriate comparison here is
> not to C++ (an error-prone language whose supposedly strong typing
> system is too weak to catch many of the errors that language fosters),
> but to a safety-oriented language such as Ada.

Are you saying that Ada is incapable of propagating errors to the end
user? All errors are guaranteed to be fixed prior to deployment? That
would be remarkable.

-Eric

Re: OO, C++, and something much better!

[Tansel Ersavas]

Joachim Durchholz wrote:
> 
> Alan wrote:
> 
> > But replace "PL/I" with "any statically-typed language," and then you can
> > see the truth: "because any statically-typed language sucks, is why."
> 
> Come on, have you ever programmed in a statically-typed language?
> Seriously?
> What you say sounds just like a Basic programmer whom I tried to convince
> he should try (just TRY!) Pascal. He said he had seen it at the
> University, and Pascal sucked...

I used Pascal, C and C++ for more than 10 years, and developed and led
development of >500000 loc projects, and I am sorry to say that I still
think they suck. I now use Smalltalk and Self and sometimes Java if I
have to, and couldn't be happier.

About types, the following segment is an appendix to a recent posting I
made to these groups.

"The exaggerated importance of type checking in OO

There is a big debate about importance of type checking in object
oriented systems. We have one camp religiously defending type checking,
and another group defending unnecessity of it. There is a merit in both
sides� arguments. This has more to do with the implementation specific
problems than a general theoretical point of view. If we ask people who
are familiar with languages based on ADTs, type checking is so
necessary,
the absence of it is total catastrophe. If we ask a Smalltalker or a
Selfer, they will tell we that type checking is not all that important. 

The problem is two edged. The more type information we put into the
objects, the more we make them dependent of these types. Any changes on
these types will have to be detected, and these parts of the programs
need to be updated, even though in compiled systems a recompilation will
suffice in many cases. The reason of inflexibility of ADT based
languages such as C++ are partly due to their reliance on type checking.
On the other hand, in the languages that we get sinful flexibility, we
actually almost never know that we may have a problem that may lie in an
untested corner, and may lurk at an unexpected moment. 

Contrary to what people say, type checking is against the nature of
object oriented systems development. Remember, in OO, we only care about
the interface of the other object. In fact it should be an OO sin to ask
the type, because, in theory, we don�t want to get intimate with objects
we are interacting apart from their interface. We only want to know the
interface. But we do check types anyway, because we do not have another
way in many of the current popular languages to guarantee that this
object has the interface that we require. Type checking is necessary in
ATD based languages because of language structure. In languages such as
Smalltalk, on the other hand, even knowing the type of an object is not
a guarantee that this object will answer a method that we use, because
we can really delete any method for that object while the system is in
operation, so even type checking is not a perfect solution. 

Then what is the solution? Common Object Requester Broker Architecture
(CORBA) makes this possible by allowing us to define only the interface
of objects. However, this approach is not much of a use of objects
within the same language. Some other languages have the notion of a
subtype, which is dependent on the interface. In the
languages which do not offer such mechanisms, one obvious solution that
comes to mind is to offer an interface signature, that will indicate
that an object really offers all the services that it is required. This
will guarantee that type of the object can change any time as long as
the public interface signature of the object does not change. Then any
object binding to this object can ask its signature rather than type to
verify that
the interface is the same as this object was created. This has run time
costs associated with it, but solves many problems that are associated
with type checking. Furthermore it is not practical for many ADT based
languages.  

In most ADT based languages type checking is done at the compile time.
This approach gives us a lot of safety, but also has an expensive price
tag in terms of flexibility and compromise of object oriented approach.
There can not be much done to increase flexibility of such languages.
One of my solutions for flexible systems such as Smalltalk is, to use
high level tools to automatically embed type or interface checking code
in development and testing phase, and after all tests are done, to
remove these checks automatically, allowing systems to run without type
checking once they are in production. This gives me best of the both
worlds."

the entire posting can be found in http://www.rase.com/oodebate/
 
... 

> I have heard several indicators that Smalltalk is very good at getting
> stuff done, in the quickest possible time. I'm willing to believe this
> (sounds reasonable anyway), but nobody talks about the disadvantages in
> the approach. Those who know Smalltalk program in it, so they won't tell
> me - and I can't believe there are none.
> I don't want to be converted to Smalltalk. I want to know about advantages
> and disadvantages, so that I can decide which language is better for a
> given task.

As a person who is developing with Smalltalk extensively I see so many
advantages, it is like working in another dimension. Development and
debugging (which I don't need to do much of debugging) becomes a joy,
rather than a burden. 

Disadvantages? Many. First, it was not easy to come to this point. I had
to spend about a year, and if I wasn't assigned to a project I wouldn't
have done it, because I didn't see a need to switch from C++ I was
enjoying. 
For starters, most Smalltalks and their tools are ridiculously
expensive. To me, this means  the vendors  shooting themselves in the
foot, at the same time hitting us with the richocet. 
Second, it requires changes in the overall approach. For the first year,
my methods looked rather like C++ ones. Only after a while I was able to
slowly embrace the entire notion and apply it. I am still sometimes
amazed with certain things I can do which I call "sickeningly simple"
solutions.   
Third, the darn class library. It takes a lot of time to digest it.
Fourth, people say absence of MI is not a problem, but it is not true.
Just look at the Streams class hierarchy and implemetation, soreness of
absence of MI is clear. 
Fifth: as I mentioned in the type checking discussion, dynamic typing
has so many advantages, but also disadvantages. 
Sixth: Lack of standardized class libraries between implementations,
especially in the GUI part. Luckily now there are graphical frameworks
such as GF/ST which give good portability between Smalltalks
Seventh: The difficulty of felivering an application (stripping,
packaging, etc), which now we have good but absurdly expensive 
Eighth: Performance. Actually this is a non-issue. I never suffered from
performance apart from screen drawing, or number crunching. In some
complex applications I was able to beat C++ applications.

You can browse some issues with Smalltalk at
http://www.rase.com/oodebate/choices.htm. 

So how do I live with these? I don't. In Smalltalk you have the power to
correct things. The open system architecture allows you to do that. For
instance, adding a simple MI by delegation took me two hours to
implement. I use it sparingly, and more on the modeling side, but I have
it when I need it. I have developed a tool with it which we will release
shortly to fix most of Smalltalk's problems. This includes layering and
visualizing Smalltalk class hierarchy to make it digest easier. The best
thing in Smalltalk is you don't have to live with problems. You have the
power to fix them. Except speed which you can't do much about. For
number crunching I use C. Apart from that I find Smalltalk more than
adequate.
 
> > Why would Chrysler hire Kent Beck to oversee the rewriting of their payroll
> > system in Smalltalk?  They could have chosen C++, Eiffel, Java or Ada95, or
> > just stayed with COBOL. Why didn't they?  Why choose Smalltalk, when there
> > are so much fewer programmers than would be available for C++?  Why choose
> > Smalltalk, when there is such a wide-spread bias against dynamic typing?
> 
> Maybe because they are manager? Not all decisions, even in large
> companies, are based on rational arguments. There is trust in consultants
> involved, who aren't always impartial. There is also much internal
> backstabbing involved - sometimes managers influence other managers into
> bad decisions, to weaken their internal position.
>
> Not that I'm convinced this is the case with the companies that you listed
> as examples. It's just that such success stories don't prove a thing. It
> would be much more interesting to hear about the consequences of these
> decisions, not about the decisions themselves.

Why don't you come to Smalltalk Solutions 97? You may see many examples.
It is in NY at Marriot Marquis between March 10-13. 

> > Why has the use of Smalltalk been growing at 60% per year?  In spite of the
> > absence of any Java-style marketing campain?
> 
> Maybe because two companies happened to decide for Smalltalk, which makes
> a huge difference if the installed base is small.
> I'm sure any proponent for any other language can make up similarly
> impressing figures.
> That 60% figure is worthless - you don't say wether it's number of
> companies, number of developer seats, number of productive systems, or
> lines of code. You don't even say since when this growth started - it
> might be 1 1/2 year as well as twenty years.

This is not true. Smalltalk base is growing very strongly especially in
organizations such as banks. Most organizations come to a point where
maintaining the existing system becomes such a burden, they have to
change to a new system. What language will they choose for the new
system? Cobol? In some cases yes. Now there are quite different looking
languages, so called "Object oriented Cobol" in workstations. However
these are the minority. I read somewhere that 15% of banks chose
Smalltalk as their new language, which worries me, because there are not
that many Smalltalkers to develop and support these systems. I think the
problem with Smalltalk is not that there are too little of it, on the
contrary, with this speed, we don't have good people to support these
systems. So much so, I get requests to set up a "Smalltalk School of
NY", which I am considering.

> > Smalltalk offers many times faster development times--and much greater
> > robustness in the face of changing requirements.  That's a strategic
> > advantage, especially in businesses and industries (like securities trading)
> > where time is not just money, but big, big money.
> 
> I already knew this. I consider this an interesting property of Smalltalk,
> but I'm not convinced Smalltalk is best for everything. And as far as I
> know, Smalltalk can't be integrated into a multi-language environment (at
> least not with a considerable amount of work, or with serious efficiency
> problems), so I'm somewhat hesitant to recommend Smalltalk at all.

No, there are Smalltalks and class libraries with extensive multi
language support. I am internally using a tool that finds all strings in
an application, sorts, finds duplicates, and prompts for each of them to
modify, without changing or recompiling code, the simplicity of that can
literally make many people "sick". These things are so trivial in
Smalltalk. 

> Regards,
> -Joachim
> 
> --
> Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

Kindest Regards
Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: OO, C++, and something much better!

[Tansel Ersavas]

Fergus Henderson wrote:
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> >Sure.  Everyone agrees that catching errors at compile time is less costly.
> >
> >However, dynamic typing results in signficantly faster development time.
> 
> That is highly debatable.  My experience is that static typing results
> in faster development time.

What is highly debatable? I have used C++ for a long time and now I am 
using Smalltalk, and there is NO comparison in development times. They
are simply different categories. Turtle vs. Rabbit.

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: OO, C++, and something much better!

[Alan Lovejoy]

Fergus Henderson wrote:
> 
> Eric Clayberg <clayberg@parcplace.com> writes:
> 
> >Fergus Henderson wrote:
> >> My experience is that errors caught by type checking constitute a LOT
> >> more than 2% of errors.
> >> For a period of time I carefully recorded the cause of every error that
> >> I found while writing a Mercury program.  Of the 155 errors that I
> >> recorded, 73 were error caught by the type checker.
> 
> While reexamining my list, I noticed that I had accidentally
> misclassified one class of errors containing 3 errors, so the number 73
> above should have been 70.  Sorry about that.
> 
> >If anything, I think that reflects poorly on the syntax of whatever
> >language you were using.
> 
> Some (14) of those 70 errors were related to the syntax, but most of
> them were errors such as "wrong number of arguments", "wrong procedure
> name", and so forth, that could occur in just about any language.  Note
> that the number 70 does *not* include errors in the type declarations
> themselves; there were an additional 13 of those.
> 
> Here's a more detailed breakdown.

To which I wish to add some comments and analysis:

>         syntax errors: 16
>         type errors: 83
>                 - errors in type declarations: 13

Doesn't apply to Smalltalk.

>                 - type errors other than errors in type declarations: 70
>                         - syntax related: 14		
May or may not apply to Smalltalk.  Can't
tell without more specifics.  I assume that
this does not apply to Smalltalk, or that
the Smalltalk compiler would catch this sort 
of error just as well as in a statically-typed 
language.

>                         - wrong procedure name: 11

The Smalltalk compiler will complain when you compile
a method that sends a message with no implementors.
So this would only apply to those cases where the
"wrong" name matched that of some other method.
I would assume that all such errors out of 11 would be 
caught by the Smalltalk compiler (about 99% would be
caught overall).

>                         - wrong constant name: 4
>                         - wrong variable name: 4

Were these "wrong" names simply undeclared, 
or declared but wrongly typed?  How many of the
"wrongly typed" ones involved type differences
that don't matter in Smalltalk (ie, long vs. short
numbers, different types of Collection)?  I will ssume that 
1 of these 8 errors would cause a Smalltalk program to 
produce the wrong result or fail (the Smalltalk compiler 
will catch any undeclared references, and about 92% of type 
incompatibilities in C++ are cases that will "just work fine"
at runtime in a Smalltalk program).

>                         - wrong number of arguments: 21
>                         - incorrect argument order: 5

Such errors (argument number/order) are FAR less likely 
in Smalltalk, thanks to Smalltalk's method name syntax.  
When they do occur, they are usually caught by the compiler 
because the incorrect message selector will probably not 
have any implementors.  Assume that all such errors would
be caught by the Smalltalk compiler (about 99% would be 
caught overall).

>                         - argument has wrong type: 7

How many of these involved type differences that don't
matter in Smalltalk? And how many were caused by the fact
that the Algol-style function call syntax makes it so easy
to get the arguments wrong? I'd assume that all of these 7 errors 
would simply not have happened in a Smalltalk program, either
because of the superior function call syntax, or because of
the superior interchangeability of similar object types.
Overall, I'd assume such errors happen about 1% of the time.

>         other errors detected at compile time: 47
>                 - missing `import_module' declarations: 7
>                 - errors in mode declarations: 13
>                 - others: 27
>         errors not detected until run time: 9

So I would estimate that of the 83 type errors, only 1 of them would show up at 
runtime in a Smalltalk program.  And all of them would probably be caught during 
early program testing. Other advantages of Smalltalk would probably eliminate several 
of those 9 run time errors (for example, more abstract code means that less new code
would need to be written to implement the program, and Smalltalk's large library
of classes/methods also reduces the need to write new--more buggy--code).  And if
it's a C++ program we're comparing against, then that introduces a whole menagerie
of possibilities for errors that would not occur in a Smalltalk program (can you
say "dangling pointer"?  I knew you could). 

And of course, the Smalltalk program will be ready for testing sooner, and thus 
you will have the luxury of testing it more thoroughly.

> The "syntax related" errors all relate to a particular aspect of
> Mercury syntax: calling and defining procedures that have implicit side
> effects uses a different syntax than is used for procedures which do
> not have any implicit side effects.  This is clearly an error-prone
> aspect of the syntax, but it enhances readability.
> 
> Of the "syntax errors", 10 were caused by missing or additional commas;
> this class would probably not occur if Mercury syntax used say `;' as
> a statement terminator rather than `,' as a statement separator.

Note how syntax affects the error rate.  The superiority of the Smalltalk
message send (function call) syntax in this regard has not been sufficiently
highlighted in these sorts of discussions, in my opinion.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Joachim Durchholz]

Tansel wrote:

> Contrary to what people say, type checking is against the nature of
> object oriented systems development. Remember, in OO, we only care about
> the interface of the other object. In fact it should be an OO sin to ask
> the type, because, in theory, we don�t want to get intimate with objects
> we are interacting apart from their interface. We only want to know the
> interface.

There's a misunderstanding here.

I agree checking should be done on the interface, but I was not aware of  
any difference between type and interface. After all, objects with  
identical interface have the same type for all practical purposes.

> ATD based languages because of language structure. In languages such as
> Smalltalk, on the other hand, even knowing the type of an object is not
> a guarantee that this object will answer a method that we use, because
> we can really delete any method for that object while the system is in
> operation, so even type checking is not a perfect solution.

A good type-checking Smalltalk system could work with versioning, so if  
you delete a routine, you actually define a new class with the routine  
deleted. Existing (typechecked) code would continue to work. Of course the  
system should convert as much as possible to the new version of the class  
structure, but if it finds code that uses the delete routine, the  
programmer has to correct it (or the code has to remain on the old version  
level).

> Disadvantages? Many.

Thanks for the info. This type of stuff is tremendous help in seeing  
beyond all the hype.

> For starters, most Smalltalks and their tools are ridiculously
> expensive. This is equivalent for the vendors to shooting themselves in
> the foot, at the same time hitting us with the richocet.

Seems to be a general problem. Obviously this is one of the worst market  
barriers for new languages: Market is small, so prices have to be high to  
make a living from them, so market remains small.
On the other hand, this has saved us from countless language wars, so  
maybe this vicious circle is a godsend...

> Why don't you come to Smalltalk Solutions 97? You may see many examples.
> It is in NY at Marriot Marquis between March 10-13.

Sorry, that's a bit far from Germany... (domain .de is short for  
"Deutschland").

> This is not true. Smalltalk base is growing very strongly especially in
> organizations such as banks.

I didn't want to downplay the growth of Smalltalk. It's just that the  
numbers presented were nearly content-free. I'd very much like to see some  
solid numbers, though.

Regards,
-Joachim

--
Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32E6862D.608B@parcplace.com> Eric Clayberg <clayberg@parcplace.com> writes:

> Norman H. Cohen wrote:
> >[...]
> > Of course dynamic typing does not make these errors go away, it just
> > hides them so that you have to find them yourself instead of having them
> > pinpointed for you by a compile-time error message.
> 
> Not true. In a language like Smalltalk, those "errors" as you call them
> are not hidden; they never existed to begin with. Having worked
> extensively with several statically types languages (C, C++, Fortran,
> etc.) and now having worked commercially with Smalltalk over the last
> several years, I conclude that most "type" errors in statically types

Well, the evidence you list here is not convincing.  I mean C?
Fortran? or even C++?  These are not particularly strongly typed.
Though they are statically typed.  The first two are definitely not as
strongly typed as ST.  But, you can easily get the errors that are
mentioned above by NC in ST.  They just come out differently.  Shrug.
I tend to think that catching them earlier is better.  Also, the
structure imposed is better for long term maintenance and new
maintainers (those who did not write the stuff).  As Alan has pointed
out, the ST answer to this is the "ease/speed with which you can
change" something.  Yes, but that does not seem sufficient - to me.
Clearly it is for others.


> > In my experience, a line containing a stupid mistake that would have
> > been caught by decent compile-time checks can easily take 50 times as
> > long to develop (counting the time to debug a line as part of that
> > line's development time) as a line without such an error.  In that case,
> > even if we accept the 2% figure, static typing is still a win.
> 
> I don't follow that logic at all. I think you are multiplying apples and
> oranges together to get pears. The dubuggers commonly available with
> most Smalltalk systems make finding and fixing bugs a trivial process -
> certainly no harder than writing the code in the first place.

Norman clearly has a point.  But it is just as clear that it is not
obvious when something like a "50 times" factor is involved.  Or
whether it is a case of "50 times nothing is still nothing" (small
programs) and so would be irrelevant anyway.  OTOH, debuggers are not
relevant for fielded software and besides debuggers for statically
typed languages have become pretty sophisticated as well, so "debugger
sophistication" is not relevant either.

> projects in the past, I can tell you some of the reasons why Smalltalk
> is so popular there: 1) it provides much faster time to market (very
> important in the securities industry),

Makes some sense.

> 2) it has a simple, logical and consistent language syntax
> (developers can concentrate of the problem at hand and not the
> vagaries of the syntax),

That's nice, but should be irrelevant to the customer.  So, I don't
see how this could _objectively_ have anything to do with why they
like it - they never see the syntax (or at least they shouldn't have
to!)


> 3) it is extremely reliable in practice (the language features of
> Smalltalk help eliminate whole classes of errors common in languages
> like C++),

Nobody's talking about C++ here.  Or for that matter even Java.  Try
Ada or Eiffel.  How many commercial jet liners are running their
systems with ST?  Of course there is a tradeoff - this kind of
reliability does not come from "getting _something_ quickly up and
'running'".  OTOH it is quite believable that "wallstreeters" deem
time to use, worth the reliability risk.  This is often true when you
are "playing percentages".


> 4) it is extremely easy to debug when an error does occur. If you
> doubt that any of these are true, then you should try it out
> yourself. You can download Smalltalk Express (a fully functional,
> 16-bit WIndows Smalltalk IDE) for free from
> http://www.objectshare.com.

That's great too.  But this is equally true of strong statically typed
languages, both "extremely easy to debug" and available free
downloadable versions.  Actually some of these (GNAT for example) are
high quality industrial strength implementations.


/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Andy Bower]

Eric Clayberg <clayberg@parcplace.com> wrote:

>Fergus Henderson wrote:
>> I don't know how it got its start there, but I have heard that it got a
>> bit of a boost after the stockmarket crash in '87.  Apparently the
>> volume of shares traded was very high, and many financial programs
>> failed, because the numbers involved were so large that they overflowed
>> various limits, but the Smalltalk programs kept running, because
>> Smalltalk quietly switches to using floating point arithmetic when
>> integer arithmetic overflows.  (Well, that's the rumour anyway.  I
>> don't know how much truth there is to it.)

>Actually, Smalltalk transparently switches to using "large" integers
>that have no limits on size. In fact, it's actually fun to run large
>factorials in Smalltalk to see how large an integer it will generate.
>VisualSmalltalk will calculate the result of "1000 factorial" in a
>second or two and display the results. BTW, the result of that
>expression is: :-)

>large number snipped<

Eric,

Perhaps an even more amusing trial, to embarass those used to
languages that rely soley on fixed size integer and floating point
arithmetic, is  to use Smalltalk to calculate the largest known prime
number. To do so, evaluate:

(2 raisedToInteger: 1257787)-1

A word of caution, however. DON'T DISPLAY the result. In Dolphin
Smalltalk it takes a mere couple of seconds to calculate the prime but
to print out it's 378,632 digits demanded a whole evening of toil for
our Pentium 200. For this reason, I am not embedding the result to
this posting.

Happy number crunching

Andy Bower
bower@intuitive.co.uk

Re: OO, C++, and something much better!

[Richard A. O'Keefe]

The debate about Smalltalk has missed the point, I think.
Eric Clayberg thinks Fergus Henderson's experience with Mercury
refelects badly on Mercury syntax.  He doesn't realise that
Mercury syntax is *simpler* than Smalltalk syntax.

My experience with several languages is that the commonest cause of
type errors in programs that _I_ write is getting the number (in
dynamic languages) and/or order (in both static and dynamic languages)
of arguments wrong in subprogram calls with many arguments.

The type system is not the only way in which Smalltalk differs from C.
Another important way is the syntax of function calls.
Smalltalk encourages the use of infix operators whenever it makes sense.
It's fairly easy to remember the order of two arguments.
For operations with more than two arguments, the names of the arguments
are in effect part of the spelling of the name of the operation.
For example,
	arr Put: elt At: inx
*tells* you what the order of the arguments is; writing
	arr Put: inx At: elt
is not a very likely mistake.  And that's good, because sometimes inx and
elt are the _same_ type, in which case a type checker won't help you at all.

In the Prolog library I developed for Quintus, I took great pains to use
consistent argument orders and to build the argument order into the
operation name whenever I could.  For example,
	string_length(String, Length).

I'm actually reading this in comp.lang.ada.  Ada provides keyword syntax
for parameter passing.  If you write
	Put(Item => Foo, File => Bar);
it's easy to get the parameters right, because the name is reminding you
what the argument should be.  (So-called Hungarian notation is a pathetically
crippled makeshift in comparison.)

Ada also works around the "inx and elt are the same type" problem in many
cases.  If I have
	Max_Box_Number: constant := 1000;
	type Box_Number is range 1 .. Max_Box_Number;
	Max_Apple_Count: constant := 200;
	type Apple_Count is range 0 ... Max_Apple_Count;
	type Box_Table is array (Box_Number) of Apple_Count;
	B: Box_Table;
then
	B(M) := N;
and	B(N) := M;
cannot both be legal.

Does anyone have any statistics, for any language, of the *causes* of
things that produced type errors as *symptoms*?  Fergus, how about you?

The point I am making here is that there are other ways of reducing
errors-with-type-clashes-as-symptoms than a static type checker, and that
Smalltalk has one very effective one (parameter names in calls, and calls
without parameter names forced to have very short argument lists).
Maybe we can find some other things that help.  Yes, a static type system
is very good at noticing the symptoms, but we can _all_ benefit from
reducing the _causes_.

-- 
My tertiary education cost a quarter of a million in lost income
(assuming close-to-minimum wage); why make students pay even more?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Don Harrison]

Gee, Eric. It seems like you versus the whole static typing community. :(

You wrote:

:What about propogating a null pointer exception to the user? Is that
:somehow better?

I don't want to argue about whether or not exceptions should be propagated
(as others are doing a good enough job of that). I just want to encourage
you not to use C++ as the basis for your comparison with Smalltalk.

Some of your comments seem to assume that C++ is the sterotypical statically-
typed language. It isn't - it's merely the most popular. :(  You would be
better off comparing Smalltalk with a statically-typed langauge with a 
coherent type system such as Eiffel, Ada or Sather.

Some of your antagonists come from those backgrounds and they would agree with 
you that C++ is the pits. :)


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Richard A. O'Keefe]

Eric Clayberg <clayberg@parcplace.com> writes:
>Having been involved with commercial Smalltalk development for quite a
>few years, I tend to agree with Alan that the percentage of actual type
>related errors in Smalltalk programs is less that 2% - ....
>experience. I have written over several hundred thousand lines of
>... Most "message not
>understood" errors, in fact, are to the nil object in Smalltalk (the
>moral equivalent of a null pointer in C). These are not really type
>errors, but usually problems with improper initializations or premature
>discarding of data. These are logic problems; not type problems. A
>static type checker would catch them no better in Smalltalk than it
>would in C++.

Sorry, there is a misconception here.  There _are_ type systems,
several in fact, which _would_ catch such errors.  For example, I
believe the *type checker* in Dr Scheme will catch many of these
errors.  Suppose you have a function f which is defined on some
set of values v, and there is an expression (f x).  The type checker
determines a set of possible values p for x.
	p subset v => static check passed.
	p intersect v empty => certain type error
	neither of the above => run time check needed
The Dr Scheme checker uses something called "set based analysis".
I believe that the Stalin compiler does something similar.

Thing is, "type error" is a term in the language of SYMPTOMS,
"logic error" is a term in the language of MISTAKES.
A type error may very well be a symptom of a logic error, why not?

The fact that a C++ compiler cannot detect null pointer errors as
type errors is a fact about C++ specifically, not a fact about static
type systems in general.  I once designed a type system in which
	^T
meant non-null pointer to T and
	?T
meant possibly-null pointer to T.  (My main reason for this was
optimisation; I wanted safety, but didn't want to pay the price
of null checks over and over again.)  In that type system,
	var x: ?T; y: ^T := new T;
	x := y;		-- always legal
	y := x;		-- needs a run time check
	x := null;	-- always legal
	y := null;	-- statically illegal

What's more, there is a static checker for C called LClint, available
free from http://larch-www.lcs.mit.edu:8001/larch/lclint/
that _does_ perform static checks for null pointers, and _does_ check
for initialisation.

Of course, the kinds of data flow analysis that LClint does (or more
truthfully, approximates) are hard to do in a "fluid" language like
Lisp or Smalltalk, where what the program _is_ can change at run time.
The basic issue there is really dynamic *programs* in Lisp, R, S,
Prolog, Smalltalk, &c vs static *programs* in C, Ada, &c.

-- 
My tertiary education cost a quarter of a million in lost income
(assuming close-to-minimum wage); why make students pay even more?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Don Harrison]

Norman H. Cohen writes:

:Don Harrison wrote:
:>
:> Matthew Heaney writes:
:>
:....
:> :
:> :And as far as your example "proving" that Ada is not type-safe: that is
:> :incorrect.
:>
:> Correct, according to the Ada definition. As Norman Cohen put it,
:>
:> : It shows that Ada is not subtype-safe.
:>
:> That becomes "not type-safe" if you regard sub-types as distinct types.
:
:I'm reminded of the following riddle, which I've seen attributed to
:Abraham Lincoln:
:
:   Q: If you call a dog's tail a leg, how many legs does a dog have?
:   A: Four.  Calling the tail a leg does not make it one.

Nice quote. :)  If Abe Lincoln said it, it must be true! :)

:Calling a subtype a distinct type does not make it one.  Reread that
:post of mine that you quoted.  Its main point is that, according to the
:Ada definition, subtypes are NOT distinct types.  

I no longer have it but I did read it. What you suggest is true "according to 
the Ada definition". However, IMO, the definition is inadequate. 

:Distinct types are
:disjoint sets of values distinguished at compile time.  

Don't agree. I think they must simply be *different* sets of values. In the 
special case where the set of values is a subset of the values of another 
type, you have a sub-type (in the Ada sense). 

:Subtypes of a
:type are (possibly overlapping) sets of values in the same type,
:distinguished by whether or not they obey certain constraints that can,
:in general, only be checked at run time.

Yes ... "according to the Ada definition".


The real issue, as far as I'm concerned, is that type safety (not surprisingly)
depends on the definition a type. A language such as Eiffel might be regarded
as type-unsafe purely because it regards sub-types as distinct types. These 
types - and their attendant runtime constraint violations - are materially
no different from equivalent sub-types in Ada - which also cause runtime
constraint violations.

It's absolutely meaningless to declare one language type-safe and another 
unsafe without reference to the definition of type underlying the claim.

Is it possible to write a system-invalid Ada program? Definitely, ... as you
can with Eiffel.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Mark Windholtz]

Marc Robertson wrote:
> 
> Alan Lovejoy wrote:
> >
> > Graham Hughes wrote:
> > >
> > > Why should they manually check that the object is capable of the
> > > operations demanded when the compiler can?
> >
> > This is a non argument.  Since someone must check, there is no difference in
> > principle whether that someone is the compiler or the run-time system.  It's
> > an implemenation difference, not a difference in kind.
> 
> There is a difference in practice.  If the compiler detects an error,
> the only one that has to worry about it is the developer.  If an error
> is present that the run-time system has to handle, all users are
> potentially affected by it.  There have been any number of studies(
> unfortunately, I don't have access to them here, so I can't quote them )
> that indicate that the cost to correct a problem increases dramatically
> the later in the development process you detect it. The sooner problems
> can be eliminated, the less it costs to eliminate them!
> -- 

 I'm sure most agree that finding and correcting problems
 early is a good thing.  The question is what kind of problems?  
 Dynamic languages let you test the logic more and 
 static languages (perhaps) let you test the interfaces more.

 I say "perhaps" because as soon as casting is added to 
 a program written in a static language, you lose the
 testing of the interface.

 And it is very hard to write interesting OO in a static
 language without occationally casting.

 I maintain that to use a static language with casting
 amounts to paying the time-to-market cost of a static
 language while writing extra code to support features
 that come for free in a dynamic language. 

 It seems to be the worst of both worlds.
   
 The mistake of casting NULL to an object and attempting
 to call a function on it in C++ is the same mistake as
 sending a message to the Nil object in Smalltalk.

 But at runtime only the static language is likely 
 to cause a core dump or GPF.  In other words the
 result of the error is more costly.  And the compiler
 can't help in either case.

 -------------------------------------------
 Cincinnati/Dayton Smalltalk Users Group
 http://www.infinet.com/~mwind/st_users.htm
 -------------------------------------------
 Mark.Windholtz@sdrc.com   (513) 576-5626
 home:Windholtz@acm.ORG

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "doylep" == Patrick Doyle <doylep@ecf.toronto.edu> writes:

doylep> In article <yf3sp3y9ur6.fsf@sabi.demon.co.uk>,
doylep> Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:

piercarl> Unfortunately exceptions-as-object is a bad idea, and claiming
piercarl> priority for bad ideas is hardly a sport worth engaging
piercarl> into. :-)

doylep>   Could you elaborate on why that is a bad idea?

Of course, and easily; somebody asked me the same idea by private
e-mail, so I can just paste in the reply(s) and do a little bit of
editing. It's also one of my pet peeves... And it is astonishing that
what I am going to say, that has been part of the state of the art for
some dozen years, is not yet apparently widely known.

Let's start with the nature of exceptions. The first point is that if a
procedure implements a total function then it will never have an
exception.

Therefore exceptions arise only and only if a procedure implements a
partial function, and arise only and only when the inputs to a procedure
are outside its domain.

This means that an exception can only arise when at some point in a
procedure where there is a 'if' (or similar) statement whose
precondition is stronger than the postcondition of the statement that
precedes it. For example:

  float sqrt(float f) { if (f >= 0) return exp(0.5*ln(f)); }

Here the precondition of the 'if' is $f >= 0$, but the postcondition
preceding it is (more or less) $true$.

Now exception handling means extending the precondition of a procedure,
up to making it become a total function. This means simply weakening the
precondition of 'if's by adding 'else'/'elif' clauses.

Consider:

  extern float sqrt_neg_arg(float);

  float sqrt(float f)
    { return (f >= 0) ? exp(0.5*ln(f)) : sqrt_neg_arg(f); }

Now 'sqrt' is a total function. This is the general way of``defining''
and ``raising'' exceptions: provide an 'else' that invokes a procedure;
the name of the procedure is the name of the ``exception''.

Unfortunately in the general case this simply cannot be done as written,
because the author of a piece of software may not be in a position to
know what to code in those 'else's, for the more appropriate action may
depend on the runtime context. It is thus inappropriate to assign a
statically defined association between a name like "sqrt_neg_arg"
and a procedure implementation.

The obvious and correct solution is to make the name of the procedure
dynamically scoped; then it can be redefined whenever this is needed.

Thus:

* an exception is a fact, not an object;

* the fact is the absence of a suitable 'else' somewhere when it should
  be there;

* defining and raising an exception means simply adding an 'else' and a
  call to a dynamically bound procedure;

* handling an exception means simply resolving the dyanmically scoped
  name to a procedure body and executing it.

Finally, recovery from an exception may involve non local control
transfers out of the procedure that handles the exception; but this is
an entirely separate issue. It need not be the case.

So, basically *everything* is wrong (and clumsily so) with the ``C++''
exception-as-object system:

* the name of the exception class should be that of a dynamically scoped
  procedure.

* an exception object is really just a clumsy and silly way of
  specifying an argument list to that dynamically scoped procedure.

* non local control transfers are then mandatory.

Consider the stark contrast between (in some language reminiscent of
``C++''):

  fluid float sqrt_neg_arg(float);

  float sqrt(float f)
    { return (f >= 0) ? exp(0.5*ln(f)) : sqrt_neg_arg(f); }

  main()
  {
    {
      fluid float sqrt_neg_arg(float f) { return 0.0; }

      printf("%f\n",sqrt(-2.0));
    }

    {
      fluid float sqrt_neg_arg(float f)
      {
	fprintf(stderr,"panic: negative arg to 'sqrt': %f\n",f);
	abort();
      );
      
      printf("%f\n",sqrt(-2.0));
    }
  }

and

  class sqrt_neg_arg {
  public: float n;
    sqrt_neg_arg(float f) : n(f) {}
  };

  float sqrt(float f)
  {
    if (f >= 0)
	  return exp(0.5*ln(f));
    else  throw sqrt_neg_arg(f);
  }

  main()
  {
    try { printf("%f\n",sqrt(-2.0)); }
    catch(sqrt_neg_arg &sna)
    {
      // cannot just return 0.0 -- too bad.
      puts("0.0"); // not really what we wanted
    }

    try { printf("%f\n",sqrt(-2.0)); }
    catch(sqrt_neg_arg &sna)
    {
      fprintf(stderr,"panic: negative arg to 'sqrt': %f\n",sna.f);
      abort();
    }

  }

As you can see the second solution is really just a clumsy, misleading,
limited version of the first. Exceptions are not objects; and exception
objects are just stupid ways of passing a parameter list to a
dynamically scoped procedure name, which is confused with a class.

However, in most cases even for exception handling one does not really
need dynamically scoped function names; dynamically scoped function
pointer variables are about as good, as in (rewriting my example):

  float sqrt_neg_arg_default(float f)
    { fprintf(stderr,"sqrt neg arg: %f\n",f); abort(); }

  fluid float (*sqrt_neg_arg)(float) = sqrt_neg_arg_default;

  float sqrt(float f)
    { return (f >= 0) ? exp(0.5*ln(f)) : (*sqrt_neg_arg)(f); }

  float sqrt_neg_arg_zero(float f)	{ return 0; }
  float sqrt_neg_arg_abs(float f)	{ return sqrt(-f); }

  main()
  {
    {
      fluid float (*sqrt_neg_arg)(float) = sqrt_neg_arg_abs;
      printf("%f\n",sqrt(-4.0));  // prints 2.0
    }

    {
      fluid float (*sqrt_neg_arg)(float) = sqrt_neg_arg_zero;
      printf("%f\n",sqrt(-42.0)); // prints 0.0
    }

    printf("%f\n",sqrt(-33.0)); // default, aborts
  }

Dynamically scoped function pointers have the advantage that they don't
require introducing into the language nested functions, and allow one
more easily to separate ``exception handler'' interface and
implementation.

Note that in effect in ``C++'' the 'fluid' storage class that turns a
variable into a dynamically scoped one is pretty easy to simulate (in
the shallow binding way) using constructors/destructors:

------------------------------------------------------------------------
typedef void		*Fluid;

class FluidFrame
{
private:
  Fluid		   	  saved;
  Fluid			  *variable;
public:
  construct		  FluidFrame(Fluid *);
  destruct		  ~FluidFrame();
};

static inline		FluidFrame::FluidFrame
( register Fluid	  *const avariable)
{
  this->saved	  = *avariable;	/* Save old value	    */
  this->variable  = avariable;	/* Note where to restore it */
}

static inline		FluidFrame::~FluidFrame()
{ *this->variable = saved; }

#define fluid(NAME)							\
  FluidFrame Fluid_##NAME(& (Fluid) (NAME)); NAME

#define fluidfor(CLASS,MEMBER,NAME)					\
  FluidFrame Fluid_##CLASS##_##NAME					\
    (& (Fluid) (CLASS MEMBER NAME));					\
  CLASS MEMBER NAME
------------------------------------------------------------------------

The the example above becomes:

  float sqrt_neg_arg_default(float f)
    { fprintf(stderr,"sqrt neg arg: %f\n",f); abort(); }

  float (*sqrt_neg_arg)(float) = sqrt_neg_arg_default;

  float sqrt(float f) // implements a total function
    { return (f >= 0) ? exp(0.5*ln(f)) : (*sqrt_neg_arg)(f); }

  float sqrt_neg_arg_zero(float f)	{ return 0; }
  float sqrt_neg_arg_abs(float f)	{ return sqrt(-f); }

  #include <Fluid.H>

  main()
  {
    {
      fluid (sqrt_neg_arg) = sqrt_neg_arg_abs;
      printf("%f\n",sqrt(-4.0));  // prints 2.0
    }

    {
      fluid (sqrt_neg_arg) = sqrt_neg_arg_zero;
      printf("%f\n",sqrt(-42.0)); // prints 0.0
    }

    printf("%f\n",sqrt(-33.0)); // default, aborts
  }

which seems rather legible, vastly more flexible/reasonable than the
convoluted and limiting current ``C++'' syntax.

Now there is completely orthogonal problem of non local control
transfers, which might well be useful in a procedure implementation that
``handles'' an exception. In the above code snippets an example of the
use of non local control transfers is the call to 'abort()', which exits
the current process and transfers control back to the invoking process;
one could use 'setjmp()' or 'longjmp()', or something better, for finer
grained control transfers.

It is a pity that the ``C++'' exception handling features tie so
intimately together the distinct concepts of dynamically scoped
identifiers (and then they are provided in a rather clumsy form) and of
non local control transfers (and then they are also provided in a rather
clumsy form).

The issue of non local control transfers, even if only the form of
upward funargs, and scope entry/exit triggers, is interesting and
``C++'' provides only ad hoc and limited machinery to deal with it.

  As to this, I rememjber reading someone stating that as far as he knew
  only TECO (yes, TECO!) of most languages around provides general clean
  entry/exit scope functions/triggers. Ah well.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Paul Kyzivat]

piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote:

[snip a long and interesting explanation of exception handling]

I found the discussion very interesting. In a theoretical way I agree
with you. However I think in a practical sense it misses the point to
an extent:

For code to be readable, it is useful to have the exception handling
easily and clearly lexically scoped with the code that it applies to.
What you suggest is really very little different than what existed in
various libraries prior to the introduction of compiler supported
exception handling. I remember it in Fortran - it did a nice job of
adding to the confusion of all those gotos.

You are right that this really has more to do with how to suport a new
form of non-local control transfer than it does exceptions. But
usually non-local control transfer is required for exception handling
because the function otherwise has no return arguments that can be
used to express what happened. And, while TRY is ugly and clumsy in
some cases, it does allow the normal flow of control to be segregated
from the abnormal flow of control while still making it clear how they
are related.

I agree with you that classes as exceptions is in a way a kludge. But
they do more than pass arguments to a handler. They also server as a
hierarchical classification system for exceptions. Using classes for
this is a matter of economy of language concepts. (Perhaps we can call
it reuse of a language concept.)

	Paul Kyzivat

Re: What is wrong with OO ?

[Damon Feldman]

 Bertrand Meyer <bertrand@eiffel.com> wrote:
>Bjarne Stroustrup wrote:

>> C++ use grew
>> very nicely for years without hype. I base my statement on years of looking
>> at C++ use, teching, and learning - many of those years were before anyone
>> was given time off from their day job to learn C++.

>This is really too far off the reality to let pass

>people promoting
>less-hyped and less-politically-correct approaches, coming in many cases
>from private industry (often precisely because they were more innovative
>and could not find a hospitable environment in academia or even large
>corporate research labs) had to resort to the normal, commercial forms
>of "marketing", thus allowing their better endowed competitors to drape
>themselves in the mantle of Pure Science and accuse the former of crass
>commercialism. This is a very effective tactic, and worked quite well in
>the history of O-O: keeping innovators  away from the Establishment

Come come.  Private industry is more innovative than academia "or even large 
corporate" labs?  "This is an effective tactic [for] keeping innovators away 
from the Establisment?"  If the innovators did get close to the establishment, 
might they have discovered who really assasinated Kennedy :-).

Just kidding, of course.

But I think that the academic success of C++ was based on acceptance by 
tenured faculty who were not payed off or otherwise influenced by big business 
or in a conspiracy to foist C++ on the programming community.

C++ was object oriented, and it was downward compatible (almost) with C, which 
was and is in wide use.

Damon

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Ronald E Jeffries]

On 25 Jan 1997 02:07:04 +0000, piercarl@sabi.demon.co.uk (Piercarlo
Grandi) wrote:

>Let's start with the nature of exceptions. The first point is that if a
>procedure implements a total function then it will never have an
>exception.
>
>Therefore exceptions arise only and only if a procedure implements a
>partial function, and arise only and only when the inputs to a procedure
>are outside its domain.

Yes ... and then you go on to make the function more robust, which
would be a good thing when it's practical.  But as you point out, the
exceptions arise when the inputs are out of the range contemplated by
the function as written.  

Exceptions, however, whether represented as objects or long jumps, are
about handling the unexpected.

My application system must keep on going, whether or not the input
routines are prepared to deal with B's in the middle of the numbers,
and dates like 2/31/1997.  Complexity, lack of access to the code,
limited resources mean that the input routines won't ever be made
complete.  And they can't know what their users want done with those
B's and weird dates anyway.

At the same time, when using the input routines, it is impractical
(costly and error-prone) to have every call to the routines check for
errors.  It is much more practical and convenient to choose a standard
place where, if an input error occurs, a default action can be taken.

In a project I'm presently working on, the input routines try to
handle all the errors.  Then when the application definers decided
what kind of notifications they wanted on input errors, we had to go
in and edit the input routines and change them all around to get the
job done.  Had they just thrown an exception, we could have fielded
the exception where we wanted to, and filed our notifications and gone
on.

While complete program correctness is an interesting science, it is
not something that we often attain in practice.  Exceptions are a
simple and practical way to deal with the faults we humans often leave
in our programs and our data.

Regards,

Ron Jeffries
Smalltalker
How do I know what I think until I see what I type?

Re: OO, C++, and something much better!

[Robert Dewar]

Richard said, replying to me

>>equally if you do something like
>>
>>   (x = p; x < &p[10]; p += 3)
>>
>>you can find you have an infinite loop, all quite in accordance with the
>>C semantics, although somewhat surprising.
>
>This case must work.  Such a reference to the end of an object is required
>to be treated like a reference within the object.

(note, the p += 3 should of course be x += 3, as I noted in a followup
 post, but I assume Richard understands this typo)

Chuckle, chuckle, it is nice to be able to catch Richard out like this :-)

Richard, you did not look at the example carefully enough. The fact that
you think it works even after I warned that it does not is a perfect
example of how serious this pitfall is!

>   (x = p; x < &p[10]; x += 3)


The problem in my example is that I am bumping x by 3 each time. Sure
it would work if the 3 is replaced by 1, because of the special kludge
in the ANSI standard to allow &p[10] but the increment of 3 causes the
value of x to be further past the end of the array, and this is not
required to work.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Bryan Dollery]

Ronald E Jeffries wrote:

[...]

> Exceptions, however, whether represented as objects or long jumps, are
> about handling the unexpected.

Nice misconception. Exceptions are deviations from the rule.

There has also been some discussion in this thread about partial/total
functions, and how total functions don't need exception handlers (all
implementations of functions are partial because the state of the
underlying software/hardware can not be known, and this environment
constitutes part of the input to the function, thus making any 'total'
function partial, as some of its inputs are implied). 

I beg to differ. "Exceptions" aren't just techniques to handle errors in
input, output or computation. Exceptions are exactly that, exceptions.
The reason 'exception handlers' aren't called 'error trappers' is
because they don't just trap errors.

If one has a routine to search a list from a given position for a
paricular value one could implement this algorithm:


(pseudo-code)
search( this, for, from )
{
  if from < this.LowerBounds or from > this.UpperBounds
    return -1
  i := from
  while ( i < this.UpperBound)
    if ( this[i] = for )
      return i
  loop
  return -1
}

This has all sorts of problems. Uglyness is just one of them. However,
without exceptions and attempt to tidy it up would just make it longer,
and uglier.

With exception handling:

search( this, for, from )
  try
    i := from
    while ( this[i] != for )
    loop
    return i
  except
    return -1
end

Ok, this does enforce the precondition that FROM has to be within the
bounds of the list. But this is just a side effect, and could be made
explicit with a comment, or even a condition statement, or an assertion.
The main point is that the general rule is to itterate the list, and to
find the required item. That is what this routine does. If something
unusual happens, such as the item not being in the list, then an
exceptional situation has arrisen. Perfect.

This is of course not a perfect example, better ones could be found. It
could, and probably will, be argued that a search routine generally has
as good a chance of failing as succeeding. That is irrelevant. The point
is that exceptions to general processing should be handled by exception
handlers.

As to the question of an exception being an object. I have done some
research on this. It was proposed by my supervisor Dr Carl Bamford that
a new interface be added to the class structure, to augment the Public
and Private interfaces that are generally accepted by the C++
fraternity. This is an exception interface, to which exception handling
classes could be bolted. This was a method by which information and
control from exceptions could be gained.

-- 
Bryan Dollery.
MD ByteSmart Systems Ltd.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>The obvious and correct solution is to make the name of the procedure
>dynamically scoped; then it can be redefined whenever this is needed.

Yes, it is well known that exception handling can be modeled as
dynamically-scoped procedure names.  And you explained that quite
clearly.  What is not clear (to me) is why you think that way of doing
things is so much better.

>Thus:
>
>* an exception is a fact, not an object;
>
>* the fact is the absence of a suitable 'else' somewhere when it should
>  be there;

Why "should be"?  What's wrong with partial functions?  I mean, it seems
perfectly reasonable to define "square root" such that negative numbers
don't have square roots.  Other definitions are possible (e.g. complex
numbers), but this definition is certainly a reasonable one.

>Finally, recovery from an exception may involve non local control
>transfers out of the procedure that handles the exception; but this is
>an entirely separate issue. It need not be the case.

It is almost always the case.

>So, basically *everything* is wrong (and clumsily so) with the ``C++''
>exception-as-object system:
>
>* the name of the exception class should be that of a dynamically scoped
>  procedure.
>
>* an exception object is really just a clumsy and silly way of
>  specifying an argument list to that dynamically scoped procedure.

You use words like "clumsy" and "silly", but you don't back them up with
real arguments very well.

>* non local control transfers are then mandatory.

This seems OK to me (see below).

>Consider the stark contrast between (in some language reminiscent of
>``C++''):
[example snipped]
>and
[C++ example snipped]

>As you can see the second solution is really just a clumsy, misleading,
>limited version of the first.

Sorry, but no, I can't see that.  They look more-or-less the same to me.
Here are some pieces of your example:

>    try { printf("%f\n",sqrt(-2.0)); }
>    catch(sqrt_neg_arg &sna)
>    {
>      // cannot just return 0.0 -- too bad.
>      puts("0.0"); // not really what we wanted
>    }

Why "not really what we wanted"?  If the goal is to "print out the
square root of the number, but if its negative, print 0.0", then the
above code seems to do that pretty clearly.  In your "fluid" example, on
the other hand, you trick the sqrt function into returning a bogus value
for a negative argument -- this doesn't seem clearer to me.

Alternatively, if you really want a sqrt function that returns zero for
negative arguments, why not write a wrapper function, which calls sqrt,
and has an exception handler saying "return 0.0"?  This is what you need
to do anyway, in the general case -- suppose I want to have square root
of a negative number return a complex number?  Well, I need a wrapper
function, since this new functionality has a different result type from
your sqrt, which returns a float.

But in any case, you normally don't want to print "0.0" for the square
root of -2 -- you want to print an error message, or do something else
entirely different, as in the next case:

>    try { printf("%f\n",sqrt(-2.0)); }
>    catch(sqrt_neg_arg &sna)
>    {
>      fprintf(stderr,"panic: negative arg to 'sqrt': %f\n",sna.f);
>      abort();
>    }

I claim that this is the sort of thing you usually want to do when you
handle an exception -- do something entirely different, and not just
pretend that all is well.  And your "fluid" example doesn't seem to do
this any better.

(Of course *most* exceptions aren't handled at all -- they're simply
bugs in the program, and you want to get rid of bugs before your
customers see them.  For this case, the value of an exception is just in
pinpointing the error, for ease of debugging.)

>Note that in effect in ``C++'' the 'fluid' storage class that turns a
>variable into a dynamically scoped one is pretty easy to simulate (in
>the shallow binding way) using constructors/destructors:
[example snipped]
>which seems rather legible, vastly more flexible/reasonable than the
>convoluted and limiting current ``C++'' syntax.

Again, why do you think this is better than using C++ exception
handling?

I'm reading this on comp.lang.ada, and Ada is a multi-threaded
language.  Your simulation of dynamic scoping doesn't quite work in a
multi-threaded environment.  You need to make the function pointer into
per-task data.

Note that this simulated dynamic scoping is likely to be much less
efficient than a (good) implementation of exception handling.  Exception
handling can (and should) be implemented using a PC-table-lookup
strategy, which makes it near-zero overhead to enter an exception-
handled region.

>Now there is completely orthogonal problem of non local control
>transfers, which might well be useful in a procedure implementation that
>``handles'' an exception. In the above code snippets an example of the
>use of non local control transfers is the call to 'abort()', which exits
>the current process and transfers control back to the invoking process;
>one could use 'setjmp()' or 'longjmp()', or something better, for finer
>grained control transfers.

A goto statement is what you want, but you want to goto an outer
procedure -- this is allowed in Pascal, for example.  And you want
nested procedures, of course.  (Of course, you can't use the word "goto"
in the name of a feature, or people will think you're evil.  On the
other hand, you can have a feature with semantics similar to goto, and
people will be perfectly happy -- so long as you don't call it goto.)

>It is a pity that the ``C++'' exception handling features tie so
>intimately together the distinct concepts of dynamically scoped
>identifiers (and then they are provided in a rather clumsy form) and of
>non local control transfers (and then they are also provided in a rather
>clumsy form).

OK, I guess I can see part of what you're saying: dynamic scoping and
non-local gotos ought to be two separate language features, each usable
in its own right, rather than combining them into a single feature
(exception handling).  (The "clumsy" doesn't add much to your argument,
since you don't really say what's so clumsy.)  Is this it?  I guess
there's some merit in that -- I like orthogonality.  Other than this, I
can't see any advantage of your scheme.

One advantage of the exceptions-as-objects viewpoint is that you can
have a hierarchy of exception classes.  This allows the call site to
determine the granularity of the exceptions to be handled.  E.g. handle
any I/O exception, or handle just the end-of-file exception, or handle
*all* exceptions.  This seems like a valuable capability, and I don't
see any way to do it in your "fluid" language.  E.g., suppose I want to
say, in the main program, "If I get *any* exception, send a signal to
the so-and-so device, telling it to shut down, and then I want to kill
the program"?

Another issue is efficiency:  I don't see any way to implement your
"fluid" feature with near-zero overhead on entering and leaving the
scope of a fluid object.  Exception handlers can be implemented
efficiently, because upon entering the scope of the handler, you can
know at compile time the address of the handler.  With fluid variables,
how do I know (at the original declaration point) that somebody won't
make a binding to some dynamic value?

Another issue is stack overflow: In Ada, if the stack overflows, you get
a Storage_Error exception.  The exception handler is executing *after*
chopping back the stack (i.e. after doing the non-local goto), so the
handler can reasonably do some work.  In your scheme, the handler is a
function, which is called while the stack is still "full".  You need
some way of ensuring that this function has enough stack space to do its
job -- perhaps hold a little bit of stack space "in reserve", so the
function can at least do a non-local goto.  This is easier in the Ada
case, since the only such function is the run-time system's
Raise_Exception procedure, which the compiler can know about.

I realize this is irrelevant to C++, where you can't even *try* to
handle stack overflows.

>  As to this, I rememjber reading someone stating that as far as he knew
>  only TECO (yes, TECO!) of most languages around provides general clean
>  entry/exit scope functions/triggers. Ah well.

What are "entry/exit scope functions/triggers".  (I don't know much
about TECO, except that it is terse to the point of looking like line
noise.)

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <32e9e445.163056932@library.airnews.net>,
Ronald E Jeffries <jeffries@ic.net> wrote:
>In a project I'm presently working on, the input routines try to
>handle all the errors.  Then when the application definers decided
>what kind of notifications they wanted on input errors, we had to go
>in and edit the input routines and change them all around to get the
>job done.  Had they just thrown an exception, we could have fielded
>the exception where we wanted to, and filed our notifications and gone
>on.

But this is true in Mr. Grandi's scheme, too.  Instead of raising an
exception, Mr. Grandi calls a function to handle the error.  And that
function is *dynamically scoped*, which means that the call site can
define it.  Just like the call site defines the handler code in the C++
or Ada way of doing things.

What you say above is the whole point of exceptions -- one piece of code
detects an error, and a different piece of code decides what to do about
it.  And Mr. Grandi's scheme is just as good as the C++/Ada scheme, in
this regard.  (I'm not sure why Mr. Grandi thinks his scheme is so
vastly superior, though.)

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>The obvious and correct solution is to make the name of the procedure
>dynamically scoped; then it can be redefined whenever this is needed.

How about this: The exception-handler is a procedure that is passed to
the procedure that detects the error.  So, in your sqrt example, the
sqrt function would take a Float parameter, and a function to call in
case the Float is negative.  This is essentially how Smalltalk does
things.  If you allow defaults on parameters, then you can make the
default handler be "print out a message and kill the program" or "enter
the debugger" or whatever.  So callers only have to worry about it if
they want to do something special on sqrt(negative).

Is this not pretty much equivalent to your dynamic-scoping scheme?
And it has the advantage that the relevant information is in the
specification of the procedure that wants to "raise" the exception.

- Bob

Re: OO, C++, and something much better!

[David N. Smith]

In article <c0.9w.2DpS6R$08e@craftedsmalltalk.com> ,
traymond@craftedsmalltalk.com writes:
>Sure, smalltalk programmers can index into the wrong array.

Just an aside, but Smalltalk programmers index arrays much less often
than C++ programmers for two reasons:

(1) Smalltalk supports a nice set of other collections; arrays are not
used as often because better collections exist. Many of these do not even
allow indexing.

(2) Smalltalk programmers use various kinds of 'iterators' in which
Smalltalk does the iteration. I always look at places where I have to
hand index a collection as a place where I've probably not done things
right. It's a red (or at least orange) flag.

Dave

_____________________________________________
David N. Smith
IBM T J Watson Research Center, Hawthorne, NY
Mailto: dnsmith@watson.ibm.com
Home Page: http://www.dnsmith.com/
_____________________________________________
Any opinions or recommendations are those 
of the author and not of his employer.

Re: OO, C++, and something much better!

[Joachim Durchholz]

Ed wrote:

> >  What makes you
> > think that the ``superb debugging facilities'' are going to be at the
> > installation site?
> Because they are <g> The walkback trace is also available in the runtime
> system.

I don't buy that.
Well, yes, technically, the debugging facilities may be present. But they  
may at well be not present - or would you let the end user correct the  
code?

Regards,
-Joachim

--
Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

Re: OO, C++, and something much better!

[Damon Feldman]

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


Tansel, (tansel@rase.com) said:

>There is a big debate about importance of type checking in object
>oriented systems. We have one camp religiously defending type checking,
>and another group defending unnecessity of it. There is a merit in both
>sides� arguments.

Clearly.  Perhaps we can stop bickering long enough to do something 
productive.  How hard could it be to write a type-free interpreter in a 
staticly - typed language?  This would allow static typing where possible
and dynamic binding where truely necessary.

Since any OO-lang already supports inheritance, polymorphism, etc. the 
interpretation proces shouldn't be too hard because it can steal these 
features from the underlying language (hopefully).

Off the top of my head, you'd need a root class for everything (or at least an 
interface), call it "Object", and it would have to support a perform: method.  
This could perhaps be done in C++ most easily since you can pass functions 
around so easily.  In a better language it would be harder, though (e.g. a 
language without crazy unchecked pointers floating around everywhere).

Since the compiler wants to know that a function call is legit at compile 
time, you might have to type in a dictionary of calls to be looked up by 
method name at runtime.  Each call would be statically well-typed, but the 
lookup mechanism could take the method name and args as strings to be checked 
at runtime to see if the method names are in the lookup dictionary (and 
would generate a "does not understand" message if the desired function was not 
there).

The downside to this scheme (if it would work at all) is that it requires us 
to define all methods that might be called via the "perform" hack, above, in 
these dictionaries -- one for each class.

Or is that a FEATURE!?

Maybe someone has something slicker/easier?

>> Regards,
>> -Joachim

>Kindest Regards
>Tansel

Obsequious regards,
Damon

Re: OO, C++, and something much better!

[Eric Clayberg]

Jon S Anthony wrote:
> > The simplicity and consistency of the language drastically reduces
> > the scenarios where a real type error would occur. On those rare
> 
> Baloney.

Only to those who have never used it in a commercial situation. You
might want to try it first before blindly criticizing it.

> Irrelevant in a fielded piece of software.

Hey, where I come from, we actually *test* our software *before* we
deploy it.

> Hey, ST is nice - just don't make out that its dynamic typing is as
> safe as a statically checked strongly typed language in high
> reliability scenarios.

Baloney (back at you). There hasn't been a shred of proof presented here
that supports that supposition. Do you have any? Where is your proof
that apps built in statically typed languages are more reliable that
dynamically typed languages? Where is your proof that Smalltalk in
particular is anything less than ideal for high reliability scenarios? I
have seen dozens of Smalltalk apps working flawlessly in exactly that
kind of scenario.

-Eric

Re: OO, C++, and something much better!

[Eric Clayberg]

Robb Nebbe wrote:
> Obviously the lack of static typing in Smalltalk does not make it unsuitable
> for software development, a fact that some people (probably those who have
> never programmed in Smalltalk) seem to have trouble grasping.

Yes, that is a common problem.

> However, dynamic typing is mostly a stop-gap measure since static type
> systems aren't quite up to snuff yet. I expect static type systems to
> steadily improve until there is no longer any reasonable justification
> for dynamic typing but we aren't there yet in my opinion.

I doubt that will ever happen or whether it is even a desirable goal to
begin with. I don't see dynamic typing as a stop-gap measure at all.
Rather, I see it as a very valuable and valid approach to software
development.

-Eric

Re: OO, C++, and something much better!

[Eric Clayberg]

Joachim Durchholz wrote:
> Well, dynamic typing isn't the only problem about Smalltalk. There's some
> efficiency problems, and it's difficult to strip a program to its
> essential components for distribution.

There is quite a lot of work being done in the Smalltalk industry to
correct some these deficiencies. There are technologies becoming
available in the Smalltalk world that should boost performance of
Smalltalk systems by 3.5-5X or more (see http://www.animorphic.com for
one example). Some of the newer Smalltalk implementations on the market
(e.g., Smalltalk MT) produce very fast native code. All of the major
vendors are working at dramatically improving their distribution
technologies (like ParcPlace's SLL and Firewall technology or IBM's
forthcoming IC technology).

-Eric

Re: OO, C++, and something much better!

[Eric Clayberg]

Matt Kennel wrote:
> A static type langauge need not be manifestly typed everywhere (programmer
> putting specific written type annotations on all variables); a small
> dose of type inference substantially increases the "prototypability" and
> elides lots of stupid 'search-n-replace' busywork found in dumber static
> languages.

See the discussion of StrongTalk
(http://www.animorphic.com/oopsla96-ws/types-proposal/nwst.html) for an
example of how this can be done optionally with Smalltalk.

-Eric

Re: OO, C++, and something much better!

[Eric Clayberg]

Claus Reinke wrote:
> Using dynamic typing as the default and static type inference 
> as an additional program analysis should not harm anyone.

Agreed. 

> IMHO, completely static systems are not reasonable because 
> of the severe restrictions they impose on the language

Agreed.

> Sorry, but you should definitely *not* base your conclusions about
> statically typed languages on C,C++,Fortran, etc.

Fair enough. I will base my conclusions about C++ based on C++. ;-)

> Try something like Standard ML or Haskell

When I get the time, I would like to. Are either commercially available?
If so, where? What about free versions? Thanks.

-Eric

Re: OO, C++, and something much better!

[Fergus Henderson]

Tansel Ersavas <tansel@rase.com> writes:

>Fergus Henderson wrote:
>> 
>> Alan Lovejoy <alovejoy@concentric.net> writes:
>> 
>> >dynamic typing results in signficantly faster development time.
>> 
>> That is highly debatable.  My experience is that static typing results
>> in faster development time.
>
>What is highly debatable? I have used C++ for a long time and now I am 
>using Smalltalk, and there is NO comparison in development times. They
>are simply different categories. Turtle vs. Rabbit.

"Dynamic typing vs static typing" is not the same debate as
"Smalltalk vs C++".

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32E68D40.65EC@parcplace.com> Eric Clayberg <clayberg@parcplace.com> writes:

> What about if your program crashed because you tried to address a null
> pointer? Does this mean you shouldn't use C or C++?

Yes.  1/2 :-)


> Almost all "message not understood" errors are simply messages sent
> to nil (the moral equivalent of a null pointer).

This doesn't seem much better...


> This usually happens either when something isn't initialized yet or
> it has been prematurely released - certainly mot uncommon
> occurrences in the static typing world.

For non dispatched operations in a statically typed language with
strong typing, this would not happen.  For dispatched operations in
such a language, it would be an unusual circumstance.


> Real type errors (e.g., those that a static typing system would
> actually catch) rarely ever occur in Smalltalk.

Huh?  You clearly have a rather limited view of strong static typing.
What you are really saying is that weak static typing provides little
structure (your "real type error").  So what?  Static and dynamic are
orthogonal to whether the type system is highly expressive and
strongly enforced.


> The simplicity and consistency of the language drastically reduces
> the scenarios where a real type error would occur. On those rare

Baloney.


> occasions where a type error does occur, Smalltalk's excellent
> debugging facilities make them very easy to correct.

Irrelevant in a fielded piece of software.  Invoking a debugger for a
type error is not particularly useful while your assembly line grinds
to a halt or otherwise chews up prodigious resources while you call in
the developers to have a look at the "debugging screen".

 
> But rather that guess about Smalltalk, why not give a try and see for
> yourself? You can download Smalltalk Express (a fully functional 16-bit
> Windows Smalltalk IDE) for free from http://www.objectshare.com.

Hey, ST is nice - just don't make out that its dynamic typing is as
safe as a statically checked strongly typed language in high
reliability scenarios.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Tansel Ersavas]

Norman H. Cohen wrote:

> I mentioned the securities industry specifically because Alan Lovejoy
> had brought up the use of Smalltalk in that industry.  This industry has
> perceived that Smalltalk speeds deployment of software, but I suspect
> that few realize that this is accomplished by deferring the detection of
> some errors until after deployment!  The appropriate comparison here is
> not to C++ (an error-prone language whose supposedly strong typing
> system is too weak to catch many of the errors that language fosters),
> but to a safety-oriented language such as Ada.  Given the potential
> financial impact of an incorrect program, people in this industry ought
> to demand the same protection against programming errors that purchasers
> of safety-critical software demand.

As you rightly point out, there are many errors in some statically typed
languages such as C++ that would be deferred till execution such as
dangling pointers that require sophisticated tools to identify them at
run-time, so just being statically typed is not a guarantee. 

In Smalltalk, I am internally testing a tool that captures and embeds
type checking automatically during development, and strips that
information when you request. This way I can actually apply not only
type checking, but few other checks that increase reliability
dramatically, while not compromising flexibility. For instance I can
check the validity of interface for potential candidates (not
necessarily inherited from the same class) of a hetorogeneous collection
which will allow me to have a hetorogeneous collection with the
knowledge that everything I keep in that collection has a valid
interface. If I encounter a special problem, I as an individual can add
specific diagnostics for this type of problem so easily to my suite of
problem detection tools. These facilities are like extending the
language.
And you can never do things in Ada to increase flexibility dramatically. 

> Then again, I suppose they wouldn't be in the securities industry if
> they didn't enjoy high-stakes gambles. :-)

Then again, I suppose that paraniod Ada crippled by these concerns is
mostly used by the defence industry where perceived correctness is
paramount at any price. People can use Ada where the business is killing
the right people, but, thanks, I'll use languages such as Smalltalk and
Self, and I know that I can make them as secure as possible if I want
to.

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: OO, C++, and something much better!

[Fergus Henderson]

Eric Clayberg <clayberg@parcplace.com> writes:

>Claus Reinke wrote:
>> Try something like Standard ML or Haskell
>
>When I get the time, I would like to. Are either commercially available?
>If so, where? What about free versions? Thanks.

There are several free implementations of Haskell, including an
interactive environment aimed at quick development (Hugs) as well as
optimizing compilers that generate native code (e.g. ghc).  See
<http://carol.fwi.uva.nl/~jon/func.html> for some pointers.
I don't think there are any commercial implementations.

Regarding SML, try the comp.lang.ml FAQ list.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Lawrence G. Mayka]

Eric Clayberg <clayberg@parcplace.com> wrote:

>Claus Reinke wrote:

>> Try something like Standard ML or Haskell

>When I get the time, I would like to. Are either commercially available?
>If so, where? What about free versions? Thanks.

Harlequin Inc. (http://www.harlequin.com) advertises a commercial
implementation of the 1996 version of Standard ML, a.k.a. SML.  See in
particular http://www.harlequin.com/mlworks/Welcome.html.  You can
apparently download an evaluation copy.

I know Harlequin primarily from their commercial implementations of
ANSI Common Lisp (a.k.a. CLOS), a dynamic object-oriented language
that is in many ways technically superior to Smalltalk.  (I've
programmed in Smalltalk for 6 months now.  Prior to that I programmed
in CLOS for 8 years, and before that in C++ for 4 years.)  Harlequin
is also apparently in the final stages of developing a commercial
implementation of Dylan, the dynamic object-oriented language that
Apple once championed.

Links to all of Harlequin's symbolic processing products appear on
http://www.harlequin.com/full/products/Welcome.html.

I have no affiliation with Harlequin other than as a satisfied
customer (actually not any more, since I write in exclusively in
Smalltalk now, for various reasons).


Lawrence G. Mayka
lgmayka@sprynet.com

Re: OO, C++, and something much better!

[Tansel Ersavas]

Joachim Durchholz wrote:
> 
> Tansel wrote:
> 
> > Contrary to what people say, type checking is against the nature of
> > object oriented systems development. Remember, in OO, we only care about
> > the interface of the other object. In fact it should be an OO sin to ask
> > the type, because, in theory, we don�t want to get intimate with objects
> > we are interacting apart from their interface. We only want to know the
> > interface.
> 
> There's a misunderstanding here.
> 
> I agree checking should be done on the interface, but I was not aware of
> any difference between type and interface. After all, objects with
> identical interface have the same type for all practical purposes.
> 

For practical purposes type checking in statically typed languages
involve
both structure and the interface. This doesn't take into consideration
that
part of the structure may be private. There are notable exceptions
though


...

> A good type-checking Smalltalk system could work with versioning, so if
> you delete a routine, you actually define a new class with the routine
> deleted. Existing (typechecked) code would continue to work. Of course the
> system should convert as much as possible to the new version of the class
> structure, but if it finds code that uses the delete routine, the
> programmer has to correct it (or the code has to remain on the old version
> level).

Good point. There are still ways to bypass these in run-time though.
 
...
 
> > Why don't you come to Smalltalk Solutions 97? You may see many examples.
> > It is in NY at Marriot Marquis between March 10-13.
> 
> Sorry, that's a bit far from Germany... (domain .de is short for
> "Deutschland").

Ooops, sorry. I didn't notice. 
 
> > This is not true. Smalltalk base is growing very strongly especially in
> > organizations such as banks.
> 
> I didn't want to downplay the growth of Smalltalk. It's just that the
> numbers presented were nearly content-free. I'd very much like to see some
> solid numbers, though.

InfoWorld and IDC are publishing such numbers. If I come across some, I
might 
collect and post them at one stage.
 
> Regards,
> -Joachim
Kind Regards

Tansel 
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: OO, C++, and something much better!

[Robert Dewar]

Alan says

"So then, why have so many investment banks adopted Smalltalk as the language
of choice for doing securities trading applications?  The reason typically
given is that development speed in Smalltalk is so much faster--which boils
down to big bucks on the trading floor.  Could the financial people be wrong?"


Of course they could .. I know of one major catastrophe in attempting to
use Smalltalk for a large financial application -- which ended up costing
a huge amount of money ....

If you assume that popularity is necessarily related to technical
soundness, no doubt you think that MSDOS was a perfect operating
system, and that Lots 1-2-3 macro language is the best programming
language!

Re: OO, C++, and something much better!

[Robert Dewar]

iAlan said

"So then, why have so many investment banks adopted Smalltalk as the language
of choice for doing securities trading applications?  The reason typically
given is that development speed in Smalltalk is so much faster--which boils
down to big bucks on the trading floor.  Could the financial people be wrong?"


Note incidentally that these "financial people" in whom Alan has so much
trust are the folks who have brought you the multi-billion $ Y2K disaster!

Re: OO, C++, and something much better!

[James O'Connor]

Joachim Durchholz wrote:
> 
> Tansel wrote:
> 
> > Contrary to what people say, type checking is against the nature of
> > object oriented systems development. Remember, in OO, we only care about
> > the interface of the other object. In fact it should be an OO sin to ask
> > the type, because, in theory, we don�t want to get intimate with objects
> > we are interacting apart from their interface. We only want to know the
> > interface.
> 
> There's a misunderstanding here.
> 
> I agree checking should be done on the interface, but I was not aware of
> any difference between type and interface. After all, objects with
> identical interface have the same type for all practical purposes.

There are subtle differences between 'type', 'interface', and 'class'
and the terms get used somewhat interchangebly around here.  Java, for
example uses two separate constructs; Class (defining an interface and
and implementations) and Interface (describing only an interface). 
Ada95 (I think) uses the term type to mean a type of data tructure, the
type-and-package become what others call a class and the term 'Class'
means a family of types (I think this is right...).  Smalltalk uses the
term 'class' to mean a class and the term 'type' to mean providing or
describing a certain interface.  However even type and interface are not
interchangble.  In Java, two objects that happen to share the same set
of method signatures are not the same 'type' unless the inherit from a
common base Class or base Interface.  However, in Smalltalk, two objects
that share the same set of method signatures are considered of the same
'type' regardless of class membership.
> 
> > ATD based languages because of language structure. In languages such as
> > Smalltalk, on the other hand, even knowing the type of an object is not
> > a guarantee that this object will answer a method that we use, because
> > we can really delete any method for that object while the system is in
> > operation, so even type checking is not a perfect solution.
> 
> A good type-checking Smalltalk system could work with versioning, so if
> you delete a routine, you actually define a new class with the routine
> deleted. Existing (typechecked) code would continue to work. Of course the
> system should convert as much as possible to the new version of the class
> structure, but if it finds code that uses the delete routine, the
> programmer has to correct it (or the code has to remain on the old version
> level).
> 
Deleting methods on the fly isn't very common.  But delegation is, I
believe.  If you use the #doesNotUnderstand: aMessage delagation
approach, than knowing the claass of an object may not tell you whether
a particular message send will work.

> > Disadvantages? Many.
> 
> Thanks for the info. This type of stuff is tremendous help in seeing
> beyond all the hype.
> 
> > For starters, most Smalltalks and their tools are ridiculously
> > expensive. This is equivalent for the vendors to shooting themselves in
> > the foot, at the same time hitting us with the richocet.
> 
> Seems to be a general problem. Obviously this is one of the worst market
> barriers for new languages: Market is small, so prices have to be high to
> make a living from them, so market remains small.
> On the other hand, this has saved us from countless language wars, so
> maybe this vicious circle is a godsend...

I think this is coming around.  PPD has Smalltalk Express.  I know both
Dolphin (http://www.intuitive.co.uk) and SmalltalkMT
(http://www.objectconnect.com) have very low priced Smalltalk products
in the works.  Dolphin intriques me because of the Smalltalk Applet
plug-in available.  SmalltalkMT looks cool because it produces very
small, fast executables.

> 
> > Why don't you come to Smalltalk Solutions 97? You may see many examples.
> > It is in NY at Marriot Marquis between March 10-13.
> 
> Sorry, that's a bit far from Germany... (domain .de is short for
> "Deutschland").
> 
> > This is not true. Smalltalk base is growing very strongly especially in
> > organizations such as banks.
> 
> I didn't want to downplay the growth of Smalltalk. It's just that the
> numbers presented were nearly content-free. I'd very much like to see some
> solid numbers, though.
> 
> Regards,
> -Joachim
> 
> --
> Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

-- 
James O'Connor 
--------------------------------------
joconnor@jmpstart.com
http://www.jmpstart.com
--------------------------------------

Re: OO, C++, and something much better!

[Robert A Duff]

In article <32E987FC.1FF2@rase.com>, Tansel Ersavas  <tansel@rase.com> wrote:
>What is highly debatable? I have used C++ for a long time and now I am 
>using Smalltalk, and there is NO comparison in development times. They
>are simply different categories. Turtle vs. Rabbit.

I don't doubt it.  But why do attribute this difference to
static-vs-dynamic typing?  Maybe it's caused by having garbage
collection, or having a better predefined library, or having better
debugging tools, or the confusing syntax of type definitions in C++, or
the confusion between arrays and pointers in C++, or any number of other
things.

- Bob

Re: OO, C++, and something much better!

[Robert Dewar]

Andy says

"Perhaps an even more amusing trial, to embarass those used to
languages that rely soley on fixed size integer and floating point
arithmetic, is  to use Smalltalk to calculate the largest known prime
number. To do so, evaluate:"

Actually the approach in Smalltalk is rather simplistic. For a more 
interesting approach to multi-precision arithmetic, have a look at
ABC, which can, in a sense compute in infinite precision using continued
fractions. For example, you can trivially write a program which will print
digits of pi, and watch it printing them, and let it print as many as
you want. The program to do this is just a few lines long.

Information on ABC should be locatable at CWI in Amsterdam (chief architect
is Lambert Meertens).

Re: OO, C++, and something much better!

[Robert Dewar]

"Perhaps an even more amusing trial, to embarass those used to
languages that rely soley on fixed size integer and floating point
arithmetic, is  to use Smalltalk to calculate the largest known prime
number. To do so, evaluate:"


Incidentally I don't know why anyone should be embarrassed by having
integer types with limits. There are many advantages, both in efficiency
and from the point of view of enforcing invariants in having types with
well defined ranges. 

An interesting P.S. for the Ada folks reading this (like so many
messages today, this thread is cross-posted to a whole bunch of language
groups -- we really need a separate group for this rambling stuff on
languages -- an inordinate amount of which is rambling by people who
clearly know very little about language design -- anyway back to Ada.

In Ada 95, the type Integer'Base is an unconstrained type. An implementation
is allowed, BUT NOT REQUIRED, to limit the range of values of this type that
it will handle, so it is quite permissible to use multiple precision for
this type. This would be nicer than introducing a new type, since Ada, like
nearly all other languages, has trouble introducing general literals for
new types, so if you use Integer'Base this way, you also get arbitrary
precision literals.

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "bertrand" == Bertrand Meyer <bertrand@eiffel.com> writes:


Chris> ISE Eiffel does give the user a degree of parameterization: a
Chris> compilation option specifies the size threshold beyond which a
Chris> routine will not be inlined.

Bertrand> Most users are happy with the
Bertrand> default, which inlines small, frequently called routines.

Chris> How on earth does the compiler know if a routine is "frequently
Chris> called"?

bertrand> Sorry, sloppy wording on my part. I meant "called from many
bertrand> different places in the code", which does tend to correlate
bertrand> with the numbers of times the routine will be called, although
bertrand> of course this is not always true (as with a routine that is
bertrand> called from just one place, but that place is in a loop). Just
bertrand> one criterion among others. Thanks for noting the incongruity
bertrand> in my original message.

So it is the number of static invocations rather than dynamic calls.

However it is often possible and actually rather easy to estimate
dynamic call frequency in a compiler; usually by propagating loop
repetition estimates across procedur boundaries, which is not that
hard. Loop repetition estimates are actually often surprisingly easy, as
a few loops have statically known repetition counts, and for the others
assuming a notional repetition count (something like 10) often gives
suprisingly good results (I remember reading this in somebody's work, I
think the author of PCCTS, but I am not sure).

Re: What is wrong with OO ?

[Sean Case]

In article <E413nz.9IA@research.att.com>,
bs@research.att.com (Bjarne Stroustrup) wrote:

>I think that if C++ was as hard to understand and use as some people claim,
>it would have failed to become popular in the first place and would have
>vanished under the continuous barrage of fair and unfair criticism - despite
>its (eventual) popularity.

and also

>I have often found myself wondering if the C++ wouldn't have been much better
>for all concered had there (just) been two dozen good C++ books instead of
>the 400+ books that mostly fail to teach the basic principles and mostly
>lead students and programmers astray.

So, C++ must be easy to learn, or else there wouldn't be hundreds of books
about it by people who don't understand it properly.

Or, to put it another way, C++ looks easy to learn, but has hidden pitfalls
that bedevil even those who write books on the subject.

Sean Case


---------------------------------------------
Sean Case                  gscase@tpgi.com.au

Code is an illusion. Only assertions are real.

Re: What is wrong with OO ?

[William Grosso]

On Sun, 26 Jan 1997 16:09:42 +1100, gscase@tpgi.com.au (Sean Case)
wrote:
>
>So, C++ must be easy to learn, or else there wouldn't be hundreds of books
>about it by people who don't understand it properly.
>
>Or, to put it another way, C++ looks easy to learn, but has hidden pitfalls
>that bedevil even those who write books on the subject.
>

Or, to put it another way, lots of crappy books have been written on 
C++ because people who don't know much about it have decided
to demonstrate their ignorance (and make a quick buck or two). 

Why this reflects on C++ rather than the authors is pretty much a 
mystery to me. 


Cheers,

Andy
"In the beginning, everything was even money"
       --Mike Caro

Re: OO, C++, and something much better!

[TanselErsavas]

Robert Dewar wrote:
> 

> Robert replies
> 
> The danger is that the "test everything as-you-go" style degrades into
> "design everything as-you-go", which is tempting for fast development,
> and is even appropriate for certain kinds of prototyping, but is a
> complete disaster for generating large scale reliable software, as has
> been proved over and over again by experience.

This is not a fact. I have been involved in large projects which used
"incremental testing" that were quite successful. This depends on who is
attempting it, and what tools and techniques they use. On the contrary,
I use an approach which I call "conception-evolution" that is an
advanced and formalized evolutionary prototyping technique similar to
the ones you claim to cause disaster, which I am yet to see. Discrete
steps of waterfall has long gone, and this applies to parts of testing
as well. The problem with prototyping approaches is that they are not
formally disciplined, and they mainly concantrate on the user interface
which in some systems only the tip of the iceberg. If you can prototype
the entire system using formal diagramming techniques and a disciplined
approach, then you are much more likely to identify problems much
earlier.

The key to develop succesful systems is iteration. No one can claim that
with careful planning and analysis they can come up with the ideal
system in one shot. With most of the available inflexible languages,
tools and development environments it is not practical to modify systems
once a big chunk of them is developed. However with languages such as
Smalltalk and a new breed of tools, this will be very possible in the
near future. Our company is working on one such tool right now, and
there are others.

> "is there any other environment"
> 
> Yes, of course, this kind of dynamic environment is common. Many Basic
> systems share this kind of flexibility. APL and ABC come to mind
> immediately, but there are many others. This is actually more a matter
> of implementation style than languagde design, though in some cases
> language designs facilitate this kind of dynamic approach.
>
> You can even provide this kind of dynamic development envrionment with
> languages like C, using incremental compialtion and fix-and-continue.
>

It is true that interpretation and dynamic environments are
implementation styles. As you say some languages are much more suitable
for this than some others. I am sorry that you have to mention Basic and
a lot of people will have to use it, just because it happens to be the
favorite of "you know who", otherwise it wouldn't have had the place it
has Today.

Coming to intrepretive style of Smalltalk and Smalltalk like languages,
they are made for this style. It is much more easier and natural to
implement Smalltalk as is, while it requires a considerable amount of
time and effort to come up with one for C. For that reason Smalltalk
based environments are being increasingly used for other languages. A
typical example is VisualAge suite. 
BTW there are entire languages and environments, for instance the PC
version of the latest version of the LINC suite of Unisys, developed in
Smalltalk. There are also a few Lisp implementations. It would be
trivial to build a C or a Pascal interpreter, although I don't see much
reason for it. Squeak group is actually discussing support for other
languages to attract other developers to Squeak environment. They are
very aware that most other languages have no chance to compete with a
Smalltalk like language in the long term and they have an advantage of
being able to distribute it free even for commercial uses.

> But once again, this kind of dynamic environment can be very dangerous.
> it is the antithesis of the careful approach using formal or semi-formal
> tools that is the key to generaing large scale reliable software. Consider
> for instance the clean room model. I would get that most of those who
> like the highly dynamic style cannot even *imagine* that the clean room
> approach works, let alone that it has been found to be highly effective.

This is not an either-or case. You can have formalizm and formal tools
in a dynamic environment, and once you have them, you'll have such
powers, it will be another dimension in software development. 

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: OO, C++, and something much better!

[Robert Dewar]

Eric says

"Hey, where I come from, we actually *test* our software *before* we
deploy it.

Sounds like you rely on testing to ensure reliability from what you
say, which sounds pretty dubious to many of us! 

Re: OO, C++, and something much better!

[Fergus Henderson]

Alan Lovejoy <alovejoy@concentric.net> writes:

>Fergus Henderson wrote:
>> 
>> Here's a more detailed breakdown.
>
>To which I wish to add some comments and analysis:
>
>>         syntax errors: 16
>>         type errors: 83
>>                 - errors in type declarations: 13
>
>Doesn't apply to Smalltalk.
>
>>                 - type errors other than errors in type declarations: 70
>>                         - syntax related: 14		
>May or may not apply to Smalltalk.  Can't
>tell without more specifics.

I gave some specifics below; these would not apply to Smalltalk.

>>                         - wrong procedure name: 11
>
>The Smalltalk compiler will complain when you compile
>a method that sends a message with no implementors.
>So this would only apply to those cases where the
>"wrong" name matched that of some other method.
>I would assume that all such errors out of 11 would be 
>caught by the Smalltalk compiler (about 99% would be
>caught overall).

Fair enough.

>>                         - wrong constant name: 4
>>                         - wrong variable name: 4
>
>Were these "wrong" names simply undeclared, 
>or declared but wrongly typed?

In the case of the wrong constant names, I didn't record
these distinctions, but my guess is that probably they were
mostly simply undeclared (and hence would have been
detected at compile time in Smalltalk).

In the case of the wrong variable names, it's a little more
complicated.  In Mercury, variables do not need declarations.
Most errors involving variables are caught by either singleton
variable warnings and/or by mode errors (both of these are counted
in the "others" category below).  Three of these four cases caught by
type checking involved using an incorrect name that was also the name
of another variable.  I think they would also have occurred in
Smalltalk (and would not have been deteted until run time).
The fourth case involved trying to use the same name for two different
variables.  I'm not sure whether that one would have occurred in Smalltalk.
I guess it would depend on whether the programmer noticed that there
was already a declaration for that variable.

> How many of the
>"wrongly typed" ones involved type differences
>that don't matter in Smalltalk (ie, long vs. short
>numbers, different types of Collection)?

I doubt if there are any of these sort of errors.
Mercury has a quite simple type system.  
For example, there is only one integer type in Mercury.
Mercury is not C++.

>I will ssume that 
>1 of these 8 errors would cause a Smalltalk program to 
>produce the wrong result or fail (the Smalltalk compiler 
>will catch any undeclared references, and about 92% of type 
>incompatibilities in C++ are cases that will "just work fine"
>at runtime in a Smalltalk program).

As mentioned above, I think that at least 3 of these 8 errors would
occur in Smalltalk and not be caught by the compiler.

>>                         - argument has wrong type: 7
>
>How many of these involved type differences that don't
>matter in Smalltalk?

Probably none of them.

>And how many were caused by the fact
>that the Algol-style function call syntax makes it so easy
>to get the arguments wrong?

Again, probably none of them.

> So I would estimate that of the 83 type errors, only 1 of them would
> show up at runtime in a Smalltalk program.

Well, I think your estimate is wrong.  I would estimate that
11 of them would show up at runtime.

This would more than double the total number of runtime errors.

In addition, I estimate that there are probably another 9 errors in
the "others" category, e.g. uninitialized variable errors, that are
caught by static analysis in the Mercury compiler but which are unlikely
to be caught by Smalltalk compilers.  Furthermore, just as there are
errors that occur only in Mercury, and not in Smalltalk, there are no
doubt many errors that would occur only in Smalltalk, and not in
Mercury.  Obviously such errors aren't included in my list...

> Other advantages of
> Smalltalk would probably eliminate several of those 9 run time errors
> (for example, more abstract code...

I doubt this.  Mercury code is generally very high-level already, and
looking at the nature of the errors, it's hard to see how using a
different language could help avoid all but one of them.

One of the nine errors was caused by incorrect argument order
(it wasn't caught by typechecking since the arguments were both the
same type).  That one might well have been avoided in Smalltalk.

Three were errors in the program's output.
	- omitting the filename on one of the error messages
	- enclosing something in double quotes instead of
	  in singe quotes
	- printing `foo()' rather than `foo' (parentheses
	  should only have been used when there were arguments,
	  but the program printed them even when there were no
	  arguments)

Four were serious semantic errors (logic bugs); these are all too
complicated to explain concisely, but I can't imagine any programming
language feature that would avoid them.

One was a performance bug, caused by using an unnecessarily inefficient
algorithm in the inner loop.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Lawrence G. Mayka]

James O'Connor <joconnor@jmpstart.com> wrote:

>Joachim Durchholz wrote:

>> Tansel wrote:

>> > For starters, most Smalltalks and their tools are ridiculously
>> > expensive. This is equivalent for the vendors to shooting themselves in
>> > the foot, at the same time hitting us with the richocet.

>> Seems to be a general problem. Obviously this is one of the worst market
>> barriers for new languages: Market is small, so prices have to be high to
>> make a living from them, so market remains small.
>> On the other hand, this has saved us from countless language wars, so
>> maybe this vicious circle is a godsend...
>
>I think this is coming around.  PPD has Smalltalk Express.  I know both
>Dolphin (http://www.intuitive.co.uk) and SmalltalkMT
>(http://www.objectconnect.com) have very low priced Smalltalk products
>in the works.  Dolphin intriques me because of the Smalltalk Applet
>plug-in available.  SmalltalkMT looks cool because it produces very
>small, fast executables.

And now Cincom is offering ObjectStudio
(http://www.cincom.com/objectstudio) for less than $100.
ObjectStudio's apparent advantage is that of a full-featured, mature
development environment with full Win32 compliance at the lowest price
of any commercial implementation.


Lawrence G. Mayka
lgmayka@sprynet.com

Re: OO, C++, and something much better!

[Robert Dewar]

Tansel said

">What is highly debatable? I have used C++ for a long time and now I am
>using Smalltalk, and there is NO comparison in development times. They
>are simply different categories. Turtle vs. Rabbit."


Yes, an apt reference to the fable, and I trust you remember who wins the
race between the Tortoise and the Hare (which is the translation of the
Greek I am used to, but I doubt we know precisely what animals Aesop was
describing to this level of detail).

In this case, the reason for the tortoise winning may well be found in
the long term maintenance and life cycle costs. Yes, langauges like
Smalltalk are certainly handy for quick prototyping, but who knows what
the long term life cycle cost effects will be -- answer: no one, because
commercial use of Smalltalk is too new to have more than scattered data.

Again, noticing that Ada is on the list of xpostings, it is interesting to
note that the first Ada translator (Ada/Ed) was written in a dynamically
typed language (SETL -- which is a very high level language oriented around
high level set operations, or more precisely ZF-set operations, where 
general mappings play a critical role. It is a garbage collected langguage
with pure value semantics (e.g. no pointers).

It is indeed a highly effective prototyping language, and allowed us to get
something working quickly. However, in retrospec, we felt one of the big
weaknesses of SETL was precisely the dynamic typing. If your data structures
are such that only an integer makes sense in a particular context, then it
is nice to have this statically checked, instead of letting an accidental
assignment of some incorrect type cause chaos down the road.

These days it is quite entertaining to see a whole new generation of 
programmers introduced for the first time to dynamic typing, but of course
it is not new at all (LISP is almost as old as Fortran), but in my opinion,
anything that the compiler can do for you is valuable. What you will find
programmers saying in the Ada and Alogol-68 worlds is that it is often hard
work to get the program past the compiler, but once past, it works the first
time.

Ada programmers often don't paricularly care about debuggers -- ask a roomful
of Ada programmers whether they find debuggers useful, and maybe half will
say they regard them as critical. By contrast, when I suggested the idea
that debuggers were not that important to Gabriel (of Lisp fame, sorry I
forget his first name) he thought it was a huge joke, the very *idea* that
someone could do without a debugger -- it actually set him laughing :-)

Someone actually posted earlier to this thread the idea that it was pretty
useless to have the compiler verify type invariants, because debugging
would find the errors easily. It is positively scary that there are
programmers around who could say this with a straight face. But then
any exposure to the general community of programmers is a very
frightening experience :-)

Re: OO, C++, and something much better!

[Felix Beer]

feldmand@erols.com (Damon Feldman) wrote:

[...]
> How hard could it be to write a type-free interpreter in a 
>staticly - typed language?  This would allow static typing where possible
>and dynamic binding where truely necessary.
[...]
>Off the top of my head, you'd need a root class for everything (or at least an 
>interface), call it "Object", and it would have to support a perform: method.  
[...]
>Maybe someone has something slicker/easier?
[...]

Sounds like a coarse description of Objective-C to me. You should
really give it a try, it comes along with the GNU compiler.

- Felix

--
Felix Beer                                fbeer@ping.at
Radetzkystr. 36                    fb@aquaconsult.co.at
A-2500 Baden, Austria                    +43 2252 41431

Re: OO, C++, and something much better!

[Bob Haugen]

Robert A Duff wrote:
> 
> In article <32E987FC.1FF2@rase.com>, Tansel Ersavas  <tansel@rase.com> wrote:
> >What is highly debatable? I have used C++ for a long time and now I am
> >using Smalltalk, and there is NO comparison in development times. They
> >are simply different categories. Turtle vs. Rabbit.
> 
> I don't doubt it.  But why do attribute this difference to
> static-vs-dynamic typing?  Maybe it's caused by having garbage
> collection, or having a better predefined library, or having better
> debugging tools, or the confusing syntax of type definitions in C++, or
> the confusion between arrays and pointers in C++, or any number of other
> things.

In my experience, it is all of the above PLUS a dynamic style of 
development that is enabled by dynamic typing.  Here is an attempt to 
describe the style:
Each class, and each method of each class, and even individual statements 
within methods, can be tested immediately from a workspace.  The test 
statements can then be assembled as class methods for regression testing. 
 The class test methods can then be composed into use-case test methods. 
 So you test everything as-you-go, bottom up, without having to create 
test harnesses, stubs, and other administrative trivia.  So you code 
seldom gets out of control.
Lint-style static checks could be included in the above description;  I 
understand some Smalltalk tools are coming on the market to do that.

Is there any other environment (except Lisp) that enables such dynamic 
testing?

Bob Haugen
Nexgen Software

Re: OO, C++, and something much better!

[James O'Connor]

Robert Dewar wrote:
> 
> Alan says
> 
> "So then, why have so many investment banks adopted Smalltalk as the language
> of choice for doing securities trading applications?  The reason typically
> given is that development speed in Smalltalk is so much faster--which boils
> down to big bucks on the trading floor.  Could the financial people be wrong?"
> 
> Of course they could .. I know of one major catastrophe in attempting to
> use Smalltalk for a large financial application -- which ended up costing
> a huge amount of money ....

Curious, was the catastophe because of Smalltalk?  Or because of bad
design/requirements analysis?  I would be more inclined to guess the
later.  Like the Arianne V that blew up awhile back?  Wasn't that
written in Ada?  Was it because it was written in Ada or becuase the
designer made a mistake. I would be inclined to think it was the
designer's fault, not the languages.
> 
> If you assume that popularity is necessarily related to technical
> soundness, no doubt you think that MSDOS was a perfect operating
> system, and that Lots 1-2-3 macro language is the best programming
> language!

I do, however, think that Alan's point is that some big people with a
lot of money and a lot at stake have decided that Smalltalk is a viable
solution for that environment.
-- 
James O'Connor 
--------------------------------------
joconnor@jmpstart.com
http://www.jmpstart.com
--------------------------------------

Re: OO, C++, and something much better!

[James O'Connor]

Lawrence G. Mayka wrote:
> 
> James O'Connor <joconnor@jmpstart.com> wrote:
> 
> >Joachim Durchholz wrote:
> 
> >> Tansel wrote:
> 
> >> > For starters, most Smalltalks and their tools are ridiculously
> >> > expensive. This is equivalent for the vendors to shooting themselves in
> >> > the foot, at the same time hitting us with the richocet.
> 
> >> Seems to be a general problem. Obviously this is one of the worst market
> >> barriers for new languages: Market is small, so prices have to be high to
> >> make a living from them, so market remains small.
> >> On the other hand, this has saved us from countless language wars, so
> >> maybe this vicious circle is a godsend...
> >
> >I think this is coming around.  PPD has Smalltalk Express.  I know both
> >Dolphin (http://www.intuitive.co.uk) and SmalltalkMT
> >(http://www.objectconnect.com) have very low priced Smalltalk products
> >in the works.  Dolphin intriques me because of the Smalltalk Applet
> >plug-in available.  SmalltalkMT looks cool because it produces very
> >small, fast executables.
> 
> And now Cincom is offering ObjectStudio
> (http://www.cincom.com/objectstudio) for less than $100.
> ObjectStudio's apparent advantage is that of a full-featured, mature
> development environment with full Win32 compliance at the lowest price
> of any commercial implementation.

Thanks, didn't mean to slight the Cincom people.  ObjectStudio's been
around for awhile (from the V-MARK days), but I've never used it myself.

It appears to me that everyrthing from shrink-wrapped or small shareware
apps all the way up to huge distributed apps is possible within the
range of Smalltalk implementations.  The price scale is there.

> 
> Lawrence G. Mayka
> lgmayka@sprynet.com

-- 
James O'Connor 
--------------------------------------
joconnor@jmpstart.com
http://www.jmpstart.com
--------------------------------------

Re: OO, C++, and something much better!

[James O'Connor]

Robert Dewar wrote:
> 
> Tansel said
> 
> ">What is highly debatable? I have used C++ for a long time and now I am
> >using Smalltalk, and there is NO comparison in development times. They
> >are simply different categories. Turtle vs. Rabbit."
> 
> Yes, an apt reference to the fable, and I trust you remember who wins the
> race between the Tortoise and the Hare (which is the translation of the
> Greek I am used to, but I doubt we know precisely what animals Aesop was
> describing to this level of detail).
 
> In this case, the reason for the tortoise winning may well be found in
> the long term maintenance and life cycle costs. Yes, langauges like
> Smalltalk are certainly handy for quick prototyping, but who knows what
> the long term life cycle cost effects will be -- answer: no one, because
> commercial use of Smalltalk is too new to have more than scattered data.

Yes, that was perhaps a bad anology on his part to try to prove that
point :)

For that matter, has Ada been used enough in commercial systems long
enough to have meaningful data about long-term maintanence costs?
> 
> Again, noticing that Ada is on the list of xpostings, it is interesting to
> note that the first Ada translator (Ada/Ed) was written in a dynamically
> typed language (SETL -- which is a very high level language oriented around
> high level set operations, or more precisely ZF-set operations, where
> general mappings play a critical role. It is a garbage collected langguage
> with pure value semantics (e.g. no pointers).
> 
> It is indeed a highly effective prototyping language, and allowed us to get
> something working quickly. However, in retrospec, we felt one of the big
> weaknesses of SETL was precisely the dynamic typing. If your data structures
> are such that only an integer makes sense in a particular context, then it
> is nice to have this statically checked, instead of letting an accidental
> assignment of some incorrect type cause chaos down the road.
> 
> These days it is quite entertaining to see a whole new generation of
> programmers introduced for the first time to dynamic typing, but of course
> it is not new at all (LISP is almost as old as Fortran), but in my opinion,
> anything that the compiler can do for you is valuable. What you will find
> programmers saying in the Ada and Alogol-68 worlds is that it is often hard
> work to get the program past the compiler, but once past, it works the first
> time.
> 
> Ada programmers often don't paricularly care about debuggers -- ask a roomful
> of Ada programmers whether they find debuggers useful, and maybe half will
> say they regard them as critical. By contrast, when I suggested the idea
> that debuggers were not that important to Gabriel (of Lisp fame, sorry I
> forget his first name) he thought it was a huge joke, the very *idea* that
> someone could do without a debugger -- it actually set him laughing :-)

I once commented to an (Ada advocate) friend that the more dynamic your
language got, the more you needed dynamic tools to deal with it.  When I
did Ada83 years ago, I could use source code print-outs to debug my code
because every object was statically typed and every subprogram call was
statically bound.  Now that I use Smalltalk (Ada people think I've
fallen from grace, Smalltalkers think I've reached enlightenment),
source code print-outs are not as valuable because it us much harder to
derive runtime state and flow of control.  I wouldn't necessarily say
that over-reliance on dynamic debuggers is good, even in Smalltalk.  The
debuggers are verypowerful in Smalltalk, but even better is to use the
various powerful cross-referencing tools to ensure thos errors don't
happen in the first place.

> 
> Someone actually posted earlier to this thread the idea that it was pretty
> useless to have the compiler verify type invariants, because debugging
> would find the errors easily. It is positively scary that there are
> programmers around who could say this with a straight face. But then
> any exposure to the general community of programmers is a very
> frightening experience :-)

I was on a particularly ugly project and I used to ask my co-workers "If
someone built a plane the way we're building this software, would you
get in it?"

-- 
James O'Connor 
--------------------------------------
joconnor@jmpstart.com
http://www.jmpstart.com
--------------------------------------

Re: OO, C++, and something much better!

[Larry J. Elmore]

Bob Haugen <linkage@interaccess.com> wrote in article
<32EB845C.68EB@interaccess.com>...

> Is there any other environment (except Lisp) that enables such dynamic 
> testing?

I don't know about OO languages, but Forth is (properly) programmed that
way, i.e., top-down design, bottom-up implementation with immediate testing
of each component. I really liked Forth when I used it 10 years ago, and
from what I've seen of it, Smalltalk has a similar 'feel'. Too bad there's
no good implementation of it within my current budget...

-- 
-----------------------------------------------------
Larry J. Elmore
Bozeman, Montana

"And they shall beat their swords into plowshares."
--Isaiah 2:4

"History teaches us that those who beat their swords into plowshares
usually end up plowing for those who kept their swords."
--Anon.

Re: OO, C++, and something much better!

[George Wolke]

James O'Connor <joconnor@jmpstart.com> wrote in article
<32EB753C.678B@jmpstart.com>...
> Curious, was the catastophe because of Smalltalk?  Or because of bad
> design/requirements analysis?  I would be more inclined to guess the
> later.  Like the Arianne V that blew up awhile back?  Wasn't that
> written in Ada?  Was it because it was written in Ada or becuase the
> designer made a mistake. I would be inclined to think it was the
> designer's fault, not the languages.

The Ariane V failure was a design error.  The design called for using
Ariane IV code as the baseline, even though their mission requirements were
different.  Also, a decision was made to assume the design correct unless
an error was observed, rather than to use closed-loop simulation to prove
the design sound.  

What happened was that the design called for limited error checking on
conversion routines in order to save of the overall EEPROM usage of the
flight software.  When a section of code (used only for ground operations,
but still enabled for flight) caused a run-time assertion, the system
switched to a redundant computer.  Unfortunately, the backup was running
the same code as the primary and thus it failed too!!  Thus the mission
failed!

Re: OO, C++, and something much better!

[Robert Dewar]

Bob asks

" So you test everything as-you-go, bottom up, without having to create
test harnesses, stubs, and other administrative trivia.  So you code
seldom gets out of control.
Lint-style static checks could be included in the above description;  I
understand some Smalltalk tools are coming on the market to do that.

Is there any other environment (except Lisp) that enables such dynamic
testing?"


Robert replies

The danger is that the "test everything as-you-go" style degrades into
"design everything as-you-go", which is tempting for fast development,
and is even appropriate for certain kinds of prototyping, but is a
complete disaster for generating large scale reliable software, as has
been proved over and over again by experience. 

"is there any other environment"

Yes, of course, this kind of dynamic environment is common. Many Basic
systems share this kind of flexibility. APL and ABC come to mind 
immediately, but there are many others. This is actually more a matter
of implementation style than languagde design, though in some cases
language designs facilitate this kind of dynamic approach.

You can even provide this kind of dynamic development envrionment with
languages like C, using incremental compialtion and fix-and-continue.

But once again, this kind of dynamic environment can be very dangerous.
it is the antithesis of the careful approach using formal or semi-formal
tools that is the key to generaing large scale reliable software. Consider
for instance the clean room model. I would get that most of those who
like the highly dynamic style cannot even *imagine* that the clean room
approach works, let alone that it has been found to be highly effective.

Re: OO, C++, and something much better!

[Joachim Durchholz]

Arrgh, got a private copy before the news arrived, and my mailer is too  
dumb to redirect the private reply into the newsgroup...
Well, I always wanted to cut&paste text screenful by screenful... here we  
go:

> > I agree checking should be done on the interface, but I was not aware of
> > any difference between type and interface. After all, objects with
> > identical interface have the same type for all practical purposes.
>
> There are subtle differences between 'type', 'interface', and 'class'
> and the terms get used somewhat interchangebly around here.

I think these differences are mostly artificial. They have been introduced
to capture subtle differences in the way languages implement various
concepts.

To my understanding, a class is a piece of program code, and an interface
(or type) is everything that one must know to use that class. So an
interface is a set of routine signatures and maybe class invariants,
routine preconditions and routine postconditions.

> Java, for
> example uses two separate constructs; Class (defining an interface and
> and implementations) and Interface (describing only an interface).

A Java interface is just a shorthand for "class with nothing than an
interface". A Java interface is not a general OO interface.
Similar shorthands are known from other languages. C structures aren't
full structure in a general sense, still I can talk about a structure
containing fields and an application structure. I just have to make clear
which sense is intended.

> Ada95 (I think) uses the term type to mean a type of data tructure, the
> type-and-package become what others call a class and the term 'Class'
> means a family of types (I think this is right...).

Types can be "opaque", meaning nothing about their internal structure is
known to the outside world. (At least the original language had it this
way, but I see no reason why they should have changed this.)
I don't know anough of Ada95 to comment on the rest.

> Smalltalk uses the
> term 'class' to mean a class and the term 'type' to mean providing or
> describing a certain interface.

Well, then I'm a Smalltalker wrt. terminology...

> However even type and interface are not
> interchangble.  In Java, two objects that happen to share the same set
> of method signatures are not the same 'type' unless the inherit from a
> common base Class or base Interface.

There are two cases to distinguish here:
1) Signatures are the same, but there are observable differences in
routine behaviour. In that case, the routines must do different things,
which means they have different preconditions, different postconditions,
or the classes have different invariants.
2) Signatures are the same, and there is no difference in routine
behaviour. This case should be extremely rare though... and I'd consider
them the same type, even if Java doesn't.

> Deleting methods on the fly isn't very common.

That was just an example. The same goes for changing signatures.

> But delegation is, I
> believe.  If you use the #doesNotUnderstand: aMessage delagation
> approach, than knowing the claass of an object may not tell you whether
> a particular message send will work.

Yup. But I don't think that this approach is too friendly to any attempt
at compilation.
But this is a totally different can of worms... enough!

Regards,
Joachim

Re: OO, C++, and something much better!

[Eric Clayberg]

Robert Dewar wrote:
> Actually the approach in Smalltalk is rather simplistic. For a more
> interesting approach to multi-precision arithmetic, have a look at
> ABC, which can, in a sense compute in infinite precision using continued
> fractions. For example, you can trivially write a program which will print
> digits of pi, and watch it printing them, and let it print as many as
> you want. The program to do this is just a few lines long.

Hmmm. ABC sounds interesting, but from the description above, this does
not sound like a capability that it has that Smalltalk does not have as
well. Smalltalk can also do infinite precision arithmetic using its
built-in Fraction class. I too have seen the pi example described above
written in a few lines of Smalltalk code. 

-Eric

Re: OO, C++, and something much better!

[Eric Clayberg]

Jon S Anthony wrote:
> In article <32E6862D.608B@parcplace.com> Eric Clayberg <clayberg@parcplace.com> writes:
> > 2) it has a simple, logical and consistent language syntax
> > (developers can concentrate of the problem at hand and not the
> > vagaries of the syntax),
> 
> That's nice, but should be irrelevant to the customer.  So, I don't
> see how this could _objectively_ have anything to do with why they
> like it - they never see the syntax (or at least they shouldn't have
> to!)

I think we have a disconnect as to who "they" are. My comment concerned
the developers who actually have to program in the language, not the end
users of the resultant application. I was merely trying to point out
some of the reasons why the decision makers in the securities industry
had selected Smalltalk for their internal development efforts. The
simplicity of the language and its syntax is one of its major appeals
(although certainly not the only one).

-Eric

Re: OO, C++, and something much better!

[TanselErsavas]

James O'Connor wrote:
> 
> Robert Dewar wrote:
> >
> > Tansel said
> >
> > ">What is highly debatable? I have used C++ for a long time and now I am
> > >using Smalltalk, and there is NO comparison in development times. They
> > >are simply different categories. Turtle vs. Rabbit."
> >
> > Yes, an apt reference to the fable, and I trust you remember who wins the
> > race between the Tortoise and the Hare (which is the translation of the
> > Greek I am used to, but I doubt we know precisely what animals Aesop was
> > describing to this level of detail).
> 
 
> Yes, that was perhaps a bad anology on his part to try to prove that
> point :)


I actually deliberately used this example. First of all, it has an
element of truth that although you can develop applications very fast
with Smalltalk, fine tuning and packaging them is slow, even with
Today's nice tools, so I don't think that we should create an illusion
that it is all a bed of roses. However, still there is no comparison. It
is my observation that since it is so easy to develop in Smalltalk, the
first target of people is to make the system run. That allows so many
performance problems to creep into the system, which need to be
optimized later. On the contrary, in primitive languages efficiency is
always a factor. These types of problems are very solvable through good
training and tools.

Second, for "the Tortoise and the Hare", isn't it the time that we
stopped believing such things? Just because we have a fable from the
mythological times, does it mean that it is true, or it will always be
like that? We are living in an age that we can have our own experiments
rather than relying on old dogma. 

> > In this case, the reason for the tortoise winning may well be found in
> > the long term maintenance and life cycle costs. Yes, languages like
> > Smalltalk are certainly handy for quick prototyping, but who knows what
> > the long term life cycle cost effects will be -- answer: no one, because
> > commercial use of Smalltalk is too new to have more than scattered data.

Not really. I have used most commercial languages including Smalltalk
long enough, to see development and maintenance with Smalltalk is always
so fast, it is just another dimension. You need people who know what
they are doing though. The biggest problem with Smalltalk is people, and
organizations who insist in developing applications with an army of
people who don't know much, rather than a few good people. 
 
> I once commented to an (Ada advocate) friend that the more dynamic your
> language got, the more you needed dynamic tools to deal with it.  When I
> did Ada83 years ago, I could use source code print-outs to debug my code
> because every object was statically typed and every subprogram call was
> statically bound.  Now that I use Smalltalk (Ada people think I've
> fallen from grace, Smalltalkers think I've reached enlightenment),
                                                     ^^^^^^^^^^^^^
Congratulations! I had already noticed that light coming from your
direction.

> source code print-outs are not as valuable because it us much harder to
> derive runtime state and flow of control.  I wouldn't necessarily say
> that over-reliance on dynamic debuggers is good, even in Smalltalk.  The
> debuggers are very powerful in Smalltalk, but even better is to use the
> various powerful cross-referencing tools to ensure those errors don't
> happen in the first place.
> 
> >
> > Someone actually posted earlier to this thread the idea that it was pretty
> > useless to have the compiler verify type invariants, because debugging
> > would find the errors easily. It is positively scary that there are
> > programmers around who could say this with a straight face. But then
> > any exposure to the general community of programmers is a very
> > frightening experience :-)

The idea of keeping the compiler as simple as possible is a very
important step in obtaining language flexibility and portability . C has
relied on this, and I find Smalltalk's simplicity and language syntax
brilliant. It takes time to digest it though. However, "you can not do
it with the compiler" does not mean that you have to do it with
debugging. This is not an either-or case. Lint type of tools are used
for C and C++, and Smalltalk environments are very clever to identify
many potential bugs. I use a technique that automatically embeds type
and other safety checking into code and automatically remove when I
don't need them any more. I will commercialize this in future releases
of my Snowball Rapid Systems Engineering tool. 

...

> James O'Connor

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: OO, C++, and something much better!

[Eric Clayberg]

Larry J. Elmore wrote:
> I really liked Forth when I used it 10 years ago, and
> from what I've seen of it, Smalltalk has a similar 'feel'. Too bad there's
> no good implementation of it within my current budget...

Actually, that has changed dramatically in the last few months. 

o Smalltalk Express is a fully functional 16-bit Windows Smalltalk IDE
that is available for free from http://www.objectshare.com/seinfo.htm. 

o ObjectStudio 5.0 is available for $95 from
http://www.cincom.com/objectstudio/justryit.htm. 

o Dolphin Smalltalk is in beta but is expected to cost <$200 (see
http://www.intuitive.co.uk/dolphin/dolphin.htm for details). 

o Smalltalk MT is now available for $295 from
http://www.objectconnect.com.

There are also other low-cost Smalltalk products in the works.

-Eric

Re: OO, C++, and something much better!

[William Clodius]

Robert Dewar wrote:
> 
> <snip>
> 
> An interesting P.S. for the Ada folks reading this (like so many
> messages today, this thread is cross-posted to a whole bunch of language
> groups -- we really need a separate group for this rambling stuff on
> languages -- an inordinate amount of which is rambling by people who
> clearly know very little about language design -- anyway back to Ada.
> <snip>

The ideal would be to have a comp.lang.advocacy group, but, as that does
not exitst, comp.lang.misc appears to be the most appropriate existing
group. I would suggest setting followups to there for most responses to
threads such as this one, except for followups such as this one which
suggest ways of dealing with threads posted to multiple language groups. 

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: OO, C++, and something much better!

[Robert Dewar]

"I do, however, think that Alan's point is that some big people with a
lot of money and a lot at stake have decided that Smalltalk is a viable
solution for that environment."


The expenditure of large amounts of money does not validate the wisdom
of the projects on which the expenditures are made!

Re: OO, C++, and something much better!

[Robert Dewar]

Eric says

"Hmmm. ABC sounds interesting, but from the description above, this does
not sound like a capability that it has that Smalltalk does not have as
well. Smalltalk can also do infinite precision arithmetic using its
built-in Fraction class. I too have seen the pi example described above
written in a few lines of Smalltalk code."

As far as I know the built in fraction class in ST is just straigntforward
rational arithmetic, that I know of, continued fractions are not used.
Can you in ST print out the Square root of 2 to as many digits as you
like, or the cosine of 0.3?

Re: OO, C++, and something much better!

[Robert Dewar]

Tansel said

"I actually deliberately used this example. First of all, it has an
element of truth that although you can develop applications very fast
with Smalltalk, fine tuning and packaging them is slow, even with
Today's nice tools, so I don't think that we should create an illusion
that it is all a bed of roses. However, still there is no comparison. It
is my observation that since it is so easy to develop in Smalltalk, the
first target of people is to make the system run. That allows so many
performance problems to creep into the system, which need to be
optimized later."

Robert replies

As I said before, it is amusing to see a new generation of programmers
exposed for the first time to the wonders of dynamic languages (if there
had been an internet 30 years ago, you could surely have seen exactly
the post above talking about Lisp).

The idea that you can completely ignore efficiency and then somehow
fix it up later by "optimization" is appealing, but naive. if you want
efficient, you have think about this requirement from the start. To say
that you can deal with this later is very similar to the claim that you
can develop in a sloppy hack-away-and-get-it-working mode and then build
in reliability later.

In my opinion a lot of the problems in large software systems, no matter
what language they are built in, arise from failure to do proper design
and requirements engineering. You would think that we would have learned
something about this in all this time, but I still see people building
large systems in the same roar-ahead-and-get-it-working-more-or-less
mode. 

Although it is of course possible to develop large and reliable systems
in Smalltalk, one has to consider the people dynamics of any language, and
in my experience, Smalltalk tends to unduly encourage premature coding.
o

Re: OO, C++, and something much better!

[Robert Dewar]

"Hmmm. ABC sounds interesting, but from the description above, this does
not sound like a capability that it has that Smalltalk does not have as
well. Smalltalk can also do infinite precision arithmetic using its
built-in Fraction class. I too have seen the pi example described above
written in a few lines of Smalltalk code."


As far as I know the fraction class in ST is just a straigntforward
implementation of rational arithmetic. The advantage of the continued
fraction approach is that you can get arbitrary precision for irrational
numbers. For example it is fine to write the sqrt (2.0) in ABC, and this
is *exactly* the square root of 2. If you print out this value, it will
print out an infinite number of digits, and take an infinite amount of
time to do it. You can however say give me the first N digits (or more
precisely there is a truncation operator that says, truncate this value
to N decimal digits, and then you can output the truncated value.

Re: OO, C++, and something much better!

[Richard Riehle]

On Thu, 9 Jan 1997, Bertrand Meyer wrote:

> To the four properties listed in my original I should also add two
> just as essential requirements: true multiple inheritance, for combining
> different abstractions (and with the right mechanisms to avoid any
> ambiguity or conflict); and, most importantly, Design by Contract
> and the rules on how assertions combine with inheritance. As someone
> remarked, it is really impossible to understand inheritance without
> understanding Design by Contract.

  Bertrand,

  I understand that the notion of "design by contract" was probably
  your original contribution to the literature, and I also realize
  that your concept of it is inextricably linked to the Eiffel 
  model for assertions.  However, I would like to suggest another
  view of the same idea.

  Assertions, as I understand them are predominately a run-time
  check on the software entities.  If I may oversimply, Preconditions
  "require" that certain propositions are true for a feature to begin
  executing, Postconditions "ensure" the other propositions are true upon
  leaving a routine, and Invariants guarantee that certain 
  entities remain intact during execution. While this description does
  seem to oversimplify the Eiffel design of assertions, I hope it will not
  offend you.  

  The Eiffel assertion model contains all of the elements of an Ada
  type, though an Ada data type does not contain all the elements of
  an Eiffel assertion.  When I say, 

            type T is ... ;

  I am saying for T that there is a set of assertions which are post-,
  pre-, and invariant.  These assertions, implied to be sure, are also
  checked at run-time.  I am saying by the declaration for T, that
  there is a minimum value for T, a maximum value, and any routine
  that uses T must not let it stray from that range.  Also, in Ada 95,
  I can check the validity of that value at any time using the 
  expression,

            if T1'Valid then ... end if;

  where T1 is a value of type T.  

  My question is, can one write an invalid assertion in Eiffel?  That is,
  can the expression  for an assertion be some complex that it contains
  the very kind of error that we are trying to avoid with procedural
  code?

  If I define an assertion,


              require
                   some complex mathematical expression
              ensure
                   another complex expression
  
  is there some mechnism inherent in Eiffel that can evaluate my
  assertions for correctness?

  The Ada model for pre-, post- and invariant conditions is, to be sure,
  more conservative and less sophisticated than designed into Eiffel. But
  that very conservatism contributes to the simplicity of the process of
  creating specifications. 

  Although Ada software developers do not customarily use the expression,
  "design by contract," that is exactly what they are doing whenever they
  design their own data types and specify the acceptable ranges and
  boundaries acceptable for those types.  

  As for the assertion mechanism, itself, there is probably no reason
  why a compiler publisher could not add to an implementation three
  pragmas,

          pragma Precondition  ( expression )
          pragma Postcondition ( expression )
          pragma Invariant     ( expression )

  but in so doing we must ask whether the addition of such pragmas would
  really make the resulting program more reliable than it was using 
  the more conservative model of simple type definition.

  Bertrand, on a personal note, I am glad to see you engaged in this
  dialogue.  We need more of this level of discussion here. Thanks.


  Richard

Re: OO, C++, and something much better!

[Nick Leaton]

Roy Phillips wrote:
> ... More problematical is
> the
> accidental substitution, for example of an operation with same name but
> an
> entirely differant meaning (for example, the terms 'interest' (financial
> domain) and 'interest' (marketing domain)) - blame the English language
> if
> you will, but without semantic specification (i.e., Eiffel assertions)
> the
> whole thing is a can of worms.
> 

If we take two classes, car and array. We have an array of cars and car
is comparable. We can then have a sort implemented in array and sort
cars. But if we wish to sort cars by size or price, then it becomes a
little more difficult. You have two meanings to comparable for a car.
Personally, I'm not sure of the best way to approach this problem but I
suspect it would involve a sorter class, with price_sorter and
size_sorter classes derived from the base class sorter.
-- 

Nick

Re: What is wrong with OO ?

[Robert C. Martin]

In article <5bub0e$jfc@uni.library.ucla.edu>, jmartin@cs.ucla.edu (Jay
Martin) wrote:

> Since C
> programmers are notorously ignorant of computer language design, the
> audience is not too discerning. 

This is a an unworthy, biased, and biggotted statement.  The only common
attribute shared by the class of people called "C programmers" is that they
write programs in C.  They do not share any form of common ignorance. Any
notoriety to that effect comes from those who erroneously take such notice.  
They form another class of people whose sole common characteristic is that they
think C programmers are ignorant.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: OO, C++, and something much better!

[Jerry van Dijk]

: Curious, was the catastophe because of Smalltalk?  Or because of bad
: design/requirements analysis?  I would be more inclined to guess the
: later.  Like the Arianne V that blew up awhile back? 

etc.

I keep wondering, why all this heated debat? Why try to convince each
other the the language you like best is the ideal for everything ?
Isn't this whole discussion futile since programming languages are just
tools, and not every problem looks like a nail ?

Smalltalk would not exactly be my first choice if I had to built a large
reliable system. Neither would Ada be my first choice for developing
a PC GUI front-end. But I have developed a banking application in which
the presentation- and application layers were written in Smalltalk,
while the functional- and interface layers were written in Ada.

Jerry.
-- 
+----------------+-------------------------------+
| Jerry van Dijk | Consultant, Ordina Finance BV |
|    Team Ada    |        Haarlem, Holland       |
+----------------+-------------------------------+

Re: OO, C++, and something much better!

[Norman H. Cohen]

Eric Clayberg wrote:

> If you say
> that apps built with Ada are even more stable, then great. Do you have
> any evidence that shows that deployed Ada apps are more stable in
> practice than deployed Smalltalk apps? I have never seen anything beyond
> supposition and guesses (usually offered up by folks who have never used
> Smalltalk).

No, I've such comparisons between Ada and C/C++ (see, for example
http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html,
which shows the same programmers developing Ada code and C code, and
producing the average Ada line for 60% of the cost of an average C line,
with only 1/6 as many defects in the delivered code), but not between
Ada and Smalltalk.  I would certainly be interested in such
comparisons.  If there are any Smalltalk versus C comparisons, it would
be interesting to observe whether the same factors are achieved (with
the caveat that this is not as controlled an experiment as a direct
comparison of Ada and Smalltalk code written by the same programmers).


> Are you saying that Ada is incapable of propagating errors to the end
> user? All errors are guaranteed to be fixed prior to deployment? That
> would be remarkable.

Of course I'm saying no such thing.  I am saying that there is a large
class of errors that (1) occur frequently in real programs and (2) could
be caught at compile time in a language that allows many consistency
properties to be encoded as type distinctions and enforces type
distinctions.  This class does not include all errors by any means, but
it includes enough errors to make a huge difference in reliability.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32EB753C.678B@jmpstart.com> James O'Connor <joconnor@jmpstart.com> writes:

> Curious, was the catastophe because of Smalltalk?  Or because of bad
> design/requirements analysis?

Or lousy people.  Or more to the point, feckless management.  This is
what it basically always comes down to.

> I would be more inclined to guess the
> later.  Like the Arianne V that blew up awhile back?  Wasn't that
> written in Ada?  Was it because it was written in Ada or becuase the
> designer made a mistake. I would be inclined to think it was the
> designer's fault, not the languages.

Yup.  Well, actually, again it was _management_ that decided against
certain recommendations and didn't bother requiring full scale testing
of software that had never before been tried in the environment in
which it was being "reused".


> I do, however, think that Alan's point is that some big people with a
> lot of money and a lot at stake have decided that Smalltalk is a viable
> solution for that environment.

And I would guess that under various scenarios in that environment, it
_is_.  In fact, I'd go further and say that there is undoubtedly a
class of these where it is the _best_ viable alternative.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32EA52FA.1CF9@jmpstart.com> James O'Connor <joconnor@jmpstart.com> writes:

> There are subtle differences between 'type', 'interface', and 'class'
> and the terms get used somewhat interchangebly around here.  Java, for

Agreed.


> example uses two separate constructs; Class (defining an interface and
> and implementations) and Interface (describing only an interface). 
> Ada95 (I think) uses the term type to mean a type of data tructure, the
> type-and-package become what others call a class and the term 'Class'
> means a family of types (I think this is right...).

In Ada, a type is definitely _not_ a kind of "datastructure".  OTOH, I
don't think that "interface" is a technical term in Ada - at least I
can't find any definition of it.  Well, there's package _interface_,
but that has nothing to do with this discussion.  In this context, I
believe that Ada lingo would say that a _type_ defines an "interface"
as the term is being used here, plus the set of legal values for that
interface.  If you want to dump this last bit (what the legal values
are) into the notion of "interface", then it looks like a type simply
defines an interface (this sounds kind of like the notion of a ADT as
often given):

RM 3.2

(1)
    A type is characterized by a set of values, and a set of primitive
    operations which implement the fundamental aspects of its
    semantics. An object of a given type is a run-time entity that
    contains (has) a value of the type. 
(2)
    Types are grouped into classes of types, reflecting the similarity
    of their values and primitive operations. There exist several
    language-defined classes of types (see NOTES below). Elementary types
    are those whose values are logically indivisible; composite types are
    those whose values are composed of component values.

The "primitive operation" bit implicitly captures the part about being
defined relative to a package specification (which is the only place
that primitive operations can be defined) and the "packaged" whole is
basically what other languages call a class (type conjoined with
module) or (as in the Java case) you may need to toss in an
implementation for the specification to complete the analogy.

So (for Ada), I suppose you could say that an "interface" is an extra
language thing meant to specify the semantics of something, that every
type defines an interface and (possibly) any interface has a
corresponding type which defines it.  And the term "class" is used to
denote a family of related types - related through type derivation.  I
find this use of the term "class" rather appealing as it adheres
fairly close to what classification systems have always meant by
"class".  A class functions kinda sorta as a meta-type (and you can
define extra operations for it as well).

Also, a type does not provide or imply an implementation.  It can be
defined separately from any implementation and can be given several
different implementations.


> type and interface are not interchangble.  In Java, two objects that
> happen to share the same set of method signatures are not the same
> 'type' unless the inherit from a common base Class or base
> Interface.

Ada takes this a bit further: Technically, two objects _can't_ share
the same set of method signatures (primitive operations) _unless_ they
are of the _same_ type.  Even if T2 is derived from T1, they are still
two different types.  But, they both belong to the same class of types
and all the methods of T1 are (implicitly) declared for T2 with the
signatures adjusted for T2.  Of course any or all of these may be
overridden for T2.  In practice, things basically work as you would
expect.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Norman H. Cohen]

James O'Connor wrote:

> There are subtle differences between 'type', 'interface', and 'class'
> and the terms get used somewhat interchangebly around here.  
...
> Ada95 (I think) uses the term type to mean a type of data tructure, the
> type-and-package become what others call a class and the term 'Class'
> means a family of types (I think this is right...). 

Almost right.  An Ada type can be (either publically or privately) a
null record that exists to be extended.  In that case, the type is not
really a data structure, but (in conjunction with the subprograms
provided by its package) an interface.  

Like a Java class, an Ada type can be declared "abstract", meaning that
it exists for the purpose of declaring a common interface for all the
types that will be derived from it, but that no objects of that type
itself will ever exist.  The operations declared for an abstract type
need not have implementations (although the corresponding operations of
nonabstract descendants must).

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Ed Shirk]

Joachim Durchholz wrote:
> 
> Ed wrote:
> 
> > >  What makes you
> > > think that the ``superb debugging facilities'' are going to be at the
> > > installation site?
> > Because they are <g> The walkback trace is also available in the runtime
> > system.
> 
> I don't buy that.
> Well, yes, technically, the debugging facilities may be present. But they
> may at well be not present - or would you let the end user correct the
> code?
> 

There are seperate facilities for logging the error which are in the
runtime system. The user is not able to modify code since the compiler
is not part of the runtime. But all the meta-information available in
the runtime program allows a very complete error log to be written. Very
often a developer is able to find and fix any problems from the
information in the log. 

A software producer might choose to not include it, since it does reveal
a lot of internal infomation about the software. But that is a choice
that can be made, depending on the situation.

   
> Regards,
> -Joachim
> 
> --
> Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

-- 
Ed Shirk
ParcPlace-Digitalk
http://www.ParcPlace.com

Re: OO, C++, and something much better!

[Rolf Breuning]

Joachim Durchholz wrote:
> 
> Ed wrote:
> 
> > >  What makes you
> > > think that the ``superb debugging facilities'' are going to be at the
> > > installation site?
> > Because they are <g> The walkback trace is also available in the runtime
> > system.
> 
> I don't buy that.
> Well, yes, technically, the debugging facilities may be present. But they
> may at well be not present - or would you let the end user correct the
> code?
> 

No, but it its an expensive product you can implement a 'Call vendor' 
button that lets him contact the programmer to inspect the whole system.

And he won't be able to claim he can't reproduce the error !

**********************************************************************
* Rolf Breuning                             breu@eecs.rwth-aachen.de *
* Bahnhofstr.7                                     using OS/2 Warp 4 *
* D-52064 Aachen                             - standard disclaimer - *
**********************************************************************

Re: OO, C++, and something much better!

[Robert A Duff]

In article <5c4ab5$134$1@goanna.cs.rmit.EDU.AU>,
Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote:
>I have seen this argument the other way around:
>in a language with strong *dynamic* checking, the run time system
>catches all the errors that actually happen, while a static checker
>misses a lot of them.

Well, it's not clear whether this thread is about "static vs. dynamic
type checking", or "Smalltalk vs. C++".  As has been pointed out,
Smalltalk doesn't do a very good job of dynamic checking (e.g. no checks
on parameter passing or assignment), and C++ doesn't do a very good job
of static checking (e.g. no easy way to define distinct integer types),
not to mention that the C++ type system (and the Ada type system) is
less flexible than in needs to be.

>Surely the answer is not to be dogmatic either way, but to accept that
> - no amount of static checking is ever going to eliminate the need
>   for _all_ dynamic checking
> - dynamic checking has a run time cost; other things being equal it
>   is better to move it to compile time
> - dynamic checking has a life cycle cost; other things being equal
>   it is better to catch errors with a compiler than with testing
> - static checking limits expressiveness to what the language designer
>   believed was feasible (the Ada 95 type system really is very limited,
>   why TYPE isn't even a type!)
> - static checking has a life cycle cost; it _may_ pay off during a
>   prototyping phase, for example.

Wow!  Somebody with a reasonably broad view, rather than a "my language
is perfect" attitude!  (I mean, I agree with the above.)

>>In other words: I'd feel really embarrassed if the user ever saw a  
>>"message not understood" error.
>
>Don't worry, I see enough "core dumped" messages on one system and
>pretty pictures of bombs on another, and my friends see "GPF" often
>enough, that we'd forgive you...

Indeed.

Of course, all of these kinds of run-time failures should cause
embarrassment.  I'm amazed by some comments in this thread that seem to
imagine the end-user fooling about in the (admittedly nice) Smalltalk
debugger.  And comments that seem to confuse the detection/prevention of
bugs with the tracking-down and fixing thereof.

>>IMHO, bugs that can be found automatically should be found automatically.  
>
>Not all languages are used by software engineers.  For example, I am
>currently working with a language called R, based on S.  It's an
>interactive programming language for statistics and graphics.  S is well
>regarded by its users,  If it required declarations, they wouldn't use it.

Hmm.  I have mixed feelings about that statement.  Since I know nothing
about R or S, I'm willing to believe that the R language has an entirely
appropriate set of static and dynamic rules, for this type of
"application".  But I'm not so sure that "well regarded by its users" is
exactly the right criterion.  I mean, this borders on the attitude that
too many programmers have, which seems to be that a language is good if
it's fun to program in.  I've got nothing against having fun (I like
programming a lot), but surely the ultimate goal is to produce good
software.  As you can see from this thread, Smalltalk is well-regarded
by many of its users, and Ada is well-regarded by many of its users, and
the same for C -- isn't there some sort of objective reality, that goes
beyond what programmers think they like?

>>So, dynamic typing has the disadvantage that it makes a set of compile- 
>>time checks impossible.
>
>This is simply false.  ...

Hmm.  In the Smalltalk context, it seems that adding compile-time checks
requires modifying the language, so that there's some way to
(optionally) declare the type/interface expected for each parameter and
variable.  I mean, type-inference is all well and good, but there's got
to be some (preferably fairly localized) information to start inferring
from.

- Bob

Re: OO, C++, and something much better!

[Richard Kenner]

In article <32edc09c.3000098@nntp.interaccess.com> sames@interaccess.com (Samuel S. Shuster) writes:
>  Yeah, I can see it that "Many Of You" just say "It Compiles, Let's Ship It!"
>
>  The quality of the drugs you're taking is showing.

I've heard nobody claim that *testing* is a bad idea.  The claim, with
which I agree, is that *reliance* on testing is a bad idea.  There's a
very large difference between those claims.

Re: OO, C++, and something much better!

[Eric Clayberg]

David Hanley wrote:
> Baloney boomerang.  You've made dozens of counterintuitive claims for
> dynamic typing( smalltalk in particular ) and supported zero of them.

Counterintuitive to who? To someone who knows little about Smalltalk? To
you maybe? A quick scan of the varied responses in this thread indicate
that for quite a few people, these "claims" are quite intuitive and
match their own real world experiences. It is the claim that Smalltalk
is somehow less reliable than statically typed languages that I have
seen zero support for (other than conjecture and innuendo).

> In fact, people on the static typing 'side' of the issue, such as Fergus
> Henderson, have provided good data with compelling arguemnts for static
> typing.

He certainly presented some data. It wasn't very clear that it provided
much support for static typing, however. In fact, his numbers
(especially the variety of errors that he ran into) only served to make
me (and, I imagine, most of the other Smalltalk developers in this
thread) quite happy that I was using Smalltalk (in which, as was pointed
out in response to his numbers, most of those errors couldn't occur).

> A good proof would be there the set of errors which can happen in a
> statically typed system, as opposed to a dynamically typed syatem, are
> fewer.  This is a very simple arguemnt.

OK, then, back it up. So far, *you* haven't *proven* anything. The above
is yet another unsubstantiated claim that statically typed systems are
somehow more reliable than dynamically typed systems. Show me some proof
that Smalltalk is somehow less reliable for building applications than
any arbitrary statically typed language.

In fact, I would very much like to see the above list of potential
errors (and your guess as to how frequently they might occur). Having
used several different statically typed languages over the years as well
as Smalltalk, my experience (and that of many of the folks contributing
to this discussion) is that the Smalltalk-based systems are usually much
more reliable in practice.

-Eric

Re: OO, C++, and something much better!

[Robert A Duff]

In article <dewar.854377413@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>On the other hand, it is quite possible to generate high reliability code
>with no testing whatsoever.

I skept.

> ...For more information on this possibility (which
>often seems almost incredible to the test-debug crowd), read up on the
>cleanroom approach to generating software, an approach in which the development
>team is not permitted to do any testing!

It's incredible to me, and I don't count myself among the "test-debug
crowd".  I count myself among the "static type checking, and even
better, formal verification" crowd.  Nonetheless, whatever you've proven
at compile time, I want to see it work.

- Bob

Re: OO, C++, and something much better!

[Brian Rogoff]

On Mon, 27 Jan 1997, Norman H. Cohen wrote:
> Tansel Ersavas wrote:
> 
> > In Smalltalk, I am internally testing a tool that captures and embeds
> > type checking automatically during development, and strips that
> > information when you request. This way I can actually apply not only
> > type checking, but few other checks that increase reliability
> > dramatically, while not compromising flexibility. 
> 
> You seem to agree with me, then, that Smalltalk plus static consistency
> checking (provided in this case by extra tools) is more valuable than
> Smalltalk without static checking.  You also seem to agree that type
> checking is an important form of consistency checking.  

	A lot of really interesting work on this is being done in the
Scheme community, under the name "soft typing". The basic idea is to use 
ML style type inferencing on dynamic languages to statically determine
types in most cases, or, when this fails, to insert run time checks or warn
the programmer that there is a possible type error at that point in the
software. 

	Of course, compilation time will be increased by doing this, and I 
haven't seen any data about how well this scales to very large programs. 
 
> 
> I have tried to focus my comments in this thread on the value of strong
> typing in general.  Although I have used Ada as an example of a
> strongly-typed language, it is not my intent to engage in Smalltalk
> versus Ada language wars.  

> > And you can never do things in Ada to increase flexibility dramatically.
> 
> No, if you wanted, you could achieve all the weakness of the Smalltalk
> type system in an Ada program by declaring one type, Object, and using
> it as the root of all tagged type derivations.

	In order to prevent further decline of the discussion into a
language war, a term like "weakness of the Smalltalk type system" should 
be replaced by something less inflammatory, though I realize that you are 
not using "weak" in a pejorative but rather in a technical sense. 

	In any case, I think it would be rather difficult to graft
something like metaclasses (i.e. something like the CLOS MOP) onto Ada.
I know there has been some work in adding such things to C++ and BETA, 
but I haven't really studied it. It does seem that dynamically typed 
languages are a more suitable vehicle for these sorts of reflective 
facilities.

-- Brian

Re: OO, C++, and something much better!

[Eric Clayberg]

Robert Dewar wrote:
> The idea that you can completely ignore efficiency and then somehow
> fix it up later by "optimization" is appealing, but naive. if you want
> efficient, you have think about this requirement from the start. To say
> that you can deal with this later is very similar to the claim that you
> can develop in a sloppy hack-away-and-get-it-working mode and then build
> in reliability later.

Not true at all. Getting the program "right" and the algorithms correct
is the most important thing to do first. Premature optimization often
leads to less than optimal results. You can spend lots of time
optimizing something up front that in the final analysis would have very
little impact on your program to begin with. In fact, premature
optimization can often lead to inflexible, even brittle, designs that
will cause major maintenance headaches down the road. IMO, it's much
better to get the program right first, and then optimize any areas that
are actually affecting performance. Every optimization employed usually
has a cost and that cost is felt in terms of reduced flexibility and
loss of genericity.

> Although it is of course possible to develop large and reliable systems
> in Smalltalk

Absolutely. I have seen thousands of them in operation and have worked
on several dozen myself.

> Smalltalk tends to unduly encourage premature coding.

Smalltalk encourages getting the job done sooner rather than later. In
many industries, time-to-market is one of the most important
considerations. Starting (and finishing) sooner and "large and reliable
systems" are *not* mutually exclusive propositions. If you think they
are, then maybe you are simply using the wrong tools...

-Eric

Re: OO, C++, and something much better!

[David Hanley]

Mark Windholtz wrote:
>
>  I'm sure most agree that finding and correcting problems
>  early is a good thing.

	Indeed.

>   The question is what kind of problems?
>  Dynamic languages let you test the logic more and
>  static languages (perhaps) let you test the interfaces more.
	
	I couldn't disagree more.  I doubt that dynamic languages let you test
logic more, while I definitely agree that static languages let you test
interfaces more.

	I would argue that static langauges let you test logic more because you
can embed the logic of your program into your type system.  For example,
a function that computes the containing rectangle of a polygon can
return a rectangle, composed of four points.  If you try to treat the
return value differently in some way, you know right away, at compile
time.  

> 
>  I say "perhaps" because as soon as casting is added to
>  a program written in a static language, you lose the
>  testing of the interface.

	Only if you do unsafe casting, and such casiting is necessary.  Static
typing != C.

> 
>  And it is very hard to write interesting OO in a static
>  language without occationally casting.

	Again, static typing != C.  It appears to me very often that in these
static Vs. dynamic debates the "dynamic side" assumes across the board
that "static OOP" == C++.  This is simply not the case!

> 
>  I maintain that to use a static language with casting
>  amounts to paying the time-to-market cost of a static
>  language

	In other words, less?

>  while writing extra code to support features
>  that come for free in a dynamic language.

	Like?  An example, please?

>  The mistake of casting NULL to an object and attempting
>  to call a function on it in C++ is the same mistake as
>  sending a message to the Nil object in Smalltalk.

	Sure, but C++ != static typing.

> 
>  But at runtime only the static language is likely
>  to cause a core dump or GPF.  In other words the
>  result of the error is more costly. 

	So smalltalk will happily pass a message to the nill object, and the
progrm will chug along just fine?  Somehow, this seems unlikely to me.

>  And the compiler
>  can't help in either case.

	What if the type system is constructed so that nill cannot be passed to
a function?  Like in SML for instance?
	
-- 
------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[David Hanley]

Tansel Ersavas wrote:
> 
>
> I used Pascal, C and C++ for more than 10 years, and developed and led
> development of >500000 loc projects, and I am sorry to say that I still
> think they suck. I now use Smalltalk and Self and sometimes Java if I
> have to, and couldn't be happier.

	I agree that the three previously mentioned languages suck, but I do
not agree that they equal static typing.  I would say that of all the
languages you mention in the obove paragraph, Java is the best one, and
I would consider it statically typed.


> There is a big debate about importance of type checking in object
> oriented systems. We have one camp religiously defending type checking,
> and another group defending unnecessity of it. 

	This characterization of supporters of static tyoe chacking as
"religous" definitely contributes to the objective and factually-based
air of your post. :)

> 
> The problem is two edged. The more type information we put into the
> objects, the more we make them dependent of these types. Any changes on
> these types will have to be detected, and these parts of the programs
> need to be updated, even though in compiled systems a recompilation will
> suffice in many cases.

	Of course, you fail to mention that errors due to these changes will be
detected and flagged immediately, exactly ay the point of origin, rather
than later in the cycle, and far away.

> Contrary to what people say, type checking is against the nature of
> object oriented systems development.

	I didn't find this in any OO definintion I ever saw.  In fact, OO was
originally introduced in sumula, which was statically typed.

>  Remember, in OO, we only care about
> the interface of the other object.

	And the interface accepts and return things, which have typed.

>  In fact it should be an OO sin to ask
> the type, because, in theory, we don�t want to get intimate with objects
> we are interacting apart from their interface.

	Which acceps and returns types.

------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32EB94C4.2CA5@parcplace.com> Eric Clayberg <clayberg@parcplace.com> writes:

> Jon S Anthony wrote:
> > That's nice, but should be irrelevant to the customer.  So, I don't
> > see how this could _objectively_ have anything to do with why they
> > like it - they never see the syntax (or at least they shouldn't have
> > to!)
> 
> I think we have a disconnect as to who "they" are. My comment concerned
> the developers who actually have to program in the language, not the end
> users of the resultant application. I was merely trying to point out
> some of the reasons why the decision makers in the securities industry
> had selected Smalltalk for their internal development efforts. The
> simplicity of the language and its syntax is one of its major appeals
> (although certainly not the only one).

Aha!  Another "talking past one another" instance.  I wonder how many
times this has happened in this thread alone and been _missed_?  And
thereby generating a lot of irrelevant heat and no light...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Robert A Duff]

In article <dewar.854377239@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Runtime checks tell you only that a specific execution of the program did
>not fail the checks, and are thus subject to the fundamental weakness of
>all dynamic based testing methods -- they can establish the presence of bugs,
>but they cannot easily be used to prove the absence of bugs.

But, to be fair, to the dynamic-typing folks, static checking can't
prove the absense of bugs, either.  There is no silver bullet.  Static
checking eliminates *some* bugs, and that's good.  A catch-phrase like
"testing can't eliminate bugs" isn't helpful, since no other technique
is perfect, either.

IMHO, one should be looking for techniques that reduce bugs, not for
some fool-proof-method that can replace some-other-foolproof-
method-that-eliminates-bugs, and thereby replace the other technique.

This comment even applies to formal proofs of "correctness", since
"correctness" really means, in this context, "obeys some formal
specification", and there is never, nor can there ever be, a formal
proof that the formal specification obeys what a reasonable person
demands of the software.

IMHO, one should be applying static checking and also dynamic checking
and also testing and also anything-else-one-think-of to eliminate bugs.
No single techique will suffice.

- Bob

Re: OO, C++, and something much better!

[Bob Jarvis]

Robert A Duff <bobduff@world.std.com> wrote in article <E4oIFx.Jp4@world.std.com>...
> < snip >
> As you can see from this thread, Smalltalk is well-regarded
> by many of its users, and Ada is well-regarded by many of its users, and
> the same for C -- isn't there some sort of objective reality, that goes
> beyond what programmers think they like?

"Objective reality"?  Pun?  :-)

It seems to me that people know what they like and like what they know, be it in
programming languages or music or what have you.  Those who have never worked
in a language with solid strong typing may perhaps go on a knee-jerk rant about
how awful it is/must be.  Those who have never worked with a true dynamically-typed
language may be unable to envision the possibilities.  I forget who said it, but I 
think that the idea that "where you stand on an issue depends on where you sit"
certainly applies here.

> Hmm.  In the Smalltalk context, it seems that adding compile-time checks
> requires modifying the language, so that there's some way to
> (optionally) declare the type/interface expected for each parameter and
> variable.  I mean, type-inference is all well and good, but there's got
> to be some (preferably fairly localized) information to start inferring
> from.

As a Smalltalk developer there are times where I think I'd like to be able to
specify the class of a message parameter so that some level of "type
checking" could be done.  Something like

	myMessage(String): parm1(String) parm: parm2(Magnitude)

would indicate that myMessage should answer a String (or some subclass of
String), that the first parameter should be a String, and the second parameter
should be a Magnitude.  It would be nice if this was optional - if no classes were
specified then the system shouldn't try to do any checking.

However, as a Smalltalk developer I'm also aware that this isn't absolutely
necessary to developing quality software.  I'm sometimes troubled by the lack
of "control" in Smalltalk - why, anyone can pass anything to any message!
On the other hand I'm sometimes thrilled by the lack of interference - I can hack
the snot out of the code and it'll STILL WORK!  Granted, when I'm working in
C++ I can do the same sort of thing, after a fashion - but after spending a
good deal of time in Smalltalk I find that moving to C++ feels like putting
on a straitjacket.
-- 
Bob Jarvis
Mail addresses hacked to foil automailers!
Send replies to jarvisb@timken.com

Re: OO, C++, and something much better!

[Matthew Heaney]

In article <dewar.854377413@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>On the other hand, it is quite possible to generate high reliability code
>with no testing whatsoever. For more information on this possibility (which
>often seems almost incredible to the test-debug crowd), read up on the
>cleanroom approach to generating software, an approach in which the development
>team is not permitted to do any testing!

This is not quite correct.  In the cleanroom approach, the developer is not
allowed to do any *unit* testing.  But testing is done - of the system -
using statistically-based techniques.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32EB845C.68EB@interaccess.com> Bob Haugen <linkage@interaccess.com> writes:

> In my experience, it is all of the above PLUS a dynamic style of 
> development that is enabled by dynamic typing.  Here is an attempt to 
> describe the style:
[...]

I really don't see how this description is attributable to dynamic
_typing_ as opposed to just good ol' dynamic/interpreter based stuff.


> Each class, and each method of each class, and even individual
> statements within methods, can be tested immediately from a
> workspace.  The test statements can then be assembled as class
> methods for regression testing.  The class test methods can then be
> composed into use-case test methods.  So you test everything
> as-you-go, bottom up, without having to create test harnesses,
> stubs, and other administrative trivia.  So you code seldom gets out
> of control.

What's this have to do with dynamic _typing_?  You could do this vary
sort of thing with an interpreter implementation of a statically typed
language.  In fact, you can do close to this even _without_ such a
dynamic implementation.


I'm beginning to think that this entire thread (all sides) is a
meaningless wash...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32E9F63A.159D@rase.com> Tansel Ersavas <tansel@rase.com> writes:

> Norman H. Cohen wrote:
> >[...]
> 
> As you rightly point out, there are many errors in some statically typed
> languages such as C++ that would be deferred till execution such as
> dangling pointers that require sophisticated tools to identify them at
> run-time, so just being statically typed is not a guarantee. 

Of course it is not a gurantee.   Who said otherwise?


> problem detection tools. These facilities are like extending the
> language.  And you can never do things in Ada to increase
> flexibility dramatically.

Why not?  "Just" provide an implementation that supports some of the
flexibility you get from a "dynamic language".  For example, have an
interpreter with continually type checked input plus some "type
derivation" for easing early phase construction or small
constructions.


> > Then again, I suppose they wouldn't be in the securities industry if
> > they didn't enjoy high-stakes gambles. :-)
> 
> Then again, I suppose that paraniod Ada crippled by these concerns is
> mostly used by the defence industry where perceived correctness is
> paramount at any price. People can use Ada where the business is killing
> the right people, but, thanks, I'll use languages such as Smalltalk and
> Self, and I know that I can make them as secure as possible if I want
> to.

Oh my my my, some prejudices slipping out, eh?  Also some preconceived
notions.  I suppose you don't realize that things like ST and Self are
much more the darlings of DoD, than Ada ever was.  But who cares?  Why
should anyone care?  Do you ride on airplanes?  Use the internet
(oops, must, since your message is here)?  How about indirect use of
satellites?  Use computers (oops again)?  Benefit from
microprocessors?  I mean really - can we please have a _little_ bit of
clued in discussion instead of these empty headed booby comments???

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <5c8dkh$2e0@news1.ucsd.edu> mbk@inls1.ucsd.edu (Matt Kennel) writes:

> : A
> : static type checker would catch them no better in Smalltalk than it
> : would in C++.
> 
> This is where I disagree---a really good static language can express
> interesting logical structure in the type system, and mechanically prevent
> a number of "logic" errors as in other systems because they had checkable
> type consequences. 

Exactly.  That's it, in a nutshell.


> : upon how their favorite statically typed language works. Smalltalk has
> : very different rules than what are common in most statically typed
> : languages. Smalltalk simply doesn't need static type checking. 
> 
> That ST is clean and coherent without it is not under debate.

Exactly.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Norman H. Cohen]

Don Harrison wrote:

> :Distinct types are
> :disjoint sets of values distinguished at compile time.
> 
> Don't agree. I think they must simply be *different* sets of values. In the
> special case where the set of values is a subset of the values of another
> type, you have a sub-type (in the Ada sense).
> 
> :Subtypes of a
> :type are (possibly overlapping) sets of values in the same type,
> :distinguished by whether or not they obey certain constraints that can,
> :in general, only be checked at run time.
> 
> Yes ... "according to the Ada definition".
> 
> The real issue, as far as I'm concerned, is that type safety (not surprisingly)
> depends on the definition a type. A language such as Eiffel might be regarded
> as type-unsafe purely because it regards sub-types as distinct types. These
> types - and their attendant runtime constraint violations - are materially
> no different from equivalent sub-types in Ada - which also cause runtime
> constraint violations.

Don, I think you are still being confused by terminology.  A "subtype"
in Ada has almost nothing to do with a "subtype" in Eiffel.  Rather,
what you are calling a subtype in Eiffel corresponds quite closely to a
derived type in Ada.  Just as a run-time error can occur in Eiffel
converting from a type to a subtype (i.e., casting downward in the
inheritance hierarchy), an exception can occur in Ada converting from a
type T'Class to a type directly or indirectly derived from T.  These
run-time errors are analogous.  Ada range checks (which check for
membership in a scalar subtype) are a totally different animal.

If you are saying simply that Ada is not completely type-safe because
conversion from T'Class to a descendent of T may or may not fail a
run-time check, depending on the tag of the object being converted, I
have no argument.  To accommodate the flexibility provided by
polymorphic programming, Ada relaxes compile-time type checks in this
one instance, replacing the compile-time check by a run-time check--but
only when the programmer explicitly requests this by writing a downward
type conversion.

In either Eiffel or Ada, conversion downwards in a type hierarchy should
be rare in a good object-oriented design.  (Java is another matter.  The
Java language-defined container classes all contain elements of class
Object, so upon extracting an object from a Dictionary, for example, you
must cast it downward in the hierarchy to the class of the values
contained in the Dictionary.  Typically, all Dictionary values belong to
a class much more specialized than Object, and the programmer knows what
this class is, but Java provides no way to declare this, to let the
compiler use this information to type-check insertions, and to exploit
the information to avoid the run-time check inherent in downward
casting.)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Norman H. Cohen]

traymond@craftedsmalltalk.com wrote:
> 
> In <32E788D4.4B91@watson.ibm.com>, "Norman H. Cohen" <ncohen@watson.ibm.com> writes:
> [stuff deleted]
> :For example, suppose a program has an array of "producer companies" that
> :manufacture a particular product and an array of "consumer companies"
> :that buy that product.  Suppose the program manipulates both integers
> :meant to index into the first array and integers meant to index into the
> :second array.  Mistakenly using a variable holding an integer of the
> :first kind to index into the second array could produce subtle errors
> :that might be hard to track down, or might just silently produce
> :incorrect answers.  In a strongly typed language such as Ada, one could
> :write
> :
> :   type Producer_Number is range 1 .. Max_Producer_Count;
> :   type Consumer_Number is range 1 .. Max_Consumer_Count;
> :   Producers : array (Producer_Number) of Company;
> :   Consumers : array (Consumer_Number) of Company;
> :
> :Producer_Number and Consumer_Number are distinct integer types whose
> :uses cannot be intermixed without an explicit type conversion.  (This is
> :a degree of type protection unavailable in C or C++).  Certain variables
> :can be declared to be of type Producer and others of type Consumer.  An

Oops.  I meant to say "Certain variables can be declared to be of type
Producer_Number and others of type Consumer_Number."  Sorry if this
caused any confusion.

> :attempt to use a variable of type Producer_Number to index into the
> :array Consumers will produce a compile-time type error.
> :
> :As you said, "Smalltalk does not lend itself to 'type' errors of that
> :nature."  Smalltalk programmers are no less likely than other
> :programmers to use an integer variable to index into the wrong array,
> :but since Smalltalk does not have the means to express such distinctions
> :as type distinctions, I would imagine that most Smalltalk programmers
> :would think of this as a "general logic error" rather than as the kind
> :of problem that would be caught by compile-time type checks.  (When you
> :don't have a hammer, none of your problems look like nails.)
> 
> Sure, smalltalk programmers can index into the wrong array.
> However, your example appears to be formulated for a procedural
> style of programming.  When smalltalk programmers want to
> separate consumers and producers they usually use different
> objects which reduces the tendency to produce the type of
> errors you refer to.

When you say "different objects" do you really mean "different
classes"?  If so, the Ada analog would be "different types", and that's
just what I've done above:  used different types for consumer numbers
and producer numbers.  However, with static checking, this does more
than simply "reduce the tendency to produce" this kind of error; it
causes the compiler to catch this kind of error and point it out to the
programmer even before the program is tested.

I presume you are using the word "procedural" to mean "not object
oriented".  However, there is nothing in the example above that suggests
this.  Perhaps it is the presence of a built-in array type that looks
unSmalltalk-like to you.  Fine, replace the two integer types with two
classes called producerID and consumerID, make Producers an object
belonging to some collection class with an extract method that takes a
producerID object, and make Consumers an object belonging to some
collection class with an extract method that takes a consumerID object. 
My argument remains the same:  It is easy to inadvertently send an
extract message with a producerID argument to Consumers or an extract
message with a consumerID argument to Producers.  The incorrect call
might occur only on some obscure path that testing fails to exercise. 
Strong typing allows such errors to be caught at compile time.

> Part of the power of smalltalk is the use of interface polymorphism.
> Classes do not have to inherit from the same root to be able
> to use the same message interface.  When designing the
> software for your problem one can compose methods that use
> polymorphism so that a single method can "operate" on producers
> and consumers without having to know what it is operating on.
> As a matter of fact a programmer reading the method may not
> even be able to tell if it processes consumers or producers
> because both will work.

This is s red herring.  The benefits of interface polymorphism are not
lost (in fact they are made safer) if classes must be declared to
support a given message, and any attempt to send a message to an object
not declared to support it is caught as an error at compile time.  
In Java, we could write

   interface Company is {
      abstract public void someMethod();
   }

   class ConsumerCompany implements Company {
      public void someMethod () { ... };
      ...
   }

   class ProducerCompany implements Company {
      public void someMethod () { ... };
      ...
   }

and a call X.someMethod() where X is declared to be of class Company
might invoke either the ConsumerCompany or ProducerCompany version of
someMethod, but an attempt to apply someMethod to an object whose class
does implement the Company interface would be flagged as an error at
compile time.  In Ada, we could write

   package Companies is
      type Company is abstract tagged private;
      procedure Some_Method (C: in out Company) is abstract;
      ...
   end Companies;

   package Companies.Consuming is
      type Consumer_Company is
         new Company with private;
      procedure Some_Method (CC: in out Consumer_Company);
      ...
   end Companies.Consuming;

   package Companies.Producing is
      type Producer_Company is
         new Company with private;
      procedure Some_Method (PC: in out Producer_Company);
      ...
   end Companies.Producing;

and a call Some_Method(X) where X is of type Company'Class might invoke
either the Producer_Company or Consumer_Company version of Some_Method,
but an attempt to call Some_Method with a parameter that does not belong
to the class rooted at type Company would be flagged as an error at
compile time.  The issue is not whether or not to have interface
polymorphism--every OO language does--but rather whether or not to
impose some discipline and structure on interface polymorphism, by
making the interfaces explicit and checking at compile time that they
are used consistently.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Ell]

TanselErsavas (tansel@rase.com) wrote:
: The biggest problem with Smalltalk is people, and
: organizations who insist in developing applications with an army of
: people who don't know much, rather than a few good people. 

This seems different from, how Alan Kay's view of how Smalltalk should be
used.  Especially for ubiquitous small applications.

Elliott

Re: OO, C++, and something much better!

[Bob Jarvis]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article <dewar.854327202@merv>...
> Eric says
> 
> "Hey, where I come from, we actually *test* our software *before* we
> deploy it.
> 
> Sounds like you rely on testing to ensure reliability from what you
> say, which sounds pretty dubious to many of us! 

And, pray tell, what do *you* rely on to ensure reliability?  Purity of thought and
the best of intentions?  :-)

I don't care what language a particular piece of software is written in.  If it's *my*
project I'm going to ensure it's tested thoroughly before it's deployed.
-- 
Bob Jarvis
Mail addresses hacked to foil automailers!
Send replies to jarvisb@timken.com

Re: OO, C++, and something much better!

[John Woods]

jhd@herold.franken.de (Joachim Durchholz) writes:

>Oh yes there is a difference. The compiler will catch all errors; the run- 
>time system will miss some.
>In other words: I'd feel really embarrassed if the user ever saw a  
>"message not understood" error.
>IMHO, bugs that can be found automatically should be found automatically.  
>Each 2% failure probability that's taken out will make the total system  
>more stable (remember a dozen 2% failure sources give a total failure  
>probability of about 22%).

*All* errors?  How does the compiler prevent you from dereferencing a
null pointer.

I'd be really embarrassed if a client saw a 'does not understand'
error, but less so if they got a dialog which informed them that there
was a serious internal error and that they should contact the
contractor.  Dereffing nil in C++ isn't usually so elegant.

Your argument about 2% doesn't wash, because of `ignoratio elenchi'.
Of course we would all like the compiler to rid us of as much error as
possible.  We'd be dumb to disagree --- that's why you put your
argument in these terms.  What you don't seem to accept is that we
have grounds to think this 2% reduction is cost free.  

In my experience, the 2% error reduction C++ might give you over
Smalltalk because of static typing is drowned by other factors.  In
particular, although I learned Pascal, C and C++ first, I make less
errors typing Smalltalk because I type less.  And I have to spend less
time trying to make a language do things it doesn't seem to want to
do.  That's before we even start talking about maintainability.

If you prefer static typing, fine.  Tastes vary, and as Ovid said:
``there is no disputation about tastes [that is meaningfull]'.  What I
cannot accept is your constant imputation that we are happy to ignore
a compiler technology that would make our code just a little more
error free.  It would make our code so much harder to write and
maintain that the benefits do not, to us, seem to approach the point
where we would be happy to bin the advantages of dynamic typing.

... John H. Woods







--
"
Forsan et haec olim meminisse iuvabit (Virgil)
[approx] Tr: The time may come when we will look back on these days and laugh
"

Re: OO, C++, and something much better!

[Bob Jarvis]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article <dewar.854209138@merv>...
> iAlan said
> 
> "So then, why have so many investment banks adopted Smalltalk as the language
> of choice for doing securities trading applications?  The reason typically
> given is that development speed in Smalltalk is so much faster--which boils
> down to big bucks on the trading floor.  Could the financial people be wrong?"
> 
> 
> Note incidentally that these "financial people" in whom Alan has so much
> trust are the folks who have brought you the multi-billion $ Y2K disaster!

I don't think you can lay the Y2K problems solely at the feet of the financial industry.
It's the responsibility of every developer who has ever stored a 2-digit year in any
program.
-- 
Bob Jarvis
Mail addresses hacked to foil automailers!
Send replies to jarvisb@timken.com

Re: OO, C++, and something much better!

[John Woods]

donh@syd.csa.com.au (Don Harrison) writes:

>Eric Clayberg writes:

>:Actually, Smalltalk transparently switches to using "large" integers
>:that have no limits on size. In fact, it's actually fun to run large
>:factorials in Smalltalk to see how large an integer it will generate.
>:VisualSmalltalk will calculate the result of "1000 factorial" in a
>:second or two and display the results. BTW, the result of that
>:expression is: :-)

>[some gi-normous number]

>That's impressive. Might hang onto it in case it comes in handy one day. :)


>Don.
>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Don Harrison             donh@syd.csa.com.au

I was showing off VW to a Pascally friend with these large integers.
BTW, the only way to get a scientific format for this is to convert it
into a string and count the digits --- about 2500.  It takes my two
year old PC less than a second to calculate this, and slightly more
than a second to convert it into a string!

Anyway, back to the showing off.  I ran a low priority process finding
the factorial of a million, to show him how stable the system was.
Obviously nothing happened, and I forgot about the process.

Weeks later, my system was getting pretty slow.  I had a good look
at my image.  It contained a two megabyte integer!  But, apart from
the brain aching slowness, it was still crunching reliably away.


... John H Woods


--
"
Forsan et haec olim meminisse iuvabit (Virgil)
[approx] Tr: The time may come when we will look back on these days and laugh
"

Re: OO, C++, and something much better!

[Samuel S. Shuster]

Robert,

 >>Eric says
 >
 >>"Hey, where I come from, we actually *test* our software *before* we
 >>deploy it.
 >
 >Sounds like you rely on testing to ensure reliability from what you
 >say, which sounds pretty dubious to many of us! 

  Yeah, I can see it that "Many Of You" just say "It Compiles, Let's Ship It!"

  The quality of the drugs you're taking is showing.

                                And So It Goes
                                     Sames

============================================================================
sshuster@parcplace.com
ParcPlace-Digitalk
Consultant
All opinions are my own.
============================================================================

Re: OO, C++, and something much better!

[Samuel S. Shuster]

Robert,

 >The danger is that the "test everything as-you-go" style degrades into
 >"design everything as-you-go"

  Is that a fact? Or just your perception of a danger? Where is anything but
your conjecture to base this misstatement of causality?

 >But once again, this kind of dynamic environment can be very dangerous.
 >it is the antithesis of the careful approach using formal or semi-formal
 >tools that is the key to genera[t]ing large scale reliable software.

  On the other hand, the static environment can be very dangerous. It is the
antithesis of productivity using flexible or semi-flexable tools that is the key
to generating successful applications.

  Your argument is as devoid of logic as my above parody. All environments can
be dangerous if they are not used with rigor and discipline. That has a lot more
to do with being a professional and using a coherent methodology than it does
with the environment with which the results are implemented.

  What's the deal? Are you basing your judgements of dynamic environments on the
XBase world or something? That "Programming For The Masses" idiocy did indeed
produce a huge pool of incompetent developers who know little of professional
development, and want to know even less. From this did spring an even larger
amount of slop and waste product.

  That though, had a lot more to do with the "They Gave Me dBase, Now I Is A
Programmer" environment of that community than it did with the fact that XBase
was / is a dynamic environment. That community never did anything to promote a
professional attitude towards development. The Object Technology environment is
quite the opposite.

  You can not take the failing of one community and blithely apply it to all
others that share one or two common features. The issues of static vs dynamic
environments are mutually exclusive of cowboyism vs professionalism. It is
simply brain dead to bring them into comparison.

                                And So It Goes
                                     Sames

============================================================================
sshuster@parcplace.com
ParcPlace-Digitalk
Consultant
All opinions are my own.
============================================================================

Re: OO, C++, and something much better!

[Robert Dewar]

Richard said

" - dynamic checking has a run time cost; other things being equal it
   is better to move it to compile time


The advantage in moving checking to compile time is much more than an
efficiency concern. The checks made at at compile time establish absolute
invariants, such that the corresponding errors cannot possibly occur in any
possible execution of the program.

Runtime checks tell you only that a specific execution of the program did
not fail the checks, and are thus subject to the fundamental weakness of
all dynamic based testing methods -- they can establish the presence of bugs,
but they cannot easily be used to prove the absence of bugs.

Re: OO, C++, and something much better!

[Robert Dewar]

Bob Jarvis said

"I don't think you can lay the Y2K problems solely at the feet of the financial i
ndustry.
It's the responsibility of every developer who has ever stored a 2-digit year in
 any
program.



Robert Dewar replies

Sure, but the most serious instances of the problem are those associated
with big-bucks big-iron fiscal codes.

Re: OO, C++, and something much better!

[Robert Dewar]

Bob says

"And, pray tell, what do *you* rely on to ensure reliability?  Purity of thought
and
the best of intentions?  :-)

I don't care what language a particular piece of software is written in.  If it'
s *my*
project I'm going to ensure it's tested thoroughly before it's deployed.


Robert replies

The tone of this reply certainly is a typical hacker's attitude that it is
impossible to write correct code, and that the only possible approach is to
write incorrect code, and then hope to correct it by testing.

In fact it is essentially impossible to write really high reliability software
this way, e.g. safety critical software. Sure testing plays a role, especially
disciplined testing such as code and path coverage testing, but it is
inconceivable to rely on testing alone. 

Writing correct code has nothing to do with purity of thought or good
intentions. It has to do with using a disciplined approach, aided by
formal specification and formal reasoning, often with the use of tools
specifically designed to support this approach (e.g. the PRAXIS Examiner).

Actually I would prefer to use the word rigorous to formal in the above
paragraph, because formal to many people means mathematically formal, and
although mathematical formalisms are important tools, they are not the
only possible approach.

Testing can reveal the presence of bugs sure, but haphazard testing cannot
provide the absence of bugs. It is true that formal testing techniques are
a legitimate part of a formal approach, and can be used to verify or provide
theorems and invariants about the code, but only if the code has been developed
in a rigorous manner to start with.

On the other hand, it is quite possible to generate high reliability code
with no testing whatsoever. For more information on this possibility (which
often seems almost incredible to the test-debug crowd), read up on the
cleanroom approach to generating software, an approach in which the development
team is not permitted to do any testing!

Re: OO, C++, and something much better!

[Norman H. Cohen]

Tansel Ersavas wrote:

> In Smalltalk, I am internally testing a tool that captures and embeds
> type checking automatically during development, and strips that
> information when you request. This way I can actually apply not only
> type checking, but few other checks that increase reliability
> dramatically, while not compromising flexibility. 

You seem to agree with me, then, that Smalltalk plus static consistency
checking (provided in this case by extra tools) is more valuable than
Smalltalk without static checking.  You also seem to agree that type
checking is an important form of consistency checking.  

I have tried to focus my comments in this thread on the value of strong
typing in general.  Although I have used Ada as an example of a
strongly-typed language, it is not my intent to engage in Smalltalk
versus Ada language wars.  However, I must correct some misimpressions
in your post:  

> And you can never do things in Ada to increase flexibility dramatically.

No, if you wanted, you could achieve all the weakness of the Smalltalk
type system in an Ada program by declaring one type, Object, and using
it as the root of all tagged type derivations.

> People can use Ada where the business is killing
> the right people, but, thanks, I'll use languages such as Smalltalk and
> Self, and I know that I can make them as secure as possible if I want
> to.

By expensive investment in additional, nonstandard tools?  

(By the way, Ada is in common use in industies where the business is
making sure you DON'T kill people--industries such as air-traffic
control, avionics for civilian airliners, railroad control, and medical
instrumentation.)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Robert C. Martin]

In article <32E6797A.6E21@parcplace.com>, clayberg@parcplace.com wrote:

> Fergus Henderson wrote:
> > I don't know how it got its start there, but I have heard that it got a
> > bit of a boost after the stockmarket crash in '87.  Apparently the
> > volume of shares traded was very high, and many financial programs
> > failed, because the numbers involved were so large that they overflowed
> > various limits, but the Smalltalk programs kept running, because
> > Smalltalk quietly switches to using floating point arithmetic when
> > integer arithmetic overflows.  (Well, that's the rumour anyway.  I
> > don't know how much truth there is to it.)
> 
> Actually, Smalltalk transparently switches to using "large" integers
> that have no limits on size. In fact, it's actually fun to run large
> factorials in Smalltalk to see how large an integer it will generate.
> VisualSmalltalk will calculate the result of "1000 factorial" in a
> second or two and display the results. BTW, the result of that
> expression is: :-)
> 
>
4023872600770937735437024339230039857193748642107146325437999104299385123986290
>
2059204420848696940480047998861019719605863166687299480855890132382966994459099
>
7424504087073759918823627727188732519779505950995276120874975462497043601418278
>
0946464962910563938874378864873371191810458257836478499770124766328898359557354
>
3251318532395846307555740911426241747434934755342864657661166779739666882029120
>
7379143853719588249808126867838374559731746136085379534524221586593201928090878
>
2973084313928444032812315586110369768013573042161687476096758713483120254785893
>
2076716913244842623613141250878020800026168315102734182797770478463586817016436
>
5024153691398281264810213092761244896359928705114964975419909342221566832572080
>
8213331861168115536158365469840467089756029009505376164758477284218896796462449
>
4516076535340819890138544248798495995331910172335555660213945039973628075013783
>
7615307127761926849034352625200015888535147331611702103968175921510907788019393
>
1781141945452572238655414610628921879602238389714760885062768629671466746975629
>
1123408243920816015378088989396451826324367161676217916890977991190375403127462
>
2289988005195444414282012187361745992642956581746628302955570299024324153181617
>
2104658320367869061172601587835207515162842255402651704833042261439742869330616
>
9089796848259012545832716822645806652676995865268227280707578139185817888965220
>
8164348344825993266043367660176999612831860788386150279465955131156552036093988
>
1806121385586003014356945272242063446317974605946825731037900840244324384656572
>
4501440282188525247093519062092902313649327349756551395872055965422874977401141
>
3346962715422845862377387538230483865688976461927383814900140767310446640259899
>
4902222217659043399018860185665264850617997023561938970178600408118897299183110
>
2117122984590164192106888438712185564612496079872290851929681937238864261483965
>
7382291123125024186649353143970137428531926649875337218940694281434118520158014
>
1233448280150513996942901534830776445690990731524332782882698646027898643211390
>
8350621709500259738986355427719674282224875758676575234422020757363056949882508
>
7968928162753848863396909959826280956121450994871701244516461260379029309120889
>
0869420285106401821543994571568059418727489980942547421735824010636774045957417
>
8516082923013535808184009699637252423056085590370062427124341690900415369010593
>
3983835777939410970027753472000000000000000000000000000000000000000000000000000
>
0000000000000000000000000000000000000000000000000000000000000000000000000000000
>
0000000000000000000000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000


It is the hallmark of large factorials, that they terminate with lots of zeros.
More interesting yet is that regardless of what radix you convert the factorial
to, providing the radix is not much larger than the factorialized number,
the factorial
will *still* terminate in a lot of zeroes.  

Just thought this thread needed a little hard data.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: OO, C++, and something much better!

[Eric Clayberg]

Robert Dewar wrote:
> Sounds like you rely on testing to ensure reliability

No. I rely on testing to *improve* reliability.

> which sounds pretty dubious to many of us! 

The many of who?? The need for testing prior to deployment is
"dubious"?? I had wondered where many of the high-profile software
failures that the media seizes on from time to time had come from.

-Eric

Re: OO, C++, and something much better!

[David Hanley]

Bob Haugen wrote:
> 

>  The class test methods can then be composed into use-case test methods.
>  So you test everything as-you-go, bottom up, without having to create
> test harnesses, stubs, and other administrative trivia.  So you code
> seldom gets out of control.

	This seems to be a very tenuous statement, at best.  

> Is there any other environment (except Lisp) that enables such dynamic
> testing?

	SML, haskell, etc, allow, it, and they are statically typed. 


-- 
------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[Eric Clayberg]

Robert Dewar wrote:
> an approach in which the development team is not permitted to do 
> any testing!

Jeez. And I thought that approach was proprietary to Microsoft! <GD&R>

-Eric

Re: OO, C++, and something much better!

[David Hanley]

Eric Clayberg wrote:
> 
> Jon S Anthony wrote:

> > Hey, ST is nice - just don't make out that its dynamic typing is as
> > safe as a statically checked strongly typed language in high
> > reliability scenarios.
> 
> Baloney (back at you). There hasn't been a shred of proof presented here
> that supports that supposition. Do you have any? 

	Baloney boomerang.  You've made dozens of counterintuitive claims for
dynamic typing( smalltalk in particular ) and supported zero of them. 
In fact, people on the static typing 'side' of the issue, such as Fergus
Henderson, have provided good data with compelling arguemnts for static
typing.

> Where is your proof
> that apps built in statically typed languages are more reliable that
> dynamically typed languages?

	A good proof would be there the set of errors which can happen in a
statically typed system, as opposed to a dynamically typed syatem, are
fewer.  This is a very simple arguemnt.

------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: What is wrong with OO ?

[Paul Keister]

William Grosso <apuleius@ix.netcom.com> wrote in article
<32ebdcca.1653858@nntp.ix.netcom.com>...
: On Sun, 26 Jan 1997 16:09:42 +1100, gscase@tpgi.com.au (Sean Case)
: wrote:
: >
: >So, C++ must be easy to learn, or else there wouldn't be hundreds of
books
: >about it by people who don't understand it properly.
: >
: >Or, to put it another way, C++ looks easy to learn, but has hidden
pitfalls
: >that bedevil even those who write books on the subject.
Everything involving computers has hidden pitfalls.

: Or, to put it another way, lots of crappy books have been written on 
: C++ because people who don't know much about it have decided
: to demonstrate their ignorance (and make a quick buck or two). 
: 
: Why this reflects on C++ rather than the authors is pretty much a 
: mystery to me. 
C++ was designed so that it could be learned in stages, to that experienced
programmers (particularly C programmers) could use individual features of
the language as they are ready.  Unfortunatley, many people choose to write
books while they are in the beginning stages of learning C++.

For some of us, the love affair with C++ begins with the perception that
just by using member functions and inheritance in our procedural code,
things get clearer, and code gets easier to maintain.  Some people never
get past this stage(look at the Microsoft Foundation Classes, for
instance).  I my case, it took years for me to reach a level of
understanding where I was able to realize my ignorance.

I consider this to be a real strength of C++ and a key factor in its
overwhelming popularity.  But it does have a downside, which is that
beginner C++ programmers tend to be overconfident.

Writing a book with a title "Learn C++ in 29 Days" is the result of
calculating deception on the part of the author and/or publisher.  But when
someone buys the book, reads it in 29 days, and then has enough confidence
to consider themselves a C++ expert, you have to at least partly blame the
accessibility of the languges.

I don't think this is a bad thing, just a fact of life, and a natural
consequence of a language that is so woderfully accessible.

-- 
Paul Keister
        "opinions express are generally the
          exact opposite of my employer"
   http://www.crl.com/~diyall/husband

Re: What is wrong with OO ?

[Dann Corbit]

Following that line of reasoning:
There are thousands of books on elementary arithmetic.  Many times as many
as the number of C++ books.  That must mean that leaning elementary
arithmetic is only for Ph.D. candidates.  Certainly not for young children.

Your argument is NULL.

Try reading one of Steve Heller's books on C++.  They are designed so that
absolutely anyone can understand.  I am not saying that C++ is the easiest
thing on earth to learn.  Sometimes, there is difficulty associated with
learning (even elementary arithmetic has perils for those who have not yet
grasped all nuances).  Learning C++ is not so difficult that a capable high
school student cannot learn it.

Sean Case <gscase@tpgi.com.au> wrote in article
<AF1132469668D5B8@rd-ppp-072.tpgi.com.au>...
> In article <E413nz.9IA@research.att.com>,
> bs@research.att.com (Bjarne Stroustrup) wrote:
> 
> >I think that if C++ was as hard to understand and use as some people
claim,
> >it would have failed to become popular in the first place and would have
> >vanished under the continuous barrage of fair and unfair criticism -
despite
> >its (eventual) popularity.
> 
> and also
> 
> >I have often found myself wondering if the C++ wouldn't have been much
better
> >for all concered had there (just) been two dozen good C++ books instead
of
> >the 400+ books that mostly fail to teach the basic principles and mostly
> >lead students and programmers astray.
> 
> So, C++ must be easy to learn, or else there wouldn't be hundreds of
books
> about it by people who don't understand it properly.
> 
> Or, to put it another way, C++ looks easy to learn, but has hidden
pitfalls
> that bedevil even those who write books on the subject.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "jeffries" == Ronald E Jeffries <jeffries@ic.net> writes:

jeffries> On 25 Jan 1997 02:07:04 +0000, piercarl@sabi.demon.co.uk (Piercarlo
jeffries> Grandi) wrote:

piercarl> Let's start with the nature of exceptions. The first point is
piercarl> that if a procedure implements a total function then it will
piercarl> never have an exception.

piercarl> Therefore exceptions arise only and only if a procedure
piercarl> implements a partial function, and arise only and only when
piercarl> the inputs to a procedure are outside its domain.

jeffries> Yes ... and then you go on to make the function more robust,
jeffries> which would be a good thing when it's practical.  But as you
jeffries> point out, the exceptions arise when the inputs are out of the
jeffries> range contemplated by the function as written.

jeffries> Exceptions, however, whether represented as objects or long
jeffries> jumps, are about handling the unexpected.

Not quite -- they are precisely about handling the *expected*, but
*undefined*. By definition you cannot handle the unexpected, I would
say.

[ ... ]

jeffries> In a project I'm presently working on, the input routines try
jeffries> to handle all the errors.  Then when the application definers
jeffries> decided what kind of notifications they wanted on input
jeffries> errors, we had to go in and edit the input routines and change
jeffries> them all around to get the job done.  Had they just thrown an
jeffries> exception, we could have fielded the exception where we wanted
jeffries> to, and filed our notifications and gone on.

Ah, but that's precisely a good example that shows that exception
handling (a terrible misnomer) is about dealing with the expected, but
undefined. It is expected that the ``user'' will do strange things, but
since it is as yet undefined what strange things will happen, one punts
to an handler define by a dynamic-context, and this is the very reasons
for having dynamically scoped identifiers.

Put another way exception handling is when the required precondition of
a procedure is weaker than that of the procedure one actually is in a
position to write. The difference is then filled in by calling
dynamic-context dependent ``handlers''.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "bobduff" == Robert A Duff <bobduff@world.std.com> writes:

bobduff> In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
bobduff> Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:

piercarl> The obvious and correct solution is to make the name of the
piercarl> procedure dynamically scoped; then it can be redefined
piercarl> whenever this is needed.

bobduff> How about this: The exception-handler is a procedure that is
bobduff> passed to the procedure that detects the error.  So, in your
bobduff> sqrt example, the sqrt function would take a Float parameter,
bobduff> and a function to call in case the Float is negative.  This is
bobduff> essentially how Smalltalk does things.  If you allow defaults
bobduff> on parameters, then you can make the default handler be "print
bobduff> out a message and kill the program" or "enter the debugger" or
bobduff> whatever.  So callers only have to worry about it if they want
bobduff> to do something special on sqrt(negative).

bobduff> Is this not pretty much equivalent to your dynamic-scoping
bobduff> scheme?

It is indeed entirely equivalent for that is a (xxx-reduction it the
technical term, I don't remember offhand which greek letter stands for
xxx), a way to transform global (dynamically scoped) variables into
procedure parameters.

If one does not like global variables, dynamically scoped or not, one
can transform them into parameters to all procedures that access
them. But then for all their awfulness global variables, and even
dynamically scoped global variables, are useful, in the sense they are
merely convenient, for the xxx-reduction involves a bit more verbiage.

With non-too-clever implementations adding defaulted extra arguments can
also result in distinctly inferior code, because it involves passing an
extra argument for each potential ``exception'' one wants to handle.

Consider for example floating division: it would require at least three
extra ``implicit'' arguments/parameters (overflow, underflow, illegal
divisor).

bobduff> And it has the advantage that the relevant information is in
bobduff> the specification of the procedure that wants to "raise" the
bobduff> exception.

This is not a big advantage; one can achieve the same effect by
requiring, as some languages do, a procedure/module to ``import''
explicitly any global (or fluid) variables it will make use of.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "bobduff" == Robert A Duff <bobduff@world.std.com> writes:

[ ... ]

bobduff> What you say above is the whole point of exceptions -- one
bobduff> piece of code detects an error, and a different piece of code
bobduff> decides what to do about it.  And Mr. Grandi's scheme is just
bobduff> as good as the C++/Ada scheme, in this regard.  (I'm not sure
bobduff> why Mr. Grandi thinks his scheme is so vastly superior,
bobduff> though.)

Actually, it's not *my* scheme, it has been known for thirty years or
so; and then it is not quite "vastly superior", it is just the right
thing to do; my point is that:

  piercarl> So, basically *everything* is wrong (and clumsily so) with
  piercarl> the ``C++'' exception-as-object system:

  piercarl> * the name of the exception class should be that of a
  piercarl>   dynamically scoped procedure.

  piercarl> * an exception object is really just a clumsy and silly way of
  piercarl>   specifying an argument list to that dynamically scoped
  piercarl>   procedure.

  piercarl> * non local control transfers are then mandatory.

These things are wrong because they involve a clumsy and limited
mechanism. Dynamically scoped identifiers are usuful for a number of
cases where actions must depend on the program context; dynamically
scoped variables, not just procedures, are very useful too. Non local
control transfers are also very useful in their own right.

Now, ``exception handling'' presents as an ad hoc, and often pretty
ungainly mechanism, a particular, and restrictive, combination of the
fundamental concepts of dynamic coping and non-local control transfers.

It is much better to provide the two things separatley, for this allows
for example ``exception handling'' _without_ forcing control transfers,
and control transfers without necessarily involving dynamically scoped
identifiers. And then runtime parametrization via dynamically scoped
variables...

But really the biggest problem of the mechanism is that it presents as
something complicated and special, to the point of requiring its own
control structure, chapter in the book, papers, and so on, what is an
entirely simple thing, as long as one presents it as: dynamic scope
+optional control transfer.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "bobduff" == Robert A Duff <bobduff@world.std.com> writes:

bobduff> In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
bobduff> Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:

piercarl> The obvious and correct solution is to make the name of the
piercarl> procedure dynamically scoped; then it can be redefined
piercarl> whenever this is needed.

bobduff> How about this: The exception-handler is a procedure that is
bobduff> passed to the procedure that detects the error.  So, in your
bobduff> sqrt example, the sqrt function would take a Float parameter,
bobduff> and a function to call in case the Float is negative.  This is
bobduff> essentially how Smalltalk does things.  If you allow defaults
bobduff> on parameters, then you can make the default handler be "print
bobduff> out a message and kill the program" or "enter the debugger" or
bobduff> whatever.  So callers only have to worry about it if they want
bobduff> to do something special on sqrt(negative).

bobduff> Is this not pretty much equivalent to your dynamic-scoping
bobduff> scheme?

It is indeed entirely equivalent for that is a (xxx-reduction it the
technical term, I don't remember offhand which greek letter stands for
xxx), a way to transform global (dynamically scoped) variables into
procedure parameters.

If one does not like global variables, dynamically scoped or not, one
can transform them into parameters to all procedures that access
them. But then for all their awfulness global variables, and even
dynamically scoped global variables, are useful, in the sense they are
merely convenient, for the xxx-reduction involves a bit more verbiage.

With non-too-clever implementations adding defaulted extra arguments can
also result in distinctly inferior code, because it involves passing an
extra argument for each potential ``exception'' one wants to handle.

Consider for example floating division: it would require at least three
extra ``implicit'' arguments/parameters (overflow, underflow, illegal
divisor).

bobduff> And it has the advantage that the relevant information is in
bobduff> the specification of the procedure that wants to "raise" the
bobduff> exception.

This is not a big advantage; one can achieve the same effect by
requiring, as some languages do, a procedure/module to ``import''
explicitly any global (or fluid) variables it will make use of.

Re: OO, C++, and something much better!

[matthew mclellan]

Nick Leaton (nickle@calfp.co.uk) wrote:
: Roy Phillips wrote:
: > ... More problematical is
: > the
: > accidental substitution, for example of an operation with same name but
: > an
: > entirely differant meaning (for example, the terms 'interest' (financial
: > domain) and 'interest' (marketing domain)) - blame the English language
: > if
: > you will, but without semantic specification (i.e., Eiffel assertions)
: > the
: > whole thing is a can of worms.
: > 

: If we take two classes, car and array. We have an array of cars and car
: is comparable. We can then have a sort implemented in array and sort
: cars. But if we wish to sort cars by size or price, then it becomes a
: little more difficult. You have two meanings to comparable for a car.
: Personally, I'm not sure of the best way to approach this problem but I
: suspect it would involve a sorter class, with price_sorter and
: size_sorter classes derived from the base class sorter.
: -- 

: Nick

What about deriving car_array from array, and overriding the sort method?

Matt
Raytheon E-Systems

--The opinion(s) expressed above are mine, and not at all related to Raytheon
	E-Systems

Re: OO, C++, and something much better!

[Jun Nolasco]

No wonder so many softwares today look more like betas than 
shipping-quality products. Has anyone heard about the recent story 
about a certain product that had bug fixes released because the 
previous bug fix contained bugs? :-)


						Jun Nolasco
						nolasco@inx.net

Re: OO, C++, and something much better!

[Robert A Duff]

In article <E4oMBG.62@jvdsys.nextjk.stuyts.nl>,
Jerry van Dijk <jerry@jvdsys.nextjk.stuyts.nl> wrote:
>I keep wondering, why all this heated debat? Why try to convince each
>other the the language you like best is the ideal for everything ?

There's no point in that, I agree.

>Isn't this whole discussion futile since programming languages are just
>tools, and not every problem looks like a nail ?

No, no, and no!  A language is not "a tool".  It is a *collection* of
perhaps-related tools.  If you hand me one toolbox, containing a hammer
and a saw, and another toolbox, containing a screwdriver and a set of
socket wrenches, and make me choose between them, it's perfectly
reasonable for me to say, "Hey, I wanted a hammer and a wrench."  To me,
that's what this debate is about.  I *really* want Ada's type safety (at
compile time, in many cases) and Smalltalk's flexibility and simplicity.
I want both.

Don't tell me, "If you choose the hammer, you can't have the wrenches."
I think it's technically feasible to have both.  I think the idea that a
programming language is a single tool, take it or leave it, as is, is
bogus.

>Smalltalk would not exactly be my first choice if I had to built a large
>reliable system. Neither would Ada be my first choice for developing
>a PC GUI front-end.

But suppose I want to build a large reliable system with a GUI front end?

>... But I have developed a banking application in which the
>presentation- and application layers were written in Smalltalk, while
>the functional- and interface layers were written in Ada.

OK, that's an OK answer, given the current state-of-the-art, but there
are serious costs to interfacing between the two.  I claim that it's
possible to design a programming language that supports both at the same
time, without the interfacing difficulties.

Interfacing between two different languages is a serious problem.  The
design of Ada 95 goes to a great deal of trouble to make interfacing
between Ada and C (etc) as easy as possible, but it's still painful.
Silly little things, like whether strings are null-terminated, or carry
their bounds with them.

So I don't buy the idea that you can just choose whatever language is
best for each module, and then paste them together.

- Bob

Re: OO, C++, and something much better!

[Ell]

Robert A Duff (bobduff@world.std.com) wrote:
: In article <dewar.854377413@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
: >On the other hand, it is quite possible to generate high reliability code
: >with no testing whatsoever.
 
: I skept.
 
: > ...For more information on this possibility (which
: >often seems almost incredible to the test-debug crowd), read up on the
: >cleanroom approach to generating software, an approach in which the development
: >team is not permitted to do any testing!

Not having the same team that creates code do the testing doesn't mean the
project doesn't carry or see the importance of testing.

Elliott

: It's incredible to me, and I don't count myself among the "test-debug
: crowd".  I count myself among the "static type checking, and even
: better, formal verification" crowd.  Nonetheless, whatever you've proven
: at compile time, I want to see it work.
: 
: - Bob
: 

Re: OO, C++, and something much better!

[Don Harrison]

Eric Clayberg writes:

:Don Harrison wrote:
:> Gee, Eric. It seems like you versus the whole static typing community. :(
:
:Hey, it looks like a couple of other Smalltalk developers are jumping
:into the fray as well. :-)

I'm not a Smalltalker although I might appreciate where you're coming from. :)
I'm more familiar with Eiffel and (less so) with Ada. 


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Tim Ottinger]

On Mon, 27 Jan 1997 17:36:03 -0500, "Norman H. Cohen"
<ncohen@watson.ibm.com> wrote:

>No, I've such comparisons between Ada and C/C++ (see, for example
>http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html,
>which shows the same programmers developing Ada code and C code, and
>producing the average Ada line for 60% of the cost of an average C line,
>with only 1/6 as many defects in the delivered code), but not between
>Ada and Smalltalk.  I would certainly be interested in such
>comparisons.  If there are any Smalltalk versus C comparisons, it would
>be interesting to observe whether the same factors are achieved (with
>the caveat that this is not as controlled an experiment as a direct
>comparison of Ada and Smalltalk code written by the same programmers).

Just a note on per-line measurements across languages: Don't buy it.
I saw one where it "proved" that COBOL or ASSEMBLY were the better 
quality languages to use and that it was unjustifiable to use Ada
and C programmers, who may cost $100s per line of code.

The trick was that the errors and cost *per*line*of*code* was lower
for assembly and for cobol. The reason? They took far more lines of
code to do the same job. C takes very few lines of code to do most
low-level functions. As a result, it screws up the metrics horribly.
Ada is also cursed with some fair economy.

I think C++ rather varies between being more and being less concise
than C depending on what you're looking at. I don't know how to even
compare these fairly similar languages in terms of 'per line' fairly.

I think with Java we'll find the same. 

I'm not sure how to measure Smalltalk, or even what to measure it
against.

I'm fairly well convinced that "per class" and "per line" and even
"per project" aren't fair. Probably neither is anything else.

If we had a fair way to compare languages, these kinds of studies
would be very useful.

But even if it were, it surely would do little good to spend the
time and mental cpu cycles to try to convince people that what
they do for a living is stupid and wrong.  

Especially when it's neither immoral nor illegal, and quite
profitable.
-------------------------------------------------------------
Tim Ottinger      | Object Mentor Inc. | OOA/D, C++, more.. 
tottinge@oma.com  | http://www.oma.com | Training/Consulting
-------------------------------------------------------------
"... remember, there are ways of succeeding that we would not
 personally have chosen. "              - Bjarne Stroustrup
-------------------------------------------------------------

Re: OO, C++, and something much better!

[Antoine Trux]

Eric Clayberg wrote:
> 
> Robert Dewar wrote:
> > The idea that you can completely ignore efficiency and then somehow
> > fix it up later by "optimization" is appealing, but naive. if you want
> > efficient, you have think about this requirement from the start. To say
> > that you can deal with this later is very similar to the claim that you
> > can develop in a sloppy hack-away-and-get-it-working mode and then build
> > in reliability later.
> 
> Not true at all. Getting the program "right" and the algorithms correct
> is the most important thing to do first. Premature optimization often
> leads to less than optimal results. You can spend lots of time
> optimizing something up front that in the final analysis would have very
> little impact on your program to begin with. In fact, premature
> optimization can often lead to inflexible, even brittle, designs that
> will cause major maintenance headaches down the road. IMO, it's much
> better to get the program right first, and then optimize any areas that
> are actually affecting performance. Every optimization employed usually
> has a cost and that cost is felt in terms of reduced flexibility and
> loss of genericity.

I would like to point out that the current Smalltalk implementations,
which use dynamic compilation techniques, are very efficient.

However, it seems difficult to have persons who have not recently used
Smalltalk believe this, especially the ones who have a strong background
in computer science! The only efficient way I have found so far to
convince those persons is to show them some of the demos included in
GF/ST (a framework for building Smalltalk applications with graphs).

Now, although most current Smalltalk implementations are more than fast
enough for most of the purposes, it is true that the code produced is
not quite as fast as C code. Sometimes (perhaps once a month, once a
year, or never, depending on what kind of applications you write), you
just have to take the most of every CPU cycle. But even in those cases,
you can usually isolate the time-critical routines, code them in C(++)
or assembler, and call them from Smalltalk. This is possible at least in
the Windows platforms with the major Smalltalk dialects.

This being said, I fully agree with what Eric writes.

Antoine Trux

Re: OO, C++, and something much better!

[traymond]

In <32ED2930.3B92@watson.ibm.com>, "Norman H. Cohen" <ncohen@watson.ibm.com> writes:
>traymond@craftedsmalltalk.com wrote:
>I presume you are using the word "procedural" to mean "not object
>oriented".  However, there is nothing in the example above that suggests
>this.  Perhaps it is the presence of a built-in array type that looks
>unSmalltalk-like to you.  Fine, replace the two integer types with two
>classes called producerID and consumerID, make Producers an object
>belonging to some collection class with an extract method that takes a
>producerID object, and make Consumers an object belonging to some
>collection class with an extract method that takes a consumerID object. 
>My argument remains the same:  It is easy to inadvertently send an
>extract message with a producerID argument to Consumers or an extract
>message with a consumerID argument to Producers.  The incorrect call
>might occur only on some obscure path that testing fails to exercise. 
>Strong typing allows such errors to be caught at compile time.

Agreed, it does.  But, it costs more to do so.  One reason
there is a lower incidence of type errors in smalltalk programs
is that it uses named parameters.  I know that ADA has named parameters
but last time I looked they were not required.  Named parameters are
required in smalltalk for anything other than unary messages and binary 
operators.

The point that most of the smalltalk programmers are trying to make here,
is not that strong typing will not do a better job of catching type
errors earlier than one would in smalltalk, but that because of
other features in smalltalk the incidence of type errors is
much lower and the additional benefit of strong typing would not
be worth the reduction in flexibility.  Furthermore, many of us
realize that smalltalk would benefit by having type-inference
tools to advise us of potential errors.  But, we would use these
as lint-like analysis tools.

One point that I don't think has been brought out well enough
is that smalltalk is incrementally compiled.  So, whenever
I compose a method it is compiled.  Frequently, the state
of my instance variables description is incomplete and
sometimes my method description is incomplete but I can
still compile the method.  Strong typing makes it very
difficult to do this.  Instead, I would have to resort
to using a file based editor and then do the compilation
after my description was sufficiently complete.  I should
also add the value of having an incomplete description in
the environment is that I can use the smalltalk browser and
cross-referencing tools to remind me what I have called things
and what I am doing with them.  If I use a file editor for
this I have scroll up and down, search back and forth, use
grep to find something in a different file, and etc...

Again, it is not that we think strong typing has no benefit,
but we think that with smalltalk and its environment the benefit
of enforced strong typing is not worth the cost.

===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk   *Breakpoints* and *Watchpoints* for
19 Tilley Ave.                  VW and ENVY/Developer 
Newport, RI  02840
(401) 846-6573      traymond@craftedsmalltalk.com
http://www.craftedsmalltalk.com
===========================================================

Re: OO, C++, and something much better!

[Claus Reinke]

In <32E99D64.DB6@parcplace.com> Eric Clayberg <clayberg@parcplace.com> 
writes (citing me):

>> Sorry, but you should definitely *not* base your conclusions about
>> statically typed languages on C,C++,Fortran, etc.

>Fair enough. I will base my conclusions about C++ based on C++. ;-)

>> Try something like Standard ML or Haskell

>When I get the time, I would like to. Are either commercially available?
>If so, where? What about free versions? Thanks.

Both are freely available in various implementations. Both have a
standard.  For Standard ML, there are also some commercial versions.
In view of the newsgroups line of this thread, I will only provide
some basic links here (the first two should suffice to get
information on implementations of these particular languages):

Information on Haskell 

  http://haskell.cs.yale.edu/haskell-report/haskell-report.html

The ML FAQ 

  http://www.cis.ohio-state.edu/hypertext/faq/usenet/meta-lang-faq/faq.html

My own collection of FP links 

  http://www.informatik.uni-kiel.de/~cr/FP.html


By the way, I (thought I) was completely against static type checking
(which I equated with typed languages in general) until I noticed
that it was only the all-or-nothing approach (restrict the language
until it can be statically typed) that caused my disapproval.

Of course, there are other issues, such as explicit type declarations
vs. type inference, or the problems of typing more advanced language
features (including some of object-oriented languages). The latter
seems to be one of the reasons why programming languages haven't
improved so much over the last decade, but it has also been a major
motivation to improve the theory and practice of type systems over
the same period of time.

Personally, I hope this research will lead to languages that are at
least as expressive as those early languages that had to rely
completely on either dynamic typing or explicit type declarations,
but combined with the virtues of mostly static and mostly implicit
type systems (and certainly with improved language designs).

Until this happens (if it does;-), it seems important to spread the
message that none of the current languages is perfect. Programmers
(and language designers) need to keep an open mind for those other
languages (and paradigms) they are not using daily.

Having said this, I tend to find experience reports of practioners in
various languages very valuable, and even more so without the
occasional attempt to compare `my language which I know very well'
with `your language which I haven't read about, too'. Only the
reports provide real information, based on experience which is hard
to collect personally in many different languages. Everybody can then
make his/her own decisions based on the facts provided. However, it
would be nice if these reports would also include `the experienced
programmer's wishlist', i.e., what do I miss most in the language I
know so well (NOT: what those other languages don't have).

This way, it might also be easier to overcome the problems of 
different programming culture, e.g., `I don't want static type systems,
but I could not work without all those tools that help me to analyze
my programs'.

Hope this helps,

-- 
Claus Reinke                                University of Kiel
email: cr@informatik.uni-kiel.de            Department of Computer Science
http://www.informatik.uni-kiel.de/~cr/      Preusserstr. 1-9,   24105 Kiel

Re: OO, C++, and something much better!

[Eric Clayberg]

David Hanley wrote:
> To people who understand programming, and, in particualr, static typing.

That's a mighty arrogant assertion on your part. Are you saying that
folks who use Smalltalk (or, in general, folks who don't agree with your
particular world view), don't understand programming or static typing
for that matter? I understand them both quite well, thank you. Most of
the Smalltalk developers who have entered this thread (myself included)
have extensive programming experience with statically typed languages as
well as Smalltalk. As Terry Raymond said elsewhere in this thread:

"Again, it is not that we think strong typing has no benefit, but we
think that with Smalltalk and its environment the benefit of enforced
strong typing is not worth the cost."

I couldn't agree more.

> Another quick scan of this group would make it equally obvious that
> while some may find these claims intuitive, many other find the same
> claims counterintuitive, and contrary to thier experience.  If we all
> found it intuitive, there's be no discussion, right?

Very true. In fact, it looks like number of folks who find the claims
intuitive and the number who don't are roughly the same in this
discussion. From my point of view, the answer is not as clear cut as you
would like us to believe.

> > OK, then, back it up. So far, *you* haven't *proven* anything.
> I have.

Where? All I see is the same assertion over and over again.

> All other things being equal, there are fewer errors that can
> happen in a static typed system, as opposed to a dynamially typed
> system.  Your refusal to accept this simple arguement makes you appear
> as if you have some kind of religous attachment to your system.

Not at all. It's simply that your "argument" isn't that simple. While
static typed systems will, in fact, prevent certain classes of errors,
you have not proven that dynamically typed languages (like Smalltalk)
don't *also* prevent certain classes of errors. Thus the issue of
"fewer" errors is not very clean cut at all. If you are merely arguing
that a static typed system will have fewer *type* errors in it, then
fine, I can buy that. If you are asserting that this means that there
are fewer errors over all, then you haven't proved anything at all. So,
once again, I ask, where is your proof that Smalltalk is somehow less
reliable for building applications than any arbitrary statically typed
language?

In your prior message you said:

> A good proof would be there the set of errors which can happen in a
> statically typed system, as opposed to a dynamically typed syatem, are
> fewer.

Since you say that this would be a good proof, then why don't you
present the "set of errors" that you see on both sides of the coin and
let us all take a crack at it? Without that, your argument degrades to
so much empty sophistry.

-Eric

Re: OO, C++, and something much better!

[David Hanley]

Eric Clayberg wrote:
> 
> David Hanley wrote:
> > Baloney boomerang.  You've made dozens of counterintuitive claims for
> > dynamic typing( smalltalk in particular ) and supported zero of them.
> 
> Counterintuitive to who? To someone who knows little about Smalltalk?

	To people who understand programming, and, in particualr, static
typing. ;)

	Another quick scan of this group would make it equally obvious that
while some may find these claims intuitive, many other find the same
claims counterintuitive, and contrary to thier experience.  If we all
found it intuitive, there's be no discussion, right?

> It is the claim that Smalltalk
> is somehow less reliable than statically typed languages that I have
> seen zero support for (other than conjecture and innuendo).

	The simple arguemnt follows.

> 
> > In fact, people on the static typing 'side' of the issue, such as Fergus
> > Henderson, have provided good data with compelling arguemnts for static
> > typing.
> 
> He certainly presented some data. It wasn't very clear that it provided
> much support for static typing, however. In fact, his numbers
> (especially the variety of errors that he ran into) only served to make
> me (and, I imagine, most of the other Smalltalk developers in this
> thread) quite happy that I was using Smalltalk (in which, as was pointed
> out in response to his numbers, most of those errors couldn't occur).

	Again, you showed nothing of the sort.  In fact, it seemed that you
don't completely understand the issues involved with a good static typed
system.

> 
> > A good proof would be there the set of errors which can happen in a
> > statically typed system, as opposed to a dynamically typed syatem, are
> > fewer.  This is a very simple arguemnt.
> 
> OK, then, back it up. So far, *you* haven't *proven* anything.

	I have.  All other things being equal, there are fewer errors that can
happen in a static typed system, as opposed to a dynamially typed
system.  Your refusal to accept this simple arguement makes you appear
as if you have some kind of religous attachment to your system.

	Let's start very simply; is the above system true or false?

-- 
------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[Robert I. Eachus]

In article <32ED2448.685A@parcplace.com> Eric Clayberg <clayberg@parcplace.com> writes:

  > OK, then, back it up. So far, *you* haven't *proven* anything. The above
  > is yet another unsubstantiated claim that statically typed systems are
  > somehow more reliable than dynamically typed systems. Show me some proof
  > that Smalltalk is somehow less reliable for building applications than
  > any arbitrary statically typed language.

   Try this.  Build a new aircraft with radical new avionics
requirements, or a vertical takeoff and landing rocket (DC-X), or a
railroad traffic control system for high-speed trains, or run an
air-traffic control system, or anything where the software is large
and complex and it has to work the first time.  Write the operational
software in Smalltalk.  Come back when your software has been proven
in service.

   Langauges other than Ada have been used for this, including Jovial,
Fortran, C and even CMS-2.  But to my knowledge neither C++ or
Smalltalk has been used.  NOT because they are bad languages, but
because in this role it is difficult to do the amount of "bench"
checking required to get someone to foot the bill and take the risk of
actually fielding the software.  Well, not quite true, AT&T has used
C++ in phone switching systems and gotten roundly castigated for it
when the inevitable failures occured.

   By the way, you can write Ada code which uses dynamic dispatching,
and there are some safety-critical systems where it is permitted.  The
same with pointers, dynamic allocations, and tasking.  This is not
about such features, this is about how much confidence can you have
before the software is run.  When it absolutely has to work the first
time, you get very conservative in your design rules.

--

					Robert I. Eachus

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

Re: OO, C++, and something much better!

[Travis Griggs]

Bob Jarvis wrote:
> As a Smalltalk developer there are times where I think I'd like to be able to
> specify the class of a message parameter so that some level of "type
> checking" could be done.  Something like
> 
>         myMessage(String): parm1(String) parm: parm2(Magnitude)
> 
> would indicate that myMessage should answer a String (or some subclass of
> String), that the first parameter should be a String, and the second parameter
> should be a Magnitude.  It would be nice if this was optional - if no classes were
> specified then the system shouldn't try to do any checking.
> 
> However, as a Smalltalk developer I'm also aware that this isn't absolutely

I agree, there have been times I thought this would be nice. The problem
with this (as I see it) is that you just shot reuse a part. Create a
MeasuredValue system (one that associates numerical magnitudes with
units) and you can't throw your new (and very powerful) numbers at your
message. Create a set of objects which represents algebraic math. Same
thing. Create a UserMessage (for internationalization) and throw it in
as your String parameter. Again, kaboom.

I use *these* examples, because I have actually done implementations of
each. And in each case I have been nothing less than delighted at the
polymorphic nature of the system and how well my new stuff interfaced
with the already existing class library.

To really be able to retain this flexibility and still add the type
checking you propose you could take different approaches:

1) You could add the ability to do OR type declarations (i.e. a type is
UserMessage OR String).

2) You could add multiple inheritance, so that if you need to throw an
Algabraic object at a method that expects a Magnitude, you just add
Magnitude to the Algabraic objects list of super classes.

3) You could come up with a typing system that specifies interface (i.e.
an object of a given interface is garanteed to respond to messages a, b,
and c), rather than class implementation.

Each has problems though:

1) assumes that you know (up front) all of the class types that will be
thrown at a method. This doesn't happen. How am I supposed to know when
I design my object (with its typed method(s)) that in a year from now I
will write yet another numerical object that encodes error propogation
(e.g. Geometric Dimensioning and Tolerancing)? BTW: I've done this one
too - dont want anyone to think I'm making up hypothetical examples
here.

2) MI for purposes of reuse is like one of those calculus functions we
all hate (i.e. as the limit approaches infinity type of thing). IOW, as
the set of objects approaches being generically reusable system wide,
all classes end up inheriting from each other. Of course, this is more
than MI, this is Circular inheritance! (i.e. in one place Integer needs
to inherit from MeasuredValue to be used, but in another place
MeasuredValue needs to be inherit from Integer).

3) typing the interface (as opposed to the class representation) is
somewhat better, but it still has problems. In addition to typing the
interface, I've got to make sure that these expected methods return
values that have typed interfaces (i.e. method 'a', which incoming
parameter must respond to, must return an object that responds to
messages c, d, e). And what if two objects implement method 'a' with
totally different behaviors and intended uses (e.g. both Magnitude and
Set respond to +).

-- 
Travis or Kerrin Griggs
Key Technology   (509) 529-2161
tkc@bmi.net         (509) 527-8743

Re: OO, C++, and something much better!

[Eric Clayberg]

David Hanley wrote:
> So smalltalk will happily pass a message to the nill object, and the
> progrm will chug along just fine?

Most the most part, yes. The nil object is just like any other object in
the system. It is also the default placeholder for any uninitialized
variables. There are lots of examples where sending messages to nil or
passing nil as an argument is just fine. It is only when you send a
message to nil that it does not expect that you have a problem. Even
then, it depends upon what kind of exception handlers the developer has
set up whether the program will chug along just fine or simply report
the error, write an error log and halt the program (in any case, a core
dump is rarely the outcome).

-Eric

Re: OO, C++, and something much better!

[Robert C. Martin]

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


In article <32E8DC1C.4871@rase.com>, tansel@rase.com wrote:

> Contrary to what people say, type checking is against the nature of
> object oriented systems development. Remember, in OO, we only care about
> the interface of the other object. 

This statement is oxymoronic.  A type is defined by the interfaces it
accepts.  There is no other definition of a type.  Thus, the statement 
above could be translated as follows:

"...type checking is against the nature of OO...in OO we conly care about
the type of the other object."

In fact, type checking is at the very *heart* of OO.  The current debate
has nothing to do with whether types ought to be checked or not, indeed they
*must* be checked.  The current debate is simply arguing about *when* those
types will be checked.

In ST, users send messages to objects.  They must be reasonably sure that
the object they are sending the message to can respond to that message.  So
they are performing the type checking in their head.  The language performs the
same check later on, at run time.

In C++, the compiler insists that all types are declared, so that when
a programmer sends a message to an object, the compiler can be 100% certain
that the object can accept that message.  Thus, no run time check is 
necessary.

> In fact it should be an OO sin to ask
> the type, because, in theory, we don�t want to get intimate with objects
> we are interacting apart from their interface. 

We typically don't have to ask the type of an object.  In ST, the language
will do the asking for us at run time.  In C++ the compiler has done it 
at compile time.

However, there are times both in ST and C++ where we are given an object
of unknown type and we do not want to send that object a message until
we *know* it can deal with it.  Thus in ST we use 'respondsTo' and in
C++ we use 'dynamic_cast'.  Both of these are essentially run time type
checks that can be applied by the programmer.

> We only want to know the interface. 

Which *is* the type.  However, in ST we are interested only in a subset
of the interface; thus we are interested only in that portion of the 'type'
that responds to our message.  In C++ we approximate this ability to be
interested in partial types by using MI and creating true partial types.
(i.e. supertypes that declare only part of a particular subtype)  This
is why MI is not important to ST, but is critical to C++.

> one obvious solution that
> comes to mind is to offer an interface signature, that will indicate
> that an object really offers all the services that it is required. This
> will guarantee that type of the object can change any time as long as
> the public interface signature of the object does not change. Then any
> object binding to this object can ask its signature rather than type to
> verify that
> the interface is the same as this object was created. This has run time
> costs associated with it, but solves many problems that are associated
> with type checking. Furthermore it is not practical for many ADT based
> languages.  

In fact it is identical to dynamic_cast in C++ where the public interface
that you mentioned is an abstract superclass of the object being checked.
Java has a similar mechanism (isInstanceOf) and so does Eiffel (=?).  

> In most ADT based languages type checking is done at the compile time.
> This approach gives us a lot of safety, but also has an expensive price
> tag in terms of flexibility and compromise of object oriented approach.

No, the cost is not in flexibility.  The cost is in the time required
to declare all the types and manage the dependencies appropriately.
Flexibility is not encroached upon. 

The development time argument is a strong one.  The declaration of 
all types is somewhat onerous.  Java helps this out by building
the declarations into the implementations, but the dependency management
issues is still present.  In ST, declarations and dependency management are 
much less of a concern since all declarations are implied and none are checked
until runtime.

On the other hand, the benefit of static languages is in the fact that
they can be made very run time efficient, by doing all the type checking
at compile time.  Morevoer, once compiled we *know* that there are no
type errors lurking in the runnable code.  (Unless purposely put
there by casts).

> There can not be much done to increase flexibility of such languages.
> One of my solutions for flexible systems such as Smalltalk is, to use
> high level tools to automatically embed type or interface checking code
> in development and testing phase, and after all tests are done, to
> remove these checks automatically, allowing systems to run without type
> checking once they are in production. This gives me best of the both
> worlds."

Actually it give the worst of both worlds.  The lack of type checking is
of benefit only during development.  Once the program is known to work,
type checking is useless.  By putting a type-checker in front of the 
Smalltalk compiler (i.e. stlint ;^) you effectively introduce all the
disadvantages of C++ declarations and dependency management without providing
the benefit of efficient execution.  Once you remove the stlint, the run
time system is still doing run-time type checking (i.e. looking up method
invocations)

> Eighth: Performance. Actually this is a non-issue. I never suffered from
> performance apart from screen drawing, or number crunching. 

In most cases ST preformance *is* a non-issue.  But there is a large class
of applications that require hard real time performance, and which will
not be able to tolerate ST.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: OO, C++, and something much better!

[David Hanley]

Eric Clayberg wrote:
> 
> David Hanley wrote:
> > So smalltalk will happily pass a message to the nill object, and the
> > progrm will chug along just fine?
> 
> Most the most part, yes. The nil object is just like any other object in
> the system. It is also the default placeholder for any uninitialized
> variables. There are lots of examples where sending messages to nil or
> passing nil as an argument is just fine.

	There are losts of cases in C/C++,java,etc where passing null as an
argment is just fine as well.

>  It is only when you send a
> message to nil that it does not expect that you have a problem.

	No kidding.  I still don't understand your implication that it is ok,
and has somethin to do with dynamic typing.

>  Even
> then, it depends upon what kind of exception handlers the developer has
> set up whether the program will chug along just fine or simply report
> the error, write an error log and halt the program (in any case, a core
> dump is rarely the outcome).

	So are you under the impression that ST is the only language that can
trap null pointer writes?  And what exactly does this have to do with
static and dynamic typing?

-- 
------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32E8EB48.2C0C@parcplace.com> Eric Clayberg <clayberg@parcplace.com> writes:

> Are you saying that Ada is incapable of propagating errors to the end
> user? All errors are guaranteed to be fixed prior to deployment? That
> would be remarkable.

It would not be merely "remarkable", it would be wog-boggling amazing.
Alas, it is not true.  OTOH, other things being equal (quality of
engineers, programmers, etc), it does appear that there tends to be a
very "low" number of these errors with Ada as the implementation
vehicle.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E4p4qH.4A@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> In article <E4oMBG.62@jvdsys.nextjk.stuyts.nl>,
> Jerry van Dijk <jerry@jvdsys.nextjk.stuyts.nl> wrote:
> >Smalltalk would not exactly be my first choice if I had to built a large
> >reliable system. Neither would Ada be my first choice for developing
> >a PC GUI front-end.
> 
> But suppose I want to build a large reliable system with a GUI front end?
> 
> >... But I have developed a banking application in which the
> >presentation- and application layers were written in Smalltalk, while
> >the functional- and interface layers were written in Ada.
> 
> OK, that's an OK answer, given the current state-of-the-art, but there
> are serious costs to interfacing between the two.  I claim that it's
> possible to design a programming language that supports both at the same
> time, without the interfacing difficulties.

Actually, that is more than an OK answer.  It is highly unlikely that
a single "theory" (pgmlan in this context) can encompass and express
all possible view points on a particular subject and maintain any kind
of coherency itself.  I'd go further and say it is out right ludicrous
to make such a claim.  It has never been done - not even in things
that actually _are_ sciences and engineering (forget about software
and computer "science") - and there is no evidence whatsoever that it
_can_ be, let alone _will_ be.  The idea of "one language for all
things" is every bit as silly as "_the_ theory of everything".

So, it makes a lot of sense to concentrate on working out explicit
well defined interface points between PL semantics where the
"impedance mismatch" is controlled and "easily" managed.  Of course
this would require real communication and cooperation between the
various camps - wow, what a novel idea...

Notice that something like CORBA is not really the same thing (it
functions a bit more like Ontalingua in the KE/KA field).  It tries to
solve this problem by being a kind of "universal common denominator"
for describing interfaces with a lot of automated assistance in
translating between it and various targets.  While it does work (even
between ST and C), and basically is better than anything else
currently available, something like Ada's _Interfaces_ subsystem for
each language would have far less "semantic impedance mismatch"
problems.


> Interfacing between two different languages is a serious problem.  The
> design of Ada 95 goes to a great deal of trouble to make interfacing
> between Ada and C (etc) as easy as possible, but it's still painful.

Agreed, but it is pretty trivial compared to the next task up the
ladder: that of having a module's contextual semantics spelled out and
codified as part of its overall semantic description, thereby allowing
at least the possibility of true parts catalogues.  Don't hold your
breath...


> So I don't buy the idea that you can just choose whatever language is
> best for each module, and then paste them together.

Then the software biz is never going to get beyond the artisan or
blacksmith stage it's been stuck in for the last 35 odd years.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Matt Kennel]

Eric Clayberg (clayberg@parcplace.com) wrote:
: So,
: once again, I ask, where is your proof that Smalltalk is somehow less
: reliable for building applications than any arbitrary statically typed
: language?

There is no "proof", but I strongly suspect that most statically typed
languages possess more assertions in idiomatic code than ones that do not.

Re: OO, C++, and something much better!

[Matt Kennel]

Robert C. Martin (rmartin@oma.com) wrote:
: In article <32E8DC1C.4871@rase.com>, tansel@rase.com wrote:

: "...type checking is against the nature of OO...in OO we conly care about
: the type of the other object."

: In fact, type checking is at the very *heart* of OO.  The current debate
: has nothing to do with whether types ought to be checked or not, indeed they
: *must* be checked.  The current debate is simply arguing about *when* those
: types will be checked.

: In ST, users send messages to objects.  They must be reasonably sure that
: the object they are sending the message to can respond to that message.  So
: they are performing the type checking in their head.  The language performs the
: same check later on, at run time.

: In C++, the compiler insists that all types are declared, so that when
: a programmer sends a message to an object, the compiler can be 100% certain
: that the object can accept that message.  Thus, no run time check is 
: necessary.

I disagree, the issue is larger than this. 

A statically typed language provides type constraints about the interpretation
those human readable things called 'symbols' and their implementation as
variables.

These type constraints, as implicit assertions, don't exist otherwise.

The ``time of checking'' is a technological consequence of these assertions,
but one could write Eiffel compilers with smalltalk-style incremental
byte-coded highly homogeneous representations which delay typechecking until
runtime, and still have more things to check.  

Assignment, whether implicit (argument substitution) or explicit, is a point
requiring a check, not just subroutine calls. 

***

My discomfort with a fully dynamic typing scheme is that it depends on
the particular implementation exigencies of some routine to signal whether
something is 'right or not'.  For instance, one could pass things which
accept the "doit_one" message to routine X, if this particular X happens
to call "doit_one" in its implementation.

Now, I wish to make a subclass with routine X', which now calls "doit_two"
in addition to "doit_one".  All of a sudden, I am not guaranteed
substitutability, because some objects were passed to routine X which,
contrary to my expectation, didn't uphold "doit_two".  So subclassing
in Smalltalk doesn't necessarily guarantee a true subtype. 

And if routine "X" were just a temporary 'debugging' stub very little check
would be done.

I wish to worry less about the particular details of the contents of
subroutines, and be able to conceive of abstract categories of classes and
behaviors. 

I would find type-checking most useful in extending an existing program
(reminding me of implicit promises), more than initial development when
I could remember all the pieces at once. 

: Robert C. Martin    | Design Consulting   | Training courses offered:

Re: OO, C++, and something much better!

[Jacqueline U. Robertson]

Keywords: 
Cc: 

In article <32EE20A3.755D@netright.com>,
David Hanley  <david_nospam@netright.com> wrote:
>> 
>	I have.  All other things being equal, there are fewer errors that can
>happen in a static typed system, as opposed to a dynamially typed
>system.  Your refusal to accept this simple arguement makes you appear
>as if you have some kind of religous attachment to your system.
>
>	Let's start very simply; is the above system true or false?
>
Depends - are we including C and C++ here ?  In either language, I have static 
type checking, but I can use casting to defeat that type checking - thus,
I get NONE of the benefits of static typing, and also none of the benefits
of dynamic checks (as is done in Smalltalk).  

IMHO, he arument runs like this:  In the case of Smalltalk, the 'cost' of
adding static typing  ( in terms of reduced flexibility and slower
development time ) is not worth the 'gain'of static typing.  To some
extent, this is a subjective statement - but having used C, C++,
and Smalltalk extensively, IMHO development is more rapid and
more safe (less error prone) in Smalltalk than in C or C++.

Howvere, choice of language is not that simple.  If I need to build a 
DLL callable from the OS, then my language of choice is not an option.
As with all things, pick the right tool for the right job.



James A. Robertson
email: jamesr@parcplace.com
phone: 410 952-0471

<note that I am posting through my wife's account.  I don't claim to speak for
her>






















>-- 
>------------------------------------------------------------------------------
>David Hanley, Software Developer, NetRight technologies.
>My employer pays me for my opinions; nonetheless he does not share all
>of them
>E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[Alan Lovejoy]

Fergus Henderson wrote:
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> >Fergus Henderson wrote:
> >>
> >> Here's a more detailed breakdown.
> >
> >To which I wish to add some comments and analysis:
> >
> >>         syntax errors: 16
> >>         type errors: 83
> >>                 - errors in type declarations: 13
> >
> >Doesn't apply to Smalltalk.
> >
> >>                 - type errors other than errors in type declarations: 70
> >>                         - syntax related: 14
> >May or may not apply to Smalltalk.  Can't
> >tell without more specifics.
> 
> I gave some specifics below; these would not apply to Smalltalk.
> 
> >>                         - wrong procedure name: 11
> >
> >The Smalltalk compiler will complain when you compile
> >a method that sends a message with no implementors.
> >So this would only apply to those cases where the
> >"wrong" name matched that of some other method.
> >I would assume that all such errors out of 11 would be
> >caught by the Smalltalk compiler (about 99% would be
> >caught overall).
> 
> Fair enough.
> 
> >>                         - wrong constant name: 4
> >>                         - wrong variable name: 4
> >
> >Were these "wrong" names simply undeclared,
> >or declared but wrongly typed?
> 
> In the case of the wrong constant names, I didn't record
> these distinctions, but my guess is that probably they were
> mostly simply undeclared (and hence would have been
> detected at compile time in Smalltalk).
> 
> In the case of the wrong variable names, it's a little more
> complicated.  In Mercury, variables do not need declarations.
> Most errors involving variables are caught by either singleton
> variable warnings and/or by mode errors (both of these are counted
> in the "others" category below).  Three of these four cases caught by
> type checking involved using an incorrect name that was also the name
> of another variable.  I think they would also have occurred in
> Smalltalk (and would not have been detected until run time).

What do you mean by "using an incorrect name that was also the name of
another variable"?  In general, a Smalltalk variable can only have one
name, and a name can only be bound to one variable. You cannot declare two 
variables with the same name in the same scope. You can, however, redeclare 
a variable in a BlockClosure that overrides a variable declared in an outer 
scope--but you will be warned of this.

So if by "using" you meant "declaring," then this can't happen without
warning.

However, if by "using" you meant "referencing," then such could in fact
occur.  But the data I collected for Smalltalk did not show this sort of
error as occuring with much frequency.  I think this is because Smalltalk
uses global variables far less than is common in other languages, so the
probability that a typo in a variable name will accidentally match some
other declared variable is therefore less.

> The fourth case involved trying to use the same name for two different
> variables.  I'm not sure whether that one would have occurred in Smalltalk.
> I guess it would depend on whether the programmer noticed that there
> was already a declaration for that variable.

As noted above, this can't occur in Smalltalk without warning.  This does
not happen often.  I can't remember the last time I encountered it, and
I write several hundred k-bytes of Smalltalk code every week.

> > How many of the
> >"wrongly typed" ones involved type differences
> >that don't matter in Smalltalk (ie, long vs. short
> >numbers, different types of Collection)?
> 
> I doubt if there are any of these sort of errors.
> Mercury has a quite simple type system.
> For example, there is only one integer type in Mercury.

How many Collection types?  Are integers interchangeable with floats,
and complex numbers, and fractions, and...

> Mercury is not C++.

Good!  I'm sure your happy about that :-).

> >I will ssume that
> >1 of these 8 errors would cause a Smalltalk program to
> >produce the wrong result or fail (the Smalltalk compiler
> >will catch any undeclared references, and about 92% of type
> >incompatibilities in C++ are cases that will "just work fine"
> >at runtime in a Smalltalk program).
> 
> As mentioned above, I think that at least 3 of these 8 errors would
> occur in Smalltalk and not be caught by the compiler.

Except that my data show 2% or less as the rate of occurrence for "type" 
errors **IN SMALLTALK**.  I have been keeping track of this in my own 
work since last May.  I think trying to extrapolate what you measure
in Mercury programming to Smalltalk makes about as much sense as
applying the Smalltalk data to Mercury: interesting, but only an
approximation at best.

> >>                         - argument has wrong type: 7
> >
> >How many of these involved type differences that don't
> >matter in Smalltalk?
> 
> Probably none of them.

Are integers and floats interchangeable in Mercury?  What about Arrays,
Lists and SortedCollections?  Dictionaries implemented using either 
HashTables or BinaryTrees?

> >And how many were caused by the fact
> >that the Algol-style function call syntax makes it so easy
> >to get the arguments wrong?
> 
> Again, probably none of them.

Does Mercury use Algol-style function call syntax?  That is, "f(x, y, z, ...)"?
If so, the fact that Smalltalk will have fewer cases of "wrong argument" due
to its superior function call (message send) syntax is not a debatable point.
It's a fact.

> > So I would estimate that of the 83 type errors, only 1 of them would
> > show up at runtime in a Smalltalk program.
> 
> Well, I think your estimate is wrong.  I would estimate that
> 11 of them would show up at runtime.
>
> This would more than double the total number of runtime errors.

I disagree.  I think your estimate is biased by your lack of experience
using Smalltalk, and by the fact you are trying to extrapolate from
data about programming in Mercury to Smalltalk--a very different language
and programming environment.

> In addition, I estimate that there are probably another 9 errors in
> the "others" category, e.g. uninitialized variable errors, that are
> caught by static analysis in the Mercury compiler but which are unlikely
> to be caught by Smalltalk compilers.  Furthermore, just as there are
> errors that occur only in Mercury, and not in Smalltalk, there are no
> doubt many errors that would occur only in Smalltalk, and not in
> Mercury.  Obviously such errors aren't included in my list...

The Smalltalk compiler warns you of uninitialized temporary variables in
methods. It does not warn you of uninitialized instance variables, but
there is a coding convention that makes preventing such quite trivial:
you initialize all such variables in an object's #initialize method. The
object is sent the message #initialize whenever it is first instantiated
by the class.  Following this convention, it is a) easy to tell whether
a variable has been initialized, and b) therefore, not a frequently-encountered
problem.

> > Other advantages of
> > Smalltalk would probably eliminate several of those 9 run time errors
> > (for example, more abstract code...
> 
> I doubt this.  Mercury code is generally very high-level already, and
> looking at the nature of the errors, it's hard to see how using a
> different language could help avoid all but one of them.

I can't comment on Mercury.  I can say that Smalltalk makes many sorts of
coding errors that are common in other langauges much less likely in the 
first place.

> One of the nine errors was caused by incorrect argument order
> (it wasn't caught by typechecking since the arguments were both the
> same type).  That one might well have been avoided in Smalltalk.

Yes.

> Three were errors in the program's output.
>         - omitting the filename on one of the error messages
>         - enclosing something in double quotes instead of
>           in singe quotes
>         - printing `foo()' rather than `foo' (parentheses
>           should only have been used when there were arguments,
>           but the program printed them even when there were no
>           arguments)

These sound like bugs that would have happened in Smalltalk, too.

> Four were serious semantic errors (logic bugs); these are all too
> complicated to explain concisely, but I can't imagine any programming
> language feature that would avoid them.

A larger library of reusable code (your own, or that of some third party)
might have left less chance for the introduction of bugs that is common
in de novo code.

> One was a performance bug, caused by using an unnecessarily inefficient
> algorithm in the inner loop.

You might have coded this more efficiently to begin with, given a development
environment and language that encourages more rapid development (less time
pressure, a larger library of reusable code, and library code that is more
generic and hence more reusable).

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Alan Lovejoy]

Robert Dewar wrote:
> 
> iAlan said
> 
> "So then, why have so many investment banks adopted Smalltalk as the language
> of choice for doing securities trading applications?  The reason typically
> given is that development speed in Smalltalk is so much faster--which boils
> down to big bucks on the trading floor.  Could the financial people be wrong?"
> 
> Note incidentally that these "financial people" in whom Alan has so much
> trust are the folks who have brought you the multi-billion $ Y2K disaster!

More distortion.  Just because the financial institutions have tried C++ then
rejected it in favor of Smalltalk and Objective-C does not mean they are never
wrong and never make mistakes.  After all, they tried to use C++ first instead
of Smalltalk <g>.  

But to conclude that my statements imply that I have some sort of naive faith
and trust in "the financial people" is a slimy rhetorical device with no justification
whatsoever. Shame on you.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Robert I. Eachus]

In article <5cio7f$brk$1@news.nyu.edu> kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

  > I've heard nobody claim that *testing* is a bad idea.  The claim,
  > with which I agree, is that *reliance* on testing is a bad idea.
  > There's a very large difference between those claims.

   I agree, but I would state it very differently.  There are projects
where using the debugger as part of the verification process is
acceptable.  However, any bugs showing up during formal test would
occasion a LOT of soul searching, and possibly a decision to
completely rewrite significant sections of the application.  The most
likely decision is to forgo fielding that version of the software.

   It is more expensive to build applications this way, but
surprisingly it is probably easier and cheaper to use error prevention
techniques to get a one per ten million SLOC error rate than to use
debugging to get a one per thousand line error rate.

   
--

					Robert I. Eachus

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

Re: OO, C++, and something much better!

[Alan Lovejoy]

Robert Dewar wrote:
> 
> Alan says
> 
> "So then, why have so many investment banks adopted Smalltalk as the language
> of choice for doing securities trading applications?  The reason typically
> given is that development speed in Smalltalk is so much faster--which boils
> down to big bucks on the trading floor.  Could the financial people be wrong?"
> 
> Of course they could .. I know of one major catastrophe in attempting to
> use Smalltalk for a large financial application -- which ended up costing
> a huge amount of money ....

I see.  So when a C or C++ or Ada project fails, you blame the programmers
and/or the management, but when a Smalltalk project fails, you blame the
language? Are you a politician or government bureaucrat, by an chance?

> If you assume that popularity is necessarily related to technical
> soundness, no doubt you think that MSDOS was a perfect operating
> system, and that Lots 1-2-3 macro language is the best programming
> language!

You are twisting the argument and taking it out of context.  Typical USENET
bullshit.

The issue was why Smalltalk was becoming so popular at financial institutions, 
in spite of all the prejudice against it.  The argument was that the reason
for its popularity was because of its superior development speed.  

The financial folks follow the conventional herd most of the time (such as
those who've gone WinTel).  The fact that they are NOT doing so in the case
of Smalltalk is therefore quite significant.  Underdogs such as Smalltalk
only get adopted in any significant percentage because of technical merit.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Alan Lovejoy]

Joachim Durchholz wrote:
> 
> Alan wrote:
> 
> > But replace "PL/I" with "any statically-typed language," and then you can
> > see the truth: "because any statically-typed language sucks, is why."
> 
> Come on, have you ever programmed in a statically-typed language?
> Seriously?

I have programmed professionally in FORTRAN (2 years), Pascal (2 years), 
Modula-2 (1 year), C (I have done this a few hours at a time, several times
a month, for the last 9 years or so) and C++ (1 year).

I have also played with Ada83 (but not Ada95).  I have studied many other languages,
in the sense of having read books about them.

> What you say sounds just like a Basic programmer whom I tried to convince
> he should try (just TRY!) Pascal. He said he had seen it at the
> University, and Pascal sucked...

My first programming language was PL/I.  Then Pascal.  Then Modula-2.  I really
liked each one when I first learned it.  Oh, and I learned BASIC many years ago,
way before anything resembling VisualBasic was even conceived of.

> > (Actually, statically-typed langauges have a useful niche, but that niche
> > does not encompass all of programming).
> 
> Which?

My opinion?  Static typing is indicated when you need the highest possible
performance, and/or when the abscence of absolutely all bugs is far more important 
than development time (but formal verification methods and technology should then
also be used).  I do not think that most programming projects meet either of these
criteria.  Examples of those that do: weather simulation, nuclear explosion simulation,
operating systems microkernels, (some) device drivers, x-ray machine control software
and strategic missile control software (although perhaps not all of it).

> I could state that Smalltalk has a useful niche (that doesn't encompass
> all of programming), but I don't want throw mud back.

But that's not mud.  I'd say the same myself.

> > Ever heard of StrongTalk?  It's Smalltalk with static typing.  It was a
> > failure in the marketplace.
> 
> Why? Because static typing is bad, or because it was done badly, or just
> because the Smalltalk *environment* isn't designed with static typing in
> mind, or because the Smalltalk installations didn't want to convert
> because they would have had to retrain their developers? (The latter is
> one of the main reasons why Cobol and its ugly relatives haven't died out
> yet. Technical merit is just one factor among many that decide wether a
> language lives or dies.)

This is no mystery.  It was because the Smalltalk community does not perceive
dynamic typing as a significant problem nor static typing (of the common
variety) as an acceptable solution.

If you have a typing system that a) prevents "message not understood" exceptions,
but b) does not prevent Smalltalk code from being compiled that would work
at runtime were it not for the static type checking, then Smalltalkers would be 
interested.  I think progress is being made in this direction, but more needs to 
be done (unless there's something I don't know about, which is of course possible).

> > I conclude that static typing succeeds when
> > marketed to those who believe in static typing, and that dynamic typing
> > succeeds when marketed to those who belieive in dynamic typing.
> 
> No you can't. This is just rhetorics what you're doing.

I was answering rhetoric with rhetoric. So spank me. (Ouch!).

> > And dynamic
> > typing also succeeds when marketed to people who want the fastest
> > development times, and have no religious axe to grind over the issue.
> 
> I have heard several indicators that Smalltalk is very good at getting
> stuff done, in the quickest possible time. I'm willing to believe this
> (sounds reasonable anyway), but nobody talks about the disadvantages in
> the approach. Those who know Smalltalk program in it, so they won't tell
> me - and I can't believe there are none.
> I don't want to be converted to Smalltalk. I want to know about advantages
> and disadvantages, so that I can decide which language is better for a
> given task.

Any language is just a tool.  Learn to use the tool that is most appropriate
to the task at hand--and be open to new tools that didn't exist a decade ago.

> > Why would Chrysler hire Kent Beck to oversee the rewriting of their payroll
> > system in Smalltalk?  They could have chosen C++, Eiffel, Java or Ada95, or
> > just stayed with COBOL. Why didn't they?  Why choose Smalltalk, when there
> > are so much fewer programmers than would be available for C++?  Why choose
> > Smalltalk, when there is such a wide-spread bias against dynamic typing?
> 
> Maybe because they are manager? Not all decisions, even in large
> companies, are based on rational arguments. There is trust in consultants
> involved, who aren't always impartial. There is also much internal
> backstabbing involved - sometimes managers influence other managers into
> bad decisions, to weaken their internal position.

Sure.  But the point was that Smalltalk is gaining ground in spite of all
the prejudice against it, and in spite of the fact that using or adopting it is
swimming against the tide for C++/Java.

> Not that I'm convinced this is the case with the companies that you listed
> as examples. It's just that such success stories don't prove a thing. It
> would be much more interesting to hear about the consequences of these
> decisions, not about the decisions themselves.

I think there is significance to such things when an underdog technology
gains marketshare, in spite of being constantly deprecated and libeled by
the "in crowd."

> > Why has the use of Smalltalk been growing at 60% per year?  In spite of the
> > absence of any Java-style marketing campain?
> 
> Maybe because two companies happened to decide for Smalltalk, which makes
> a huge difference if the installed base is small.
> I'm sure any proponent for any other language can make up similarly
> impressing figures.
> That 60% figure is worthless - you don't say wether it's number of
> companies, number of developer seats, number of productive systems, or
> lines of code. You don't even say since when this growth started - it
> might be 1 1/2 year as well as twenty years.

The growth in Smalltalk started roughly four years ago.  It's a count of the
number of jobs where the primary job function is programming in a particular
language.

> > Smalltalk offers many times faster development times--and much greater
> > robustness in the face of changing requirements.  That's a strategic
> > advantage, especially in businesses and industries (like securities trading)
> > where time is not just money, but big, big money.
> 
> I already knew this. I consider this an interesting property of Smalltalk,
> but I'm not convinced Smalltalk is best for everything. 

Nor should you be.

> And as far as I
> know, Smalltalk can't be integrated into a multi-language environment (at
> least not with a considerable amount of work, or with serious efficiency
> problems), so I'm somewhat hesitant to recommend Smalltalk at all.

Smalltalk can call C just as easily as Java or Basic can.  Two way interoperability
(where C calls Smalltalk) has been a problem, but there are now at least two 
different Smalltalk implementations that compile to "native code" directly
(no bytecodes at all, this is better than JIT compilation).  With "classic"
native code compilation, two-way interoperability is not a problem.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Alan Lovejoy]

John Woods wrote:
> 
> donh@syd.csa.com.au (Don Harrison) writes:
> 
> >Eric Clayberg writes:
> 
> >:Actually, Smalltalk transparently switches to using "large" integers
> >:that have no limits on size. In fact, it's actually fun to run large
> >:factorials in Smalltalk to see how large an integer it will generate.
> >:VisualSmalltalk will calculate the result of "1000 factorial" in a
> >:second or two and display the results. BTW, the result of that
> >:expression is: :-)
> 
> >[some gi-normous number]
> 
> >That's impressive. Might hang onto it in case it comes in handy one day. :)
> 
> >Don.
> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >Don Harrison             donh@syd.csa.com.au
> 
> I was showing off VW to a Pascally friend with these large integers.
> BTW, the only way to get a scientific format for this is to convert it
> into a string and count the digits --- about 2500.  It takes my two
> year old PC less than a second to calculate this, and slightly more
> than a second to convert it into a string!
> 
> Anyway, back to the showing off.  I ran a low priority process finding
> the factorial of a million, to show him how stable the system was.
> Obviously nothing happened, and I forgot about the process.
> 
> Weeks later, my system was getting pretty slow.  I had a good look
> at my image.  It contained a two megabyte integer!  But, apart from
> the brain aching slowness, it was still crunching reliably away.

And I'll bet you saved the image to disk, quit Smalltalk and even shutdown 
your computer at least once during that time, didn't you?  And the process
just kept running (resuming right were it left off each time the image was 
restarted), n'est-ce pas?

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Alan Lovejoy]

Marc Robertson wrote:
> 
> Alan Lovejoy wrote:
> >
> > Graham Hughes wrote:
> > >
> [snip]
> >
> > > If OO is about conceptual separation of code into independent modules,
> > > why should the modules be concerned about what somebody else gives them?
> > > Why should they manually check that the object is capable of the
> > > operations demanded when the compiler can?
> >
> > This is a non argument.  Since someone must check, there is no difference in
> > principle whether that someone is the compiler or the run-time system.  It's
> > an implemenation difference, not a difference in kind.
> 
> There is a difference in practice.  If the compiler detects an error,
> the only one that has to worry about it is the developer.  If an error
> is present that the run-time system has to handle, all users are
> potentially affected by it.  There have been any number of studies(
> unfortunately, I don't have access to them here, so I can't quote them )
> that indicate that the cost to correct a problem increases dramatically
> the later in the development process you detect it. The sooner problems
> can be eliminated, the less it costs to eliminate them!

You and everyone else who replied to me completely misinterpreted the point of
the argument.

The issue I was addressing was not: "Is there any difference whatsoever between
dynamic and static typing."  Yet that is the question assumed by all the responses.
Bullshit: you can all take points off for answering the wrong question.

The ISSUE was: "Is dynamic typing contrary to OO design principles because the
object checks the type at runtime instead of relying on the compiler?".  Graham
Hughes was making an argument about the proper assignment of responsibility for
type checking from an OOA/OOD perspective, NOT from a software engineering/safety
perspective.  

And a strong case can be made that having the compiler check based on "types"
(actually type constraints/assertions) assigned to variables (not objects) 
is a severe violation of the information hiding principle.  An object should
ideally be a black box that hides its implementation (class).  Exposing the
interface of the object is acceptable, even good.  But most statically-typed
OO languages go beyond that into exposing the implementation (class)--and then
hard coding it into type constraints on variables in the program source, which 
is very, very bad.  

Using the class as a substitute for the interface violates the information hiding
principle.  This was and is the issue.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Snowball Info]

Stephen J Bevan wrote:
> 
>    From: Tansel Ersavas <tansel@rase.com>
>    Newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c++,comp.lang.smalltalk,comp.object
>    Date: Fri, 24 Jan 1997 10:58:20 -0500
>    Organization: RASE Inc.
>    References: <JSA.97Jan16141937@alexandria> <5bphq4$5js@mulga.cs.mu.OZ.AU>
>                    <32E05FAF.47BA@concentric.net> <5buodl$bci@boursy.news.erols.com>
>                    <32E2FEC7.2F7B@concentric.net> <6PE5zLpF3RB@herold.franken.de>
> 
>    I used Pascal, C and C++ for more than 10 years,
> 
> Just out of interest: when did you first get hold a C++ compiler?  I
> didn't see the first one until 1986 and so can only just claim to have
> programmed in it 10 years ago, but even then C++ 3.0 is a considerably
> different language from C++ 1.0.

Good point,  I was referring to them collectively, which perhaps I
shouldn't have had. I've met the C++ language in 1986, and used it more
and more, and in 1990 I started using it exclusively till 1993 (AT&T in
Unix, Borland in PC, one of the first users and beta testers of the
entire Borland suite incl. OWL. Tried Glockenspiel and MS too, but I
really have a dislike for MS suite incl MFC). I have introduced these
technologies to companies I worked for where I had influential senior
postions. I trained my teams, ond others in the company, did general
design, and parts of implementation. You are quite right that there are
significant differences bw AT&T 1.0 to 3.0 and between AT&T, Borland,
MS, and others. 
Then I had to switch to Smalltalk because a new project, and I must
admit, after a few months of struggle, I am now hooked to it, not that I
think it is the best (I like Self better), but I find it more than
adequate. Again, I had looked at Smalltalk before, each time either
because of time pressure, or other reasons (among them my initial
dislike of Smalltalk syntax) I did not see the reason the switch.
Recently I had to develop propriatory encryption and compression
libraries which had to be in C++, and compatible between Unix and
Windows platforms, although I completed the system with a happy
customer, I really found C++ unworkable.

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: OO, C++, and something much better!

[Alan Knight]

In article <5caqo5$k5l@mulga.cs.mu.OZ.AU>, fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) wrote:
>Eric Clayberg <clayberg@parcplace.com> writes:
>
>>Fergus Henderson wrote:
>>> My experience is that errors caught by type checking constitute a LOT
>>> more than 2% of errors.
>>> For a period of time I carefully recorded the cause of every error that
>>> I found while writing a Mercury program.  Of the 155 errors that I
>>> recorded, 73 were error caught by the type checker.
..
>Some (14) of those 70 errors were related to the syntax, but most of
>them were errors such as "wrong number of arguments", "wrong procedure
>name", and so forth, that could occur in just about any language.  Note
>that the number 70 does *not* include errors in the type declarations
>themselves; there were an additional 13 of those.

<Sigh> I know I'll regret jumping into this.

On the one hand we have people talking about the problem with dynamic type 
errors being that they are not found until "run-time", apparently with the 
assumption that run-time happens with end-users, and that testing is totally 
inadequate as a means of catching them.

That appears quite inconsistent with this definition of type errors, since 
they are almost all things that would be caught the first time the code was 
*EVER* run. In fact, both examples given (wrong # of arguments, wrong 
procedure name) would probably be caught at compile-time in Smalltalk, even 
without any static type checking. In fact, depending on your Smalltalk IDE, it 
might even offer a list of valid alternatives based on its attempt to correct 
your spelling.

In fact, from a casual glance, I see only one class of errors that I would 
classify as a type error in Smalltalk.

>                        - argument has wrong type: 7

out of 155 that's 4.5%, somewhat above the 2% quoted by some of the other 
posters, but probably within the limits of precision. Of course, many of those 
errors also get caught the first time the code is run too. Here's how I'd 
account for the others listed

 - errors in type declarations: 13                 
         No type declarations
 - syntax related: 14
        Comes from this odd mercury syntax you mentioned. Almost any language, 
no matter how dynamic, will catch syntax errors at compile time.
 - wrong procedure name: 11
        Many cases would be caught at compile time (and spelling-corrected), 
otherwise caught the very first time the method is invoked.
  - wrong constant name: 4
       Caught at compile time if it's really a constant, but in Smalltalk, 
constants are often treated as class methods, in which case it would be 
treated as a wrong procedure name.
   - wrong variable name: 4
        Caught at compile time.
   - wrong number of arguments: 21
        Very hard to do in Smalltalk. Counts as wrong procedure name.
   - incorrect argument order: 5
        Also very hard to do in Smalltalk and counts as either wrong procedure 
name or argument with wrong type.




--
Alan Knight                     | The Object People
knight@acm.org                  | Your Smalltalk Experts     
613.225.8812(v) 613.225.5943(f) | http://www.objectpeople.com

"That does not mean we should give up reading nineteenth-century
novels, we should read them avidly and often. What we must do is
give up writing them" - Jeanette Winterson

Re: OO, C++, and something much better!

[Luther Hampton]

Eric Clayberg wrote:
> 
> David Hanley wrote:
> 
> > All other things being equal, there are fewer errors that can
> > happen in a static typed system, as opposed to a dynamially typed
> > system.  Your refusal to accept this simple arguement makes you appear
> > as if you have some kind of religous attachment to your system.
> 
> Not at all. It's simply that your "argument" isn't that simple. While
> static typed systems will, in fact, prevent certain classes of errors,
> you have not proven that dynamically typed languages (like Smalltalk)
> don't *also* prevent certain classes of errors. Thus the issue of
> "fewer" errors is not very clean cut at all[.....] 

My initial take on David Hanley's point is: so what? In my experience
with languages such as Smalltalk and Objective-C (with the type-checking
surpressed) I have not found that the serious errors, i.e., the ones
that were *really* hard to find and fix, were related to incorrect
typing.  IME serious errors have to do with misunderstandings of the
requirements and the problem domain or subtle logic errors in the code. 
IMHO these are the stinkers, and no language finds them in a totally
satisfactory mannner.  Yes, its a little scary to accept that there can
be no *guarantee* that my Smalltalk program does not have a potential
type mismatch in it, but I'll get over it in exchange for some of the
advantages which I find in the language.

Rather than going back and forth about the merits of type checking we
should examine whether type mismatching is an important source of errors
in "tested" programs.

Luther Hampton  
>

Re: OO, C++, and something much better!

[Norman H. Cohen]

Robert A Duff wrote:

> Hmm.  I have mixed feelings about that statement.  Since I know nothing
> about R or S, I'm willing to believe that the R language has an entirely
> appropriate set of static and dynamic rules, for this type of
> "application". 
...
> As you can see from this thread, Smalltalk is well-regarded
> by many of its users, and Ada is well-regarded by many of its users, and
> the same for C -- isn't there some sort of objective reality, that goes
> beyond what programmers think they like?

R? S? Ada? C?  Why this obsession with languages whose names are
palindromes?

...
> 
> - Bob

Ah, now I understand!

:-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) 

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Eric Clayberg]

David Hanley wrote:
> There are losts of cases in C/C++,java,etc where passing null as an
> argment is just fine as well.

Yes, I know that. I use the three languages you mention frequently.
Heck, I've even done commercial application development in Java and work
for a company that actually has several commercial Java packages on the
market.

> No kidding.  I still don't understand your implication that it is ok,
> and has somethin to do with dynamic typing.

Huh? What implication? I was merely responding to your comment:

> So smalltalk will happily pass a message to the nill object, and the
> progrm will chug along just fine?

Remember?

> So are you under the impression that ST is the only language that can
> trap null pointer writes?

Not at all. Again, I was merely responding to your comment which was
clearly in err.

> And what exactly does this have to do with static and dynamic typing?

Not much. Again, I was merely responding to your comment which was
clearly in err.

-Eric

Re: OO, C++, and something much better!

[Russ McClelland]

> >>In other words: I'd feel really embarrassed if the user ever saw a  
> >>"message not understood" error.
> >
> >Don't worry, I see enough "core dumped" messages on one system and
> >pretty pictures of bombs on another, and my friends see "GPF" often
> >enough, that we'd forgive you...
> 

This isn't even an issue.  Any developer worth anything would install a
default exception handler that would catch all "uncaught" exceptions.  This
exception handler wouldn't even present an option to debug the code or any
of the other options available with the development exception handler.

> variable.  I mean, type-inference is all well and good, but there's got
> to be some (preferably fairly localized) information to start inferring
> from.

Why?  Why would you need to check the type?  Presumably not so that you
could write conditional statements that checked the type to see if the
instance was of a particular class?  This wouldn't be very OO (ie use
inheritence and polymorphism to handle conditional expressions).

Re: OO, C++, and something much better!

[David Hanley]

Eric Clayberg wrote:
> 
> David Hanley wrote:
> > To people who understand programming, and, in particualr, static typing.
> 
> That's a mighty arrogant assertion on your part.

	It's also sarcastic on my part.  I find one of the most diffucult part
about talking to religous fanatics of any kind is that they don't
understand basic sarcasm.  

> > Another quick scan of this group would make it equally obvious that
> > while some may find these claims intuitive, many other find the same
> > claims counterintuitive, and contrary to thier experience.  If we all
> > found it intuitive, there's be no discussion, right?
> 
> Very true. In fact, it looks like number of folks who find the claims
> intuitive and the number who don't are roughly the same in this
> discussion. From my point of view, the answer is not as clear cut as you
> would like us to believe.

	I'm not saying that there's a clear-cut answer; never did.  What I
object to is some bigoted person periodically posting how dramatically
better (ST/C/C++/COBOL/JAVA/etc) is than all other languages, and how
all programmers who do not use it are idiots.  

	Frankly, I don't care what language you happen to like; it doesn't
affect me in the slightest.  It's when people make uninformed derogitory
remarks that I get irritated.


> > All other things being equal, there are fewer errors that can
> > happen in a static typed system, as opposed to a dynamially typed
> > system.  Your refusal to accept this simple arguement makes you appear
> > as if you have some kind of religous attachment to your system.
> 
> Not at all. It's simply that your "argument" isn't that simple.

	Ok.

> While
> static typed systems will, in fact, prevent certain classes of errors,
> you have not proven that dynamically typed languages (like Smalltalk)
> don't *also* prevent certain classes of errors.

	Ok.  Since we both agree that there is a certian class of errors that
statically typed languages prevent, what needs to be shown is what
errors dynamically typed languages will prevent.  I am not aware of
these, and I sure haven't seen any sign of them!


>  Thus the issue of
> "fewer" errors is not very clean cut at all. If you are merely arguing
> that a static typed system will have fewer *type* errors in it, then
> fine, I can buy that.

	Okay, good progress...

>  If you are asserting that this means that there
> are fewer errors over all, then you haven't proved anything at all. 

	Ok, I'm makign one assumption:
	
	      static typing           dynamic typing
type errors        few                     more
other errors       same                    same      	

	Since we agree on the first line, the second one is then in question. 
If you don't present a reason why there will be fewer other errors in a
statically typed language, I'm going to assume that there will be fewer
erors total, though, hey, I might learn something from your
counter-arguement.  Enlighten me.

> So,
> once again, I ask, where is your proof that Smalltalk is somehow less
> reliable for building applications than any arbitrary statically typed
> language?

	Because the run-time error set is larger.

> Since you say that this would be a good proof, then why don't you
> present the "set of errors" that you see on both sides of the coin and
> let us all take a crack at it? Without that, your argument degrades to
> so much empty sophistry.

	I can think of a lot of errors.  I think it would be more productive if
you listed the errors you think don't apply.

-- 
------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[Al Christians]

Alan Lovejoy wrote:

>> Smalltalk can call C just as easily as Java or Basic can.  Two way interoperability (where C calls Smalltalk) has been a problem, but 
there are now at least two different Smalltalk implementations that 
compile to "native code" directly (no bytecodes at all, this is better 
than JIT compilation).  With "classic"  native code compilation, two-way 
interoperability is not a problem <<

This is the first interesting tidbit in this entire tiradathon. Please
tell us more about these new Smalltalk implementations.

Al

Re: OO, C++, and something much better!

[Jerry van Dijk]

Robert A Duff (bobduff@world.std.com) wrote:

: >Isn't this whole discussion futile since programming languages are just
: >tools, and not every problem looks like a nail ?

: No, no, and no!  A language is not "a tool".  It is a *collection* of
: perhaps-related tools.

Oops, did I accidentily kick a hobby horse here ? :-)

If you mean that any language design reflects a choice of 'features'
based on a certain model, I agree. However, from a practical point of
view, only few of us are in the position to design our own languages so
are forced to pick one of the toolboxes pre-filled by the shop.

:                                                                   To me,
: that's what this debate is about.  I *really* want Ada's type safety (at
: compile time, in many cases) and Smalltalk's flexibility and simplicity.
: I want both.

Yep. Me too. And while we are at it, lets add Eiffel style pre- and post
conditions too.

But, to put it in a style too often seen, even here on c.l.a.: "please,
tell me where to download" :-))

: Don't tell me, "If you choose the hammer, you can't have the wrenches."
: I think it's technically feasible to have both.  I think the idea that a
: programming language is a single tool, take it or leave it, as is, is
: bogus.

Not bogus, just practical.

: >... But I have developed a banking application in which the
: >presentation- and application layers were written in Smalltalk, while
: >the functional- and interface layers were written in Ada.

: OK, that's an OK answer, given the current state-of-the-art, but there
: are serious costs to interfacing between the two.

In practice its not that bad, at least, we didn't have any real problems
with it. A lot of interfacing code can be generated from specs by writing
a relatively simple parser-based tool.

:    I claim that it's
: possible to design a programming language that supports both at the same
: time, without the interfacing difficulties.

I admit I do not know enough of language design to argue against the
possibility. But common sense than begs the question: why has such an
obviously superior language not been designed already ? At least, I'm
not aware of it.

< now searching for my flame-proof email shield :-) >

: So I don't buy the idea that you can just choose whatever language is
: best for each module, and then paste them together.

Because of a) the effort to add extra interfacing code and b) the
performance penalty ? Added to the expectency that someday the ideal
language will be born ? For that are the arguments I can distill from
the above. 

However, from a practical point of view, there are far better arguments
against such a mixed language solution: manning two or more development
teams, the complexity of maintaining different but related development
enviroments, extra tool costs, etc.

In some situations the benifits of a mixed language solution outweight
these disavantages, in other situations they don't.

Jerry.
-- 
+----------------+-------------------------------+
| Jerry van Dijk | Consultant, Ordina Finance BV |
|    Team Ada    |        Haarlem, Holland       |
+----------------+-------------------------------+

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <yf3wwsxqw1z.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>Actually, it's not *my* scheme, it has been known for thirty years or

Yes, I realize you didn't invent it.  ;-)

>...Dynamically scoped identifiers are usuful for a number of
>cases where actions must depend on the program context; dynamically
>scoped variables, not just procedures, are very useful too. Non local
>control transfers are also very useful in their own right.

OK, I'll buy that much.

But how do you write an ``exception handler'' that catches a whole class
of related exceptions.  (E.g. division by zero might raise
"Divide_Error", and the caller can choose to handle "Divide_Error" or
"Arithmetic_Error" (which includes Divide_Error), or "Any_Exception", or
whatever.)

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[John W. Sarkela]

Piercarlo Grandi wrote:
[...]
> But really the biggest problem of the mechanism is that it presents as
> something complicated and special, to the point of requiring its own
> control structure, chapter in the book, papers, and so on, what is an
> entirely simple thing, as long as one presents it as: dynamic scope
> +optional control transfer.
I would advance the argument that the nature of the most appropriate
exception mechanism will vary as one adopts procedural, functional or
object oriented points of view. 

As an example of why I think objects modeling exceptions are right, I
would use the point of view first expressed to me by Bertrand Meyer,
programming by contract. Using the exception mechanism with which I
am most familiar, Visual Smalltalk's.

In human interaction, a contract is a document that describes a promise
of service to a client. A contract has three important qualities.
  1. It is observable by client and supplier.
  2. It is verifiable by client and supplier.
  3. It is enforcable by client or supplier.
When either the client or supplier detects that the terms of the
contract
have been violated, the situation is sent into arbitration for
resolution.

In my programs exactly the same holds true. When assertions about the
state
of execution have been violated, I create an instance of an exception
that
models as carefully as possible all of the information about the
observed
violation of specification. Thus, from an object modeling perspective,
the
exception object serves as the court of arbitration for disputes between
clients
and servers.  Handlers may be set associated with method activation
records.
Each handler serves as a local arbitrator for the signaled exception. If 
recovery is not possible, the dispute may be passed to the next higher
authority.
If none are found, default rules may be handled by the exception object
itself.

I have found this model of exceptions and their handling to be both
intuitive
and effective. The fact that non-local control transfers occur is not
really
a problem conceptually, because the control unwinds the chain of
activations
that led to the exceptional situation in the first place.

This is a rational, structured, normal handling of exceptions in an
object
model. If I were using a functional language, then total functions would
be a more appropriate point of view. However, for an object oriented
language
exceptions as objects provide a rich implementation mechanism for
supporting
the design notion of programming by contract.

John Sarkela
jsarkela@enfish.com

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[John (Max) Skaller]

On Sat, 25 Jan 1997 20:52:41 GMT, bobduff@world.std.com (Robert A
Duff) wrote:

>I'm not sure why Mr. Grandi thinks his scheme is so
>vastly superior, though.

	The reasons are plain enough: 

	First, the scheme permits retry, C++ style exceptions do not.

	Second, the scheme does not require any special
	constructions. No exception handling constructions.

	It is implemented using dynamically scoped functions,
	which are useful for other things.

	Summary: the scheme subsumes the C++ scheme
	because it can do everything the C++ scheme can do,
	with no more complexity, using other facilities --
	which are also useful in other contexts.

This would be totally convincing were it true: a language
should not introduce new special constructions when
a library component or technique would suffice.

In the example of a dynamically scoped function, there
is a direct correspondence between the "throw"
function and the "catch" function. (They're
both called the same name).

Question: What is the functional equivalent to the ability
of C++ to provide "matching"?

Re: OO, C++, and something much better!

[Jun Nolasco]

If the development team had done their unit and system testing
right, this should be a non-issue. In other words, it indicates a
problem
with the development process, not the development tool.

								Jun Nolasco
								nolasco@inx.net


Marc Robertson wrote:
> 
> There is a difference in practice.  If the compiler detects an error,
> the only one that has to worry about it is the developer.  If an error
> is present that the run-time system has to handle, all users are
> potentially affected by it.  There have been any number of studies(
> unfortunately, I don't have access to them here, so I can't quote them )
> that indicate that the cost to correct a problem increases dramatically
> the later in the development process you detect it. The sooner problems
> can be eliminated, the less it costs to eliminate them!

Re: OO, C++, and something much better!

[Fergus Henderson]

Eric Clayberg <clayberg@parcplace.com> writes:

>David Hanley wrote:
>> In fact, people on the static typing 'side' of the issue, such as Fergus
>> Henderson, have provided good data with compelling arguemnts for static
>> typing.
>
>He certainly presented some data. It wasn't very clear that it provided
>much support for static typing, however.

I certainly think it provided support for static typing.

>In fact, his numbers
>(especially the variety of errors that he ran into) only served to make
>me (and, I imagine, most of the other Smalltalk developers in this
>thread) quite happy that I was using Smalltalk (in which, as was pointed
>out in response to his numbers, most of those errors couldn't occur).

Your conclusion that "most of those errors couldn't occur" in Smalltalk
is definitely wrong.  It goes a lot further than your previous posts,
where for many of the errors you argued only that they would be caught at
compile time in Smalltalk, despite the lack of static _type_ checking,
due to the presence of static checking for existence of a matching
method selector.  

With regard to Smaltalk, I draw the following conclusions from my data:

	- use of type declarations results in some errors (wrong type
	  declarations) that would not occur in a language such as
	  Smalltalk that doesn't have type declarations; and

	- had the program been written in Smalltalk, absence of static
	  type checking would have increased the number of errors that
	  were caught only at runtime by almost a factor of two, for
	  this data set.

Errors in type declarations are very easy to fix.  Errors that occur
only at runtime can be a lot more difficult to fix, assuming you detect
them, and the possibility of non-dection increases the likelyhood of
bugs in your final product.

>Having
>used several different statically typed languages over the years as well
>as Smalltalk, my experience (and that of many of the folks contributing
>to this discussion) is that the Smalltalk-based systems are usually much
>more reliable in practice.

I don't deny that this experience is valid.  However, I suggest that it
may well be related to the nature of the specific statically type
languages that you have experienced, rather than to any attribute of
statically typed languages in general.

To put things concretely, I would be quite surprised if you had the
same experience if you with compared Smalltalk with Java, Haskell, or
SML.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Fergus Henderson]

Alan Lovejoy <alovejoy@concentric.net> writes:

>Fergus Henderson wrote:
>> 
>> In the case of the wrong variable names, it's a little more
>> complicated.  In Mercury, variables do not need declarations.
>> Most errors involving variables are caught by either singleton
>> variable warnings and/or by mode errors (both of these are counted
>> in the "others" category below).  Three of these four cases caught by
>> type checking involved using an incorrect name that was also the name
>> of another variable.  I think they would also have occurred in
>> Smalltalk (and would not have been detected until run time).
>
>What do you mean by "using an incorrect name that was also the name of
>another variable"?
[...]
>However, if by "using" you meant "referencing,"

Yes, that's what I meant.

>then such could in fact occur.
>
>But the data I collected for Smalltalk did not show this sort of
>error as occuring with much frequency.

I'm sure the frequency of different error categories may
vary quite a bit from programmer to programmer, as well
as from language to language.  Perhaps you make different
sorts of mistakes than I do.

>I think this is because Smalltalk
>uses global variables far less than is common in other languages,

That explanantion is almost certainly wrong.  I strongly suspect that
global variables are used even less in Mercury than in Smalltalk,
because Mercury, being a pure functional/logic language, does not
provide any language support for them.

>> The fourth case involved trying to use the same name for two different
>> variables.  I'm not sure whether that one would have occurred in Smalltalk.
>> I guess it would depend on whether the programmer noticed that there
>> was already a declaration for that variable.
>
>As noted above, this can't occur in Smalltalk without warning.

I would be *extremely* surprised if that is really true.  Smalltalk
implementations may well warn about occurrences that have overlapping
scopes, but I can't imagine a Smalltalk compiler issuing a warning
if a variable is declared once and then the code tries to use it
for two different (and incompatible) purposes.

>This does not happen often.

You're right.  That was only one of the 155 errors I encountered.

>> I doubt if there are any of these sort of errors.
>> Mercury has a quite simple type system.
>> For example, there is only one integer type in Mercury.
>
>How many Collection types?

... used in the program in question? 
Four: list, set, map, and varset.

I don't think that 

>Are integers interchangeable with floats,
>and complex numbers, and fractions, and...

No, but the program in question didn't use any floats,
complex numbers, or fractions.

>Except that my data show 2% or less as the rate of occurrence for "type" 
>errors **IN SMALLTALK**.

Since Smalltalk doesn't detect type errors automatically, then there
may well be a significant number of type errors in your Smalltalk
programs which you have not yet detected (but which your customers
may find ;-).

Also, it is possible that you may be misclassifying some errors as
non-type errors even though they would have been caught by static type
checking.

If you have some detailed records for Smalltalk, then perhaps you
could post them and we can give them the same sort of examination.

>> >And how many were caused by the fact
>> >that the Algol-style function call syntax makes it so easy
>> >to get the arguments wrong?
>> 
>> Again, probably none of them.
>
>Does Mercury use Algol-style function call syntax?  That is, "f(x, y, z, ...)"?

Yes.

>If so, the fact that Smalltalk will have fewer cases of "wrong argument" due
>to its superior function call (message send) syntax is not a debatable point.
>It's a fact.

Do you mean fewer cases getting past the compiler,
or fewer cases at all?

I think most of these cases were due to changes in one part of the
source code not being reflected in other parts.  I don't think
Smalltalk syntax is going to help in such cases.

>> Four were serious semantic errors (logic bugs); these are all too
>> complicated to explain concisely, but I can't imagine any programming
>> language feature that would avoid them.
>
>A larger library of reusable code (your own, or that of some third party)
>might have left less chance for the introduction of bugs that is common
>in de novo code.

The four bugs were all in very application-specific code that I can't
imagine being in any library of reusable code.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Fergus Henderson]

jur@topdog.cs.umbc.edu (Jacqueline U. Robertson) writes:

>David Hanley  <david_nospam@netright.com> wrote:
>>All other things being equal, there are fewer errors that can
>>happen in a static typed system, as opposed to a dynamially typed
>>system.  Your refusal to accept this simple arguement makes you appear
>>as if you have some kind of religous attachment to your system.
>>
>>	Let's start very simply; is the above system true or false?
>>
>Depends - are we including C and C++ here ?

The important phrase in David Hanley's quote is "all other things being
equal".  Sure, you can count C and C++ as statically typed systems, but
where's the corresponding dynamically typed system to compare against?
Comparing C or C++ against Smalltalk certainly doesn't keep all other
things equal.

>In either language, I have static 
>type checking, but I can use casting to defeat that type checking - thus,
>I get NONE of the benefits of static typing,

Oh, nonsense.  If you use casting in a few places, you still get the
benefits of static type checking in all the places that *don't* use
casts.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Rolf Breuning]

> 
>         Ok, I'm makign one assumption:
> 
>               static typing           dynamic typing
> type errors        few                     more
> other errors       same                    same
> 
>         Since we agree on the first line, the second one is then in question.
> If you don't present a reason why there will be fewer other errors in a
> statically typed language, I'm going to assume that there will be fewer
> erors total, though, hey, I might learn something from your
> counter-arguement.  Enlighten me.

- I think the whole discussion can be concentrated on one point: Can a
language
  like Smalltalk due to its lack of typing be more productive? 

  If yes, then you'll have to accept the following answer: 
    Any logical error or performance flaw you coudn't correct because
you are
    using a less productive environment is due to your environment using
static
    typing.

  Many people (including me) believe that this is the case and there are
at least
  some hints for performance measurement that go into this direction
(e.g. the 
  'Function point' measures).

  [ And greater productivity may not only come from other aspects of
Smalltalk, but
    also from the lack of static typing: Assume in e.g. C++ you defined
two classes 
    with a similar function and a similar set of messages (like 'Array'
and 
    'OrderedCollection'). For a specific application you defined
variables of type
    'Array'. 
    Somebody else wants to reuse your code, but wants to use an
'OrderedCollection'
    In C++ he must invest the time to change the code of the library (or
let you 
    change it) to avoid typing errors. Possibly you must create a common
superclass
    for 'Array' and 'OrderedCollection' if it does not yet exist.
    In this case, without static typing, the code simply could have been
reused. ]

- I think what we can learn from this discussion is: We won't get
anywhere without
  a scientifically executed study comparing the results of some
carefully chosen 
  groups of experienced / less experienced programmers of a language
given a set of
  tasks and comparing how they fit the requirements after a certain
amount of time.
  Some independent studies of this could at least give us answers for
the tasks which 
  were examined like 
   - 'Smalltalk is good for GUI Bussiness apps / distribution' or
   - 'C++ is good for Operating Systems'
   - ....
  I'm really impressed by Smalltalk, and I assume you are happy with
  your-language-of-choice, but without a thorough examination containing
the whole
  development process and the whole life cycle of the resulting
products, I'm sure
  all *we* can say is: language x is - in this certain aspect - *other*
than language
  y.
  All other may be true and our personal experience - but it can't be
true in a
  scientific sense which would enable us to persuade other people easily
to our
  believes.

- That's why I strongly reject any remark of the static typing community
that 
  "because Smalltalk doesn't provide static typing, the programs must
have more
   errors"

**********************************************************************
* Rolf Breuning                             breu@eecs.rwth-aachen.de *
* Bahnhofstr.7                                     using OS/2 Warp 4 *
* D-52064 Aachen                             - standard disclaimer - *
**********************************************************************

Re: OO, C++, and something much better!

[Eric Clayberg]

David Hanley wrote:
> It's also sarcastic on my part.

Indeed. Do you find yourself being sarcastic often? Are you often
misinterpretted?

> I find one of the most diffucult part about talking to religous fanatics 
> of any kind is that they don't understand basic sarcasm.

Possibly so. Met any "religious fanatics" lately? Care to name any?

> I'm not saying that there's a clear-cut answer; never did.

Good. I'm glad we are in agreement.

> What I object to is some bigoted person periodically posting how dramatically
> better (ST/C/C++/COBOL/JAVA/etc) is than all other languages, and how
> all programmers who do not use it are idiots.

Yeah. I hate that too. I haven't seen anyone here doing that (I would
have definitely picked up on the word "idiot" if it had been used). You
make sure and let us know if that happens. Ya know, I have my own pet
peeve as well. I really object when folks condemn a language and imply
that its users must be idiots - especially when it is obvious that they
have never actually used the language. Good thing no one is doing that
either, eh?

> Frankly, I don't care what language you happen to like; it doesn't
> affect me in the slightest.  It's when people make uninformed derogitory
> remarks that I get irritated.

Clearly. I don't like that either - especially when those remarks
concern Smalltalk.

> Since we both agree that there is a certian class of errors that
> statically typed languages prevent, what needs to be shown is what
> errors dynamically typed languages will prevent.  I am not aware of
> these, and I sure haven't seen any sign of them!

Good. So you are admitting that you might be "uninformed" on this topic?
That's OK though. Since you haven't used Smalltalk, I wouldn't expect
you to understand its capabilities. If you would like to expand your
knowledge in this area, there are a number of very nice (and free)
Smalltalk environments available. One of the best is Smalltalk Express
which you can get from http://www.objectshare.com/seinfo.htm.

> Ok, I'm makign one assumption:
>               static typing           dynamic typing
> type errors        few                     more
> other errors       same                    same

Hmmm. That's a mighty broad assumption. Do all statically typed
languages achieve the same error rates? Do all dynamic languages? How
are you quantifying "few" and "more"? Could "more" mean "few+1"? What do
you consider "type" errors vs. "other" errors? 

> Since we agree on the first line, the second one is then in question.

Yeah. It gets back to your earlier "set of errors" argument. What are
you defining as "other errors". If you want to play this game, then you
should at least define your terms.

> If you don't present a reason why there will be fewer other errors in a
> statically typed language, I'm going to assume that there will be fewer
> erors total

Again, this seems to be a very broad assumption on your part seemingly
based on insufficient data.

> Because the run-time error set is larger.

Again, how do you know that? What Smalltalk environment have you
used/studied/analyzed that leads you to that conclusion?

> I can think of a lot of errors.  I think it would be more productive if
> you listed the errors you think don't apply.

Since this "set of errors" argument was yours, it would be much more
appropriate for you to actually back up your own argument and provide
said set of errors. Since I don't agree with your premise to begin with,
I don't know what set of errors you had in mind. If you provide the
list, I (and I'm sure many others) would be happy to point out which
ones don't apply.

-Eric

Re: OO, C++, and something much better!

[Nick Leaton]

Alan Knight wrote:

> In fact, from a casual glance, I see only one class of errors that I would
> classify as a type error in Smalltalk.
> 
> >                        - argument has wrong type: 7
> 
> out of 155 that's 4.5%, somewhat above the 2% quoted by some of the other
> posters, but probably within the limits of precision. Of course, many of those
> errors also get caught the first time the code is run too. Here's how I'd
> account for the others listed

But this is dependent on the way you test your code! You may not have
covered your code completely, and the order of execution may give
different results, error in one case, ok in others.
-- 

Nick

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32ED2448.685A@parcplace.com> Eric Clayberg <clayberg@parcplace.com> writes:

> David Hanley wrote:
> > Baloney boomerang.  You've made dozens of counterintuitive claims for
> > dynamic typing( smalltalk in particular ) and supported zero of them.
> 
> Counterintuitive to who? To someone who knows little about Smalltalk? To

Well, clearly from the messages, the most likely description for "who"
here is "someone familiar with strong type systems - static or
otherwise".  The Smalltalk aspect seems irrelevant.

> you maybe? A quick scan of the varied responses in this thread indicate
> that for quite a few people, these "claims" are quite intuitive and
> match their own real world experiences.

So?  A similar quick scan reveals "the varied responses in this thread
indicate that for quite a few people, these 'claims' are quite
COUNTERintuitive or even outright unbelievable and don't match their
own real world experiences".  Now what?  Yawn....


> It is the claim that Smalltalk is somehow less reliable than
> statically typed languages that I have seen zero support for (other
> than conjecture and innuendo).

The claim is not that ST isn't less reliable or that it is somehow
impossible to make a program in ST as reliable as a statically checked
strongly typed example.  The argument is really pretty simple:

1) It is possible to construct a rich and descriptively flexible
static type system.  This is obvious - it's been done many times.

2) It is possible to codify a lot of information (both "logic" and
otherwise) in terms of an integrated set of type declarations (aka
complete interface definitions) within such a type system.  This is
obvious as it's also been done many times.

3) It is possible to construct to a fairly large degree (say, 80+% or
more) a static description of a solution to a problem within the
context of and in adherance to the information provided by the types
of 2).  Again, this has been done many times.

4) It is possible to construct an _automated_ consistency checker
within the context of 1) for ensuring that the constructions of 2 & 3
are consistent.  What's more, this checker can run over the static
representations of 2 & 3.  Once more this is obvious - any semantic
analyzer is an example.

5) Application of 1-4 will lead to the discovery of many errors upon
the running of the static analysis.  These errors will include things
like "no such method for object O at invocation I" among several other
kinds.  If you have a somewhat nicer implementation, you may well also
get many "object O is not initialized before use" warnings/errors.
This too clearly happens all the time (GNAT is an example of something
that does both).

Clearly all the errors caught in 5) will never make it to the first
running example - before _any_ testing/debugging has commenced.  None
of these will even be in the picture.  However, it is definitely true
that not all errors (or even such errors) can be determined with such
a static analysis.  In these outlying cases, any decent statically
checked strongly typed language will require insertion of appropriate
_runtime_ (aka dynamic) checks (certainly Ada and Eiffel do this).
You still have to check this stuff with testing.  But many such test
cases are no longer relevant and, even more to the point, can't happen
in the fielded system even if one or more of those test cases was
overlooked.

Now, in the dynamically typed scenario, all those errors, including
things like "no such method for object O at invocation I" and "object
O not initialized before use at location L" have to have and pass
explicit tests in a test suite for the construction.  Such "full
coverage" automated test suite generation is a _lot_ more difficult
than simply doing the static analysis in the first place.  And if you
forget one, that is just one more bomb that the customer may well find
that was not even possible to find in the other scenario.

Is this "proof" that such statically analyzed systems are always more
reliable?  Of course not.  Is it hard evidence from many controlled
experiments checking and confirming that they are?  Well, hardly.
However, it _is_ evidence for the claim that "all things being equal"
(which they seldom are), statically checked, strongly typed systems
will exhibit fewer runtime errors than those which aren't.


> OK, then, back it up. So far, *you* haven't *proven* anything. The above

And neither have you.  So?  Come on - we all know that there just
_isn't_ any highly repeated(able) objective long term studies of such
multiple paradigm usage cross correlated across various domains with
"development speed", "error reduction", "maintenance improvement",
"future flexibility in enhancement", "correctness improvement", etc.
So, noone can even offer a lot of convincing objective evidence for -
much less *prove* - *anything* here.


> as Smalltalk, my experience (and that of many of the folks contributing
> to this discussion) is that the Smalltalk-based systems are usually much
> more reliable in practice.

Yawn - just some more unsubstantiated anecdotal claims.  You're doing
the very thing you are berrating the "other side" for...


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Del Archer]

Robert C. Martin wrote:
> 
> ...
> > In fact it should be an OO sin to ask
> > the type, because, in theory, we don�t want to get intimate with objects
> > we are interacting apart from their interface.
> 
> We typically don't have to ask the type of an object.  In ST, the language
> will do the asking for us at run time.  In C++ the compiler has done it
> at compile time.
> 
> However, there are times both in ST and C++ where we are given an object
> of unknown type and we do not want to send that object a message until
> we *know* it can deal with it.  Thus in ST we use 'respondsTo' and in
> C++ we use 'dynamic_cast'.  Both of these are essentially run time type
> checks that can be applied by the programmer.

I really question the use of 'dynamic_cast'; it makes it difficult to follow the 
open/closed principle.  If a function or method requires a specific type, it 
should only accept objects of that type.


Del.

Re: OO, C++, and something much better!

[Robert Dewar]

Robert Dewar wrote:
> The idea that you can completely ignore efficiency and then somehow
> fix it up later by "optimization" is appealing, but naive. if you want
> efficient, you have think about this requirement from the start. To say
> that you can deal with this later is very similar to the claim that you
> can develop in a sloppy hack-away-and-get-it-working mode and then build
> in reliability later.

Eric replied

 "Not true at all. Getting the program "right" and the algorithms correct
  is the most important thing to do first. Premature optimization often
  leads to less than optimal results."

Robert replies

 Well it depends what you mean by correct here. If correctness includes
 the notion of efficiency in an algorithmic sense (e.g. choose linear
 algorithms over quadratic algorithms where appropriate), then you are
 in fact agreeing with me, since the most important element in creating
 efficient programs is the right choice of data structures and algorithms.
 When I talk about worrying about efficiency up front, that is what I
 am talking about, not about replacing exponentiation by multiplication
 (an activity better left to intelligent compilers in any case).

 What does not work at all is to program something in a sloppy manner without
 regard to space and time use in choice of algorithms and data structures,
 and then expect to be able to "fix" the inevitable efficiency problems that
 result from these bad decisions. Such fixes may require complete rewrites,
 and in your time-to-market environment, such rewrites tend to be impractical.

Eric said

 "Smalltalk encourages getting the job done sooner rather than later. In
  many industries, time-to-market is one of the most important
  considerations."

Robert replies

 Sure and the world is obviously full of situations in which time-to-market
 is more important than reliability (almost the entire world of PC
 applications falls into this category, people are pretty much resigned to
 expecting PC tools to be unreliable).

Eric said

 "Starting (and finishing) sooner and "large and reliable
 systems" are *not* mutually exclusive propositions. If you think they
 are, then maybe you are simply using the wrong tools..."

Robert replies

 Certainly that is the case. However, in high reliability systems, take
 safety critical systems as an ultimate example, the coding time is a
 trivial part of the cost of a system in any case. By the way, are you
 aware of any safety critical systems written in Smalltalk? There must
 be some, but I don't know of any.

Re: OO, C++, and something much better!

[Robert Dewar]

Richard Kenner said

"I've heard nobody claim that *testing* is a bad idea.  The claim, with
which I agree, is that *reliance* on testing is a bad idea.  There's a
very large difference between those claims."

Nicely and clearly put! Really the problem is premature reliance on
testing. A lot of programmers never even seem to read their code, except
in the context of testing and debugging. This means of course that they
read only the code that testing digs up problems with, and the code and
logic paths that do not get fully tested (testing can almost never be
100% complete in real life programs, since the range of inputs is too
large), are never read by anyone.

Re: OO, C++, and something much better!

[Robert Dewar]

iEric said

"Robert Dewar wrote:
> an approach in which the development team is not permitted to do
> any testing!

Jeez. And I thought that approach was proprietary to Microsoft! <GD&R>"


You really should read the literature here, I think it will surprise you.
Yes, I know that the idea of being able to generate correct and reliable
code without the developers doing unit testing is almost inconceivable
to many programmers today, as is the idea of being able to develop code
without a debugger at hand, but that does not mean that it is not possible.

Re: OO, C++, and something much better!

[Robert Dewar]

Samuel says

"Yeah, I can see it that "Many Of You" just say "It Compiles, Let's Ship It"

Well you are a little confused about this, what you might be arguing against,
if you argument makes sense, is a viewpoint of "It is correct, let's ship it",
where correctness has been established by tools, both formal and informal.

Compilers are not typically very good examples of such tools, since they
themselves are beyond this kind of verification. However, have a look at
the SPARC examiner for something close.

Would it work to ship without testing? Hard to imagine right? Obviously
flies in the face of common sense right?

Well common sense is not always a good guide. In practice I can't imagine
not doing some basic integration testing, e.g. running at least the ACVC
suite in the case of an Ada compiler -- although that's not a good example
anyway, since modern compilers are far too complex to verify in either an
informal or formal sense.

However, it is definitely the case that unit testing is a stage that can
be skipped, and indeed what quite a bit of research shows is that software
quality can be improved in an environment where developers rely less on
testing, and more on getting the code right in the first place.



What is worrying is that a remarkable number of programmers seem completely
unaware of the concept of formal reasoning about their code, and are 
completely unaware of tools and techniques to support such reasoning.

I once had someone (who shall be nameless) working on the Ada Ed project
who said to me "there is no point in worrying about being one off in a loop,
you will find the error during testing anyway". Needless to say, this person
did not work long on the project! It is this kind of attutide that brings
you many of the high profile software screwups in this world!

Re: OO, C++, and something much better!

[Joachim Durchholz]

James wrote:

> Depends - are we including C and C++ here ?  In either language, I have
> static type checking, but I can use casting to defeat that type checking -
> thus, I get NONE of the benefits of static typing, and also none of the
> benefits of dynamic checks (as is done in Smalltalk).

Well, this goes overboard. I do get advantages from static typing in C/ 
C++.
There's even evidence for this - one of the worst sources of errors in C  
was that routine parameters were basically untyped. The first reaction was  
the introduction of lint (a tool that was designed to do those checks that  
the C compiler didn't do), the second was requiring types for parameters  
(with some compatibility kludges, but nobody uses old-style routines  
anymore).

These are very C-specific problems though. In C, undeclared parameters  
were cast to the (rather machine-dependent) "int" type, often with heavy  
loss in information and behaviour if the programmer passed something  
different in. The situation is somewhat different in Smalltalk - if an  
object is passed to a point it wasn't expected to go to, it still keeps  
all information and behaviour. Given the completeness of the Smalltalk  
libraries, chances are that the object will still respond in a useful way  
to anything that is thrown at it.

On a more general level, I really would like to have some benefits of  
static typing in Smalltalk. Static typing provides much information for  
optimizers. Static typing allows me to make sure my library will not crash  
if some idiot passes nonsense to them. ("Idiot" in the sense that I do  
idiotic things myself, sometimes.) Static typing allows me to explicitly  
specify contracts between caller and routine (this is a very Eiffelish  
idea that you won't find in most OO language, but it is one the C++  
community would very much like to adopt).
I found an interesting approach in Sather. You don't have to declare  
everything; the compiler assumes the most general type possible if a  
variable is introduced somewhere. Such an approach could, if done well,  
combine the advantages of static and dynamic typing.

Regards,
-Joachim

--
Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

Re: OO, C++, and something much better!

[Joachim Durchholz]

Robert wrote:

> Java has a similar mechanism (isInstanceOf) and so does Eiffel (=?).
                                                                  ^^
It's actually ?= (just helping out those looking for the details in the  
reference manuals).

Other than that, I found the post an excellent clarification in a somewhat  
muddled debate.

Regards,
-Joachim

--
Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

Re: OO, C++, and something much better!

[Joachim Durchholz]

Rolf wrote:

> - That's why I strongly reject any remark of the static typing community
>   that "because Smalltalk doesn't provide static typing, the programs
>   must have more errors"

Well, I wouldn't remark this as a fact but as a concern. After all, I'm  
interested in reliability, though I find myself interested in other things  
as well, such as fast time-to-quality and (as an auxiliary) in reuse and  
flexibility.
Given that a valid concern exists, it is the duty of the dynamic typing  
fraction to provide answers. Not all Smalltalkers in this thread have  
provided answers, some posts consisting of nothing than sarcasm and worse  
things.
I wish to thank all that tried to present the Smalltalk view honestly, and  
it certainly made me rethink some of my positions. I haven't thrown my  
static typing attitude overboard yet - after all, much of the advantages  
of Smalltalk can't be verified except by personal experience or a  
scientific study, neither of which is available to me. But I won't turn  
down job offers from Smalltalk companies in the future on the ground that  
I'd like a professional work environment either...

Regards,
-Joachim

--
Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

Re: OO, C++, and something much better!

[Richard Kenner]

In article <dewar.854542049@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>I once had someone (who shall be nameless) working on the Ada Ed project
>who said to me "there is no point in worrying about being one off in a loop,
>you will find the error during testing anyway". Needless to say, this person
>did not work long on the project! It is this kind of attutide that brings
>you many of the high profile software screwups in this world!

I think you've given a bad example.  Off-by-one in a loop is often a
situation where it will either not work at all or work correctly.
It's also often the case that it'll take a good deal of time to be
confident in the analysis of which is right.

I agree that a programmer who cannot *do* the analysis or who doesn't
understand why one might want to do that is not somebody I'd want to
hire, but I don't see what's wrong with deciding that it's faster to
take experimental approach and try both ways than to spend the time
convincing oneself exactly which is correct.  Of course, if the
decision isn't framed in precisely that way, I agree with you.

On the other hand, I do agree that if it's that hard to figure out
which is correct, probably there's some unnecessary complexity
elsewhere that needs to be removed.

Re: OO, C++, and something much better!

[Robert Dewar]

Robert said

"It is the hallmark of large factorials, that they terminate with lots of zeros.
More interesting yet is that regardless of what radix you convert the factorial
to, providing the radix is not much larger than the factorialized number,
the factorial
will *still* terminate in a lot of zeroes."

I don't see how you find that interesting, it is transparently obvious that
this is the case if you think about it for a moment ...

Re: OO, C++, and something much better!

[Robert Dewar]

Bob Duff said

"It's incredible to me, and I don't count myself among the "test-debug
crowd".  I count myself among the "static type checking, and even
better, formal verification" crowd.  Nonetheless, whatever you've proven
at compile time, I want to see it work."

All I can say, is that people who have not tried this approach are usually
skeptical. Those who have tried it are less so, although in practice as
I mention earlier, usually the clean room approach does not eliminate
testing at a latter stage, it just eliminates testing as a development
tool.

I did try a no-testing approach on one Ada related project at Alsys (though
I did not tell people I was doing it!) I wrote the high precision arithmetic
support package for the Alsys Ada runtime, and quite deliberately decided
not to do any testing at all. I built semi-formal proofs of all the assembly
language involved (perhaps about 500 lines in total, so quite small), but
did not have access to any formal tools.

The resulting code was incorporated into a build that went to customers, and
the testing was minimal, since the ACVC suite did not excercise this 
functionality. I certainly did no testing. 

The bottom line was that this module was not error free, there was one
small error found about a year later, in a very obscure pathological
case that would not have been discovered by testing at least in my
opinion, even if that testing had been formalized to guarantee code
and path coverage (it was basically a problem of misunderstanding the
spec in an obscure case).

However, although not error free, this code was certainly as reliable or
more reliable than other code in the runtime, where we tool a more
traditional approach of relying on testing to a greater extent. It's hard
to say if it was more efficient, since I sure spent a lot of time on those
500 lines of code, but going through this excercise was certainly sufficient
to convince me that removing testing from the developers kit of tools is not
necessarily a terrible idea.

I definitely think that all students should be exposed to this approach.
I know that this is done at FIT (Florida Institute of Tech) in their
Software Engineering program. At first students are dismayed, even
distraught, at the idea of having to develop code without testing, but
by the end of the semester, they have amazed themselves by proving to
themselves that it is possible.

I am not arguing for a dogmatic "developers should be arrested if they
attempt to execute their code" approach, but it is a very good idea for
people to understand that formal reasoning and careful reading of code
*before* it is tested is a powerful tool for generating reliable software.
And this applies not matter *what* language things are written in, although
in practice some languages will encourage this approach more than others.
As I mentioned earlier, if you ask a roomful of Ada programmers how many
depend on the debugger, only about half will put up their hands, but if
you ask the same question of a roomful of Smalltalk or Lisp programmers,
you will get a *much* larger response, and indeed the question will strike
people as ludicrous.

Now I trust that there are indeed Smalltalk programmers who read their code,
and avoid over-dependence on testing and debugging, just as there are
certainly slash-and-burn-and-test-and-debug Ada programmers out ther, but
there is definitely an extent to which different languages encourage 
different styles of development.

Re: OO, C++, and something much better!

[Robert A Duff]

In article <JSA.97Jan28183735@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:
>...  The idea of "one language for all
>things" is every bit as silly as "_the_ theory of everything".

True.  I don't claim there can be one programming language for all
things.  I claim that we can do a lot better than we're doing now.  I
mean, I think it *is* feasible to have a programming language that's
suitable for building applications that cover several application areas.
And it's necessary: Don't tell me you're using Ada for the "reliable"
parts of the program, and Smalltalk for the "GUI" parts of the
application -- this implies that you don't care if the GUI parts are
buggy.

I claim that the main thing that matters for any particular application
area is the availability of good (preferably standard!) libraries.  The
underlying programming language doesn't matter (as much).  The
"built-in" features of a programming language ought to support the
building of highly reusable, reliable application-area-specific
libraries, rather than trying to support those areas directly.  Given
that approach, I think you can get a lot further along the path toward
the "ultimate language" than we are now, though I agree we'll never get
to the end of that path.

>So, it makes a lot of sense to concentrate on working out explicit
>well defined interface points between PL semantics where the
>"impedance mismatch" is controlled and "easily" managed.  Of course
>this would require real communication and cooperation between the
>various camps - wow, what a novel idea...

Shrug.  I don't see how this is all that different from what I said
above.  I mean, you can get rid of the impedence mismatch entirely by
making all languages the same.  I certainly agree that it would be a
good thing if all language designers could agree on some basic stuff
(like terminology), but I think it's really too premature to expect that
to happen right now.

Anyway, look at the actual differences among the various languages in
common use.  Many of those differences have nothing to do with being
suitable for particular application areas or purposes.  E.g. Ada is case
insensitive, C is case sensitive.  It's possible to believe that case
sensitivity or insensitivity (or one of several other alternatives) is
"better", but it has little to do with the application area.  It has a
lot to do with the taste and attitudes of the individual programmer.
(Oh, boy, I hope I didn't just start a sub-war on the merits of case
[in]sensitivity.)

Another example: somebody claimed in this thread that Smalltalk's
named-notation call syntax makes programs less buggy (than C++, I
guess).  I've made the same claim for Ada (which makes named notation
optional).  One can argue about which of these three (or various other
possibilities I can think of) is best.  But I don't see how this has
anything whatsoever to do with whether you're writing GUI-ish code, or
hard-real-time code, or whatever.

Also, note that by and large, people don't choose languages based on
application areas -- they program in the language they're used to, or
that they enjoy programming in, or that everybody else uses.

>Agreed, but it is pretty trivial compared to the next task up the
>ladder: that of having a module's contextual semantics spelled out and
>codified as part of its overall semantic description, thereby allowing
>at least the possibility of true parts catalogues.  Don't hold your
>breath...

I won't.  ;-)

>> So I don't buy the idea that you can just choose whatever language is
>> best for each module, and then paste them together.

Just to clarify: It's certainly feasible to write a 100,000-line
subsystem in one language, interfacing to another 100,000-line subsystem
in another language.  The interface is painful, but it's small enough to
be manageable.  But you can't feasibly write every other 100-line module
in a different programming language.

>Then the software biz is never going to get beyond the artisan or
>blacksmith stage it's been stuck in for the last 35 odd years.

Perhaps it never will.  :-) / 2.

- Bob

Re: OO, C++, and something much better!

[Joachim Durchholz]

Luther wrote:

> Rather than going back and forth about the merits of type checking we
> should examine whether type mismatching is an important source of errors
> in "tested" programs.

Well, it's not in statically checked programs, so the hard data for this  
should come from the Smalltalk community.
Unfortunately Smalltalkers don't think in types (at least I didn't get  
that impression, correct me if I got this wrong), so I fear they aren't  
prepare to provide such data.

Regards,
-Joachim

--
Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

Re: OO, C++, and something much better!

[Robert A Duff]

In article <dewar.854543281@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>iEric said
>>Jeez. And I thought that approach was proprietary to Microsoft! <GD&R>"

What's "GD&R"?

>You really should read the literature here, I think it will surprise you.
>Yes, I know that the idea of being able to generate correct and reliable
>code without the developers doing unit testing is almost inconceivable
>to many programmers today, ...

There's a big difference between (1) developers do no testing, but a
separate Testing Department does, and (2) developers do no testing, and
hand off half-baked code to their customers.  IMHO, *relying* on
testing, or formal proofs, or any other single technique is foolish.
The enemy is bugs, and we should use every technique at our disposal to
eliminate them from released software.

>... as is the idea of being able to develop code
>without a debugger at hand, but that does not mean that it is not possible.

Debuggers are like any other helpful thing -- if you rely on it, you get
lazy.  Limited access highways, with wide lanes, broad curves, wide
median strips, big green signs marking the exits, etc., are safer than
two-lane roads with sharp curves and driveways entering with no warning.
But some or all of that advantage is lost if the drivers start falling
asleep behind the wheel.  (Also, windy two-lane roads are more fun to
drive on -- some people think debugging is fun, too.)  ;-)

- Bob

Re: OO, C++, and something much better!

[Robert Dewar]

Bob Duff said

"But, to be fair, to the dynamic-typing folks, static checking can't
prove the absense of bugs, either.  There is no silver bullet.  Static
checking eliminates *some* bugs, and that's good.  A catch-phrase like
"testing can't eliminate bugs" isn't helpful, since no other technique
is perfect, either."


Well that's a little misleading. Static checking does indeed prove the
absence of certain kinds of bugs. How far you want to expand this set
of errors that can be eliminated completely and reliably is one of the
fundamental design parameters in design of PL's.

YOu can indeed go very far. Look for instance at the programming language
that is derived from Martin Lof logic. In this language, it is impossible
to write any program that is not totally correct in a formal sense. Of
course the program might not do what you want (Bob's comment about the
correctness of the specs themselves is of course a fundamental one), but
you can't get any type errors, interpreted in the broadest possible sense,
and the prrogram is guaranteed to terminate with an output that conforms
to the specification.

The trouble with going in this direction is that you do limit expressive
power. Martin Lof logic for example allows only primitive recursion as
a control construct (*), and also you arrive at a formalism that is proably
beyond the capabilities of most programmers.

P.S. (*) primitive recursion is a little more powerful than people suppose,
there is for example no problem in programming Ackerman's function using
primitive recursion with higher order functions.

P.P.S. Is there a separate newsgroup which would be more appropriate to these
general programming language discussions. It seems to me that these heavily
cross-posted discussions probably constitute serious and annoying noise
for the majority of readers of all groups concerned.

Re: OO, C++, and something much better!

[Dennis Smith]

In article <6PnYDRs-3RB@herold.franken.de>, jhd@herold.franken.de (Joachim Durchholz) wrote:
>James wrote:
>
>> Depends - are we including C and C++ here ?  In either language, I have
>> static type checking, but I can use casting to defeat that type checking -
>> thus, I get NONE of the benefits of static typing, and also none of the
>> benefits of dynamic checks (as is done in Smalltalk).
>
>Well, this goes overboard. I do get advantages from static typing in C/ 
>C++.
>There's even evidence for this - one of the worst sources of errors in C  
>was that routine parameters were basically untyped. The first reaction was  
>the introduction of lint (a tool that was designed to do those checks that  
>the C compiler didn't do), the second was requiring types for parameters  
>(with some compatibility kludges, but nobody uses old-style routines  
>anymore).
>
>These are very C-specific problems though. In C, undeclared parameters 
****    Not all C compilers (in fact not many) convert parameters.  In fact
        what usually happens is you put it on the stack and the recipient 
        picks it up as if it were what was expected.  Thus it might be
        that an integer value is treated as a pointer, or perhaps a pointer
        as 4 characters, or other horrible things.

        Having made THAT point, let me talk a bit about type checking and
        its uses.

        1. type checking can be useful in certain places
        2. type checking can be a nuisance in other places

        In ST you often write code that does not care (to some extent) about
        the type.  You might create a method "increment" to add 1 to
        something.  You can add "1" to many things (integer, float, date, 
        time).  The problems of core-dumping, aborting or what have you,
        which would occur in C, or even worse, slightly wrong results, in
        cases where type checking SHOULD have been done, are not nearly
        as serious in ST.  For example, using the comments above on
        no-type-checking for procedure parameters -- lets assume one passed
        an integer instead of a pointer.  This would either cause an abort
        or a garbage value in C.  In ST, it is most likely that the message 
        you would send to the non-numeric object passed would simply not
        be recognized and you would get a clean, informative error.
        MUCH better then missing type-checking in C.
       
        My point here is that lack of type-checking in ST is no nearly
        as serious as lack of type-checking in C (or even C++).
       
        Having said that, there ARE some cases where it might be nice
        to have some "optional" type-checking in ST, recognizing that
        it could probably not be 100% because of the nature of ST.

        Having done development for 10 years in C, a few months in C++
        and 2.5years in ST, I would take ST over C or C++ without
        any second thoughts.  I would ALSO insist on type-checking
        in any C/C++ implementation because of the nasty
        consequences of NOT having it.

 
>were cast to the (rather machine-dependent) "int" type, often with heavy  
>loss in information and behaviour if the programmer passed something  
>different in. The situation is somewhat different in Smalltalk - if an  
>object is passed to a point it wasn't expected to go to, it still keeps  
>all information and behaviour. Given the completeness of the Smalltalk  
>libraries, chances are that the object will still respond in a useful way  
>to anything that is thrown at it.
>
>On a more general level, I really would like to have some benefits of  
>static typing in Smalltalk. Static typing provides much information for  
>optimizers. Static typing allows me to make sure my library will not crash  
>if some idiot passes nonsense to them. ("Idiot" in the sense that I do  
>idiotic things myself, sometimes.) Static typing allows me to explicitly  
>specify contracts between caller and routine (this is a very Eiffelish  
>idea that you won't find in most OO language, but it is one the C++  
>community would very much like to adopt).
>I found an interesting approach in Sather. You don't have to declare  
>everything; the compiler assumes the most general type possible if a  
>variable is introduced somewhere. Such an approach could, if done well,  
>combine the advantages of static and dynamic typing.
>
>Regards,
>-Joachim
>

------------------------------------------------------------------------------
Dennis Smith, quenton@Cherniak.ON.CA, UUCP: ..!gts!cherniak!quenton            
+1 905 771 7011, FAX +1 905 771 6288                                           
Cherniak Giblon 10 Commerce Valley Dr. E. #400, Thornhill, Ont. CANADA L3T 7N7 

Re: OO, C++, and something much better!

[Stanley R. Allen]

Robert A Duff wrote:
> 
> Interfacing between two different languages is a serious problem.  The
> design of Ada 95 goes to a great deal of trouble to make interfacing
> between Ada and C (etc) as easy as possible, but it's still painful.
> Silly little things, like whether strings are null-terminated, or carry
> their bounds with them.
> 
> So I don't buy the idea that you can just choose whatever language is
> best for each module, and then paste them together.

In the future this may be commonplace and quite easy, if everyone can
specify their interfaces in a 'neutral' language like CORBA's IDL.
I don't particularly care for IDL (its type system is very weak),
but it may do the job just fine for the next 10 years or so.  It
would be nice to see all new API's specified in something like IDL
rather than some particular programming language.  For example, it
would help a great deal if all GUI and OS APIs had 3GL-neutral IDL
descriptions.  Too much time, money, and intellectual capital is
wasted on these ridiculous interface issues.  Much of my debugging
time is spent chasing the kinds of interface problems Bob Duff is
talking about.

Having a neutral interface language with standard mappings would go
a long way to improving the programming landscape.  CORBA IDL may
herald a renaissance of multi-linguism in software development,
something which has been slowly dying over the last decade, mainly
due to the need to conform to C as the least-common denominator
for interfacing.  

-- 
Stanley Allen
mailto:s_allen@hso.link.com

"The Road Ahead": perspectives from one of capitalism's winners.

Re: OO, C++, and something much better!

[David Hanley]

Jacqueline U. Robertson wrote:
> 
> Keywords:
> Cc:
> 
> In article <32EE20A3.755D@netright.com>,
> David Hanley  <david_nospam@netright.com> wrote:
> >>
> >       I have.  All other things being equal, there are fewer errors that can
> >happen in a static typed system, as opposed to a dynamially typed
> >system.  Your refusal to accept this simple arguement makes you appear
> >as if you have some kind of religous attachment to your system.
> >
> >       Let's start very simply; is the above system true or false?
> >
> Depends - are we including C and C++ here ?  In either language, I have static
> type checking, but I can use casting to defeat that type checking - thus,
> I get NONE of the benefits of static typing, and also none of the benefits
> of dynamic checks (as is done in Smalltalk).
> 
> IMHO, he arument runs like this:  In the case of Smalltalk, the 'cost' of
> adding static typing  ( in terms of reduced flexibility and slower
> development time ) is not worth the 'gain'of static typing.  To some
> extent, this is a subjective statement - but having used C, C++,
> and Smalltalk extensively, IMHO development is more rapid and
> more safe (less error prone) in Smalltalk than in C or C++.

	I am completely willing to accept the fact that smalltalk development
may be faster and more bug-free than C++ development.  However, I don't
necessarily accept the fact that this is becuase of static typing or the
lack thereof.  I don't even think c++'s type system is particularly
nice.  There are a lot of errors that can happen in c that won't crop up
in smalltalk, such as a host of memory issues, etc.  But this have
nothing to do with static/dynamic typing.


------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[Stanley R. Allen]

James O'Connor wrote:
> 
>  [...] I actually had an Ada83
> program that blew up at runtime precisely because it was strong-typed.
> The designer had put an upper limit on a type, based on real-world
> conditions.  That upper limit didn't really mean anything, we didn't
> care about what it was.  It just happaned to be a high enough value that
> the designer thought would be sufficient.  The designer was wrong, the
> real world changed, conditions were different, and the system crashed
> because a totally meaningless limit was placed on a value in obediance
> to the typing system.  If that had been in Smalltalk, the value would
> have rolled over from Integer to LargeInteger and gone right along
> without caring (because we didn't care either, and neither did the
> use...until it crashed).
>         That was when I stopped trusting the typing system.
> 

This was obviously a design error, not a fault of static typing or
Ada83's version of it.  The telling statements are "the upper limit
didn't really mean anything", and "the designer thought it would be
sufficient".

Your specific complaint is really that Ada83 did not provide an
automatic roll-over capability for integers as part of the language.
If that's the kind of thing you want (a design question), you can
achieve it in many statically-type languages; it can easily be done
in Ada83 or Ada95 using a pacakge with a private type and overloaded
operators.

-- 
Stanley Allen
mailto:s_allen@hso.link.com

"The Road Ahead": perspectives from one of capitalism's winners.

Re: OO, C++, and something much better!

[David Hanley]

Eric Clayberg wrote:
> 
> > And what exactly does this have to do with static and dynamic typing?
> 
> Not much. Again, I was merely responding to your comment which was
> clearly in err.

	No.  You stated that it was better in smalltalk than in other
languages.  In all the languages mentioned, you have to account for the
possibility of a null pointer usage; if you don't, your program will
likely fail.  

	Personally, I don't care if it's a gpf, or a little smiley window
saying that a bad message send occured; but that's a value judgement.

-- 
------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[Robert A Duff]

In article <dewar.854542590@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Robert said
>
>"It is the hallmark of large factorials, that they terminate with lots of zeros.
>More interesting yet is that regardless of what radix you convert the factorial
>to, providing the radix is not much larger than the factorialized number,
>the factorial
>will *still* terminate in a lot of zeroes."
>
>I don't see how you find that interesting, it is transparently obvious that
>this is the case if you think about it for a moment ...

Yeah, but Mr. Martin injected the only verifiable FACT into this thread
so far, which I think was his point!

- Bob

Re: OO, C++, and something much better!

[David Hanley]

Eric Clayberg wrote:
> 
> David Hanley wrote:
>
> > Since we both agree that there is a certian class of errors that
> > statically typed languages prevent, what needs to be shown is what
> > errors dynamically typed languages will prevent.  I am not aware of
> > these, and I sure haven't seen any sign of them!
> 
> Good. So you are admitting that you might be "uninformed" on this topic?

	Absolutely not.  The fact that you, nor anyone else, have refuted it
makes me only more sure of the assertion.

> That's OK though. Since you haven't used Smalltalk, 

	Untrue.  I have written code in smalltalk.

> I wouldn't expect
> you to understand its capabilities.

	Of course not.  Since I don't agree with you, I must not know the
facts, ipso facto.


> > Ok, I'm makign one assumption:
> >               static typing           dynamic typing
> > type errors        few                     more
> > other errors       same                    same
> 
> Hmmm. That's a mighty broad assumption. Do all statically typed
> languages achieve the same error rates?

	Irrelevant to the discussion at hand.  The issue is static vs dynamic
typing.

> Do all dynamic languages? How
> are you quantifying "few" and "more"? Could "more" mean "few+1"? What do
> you consider "type" errors vs. "other" errors?

	Again, irrelevant.  The issue is sytatic vs dynamic typing, and what
it's effects on the frequency of program errors.  I would be happy to
hear one error describes which would not arise in a statically typed
enviornment.  This would, of course, destroy my enviornment.

> 
> > Since we agree on the first line, the second one is then in question.
> 
> Yeah. It gets back to your earlier "set of errors" argument. What are
> you defining as "other errors". If you want to play this game, then you
> should at least define your terms.

	Again, I would be happy to renounce the arguement if I could hear of
one error which will not occur in a dynmaically typed enviornment as
opposed to a static one.  I have made this quite clear, and I suspect
that the fact that you have not presented one meand that you can't think
of any either.

	Of course, the number of errors which may occur are many, and I don't
really feel like enumerating every single one!

	But, in the interest of reaching a speedy conclusion, let's throw a few
out:

	Array out-of-bounds.
	Null pointer usage.

	Do you feel any of these are inherently less likely in a
dynamically-typed language?  if so, why?

> Since this "set of errors" argument was yours, it would be much more
> appropriate for you to actually back up your own argument and provide
> said set of errors.

	Ok, it's all errors which are not un-understood message sends, ok?

> Since I don't agree with your premise to begin with,
> I don't know what set of errors you had in mind. If you provide the
> list, I (and I'm sure many others) would be happy to point out which
> ones don't apply.

	Ok, which errors don't apply, aside from not-understood messages?

-- 
------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[Eric Clayberg]

Jon S Anthony wrote:
> 
> In article <32ED2448.685A@parcplace.com> Eric Clayberg <clayberg@parcplace.com> writes:
> 
> > David Hanley wrote:
> > > Baloney boomerang.  You've made dozens of counterintuitive claims for
> > > dynamic typing( smalltalk in particular ) and supported zero of them.
> >
> > Counterintuitive to who? To someone who knows little about Smalltalk? To
> 
> Well, clearly from the messages, the most likely description for "who"
> here is "someone familiar with strong type systems - static or
> otherwise".  The Smalltalk aspect seems irrelevant.

It seemed relevant since David explicitly mentioned it in his comment.
In fact, since the claims seemed to be quite intuitive to the folks
familiar with static type systems *and* Smalltalk, I was left to
conclude that they were only counterintuitive to those who were familiar
with static type systems who were *not* familiar with Smalltalk.

> The claim is not that ST isn't less reliable or that it is somehow
> impossible to make a program in ST as reliable as a statically checked
> strongly typed example.

Good. Several folks seemed to have adopted that position. I only entered
this discussion to begin with based on comments to the effect that
Smalltalk was not a reliable language due to its lack of static typing. 

> Is this "proof" that such statically analyzed systems are always more
> reliable?  Of course not.  Is it hard evidence from many controlled
> experiments checking and confirming that they are?  Well, hardly.

I couldn't agree more.

> However, it _is_ evidence for the claim that "all things being equal"
> (which they seldom are), statically checked, strongly typed systems
> will exhibit fewer runtime errors than those which aren't.

Well, since, as you point out, all things are seldom equal, it is only
evidence that "statically checked, strongly typed systems will exhibit
fewer *type-related* runtime errors than those which aren't". It says
nothing about fewer errors overall or about the ultimate reliability of
the delivered systems.

> And neither have you.  So?

Since I have only been arguing *against* the negative (i.e., "Smalltalk
is less reliable"), the burden of proof was on the other side. That
proof has not been forthcoming. And, as you so clearly point out, such
"proof" is virtually impossible to obtain anyway.

> > as Smalltalk, my experience (and that of many of the folks contributing
> > to this discussion) is that the Smalltalk-based systems are usually much
> > more reliable in practice.
> 
> Yawn - just some more unsubstantiated anecdotal claims.

Which is why I was very careful to include the phrase "my experience"
and not try and argue that this constituted any sort of proof. I can no
more prove that Smalltalk-based systems are more reliable than anyone
else can prove that they're not.

-Eric

Re: OO, C++, and something much better!

[Matt Kennel]

Alan Lovejoy (alovejoy@concentric.net) wrote:

: And a strong case can be made that having the compiler check based on "types"
: (actually type constraints/assertions) assigned to variables (not objects) 
: is a severe violation of the information hiding principle.  An object should
: ideally be a black box that hides its implementation (class).  Exposing the
: interface of the object is acceptable, even good.  But most statically-typed
: OO languages go beyond that into exposing the implementation (class)--and then
: hard coding it into type constraints on variables in the program source, which 
: is very, very bad.  

1) Why is this very very bad?  Why is it non-very bad? 
  
2) The type constraints on variables do not necessarily prescribe any
   particular concrete class, much less expose any internal class information
   to extra manipulation.  What is the relation to "information hiding"?  The
   inside-vs-outside encapsulation generated by Eiffel classes or Ada packages
   or M3 modules has no relation to type constraints on variables, as far
   as I can see. 

: Using the class as a substitute for the interface violates the information hiding
: principle.  This was and is the issue.

3) And suppose you actually want to specify a particular concrete class? 
   You have "hard code" classes to create instances, after all.
   
: --
: Alan L. Lovejoy		|==============================================| 
: Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
: alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[David Hanley]

Richard Kenner wrote:
> 
> In article <dewar.854542049@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> >I once had someone (who shall be nameless) working on the Ada Ed project
> >who said to me "there is no point in worrying about being one off in a loop,
> >you will find the error during testing anyway". Needless to say, this person
> >did not work long on the project! It is this kind of attutide that brings
> >you many of the high profile software screwups in this world!
> 
> I think you've given a bad example.  Off-by-one in a loop is often a
> situation where it will either not work at all or work correctly.

#define NumEntries 100000
entry entries[ NumEntrues ];

for( a = 0 ; a < min( top , NumEntries ) ; ++ a ) 
{
    ....
}

It seems very likely to me that the above may get missed in testing. 


> I agree that a programmer who cannot *do* the analysis or who doesn't
> understand why one might want to do that is not somebody I'd want to
> hire, but I don't see what's wrong with deciding that it's faster to
> take experimental approach and try both ways than to spend the time
> convincing oneself exactly which is correct.  Of course, if the
> decision isn't framed in precisely that way, I agree with you.

	I think that this discussion( dynamic vs static typing ) could be more
broadly generalized to a discussion of weather it is better to find bugs
by testing, or to find bugs by formal mentods( types, constraints, etc
).


-- 
------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam

Re: OO, C++, and something much better!

[Alan Lovejoy]

Al Christians wrote:
> 
> Alan Lovejoy wrote:
> 
> >> Smalltalk can call C just as easily as Java or Basic can.  Two way interoperability (where C calls Smalltalk) has been a problem, but
> there are now at least two different Smalltalk implementations that
> compile to "native code" directly (no bytecodes at all, this is better
> than JIT compilation).  With "classic"  native code compilation, two-way
> interoperability is not a problem <<
> 
> This is the first interesting tidbit in this entire tiradathon. Please
> tell us more about these new Smalltalk implementations.
> 
> Al

Browse the following links:

ObjectConnect (SmalltalkMT)     http://www.objectconnect.com/
Smalltalk/X:            	http://www.informatik.uni-stuttgart.de/stx/stx.html

Also, there is a WWW site with a FAQ:  http://www.dnsmith.com/SmallFAQ/

Thirdly, there are some free Smalltalks that you can download from the net:

SmalltalkExpress:       http://www.objectshare.com/osi/main/stexpress/introstexpress.htm
Squeak:                 http://www.research.apple.com/research/proj/learning_concepts/squeak/
LearningWorks:          http://sumeru.stanford.edu/learningworks/

Fourthly, there are commercial vendors with WWW pages (one of which is making
its beta product available for free):

Intuitive (Dolphin Smalltalk):          http://www.intuitive.co.uk
ParcPlace-Digitalk
    (VisualWorks & VisualSmalltalk):    http://www.parcplace.com
IBM (VisualAge):                        http://www.software.ibm.com/software/ad/
Gemstone:                               http://www.gemstone.com/
OTI:                                    http://www.oti.com/
QKS:                                    http://www.qks.com/
VMARK (ObjectStudio):                   http://www.vmark.com/

Fifthly, there is the Smalltalk Store: http://www.smalltalk.com/

And finally, there is a WWW page on Yahoo:
http://www.yahoo.com/Computers_and_Internet/Programming_Languages/Smalltalk/

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Eric Clayberg]

Robert A Duff wrote:
> What's "GD&R"?

Grinning, Ducking & Running. Often used to signify a cheap shot. ;-)

-Eric

Re: OO, C++, and something much better!

[Richard Kenner]

In article <32EFA614.7C93@netright.com> david_nospam@netright.com writes:
>Richard Kenner wrote:
>> I think you've given a bad example.  Off-by-one in a loop is often a
>> situation where it will either not work at all or work correctly.
>
 ... example deleted ...

>It seems very likely to me that the above may get missed in testing. 

I said "often", not "always", so a counterexample doesn't disprove
what I said.

Re: OO, C++, and something much better!

[Ted Dennison]

Tim Ottinger wrote:
> 
> On Mon, 27 Jan 1997 17:36:03 -0500, "Norman H. Cohen"
> <ncohen@watson.ibm.com> wrote:
> 
> >No, I've such comparisons between Ada and C/C++ (see, for example
> >http://sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html,
> >which shows the same programmers developing Ada code and C code, and
> >producing the average Ada line for 60% of the cost of an average C line,
> >with only 1/6 as many defects in the delivered code), but not between
> >Ada and Smalltalk.  I would certainly be interested in such
> >comparisons.  If there are any Smalltalk versus C comparisons, it 
> 
> Just a note on per-line measurements across languages: Don't buy it.
> I saw one where it "proved" that COBOL or ASSEMBLY were the better
> quality languages to use and that it was unjustifiable to use Ada
> and C programmers, who may cost $100s per line of code.

Actually, the report addresses all these concerns and more. You really
should read it before saying things like this.

-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: OO, C++, and something much better!

[Stephen J Bevan]

In article <32EEC23E.4F1A@concentric.net> Alan Lovejoy <alovejoy@concentric.net> writes:
   Does Mercury use Algol-style function call syntax?  That is, 
   "f(x, y, z, ...)"? 

Which Algol do you mean here?  The last Algol 60 report I looked at
[algol60:bcs:cj:1976] contains the following example on page 373 :-

  PROCEDURE Spur(a) Order:(n) Result:(s); VALUE n
  ARRAY a; INTEGER n; REAL s;
    BEGIN INTEGER k;
     s := 0;
     FOR k := 1 STEP 1 UNTIL n DO s := s + a[k,k]
    END

(I've used capitals where boldface is used in the report) which you
can call as :- 

  Spur(a) Order:(7) Result:(V);

Granted you could also define it as :-

  PROCEDURE Spur(a, n, s); VALUE n
  ARRAY a; INTEGER n; REAL s;
    BEGIN INTEGER k;
     s := 0;
     FOR k := 1 STEP 1 UNTIL n DO s := s + a[k,k]
    END

and call it as :-

  Spur(a, 7, v);

Ada carries on this tradition of allowing both positional and named
parameters though with a different syntax to the above.


   If so, the fact that Smalltalk will have fewer cases of "wrong argument" due
   to its superior function call (message send) syntax is not a
   debatable point.  It's a fact.

Superior to what?


@article
{ algol60:bcs:cj:1976
, author=   "P. Naur and J. W. Backus and F. L. Bauer and J. Green and
C. Katz and J. McCarthy and A. J. Perlis and H. Rutishauser and K.
Samelson and B. Vauquois and J. H. Wegstein and J. H. {van
Wijngaarden} and M. Woodger and R. M. {De Morgan} and I. D. Hill and
B. A. Wichmann"
, title=    "Modified Report on the Algorithmic Language ALGOL 60"
, journal=  bcs:cj
, volume=   19
, number=   4
, pages=    "364--379"
, month=    nov
, year=     1976
, refs=     9
, checked=  19970119
, source=   "Computer Science Library, University of Manchester"
, reffrom=  Harland:poly:1984
}

Re: OO, C++, and something much better!

[Eric Clayberg]

David Hanley wrote:
> You stated that it was better in smalltalk than in other languages.

Where did I say that? All I did was respond to your comment:

> So smalltalk will happily pass a message to the nill object, and the
> progrm will chug along just fine?

> In all the languages mentioned, you have to account for the
> possibility of a null pointer usage; if you don't, your program will
> likely fail.

Absolutely. I never said nor implied otherwise.

-Eric

Re: What is wrong with OO ?

[Damon Feldman]

In article <rmartin-2701971103140001@pool10-006.wwa.com>, rmartin@oma.com (Robert C. Martin) wrote:
>In article <5bub0e$jfc@uni.library.ucla.edu>, jmartin@cs.ucla.edu (Jay
>Martin) wrote:
>
>> Since C
>> programmers are notorously ignorant of computer language design, the
>> audience is not too discerning. 
>
>This is a an unworthy, biased, and biggotted statement.  The only common
>attribute shared by the class of people called "C programmers" is that they
>write programs in C. 

While technichally true, I hope this doesn't mean that I have to stop 
insulting COBOL programmers when I see them on the street :-).

Perhaps the original poster meant to say that programmers who *advocate C
as a superior language* are ignorant of language design.  This would have
some logic behind it.

Damon

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Lawrence G. Mayka]

piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote:

>It is much better to provide the two things separatley, for this allows
>for example ``exception handling'' _without_ forcing control transfers,
>and control transfers without necessarily involving dynamically scoped
>identifiers. And then runtime parametrization via dynamically scoped
>variables...

Ironically, though, your first posting in this thread was a response
to =my= posting, pointing out to Mr. Stroustrup that his design for
exception handling was implemented years earlier in Common Lisp.  As
you may know, Common Lisp has long had both nonlocal control transfers
(THROW and CATCH--perhaps Bjarne even borrowed his keywords from
Lisp!) and dynamically scoped variables (as an option, along with the
default behavior of lexical scoping).  Indeed, some implementations of
ANSI Common Lisp exception handling do indeed employ these earlier
constructs.  Just as you suggest, dynamically scoped functions are
easily simulated via dynamically scoped variables whose values are
function objects, or via syntax extension (the Common Lisp
macroization system).

But what your scheme lacks is a classification or "matching"
mechanism.  Common Lisp was well-prepared to provide this because,
even before the standardization of CLOS, it offered the
single-inheritance capability of DEFSTRUCT and the type-testing
operator TYPEP; and so the Pittman Condition System was implementable
entirely on top of 1985-vintage Common Lisp constructs, yet easily
extendible to CLOS later.

One other very useful element both your scheme and that of C++ lacks
is that of closures as handlers.  Very often, an exception handler is
more comfortably and easily written as a lexically scoped function
that manipulates the variables of an outer function.  Again, Common
Lisp already had full-power lexical closures by 1985, whereas C++
still doesn't.

You may ask, if a language such as Common Lisp already has all the
necessary base capabilities, why provide the "syntactic sugar" of
exception handling constructs?  To clarify, standardize, and perhaps
optimize conventional usages.  Since Common Lisp supports syntax
extension (a powerful macroization system), programmers would probably
be writing such syntactic encapsulations anyway; we may as well
standardize them to enhance portability of programs, skills,
knowledge, etc.


Lawrence G. Mayka
lgmayka@sprynet.com

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert Dewar]

Lawrence said

"Ironically, though, your first posting in this thread was a response
to =my= posting, pointing out to Mr. Stroustrup that his design for
exception handling was implemented years earlier in Common Lisp."

It is just conceivably possible that Mr Stroustrup is indeed familiar
with Common Lisp and quite a few other languages :-) :-) :-)

(is three smileys enough to make it quite clear to people that an element
of sarcasm is intended :-)

If you really think that Common Lisp invented the idea of exceptions, then
you need to do some more history reading yourself!

Really, everyone should realize that language design does not happen in
a vacuum. Of course good ideas are borrowed from one language to another.
For example, many of the most important contributions that Algol-68 has
been made are in the form of ideas exported to other languages (e.g.
serial elaboration of declarations and the notion of subunits -- copied
from A68 into Ada). 

Re: OO, C++, and something much better!

[Robert A Duff]

In article <32EFB3D4.167E@hso.link.com>,
Stanley R. Allen <s_allen@hso.link.com> wrote:
>Robert A Duff wrote:
>> So I don't buy the idea that you can just choose whatever language is
>> best for each module, and then paste them together.
>
>In the future this may be commonplace and quite easy, if everyone can
>specify their interfaces in a 'neutral' language like CORBA's IDL.

Nah.  IDL is just one more language.  Interfacing between IDL and
(whatever-your-favorite-programming-language) is costly.  It's worth it,
sometimes, but nonetheless costly.

There is no "language neutral" language, IMHO.  Nor can there be.

IDL supports multiple inheritance, but some languages don't.  For
example.

>Having a neutral interface language with standard mappings would go
>a long way to improving the programming landscape.  CORBA IDL may
>herald a renaissance of multi-linguism in software development,
>something which has been slowly dying over the last decade, mainly
>due to the need to conform to C as the least-common denominator
>for interfacing.  

IDL (and/or something like it) can improve things, but it's no panacea,
IMHO.

- Bob

Re: OO, C++, and something much better!

[Robert A Duff]

In article <32EFB711.2781@hso.link.com>,
Stanley R. Allen <s_allen@hso.link.com> wrote:
>Your specific complaint is really that Ada83 did not provide an
>automatic roll-over capability for integers as part of the language.
>If that's the kind of thing you want (a design question), you can
>achieve it in many statically-type languages; it can easily be done
>in Ada83 or Ada95 using a pacakge with a private type and overloaded
>operators.

But then you lose a lot.  You can't do case_statements on that type.
You can't declare subranges, and have them automatically checked at run
time.  Literals don't work.  You can't index arrays by that private
type.  You can't say "if X in 1..100 then...".

- Bob

Re: OO, C++, and something much better!

[Nick Leaton]

Richard Kenner wrote:
> 
> In article <dewar.854542049@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> >I once had someone (who shall be nameless) working on the Ada Ed project
> >who said to me "there is no point in worrying about being one off in a loop,
> >you will find the error during testing anyway". Needless to say, this person
> >did not work long on the project! It is this kind of attutide that brings
> >you many of the high profile software screwups in this world!
> 
> I think you've given a bad example.  Off-by-one in a loop is often a
> situation where it will either not work at all or work correctly.
> It's also often the case that it'll take a good deal of time to be
> confident in the analysis of which is right.

You can't be serious. It is not black and white. In plenty of situations
with C++ or C it might work for sometime, and then cause problems.

-- 

Nick

Re: OO, C++, and something much better!

[Alan Lovejoy]

Fergus Henderson wrote:
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> [snip]
>
> >I think this is because Smalltalk
> >uses global variables far less than is common in other languages,
> 
> That explanantion is almost certainly wrong.  I strongly suspect that
> global variables are used even less in Mercury than in Smalltalk,
> because Mercury, being a pure functional/logic language, does not
> provide any language support for them.

Ok. There are a handful of global variables used by the Smalltalk system itself.
It is rare for application code to refer to any of those.  My own personal coding
style never declares global variables.  Period.

> >> The fourth case involved trying to use the same name for two different
> >> variables.  I'm not sure whether that one would have occurred in Smalltalk.
> >> I guess it would depend on whether the programmer noticed that there
> >> was already a declaration for that variable.
> >
> >As noted above, this can't occur in Smalltalk without warning.
> 
> I would be *extremely* surprised if that is really true.  Smalltalk
> implementations may well warn about occurrences that have overlapping
> scopes, but I can't imagine a Smalltalk compiler issuing a warning
> if a variable is declared once and then the code tries to use it
> for two different (and incompatible) purposes.

In other words, using the variable "anApple" as though it referenced
a Vehicle?  Well, it's true that the compiler won't flag such errors,
but the practice in Smalltalk is to use long and descriptive variable
names. As a result, such errors are not at all common. 

> [snip]
> 
> >> I doubt if there are any of these sort of errors.
> >> Mercury has a quite simple type system.
> >> For example, there is only one integer type in Mercury.
> >
> >How many Collection types?
> 
> ... used in the program in question?
> Four: list, set, map, and varset.
> 
> I don't think that

Hmmm... It would appear you didn't finish your thought.  I hate it when
that happens :-).

> >Are integers interchangeable with floats,
> >and complex numbers, and fractions, and...
> 
> No, but the program in question didn't use any floats,
> complex numbers, or fractions.

The point is the general principle of interchangeability due to a high degree
of polymorphism, not the particular types/classes used in any one program.

> >Except that my data show 2% or less as the rate of occurrence for "type"
> >errors **IN SMALLTALK**.
> 
> Since Smalltalk doesn't detect type errors automatically, then there
> may well be a significant number of type errors in your Smalltalk
> programs which you have not yet detected (but which your customers
> may find ;-).

Except that Smalltalk programs have been found to have less errors in production 
than is the case with the widely used competing languages.  Of course, that may 
or may not be true with respect to Mercury or functional languages in general.

> Also, it is possible that you may be misclassifying some errors as
> non-type errors even though they would have been caught by static type
> checking.

Well, the way that "static type checking" is really being used it would be 
better called constraint/assertion enforcement. It appears to be used to do 
other things than what can be strictly considered "type checking" (where the 
word "type" has its usual computer science meaning).  For example, it is used 
to prevent usage of variables before they have been initialized.  But that can 
be done in a dynamically typed language without using static **type** checking.  
It just requires the compiler to enforce the constraint that variables are 
assigned a value before they are used to reference any values. No "types" 
involved.

Similarly, it would be possible to have a dynamically typed language where
the variables had assignment constraints that had nothing to do with the
types of the values they can reference.  Permit me to give an example (using
a strange combination of Pascal and Smalltalk syntax, just for fun):

	VAR
		v1, v2: Group1;		{"Group1" and "Group2" are not types,
		v3, v4: Group2;		but rather "assignment compatibility groups"}
		
	BEGIN

		v1 := Apple new;	{Any type is allowed, we have dynamic typing}
		v3 := Vehicle new;

		v2 := v1; 		{Allowed because v1 and v2 have the same
					"assignment compatibility group"}
		v4 := v1;		{Error: assignment groups are different,
					so this causes an assignment constraint
					violation error at compile time}

Meditation on this example will illuminate the fundamental difference between
type-constraints bound to variables as opposed to the type of the value referenced 
by the variable.

Now, imagine that we use one such "assignment compatibility group" to represent
all those variables that should hold integer values in the range 13..24.  The
compiler won't guarantee that the variable won't hold a value not in the range,
but it will prevent the assignment of any value from some variable whose 
"assignment compatibility group" is not bound to the 13..24 assignment 
compatibility group. So the only assignments that the programmer would have to 
check would be those where the r-value was a literal--and the value of expressions, 
which have to be programmer-checked even in the case of classic static typing 
("a + b" may be outside the range, even though "a" and "b" are guaranteed to be in 
the range). So such a language would catch errors almost as well as one with classic 
"static typing," and yet no "types" are actually checked!!!

It is my contention that most of the value of "static typing" arises precisely from 
the usage of "type constraints" as what are essentially "assignment compatibility 
groups." Especially in a language such as Java (for example), where all variables 
are physically pointers (or size-compatible with pointers).

There are other ways to enforce useful invariants and constraints than using a type
system.  Smalltalk is very good at constructing such constraint-enforcement mechanisms
and abstractions.  Ever heard of ThingLab?

Such errors do not occur as often in idiomatic Smalltalk code as "static typists" 
seem to think.  There is more than one way to "skin a cat."  When you can't rely on 
"static typing," you compensate in other ways.

> If you have some detailed records for Smalltalk, then perhaps you
> could post them and we can give them the same sort of examination.

Perhaps I will.  But I don't have the time at present.  I really shouldn't be
spending the time to even make this post...

> >> >And how many were caused by the fact
> >> >that the Algol-style function call syntax makes it so easy
> >> >to get the arguments wrong?
> >>
> >> Again, probably none of them.
> >
> >Does Mercury use Algol-style function call syntax?  That is, "f(x, y, z, ...)"?
> 
> Yes.
> 
> >If so, the fact that Smalltalk will have fewer cases of "wrong argument" due
> >to its superior function call (message send) syntax is not a debatable point.
> >It's a fact.
> 
> Do you mean fewer cases getting past the compiler,
> or fewer cases at all?

Both.

> I think most of these cases were due to changes in one part of the
> source code not being reflected in other parts.  I don't think
> Smalltalk syntax is going to help in such cases.

True. But the hypertext-like nature of Smalltalk source code browsing is
absolutely essential in dealing with the problem you mention.  This is 
onle example of what I meant when I said "you compensate in other ways."

> >> Four were serious semantic errors (logic bugs); these are all too
> >> complicated to explain concisely, but I can't imagine any programming
> >> language feature that would avoid them.
> >
> >A larger library of reusable code (your own, or that of some third party)
> >might have left less chance for the introduction of bugs that is common
> >in de novo code.
> 
> The four bugs were all in very application-specific code that I can't
> imagine being in any library of reusable code.

Again, the point is not the details of any particular program, but what happens
in general.

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Alan Lovejoy]

Matt Kennel wrote:
> 
> Alan Lovejoy (alovejoy@concentric.net) wrote:
> 
> : And a strong case can be made that having the compiler check based on "types"
> : (actually type constraints/assertions) assigned to variables (not objects)
> : is a severe violation of the information hiding principle.  An object should
> : ideally be a black box that hides its implementation (class).  Exposing the
> : interface of the object is acceptable, even good.  But most statically-typed
> : OO languages go beyond that into exposing the implementation (class)--and then
> : hard coding it into type constraints on variables in the program source, which
> : is very, very bad.
> 
> 1) Why is this very very bad?  Why is it non-very bad?

Because it fails to separate interface from implementation.

> 2) The type constraints on variables do not necessarily prescribe any
>    particular concrete class, much less expose any internal class information
>    to extra manipulation.  What is the relation to "information hiding"?  The
>    inside-vs-outside encapsulation generated by Eiffel classes or Ada packages
>    or M3 modules has no relation to type constraints on variables, as far
>    as I can see.

I thought I made it clear that I was specifically deprecating those languages
that use **classes** as type constraints.  And I thought I made it clear that 
"Exposing the interface of the object is acceptable, even good."

And I agree that the way static typing is done in Ada, Modula-3 and Eiffel is
quite superior to what C++ does. But I would be even happier with the way Ada 
or Eiffel handle typing if one could simultaneously have two different variables 
whose static type constraint is "Dictionary" but where each is actually an instance 
of a different class (say HashTable and BinaryTree)--and the only class they both 
have in common in their inheritance hierarchy is Object.

> : Using the class as a substitute for the interface violates the information hiding
> : principle.  This was and is the issue.
> 
> 3) And suppose you actually want to specify a particular concrete class?
>    You have [to] "hard code" classes to create instances, after all.

	VAR

		dictionary1, dictionary2: Dictionary;

	BEGIN
	
		dictionary1 := new HashTable;
		dictionary2 := new BinaryTree;

Does that answer your questions?

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: OO, C++, and something much better!

[Eirik Mangseth]

Robert Dewar wrote:
> 
> Richard Kenner said
> 
> "I've heard nobody claim that *testing* is a bad idea.  The claim, with
> which I agree, is that *reliance* on testing is a bad idea.  There's a
> very large difference between those claims."
> 
> Nicely and clearly put! Really the problem is premature reliance on
> testing. A lot of programmers never even seem to read their code, except
> in the context of testing and debugging. This means of course that they
> read only the code that testing digs up problems with, and the code and
> logic paths that do not get fully tested (testing can almost never be
> 100% complete in real life programs, since the range of inputs is too
> large), are never read by anyone.

I believe E. Dijkstra put it quite nicely when he said:

"Testing can only show the presence of bugs, not prove their abscence"

A rather important statement to keep in mind, don't you think.

Eirik M.

/
 Eirik Mangseth		    United Consultants A/S, Norway Office
 ema@unitedconsultants.com  "Quality Software Through Quality People"
(TM)
 emangset@online.no
/

Re: OO, C++, and something much better!

[Richard Kenner]

In article <32F063B9.16C@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:
>Richard Kenner wrote:
>> I think you've given a bad example.  Off-by-one in a loop is often a
>> situation where it will either not work at all or work correctly.
>> It's also often the case that it'll take a good deal of time to be
>> confident in the analysis of which is right.
>
>You can't be serious. It is not black and white. In plenty of situations
>with C++ or C it might work for sometime, and then cause problems.

For the second time: I said "often", which does not at all contradict
with your statement that there are "plenty of situations" where this
is not the case.  When it isn't, of course, then there is indeed no
substitute for analysis.

I find it curious, though, that you mentioned languages explicitly.
Do you think that there's any difference between off-by-one problems
in C and Ada?

Re: OO, C++, and something much better!

[Nick Leaton]

Richard Kenner wrote:
> 
> In article <32F063B9.16C@calfp.co.uk> Nick Leaton <nickle@calfp.co.uk> writes:
> >Richard Kenner wrote:
> >> I think you've given a bad example.  Off-by-one in a loop is often a
> >> situation where it will either not work at all or work correctly.
> >> It's also often the case that it'll take a good deal of time to be
> >> confident in the analysis of which is right.
> >
> >You can't be serious. It is not black and white. In plenty of situations
> >with C++ or C it might work for sometime, and then cause problems.
> 
> For the second time: I said "often", which does not at all contradict
> with your statement that there are "plenty of situations" where this
> is not the case.  When it isn't, of course, then there is indeed no
> substitute for analysis.
> 
> I find it curious, though, that you mentioned languages explicitly.
> Do you think that there's any difference between off-by-one problems
> in C and Ada?

I quoted C / C++ deliberately. I don't know vast amounts about Ada. 
However in my experience this type of error is a problem with most C++/C
programmers, requiring the use of tools like Purify to handle. The 
worst bug I have ever had the misfortune to work with was a stack going
out of bounds in a threaded environment. For a combination of reasons
it took 3 man months to find and was very stressful, particularly as 
it was in the code I had written that it manifested itself. It was all
down to another piece of code setting a small default size for the 
threads stack. I have had similar problems with other systems in the
past. Currently using Eiffel, this hasn't even been an issue, just run
with all assertions on.

-- 

Nick

Re: OO, C++, and something much better!

[Robert Dewar]

Richard said

"> I think you've given a bad example.  Off-by-one in a loop is often a
> situation where it will either not work at all or work correctly.
> It's also often the case that it'll take a good deal of time to be
> confident in the analysis of which is right."


Hmmm! It is not often that I completely disagree with Richard, but this
is one such occasion :-)

If it takes a "good deal of time to be confident in the analysis of which
is right", then all the more reason to do that analysis. And I simply do
not believe that testing is guaranteed to find off-by-one errors -- that's
certainly not my experience!

Re: OO, C++, and something much better!

[David L. Shang]

In article <32F07705.289C@concentric.net> Alan Lovejoy  
<alovejoy@concentric.net> writes:
> 
> And I agree that the way static typing is done in Ada, Modula-3
> and Eiffel is quite superior to what C++ does. But I would be even
> happier with the way Ada or Eiffel handle typing if one could 
> simultaneously have two different variables whose static type
> constraint is "Dictionary" but where each is actually an instance 
> of a different class (say HashTable and BinaryTree)--and the only
> class they both have in common in their inheritance hierarchy is
> Object.
> 

The problem with the languges mentioned above is that the type
system supports only a one-way inheritance, and actually we
sometiimes need a reverse inheritance: from existing subclasses
to superclass.

Your "HashTable and BinaryTree" to "Dictionary" is a good example.

In Transframe, you can simply declare:

	class Dictionary is super HashTable, BinaryTree;

Then the class Dictionary (a superclass) inherits all the common
interfaces of HashTable and BinaryTree.

The superclass construct can do something more. For example,
a safe union type, a signature, etc. For detail, refer to
http://www.transframe.com/ at "Forum/SoftwarePatterns" page.

David Shang

Re: OO, C++, and something much better!

[Robert C. Martin]

In article <5cm364$dc2@topdog.cs.umbc.edu>, jur@topdog.cs.umbc.edu
(Jacqueline U. Robertson) wrote:

> Depends - are we including C and C++ here ?  In either language, I have
static 
> type checking, but I can use casting to defeat that type checking - thus,
> I get NONE of the benefits of static typing,

This is quite a stretch.  It is rather like saying: "I can do structured
programming in Smalltalk so I get NONE of the benefits of OO."

The fact that you *can* cast in C++ does not mean that everybody *does* cast
in C++; or that casting is a rampant and virulent disease that infects all
C++ programs to the extent that their type systems are reduced to utter chaos.
It just ain't so.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: OO, C++, and something much better!

[Tim Ottinger]

On Mon, 27 Jan 1997 10:35:11 -0800, Brian Rogoff <bpr@best.com> wrote:
>On Mon, 27 Jan 1997, Norman H. Cohen wrote:
>> Tansel Ersavas wrote:
>> 
>> > In Smalltalk, I am internally testing a tool that captures and embeds
>> > type checking automatically during development, and strips that
>> > information when you request.
>	A lot of really interesting work on this is being done in the
>Scheme community, under the name "soft typing". The basic idea is to use 
>ML style type inferencing on dynamic languages to statically determine
>types in most cases, or, when this fails, to insert run time checks or warn
>the programmer that there is a possible type error at that point in the
>software. 

...and at the same time, a lot of people have created imitations
of the smalltalk library for C++.

To me this doesn't prove anything so much as that no matter whether
you prefer static or dynamic types, you could use a little of the
other, too.

-------------------------------------------------------------
Tim Ottinger      | Object Mentor Inc. | OOA/D, C++, more.. 
tottinge@oma.com  | http://www.oma.com | Training/Consulting
-------------------------------------------------------------
"... remember, there are ways of succeeding that we would not
 personally have chosen. "              - Bjarne Stroustrup
-------------------------------------------------------------

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <5d93d3$nhs$1@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>ka@socrates.hr.lucent.com (Kenneth Almquist) writes:
>>Dynamic scoping is not a particularly good candidate for inclusion in
>>a language because the programmer can implement it by hand (at least in
>>C++ and Ada) and with good program design it should be rarely used.

But it is *always* used (in C++ and Ada) when you raise exceptions.
I admit that it is rarely needed in any other contexts.

>>...  The
>>same goes for nonlocal gotos; these can be simulated using Ada/C++ style
>>exceptions and with good program design they should be rarely used.

This seems like abstraction inversion, to me.  It makes more sense to me
to say that exceptions are implemented in terms of non-local gotos,
rather than the other way 'round.

I don't understand why gotos are considered evil, whereas exceptions are
OK.  Raising an exception has at least as bad an effect on readability
as a goto -- it's like a goto, but you can't tell (statically) where
it's going to.  Nonetheless, exceptions are a Good Thing (whether they
are done like Ada or like Piercarlo Grandi wants).

>Without wanting to argue either for or against dynamic scoping (some of
>my favourite languages have it and some haven't), the claim that "the
>programmer can implement it by hand" is true only in the sense that the
>programmer can implement most control structures using "if ... goto".
>You can in this sense implement almost _anything_ by hand, but you'd be
>mad to, and you wouldn't put up with a language designer using that
>excuse to omit while loops from the language.

Well, in Smalltalk, while loops are not exactly part of the core
language -- they're part of the predefined library.  And I think that's
a pretty elegant way to do it.

>In fact, the programmer can _not_ implement dynamic scoping easily by
>hand in Ada and thanks to the arcane scope rules of C++ (from time to
>time I reread the draft C++ standard trying to find out what the scope
>rules _are_, does _anyone_ know?) it is even less true there.
>
>There are a number of points about dynamic scoping:
>(a) it dilutes the "ownership" of a name.
>    For this reason I don't think it would be appropriate for Ada.
>(b) dynamically scoped variables are automatically unwound whenever
>    a contour rebinding them is exited for whatever reason.
>(c) binding and unbinding dynamically scoped variables is expected
>    to be CHEAP.
>Simulating dynamically scoped variables in Ada or C++ would seem to require
>- introducing a *visible* shadow variable to hold the outer value
>- setting up an exception handler to unwind and resignal
>- remembering to unwind at _every_ return point.
>This is a heavy burden on the programmer, worse in my view than having
>to use "if ... goto .." instead of "while".  It is also likely to be
>seriously less efficient than a reasonable mechanism implemented by the
>compiler.

The above can simulated in Ada using controlled types.  It's possible to
implement controlled types efficiently, but it's not easy in the general
case, and I don't know of any Ada compilers that do so.

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Patrick Doyle]

In article <01bc14ab$3ce476e0$752d54c7@vbykov.hip.cam.org>,
Vassili Bykov <vbykov@cam.org> wrote:
>
>Control constructs cannot *in principle* be a part of the standard library.
>(Unless you take Lisp or Scheme and consider macros as part of the
>library--which, strictly speaking, they are not).

  Why is that?

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "jmartin" == Jay Martin <jmartin@cs.ucla.edu> writes:

jmartin> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

piercarl> Well, yes and no. Not quite. It can be kludged, and I have
piercarl> provided one such kludge, but adding to a language is easy but
piercarl> non trivial. Since it is needed regardless of whether a
piercarl> language provides it or not, it's better to have it done
piercarl> cleanly and efficiently rather than as a kludge.

piercarl> This is actually a general principle of system/language
piercarl> design; there are a number of features which are essential,
piercarl> and cannot simply be omitted; omitting them from the
piercarl> primitives of the languages will simply mena that the
piercarl> implementation burden shifts on the programmer. My two
piercarl> favourite examples are spooling for operating systems and
piercarl> generators for programming languages. There are OSes that
piercarl> don't have spooling, and then it must be done by the user, by
piercarl> multitasking her/imself; there are languages that don't have
piercarl> generators, and then they must be simulated by the programmer,
piercarl> usually via global variables or ``control blocks''. In either
piercarl> case it is a waste. Dynamic scoping is another good example.

jmartin> It seems to me you are assuming that dynamic scoping is necessary and
jmartin> that a programmer will have to simulate it.  It seems more prudent to
jmartin> me to recognize the limitations and paradigm of your tool and just
jmartin> implement it in the tedious and boring "normal" way.

Ahhh, but what I have been arguing is merely the obvious: runtime
customization of imlementations is a fact of life, whether one like sit
or not, and dynamically scoped identifiers are the most
direct/obvious/``simplest'' way to do it, e.g. environment variables in
UNIX and similar facilities in most other systems/languages.

It is well true that once can always perform a reduction from a program
with statically or dynamically scoped global/fluid variables to one that
does not have them, only parameters and local variables (and the latter
can further be transformed into parameters):

jmartin> Which in this instance is by passing parameters

but this does not necessarily mean that it is desirable... In effect it
is not very desirable, as long as the global/fluid variables left in teh
program are clearly encapsulated.

jmartin> or having different functions.

This is in the general case unfeasible (there can be any number of
procedures that one would want to do)...

jmartin> [ ... strong preference for the bondage&discipline school of
jmartin> programmign language design :-) ... ]

jmartin> When you are in a room filled criminally insane programmers,
jmartin> straightjackets nstart sounding like a cool idea.

I must confess that this approach actually strikes a chord with me,
except that I'd rather have a BFG-9000 than a set of straitjackets :-).

But then on balance, emotions set aside, I tend to prefer tools that can
be used nicely by the non criminally insane (the merely insane probably)
programmers to do nifty things, than those designed for damage
limitation. Perhaps I am an incurable optimist.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Vassili Bykov]

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article
<5def36$rjd@mulga.cs.mu.OZ.AU>...
> "Vassili Bykov" <vbykov@cam.org> writes:
> > [...]
> >Control constructs cannot *in principle* be a part of the standard
library.
> 
> Sure they can.  Consider tcl, for example.

Oops, sorry I jumped it--in the post I replied to, Kenneth Almquist was
talking about Ada and C++ so I assumed "regular" languages with
applicative-order evaluation.  In these, they cannot because functions
always evaluate arguments.  For control constructs you would either need
lazy as in Haskell or syntactially transparent delayed as in Smalltalk
evaluation.  (Or... hmm... weird? as in Tcl. :-)

> >(Unless you take Lisp or Scheme and consider macros as part of the
> >library--which, strictly speaking, they are not).
> 
> Why aren't they?  What *in principle* reason is there why they can't be?

Because macros are AST (or token stream, in lesser languages)
transformation rules known to the compiler. Libraries are collections of
machine (or virtual machine) code blocks to be called by the application
program.  In other words, macros extend the compiler while library routines
extend the apllication program.  That's the "strictly speaking" reason I
meant.  

I didn't mean to be dense--I said that only because if we extend the
meaning of "standard library" to include standard macros always known to
the compiler then what is the difference between "part of the library" and
"part of the language"?

--Vassili

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Bill Gooch]

Vassili Bykov wrote:
> 
> ....
> I didn't mean to be dense--I said that only because if we extend the
> meaning of "standard library" to include standard macros always known to
> the compiler then what is the difference between "part of the library" and
> "part of the language"?

Why should there be such a difference in practice, 
regardless of the nature of the extension?

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Vassili Bykov]

Bill Gooch <bill@iconcomp.com> wrote:
> Vassili Bykov wrote:
> > I didn't mean to be dense--I said that only because if we extend the
> > meaning of "standard library" to include standard macros always known
to
> > the compiler then what is the difference between "part of the library"
and
> > "part of the language"?
> 
> Why should there be such a difference in practice, 
> regardless of the nature of the extension?

I don't say there should be.  I was referring to the part of the original
Fergus Henderson's <fjh@murlibobo.cs.mu.OZ.AU> message:

> Actually I'd be quite happy with a language in which while loops
> were part of the standard library, rather than part of the language.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <01bc14ab$3ce476e0$752d54c7@vbykov.hip.cam.org>,
Vassili Bykov <vbykov@cam.org> wrote:
>Control constructs cannot *in principle* be a part of the standard library.

Control constructs *are* part of the standard library in Smalltalk.  And
it's an elegant way to do things.  I'm not sure what you mean by "*in
principle*" in this case.

Probably (I suspect) the whileTrue:do: thing (or whatever it's called)
in Smalltalk is implemented as a "built in" thing in most
implementations, but that's not semantically necessary.  If Smalltalk
had a goto primitive, one could write the while loop primitive in
Smalltalk.  (Actually, I guess you can do it via recursion, if you're
willing to count on tail recursion elimination.)  In any case, the fact
that it's "built in" to the compiler does not imply that it's "built in"
to the semantics -- I mean, a C compiler is well within its rights to
"build in" the printf function (i.e. special case it in some way that
might get better efficiency).

>(Unless you take Lisp or Scheme and consider macros as part of the
>library--which, strictly speaking, they are not).

No, they're not macros, they're "normal" messages/methods (that is,
procedure calls), with "blocks" as parameters.  (I'm not sure why macros
are considered out of bounds here, but in any case, macros aren't needed
in this case.)

- Bob

Re: OO, C++, and something much better!

[Richard A. O'Keefe]

I wrote:
: The type system is not the only way in which Smalltalk differs from C.
: Another important way is the syntax of function calls.
: Smalltalk encourages the use of infix operators whenever it makes sense.

"John W. Sarkela" <jsarkela@enfish.com> writes:
>On the contrary, Smalltalk does not encourage the use of
>operators whatsoever. There are two and only two operators
>in Smalltalk.

I think any fair person would agree that calling "+" an operator is
not _wholly_ unreasonable, even in Smalltalk.  The _application_ of
"+" to arguments is a message send, but "message send" is no more and
no less than "dispatched procedure call".

Anyone saying that "+" is not an operator in Ada, for example, on the
flimsy grounds that "+" is actually an overloaded function, would not
be taken seriously.  (Except in APL) "operator" is a syntactic property,
not a semantic one.



-- 
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes.  --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Alan Lovejoy]

Richard A. O'Keefe wrote:
> 
> I wrote:
> : The type system is not the only way in which Smalltalk differs from C.
> : Another important way is the syntax of function calls.
> : Smalltalk encourages the use of infix operators whenever it makes sense.
> 
> "John W. Sarkela" <jsarkela@enfish.com> writes:
> >On the contrary, Smalltalk does not encourage the use of
> >operators whatsoever. There are two and only two operators
> >in Smalltalk.
> 
> I think any fair person would agree that calling "+" an operator is
> not _wholly_ unreasonable, even in Smalltalk.  The _application_ of
> "+" to arguments is a message send, but "message send" is no more and
> no less than "dispatched procedure call".
> 
> Anyone saying that "+" is not an operator in Ada, for example, on the
> flimsy grounds that "+" is actually an overloaded function, would not
> be taken seriously.  (Except in APL) "operator" is a syntactic property,
> not a semantic one.

An "operator" is a "built in" function whose semantics is defined by the
grammar of the language.  The "name" of an operator is usually either
reserved, or else would not be a syntactically valid programmer-defined 
function identifier.

In languages that permit "operator overloading," there will be syntactic
(and usually semantic) constraints on the definition of an "operator" 
that would not apply to other functions.  For example, the name of an
operator would have to be the same as one of the "built in" operators.
A programmer-defined operator named "=" would probably be constrained to 
have a Boolean return type, and to have only two arguments.  The "+"
operator
would be constrained to have only two arguments, and would have a
predefined 
and unchangeable evaluation order precedence.

The reason that "+" would be considered an operator in languages that
have
"operator overloading" is because the semantics of "+" is (partially)
defined
by the syntax of the language.  One does not need to define the meaning
of
"+" in Ada (as a function with source code) in order to use it for
integer 
addition.  In Smalltalk, "+" has no formal meaning **syntactically**
other than 
"a message whose selector is +".  There is a method (with editable
source code)
that defines the meaning of "+" for Integers (actually, there are three,
one 
for SmallIntegers, one for LargeIntegers, and an abstract one for
Integers that 
aren't Small or Large (any such would have to be defined by the
programmer).

However, most Smalltalk implementations optimize the "+" message.  If
this
message is sent to a SmallInteger, the runtime system (usually a VM, but
not always) does integer addition directly without actually doing a
dynamic
method dispatch.  So one can simply remove the "+" method from
SmallInteger,
and nothing will break!

So "+" is not formally an operator, but may be one in practice (in most
implementations).  But if it is an operator, it's not because it has the
name "+", but because its meaning (in at least one case) is not defined
by 
a construct (such as a method) expressed "in the language."

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Jay Martin]

pcg@aber.ac.uk (Piercarlo Grandi) writes:

>>>> "jmartin" == Jay Martin <jmartin@cs.ucla.edu> writes:

>Ahhh, but what I have been arguing is merely the obvious: runtime
>customization of imlementations is a fact of life, whether one like sit
>or not, and dynamically scoped identifiers are the most
>direct/obvious/``simplest'' way to do it, e.g. environment variables in
>UNIX and similar facilities in most other systems/languages.

Yeah but sometimes you have to go that extra mile for good software.

>jmartin> Which in this instance is by passing parameters

>but this does not necessarily mean that it is desirable... In effect it
>is not very desirable, as long as the global/fluid variables left in teh
>program are clearly encapsulated.

I basically always pass data and almost never use variables from a
larger scope (globals). Doesn't seem much of burden to me. Explicit
data flow seems clearer and to not do so is conceptually using
"side-effects".  Ick!

>jmartin> or having different functions.

>This is in the general case unfeasible (there can be any number of
>procedures that one would want to do)...

But in specific cases it works fine.  Generality can have many downsides.
  

Jay

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Fergus Henderson]

"Vassili Bykov" <vbykov@cam.org> writes:

>I didn't mean to be dense--I said that only because if we extend the
>meaning of "standard library" to include standard macros always known to
>the compiler then what is the difference between "part of the library" and
>"part of the language"?

The difference is that things that are part of the library are things
that a user can program user-defined alternatives.  For example,
in C, printf() is part of the standard library, and you can write a
my_printf() function that does similar things to printf() (and
is perhaps implemented as a layer on top of printf()).  On the
other hand, it's not possible to do the equivalent for Pascal's
write statement or for C's for loops, because these are part of
the language proper, not the standard library.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "fjh" == Fergus Henderson <fjh@murlibobo.cs.mu.OZ.AU> writes:

[ ... ]

fjh> The difference is that things that are part of the library are things
fjh> that a user can program user-defined alternatives.  For example,
fjh> in C, printf() is part of the standard library, and you can write a
fjh> my_printf() function that does similar things to printf() (and
fjh> is perhaps implemented as a layer on top of printf()).  On the
fjh> other hand, it's not possible to do the equivalent for Pascal's
fjh> write statement or for C's for loops, because these are part of
fjh> the language proper, not the standard library.

Well, even if 'printf' were syntactically a statement and not a
procedure call, you could still write your 'my_printf' as a procedure;
similarly that 'if then else' is not a procedure call in ``Pascal'' does
not forbid you from writing a procedure like
'myif(condition,thenPart,elsePart)'.

The real reason why/why not is rather different from being alanguage
primitive or not; it is whether one has the reflective abilities to
implement one's own verion of 'printf' or 'myif'.

In ``C'' one has the reflective facilities for writing one's own
'printf' (such facilities are '#include <stdarg>', which allow a
procedure to ``reflect'' on its parameter list), but not for writing
control structures (except for some very limited ability using
preprocessor macros). Pascal does not offer reflective
abilities/primitives for parameter lists or control structures.

There are languages that offer user-visible primitives that allow
building ad-hoc control structures, by way of ``reflection''; usually
such facilities, as a bit of overkill, are based on that extremely
powerful reflective ability, the one to reflect on program state via
continuations/closures, and the associated one, the ability to reflect
on program fragments; for example Scheme and Smalltalk-80 allow
definitions of control structures using either/both reflection on
continuation/closures and code fragments. Neither are avalable in ``C''
or ``Pascal'', and thus control abstraction is not possible; the issue
is not thus quite related to having some reserved syntax or not.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "fjh" == Fergus Henderson <fjh@murlibobo.cs.mu.OZ.AU> writes:

[ ... ]

fjh> The difference is that things that are part of the library are things
fjh> that a user can program user-defined alternatives.  For example,
fjh> in C, printf() is part of the standard library, and you can write a
fjh> my_printf() function that does similar things to printf() (and
fjh> is perhaps implemented as a layer on top of printf()).  On the
fjh> other hand, it's not possible to do the equivalent for Pascal's
fjh> write statement or for C's for loops, because these are part of
fjh> the language proper, not the standard library.

Well, even if 'printf' were syntactically a statement and not a
procedure call, you could still write your 'my_printf' as a procedure;
similarly that 'if then else' is not a procedure call in ``Pascal'' does
not forbid you from writing a procedure like
'myif(condition,thenPart,elsePart)'.

The real reason why/why not is rather different from being alanguage
primitive or not; it is whether one has the reflective abilities to
implement one's own verion of 'printf' or 'myif'.

In ``C'' one has the reflective facilities for writing one's own
'printf' (such facilities are '#include <stdarg>', which allow a
procedure to ``reflect'' on its parameter list), but not for writing
control structures (except for some very limited ability using
preprocessor macros). Pascal does not offer reflective
abilities/primitives for parameter lists or control structures.

There are languages that offer user-visible primitives that allow
building ad-hoc control structures, by way of reflection; usually such
facilities, as a bit of overkill, are based on that extremely powerful
reflective ability, the one to reflect on program state via
continuations/closures, and the associated one, the ability to reflect
on program fragments; for example Scheme and Smalltalk-80 allow
definitions of control structures using either/both reflection on
continuation/closures and code fragments. Neither are avalable in ``C''
or ``Pascal'', and thus control abstraction is not possible.

Re: OO, C++, and something much better!

[Robin Rosenberg]

tkc@bmi.net (Travis Griggs) writes:
> 
> Of course, the developer opened his debugger, found the offending
> message send, fixed the method, and restarted, right? Meanwhile, the
> statically typed developer still didn't have the feature. :)

In SparcWorks/C++ you can inspect the problem in the debugger, edit the
offending code and resume execution at some appropriate point int the
program. So this can be done in a statically typed/compiled language.

-- 
Robin Rosenberg,  | Voice: +46-8-7036200 | "Any opinions are my own, etc. etc."
Enator Objective  | Fax:  (+46-8-7036283)|      <this line left blank>
Management AB     | Mail:  rrg@funsys.se | 

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Fergus Henderson]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

>I wrote:
>>>In fact, the programmer can _not_ implement dynamic scoping easily by
>>>hand in Ada and thanks to the arcane scope rules of C++ (from time to
>>>time I reread the draft C++ standard trying to find out what the scope
>>>rules _are_, does _anyone_ know?) it is even less true there.
>
>fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) replied fliply:
>>To answer your parenthetical question, the scope rules are defined in
>>sections 3.3 [basic.scope] and 3.4 [basic.lookup] of the draft.
>
>Get real!

OK, that _was_ a bit flip.  You're right that the scope rules of C++
can be rather arcane.

>fjh proposes the following sketch of implementing a dynamically
>scoped variable in C++:
>
>>	#include "dynamic_scope.h"
>>	
>>	dynamically_scoped<int> x;
>
>>	void foo() {
>>		rebind<x> local_x;	// or something like that
>>	}
>
>Close, but not quite.  (This approach is also applicable in Ada 95.)
>
>What's wrong with it?  x has the wrong type.

You can give `x' an implicit conversion to type "reference to int".

	operator int & ();

Now, due to C++'s arcane overloading rules ;-), this is not
exactly the same in all circumstances, but it usually does
the trick.  Sometimes you may have to insert a few additional
explicit conversions.

(My compiler seems to think that you need an assignment operator
as well.  Maybe it's right.)

>In languages that have them, dynamically scoped variables follow different
>_scope_ rules from other variables, but there is nothing special about
>their _contents_.  It would be necessary to do something like
>
>	int x;
>
>	void foo() {
>	    rebind< &x > preserved_x;
>	    ...
>	}

You could do that too, and it would work fine in the case of `int'.
However, for other types that has some disadvantages.
It won't work if type of `x' doesn't allow copying.
Even if `x' can be copied, you will most likely have to do a deep copy,
which may be slow.  That's why I went for the approach with
the implicit conversion-to-reference instead.

>An "implementation" of
>dynamically scoped variables which depends on giving them the wrong
>type (your approach) _does_ impose a heavy burden on the programmer,
>because then every reference that would have been a reference to x
>has to become x.contents() or whatever you want to call it.

No, that's not correct, because you can use an implicit conversion.

>>>It is also likely to be
>>>seriously less efficient than a reasonable mechanism implemented by the
>>>compiler.
>
>>I'm not convinced.
>
>Why not.  Do you actually know any C++ compilers which make your approach
>run as fast as a good Lisp system (Harlequin, Franz, CMUCL)?  The obvious
>mechanism is essentially a Prolog-style trail.

Well, with the implementation I was thinking of, block entry and block
exit are likely to quite cheap.  The main cost of my C++ implementation
is that you have an extra indirection for each access to the variable.
But I think it will be at least competitive.

	template <class T> class dynamically_scoped;

	template <class T, dynamically_scoped<T> & ds_var> class rebind;

	template <class T>
	class dynamically_scoped {
		template <dynamically_scoped<T> & ds_var>
		friend class rebind<T, ds_var>;
		T* current_var;
		T original_var;
	public:
		dynamically_scoped() {
			current_var = &original_var;
		}
		dynamically_scoped<T>& operator = (const T &val) {
			*current_var = val;
			return *this;
		}
		operator T& () {
			return *current_var;
		}
	};

	template <class T, dynamically_scoped<T> & ds_var>
	class rebind {
		T new_var;
		T* prev_var;
	public:
		rebind() {
			prev_var = ds_var.current_var;
			ds_var.current_var = &new_var;
		}
		~rebind() {
			ds_var.current_var = prev_var;
		}
	private:
		// prevent copying
		rebind(const rebind<T, ds_var>&);
		void operator =(const rebind<T, ds_var>&);
	};

If you're willing to assume that the variable can be cheaply copied,
you can do better.  Here's an alternate implementation that has
performance characteristics that are more similar to your suggested
implementation:

	template <class T> class dynamically_scoped;

	template <class T, dynamically_scoped<T> & ds_var> class rebind;

	template <class T>
	class dynamically_scoped {
		template <dynamically_scoped<T> & ds_var>
		friend class rebind<T, ds_var>;

		T current_value;
	public:
		dynamically_scoped<T>& operator = (const T & x) {
			current_value = x;
			return *this;
		}
		operator T& () {
			return current_value;
		}
	};

	template <class T, dynamically_scoped<T> & ds_var>
	class rebind {
		T old_value;
	public:
		rebind() {
			old_value = ds_var.current_value;
		}
		~rebind() {
			ds_var.current_value = old_value;
		}
	private:
		// prevent copying
		rebind(const rebind<T, ds_var>&);
		void operator =(const rebind<T, ds_var>&);
	};

>Block entry:
>	for each dynamic variable x
>	    push contents of x onto Trail
>	push block descriptor onto Trail
>
>Block exit:
>	discard block descriptor from Trail
>	for each dynamic variable x in reverse order
>	    pop contents of x from Trail

With the second implementation above, block entry and exit are
in fact slightly cheaper:

  Block entry:
	for each dynamic variable x
	   copy (not push) contents of x onto stack

  Block exit:
	for each dynamic variable x
	   copy (not push) contents of x from stack

I tried a simple test of dynamically_scoped<int>.  My compiler (SGI
C++) generated one instruction to put the address of x in a register,
and then a load/store pair for block entry and a load/store pair for
block exit.

By storing the trail on the stack, you save having to increment the
trail pointer (the stack pointer increment is usually free, since you
normally have to increment it anyway).  You also reduce the danger
of cache collisions, although that's probably not a noticable effect.
Furthermore, unlike say Prolog, you pay the cost of trailing and
untrailing only when you're actually using it (you don't have
any untrail loops).  The downside is that you can't get tail recursion
optimization.

Most modern Unix C++ implementations use separate code address tables for
exception handling, so there's no need to push any descriptors.
(PC implementations are another matter, though -- they do normally
push and pop stuff.  I think that's mostly Microsoft's fault.)

>There are three things to be said about this:
>
>(1) it is hard to see how to do _substantially_ better than this.

Yes, but as shown above you can do slightly better, and in any case all
you really need is to not do substantially worse.

>(2) the exception unwinder uses block descriptors, it is hard to
>    see how such a _global_ mechanism can be efficiently simulated
>    by _local_ classes.

Well, the local C++ classes are making use of the underlying C++
exception handling mechanism, which could use a global block descriptor
stack or separate code address tables or some other global mechanism.

>(3) Lisp systems enforce certain _global_ restrictions on the use
>    of dynamic binding.  fjh's mechanism can simulate to some degree
>    what Lisp _allows_ but not what it _forbids_.

Could you be more specific about the restrictions that Lisp systems
enforce?

You can enforce quite a bit in C++.

>None of this should be taken as endorsing the addition of dynamic binding
>to any specific language.

Yes, and the fact that you *can* implement dynamically scoped variables
in C++ does not mean that you necessarily *should* ;-)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Charles A. Jolley]

> Well, who am I to judge.. but in my view C++ is basically C with the 
> capability to add functions to structs. Before I tried C++, I would
> bundle pointers to functions in my C-structs to fake some kind of
> OO-like bundling of similar functions ;)   C++ take this a major
> step further by actually bundling data and functions together
> in a struct. But that is what classes are in C++: just enhanced
> structs!

C++ actually does not bundle code with the structs. If a member function
is not virtual, the compiler will just binds a obj.foo() reference to its
obj::foo() counterpart.  On the other hand, if a member function is
virtual, then function pointers, like you mentioned above, are used. 
Anyway, just a minor detail; they're still just glorified structs. ;)

-Charles

-Charles Jolley
cjolley@oz.sunflower.org
-------------------------------
       HACS Design Group
 "...there is a better way..."
-------------------------------

Re: What is wrong with OO ?

[richard]

In <01bc0269$3fd55b20$ca61e426@DCorbit.solutionsiq.com>, "Dann Corbit" <dcorbit@solutionsiq.com> writes:

>I remember hearing similar arguments about PL/1 many years ago.  The line
>of reasoning went something like this, "It is such a complex language, that
>the average programmer can never become proficient in it."  This is, of
>course, pure bologna.  With an advanced language you can be proficient
>right away.  You don't **have** to use the advanced features.  Start with
>the simple things and work forward.  Classes, for instance, are simple. 
>There are some advanced features of classes like whether a member should be
>virtual or pure virtual to create an abstract class.  But you don't need to
>know that to learn the language and actively use it as a productive tool.

I doubt that a lot of people know everything about C++, even when they
have been using it for years. Most programmers don't use a lot of 
features of a language simply because they don't *need* them. What
is interesting for one leaves someone else totally cold.

>And as to why virtual/non-virtual (IMO):
>Something that is virtual can be replaced and/or shared.  If you need these
>capabilities, then make it virtual.  A pure virtual member will cause a
>class to be abstract.  This is valuable if you have a class that is really
>not able to exist as a useful entity until it has been specialized by a
>class that inherits from it (in other words, you don't want to create a
>stand-alone instance of the abstract class).
>

Virtual functions are also a kind of documentation. When declaring a 
function virtual, the programmer is more or less saying "go ahead,
override this function if you like."

Greetz,

RS

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Vassili Bykov]

Robert A Duff <bobduff@world.std.com> wrote in article
<E59AsK.5LC@world.std.com>...
> Control constructs *are* part of the standard library in Smalltalk.  And
> it's an elegant way to do things.  I'm not sure what you mean by "*in
> principle*" in this case.
> >(Unless you take Lisp or Scheme and consider macros as part of the
> >library--which, strictly speaking, they are not).
> No, they're not macros, they're "normal" messages/methods (that is,
> procedure calls), with "blocks" as parameters.  (I'm not sure why macros
> are considered out of bounds here, but in any case, macros aren't needed
> in this case.)

Sorry, but the post I replied to discussed Ada and C. Your Smalltalk points
are correct but Smalltalk is unique (again :-).  Unlike most other
"mainstream" languages it provides delayed evaluation ("blocks")--something
without which you *cannot* build control constructs for languages with
applicative-order evaluation, while unlike Scheme and CL's closures the
syntax of blocks is extremely brief. This is why you can build control
constructs as functions without the need for syntactic sugar for usability.

If you disagree with the first statement, try to write "while as a
function" in C or similar language. If you disagree with the second,
imagine a bare-bones Scheme-like system with only "lambda", "define" and
"if": it is *all* you need to have any control construct and write any
program, but it will be unreadable without syntactic abstraction a macro
system gives. (Macros are out of bounds because they extend the compiler,
not the program.)

--Vassili

Re: What is wrong with OO ?

[richard]

In <E3uK9F.CzG@research.att.com>, bs@research.att.com (Bjarne Stroustrup) writes:

>
>Why is any of this relevant now? Why do I bother with this debate on
>"innovation?" Because some of what is said related directly to what C++
>is and should be, and that again affects where it is reasonable to use
>it and how it is best used. If you misunderstand some of the fundamentals
>of a language, the code you write in it is going to be suboptimal in several
>ways.
>	

Well, who am I to judge.. but in my view C++ is basically C with the 
capability to add functions to structs. Before I tried C++, I would
bundle pointers to functions in my C-structs to fake some kind of
OO-like bundling of similar functions ;)   C++ take this a major
step further by actually bundling data and functions together
in a struct. But that is what classes are in C++: just enhanced
structs!

I find that many of the OO-capabilities of C++ are just "crammed in"
to overcome the static nature of the language. C++ is by far not 
elegant in this respect. I get the idea that a lot of features 
have been braught in on the fly ("hey, multiple inhertiance
would be neat. And while we're at it, let's try templates too").

That C++ still works as a OO-language is mostly due to the strengths of
the language C itself... it appears to still work even under the
weirdest circumstances. In that respect Stroustup made an excellent
chouce by using C as a base ;)

Greetz,

RS

Re: What is wrong with OO ?

[Nick Leaton]

richard@highrise.nl wrote:
> 
> Virtual functions are also a kind of documentation. When declaring a
> function virtual, the programmer is more or less saying "go ahead,
> override this function if you like."
> 

The decision to make a function virtual assumes a knowledge of what
users of your class are going to do. It akin to predicting the future.
One of the problems with C++ is this very point. Should you, as a
designer of a class restrict what someone else does with your class?
If you provide the class to someone else without source code, and they
find a bug. One solution to fixing the bug is to produce a new class
that inherits the original, and redefines the offending routine. However
your decision about declaring or not declaring the routine virtual in
the first place affects what can be done.

-- 

Nick

Re: What is wrong with OO ?

[Robert Dewar]

RS says

<<I doubt that a lot of people know everything about C++, even when they
have been using it for years. Most programmers don't use a lot of
features of a language simply because they don't *need* them. What
is interesting for one leaves someone else totally cold.>>

Indeed, and in practice it seems that a lot of "C++" programmers know
little more than the C subset with a very minimum of additional features.
However, I think this is probably best ascribed to ignorance rather than
careful consideration of what people find interesting!

Re: What is wrong with OO ?

[Vlastimil Adamovsky]

richard@highrise.nl wrote:

>................................. but in my view C++ is basically C with the 
>capability to add functions to structs. Before I tried C++, I would
>bundle pointers to functions in my C-structs to fake some kind of
>OO-like bundling of similar functions ;)   C++ take this a major
>step further by actually bundling data and functions together
>in a struct. But that is what classes are in C++: just enhanced
>structs!

Whow! Then you really don't need C++. Use C instead. 
There is nothing keeping you from using member functions in C structures.
It is completely legal.

>I find that many of the OO-capabilities of C++ are just "crammed in"
>to overcome the static nature of the language. C++ is by far not 
>elegant in this respect. I get the idea that a lot of features 
>have been braught in on the fly ("hey, multiple inhertiance
>would be neat. And while we're at it, let's try templates too").

Multiple inheritance is great. Templates are very useful in generic programming.

>That C++ still works as a OO-language is mostly due to the strengths of
>the language C itself... it appears to still work even under the
>weirdest circumstances. In that respect Stroustup made an excellent
>chouce by using C as a base ;)

It was a smart choice.











 Vlastimil Adamovsky
 ** C++ and Smalltalk consultant **
 * http://www.stepweb.com *

Re: Worse is better, was: Language marketing question

[Bob Haugen]

Piercarlo Grandi wrote:

> Richard Gabriel has written a classic "Worse is Better" paper on all
> this, which discusses some of the issues (even if I really disagree with
> some of the analysis and most importantly with the recommendations).

I recently read and am currently thinking about that same paper, and 
so would be interested in your disagreements.

Bob Haugen
Nexgen Software

Re: Worse is better, was: Language marketing question

[Donald M. MacQueen]

Bob Haugen wrote:
> 
> Piercarlo Grandi wrote:
> 
> > Richard Gabriel has written a classic "Worse is Better" paper on all
> > this, which discusses some of the issues (even if I really disagree with
> > some of the analysis and most importantly with the recommendations).
> 
> I recently read and am currently thinking about that same paper, and
> so would be interested in your disagreements.
> 
> Bob Haugen
> Nexgen Software




Is this paper available on the Web?

I'd like to read it too.

Thanks in advance.



Donald

Re: What is wrong with OO ?

[Robert Dewar]

Charles said

<<C++ actually does not bundle code with the structs. If a member function
is not virtual, the compiler will just binds a obj.foo() reference to its
obj::foo() counterpart.  On the other hand, if a member function is
virtual, then function pointers, like you mentioned above, are used.
Anyway, just a minor detail; they're still just glorified structs. ;)>>

YOu should better say "typical C++ implementations" rather than C++, I see
nothing in the draft standard that would support your claim that this is
implied by the language definition.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Vassili Bykov]

Fergus Henderson <fjh@murlibobo.cs.mu.OZ.AU> wrote:
> ...   On the
> other hand, it's not possible to do the equivalent for Pascal's
> write statement or for C's for loops, because these are part of
> the language proper, not the standard library.

Of course it's not possible.  So we came to what it started with: it is in
principle impossible to have, for example, "for" loop in the standard
library instead of the language proper in a C/Pascal/Ada/Java-like language
even if it were up to us to move it there, because these languages lack the
necessary expressive facilities.  It is possible in Smalltalk, CL, or
Scheme--even Tcl weird as it is.
[But I'm not going into a second round on that, SICP explains it all]

Re: Worse is better, was: Language marketing question

[Lee Willis]

Donald M. MacQueen wrote:
> Bob Haugen wrote:
> > Piercarlo Grandi wrote:
> > > Richard Gabriel has written a classic "Worse is Better" paper on all
> > > this, which discusses some of the issues (even if I really disagree with
> > > some of the analysis and most importantly with the recommendations).

> Is this paper available on the Web?

http://rembrandt.erols.com/mon/SoftwareEngineering/WorseIsBetter.html

-- 
Lee Willis	MultiGen Inc. 550 S Winchester Blvd. Suite 500
		San Jose, CA 95128 		(408) 261-4100
"Sure, everyone knows [software] reusability is wonderful for the 
consumer side of the reuse transaction.  But what makes it wonderful 
for the producers?"  -- Brad Cox, _Superdistribution_

Re: C++ Class

[William Ying]

Loc Minh Phan Van wrote:
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.

Two solutions:
1)	Make the base class as Abstract Base Class (or Absolute Base Class in
some books) by setting a virtual function to be zero.  It is well
documented in any C++ books.
2)	Put the base class constructors in protected field.

- Bill -

Re: C++ Class

[Aaron J Margosis]

Make it an abstract class, using pure virtual functions.


Loc Minh Phan Van wrote:
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.

-- Aaron

---------------------------------
Aaron J Margosis
Work e-mail:  margosis@lccinc.com
Work phone:  703-516-6727
Personal:  Aaron_Margosis@compuserve.com

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "jsarkela" == John W Sarkela <jsarkela@enfish.com> writes:

[ ... much omitted ... ]

jsarkela> My experience suggests that my designs have higher degrees of
jsarkela> reusability if I do indeed consider that objects may express
jsarkela> free will. You may consider this fuzzy thinking, yet I tend to
jsarkela> create more concise collaborations with better factoring of
jsarkela> responsibility if I do think of my objects as expressing an
jsarkela> individual will and as a locus of responsibility.

Well, ain't you lucky? :-)

[ ... much omitted ... ]

Re: C++ Class

[Ron Smith]

Please watch your crossposting.  I don't know why this is in any of the
newsgroups except comp.lang.c++.

I didn't bring my asbesteos underwear so please don't flame me for
pointing this out.

Loc Minh Phan Van wrote:
> 
> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

Re: C++ Class

[John Kapson [C]]

In article <33018394.1718@scf.usc.edu>, Loc Minh Phan Van <locphan@scf.usc.edu> writes:
> Hi,
> 	Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class. 
> 
> 	If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

Shame, shame, shame.  If you want me to do your homework,
you'll have to pay my hourly rate.  8-)

John

Re: C++ Class

[Vlastimil Adamovsky]

Keith P. Boruff wrote:
> 
> Loc Minh Phan Van wrote:
> >
> > Hi,
> >         Is there anyway that we can Define a class that can not be instantiated
> > in any way by the user (that is, you can not have objects of that type),
> > but it can be used as a base class.
> >
> 
> Read about polymorphism and virtual functions.
> 

Read about "Abstract classes" and pure virtual functions.

Vlastimil Adamovsky


       The contents of this message express only the sender's opinion.
       This message does not necessarily reflect the policy or views of
       my employer, Merck & Co., Inc.  All responsibility for the statements
       made in this Usenet posting resides solely and completely with the
       sender.

Re: C++ Class

[Jason Shankel]

Loc Minh Phan Van wrote:
> 
> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

In C++, you're talking about an abstract base class.
An abstract class in C++ is a class which has at least one
pure virtual function, which must be overridden by a child class.
Pure virtual functions are designated by the "=0" idiom.
Abstract base classes cannot be instantiated:


class IFoo
{
	public:
		virtual void Method() = 0; //Pure virtual function
};

class CFoo : public IFoo
{
	public:
		virtual void Method(){}; //Overridden
};

void main()
{
	IFoo *object;

	object = new IFoo(); //ERROR, cannot instantiate abstract class
	object = new CFoo(); //Legal
};

C++ Class

[Loc Minh Phan Van]

Hi,
	Is there anyway that we can Define a class that can not be instantiated
in any way by the user (that is, you can not have objects of that type),
but it can be used as a base class. 

	If so please give me a little example.

Thanks

Fr, Loc Phan

Re: C++ Class

[Keith P. Boruff]

Loc Minh Phan Van wrote:
> 
> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

Read about polymorphism and virtual functions. 
 
--------------------------------------------------------
Keith P. Boruff			Email:
West Babylon			kboruff@village.ios.com
Long Island, NY			boruffk@sunysuffolk.edu

Re: C++ Class

[Kevin J. Hopps]

Loc Minh Phan Van wrote:
> 
> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

If a class has a "pure virtual function" it cannot be instantiated
directly, but only as a base class of a derivative that implements the
function.  For example:

class Cloneable
{
public:
	virtual Cloneable* clone() = 0;
};

class Thing : public Cloneable
{
public:
	virtual Thing* clone();
};

int main()
{
	Cloneable c;	// error
	Thing t;	// ok
	return 0;
}
-- 
Kevin J. Hopps, Imation          kjhopps@imation.com

My opinions are my own.  I speak neither for Imation nor 3M.



Opinions expressed herein are my own and may not represent those of my employer.

Re: C++ Class

[Kent Tong]

Loc Minh Phan Van <locphan@scf.usc.edu> wrote:

>Hi,
>	Is there anyway that we can Define a class that can not be instantiated
>in any way by the user (that is, you can not have objects of that type),
>but it can be used as a base class. 
>
>	If so please give me a little example.

deferred class Foo
feature
   IWillNeverCrossPostAgain 
   is 
      deferred 
   end;   


---
Kent Tong
v3 is out!!!
Freeman Installer ==> http://www.netnet.net/users/freeman/

Re: C++ Class

[Paul Kenneth Egell-Johnsen]

Loc Minh Phan Van wrote:

> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.

That would be an abstract base class, with pure virtual members.

class base
{
	virtual method() = 0; // this is not defined in the base,
                              // derived objects must define this.
                              // Don't think a user can instanciate
                              // this, take a look in the faq.
}

Paul K Egell-Johnsen

mailto:paulken4@afrodite.hibu.no
http://afrodite.hibu.no:8001/paulken4/

Re: OO, C++, and something much better!

[Piercarlo Grandi]

>>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:

alovejoy> Richard A. O'Keefe wrote:

Richard> [ ... ] I think any fair person would agree that calling "+" an
Richard> operator is not _wholly_ unreasonable, even in Smalltalk.  The
Richard> _application_ of "+" to arguments is a message send, but
Richard> "message send" is no more and no less than "dispatched
Richard> procedure call".

Richard> Anyone saying that "+" is not an operator in Ada, for example,
Richard> on the flimsy grounds that "+" is actually an overloaded
Richard> function, would not be taken seriously.  (Except in APL)
Richard> "operator" is a syntactic property, not a semantic one. [ ... ]

Quite so, but then:

alovejoy> An "operator" is a "built in" function whose semantics is
alovejoy> defined by the grammar of the language.

The _semantics_ are defined by the grammar????
An operator like "+" is a _function_????

"+" is a symbol, a lexical entity; it will usually represent the plus
operator, which is a syntactic entity, the name of an interface; such
interface may well be that for one or more builtin procedures, which are
the semantic entities.

So we have that the representation of the plus operator is defined by
the lexicon of the language, and is usually the "+" character; the plus
operator has a usually definite role in syntax, and may or may not be,
and usually is, the interface to several different _operations_ that
have different semantics, which operations and their semantics are not
defined by the grammar (unless one uses 2-level grammars as described by
Uzgalis et al., but this is a really obscure if fascinating point that I
guess was not meant by anybody in this thread).

Some OO languages allow all three of affix, infix and prefix syntaxes
for the plus operator, for example ``C++'', and affix syntax can only be
used for ``member functions'', and infix only for non member (non
builtin?) functions, as in:

  class Int { int i; public: Int operator +(Int,Int); .... };

  int i(1); // In recent ``C++'' versions, BS has reintroduced the "thin
	    // ice" ambiguity
  int j(2);

  // These are legal
  (void) i + i;			// infix
  (void) j + j;			// infix
  (void) j.operator +(j);	// affix

  // These _ought_ to be legal, and some may well be in some version of
  // ``C++'' out there.
  (void) operator +(i,i);	// prefix
  (void) i.operator+(i);	// affix
  (void) operator+(j,j);	// prefix

In Smalltalk-80, unconventionally, there are no reserved operator
symbols; but all symbols that are formed out of a certain set of special
characters can/must be used in an affix role that _looks_ like (because
of the absence of ':') infix notation, and might even be regarded as
infix.

What is builtin in Smalltalk-80 is not operator symbols (the ``message
selector'') but the primitive bytecodes to which they resolve (the
``method''), which is an operation, not an operator.

And so on...

Re: OO, C++, and something much better!

[Ulf Schuenemann]

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



In article <E4voIF.86o@world.std.com>, bobduff@world.std.com (Robert A Duff) writes:
...
|> I've often thought that it would be an improvement to Ada, if the
|> programmer of the function declaration decides whether named or
|> positional notation should be used, for each parameter.  Instead, Ada
|> allows a little bit too much flexibility, for my taste: The programmer
|> of each call gets to decide.  Also, you can write the parameters in any
|> order, if they're named, which you can't do in Smalltalk.

A technical note: IMO this discussion confuses
the notion of "named parameter" with the notion of "mixfix".

AFAIK Smalltalk has not "named parameters" [of course parameters
_have_ names inside the method, but not outside]. Positional
correspondence is used to bind the arguments in a method-call
to its parameter-names.

Smalltalk has "mixfix". The name (=selector?) of the method can
be split in several words. In the method-call the arguments stand
between these words.

Ada has "named parameters". The name of the parameters appears (in Ada: 
can appear) in the function-call. The arguments in the functions-call
are bound to parameters by name-correspondence. 

AFAIK Ada does not have "mixfix" [for userdefined functions -
If-then-else might be seen as mixfix-function.]

Just my $.02

Ulf Schuenemann

--------------------------------------------------------------------
 ,_.   Ulf Sch�nemann
#,  \  Fakult�t f�r Informatik, Technische Universit�t M�nchen, Germany.
 |   > mailto:schuenem@informatik.tu-muenchen.de
 v=-<  http://hphalle2.informatik.tu-muenchen.de/~schuenem/

Re: C++ Class

[Lee, Shih Hao]

Loc Minh Phan Van <locphan@scf.usc.edu> wrote in article
<33018394.1718@scf.usc.edu>...
> Hi,
> 	Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class. 
> 

Declare the constructor of that class to be protected.

class B {
protected:
	B() { /*...*/}
};

class D : public B {
public:
	D() : B() { /*...*/}
};

main()
{
	D d;		// OK!
	B b;		// Error!
}

tony
-- 
class Signature { static char *name, *belief, *URL, *eMail; };
char *Signature::name = "Lee, Shih Hao (Anthony Lee)";
char *Signature::belief = "Long live of Borland C++/OWL";
char *Signature::URL = "http://necta.nec.com.tw/~tony";
char *Signature::eMail = "mailto:tony@necta.nec.com.tw";

Re: language marketing question, was Re: What is wrong with OO ?

[Robert Dewar]

John said

<<Hmm.  Its more likely that the majority of people who do doctorates stay in
academia, rather than joining the corporate rat-race.  The latter offers
better money.>>

Why guess at something like this and, not surprisingly guess wrong. It is
certainly NOT the case that the majority of people who do doctorates stay
in academia!

Re: OO, C++, and something much better!

[Richard A. O'Keefe]

Alan Lovejoy <alovejoy@concentric.net> writes:
>An "operator" is a "built in" function whose semantics is defined by the
>grammar of the language.  The "name" of an operator is usually either
>reserved, or else would not be a syntactically valid programmer-defined 
>function identifier.

1.  "operator" is one of those words like "type".

2.  Grammars do not define the semantics.

3.  Let's take "+" in Ada as an operator (because that's what the Ada
    standard calls it).  It is not *A* built in function, it is several.
    And it is not a _fixed_ set, but a set which can be expanded.

    Guess what?  "+" in Smalltalk is exactly the same.  The language
    provides some built-in readings for "+" to which you can add your own.

4.  In Prolog, "operator" is a _syntactic_ property of symbols having
    _no_ semantic consequences whatsoever.   When people talk about
    "operator precedence languages", they are similarly referring to
    purely syntactic properties.

5.  In Prolog and Pop, both of them languages where the programmer can
    define new operators, the set of symbols usable as operators and the
    set of symbols usable as `function' names are identical.  In APL,
    user-defined functions _are_ niladic, monadic, or dyadic operators;
    ALL of them.


>In languages that permit "operator overloading," there will be syntactic
>(and usually semantic) constraints on the definition of an "operator" 
>that would not apply to other functions.  For example, the name of an
>operator would have to be the same as one of the "built in" operators.


6.  In Ada and C++, the only restriction on programmer overloading of
    infix operators is that they take two arguments.  

    But this is a fact about *those* languages, and *only* about those
    languages.  It is not a fact about operators.  In Algol 68, from
    which the designers of Ada and of C++ learned, programmers could
    and did define any operators they wanted.  In Fortran 90, the third
    "major" current language having operator overloading, there is an
    infinite set of programmer-definable operators.  In S, there is an
    infinite set of programmer-definable operators.

In short, you are confusing specific details that happen to apply to
a _few_ languages with general properties of operators in general.

To return to the specific case in point, the form

	X + Y

in Smalltalk involves
 - a symbol written infix between two expressions
 - which is drawn from a small language-defined set of symbols which
   can appear in that position
 - for which the language partially defines the semantics
 - to which the programmer can add additional semantics

Is there any aspect of this, relevant to the question of "notations that
help people avoid errors", which materially differs from the situation
in Ada?  Is there any aspect of this which makes it unreasonable to
call "+" in Smalltalk an (infix) operator?

The one and only thing present in Ada and C++ which is lacking here is
a notion of "precedence".  All "infix operators" in Smalltalk have the
same precedence.  But APL is exactly the same:  there is no operator
precedence in APL either, and no-one says the symbols are not operators!

>A programmer-defined operator named "=" would probably be constrained to 
>have a Boolean return type, and to have only two arguments.

You might actually take a look at C++ some time.  About having two
arguments, you are right.  _Any_ infix operator has to have two
arguments.  This is a fact about _syntax_.  But there is no such
restriction on the result type.

>The "+" operator would be constrained to have only two arguments,

The "+" thingy in Smalltalk gets two arguments as well.  How does that
make it not an operator?

>and would have a predefined and unchangeable evaluation order precedence.

You are muddling up the syntactic notion of precedence with the
semantic notion of evaluation order.  The evaluation order of overloaded
operators in Ada, C++, or Fortran is whatever you want it to be.  And
Smalltalk infix method calls *ALSO* have a predefined and unchangeable
precedence.  It just happens that they all have the same precedence.  So?

>The reason that "+" would be considered an operator in languages that have
>"operator overloading" is because the semantics of "+" is (partially)
>defined by the syntax of the language.  One does not need to define the
>meaning of "+" in Ada (as a function with source code) in order to use it
>for integer addition.

This is again characteristically muddled.  The *syntax* of Ada has, and
_can_ have, nothing to say about the *semantics* of the language.  The
initial semantics of the "+" symbol in Ada are defined EXACTLY the same
way that the initial semantics of the "+" symbol in Smalltalk are
defined:  by definitions associated with particular types in the standard
library.

I am very fond of Smalltalk.  You do it no service by pretending that
there is a fundamental difference here, especially when you do not know
Ada or C++ well.

True, you may be able to remove methods from "+" in Smalltalk, but that
is not a special fact about "+" in Smalltalk or a special restriction of
"+" in Ada.  You can't remove methods from _anything_ in Ada or C++.
-- 
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes.  --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Alan Lovejoy]

Piercarlo Grandi wrote:
> 
> >>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> alovejoy> Richard A. O'Keefe wrote:
> 
> Richard> [ ... ] I think any fair person would agree that calling "+" an
> Richard> operator is not _wholly_ unreasonable, even in Smalltalk.  The
> Richard> _application_ of "+" to arguments is a message send, but
> Richard> "message send" is no more and no less than "dispatched
> Richard> procedure call".
> 
> Richard> Anyone saying that "+" is not an operator in Ada, for example,
> Richard> on the flimsy grounds that "+" is actually an overloaded
> Richard> function, would not be taken seriously.  (Except in APL)
> Richard> "operator" is a syntactic property, not a semantic one. [ ... ]
> 
> Quite so, but then:
> 
> alovejoy> An "operator" is a "built in" function whose semantics is
> alovejoy> defined by the grammar of the language.
> 
> The _semantics_ are defined by the grammar????
> An operator like "+" is a _function_????

Ah, sorry.  You've caught me using imprecise terminology.  The semantics
are defined by the **language**, not the "grammar."  And the operator
"+" 
**names** an operation, in this case addition.  The compiler resolves
the 
"+" operator to a built-in function (that is, a compiler-defined inlined 
function or macro) as is appropriate for each usage (assuming the
language 
is statically typed, and that dynamic method dispatch is not required).  
So in the context of a particular usage, the "+" operator names a
particular 
conceptual function (e.g., "complex number addition").  And of course,
the 
compiler writer could implement the complex number addition operation as 
an actual function call, should he so desire.  

> In Smalltalk-80, unconventionally, there are no reserved operator
> symbols; but all symbols that are formed out of a certain set of special
> characters can/must be used in an affix role that _looks_ like (because
> of the absence of ':') infix notation, and might even be regarded as
> infix.
> 
> What is builtin in Smalltalk-80 is not operator symbols (the ``message
> selector'') but the primitive bytecodes to which they resolve (the
> ``method''), which is an operation, not an operator.
> 
> And so on...

Well, in most cases, binary message sends resolve to the same bytecode
as any other message send ("send selector stored as literal[n]").  What 
the selector may be is irrelevant to the message-send bytecode.  But in 
a few cases, the bytecode emitted by the compiler will specially reflect 
the message selector (e.g, "==" and other "no dispatch" messages).  It
is 
defensible to call such bytecodes operations--or rather, applying your
own 
criticism to this case, one can call what such bytecodes do "operations" 
(since the bytecodes are not literally operations, but merely codes that 
signify operations).

--
Alan L. Lovejoy		| Why Smalltalk?
Smalltalk Consultant    | Because I don't want to follow the crowd,
alovejoy@concentric.net	| but to lead it.

Re: OO, C++, and something much better!

[Alan Lovejoy]

Richard A. O'Keefe wrote:
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> >An "operator" is a "built in" function whose semantics is defined by the
> >grammar of the language.  The "name" of an operator is usually either
> >reserved, or else would not be a syntactically valid programmer-defined
> >function identifier.
> 
> 1.  "operator" is one of those words like "type".

Ok.  Given what you say below, I see what you mean.

> 2.  Grammars do not define the semantics.

Yes, sorry.  **Languages** specify a grammar and a mapping between
sentences 
and their meanings.

> 3.  Let's take "+" in Ada as an operator (because that's what the Ada
>     standard calls it).  It is not *A* built in function, it is several.
>     And it is not a _fixed_ set, but a set which can be expanded.

Yes, an operator (or more precisely, an operation) is not just one
function.  
Again, sorry for being imprecise.  What I should have said:

	An "operator" names a "built in" operation whose semantics are defined 
	by the programming language specification.  The code emitted by the
	compiler for an operation will either be a call to some built-in 
	(or perhaps user-defined) function, or will be generated inline as 
	specified by some macro function/template defined in the compiler. 
	The compiler may emit very different code for the "same" operation,
	depending on the context in which the operator was used (e.g., 
	integer addition versus complex number addition).

>     Guess what?  "+" in Smalltalk is exactly the same.  The language
>     provides some built-in readings for "+" to which you can add your own.

Note that I pointed out that "+" was one of a special set of message
selectors 
whose meaning was defined by the langauge.  The difference is that there
is nothing special about the syntax of "+" (that does not also apply to
any
other binary message selector).

> 4.  In Prolog, "operator" is a _syntactic_ property of symbols having
>     _no_ semantic consequences whatsoever.   When people talk about
>     "operator precedence languages", they are similarly referring to
>     purely syntactic properties.
>
> 5.  In Prolog and Pop, both of them languages where the programmer can
>     define new operators, the set of symbols usable as operators and the
>     set of symbols usable as `function' names are identical.  In APL,
>     user-defined functions _are_ niladic, monadic, or dyadic operators;
>     ALL of them.

So?  Terminology differs from language to language.  I was trying to
provide a definition that would be valid for most commonly-used
langauges
(which IMHO would not include Prolog, Pop or APL).  That my definition
does 
not jibe with the terminology of each and every language is neither
surprising
nor disturbing, IMHO.  I'm sorry if that doesn't fulfill the goals you'd
like
to set for the definition.  We each have our own agendas.

And if ALL functions are operators, then the distinction is meaningless:
the difference that makes no difference is not a real difference.

> >In languages that permit "operator overloading," there will be syntactic
> >(and usually semantic) constraints on the definition of an "operator"
> >that would not apply to other functions.  For example, the name of an
> >operator would have to be the same as one of the "built in" operators.
> 
> 6.  In Ada and C++, the only restriction on programmer overloading of
>     infix operators is that they take two arguments.

False:  I cannot name an operator whatever I choose.  I cannot invent
new
names, not even ones chosen from a set of legal characters.

>     But this is a fact about *those* languages, and *only* about those
>     languages.  It is not a fact about operators.  In Algol 68, from
>     which the designers of Ada and of C++ learned, programmers could
>     and did define any operators they wanted.  In Fortran 90, the third
>     "major" current language having operator overloading, there is an
>     infinite set of programmer-definable operators.  In S, there is an
>     infinite set of programmer-definable operators.
> 
> In short, you are confusing specific details that happen to apply to
> a _few_ languages with general properties of operators in general.

An alternative interpretation is that the term operator means different
things in different languages--a point you yourself have alluded to,
I believe.  As I said, I was trying to define "operator" so that it
would be consistent with the usage of the term in FORTRAN, COBOL, BASIC,
Pacal, C, C++ and other very commonly used languages.  I don't think
the term "operator" means the same thing in Pascal as it does in
Fortran-90
or in S, let alone APL or Pop.

> To return to the specific case in point, the form
> 
>         X + Y
> 
> in Smalltalk involves
>  - a symbol written infix between two expressions
>  - which is drawn from a small language-defined set of symbols which
>    can appear in that position
>  - for which the language partially defines the semantics
>  - to which the programmer can add additional semantics

Yes, and the expression

	X and: Y

in Smalltalk involves
   - a message selector written infix between two expressions (it's 
     certainly not "prefix" or "postfix" or "affix")
   - which is drawn from a small language-defined set of symbols which
     can appear in that position (the alphanumeric characters, which is 
     arguably a "small" set)
   - for which the language partially defines the semantics (in some
     implementations, #and: will be a "no lookup" message if the
     receiver is a Boolean)
   - to which the programmer can add additional semantics

So which one is an operator?  Neither?  Both?

> Is there any aspect of this, relevant to the question of "notations that
> help people avoid errors", which materially differs from the situation
> in Ada?  Is there any aspect of this which makes it unreasonable to
> call "+" in Smalltalk an (infix) operator?

I don't know.  I said in my post that "+" may be an operator, because
it may invoke a built-in operation.  It's just not an operator for any
syntactical reasons.  Without a definition of operator, how can this
be decided?  I provided a definition I like (after the ammendments I
offered due to your valid criticisms).  I have yet to see your
definition,
though.

> The one and only thing present in Ada and C++ which is lacking here is
> a notion of "precedence".  All "infix operators" in Smalltalk have the
> same precedence.  But APL is exactly the same:  there is no operator
> precedence in APL either, and no-one says the symbols are not operators!

No, all **binary selectors** have the same precedence.  A keyword
selector
with two arguments (one receiver and and one argument in ST jargon)
also has "infix" syntax--and all such also have the same precedence.

> >A programmer-defined operator named "=" would probably be constrained to
> >have a Boolean return type, and to have only two arguments.
> 
> You might actually take a look at C++ some time.  About having two
> arguments, you are right.  _Any_ infix operator has to have two
> arguments.  This is a fact about _syntax_.  But there is no such
> restriction on the result type.

Note I used "=" and not "==".  That was deliberate.  I was not thinking
of C++ per se.

And it is demonstrably false that an infix operator can only have two
arguments:  "x ? y : z" is an infix operator that takes three arguments.
Q.E.D.

> >The "+" operator would be constrained to have only two arguments,
> 
> The "+" thingy in Smalltalk gets two arguments as well.  How does that
> make it not an operator?

For the same reason that "on:" is not an operator?  All keyword
selectors
with only one ":" must also have exactly two "arguments" (or argument
and
receiver, in Smalltalk jargon).

But I was not arguing that "+" is not an operator in Smalltalk, but
rather
that if it is, it is not because of its syntax.

You can use syntactical distinctions to define what is and what is not
an operator if you choose.  But I don't see the utility of defining the
term that way.  Basing the distinction on a semantic difference of some
sort would seem to be more productive.  But to each his own.

> >and would have a predefined and unchangeable evaluation order precedence.
> 
> You are muddling up the syntactic notion of precedence with the
> semantic notion of evaluation order.  ...

Really? Would you care to be more specific on how my voluminous comments
on 
the nature and definition of "precedence" and "evaluation order" have
"muddled" 
the two?  Are you claiming there is no relation between them, and that
any
statement that implies such a relation improperly "muddles" them?

>.. The evaluation order of overloaded
> operators in Ada, C++, or Fortran is whatever you want it to be.

Well, when I learned C++ in the late eighties, the precedence of
operators 
was fixed, IIRC.  If the situation has changed since then (or my memory
is 
faulty), then I stand corrected.  However, if no one has yet written a
paper entitled, "Programmer-redefinable Operator Precedence Considered
Harmful," then I may have to do so.  It's bad enough to have to consult
a reference in order to determine what the precedence of an operator is.
To have the precedence be context-dependent based on the types of the
arguments... Shudder.

But this issue is not all that important to the definition of the term
"operator.".

>  And
> Smalltalk infix method calls *ALSO* have a predefined and unchangeable
> precedence.  It just happens that they all have the same precedence.  So?

So thay all have the same precedence, instead of having it determined on
a name by name (selector by selector, symbol by symbol) basis.  If I
define
a new method with the selector "@", its precedence is determined by the
fact that it is a binary selector, not by its specific name.

> >The reason that "+" would be considered an operator in languages that have
> >"operator overloading" is because the semantics of "+" is (partially)
> >defined by the syntax of the language.  One does not need to define the
> >meaning of "+" in Ada (as a function with source code) in order to use it
> >for integer addition.
> 
> This is again characteristically muddled.  The *syntax* of Ada has, and
> _can_ have, nothing to say about the *semantics* of the language.  ...

Yes. As I said above, I mispoke.  I should have said that "+" would be
considered an operator because its semantics is (partially) determined
by the language.

> ... The
> initial semantics of the "+" symbol in Ada are defined EXACTLY the same
> way that the initial semantics of the "+" symbol in Smalltalk are
> defined:  by definitions associated with particular types in the standard
> library.

As I said, "+" may in fact be an operator in Smalltalk, for just the
reasons
you give above.  I note that you are not arguing the case based on
syntax
here...

> I am very fond of Smalltalk.  You do it no service by pretending that
> there is a fundamental difference here, especially when you do not know
> Ada or C++ well.

I did not intend to imply that there is any fundamental difference, just
a syntactic one.  Why is that bad?  Or even inflammatory?

> True, you may be able to remove methods from "+" in Smalltalk, but that
> is not a special fact about "+" in Smalltalk or a special restriction of
> "+" in Ada.  You can't remove methods from _anything_ in Ada or C++.

I mentioned the possibility of removing "+" from the system in order to
show that the semantics of "+" is "built in" to most Smalltalk
implementations,
in support of the idea that "+" may in fact be an operator in
Smalltalk.  
I am sorry if anyone thought I was trying to say "see, Smalltalk is
different,
and more powerful and just all around better."  That was NOT the message
I was trying to convey, and I am mystified why anyone would have thought
so.

Was it, perhaps, due to my .sig?

--
Alan L. Lovejoy		| Why Smalltalk?
Smalltalk Consultant    | Because I don't want to follow the crowd,
alovejoy@concentric.net	| but to lead it.

Re: OO, C++, and something much better!

[Alan Lovejoy]

Piercarlo Grandi wrote:
> 
> >>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> alovejoy> The semantics are defined by the **language**, not the
> alovejoy> "grammar."  And the operator "+" **names** an operation, in
> alovejoy> this case addition.
> 
> alovejoy> The compiler resolves the "+" operator to a built-in function
> alovejoy> (that is, a compiler-defined inlined function or macro) as is
> alovejoy> appropriate for each usage (assuming the language is
> alovejoy> statically typed, and that dynamic method dispatch is not
> alovejoy> required).
> 
> Even in dynamically typed languages, as long as type inference can
> resolve to a single type... This, and the following, seem pedantic
> observations, and I can well imagine that you have written as you have
> written merely to verbosely list all possibilities, but they are
> important.
> 
> Also, it need not be a builtin function, as the languages mentioned in
> this thread, both Adas, ``Smalltalk''s of various ilks, and ``C++'', all
> permit using the "+" symbol to be bound to both builtin and user defined
> implementations, and more than one actually. I am rather sure that you
> know this, and it is probably important (for reasons I mention later)
> not to give the impression that usually/generally names that look like
> operators symbols can only be bound to builtins.

Yes. That's not what I was thinking (that operator symbols could only be
bound to builtins), but I can see that someone might well have taken it 
that way, now that you mention it.  In the classic languages, it was
typical for names not constructed using alphanumeric characters to be
reserved (not useable for programmer-defined entities).  This is
important
only for understanding the history of the terminology, and the
justifications
and motivations behind said terminology.

> [snip]
> 
> But the conclusion is really that the set of operator symbols that a
> language uses and the (syntactical) rules with which some of them are
> used are a rather independent matter from which implementation the
> symbol denotes, how many, and what is their nature (builtin, user
> defined, macro implemented as an extracode, or whatever).

Yes, exactly.  Any token can be given any meaning, since semantic
mapping
is arbitrary.  There is nothing special about "+", "=" or "return". 
They
are all just sequences of lexical symbols (which is true in any
language).  
This is why I don't like the idea of calling "+" an operator merely
because 
of the lexical symbol(s) with which it is composed.  Whether it's an
operator
or not should depend either on some mathematical property of its
semantics
(e.g., it is required to be associative, or transitive, or commutative,
or
some such)

Is there a useful semantic distinction between "function" and "operator" 
in math?  If so, what is it?

> In all three language families (ada, smalltalk, c++) mentioned the
> ability to use more or less arbitrary symbols for more or less arbitrary
> implementations is regarded as significant notational convenience;
> whether this actually amounts to much is not easy to say, but a
> qualitative argument can be made: that in an OO context it gives
> user-defined classes/types and the associated operations/procedures
> notational equivalence with the builtin ones, and thus enhances
> orthogonality and _notational_ abstraction, which may well be of some
> use.

Yep.  Using the same notation for the same conceptual function or
operation,
regardless of whether the implementation is programmer-defined or "built
in,"
certainly appears to "be of some use," at least in my experience.

--
Alan L. Lovejoy		| Why Smalltalk?
Smalltalk Consultant    | Because I don't want to follow the crowd,
alovejoy@concentric.net	| but to lead it.

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "cjolley" == Charles A Jolley <cjolley@oz.sunflower.org> writes:

>> Well, who am I to judge.. but in my view C++ is basically C with the 
>> capability to add functions to structs. Before I tried C++, I would
>> bundle pointers to functions in my C-structs to fake some kind of
>> OO-like bundling of similar functions ;)   C++ take this a major
>> step further by actually bundling data and functions together
>> in a struct. But that is what classes are in C++: just enhanced
>> structs!

cjolley> C++ actually does not bundle code with the structs. If a member
cjolley> function is not virtual, the compiler will just binds a
cjolley> obj.foo() reference to its obj::foo() counterpart.  On the
cjolley> other hand, if a member function is virtual, then function
cjolley> pointers, like you mentioned above, are used.  Anyway, just a
cjolley> minor detail; they're still just glorified structs. ;)

But this is an implementation detail, and even in the implementation
vtables of function pointers are not part of any instance of any
'struct'.

In ``C++'' in no way data and functions are bundled together; the only
bundling is of function declarations/definitions with data
declarations/definitions. There is an immense amount of difference
between:

  struct complex
  {
    float re,im;
    struct complex (*add)(struct complex,struct complex);
    ....
  };

  struct complex c = { .... };
  c = (*c.add)(c,c);

which is reminiscent of prototype systems and:

  class complex
  {
    float re,im;
  public:
    complex add(complex);
    ....
  };

  complex complex::add(complex b) { ... };

  complex c(....);
  c = c.add(c);

which isn't.

The difference is that in ``C++'' a 'class'/'struct' definition also
doubles up as a module, which contains the definition of a single
'struct' and of a bunch of related functions. In fact a ``C++'' 'class'
can be used as a mere module if it does not contains any data member
definitions. The above ``C++'' example should really be read as:

  class complex
  {
    struct complex { float re,im; };
  public:
    complex add(complex,complex);
    ....
  };

  complex::complex complex::add(complex::complex a,b) { ... };

  complex::complex c(....);
  c = complex::add(c,c);

If ``C++'' were based on the latter syntax scheme, admittedly more
verbose, fewer people would get the wrong impression that there is
anything magic/special about the affix syntax and the other syntactic
shortcuts. Too bad.

Naturally the same observation applies to the other languages with
similar syntax, like ``Smalltalk'' and ``Eiffel''; in all of these the
affix syntax and the syntactic conflation of the type definition with
that of the module can result in confusion, which is made worse in the
case of ``Smalltalk'' by the use of actor-like terms... In Ada 95 the
more verbose but clearer syntax is required, but then the compiler is
not requried to support or enforce the OO paradigm, and allows more than
one type definition in a module regardless (also in ``C++'', but only if
one uses the more verbose syntax).

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <yf3ybcsm5ce.fsf@sabi.demon.co.uk> Piercarlo Grandi <piercarl@sabi.demon.co.uk> writes:

> It names a particular implementation of that conceptual function; the
> lexical item "+" names a particular conceptual function in maths, not
> programming languages. The character "+" names procedures in programming
> languages and functions in maths...

Just to be clear: "+" does not stand for some _particular_ function in
mathematics.  It varies on context.  Specifically, a) what the formal
system is and b) what interpretation is being given to that system.


> At times, BTW, I am not so sure that is such a good idea, for while the
> function computed by the "+" procedure usually somewhat resembles the
> function indicated by "+" in maths, the details (and vital ones) are as
> a rule grotesquely different (just consider addition of 'real's and of
> 'R'eals).

Again - it depends on context.  There are cases where the two will
denote identical results.


> I often think that the constant attempt to make programming languages
> resemble maths (and this includes functional languages) are not quite
> useful: Lisp, properly written, seems rather legible and yet does not
> quite resemble maths notation, operator symbols and all that.

Forget about the notation.  That's irrelvant.  The real problem is
that _often_ (not always) the semantics are all wrong in those cases
where they are "supposed to be the same or at least similar".


> In all three language families (ada, smalltalk, c++) mentioned the
> ability to use more or less arbitrary symbols for more or less arbitrary
> implementations is regarded as significant notational convenience;
> whether this actually amounts to much is not easy to say, but a
> qualitative argument can be made: that in an OO context it gives
> user-defined classes/types and the associated operations/procedures
> notational equivalence with the builtin ones, and thus enhances
> orthogonality and _notational_ abstraction, which may well be of some
> use.

Bingo.  That's pretty much it in a nutshell...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <33054E63.C2A@concentric.net> Alan Lovejoy <alovejoy@concentric.net> writes:

> Is there a useful semantic distinction between "function" and "operator" 
> in math?  If so, what is it?

Generally speaking, the terms "operator" and "operation" are used to
refer to functions which map an "n-order" set to the "base" or
"1-order" set.  Let A be a set and A^n be the cross product of A with
it self n times (n could be 1).  If f is a function from A^n to A,
f:A^n -> A, then f is an "n-ary operation".  For example, addition is
a simple binary operation on N (set of naturals).  The identity
operation is a simple unary operation for any set.  Strictly speaking,
the term "operator" is used to refer to the particular symbol for the
operation, but in practice (outside a strictly formal account) this is
typically "slopped over".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Piercarlo Grandi]

>>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:

[ ... mostly agreement, BTW, ... ]

piercarl> But the conclusion is really that the set of operator symbols
piercarl> that a language uses and the (syntactical) rules with which
piercarl> some of them are used are a rather independent matter from
piercarl> which implementation the symbol denotes, how many, and what is
piercarl> their nature (builtin, user defined, macro implemented as an
piercarl> extracode, or whatever).

alovejoy> Yes, exactly.  Any token can be given any meaning, since
alovejoy> semantic mapping is arbitrary.  There is nothing special about
alovejoy> "+", "=" or "return".  They are all just sequences of lexical
alovejoy> symbols (which is true in any language).  This is why I don't
alovejoy> like the idea of calling "+" an operator merely because of the
alovejoy> lexical symbol(s) with which it is composed.

Ah, but I seem to remember that the original observation By Richard
O'Keefe was that whatever in most languages one calls operators is
things that are used with ``operator'' *syntax* (binary or unary),
rather than procedure call syntax, not that operators are those things
indicated by ``special'' characters, that is some sort of ``operator''
*lexicon*.

For example in ``C'' 'sizeof' indicates a unary operator, and in
``Pascal'' 'div' indicates a binary operator, and so on. ``C'' even has
a _ternary_ operator ('?:'), whose invocation syntax is rather
distinguished from that of three-argument procedures.

You may be a bit misled by your familiarity with ``Smalltallk'', which
makes it possible to use ``operator'' syntax only with symbols composed
of ``special' characters. But even in ``Smalltalk'' what really
distinguishes operators is the type of syntax they are used in, not
quite their appearance (even if it is that which implies the use of
operator-like syntax).

alovejoy> Whether it's an operator or not should depend either on some
alovejoy> mathematical property of its semantics (e.g., it is required
alovejoy> to be associative, or transitive, or commutative, or some
alovejoy> such).

This a bit dangerous (for user-defined operators); besides what really
distinguished operator from procedure invocations in most languages is
the invocation syntax, not the semantics of the associated procedure, or
the lexicon from which the symbol is drawn (which *may* be restricted in
some language though).

alovejoy> Is there a useful semantic distinction between "function" and
alovejoy> "operator" in math?  If so, what is it?

I would say it's still syntax: operators, however fancily named, tend to
be used in binary/unary syntax forms, and functions in applicative (name
plus parenthesized arg list) syntax. The two can get a bit confused,
especially for unary operators, as in programming languages (for example
many ``C'' programmers haven't realized that 'sizeof' is an operator and
not a function an write 'int a; a = sizeof(a)', instead of the more
appropriate 'sizeof a').

But then mathematicians invent notation all the time; they even have
suffix operator (e.g. "!" for factorial) or "around" operators (like
"||" for absolute value) and many more types beside. The common thing is
not quite that they use non-alphabetic symbols, but that they don't use
applicative syntax like 'f(....,....)'; consider for examples of
alphabetic operators commonly used in maths things like the 'lim' unary
operator notation, or 'sup' as used in Knuth vol 1.

Re: OO, C++, and something much better!

[Alan Lovejoy]

Piercarlo Grandi wrote:
> 
> >>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> [ ... mostly agreement, BTW, ... ]
> 
> piercarl> But the conclusion is really that the set of operator symbols
> piercarl> that a language uses and the (syntactical) rules with which
> piercarl> some of them are used are a rather independent matter from
> piercarl> which implementation the symbol denotes, how many, and what is
> piercarl> their nature (builtin, user defined, macro implemented as an
> piercarl> extracode, or whatever).
> 
> alovejoy> Yes, exactly.  Any token can be given any meaning, since
> alovejoy> semantic mapping is arbitrary.  There is nothing special about
> alovejoy> "+", "=" or "return".  They are all just sequences of lexical
> alovejoy> symbols (which is true in any language).  This is why I don't
> alovejoy> like the idea of calling "+" an operator merely because of the
> alovejoy> lexical symbol(s) with which it is composed.
> 
> Ah, but I seem to remember that the original observation By Richard
> O'Keefe was that whatever in most languages one calls operators is
> things that are used with ``operator'' *syntax* (binary or unary),
> rather than procedure call syntax, not that operators are those things
> indicated by ``special'' characters, that is some sort of ``operator''
> *lexicon*.
> 
> For example in ``C'' 'sizeof' indicates a unary operator, and in
> ``Pascal'' 'div' indicates a binary operator, and so on. ``C'' even has
> a _ternary_ operator ('?:'), whose invocation syntax is rather
> distinguished from that of three-argument procedures.
> 
> You may be a bit misled by your familiarity with ``Smalltallk'', which
> makes it possible to use ``operator'' syntax only with symbols composed
> of ``special' characters. But even in ``Smalltalk'' what really
> distinguishes operators is the type of syntax they are used in, not
> quite their appearance (even if it is that which implies the use of
> operator-like syntax).

Well, as you know, the only difference in the "syntax" of Smalltalk
binary
message sends and keyword message sends involves the form of the
selector
(a binary message selector must be composed of characters from a special
lexicon, it can have no more than two characters, and unlike a keyword
selector, it does not terminate with the ":" character).

If "div" qualifies as an operator in Pascal on syntactical grounds
(because 
it does not use the "()" to bracket an argument list), why would the
Smalltalk 
message selector "div:" not also qualify as an operator on the same
basis 
(since it also does not use "()" to bracket an argument list)?

Many seem to feel that any function name whose syntax matches that of
symbols such as "+" as used in mathematical expressions is an operator,
and that anything else is not.  Excuse me, but the only difference
between
such syntax and that of message selectors such as "and:" or "div:" in
Smalltalk is the final ":" character in the function names.   That seems
rather an insubstantial basis on which to distinguish between
"operators" 
and "non-operators."   Would the "div" operator in Pascal cease to
qualify
as an operator if its name were changed to "div:"?

> alovejoy> Whether it's an operator or not should depend either on some
> alovejoy> mathematical property of its semantics (e.g., it is required
> alovejoy> to be associative, or transitive, or commutative, or some
> alovejoy> such).
> 
> This a bit dangerous (for user-defined operators); besides what really
> distinguished operator from procedure invocations in most languages is
> the invocation syntax, not the semantics of the associated procedure, or
> the lexicon from which the symbol is drawn (which *may* be restricted in
> some language though).

I was not seriously proposing that an operator is some function that
conforms
to the associative property, but rather that it is some function that
conforms
to some well-defined math or computer science property.  For example,
according
to Jon Anthony, an "operator" in math should be a function of the form
"f: A^n -> A".  That is precisely the sort of thing I was reaching for;
the
references to associativity, transitivity and commutativity were merely
illustrative. And I agree that using any of those three properties as
the
criterion for determining what is or is not an operator in a programming
language would be ill-advised.

> alovejoy> Is there a useful semantic distinction between "function" and
> alovejoy> "operator" in math?  If so, what is it?
> 
> I would say it's still syntax: operators, however fancily named, tend to
> be used in binary/unary syntax forms, and functions in applicative (name
> plus parenthesized arg list) syntax. The two can get a bit confused,
> especially for unary operators, as in programming languages (for example
> many ``C'' programmers haven't realized that 'sizeof' is an operator and
> not a function an write 'int a; a = sizeof(a)', instead of the more
> appropriate 'sizeof a').
>
> But then mathematicians invent notation all the time; they even have
> suffix operator (e.g. "!" for factorial) or "around" operators (like
> "||" for absolute value) and many more types beside. The common thing is
> not quite that they use non-alphabetic symbols, but that they don't use
> applicative syntax like 'f(....,....)'; consider for examples of
> alphabetic operators commonly used in maths things like the 'lim' unary
> operator notation, or 'sup' as used in Knuth vol 1.

Smalltalk doesn't have "applicative" (name plus parenthesized arg list) 
syntax for message selectors.  Does that mean that all Smalltalk message
selectors are operators?  What about message selectors such as "print"
or
"size"?

I don't like the idea of using syntax to define what an operator is.  
Especially since that is not the basis for the distinction in math,
which
apparently uses the semantics of the function to make the distinction, 
as I have suggested should be the case in computer science (whether we
should use the same definition as in math is another question, however).

And how would you use syntax to tell what is or is not an operator in 
a visual programming language that used only icons and no lexical names?

--
Alan L. Lovejoy		| Why Smalltalk?
Smalltalk Consultant    | Because I don't want to follow the crowd,
alovejoy@concentric.net	| but to lead it.

Re: OO, C++, and something much better!

[Piercarlo Grandi]

>>> "jsa" == Jon S Anthony <jsa@alexandria> writes:

jsa> In article <yf3ybcsm5ce.fsf@sabi.demon.co.uk> Piercarlo Grandi
jsa> <piercarl@sabi.demon.co.uk> writes:

piercarl> It names a particular implementation of that conceptual
piercarl> function; the lexical item "+" names a particular conceptual
piercarl> function in maths, not programming languages. The character
piercarl> "+" names procedures in programming languages and functions in
piercarl> maths...

jsa> Just to be clear: "+" does not stand for some _particular_ function
jsa> in mathematics.

But it does, and sorry if I used the word "particular" improperly; I
meant by it something "any definite"; ``maths'' is often rather precise,
and which ``particular'' function "+" stands for must be very clear,
but, as you write:

jsa> It varies on context.  Specifically, a) what the formal system is
jsa> and b) what interpretation is being given to that system.

It was also perhaps not clear that by "maths" I meant something like
``ordinary maths'', a not well defined but hopefully intuitively
perceivable notion; for most any given procedure indicated by "+"
computes *some* mathematical function, even if not necessarily the one
indicated by "+" in most ``ordinary maths'' (one favourite example is
that "+" between 'unsigned' operands in ``C'' computes the function
``addition module 2^N'' rather than addition on nonnegative numbers).

piercarl> At times, BTW, I am not so sure that is such a good idea, for
piercarl> while the function computed by the "+" procedure usually
piercarl> somewhat resembles the function indicated by "+" in maths, the
piercarl> details (and vital ones) are as a rule grotesquely different
piercarl> (just consider addition of 'real's and of 'R'eals).

jsa> Again - it depends on context.

That's entirely correct, and exactly my point; as I wrote, "usually",
not "always" or "never". However the cases where the function computer
by some "+" procedure are exactly identicaly to the function dinciated
by "+" in some branch of maths would tend to be few; one major factor is
that procedures usually compute functions over finite domains/codomains,
which is almost never the case in [``ordinary''] maths, and even in
``discrete'' maths.

jsa> There are cases where the two will denote identical results.

Well, this is actually quite impossible as literally written :-); the
results of any particular "+" operation are in the domain of
implementation entities, those of any articular "+" function are in the
domain of mathematical entities.

What you probably wanted to say is that it can happen that the function
computed by some particular "+" operation is exactly the same as that
meant by some "+" function in ``ordinary'' maths.

Ues indeed, but I suspect that this is rare, for example for the reason
given above; also given that the levels of discouse of procedures
(implementations) and functions (maths) are so different, I feel that
notational similarity can mislead, and indeed:

piercarl> I often think that the constant attempt to make programming
piercarl> languages resemble maths (and this includes functional
piercarl> languages) are not quite useful: Lisp, properly written, seems
piercarl> rather legible and yet does not quite resemble maths notation,
piercarl> operator symbols and all that.

jsa> Forget about the notation.  That's irrelvant.  The real problem is
jsa> that _often_ (not always) the semantics are all wrong in those cases
jsa> where they are "supposed to be the same or at least similar".

Well, while what I have written expresses a similar sentiment, I would
be so radical in saying that notation is so irrelevant.

Actually it is irrelevant, but it is not _unimportant_, for programs are
about communicating in textual form, and communicating by suggesting
analogies that are more or less subtly flawed (e.g. having a floating
point datatype called 'real' as in many languages) might confuse people.

This is why I have expressed the idea that it might actually be useful
to have rarther different looking notations for procedures and
functions; it should matter, but I must confess that even I am
constantly amazed by the fondness for terminological confusions that
many people display; the major example is "OO", which many people take
literally as being about objects, with dire consequences.

Misnomers such as "OO" and notational devices *are* irrelevant, to those
that see them as mere pointers to the concepts they label; but
unfortunately nominalism is rampant.

[ ... agreement, strangely enough :-). Omitted not to set a bad
precedent :-) ... ]

Re: What is wrong with OO ?

[Sam Inala]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.855671030@merv>...
> Charles said
> <<C++ actually does not bundle code with the structs. If a member
function
> is not virtual, the compiler will just binds a obj.foo() reference to its
> obj::foo() counterpart.  On the other hand, if a member function is
> virtual, then function pointers, like you mentioned above, are used.
> Anyway, just a minor detail; they're still just glorified structs. ;)>>
> 
> YOu should better say "typical C++ implementations" rather than C++, I
see
> nothing in the draft standard that would support your claim that this is
> implied by the language definition.

Just for clarification: even typical C++ implementations differ from
structs
containing function pointers. Consider the following:

#include <stdio.h>

struct One {
   int x;
};

struct Two {
   int x;
   void foo() {}
};

struct Three {
   int x;
   virtual void foo() {}
};

struct Four {
   int x;
   virtual void foo() {}
   virtual void bar() {}
};

int
main() {
   printf( "sizes = %d %d %d %d\n", sizeof( One ), sizeof( Two ),
	sizeof( Three ), sizeof( Four ) );
   return 0;
}

Output from gcc:
sizes = 4 4 8 8

With an implementation of class Four like this:

struct Four {
	int x;
	void (*foo)();
	void (*bar)();
};

...we would expect the sizeof( Four ) to be 12. Instead, it most
likely contains a single pointer to a table of function pointers,
which are shared by all the instances of the class:

struct Four {
	void* vtbl;
	int x;
};

<return type> (*Four::function[ cMethods ])(...);

I only mention this because I perceive people thinking
that object instances carry around their own virtual 
function tables.

Re: What is wrong with OO ?

[Robert Dewar]

Sam said

<<...we would expect the sizeof( Four ) to be 12. Instead, it most
likely contains a single pointer to a table of function pointers,
which are shared by all the instances of the class:>>

I don't know who "we" is here, but I can't see anyone expecting this,
your "instead" is the obvious implementation, and it would surprise
me (though certainly not be invalid) if a C++ implementation did
anything else!

Re: OO, C++, and something much better!

[Piercarlo Grandi]

>>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:

piercarl> Ah, but I seem to remember that the original observation By
piercarl> Richard O'Keefe was that whatever in most languages one calls
piercarl> operators is things that are used with ``operator'' *syntax*
piercarl> (binary or unary), rather than procedure call syntax, not that
piercarl> operators are those things indicated by ``special''
piercarl> characters, that is some sort of ``operator'' *lexicon*. [
piercarl> ... examples that operators are distinguished by their
piercarl> syntactic role, usually infix/binary, prefix/unary ... ]

alovejoy> Well, as you know, the only difference in the "syntax" of
alovejoy> Smalltalk binary message sends and keyword message sends
alovejoy> involves the form of the selector (a binary message selector
alovejoy> must be composed of characters from a special lexicon, it can
alovejoy> have no more than two characters, and unlike a keyword
alovejoy> selector, it does not terminate with the ":" character).

alovejoy> If "div" qualifies as an operator in Pascal on syntactical
alovejoy> grounds (because it does not use the "()" to bracket an
alovejoy> argument list),

Not quite: because it has a syntactic role different from that of
procedure calls. In Pascal and most other languages procedure calls use
parenthetical applicative form, but operators use infix notation.

Let's start from this point: that *if* a programming language has both
procedure calls and operator uses, then they must look different somehow
to be distinguished. Now *looks* can be either syntax or lexicon. Now
the syntax role of operators seems to be rather more strongly
disciminating role in most languages, and in maths, than their lexicon,
even if often the lexicon is characteristic too.

alovejoy> why would the Smalltalk message selector "div:" not also
alovejoy> qualify as an operator on the same basis (since it also does
alovejoy> not use "()" to bracket an argument list)?

Not, because that is not a distinguished infix syntax; that's the syntax
use for normal procedure/method calls. For the latter ``Smalltalk'' uses
affix syntax, using the method selector name as the ``brackets''/``commas''
around the argument list, instead of parenthesis. Consider:

  Pascal:     i := j div k;
	      i := divide(j,k);

  Smalltalk:  i <- j // k.
	      i <- j dividedBy: k.

Now affix syntax of the keyword message like the 'o1 p: o2 q: o3' form
is the way to apply ``normal'' procedures/methods in ``Smalltalk'', and
is/would be equivalent to something like 'p:q:(o1,o2,o3)'.

it is interesting to note that ``Smalltalk'' rules tend to be a bit
oddball: for unary selectors, which must be normal symbols, look in fact
like postfix unary operators, and something like 'i div: b' looks very
much like an operator.

alovejoy> Many seem to feel that any function name whose syntax matches
alovejoy> that of symbols such as "+" as used in mathematical
alovejoy> expressions is an operator, and that anything else is not.

Lexicon, not syntax, is probably you meant here. But then both in maths
and in programming languages there are many operators, or at least
entities so called, which are drawn from the lexicon of normal
identifiers. What distinguishes them is that they must be used in some
distinguished, usually briefer than function application, syntactic
role. In most languages that have prefix/parenthetical application for
``normal'' procedures, operators have prefix/infix non parenthetical
syntax; the distinction may often be very small. Consider something like
'ABS x' vs. 'abs(x)' in ALGOL68, or for that matter 'sizeof a'
vs. 'sqrt(a)' in ``C''.

alovejoy> Excuse me, but the only difference between such syntax and
alovejoy> that of message selectors such as "and:" or "div:" in
alovejoy> Smalltalk is the final ":" character in the function names.

alovejoy> That seems rather an insubstantial basis on which to
alovejoy> distinguish between "operators" and "non-operators."  Would
alovejoy> the "div" operator in Pascal cease to qualify as an operator
alovejoy> if its name were changed to "div:"?

Not at all. My point is that it is *not* the lexicon that makes a symbol
into an operator, but a distinguished syntactic role, usually
``briefer'' than that of a normal procedure. In the ``Smalltalk'' case
binary selectors _do_ have a distinguished syntactic role, which is
indeed usually briefer (to the point that a length limitation to 2
characters is part of the rules for binary selectors).

Consider conversely ``Smalltalk'' vs. ``Pascal'' vs. maths:

  Smalltalk:	a div: b
		a // b

  Pascal:	Div(a,b)
		a div b

  maths:	div(a,b)
		a / b

To me the difference is that in all cases there is an ``ordinary''
syntax and a ``dinstiguished' syntax, and that _usually_ the
distinguished syntax is briefer/neater (otherwise there would be no
advantage to using a distinguished syntax), and often it is briefer
because the lexicon of operators is distinguished too, but not
necessarily in either programming languages or maths.

alovejoy> Whether it's an operator or not should depend either on some
alovejoy> mathematical property of its semantics (e.g., it is required
alovejoy> to be associative, or transitive, or commutative, or some
alovejoy> such). [ ... ] For example, according to Jon Anthony, an
alovejoy> "operator" in math should be a function of the form "f: A^n ->
alovejoy> A".  That is precisely the sort of thing I was reaching for; [
alovejoy> ... ]

Ahhh, but is the definition of "operator" as in ``operator theory''; as
you write a *function* is called an "operator [function]" if it is of
the given form. But operator functions and operators are quite different
entities. The discussion was really about what looks like operators. Now
there are a lot of things that look like operators in maths, which do
not indicate an operator function.

Given that maths notation and programming language notation are up to
the each and every author/programming language designer, stating
precisely what is an operator is not quite possible; but one show
examples and draw general rules. In maths operators are symbols that
essentially always have some distinguished syntatic role, and very often
are drawn from some distinguished lexicon too.

After all, as in ``Lisp'', one could simply use the same syntax and
lexicon for any symbol whatsoever; one can write:

  (+ a b)
  (plus a b)
  (do-a-+-operation-on: a b)
  (*be/very/careful->here* a b)

The one disadvantage to not having a distinguished operator syntax (and
perhaps lexicon) is verbosity; but then ``Lisp'' to me at least is as
readable as any other programming language.

Mathematicians are fond of shorthands; just consider Dirac notation
$<a|b>$, which is quite neat indeed. They might be useful in maths,
where notational simplicity may help quite a lot.

I am not quite sure that syntactic/lexical shorthands actually help in
programming, but most programming language designers, in the doubt,
provide some sort of maths-like distinguished syntax for operators.

Operator theory is entirely another matter; it is just a theory of a
class of functions.

Further material on this minuscule but amusing topic... There is a
classification of mathematical subjects online at:

  http://www.ma.hw.ac.uk/~chris/MR/MR.html

and it has a searchable index, which returns quite a number of diverse
topics as to the various meanings that can be related to "operator" in
maths.

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <yf3914o33ne.fsf@sabi.demon.co.uk> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

> But then mathematicians invent notation all the time; they even have
> suffix operator (e.g. "!" for factorial) or "around" operators (like
> "||" for absolute value) and many more types beside. The common thing is
> not quite that they use non-alphabetic symbols, but that they don't use
> applicative syntax like 'f(....,....)';

??? Mathematicians use the function "syntax" all the time.  It's
probably one of the single _most_ used notations.

> consider for examples of alphabetic operators commonly used in maths
> things like the 'lim' unary operator notation,

How do you figure that "lim" is a unary operator???  Depending on
context it is a function of at least three arguments (independent
variable, the "limit", and a function) and may well a) not even have a
value and b) even if it does, it may not be in the range of the
function argument.  Actually, in mathematical parlence "lim" is not
even an operator.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <yf3d8u0380w.fsf@sabi.demon.co.uk> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

> >>> "jsa" == Jon S Anthony <jsa@alexandria> writes:
> 
> jsa> Just to be clear: "+" does not stand for some _particular_ function
> jsa> in mathematics.
> 
> But it does, and sorry if I used the word "particular" improperly; I
> meant by it something "any definite";

My point was simply that there is not one particular interpretation
for "+" in mathematics.  This is actually obvious and I'm sure you'd
agree.


> jsa> It varies on context.  Specifically, a) what the formal system is
> jsa> and b) what interpretation is being given to that system.
> 
> It was also perhaps not clear that by "maths" I meant something like
> ``ordinary maths'', a not well defined but hopefully intuitively

And?  Presumably, by "ordinary maths" here you really mean arithmetic.
That is a precisely and rigorously defined system.


> perceivable notion; for most any given procedure indicated by "+"
> computes *some* mathematical function, even if not necessarily the one
> indicated by "+" in most ``ordinary maths''

Presumably you simply mean here that "computer arithmetic" or the
specification of arithmetic operations in a programming language
definition is not the same as standard arithmetic (even though in many
practical cases you can ignore the differences).  Well, sure.


> (one favourite example is that "+" between 'unsigned' operands in
> ``C'' computes the function ``addition module 2^N'' rather than
> addition on nonnegative numbers).

Why is congruential arithmetic not ordinary?  Note that this too has a
completely precise and rigorous definition and theory.


> by "+" in some branch of maths would tend to be few; one major factor is
> that procedures usually compute functions over finite domains/codomains,
> which is almost never the case in [``ordinary''] maths, and even in
> ``discrete'' maths.

What makes you say that??  Certainly any congruence system has this
exact aspect.  Large chunks of combinatorics deal in finite systems.
What about finite groups?  And whose to say that in "day to day
arithmetic" you aren't dealing with a congruence system whose modulus
just happens to be 10^50 or something?


> jsa> There are cases where the two will denote identical results.
> 
> Well, this is actually quite impossible as literally written :-);
> the results of any particular "+" operation are in the domain of
> implementation entities, those of any articular "+" function are in
> the domain of mathematical entities.

Yes, I see the "smiley", but I'm not sure this distinction is true or
of any use.  It would seem to imply that any set of "squiggles" on a
blackboard or piece of paper are "implementation entities" and have
not much to do with the mathematical entities they represent.  I don't
think so...


> What you probably wanted to say is that it can happen that the function
> computed by some particular "+" operation is exactly the same as that
> meant by some "+" function in ``ordinary'' maths.

What I meant was that you can't distinguish the two in any meaningful
way even if they are "in some sense different".


> jsa> Forget about the notation.  That's irrelvant.  The real problem is
> jsa> that _often_ (not always) the semantics are all wrong in those cases
> jsa> where they are "supposed to be the same or at least similar".
> 
> Well, while what I have written expresses a similar sentiment, I would
> be so radical in saying that notation is so irrelevant.
> 
> Actually it is irrelevant, but it is not _unimportant_, for programs are
> about communicating in textual form, and communicating by suggesting
[...etc....]

Yeah.  OK, I can agree with this.


> constantly amazed by the fondness for terminological confusions that
> many people display; the major example is "OO", which many people take
> literally as being about objects, with dire consequences.

Well, here we definitely agree.


> Misnomers such as "OO" and notational devices *are* irrelevant, to those
> that see them as mere pointers to the concepts they label; but
> unfortunately nominalism is rampant.

:-( but true...


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <330794C0.55E@concentric.net> Alan Lovejoy <alovejoy@concentric.net> writes:

> I don't like the idea of using syntax to define what an operator is.
> Especially since that is not the basis for the distinction in math,
> which apparently uses the semantics of the function to make the
> distinction, as I have suggested should be the case in computer
> science (whether we should use the same definition as in math is
> another question, however).

Yes, but as you hint at, there is no particular reason why "operator"
in CS/PL land should mean anything like what "operator" means in
mathematics.


> And how would you use syntax to tell what is or is not an operator
> in a visual programming language that used only icons and no lexical
> names?

Easy - the icons fit together in some ways (otherwise you'd just have
a bunch of fancy glyphs which could not be grouped together to say
anything more than what each alone says).  The "some ways of fitting
together" is just syntax.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Alan Lovejoy]

Jon S Anthony wrote:
> 
> In article <yf3afp4nepm.fsf@sabi.demon.co.uk> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:
> 
> > alovejoy> Whether it's an operator or not should depend either on some
> > alovejoy> mathematical property of its semantics (e.g., it is required
> > alovejoy> to be associative, or transitive, or commutative, or some
> > alovejoy> such). [ ... ] For example, according to Jon Anthony, an
> > alovejoy> "operator" in math should be a function of the form "f: A^n ->
> > alovejoy> A".  That is precisely the sort of thing I was reaching for; [
> > alovejoy> ... ]
> >
> > Ahhh, but is the definition of "operator" as in ``operator theory''; as
> > you write a *function* is called an "operator [function]" if it is of
> > the given form. But operator functions and operators are quite different
> > entities.
> 
> I think what you really want to say is simply that you don't think the
> standard mathematical usage is appropriate in the context of PL
> definitions.  Alan, OTOH, seems to think that it is a good idea to
> maintain some consistency with the mathematical usage.  It's not
> obvious to me which of these two views is "better".
> 
> You seem to think that you can get useful milage out of this rather
> vague and inconsistent sense used in PLs and programming.  I'm not
> sure why you think this is useful.  Perhaps as a way of calling out
> certain predefined restrictions and such in a PL definition.
> 
> Alan seems to think that maintaining the mathematical sense at least
> gives some solidity and clarity to the subject.  True enough.  But,
> it's not clear to me that this sense would have any clear use in CS/PL
> land.
> 
> Also, "operator" and "operation" are used in various mathematical
> settings in the way described, i.e., this usage is not restricted to a
> particular branch or theory.

It was useful to see Jon's interpretation of what I have said.  Had I
not
seen this, I would not have realized that I need to make my position
more
clear :-) (I take full responsibility for not stating my case with
sufficient
clarity).

I think one problem is caused by the distinction between a "descriptive"
versus a "prescriptive" statement of the meaning and usage of the terms
"operator" and "operation" in CS/PL.  It is one thing to describe
current
practice ("descriptive"), and another to advocate a "proper" usage based
on some idea of how things ought to be ("prescriptive").  None of us
have
always been completely clear with which attitude we were speaking.

And as has been noted already, "current practice" varies among various
languages.  However, I am less interested in a description of current
practice than I am in discussing how the terms should be used in 
language-independent CS discourse.  In a previous post, I defined
"operator" using syntactical distinctions (among other criteria).  That
definition was descriptive--of how the term is used in traditional,
widely-used languages.  But when I say that I think that the definition
of "operator" should not be based on syntax, I am prescribing what
I would prefer, not describing APL.

I am definitely NOT advocating that the meaning of "operator" should be
determined by its math meaning.  I think that CS should fix the meaning
of this term based on the needs and requirements of CS, not those of 
mathematics.  Each culture and society develops its own lexicon, syntax,
semantic system and taxonomy of the things important to life in that
culture/society.  Those who live near one of the poles may need many
more words for snow than those who live on a tropical island near the
equator.  Those who implement procedures for machine execution of
algorithms may need a different terminology than those who need to
construct formal proofs in the domain of mathematics.

What I like about the definition of "operator" in mathematics is that it 
is based on the semantics of the function, not its syntax.  I think that 
a distinction based on function semantics is inherently more general,
and 
much more likely to be useful in language-independent CS discourse, than 
one based on syntax.  For example, I find the distinction between
"built-in" 
versus "programmer-defined" procedure to be a more useful distinction
than 
one between "standard" versus "special" function call syntax.  There is
no requirement for a language to even have a "special" function call 
syntax. Even if a language has more than one, it may not be possible to 
identify one as "standard" and the other(s) as "special."

It is arguable, for example, whether or not the syntax of binary message
sends in Smalltalk is "special."  For that matter, one could also argue
whether or not the syntax of unary message sends is "special." The case 
could be made that there are simply three different styles, all of which 
are "first class." The only differences are the number of arguments that
are required/permitted, and the lexical symbols out of which the names
of the functions can be constructed. Lacking any formal definition of 
"special syntax", the matter is purely one of opinion, not fact.

So, Jon: Is that clearer?  Are our positions closer than you had
supposed?

--
Alan L. Lovejoy		| Why Smalltalk?
Smalltalk Consultant    | Because I don't want to follow the crowd,
alovejoy@concentric.net	| but to lead it.

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <yf3afp4nepm.fsf@sabi.demon.co.uk> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

> alovejoy> Whether it's an operator or not should depend either on some
> alovejoy> mathematical property of its semantics (e.g., it is required
> alovejoy> to be associative, or transitive, or commutative, or some
> alovejoy> such). [ ... ] For example, according to Jon Anthony, an
> alovejoy> "operator" in math should be a function of the form "f: A^n ->
> alovejoy> A".  That is precisely the sort of thing I was reaching for; [
> alovejoy> ... ]
> 
> Ahhh, but is the definition of "operator" as in ``operator theory''; as
> you write a *function* is called an "operator [function]" if it is of
> the given form. But operator functions and operators are quite different
> entities.

I think what you really want to say is simply that you don't think the
standard mathematical usage is appropriate in the context of PL
definitions.  Alan, OTOH, seems to think that it is a good idea to
maintain some consistency with the mathematical usage.  It's not
obvious to me which of these two views is "better".

You seem to think that you can get useful milage out of this rather
vague and inconsistent sense used in PLs and programming.  I'm not
sure why you think this is useful.  Perhaps as a way of calling out
certain predefined restrictions and such in a PL definition.

Alan seems to think that maintaining the mathematical sense at least
gives some solidity and clarity to the subject.  True enough.  But,
it's not clear to me that this sense would have any clear use in CS/PL
land.

Also, "operator" and "operation" are used in various mathematical
settings in the way described, i.e., this usage is not restricted to a
particular branch or theory.


> The discussion was really about what looks like operators. Now
> there are a lot of things that look like operators in maths, which do
> not indicate an operator function.

That's only because you've become attached to this idea that operators
and operations are some how defined by their "looks".  Not so.  If
anything, it is the other way around.  The semantics come first and if
it is deemed "special enough" to call out in a certain context, a
particular distinctive symbol (and much more rarely, syntax) is
chosen.


> examples and draw general rules. In maths operators are symbols that
> essentially always have some distinguished syntatic role, and very
> often are drawn from some distinguished lexicon too.

Sorry, this is just is not true.  The following are operators on the
set of Reals and none have any "distinguished syntax".

f(x) = x^2 + pi*x^(1/3)

g(y) = y^3 + 2y*e^y

The next two do have special symbols:

x^(1/2), Square root

Sin(x)


> Mathematicians are fond of shorthands; just consider Dirac notation
> $<a|b>$, which is quite neat indeed. They might be useful in maths,
> where notational simplicity may help quite a lot.

They are not simply "shorthands".  Nor "squiggles" for squiggle's
sake.  The notations are used as a way to more easily see or (even
better) assist in seeing emergent patterns from very complex notions.
The successful ones help in this and the ones that get discarded, or
simply fade away, don't.

As you point out:

> I am not quite sure that syntactic/lexical shorthands actually help in
> programming, but most programming language designers, in the doubt,
> provide some sort of maths-like distinguished syntax for operators.

it isn't obvious that this helps a lot in programming.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Bernard Badger]

In article <330794C0.55E@concentric.net> Alan Lovejoy <alovejoy@concentric.net> writes:
   Piercarlo Grandi wrote:
   > >>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:
[...skip to Piercarlo]
   > For example in ``C'' 'sizeof' indicates a unary operator, and in
   > ``Pascal'' 'div' indicates a binary operator, and so on. ``C'' even has
   > a _ternary_ operator ('?:'), whose invocation syntax is rather
   > distinguished from that of three-argument procedures.
   > 
   > You may be a bit misled by your familiarity with ``Smalltallk'', which
   > makes it possible to use ``operator'' syntax only with symbols composed
   > of ``special' characters. But even in ``Smalltalk'' what really
   > distinguishes operators is the type of syntax they are used in, not
   > quite their appearance (even if it is that which implies the use of
   > operator-like syntax).

   Well, as you know, the only difference in the "syntax" of Smalltalk
   binary
   message sends and keyword message sends involves the form of the
   selector
   (a binary message selector must be composed of characters from a special
   lexicon, it can have no more than two characters, and unlike a keyword
   selector, it does not terminate with the ":" character).

   If "div" qualifies as an operator in Pascal on syntactical grounds
   (because 
   it does not use the "()" to bracket an argument list), why would the
   Smalltalk 
   message selector "div:" not also qualify as an operator on the same
   basis 
   (since it also does not use "()" to bracket an argument list)?
You go a bit off-track here.  Since Smalltalk doesn't use the applicative
"f()" syntax, the points about operators and "()" weren't meant to apply
to Smalltalk.  They were about other common PLs like FORTRAN, C, Pascal, Ada.
_Those_ languages _tend_ to treat functions as non-operators.  Usually this
_is_ a syntactic distinction only, which is what you are arguing against.

   Many seem to feel that any function name whose syntax matches that of
   symbols such as "+" as used in mathematical expressions is an operator,
   and that anything else is not.  Excuse me, but the only difference
   between
   such syntax and that of message selectors such as "and:" or "div:" in
   Smalltalk is the final ":" character in the function names.   That seems
   rather an insubstantial basis on which to distinguish between
   "operators" 
   and "non-operators."   Would the "div" operator in Pascal cease to
   qualify
   as an operator if its name were changed to "div:"?
[As above].

[...]
   to some well-defined math or computer science property.  For example,
   according
   to Jon Anthony, an "operator" in math should be a function of the form
   "f: A^n -> A".  That is precisely the sort of thing I was reaching for;
   the
   references to associativity, transitivity and commutativity were merely
   illustrative. And I agree that using any of those three properties as
   the
   criterion for determining what is or is not an operator in a programming
   language would be ill-advised.
Has anyone mentioned APL (Ken Iverson's A Programming Language) in this 
thread?  If I recall, APL had "operators" which transformed data and
"functors" which modified the operators.  For example "/" was a functor
which accepted a left-hand-side binary function and applied it repeatedly
("over") the right-hand-side value.  (See:  "+/a" is the sum over all elements
of vector "a".)  

   > alovejoy> Is there a useful semantic distinction between "function" and
   > alovejoy> "operator" in math?  If so, what is it?
   > 
[...]
   I don't like the idea of using syntax to define what an operator is.  
   Especially since that is not the basis for the distinction in math,
   which
   apparently uses the semantics of the function to make the distinction, 
   as I have suggested should be the case in computer science (whether we
   should use the same definition as in math is another question, however).

   And how would you use syntax to tell what is or is not an operator in 
   a visual programming language that used only icons and no lexical names?
I can't see much hope of resolution.  You'll always have languages with
slightly different notions and terminology.  Presumably a visual language
may find _some_ notion of operator and function useful and will define them
_in its own terms_.  Of course, within a _system_ that embraces many 
programming languages, you would expect ^H^H^H^H^H^H^ hope to find some 
consistency :-/

--
Bernard A. Badger	bbadger@mail.ccur.com

Re: OO, C++, and something much better!

[Richard A. O'Keefe]

Alan Lovejoy <alovejoy@concentric.net> writes:
>	An "operator" names a "built in" operation whose semantics are defined 
>	by the programming language specification.  The code emitted by the
>	compiler for an operation will either be a call to some built-in 
>	(or perhaps user-defined) function, or will be generated inline as 
>	specified by some macro function/template defined in the compiler. 
>	The compiler may emit very different code for the "same" operation,
>	depending on the context in which the operator was used (e.g., 
>	integer addition versus complex number addition).

I am left with absolutely no clue *whatsoever* about what you mean
by "operator".

When _I_ say "operator" (except in APL, which uses "operator" to mean
something rather like "higher order function"), I refer to a syntactic
property of a symbol.  This interpretation is consistent with all of the
current major languages, including Ada, BASIC, C, C++, COBOL, Fortran, 
Pascal, and even things like Matlab.  Whether a particular symbol must
be used as an operator, must be used as a `function' (the x $ y -vs-
$(x, y) distinction) or may be used as either varies from symbol to
symbol and language to language.  However, in all of the languages I
mentioned, there is ***NO SEMANTIC DIFFERENCE*** between symbols that
may be used as operators and symbols that may not.  In Ada, "abs X"
involves the use of an operator.  In Fortran, "ABS(X)" involves the
use of a "function".  But the range of *semantic* possibilities is
*identical* for both languages.  (For people who have not been keeping
up, Fortran 90 has modules, user defined data types, and overloading.)

There is a useful *syntactic* distinction between
"normal functions" f(x), g(x, y)
"operators" f x    x g y
"special syntax"  <<x>>  x[y]
but it is *only* a syntactic distinction.  In all three cases,
 - the form names a built in operation
 - whose semantics are PARTIALLY defined by the language specification
 - the generated code may call a "normal function"
 - the generated code may be in-line
 - the "same" form may result in very different code depending on context.

All of this applies to sqrt(x) and even a[i] just as much as to x+y.
And all of this applies to Smalltalk just as much as for Ada.

BY YOUR VERY OWN DEFINITION, "+" IS AN OPERATOR IN SMALLTALK.

 - "+" is built in.
 - its semantics is partially defined by the language.
 - the generated code may involve a normal method call
 - or it may involve in-line code (yes there are Smalltalks that do this)
 - the "same" form may result in very different code (again, there _are_
   Smalltalks where one instance of "+" will result in certain in-line
   code, while another results in different in-line code).

>Note that I pointed out that "+" was one of a special set of message
>selectors whose meaning was defined by the langauge.  The difference is
>that there is nothing special about the syntax of "+" (that does not
>also apply to any other binary message selector).

So how on earth is this supposed to make it _not_ an operator?
When you say there is nothing about "_" that does not also apply to any
other binary message selector, you should also point out that the set of
binary message selectors in Smalltalk is CLOSED.  There is a small fixed
set of binary message selesctors in Smalltalk and they are all written
infix.  By my criterion, they are all "operators".  By your criterion,
as shown at the beginning of this message, they are all "operators".

In Algol 68, APL, Fortran 90, Prolog, and S, the set of operators is not
closed.  Programmers can and do give symbols of their own invention
operator syntax.  In Fortran, there is nothing about "+" that does not
apply to a programmer-defined operator like '.PLUS.' except for
 - precedence
 - predefined partial semantics.
In Smalltalk, the differences are _less_.


>So?  Terminology differs from language to language.  I was trying to
>provide a definition that would be valid for most commonly-used
>langauges (which IMHO would not include Prolog, Pop or APL).

Well, it wouldn't include Smalltalk either, would it?

The definition you finally DID provide *DOES* entail that "+" warrants
the name "operator" in Smalltalk.  (Your definition also entails that
every procedure and function is an operator, but we'll ignore that.)

>I'm sorry if that doesn't fulfill the goals you'd like
>to set for the definition.  We each have our own agendas.

Yes, but YOUR agenda was supposed to be "show that + is not an operator
in Smalltalk".  You have in fact provided a definition under which
EVERY method name is an operator!

>And if ALL functions are operators, then the distinction is meaningless:
>the difference that makes no difference is not a real difference.

But "all functions are operators" is YOUR definition.
Remember that MY definition is

	whether a symbol is an operator, and if so, of what kinds,
	is a purely syntactic property.  A symbol is
	- a niladic operator if invocations are written "f"
	- a prefix monadic operator if invocations are written "f y"
	- a postfix monadic operator if invocations are written "x f"
	- an outfix monadic operator if invocations are written "f1 x f2"
	- an infix dyadic operator if invocations are written "x f y"


>> >In languages that permit "operator overloading," there will be syntactic
>> >(and usually semantic) constraints on the definition of an "operator"
>> >that would not apply to other functions.  For example, the name of an
>> >operator would have to be the same as one of the "built in" operators.
>> 
>> 6.  In Ada and C++, the only restriction on programmer overloading of
>>     infix operators is that they take two arguments.

>False:  I cannot name an operator whatever I choose.  I cannot invent
>new names, not even ones chosen from a set of legal characters.

You didn't say "operator creation", you said "operator OVERLOADING".
You can only overload something that already exists.
Your specific restrictions were arity and result type.
You were specifically WRONG about result type.

Do you actually _know_ what the rules for operator naming are in
 - Algol 68?
 - Fortran 90?
 - S?
 - APL?

If you have a method that wants two arguments (the receiver and one
other), can you give it any name you want in Smalltalk and still write
it infix?

>> To return to the specific case in point, the form
>> 
>>         X + Y
>> 
>> in Smalltalk involves
>>  - a symbol written infix between two expressions
>>  - which is drawn from a small language-defined set of symbols which
>>    can appear in that position
>>  - for which the language partially defines the semantics
>>  - to which the programmer can add additional semantics

>Yes, and the expression

>	X and: Y

>in Smalltalk involves
>   - a message selector written infix between two expressions (it's 
>     certainly not "prefix" or "postfix" or "affix")
>   - which is drawn from a small language-defined set of symbols which
>     can appear in that position (the alphanumeric characters, which is 
>     arguably a "small" set)  [WRONG]
>   - for which the language partially defines the semantics (in some
>     implementations, #and: will be a "no lookup" message if the
>     receiver is a Boolean)
>   - to which the programmer can add additional semantics

>So which one is an operator?  Neither?  Both?

Clearly, both.  Why do you have a problem with that?

Note [WRONG]  The method name "and:" is NOT drawn from the set of
alphanumeric characters.  It is drawn from the set of SEQUENCES 
beginning with a letter, etc etc etc and ending with a colon.  That
is in fact a very large set.  So the set of infix operators in Smalltalk
includes a large identifier-like set.  Well, big deal.  It's just the
same in Fortran, except that a Fortran-90 extended operator name has to
begin and end with a dot.

>I don't know.  I said in my post that "+" may be an operator, because
>it may invoke a built-in operation.  It's just not an operator for any
>syntactical reasons.  Without a definition of operator, how can this
>be decided?  I provided a definition I like (after the ammendments I
>offered due to your valid criticisms).  I have yet to see your
>definition,
>though.

By your criterion, as copied at the beginning of this message, EVERYTHING
(except perhaps, and only perhaps) literals, is an operator.
At least my definition distinguishes some things that _are_ operators
(for syntactic reasons; no other valid reasons exist) from a larger
set of things that are _not_ operators.  Your new definition here is
that something is an operator if it may invoke a built-in operation,
but then "sqrt(x)" in C involves an operator and "writeln('Foo!')' in
Pascal involves an operator and we're left with no _distinction_ between
things that are operators and things that are not.

>> You are muddling up the syntactic notion of precedence with the
>> semantic notion of evaluation order.  ...

>Really? Would you care to be more specific on how my voluminous comments
>on the nature and definition of "precedence" and "evaluation order" have
>"muddled" the two?  Are you claiming there is no relation between them,
>and that any statement that implies such a relation improperly
>"muddles" them?

See any good introductory flipping textbook.
_Precedence_ is a purely syntactic notion having to do with the way
forms are grouped in the absence of explicit bracketing.
_Evaluation order_ is a purely semantic notion having to do with
when things happen.

The connection between them is extremely weak.
For example, in S,
	x * y + z
follows the normal _precedence_ order for infix operators.
It has the same effect as
	(x * y) + z
or even
	"+"("*"(x, y), z).

However, it is a general property of S that the arguments of a function
are evaluated _after_ the function has been entered.  So in S, the
evaluation order is
	1a. evaluate "+"
	1b. ENTER "+"
	1c. depending on the implementation of +, either
	    do 2, then do 3
	    or do 3, then do 2.
	1d. depending on the types of the values of the arguments,
	    do whatever kind of "addition" is required.

	2a. evaluate "*"
	2b. depending on the implementation of *, either
	        evaluate x then evaluate y
	        or evaluate y then evaluate x
	2c. depending on the types of the values of x and y,
	    do whatever kind of "multiplication" is required
	2d. return the result.

	3.  evaluate z

In fact, it is quite possible for "+" to evaluate z first, notice that
it is NA (a special Not Available code) and immediately return NA without
evaluating x*y at all.

Again, consider C.
	x * y + z
Precedence tells us that the grouping is (( x * y ) + z ).
It also tells us that the execution of '*' will finish before the
execution of '+'.  But it tells us nothing about the evaluation
order of x, y, and z.  Their evaluation can be *arbitrarily* interleaved.

Consider the example
	X * (Y + Z)
in Fortran, which has perfectly ordinary operator precedence.
The Fortran standards have for decades been crystal clear that
"*" can notice that X is zero AND NOT EVALUATE Y+Z at all, even
though on the "precedence is evaluation order" view the "+"
"is evaluated" _before_ the "*".

If "evaluation order" means anything at all, surely it has to mean
"the order in which things are evaluated".  And operator precedence
constrains that order *VERY* weakly.

In all seriousness, this is ELEMENTARY material.


>>.. The evaluation order of overloaded
>> operators in Ada, C++, or Fortran is whatever you want it to be.

>Well, when I learned C++ in the late eighties, the precedence of
>operators was fixed, IIRC.  If the situation has changed since then (or
>my memory is faulty), then I stand corrected.

The *PREDECENCE* is fixed.
The *EVALUATION ORDER* most certainly, most deliberately, and
most explicitly in the draft standard, is not.

>I mentioned the possibility of removing "+" from the system in order to
>show that the semantics of "+" is "built in" to most Smalltalk
>implementations,
>in support of the idea that "+" may in fact be an operator in
>Smalltalk.  

This was a very odd thing, because your original claim was that
"+" is NOT an operator in Smalltalk.  Because I thought you were
still arguing that "+" is NOT an operator in Smalltalk, I necessarily
interpreted your statements about removing "+" as an argument FOR
your position.  Now you are saying that it was an argument AGAINST
your position.  Well, thanks.

>I am sorry if anyone thought I was trying to say "see, Smalltalk is
>different,

But when you say that "+" is not an operator in Smalltalk, you ARE
saying that Smalltalk is different.

>and more powerful and just all around better."  That was NOT the message
>I was trying to convey, and I am mystified why anyone would have thought
>so.

>Was it, perhaps, due to my .sig?

If you think anyone actually _read_ your .signature, you may be
flattering yourself.  I certainly didn't until now.

I've deleted a large chunk of your message without replying to it in
detail because I am finding this remarkably tedious.

My conclusion:

A.  The distinction between operator precedence and evaluation order
    is a basic one that I would expect any CS graduate to have mastered.

B.  Whether something is an operator is a purely syntactic issue.

C.  In modern languages there is _NO_ semantic distinction between
    operators and other forms, although there may be a semantic
    distinction between language-defined forms and programmer-defined
    forms.

D.  I'm sick of this thread.

-- 
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes.  --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Richard A. O'Keefe]

In article <33054E63.C2A@concentric.net> Alan Lovejoy <alovejoy@concentric.net> writes:
> Is there a useful semantic distinction between "function" and "operator" 
> in math?  If so, what is it?

jsa@alexandria (Jon S Anthony) writes:
>Generally speaking, the terms "operator" and "operation" are used to
>refer to functions which map an "n-order" set to the "base" or
>"1-order" set.

Ahem.  This is a case where APL terminology is actually quite
close to mathematics.  In APL, an operator is a higher-order operation
that takes a function as an argument and delivers another function.

In mathematics, one talks about "differential operators" and "integral
operators" and they are something that takes a function and delivers
a related function (e.g. the derivative).  Anyone who has done any
signal processing will remember the "E" (time lag) operator and the
"Delta" (difference) operator.

Here's the abstract of a subject at another university (so as not to
advertise):

	Math XXXX: Functional Analysis
	Linear metric and topological spaces, duality, weak topology,
	spaces of functions, generalised derivatives and distributions,
	Sobolev spaces, linear operators, compact operators, elements
	of spectral theory, and operator calculus.

This use of the word "operator" 
 - is pretty much standard in mathematics
 - refers to a *semantic* property rather than a *syntactic* one
 - refers to a property that "+" does not have in any major programming
   language.

-- 
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes.  --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Mike Klein]

Richard A. O'Keefe wrote:

> But "all functions are operators" is YOUR definition.
> Remember that MY definition is
> 
>         whether a symbol is an operator, and if so, of what kinds,
>         is a purely syntactic property.  A symbol is
>         - a niladic operator if invocations are written "f"
>         - a prefix monadic operator if invocations are written "f y"
>         - a postfix monadic operator if invocations are written "x f"
>         - an outfix monadic operator if invocations are written "f1 x f2"
>         - an infix dyadic operator if invocations are written "x f y"
> 

If we are not limited to linear languages,
Let us not forget upper right invisible operators like powers:  (f is
invisible)

 y
x

Lest you think this is silly, Mathematica has the invisible infix
operator, Times:

 x y
(means Times[x,y] or "x multiplies by y")

I pretty much aggree with what you say.  My stab at a definition:

operator:  The syntax for denoting an operation.

> My conclusion:
> 
> A.  The distinction between operator precedence and evaluation order
>     is a basic one that I would expect any CS graduate to have mastered.
> 
> B.  Whether something is an operator is a purely syntactic issue.
> 
> C.  In modern languages there is _NO_ semantic distinction between
>     operators and other forms, although there may be a semantic
>     distinction between language-defined forms and programmer-defined
>     forms.
> 
> D.  I'm sick of this thread.

D.  This thread reminds me of when linguists try to define the word
"word"
    For the most part, it is left as an undefined intuitive idea and
they
    use a more specific term when they need to refer to some specific
concept.

Mike Klein
-- 
mailto:mklein@alumni.caltech.edu
http://www.alumni.caltech.edu/~mklein

Re: OO, C++, and something much better!

[Mike Klein]

William Clodius wrote:
> 
> Richard A. O'Keefe wrote:
> >
> > <snip>   However, in all of the languages I
> > mentioned, there is ***NO SEMANTIC DIFFERENCE*** between symbols that
> > may be used as operators and symbols that may not.  In Ada, "abs X"
> > involves the use of an operator.  In Fortran, "ABS(X)" involves the
> > use of a "function".  But the range of *semantic* possibilities is
> > *identical* for both languages.  <snip>
> 
> Minor quibble. I believe in Fortran 90, and possibly in some of the
> other languages, operators have additional semantic constraints that are
> not required by the language for functions in general, i.e., the
> corresponding function may not have certain obvious side effects such as
> modifying its arguments, SAVEd local variables, modifying global
> variables, etc. Side effects such as stack overflow, floating point
> exceptions, etc. are of course allowed as there is no practical means of
> preventing them. (Quibble on the quibble. While Fortran allows functions
> to nominally have side effects that are not allowed for operators its
> rules for expression evaluation makes reliance on the occurance of such
> side effects error prone. Well written production Fortran code should
> ideally only have functions that satisfy the semantics of operators.)
> 
Dont we already have terms for these concepts:

imperitive (called for side effects)
functional (no side effects, return value only)

Of course, most code is dysfunctional, but that's an other story :-)

Mike Klein
-- 
mailto:mklein@alumni.caltech.edu
http://www.alumni.caltech.edu/~mklein

Re: OO, C++, and something much better!

[Mike Klein]

[SNIP]

Let us suppose one wants to reason about ints (meaning modulo 2^n
integers ala C)
in a system which actually has an implementation of integers (bignums,
or whatever).

If I see code like:

	int i,j,k;
	  ...
(1)	i = j + k;

I can choose

A)  Think of the '+' in (1) as the operation:
	(i plus j) modulo n
    where i, j, and k are mathematical integers.

or

B)  Think of the '+'  in (1) as polymorphic addition operation
    in a domain different than the integers, i.e. the group
    of modular integers 

The problem with choosing interpretation B is that operators like <
Are difficult to define in any meaningful way, let alone a way that
matches any computer implementation I know of.
	
-- 
mailto:mklein@alumni.caltech.edu
http://www.alumni.caltech.edu/~mklein

Re: OO, C++, and something much better!

[Piercarlo Grandi]

>>> "jsa" == Jon S Anthony <jsa@alexandria> writes:

jsa> In article <yf3afp4nepm.fsf@sabi.demon.co.uk>
jsa> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

alovejoy> Whether it's an operator or not should depend either on some
alovejoy> mathematical property of its semantics (e.g., it is required
alovejoy> to be associative, or transitive, or commutative, or some
alovejoy> such). [ ... ] For example, according to Jon Anthony, an
alovejoy> "operator" in math should be a function of the form "f: A^n ->
alovejoy> A".  That is precisely the sort of thing I was reaching for; [
alovejoy> ... ]

piercarl> Ahhh, but is the definition of "operator" as in ``operator
piercarl> theory''; as you write a *function* is called an "operator
piercarl> [function]" if it is of the given form. But operator functions
piercarl> and operators are quite different entities.

jsa> I think what you really want to say is simply that you don't think
jsa> the standard mathematical usage is appropriate in the context of PL
jsa> definitions.

Not at all: I don't think that the use of the word "operator" as a short
form of "operator function" is what people mean by "operator" on its own.

There in maths operator symbols that do not label operator functions;
viceversa there are operator functions that are not labeled by an
operator symbol.

I am discussing what makes a symbol into an operator symbol
(distinguished syntax and usually lexicon); Alan when a procedure should
be called an "operator", even if is name does not at all look like an
operator.

In my view 'sizeof' is an operator; he seems to be arguing that

  (lambda (x y) (+ (^ y 3) (+ 2 (* y (* e y)))))

is an operator because it computes an operator function.

jsa> Alan, OTOH, seems to think that it is a good idea to maintain some
jsa> consistency with the mathematical usage.  It's not obvious to me
jsa> which of these two views is "better".

piercarl> The discussion was really about what looks like operators. Now
piercarl> there are a lot of things that look like operators in maths,
piercarl> which do not indicate an operator function.

jsa> That's only because you've become attached to this idea that
jsa> operators and operations are some how defined by their "looks".

Well, of course, because we are discussing operaror _symbols_, not
functions or procedures. The discussion arose out of discussing "+", if
I remember well.

jsa> Not so.  If anything, it is the other way around.  The semantics
jsa> come first and if it is deemed "special enough" to call out in a
jsa> certain context, a particular distinctive symbol (and much more
jsa> rarely, syntax) is chosen.

But no! As you argue a few lines below, mathematicians use special
syntax and lexicon to label functions that are not operator functions!;
similarly in programming languages there are many operators that do not
compute operator functions, for example 'sizeof' in ``C'', or '^' in
``Smalltalk''.

piercarl> examples and draw general rules. In maths operators are
piercarl> symbols that essentially always have some distinguished
piercarl> syntatic role, and very often are drawn from some
piercarl> distinguished lexicon too.

jsa> Sorry, this is just is not true.  The following are operators on
jsa> the set of Reals and none have any "distinguished syntax".

jsa> f(x) = x^2 + pi*x^(1/3)
jsa> g(y) = y^3 + 2y*e^y

No, these are two _functions_ that belong to the set of _operator
functions_.

jsa> The next two do have special symbols:

jsa> x^(1/2), Square root
jsa> Sin(x)

piercarl> I am not quite sure that syntactic/lexical shorthands actually
piercarl> help in programming, but most programming language designers,
piercarl> in the doubt, provide some sort of maths-like distinguished
piercarl> syntax for operators.

jsa> it isn't obvious that this helps a lot in programming.

Indeed! That is *my* point. In fact I think it is unhelpful. But then
there is an opinion that programs, in particular OO programs, ``model
directly the real world'', where the ``real world'' can be maths; and
thus:

  class complex a,b,c; ....

  a = b + c;

is a very good idea, for it immediately suggests, notationally, that the
program and the ``real world'' are in such a close relationship, as they
should be.

However I don't subscribe to that point of view; to me using notation to
suggest that 'class complex' and 'the Complex plane' are in close
correspondence is not such a good idea, and not very useful in any case.

Re: OO, C++, and something much better!

[Piercarlo Grandi]

>>> "jsa" == Jon S Anthony <jsa@alexandria> writes:

jsa> In article <yf3afp4nepm.fsf@sabi.demon.co.uk>
jsa> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

alovejoy> Whether it's an operator or not should depend either on some
alovejoy> mathematical property of its semantics (e.g., it is required
alovejoy> to be associative, or transitive, or commutative, or some
alovejoy> such). [ ... ] For example, according to Jon Anthony, an
alovejoy> "operator" in math should be a function of the form "f: A^n ->
alovejoy> A".  That is precisely the sort of thing I was reaching for; [
alovejoy> ... ]

piercarl> Ahhh, but is the definition of "operator" as in ``operator
piercarl> theory''; as you write a *function* is called an "operator
piercarl> [function]" if it is of the given form. But operator functions
piercarl> and operators are quite different entities.

jsa> I think what you really want to say is simply that you don't think
jsa> the standard mathematical usage is appropriate in the context of PL
jsa> definitions.

Not at all: I don't think that the use of the word "operator" as a short
form of "operator function" is what people mean by "operator" on its own.

There in maths operator symbols that do not label operator functions;
viceversa there are operator functions that are not labeled by an
operator symbol.

I am discussing what makes a symbol into an operator symbol
(distinguished syntax and usually lexicon); Alan when a procedure should
be called an "operator", even if is name does not at all look like an
operator.

In my view 'sizeof' is an operator; he seems to be arguing that

  (lambda (x y) (+ (^ y 3) (+ 2 (* y (* e y)))))

is an operator because it computes an operator function.

jsa> Alan, OTOH, seems to think that it is a good idea to maintain some
jsa> consistency with the mathematical usage.  It's not obvious to me
jsa> which of these two views is "better".

piercarl> The discussion was really about what looks like operators. Now
piercarl> there are a lot of things that look like operators in maths,
piercarl> which do not indicate an operator function.

jsa> That's only because you've become attached to this idea that
jsa> operators and operations are some how defined by their "looks".

Well, of course, because we are discussing operaror _symbols_, not
functions or procedures. The discussion arose out of discussing "+", if
I remember well.

jsa> Not so.  If anything, it is the other way around.  The semantics
jsa> come first and if it is deemed "special enough" to call out in a
jsa> certain context, a particular distinctive symbol (and much more
jsa> rarely, syntax) is chosen.

But no! As you argue a few lines below, mathematicians use special
syntax and lexicon to label functions that are not operator functions!;
similarly in programming languages there are many operators that do not
compute operator functions, for example 'sizeof' in ``C'', or '^' in
``Smalltalk''.

piercarl> examples and draw general rules. In maths operators are
piercarl> symbols that essentially always have some distinguished
piercarl> syntatic role, and very often are drawn from some
piercarl> distinguished lexicon too.

jsa> Sorry, this is just is not true.  The following are operators on
jsa> the set of Reals and none have any "distinguished syntax".

jsa> f(x) = x^2 + pi*x^(1/3)
jsa> g(y) = y^3 + 2y*e^y

No, these are two _functions_ that belong to the set of _operator
functions_.

jsa> The next two do have special symbols:

jsa> x^(1/2), Square root
jsa> Sin(x)

piercarl> I am not quite sure that syntactic/lexical shorthands actually
piercarl> help in programming, but most programming language designers,
piercarl> in the doubt, provide some sort of maths-like distinguished
piercarl> syntax for operators.

jsa> it isn't obvious that this helps a lot in programming.

Indeed! That is *my* point. In fact I think it is unhelpful. But then
there is an opinion that programs, in particular OO programs, ``model
directly the real world'', where the ``real world'' can be maths; and
thus:

  class complex a,b,c; ....

  a = b + c;

is a very good idea, for it immediately suggests, notationally, that the
program and the ``real world'' are in such a close relationship, as they
should be.

However I don't subscribe to that point of view; to me using notation to
suggest that 'class complex' and 'the Complex plane' are in close
correspondence is not such a good idea, and not very useful in any case.

Re: OO, C++, and something much better!

[richard]

In <5eb4s4$jj5$1@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

[ - lots of stuff about operator rules in various languages snipped - ]

Excuse me, but I lost track. What the heck was this thread about in the
first place???

Greetz,

RS

Re: OO, C++, and something much better!

[Piercarlo Grandi]

>>> "jsa" == Jon S Anthony <jsa@alexandria> writes:

[ ... on the role of operators and the interpration of "+", I would say
... ]

piercarl> It was also perhaps not clear that by "maths" I meant
piercarl> something like ``ordinary maths'', a not well defined but
piercarl> hopefully intuitively perceivable notion;

jsa> And?  Presumably, by "ordinary maths" here you really mean
jsa> arithmetic.

No, telepathy does not work over the net. I meant something like ``the
sort of maths ordinary people learn at ordinary schools''. Which is
rather fuzzy notion, for reasons illustrated below.

jsa> That is a precisely and rigorously defined system.

Of course any given system of arithmetic is (hopefully) so; but the
notion of ``arithmetic'' *isn't*.

There is a large difference between a mathematical system like a
particular formalization of a particular arithmetic system and the fuzzy
notion of ``ordinary maths'', or even that of ``arithmetic''; it is a
fuzzy notion because while most probably it includes *some* sort
ofarithmetic, it may include several other things.

Consider just this: suppose one wanted to say that ``ordinary maths'' is
the maths that most people learn at school; well, different countries,
and different types of school in the same country, teach different
extensions of ``ordinary maths''. Then what type of school? High school?
College? University? And which subject? And so on.

Thus my warning that using ``familiar'' looking syntax in programming
may be dangerous: for it gives a false sense of recognition of notions
like ``addition'' that are really quite ambiguous. Some particular
notion of ``addition'' can be well defined; but perhaps ``surprisingly'':

piercarl> for most any given procedure indicated by "+" computes *some*
piercarl> mathematical function, even if not necessarily the one
piercarl> indicated by "+" in most ``ordinary maths''

jsa> Presumably you simply mean here that "computer arithmetic" or the
jsa> specification of arithmetic operations in a programming language
jsa> definition is not the same as standard arithmetic (even though in
jsa> many practical cases you can ignore the differences). Well, sure.

Well, sure, but the important thing is that in many practical cases one
*cannot* ignore the differences, not that in others one *can*, for it
when one cannot that problems arise.

Also, in order to be able to ignore the differences (and many do,
without realizing it), a non trivial amount of analysis (for example
range analysis) may have to be performed. Particularly horrid subtleties
happen with the various ways that ``real'' numbers are approximated.

Again, to me it may well be misleading to use for programming a notation
that resembles that of ``ordinary maths'', for it induces in the
innocent some terrible assumptions, some of which are even true, like
yours "in many practical cases you can ignore the differences". Yeah,
but it's dangerous not to check that this is the case, and notational
similarity can mislead on how often this can be done.

This impinges on OO: 'class Complex' should perhaps bear a prominent
sticker saying "Warning: use of instances of this class as if they were
complex numbers can be hazardous to your health".

piercarl> (one favourite example is that "+" between 'unsigned' operands
piercarl> in ``C'' computes the function ``addition module 2^N'' rather
piercarl> than addition on nonnegative numbers).

jsa> Why is congruential arithmetic not ordinary?

Get real! I doubt that for example the average MBA or the average
medical doctor would consider congruential arithmetic ``ordinary'', even
if they may well agree that it has a precise definition and theory, if
they have heard it exists. Even the average PhD in geography (a subject
that is not totally devoid of maths courses like history would be) may
not be that familiar with congruential arithmetic.

jsa> Note that this too has a completely precise and rigorous definition
jsa> and theory.

Again, there is a difference between a rigorous definition and theory of
any particular mathematical subject, and the notion of ``ordinariness'',
congruential arithmetic, however precisely and rogorously defined in any
particular incarnation, is normally known only to those that have
studied fairly ``advanced'' maths at university

Also, if one looks at two "congruential arithmetic" chapters in two
relevant texbooks, their scope will be rather different. The notion of
``congruential arithmetics'' is rather fuzzy itself, for there are
_many_ possible "completely precise and rigorous definition and theory."
of it.

piercarl> by "+" in some branch of maths would tend to be few; one major
piercarl> factor is that procedures usually compute functions over
piercarl> finite domains/codomains, which is almost never the case in
piercarl> [``ordinary''] maths, and even in ``discrete'' maths.

jsa> What makes you say that??  Certainly any congruence system has this
jsa> exact aspect.  Large chunks of combinatorics deal in finite
jsa> systems.  What about finite groups?  And whose to say that in "day
jsa> to day arithmetic" you aren't dealing with a congruence system
jsa> whose modulus just happens to be 10^50 or something?

Ah sure, you would expect the average college or university graduate,
``ordinary'' people that contend with ``ordinary maths'', deal
day-to-day in combinatorics, finite groups, arithmetic mod 10^50, and so
on, for example when figuring out their taxes or planning next year's
budget for their practice. :-).

piercarl> At times, BTW, I am not so sure that is such a good idea, for
piercarl> while the function computed by the "+" procedure usually
piercarl> somewhat resembles the function indicated by "+" in maths, the
piercarl> details (and vital ones) are as a rule grotesquely different
piercarl> (just consider addition of 'real's and of 'R'eals).

jsa> Again - it depends on context.
jsa> There are cases where the two will denote identical results.

piercarl> Well, this is actually quite impossible as literally written
piercarl> :-); the results of any particular "+" operation are in the
piercarl> domain of implementation entities, those of any articular "+"
piercarl> function are in the domain of mathematical entities.

jsa> Yes, I see the "smiley", but I'm not sure this distinction is true
jsa> or of any use.

It is indeed very useful; for ``computational'' entities
and``mathematical'' entities have really intrinsically different
properties. The notation may be the same, the syntax even, but one
forgetting that ``maths'' and ``computing'' are very different things
leads to overoptimism and eventually (pretty quickly) mistakes.

Learning to avoid such an attitude is for example one of the first
things that numerical analysts have to do. I remember a famous paper
that explains various ways to write a good program that finds, if any,
the two real roots of a 2nd order equation; it is absolutely nontrivial,

jsa> It would seem to imply that any set of "squiggles" on a blackboard
jsa> or piece of paper are "implementation entities" and have not much
jsa> to do with the mathematical entities they represent.  I don't think
jsa> so...

Well, let's say that "not much to do" is an unfair caricature of what I
have written. They are related; the relationship may even be
straighforward; but they are rather different things with rather
different properties.

piercarl> What you probably wanted to say is that it can happen that the
piercarl> function computed by some particular "+" operation is exactly
piercarl> the same as that meant by some "+" function in ``ordinary''
piercarl> maths.

jsa> What I meant was that you can't distinguish the two in any
jsa> meaningful way even if they are "in some sense different".

I hope you don'tq really mean this, for this is quite gross!

If you mean it, well, an aversion at distinguishing different sorts of
entities, mathematical and computational entities, for example, can be
be quickly remedied by reading any sort of nice introductory textbook, I
would suggest "Structure and Interpretation of computer programs".

[ ... some agreeable agreements deleted, to avoid offending News
tradition :-) :-) :-) ... ]

Re: OO, C++, and something much better!

[Piercarlo Grandi]

>>> "jsa" == Jon S Anthony <jsa@alexandria> writes:

jsa> In article <yf3914o33ne.fsf@sabi.demon.co.uk>
jsa> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

piercarl> But then mathematicians invent notation all the time; they
piercarl> even have suffix operator (e.g. "!" for factorial) or "around"
piercarl> operators (like "||" for absolute value) and many more types
piercarl> beside. The common thing is not quite that they use
piercarl> non-alphabetic symbols, but that they don't use applicative
piercarl> syntax like 'f(....,....)';

jsa> ??? Mathematicians use the function "syntax" all the time.  It's
jsa> probably one of the single _most_ used notations.

I was writing of when they invent operator notation; when they design
operators, they often, but not always use non-alphabetic symbols, but
they usually use syntax (infix, postfix, prefix, ``around'', ...) that
is different from applicative syntax.

piercarl> consider for examples of alphabetic operators commonly used in
piercarl> maths things like the 'lim' unary operator notation,

jsa> How do you figure that "lim" is a unary operator???

Well, I distinguish it from non-operators because it does not involve
applicative syntax; it involves brief, ``special'' syntax, even if it
is not composed of special characters. As to ``unary'', well, this is
arguable; one could argue that it is a family of unary operators,
actually, where:

jsa> Depending on context it is a function of at least three arguments
jsa> (independent variable, the "limit", and a function)

variable and limit ``specialize'' the operator ("unary operator
notation", for example: lim  ), or that it is really a ternary operator
			x->oo

that is typographically laid out (usually) to resemble a unary operator.

If you want more obvious examples; just consider 'sin', which is often
written in operator notation: $y = sin x$, as well as function notation:
$y = sin(x)$. Same goes for "log", which is a unary operator, I would
say even when it is specialized by a base appended to it, as in log  x.
                                                                  10

jsa> and may well a) not even have a value and b) even if it does, it
jsa> may not be in the range of the function argument.  Actually, in
jsa> mathematical parlence "lim" is not even an operator.

Of course it is -- if one looks at how it is written in most textbooks,
'lim' does not look like a function application. Now, my argument is
here a bit circular; but what is an operator *symbol*, and here we have
been discussion these, and not the functions/procedures they label, is
usually evident by visual inspection. Let me insist: this usually
reveals that there is a default syntax (applicative, affix, whatever)
for functions/procedures, and there is a distinguished, usually briefer,
syntax for operator symbol, which are also often, but not necessarily,
drawn from a distinguished lexicon.

Re: OO, C++, and something much better!

[William Clodius]

Richard A. O'Keefe wrote:
> 
> <snip>   However, in all of the languages I
> mentioned, there is ***NO SEMANTIC DIFFERENCE*** between symbols that
> may be used as operators and symbols that may not.  In Ada, "abs X"
> involves the use of an operator.  In Fortran, "ABS(X)" involves the
> use of a "function".  But the range of *semantic* possibilities is
> *identical* for both languages.  <snip>

Minor quibble. I believe in Fortran 90, and possibly in some of the
other languages, operators have additional semantic constraints that are
not required by the language for functions in general, i.e., the
corresponding function may not have certain obvious side effects such as
modifying its arguments, SAVEd local variables, modifying global
variables, etc. Side effects such as stack overflow, floating point
exceptions, etc. are of course allowed as there is no practical means of
preventing them. (Quibble on the quibble. While Fortran allows functions
to nominally have side effects that are not allowed for operators its
rules for expression evaluation makes reliance on the occurance of such
side effects error prone. Well written production Fortran code should
ideally only have functions that satisfy the semantics of operators.)

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: OO, C++, and something much better!

[Matt Kennel]

Richard A. O'Keefe (ok@goanna.cs.rmit.edu.au) wrote:
: Here's the abstract of a subject at another university (so as not to
: advertise):

: 	Math XXXX: Functional Analysis
: 	Linear metric and topological spaces, duality, weak topology,
: 	spaces of functions, generalised derivatives and distributions,
: 	Sobolev spaces, linear operators, compact operators, elements
: 	of spectral theory, and operator calculus.

: This use of the word "operator" 
:  - is pretty much standard in mathematics
:  - refers to a *semantic* property rather than a *syntactic* one
:  - refers to a property that "+" does not have in any major programming
:    language.

Thank you.  I too feel the grating of my auditory cortex upon hearing
descriptions of "+" as an ''operator'' in programming languages, and sigh upon
sadly seeing such use enshrined in say, C++ syntax.  What's wrong with
"infix procedure"?  (And I have a certain fondness for good old "subroutine",
a clear and descriptive neologism sadly supplanted by fussy indeterminacies
like 'method' 'procedure' or occasionally misleading 'function'.) 

Now that I'm doing quantum mechanics again, it becomes even worse, because
questions like "do these operators commute or not" have entirely
incommensurate connotations.

I can understand how other words such as 'matrix' end up with quite unrelated
meanings in medicine and mathematics, but in programming languages, the
designers really should have known better.

Even more irritating is the frightful abuse of the word "Vector", which 
quite foolishly has come to mean 'array-style containers'. 

\begin{james_earl_jones}
  ``If this is a consular ship, then *where* is the Vector Space?  ...
    Tear this library apart until you've found the group structure, and
    bring me the designers, I want them alive!''
\end{james_earl_jones} 
: -- 

--
Matthew B. Kennel/Institute for Nonlinear Science, UCSD/
       Where do you want to go today? 
''Don't bother answering.  We're abducting you.''

Re: OO, C++, and something much better!

[Anders Pytte]

In article <5einvs$i0l@news1.ucsd.edu>, kennel@lyapunov.ucsd.edu (Matt
Kennel) wrote:

> Richard A. O'Keefe (ok@goanna.cs.rmit.edu.au) wrote:
> : Here's the abstract of a subject at another university (so as not to
> : advertise):
> 
> :       Math XXXX: Functional Analysis
> :       Linear metric and topological spaces, duality, weak topology,
> :       spaces of functions, generalised derivatives and distributions,
> :       Sobolev spaces, linear operators, compact operators, elements
> :       of spectral theory, and operator calculus.
> 
> : This use of the word "operator" 
> :  - is pretty much standard in mathematics
> :  - refers to a *semantic* property rather than a *syntactic* one
> :  - refers to a property that "+" does not have in any major programming
> :    language.
> 
> Thank you.  I too feel the grating of my auditory cortex upon hearing
> descriptions of "+" as an ''operator'' in programming languages, and sigh upon
> sadly seeing such use enshrined in say, C++ syntax.  What's wrong with
> "infix procedure"?  (And I have a certain fondness for good old "subroutine",
> a clear and descriptive neologism sadly supplanted by fussy indeterminacies
> like 'method' 'procedure' or occasionally misleading 'function'.) 
> 
> Now that I'm doing quantum mechanics again, it becomes even worse, because
> questions like "do these operators commute or not" have entirely
> incommensurate connotations.
> 
> I can understand how other words such as 'matrix' end up with quite unrelated
> meanings in medicine and mathematics, but in programming languages, the
> designers really should have known better.
> 
> Even more irritating is the frightful abuse of the word "Vector", which 
> quite foolishly has come to mean 'array-style containers'. 
> 
> \begin{james_earl_jones}
>   ``If this is a consular ship, then *where* is the Vector Space?  ...
>     Tear this library apart until you've found the group structure, and
>     bring me the designers, I want them alive!''
> \end{james_earl_jones} 
> : -- 
> 


Well, I advocate a balance between formality and fluidity in language. As
I said before, all of these words (including infix and vector) had
meanings before they were ever used in restrictive context of mathematics.
Since all your favorite mathematical terms are the result of "word
fetching" (Robert Frost), that is, using existing words in a new way to
express novel ideas, through anaology, it hardly seems fair to frown upon
the continuation of that practice.

Anders.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.com

Re: What is wrong with OO ?

[Nick Leaton]

> Nick Leaton wrote:
> >
> > richard@highrise.nl wrote:
> > >
> > > Virtual functions are also a kind of documentation. When declaring a
> > > function virtual, the programmer is more or less saying "go ahead,
> > > override this function if you like."
> >
> > The decision to make a function virtual assumes a knowledge of what
> > users of your class are going to do. It akin to predicting the future.
> 
> No. If it make sense to override, make it virtual; if it doesn't,
> don't make it virtual.

I think you might have missed the start of the thread. If you buy third
party libraries, you don't always get source. With no source, you cannot
make the function virtual.

-- 

Nick

Re: What is wrong with OO ?

[Nick Leaton]

Valentin Bonnard wrote:
> 
> Nick Leaton wrote:
> >
> > richard@highrise.nl wrote:
> > >
> > > Virtual functions are also a kind of documentation. When declaring a
> > > function virtual, the programmer is more or less saying "go ahead,
> > > override this function if you like."
> >
> > The decision to make a function virtual assumes a knowledge of what
> > users of your class are going to do. It akin to predicting the future.
> 
> No. If it make sense to override, make it virtual; if it doesn't,
> don't make it virtual.

If you can forsee the future!

> > One of the problems with C++ is this very point. Should you, as a
> > designer of a class restrict what someone else does with your class?
> 
> Yes; even the fact that you have private members restrict what
> can be done with your class; does it mean that you should
> only use public data members (ie expose all your implementation
> details) ?

We are only talking about classes that inherit, not classes that
use. Why shouldn't a class that inherits another get access to 
implementation details?

> > If you provide the class to someone else without source code, and they
> > find a bug. One solution to fixing the bug is to produce a new class
> > that inherits the original, and redefines the offending routine. However
> > your decision about declaring or not declaring the routine virtual in
> > the first place affects what can be done.
> 
> You don't inherit from a class to fix it in C++ (nor to reuse it);
> you specialize it. You don't patch a class like you apply a diff
> file to a system to patch it !

OK, Microsoft release a duff library with a duff class. You
have no source. Will Microsoft give you the source? No. You
have to inherit and overide. It is ugly, it is not ideal, but 
you have no choice.

> [For Mac programmers: overriding != SetTrapAddress]
> 
> One must never forget that inheritance is not the only way to
> use a class; composition is often the only sensible way.
> 
> If there is a bug in one member function in a class, then if
> you don't have the source code it's difficult to be sure
> that the cause of this bug (or a similar bug) is not in
> another function.
> 
> Even if you are sure that you only need to correct one
> function, public [normal] inherintance is not the way to go.
> 
> You might use private inheritance and redefine the buggy
> function:
> 
> class BuggyClass {
> public:
>     void BuggyFunction (); // need not to be virtual
>     void OtherFunction ();
> };
> 
> class CorrectedClass : private BuggyClass {
> public:
>     void BuggyFunction ();
>     using OtherFunction;
> };
> 
> void CorrectedClass::BuggyFunction ()
> {
>     // corrected function
> }

It won't work. A user that has a pointer to a BuggyClass, which
is an instance of CorrectedClass. The user calls ptr->BuggyFunction()
The buggy code will be run, not the CorrectedClass::BuggyFunction.
However if BuggyFunction is declared as virtual, it will work.

> With private inheritance it's not possible (except for
> CorrectedClass members) to convert a CorrectedClass to
> a BuggyClass; it means that only CorrectedClass know that
> CorrectedClass IS-A BuggyClass.
> 
> You can also use composition by reimplementing all the
> functions of BuggyClass; all these implementation just
> call the corresponding function in BuggyClass; only
> BuggyFunction is really rewritten.

This won't work. The corrected class will not inherit BuggyClass,
and so cannot be reffered to using a pointer to its base class.

> And anyway I feel that's a very special case. You
> should ask the BuggyClass writer to correct its class.

Agreed. But you have to be realistic. Lets say Microsoft release some
buggy code. Nothing suprising there. How long are you prepared to
wait for them to fix the code?


> Valentin Bonnard
> mailto:bonnardv@pratique.fr
> http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)

-- 

Nick

Re: OO, C++, and something much better!

[Brian Rogoff]

On 21 Feb 1997, Eric W. Nikitin wrote:
> Chris Bitmead (Chris.Bitmead@Alcatel.com.au) wrote:
> : Not true. There are other definitions of type.
> : 
> : For example, in some languages we could have a "ball" class and a
> : "cat" class, both of which respond to the message "kick", yet there is
> : no explicit "kickable" class.
> 
> In languages like Oberon-2 ( and I am fairly certain like Ada as well ),
> these concerns are modeled by separate language constructs. Encapsulation
> is provided by modules, structure comes from the type mechanism, and 
> behavior is described by dynamically-bound procedures. 
> 
> A language derived from Oberon, Lagoona, goes on to provide an additional
> feature called categories which are distinct from type, but allow 
> different types to be related via similar behaviors. ( Categories
> are similar to protocals in Objective-C and interfaces in Java ).

	Something similar to this is provided in Ada by using generic 
packages with empty bodies. For example

generic
	type Item is private;
	procedure Kick( X : in out Item );
package Kickable_Sig is
end;

with the canonical example being a mathematical group

generic
     type Element is private;
     Identity: in Element;
     with function Op(X, Y: Element) return Element;     
     with function Inverse(X: Element) return Element;  
package Group is end;

Note that the programmer need not have provided a procedure named "Kick" 
for Cat or Ball, any procedure with the specified signature will do in the 
instantiation:

package Kickable_Ball is new Kickable_sig(Element => Soccer_Ball,
Kick => Soccer_Kick);

-- Brian

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <yf34tf9csjy.fsf@sabi.demon.co.uk> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

> >>> "jsa" == Jon S Anthony <jsa@alexandria> writes:
> 
> [ ... on the role of operators and the interpration of "+", I would say
> ... ]
> 
> piercarl> It was also perhaps not clear that by "maths" I meant
> piercarl> something like ``ordinary maths'', a not well defined but
> piercarl> hopefully intuitively perceivable notion;
> 
> jsa> And?  Presumably, by "ordinary maths" here you really mean
> jsa> arithmetic.
> 
> No, telepathy does not work over the net. I meant something like ``the
> sort of maths ordinary people learn at ordinary schools''. Which is
> rather fuzzy notion, for reasons illustrated below.

It's not fuzzy at all.  It's simply completely irrelevant.


> jsa> That is a precisely and rigorously defined system.
> 
> Of course any given system of arithmetic is (hopefully) so; but the
> notion of ``arithmetic'' *isn't*.

Really?  I don't believe you at all.  The notion of arithmetic _is_
precisely defined.  What's more, when it is taught, wherever it is
taught, it will conform to the formal notion.  This isn't like CS/PL
land where you can get all warm and fuzzy and start saying "Hey, I
mean thus and such by arithemtic and my opinion is as good as anyone
elses."  You're opinion either a) matches up or b) you have some
stunningly interesting reason why it shouldn't or c) (the most likely
by far) your opinion is rubbish.


> There is a large difference between a mathematical system like a
> particular formalization of a particular arithmetic system and the fuzzy
> notion of ``ordinary maths'', or even that of ``arithmetic''; it is a
> fuzzy notion because while most probably it includes *some* sort
> ofarithmetic, it may include several other things.

Really?  Like what?  Give one example of "ordinary" "maths" that isn't
either a) EXACTLY what is meant in the formal sense or b) a slightly
_confused_ notion which on reflection will turn out to be the same as
a formal sense.


> Consider just this: suppose one wanted to say that ``ordinary maths'' is
> the maths that most people learn at school; well, different countries,
> and different types of school in the same country, teach different
> extensions of ``ordinary maths''. Then what type of school? High school?
> College? University? And which subject? And so on.

What's that have to do with it???  This is REALLY confused.  In all of
those cases, whatever is taught in the class will still conform to the
particular part of the formal definitions.  What's more, even the
_notation_ used will be extremely close.  You're whole notion of
"ordinary maths" here is completely silly.  It is really simply: some
people may learn different pieces of mathematics in different places
and different times.  So what?  In the context at hand, who cares?
What possible relevance could this have???


> Thus my warning that using ``familiar'' looking syntax in programming
> may be dangerous: for it gives a false sense of recognition of notions
> like ``addition'' that are really quite ambiguous. Some particular
> notion of ``addition'' can be well defined; but perhaps ``surprisingly'':

You're warning here may have some merit, but it _in no way whatsoever_
has anything to do with "ordinary arithmetic" being ill defined or
something and it _certainly_ does not follow.


> jsa> Presumably you simply mean here that "computer arithmetic" or the
> jsa> specification of arithmetic operations in a programming language
> jsa> definition is not the same as standard arithmetic (even though in
> jsa> many practical cases you can ignore the differences). Well, sure.
> 
> Well, sure, but the important thing is that in many practical cases one
> *cannot* ignore the differences, not that in others one *can*, for it
> when one cannot that problems arise.

Shrug.


> Also, in order to be able to ignore the differences (and many do,
> without realizing it), a non trivial amount of analysis (for example
> range analysis) may have to be performed. Particularly horrid subtleties
> happen with the various ways that ``real'' numbers are approximated.

So?  This is true no matter what the representation system and no
matter what the process for calculating, when you want actual
numerical answers.  You have the same sort of issue even if you are
using paper and pencil.  You're not being very convincing here.


> piercarl> (one favourite example is that "+" between 'unsigned' operands
> piercarl> in ``C'' computes the function ``addition module 2^N'' rather
> piercarl> than addition on nonnegative numbers).
> 
> jsa> Why is congruential arithmetic not ordinary?
> 
> Get real! I doubt that for example the average MBA or the average
> medical doctor would consider congruential arithmetic ``ordinary'', even

Ever use a clock?  Tell time?  Besides, given your definition of what
counts as "ordinary" as what happens to be taught somewhere at some
point to some people, congruential arthmetic could fit perfectly.


> that is not totally devoid of maths courses like history would be) may
> not be that familiar with congruential arithmetic.

So, now no one but PhDs in mathematics can tell time?


> Again, there is a difference between a rigorous definition and theory of
> any particular mathematical subject, and the notion of ``ordinariness'',

Again, I think you are confused.


> Also, if one looks at two "congruential arithmetic" chapters in two
> relevant texbooks, their scope will be rather different. The notion of
> ``congruential arithmetics'' is rather fuzzy itself, for there are
> _many_ possible "completely precise and rigorous definition and theory."
> of it.

First, where the scopes overlap, they will be in accord.  This isn't
opinion, my friend.  Second, all your supposedly different "theories"
will in fact be equivalent.  One derivable from the other.  Do you
really think you can just sit there and decide, "Hey, *I'm* going to
come up with my own theory of congruence and it isn't going to be like
the accepted one because *I* know better"?  OK, sure if you're Gauss
or something, but otherwise, you'd be better off sticking with
fiddling with programming language design.


> day-to-day in combinatorics, finite groups, arithmetic mod 10^50, and so
> on, for example when figuring out their taxes or planning next year's
> budget for their practice. :-).

OK, show me how you would even be able to _tell_ one way or the other
that someone was or wasn't using a congruence system with modulus
10^50 when doing his or her taxes.  That's the point.  For some reason
you have _assumed_ something about what people are doing in your so
called "ordinary" and you actually have no justification for doing
this.


> piercarl> Well, this is actually quite impossible as literally written
> piercarl> :-); the results of any particular "+" operation are in the
> 
> jsa> Yes, I see the "smiley", but I'm not sure this distinction is true
> jsa> or of any use.
> 
> It is indeed very useful; for ``computational'' entities

Well, now you'r just being a Platonist when it comes to "mathematical
entities" and you are again showing a lot of presupposition with no
justification.


> and``mathematical'' entities have really intrinsically different
> properties. The notation may be the same, the syntax even, but one
> forgetting that ``maths'' and ``computing'' are very different things
> leads to overoptimism and eventually (pretty quickly) mistakes.

You realize of course that numerical analysis is a branch of applied
mathematics don't you?



> jsa> It would seem to imply that any set of "squiggles" on a blackboard
> jsa> or piece of paper are "implementation entities" and have not much
> jsa> to do with the mathematical entities they represent.  I don't think
> jsa> so...
> 
> Well, let's say that "not much to do" is an unfair caricature of what I
> have written. They are related; the relationship may even be
> straighforward; but they are rather different things with rather
> different properties.

Well, I think the big problem here is that you are uncritically
presuming the truth of a Platonic view of mathematical entities.  This
is anything but obvious.  And a number of great mathematicians would
simply disagree with you.


> jsa> What I meant was that you can't distinguish the two in any
> jsa> meaningful way even if they are "in some sense different".
> 
> I hope you don'tq really mean this, for this is quite gross!

Of course I mean this - it's TRUE for crying out loud.  There are
cases where you can't distinguish in any meaningful way.


> If you mean it, well, an aversion at distinguishing different sorts of
> entities, mathematical and computational entities, for example, can be
> be quickly remedied by reading any sort of nice introductory textbook, I
> would suggest "Structure and Interpretation of computer programs".

Well, I would suggest that you pick up a text or two on the
foundations of mathematics before you start spouting this sort of
silly stuff.  Get a clue.  Show me how you can distinguish between the
answers you would get from a computer when computing in a congruence
system with modulus 16 or 10 and what you'd expect from the same
"operations" in the "mathematical version".


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Chris Bitmead]

In article <rmartin-2801971303450001@pool11-019.wwa.com> rmartin@oma.com (Robert C. Martin) writes:

>This statement is oxymoronic.  A type is defined by the interfaces it
>accepts.  There is no other definition of a type.  Thus, the statement 
>above could be translated as follows:

Not true. There are other definitions of type.

For example, in some languages we could have a "ball" class and a
"cat" class, both of which respond to the message "kick", yet there is
no explicit "kickable" class.

So, while you might argue that conceptually there is a "kickable"
type, nobody does this in practice, because it could lead to an order
of magnitude increase in the number of "types" identified in a system.

-- 
---------------------------------------------------------------
| Chris Bitmead.....................................9690 5727 |
| Chris.Bitmead@Alcatel.com.au............................... |
---------------------------------------------------------------
The fact that it works is immaterial.
                -- L. Ogborn

Re: OO, C++, and something much better!

[Eric W. Nikitin]

Chris Bitmead (Chris.Bitmead@Alcatel.com.au) wrote:
: In article <rmartin-2801971303450001@pool11-019.wwa.com> rmartin@oma.com 
: (Robert C. Martin) writes:
: 
: >This statement is oxymoronic.  A type is defined by the interfaces it
: >accepts.  There is no other definition of a type.  Thus, the statement 
: >above could be translated as follows:
: 
: Not true. There are other definitions of type.
: 
: For example, in some languages we could have a "ball" class and a
: "cat" class, both of which respond to the message "kick", yet there is
: no explicit "kickable" class.

The "problem" here is that in languages like C++, the class construct
provides:
	- a mechanism for encapsulation
	- an object's structure
	- an object's behavior 

In languages like Oberon-2 ( and I am fairly certain like Ada as well ),
these concerns are modeled by separate language constructs. Encapsulation
is provided by modules, structure comes from the type mechanism, and 
behavior is described by dynamically-bound procedures. 

A language derived from Oberon, Lagoona, goes on to provide an additional
feature called categories which are distinct from type, but allow 
different types to be related via similar behaviors. ( Categories
are similar to protocals in Objective-C and interfaces in Java ).

A cat has a very different structure from a ball. And yet, if I am in
the mood to kick something, and am not particular about what I am
willing to kick... each could be a member of the category "kickable".

Class is a broader term than type. From _The Annotated C++ Reference
Manual_ (c) 1990, classes contain "a sequence of objects of various
types, a set of functions for manipulating these objects, and a set
of restrictions on the access to these objects and functions".

: So, while you might argue that conceptually there is a "kickable"
: type, nobody does this in practice, because it could lead to an order
: of magnitude increase in the number of "types" identified in a system.

It depends. If "kickable" is a useful abstraction, then it should be
modeled.
-- 
Eric
---
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Those who know that they are profound strive for clarity. Those who 
   would like to seem profound to the crowd strive for obscurity.
   He is a thinker; that means, he knows how to make things simpler 
   than they are...
	- Friedrich Nietzsche 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: What is wrong with OO ?

[Fergus Henderson]

Nick Leaton <nickle@calfp.co.uk> writes:

>Valentin Bonnard wrote:
>> 
>> Nick Leaton wrote:
>> >
>> > richard@highrise.nl wrote:
>> > >
>> > > Virtual functions are also a kind of documentation. When declaring a
>> > > function virtual, the programmer is more or less saying "go ahead,
>> > > override this function if you like."
>> >
>> > The decision to make a function virtual assumes a knowledge of what
>> > users of your class are going to do. It akin to predicting the future.
>> 
>> No. If it make sense to override, make it virtual; if it doesn't,
>> don't make it virtual.
>
>If you can forsee the future!

It's not about forseeing the future, it's about programming by contract
and making appropriate design decisions.

>We are only talking about classes that inherit, not classes that
>use. Why shouldn't a class that inherits another get access to 
>implementation details?

Because those implementation details may change!

>OK, Microsoft release a duff library with a duff class. You
>have no source. Will Microsoft give you the source? No. You
>have to inherit and overide. It is ugly, it is not ideal, but 
>you have no choice.

That is a perfect example of why you should *not* do this,
because if you do, then Microsoft will screw you when they
release the next version.  In the next version, they will
have declared what you thought was a bug to be a feature,
and they will have lots of code that depends on it.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <yf33eutcrc8.fsf@sabi.demon.co.uk> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

> >>> "jsa" == Jon S Anthony <jsa@alexandria> writes:

> piercarl> beside. The common thing is not quite that they use
> piercarl> non-alphabetic symbols, but that they don't use applicative
> piercarl> syntax like 'f(....,....)';
> 
> jsa> ??? Mathematicians use the function "syntax" all the time.  It's
> jsa> probably one of the single _most_ used notations.
> 
> I was writing of when they invent operator notation; when they design
> operators, they often, but not always use non-alphabetic symbols, but
> they usually use syntax (infix, postfix, prefix, ``around'', ...) that
> is different from applicative syntax.

What do you mean "often"?  Where are you coming up with this stuff?
The major problem you are having here is _exactly_ what Alan was
getting at: You (for reasons that are beyond comprehension) seem to
think that operators are defined by _syntax_.  Well, in mathematics,
THEY AREN'T!  And until you get this straight you are going to
continue to be confused.


> piercarl> consider for examples of alphabetic operators commonly used in
> piercarl> maths things like the 'lim' unary operator notation,
> 
> jsa> How do you figure that "lim" is a unary operator???
> 
> Well, I distinguish it from non-operators because it does not involve
> applicative syntax; it involves brief, ``special'' syntax, even if it
> is not composed of special characters.

I (and the rest of mathematics) don't _care_ about your _opinion_ here
about why you think it's an operator.  Syntax is IRRELEVANT!


> As to ``unary'', well, this is arguable; one could argue that it is
> a family of unary operators, actually, where:

No, you can't argue that.  In fact, it is hilarious to even suggest
it.  You're just wrong.  This isn't _opinion_.  And besides, since
when is a "family of unary operators" a unary operator?


> jsa> Depending on context it is a function of at least three arguments
> jsa> (independent variable, the "limit", and a function)
> 
> variable and limit ``specialize'' the operator ("unary operator

This is ridiculous.  Forget "specialize" or whatever.  That's _not_
how it is defined.


> or that it is really a ternary operator

It's not a ternary operator either, because it is not an operator,
because it is not taking a some A^n -> A.


> If you want more obvious examples; just consider 'sin', which is often
> written in operator notation: $y = sin x$, as well as function notation:
> $y = sin(x)$. Same goes for "log", which is a unary operator, I would

Well, at least here you really have a couple of operators.


> jsa> and may well a) not even have a value and b) even if it does, it
> jsa> may not be in the range of the function argument.  Actually, in
> jsa> mathematical parlence "lim" is not even an operator.
> 
> Of course it is -- if one looks at how it is written in most textbooks,
> 'lim' does not look like a function application. Now, my argument is

Will you get a clue???  No.  It is not an operator.  Syntax is
irrelevant to this determination.  What makes you think for even a
fempto second that just because _you_ think "operation" in mathematics
should be defined by "syntax" mathematicians should change the
_actual_ definition, toss out a century or so of practice, etc???  You
really can't be serious.  This is absolutely laughable!

It's actually a whole set of functions (one for each limit)

Let F = Set of functions on R
let S = R union {"undefined", oo, -oo}
let a = limit point

lim-a: FxRx{a} -> S


> but what is an operator *symbol*,

WHO CARES!!!

> usually evident by visual inspection. Let me insist: this usually

You can insist alll you want.  Doesn't mean a damn thing.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <5eb4s4$jj5$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

> There is a useful *syntactic* distinction between
             ^^^^^^
> "normal functions" f(x), g(x, y)
> "operators" f x    x g y
> "special syntax"  <<x>>  x[y]

I'm not convinced.  Pleasant perhaps, but really useful?  In what way?


> >Note that I pointed out that "+" was one of a special set of message
> >selectors whose meaning was defined by the langauge.  The difference is
> >that there is nothing special about the syntax of "+" (that does not
> >also apply to any other binary message selector).
> 
> So how on earth is this supposed to make it _not_ an operator?

Simple.  For Alan the term "operator" should be distinguished by its
semantic.  In particular, that there is something "special" about its
semantic.  Syntax would be irrelevant.  Whether he is correct about
this wrt Smalltalk is irrelevant.

OTOH, as you point out (and as Piercarlo has attempted to point out in
a sea of confusions) the use of the term in PL land definitely _has_
become associated with _syntactical_ specialness and no amount of
wishing otherwise is going to do Alan any good.  Just like, no amount
of weird wishing on the part of Piercarlo is going to make
mathematicians start thinking that they should (as he seems to want)
drop the semantic distinguishing of "operator" and "operation" as a
special case of functions.  His wish makes Alan's look positively
reasonable.


> >And if ALL functions are operators, then the distinction is meaningless:
> >the difference that makes no difference is not a real difference.
> 
> But "all functions are operators" is YOUR definition.
> Remember that MY definition is

I think he really wants to go the other way around: operators are a
proper subset of functions and this is based on a _semantic_ trait not
a syntactical trait.  Of course his "definition" may have blown it, I
don't really recall what it was.  Actually, I don't think he ever
clearly said what he thought this semantic trait should be.

> I've deleted a large chunk of your message without replying to it in
> detail because I am finding this remarkably tedious.

Yes, I can agree with this.  The whole problem revolves around the
fact that people have a presupposed notion of what they think the
_kind_ of distinguishing trait of an opertor is.


> D.  I'm sick of this thread.

Can't disagree with that! :-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <5eb5jt$kl7$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

> jsa@alexandria (Jon S Anthony) writes:
> >Generally speaking, the terms "operator" and "operation" are used to
> >refer to functions which map an "n-order" set to the "base" or
> >"1-order" set.
> 
> Ahem.  This is a case where APL terminology is actually quite
> close to mathematics.  In APL, an operator is a higher-order operation
> that takes a function as an argument and delivers another function.

Yup, that fits exactly.

> In mathematics, one talks about "differential operators" and "integral
> operators" and they are something that takes a function and delivers
> a related function (e.g. the derivative).

Yes, exactly.  A very standard example would be the usual case of

 Cf = set of continuous functions on R

 ': Cf -> Cf, where f' is the derivative of f


> This use of the word "operator" 
>  - is pretty much standard in mathematics
>  - refers to a *semantic* property rather than a *syntactic* one
>  - refers to a property that "+" does not have in any major programming
>    language.

Absolutely spot on accurate.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <5einvs$i0l@news1.ucsd.edu> kennel@lyapunov.ucsd.edu (Matt Kennel) writes:

> : This use of the word "operator" 
> :  - is pretty much standard in mathematics
> :  - refers to a *semantic* property rather than a *syntactic* one
> :  - refers to a property that "+" does not have in any major programming
> :    language.

> Thank you.  I too feel the grating of my auditory cortex upon
> hearing descriptions of "+" as an ''operator'' in programming
> languages, and sigh upon sadly seeing such use enshrined in say, C++
> syntax.

Well, being a mathematician, I too can understand where you're coming
from.  But, OTOH, I don't think it is a big deal to use the term in a
different way in PL/CS land - as long as it is at least consistent.
Which, unfortunately at this point in time, it isn't.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <yf3ybclbavi.fsf@sabi.demon.co.uk> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

> jsa> I think what you really want to say is simply that you don't think
> jsa> the standard mathematical usage is appropriate in the context of PL
> jsa> definitions.
> 
> Not at all: I don't think that the use of the word "operator" as a short
> form of "operator function" is what people mean by "operator" on its own.

What people?  Where's the evidence?  Certainly in mathematics it is
_common_ practice to use the word "operator" as short for "operation"
(aka, your "operator function").


> There in maths operator symbols that do not label operator functions;
> viceversa there are operator functions that are not labeled by an
> operator symbol.

So what?  You are all hung up on syntax and glyphs.  Glyphs _can_ be
important - no doubt about it.  But that importance does not extend to
the _definition_ of the concept involved.


> I am discussing what makes a symbol into an operator symbol
> (distinguished syntax and usually lexicon); Alan when a procedure
> should be called an "operator", even if is name does not at all look
> like an operator.

So?  None of this conflicts with what I said: you don't want to use
the standard mathematical definition in PL/CS land.  Fine.  And
mathematicians don't want to use your goofy definition based on syntax
and glyphs.


> In my view 'sizeof' is an operator; he seems to be arguing that
> 
>   (lambda (x y) (+ (^ y 3) (+ 2 (* y (* e y)))))
> 
> is an operator because it computes an operator function.

I can't speak for him, but I don't think you have this even close to
right.  No one is talking about functors.


> jsa> That's only because you've become attached to this idea that
> jsa> operators and operations are some how defined by their "looks".
> 
> Well, of course, because we are discussing operaror _symbols_, not
> functions or procedures. The discussion arose out of discussing "+", if
> I remember well.

What do you mean "of course"??  And of course we are discussing _both_
because if we weren't there would be nothing to say.


> jsa> Not so.  If anything, it is the other way around.  The semantics
> jsa> come first and if it is deemed "special enough" to call out in a
> jsa> certain context, a particular distinctive symbol (and much more
> jsa> rarely, syntax) is chosen.
> 
> But no! As you argue a few lines below, mathematicians use special

But yes.  That is exactly how it happens in mathematics.

> syntax and lexicon to label functions that are not operator functions!;

Sure.  So what?


> piercarl> examples and draw general rules. In maths operators are
> piercarl> symbols that essentially always have some distinguished
> piercarl> syntatic role, and very often are drawn from some
> piercarl> distinguished lexicon too.
> 
> jsa> Sorry, this is just is not true.  The following are operators on
> jsa> the set of Reals and none have any "distinguished syntax".
> 
> jsa> f(x) = x^2 + pi*x^(1/3)
> jsa> g(y) = y^3 + 2y*e^y
> 
> No, these are two _functions_ that belong to the set of _operator
> functions_.

What do you mean, "no"?  How is your characterization different than
saying they are operations, i.e., functions which are operators?  Or
are you complaining about the fact that I used the term "operator" to
refer to the operation (and not the glyphs)?  In this particular
context that would really be too much.


> piercarl> I am not quite sure that syntactic/lexical shorthands actually
> piercarl> help in programming, but most programming language designers,
> piercarl> in the doubt, provide some sort of maths-like distinguished
> piercarl> syntax for operators.
> 
> jsa> it isn't obvious that this helps a lot in programming.
> 
> Indeed! That is *my* point. In fact I think it is unhelpful. But then

Fine.  IMO, this is not very interesting.


> there is an opinion that programs, in particular OO programs, ``model
> directly the real world'', where the ``real world'' can be maths; and

So?  Depending on what you mean by "model" this might be true or it
might be simply confused.  Certainly OO people are more confused than
not.  But I don't think that has a lot to do with the glyphs being
used and the syntax for combining them.


> However I don't subscribe to that point of view; to me using
> notation to suggest that 'class complex' and 'the Complex plane' are
> in close correspondence is not such a good idea, and not very useful
> in any case.

The notation has nothing to do with it.  That problem is a semantic
problem - not a syntax problem.  People can (and do) confuse a concept
of a thing for the thing, confuse a word with its meaning, etc., etc.
None of this has to do with syntax and glyphs.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Brian Rogoff]

On 24 Feb 1997, Jon S Anthony wrote:

> In article <Pine.SGI.3.95.970221115143.12989C-100000@shellx.best.com> Brian Rogoff <bpr@best.com> writes:
> 
> > On 21 Feb 1997, Eric W. Nikitin wrote:
> > > A language derived from Oberon, Lagoona, goes on to provide an additional
> > > feature called categories which are distinct from type, but allow 
> > > different types to be related via similar behaviors. ( Categories
> > > are similar to protocals in Objective-C and interfaces in Java ).
> > 
> > 	Something similar to this is provided in Ada by using generic 
> > packages with empty bodies. For example
> 
> Isn't this Lagoona category aspect basically the same as Class in Ada?
> A family of related types?
> 
> /Jon

	I can't say for sure, since I don't know Lagoona, and I don't know 
what a Lagoona "category" is. I looked at what it was being used for, and 
thought that it vaguely resembled an ML "signature", which I would
translate into Ada using a null bodied generic package. 

	"Category" is becoming one of those terms like "operator". I know 
the term from abstract algebra, but software folk use it in at least three
ways:

(1) The Lagoona way, new to me, and I still don't get it. Any Lagoona 
    users care to help? 
(2) The way I know (and love), from abstract algebra (any number of books
    discuss this, the one by Hilton&Wu is where I learned it)
(3) The Booch method uses the term for (in essence) Ada packages or C++ 
    namespaces (Robert Martin's book is my favorite source for this stuff,
    even though I prefer Ada to C++).   

-- Brian

Re: OO, C++, and something much better!

[Piercarlo Grandi]

>>> "jsa" == Jon S Anthony <jsa@alexandria> writes:

jsa> In article <yf34tf9csjy.fsf@sabi.demon.co.uk>
jsa> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

>> >>> "jsa" == Jon S Anthony <jsa@alexandria> writes:

>> [ ... on the role of operators and the interpration of "+", I would say
>> ... ]

piercarl> It was also perhaps not clear that by "maths" I meant
piercarl> something like ``ordinary maths'', a not well defined but
piercarl> hopefully intuitively perceivable notion;

jsa> And?  Presumably, by "ordinary maths" here you really mean
jsa> arithmetic.

piercarl> No, telepathy does not work over the net. I meant something
piercarl> like ``the sort of maths ordinary people learn at ordinary
piercarl> schools''. Which is rather fuzzy notion, for reasons
piercarl> illustrated below.

jsa> It's not fuzzy at all.  It's simply completely irrelevant.

....

jsa> That is a precisely and rigorously defined system.

piercarl> Of course any given system of arithmetic is (hopefully) so;
piercarl> but the notion of ``arithmetic'' *isn't*.

jsa> Really?  I don't believe you at all.  The notion of arithmetic _is_
jsa> precisely defined.  What's more, when it is taught, wherever it is
jsa> taught, it will conform to the formal notion.

Hahahahahahah! Perhaps a little familiarity with beginner level (primary
school) level textbooks would help.

What different people/educational systems call arithmetic varies widely;
even the status of arithmetic is didfferent according to different
mathematicians; to some it is the foundation of all mathematics, to some
it is founded on set theory.

Some people define ``numbers'' as primitive concepts; some people define
them as the cardinality of some set; others as other things. There are
_many_ different formal theories of arithmetic, and it makes no sense to
speak of "the formal notion" as if the word "arithmetic" always mean the
same thing, and there were a single theory of arithmetic.

Similarly, the word "operator" is used to mean different things in
different concepts; in the context of operator theory it indicates a
certain type of function, in the context of notation is indicates a
certain type of symbols. The question then is whether or how to relate
the two distinct uses of the word "operator"...

jsa> This isn't like CS/PL land where you can get all warm and fuzzy and
jsa> start saying "Hey, I mean thus and such by arithemtic and my
jsa> opinion is as good as anyone elses."  You're opinion either a)
jsa> matches up or b) you have some stunningly interesting reason why it
jsa> shouldn't or c) (the most likely by far) your opinion is rubbish.

If you are so sure, please provide evidence that the term "arithmetic"
has been used by all mathematicians to means exactly the same formal
system for the past say fifty years or so.

piercarl> There is a large difference between a mathematical system like
piercarl> a particular formalization of a particular arithmetic system
piercarl> and the fuzzy notion of ``ordinary maths'', or even that of
piercarl> ``arithmetic''; it is a fuzzy notion because while most
piercarl> probably it includes *some* sort ofarithmetic, it may include
piercarl> several other things.

jsa> Really?  Like what?  Give one example of "ordinary" "maths" that
jsa> isn't either a) EXACTLY what is meant in the formal sense or b) a
jsa> slightly _confused_ notion which on reflection will turn out to be
jsa> the same as a formal sense.

Please provide a formal theory of the meaning of term "ordinary maths"
first, as you insist that it is a formally defined notion that is unique
as when you write "the formal sense".

piercarl> Consider just this: suppose one wanted to say that ``ordinary
piercarl> maths'' is the maths that most people learn at school; well,
piercarl> different countries, and different types of school in the same
piercarl> country, teach different extensions of ``ordinary
piercarl> maths''. Then what type of school? High school?  College?
piercarl> University? And which subject? And so on.

jsa> What's that have to do with it???  This is REALLY confused.  In all
jsa> of those cases, whatever is taught in the class will still conform
jsa> to the particular part of the formal definitions.

Which one?

jsa> What's more, even the _notation_ used will be extremely close.

Hahahaha! Have you have read more than one (or even just one) maths
textbooks? The notation is often _radically_ different, especially in
different countries, and often for rather profound reasons. I have seen
maths texbooks from different countries, and there are different
operators symbols to indicate even super-ordinary operations like
division, even in books from the same country. There are often, as it is
inevitable, many notational similarities, and even much overlap in what
is discussed (usually the biggest difference is in *how* it is
discussed). Mathematicians do invent notation all the time, and do mean
different things by the same words.

jsa> You're whole notion of "ordinary maths" here is completely silly.
jsa> It is really simply: some people may learn different pieces of
jsa> mathematics in different places and different times.

jsa> So what?  In the context at hand, who cares?  What possible
jsa> relevance could this have???

Well, it has an enormous :-) importance: that your idea that the notion
of "ordinary maths" has one formal meaning ("THE formal sense", emphasis
mine) is entirely bogus.

In the present context it matters, because it is you argument that the
word "operator", in the one and only formal system of mathematics you
claim is used by everybody, is only used to label a type of function
rather than a type of symbol.

My argument is that there is wide diversity of mathematical lingos,
notations, theories, even they are mostly related, and that the word
"operator" commonly labels a type of symbols, while it indicates a type
of functions only if in the context of discussions on operator theory.

From this recognition of wide diversity of approaches in ``maths'', and
in ``computing'' for that matter, I also derive a warning about using
similar notation to indicate rather different entities, such as
mathematical and computational entities, which are never identical, and
often only approximately related:

piercarl> Thus my warning that using ``familiar'' looking syntax in programming
piercarl> may be dangerous: for it gives a false sense of recognition of
piercarl> notions like ``addition'' that are really quite ambiguous. Some
piercarl> particular notion of ``addition'' can be well defined; but perhaps
piercarl> ``surprisingly'':

jsa> You're warning here may have some merit, but it _in no way
jsa> whatsoever_ has anything to do with "ordinary arithmetic" being ill
jsa> defined or something and it _certainly_ does not follow.

Here you are misrepresenting my contention: it has never been that
"ordinary arithmetic" (I have _never_ used this term as you seem to
quote it, but this is minor quibble) is "ill defined", as you make it
up; but that the very _notion_ of what is meant by "ordinary maths" is
ambiguous, and as far as I can see operator theory is no at all part of
it, for it is only studied as such in advanced level courses at
university; still people speak of mathematical operators, and they mean
some of the symbols used in mathematical notation, not the technical
meaning of the term as used in operator theory etc.

My warning has the merit of pointing out that certain operator symbols
are ``ordinarily'' assosciated with certain functions, and that in
``ordinary'' programming languages they label procedures that compute
rather different functions, and this _may_ fool the unwary, those that
cannot appreciate that the string "a + b" may have radically different
meanings in different domains of discourse.

piercarl> Also, in order to be able to ignore the differences (and many
piercarl> do, without realizing it), a non trivial amount of analysis
piercarl> (for example range analysis) may have to be
piercarl> performed. Particularly horrid subtleties happen with the
piercarl> various ways that ``real'' numbers are approximated.

jsa> So?  This is true no matter what the representation system and no
jsa> matter what the process for calculating, when you want actual
jsa> numerical answers.  You have the same sort of issue even if you are
jsa> using paper and pencil.  You're not being very convincing here.

Stating what should be obvious is not very convincing?

piercarl> (one favourite example is that "+" between 'unsigned' operands
piercarl> in ``C'' computes the function ``addition module 2^N'' rather
piercarl> than addition on nonnegative numbers).

jsa> Why is congruential arithmetic not ordinary?

piercarl> Get real! I doubt that for example the average MBA or the
piercarl> average medical doctor would consider congruential arithmetic
piercarl> ``ordinary'', even

jsa> Ever use a clock?  Tell time?

You don't need an MBA to know that you usually must sell
things for more than you bought them for, or a PhD in chemistry to
understand that oil and water don't mix well...

Your statement is based on a confusion between a rather narrow
application of congruential arithmetic, which is taught in ad hoc way to
kids, with the notion and theory of congruential arithmetic, which is
hardly ever taught except to people attending university level degrees
in ``maths''; such confusion is not that suprising: people who are not
familiar with "maths" often make such confusions; probably your curious
idea that "arithmetic" is a term that has exactly one meaning, which is
defined formally in the same way by every author ("the formal sense") is
also due to the same sort of confusion.

jsa> Besides, given your definition of what counts as "ordinary" as what
jsa> happens to be taught somewhere at some point to some people,
jsa> congruential arthmetic could fit perfectly.

Here you are misrepresenting again what I write: I wrote "ordinary
people" and "ordinary schools", not "some point" and "some people". Some
people get taught at some point congruential arithmetic, or for that
matter things like interval arithmetic or Riemann manifolds or other
curious things, that does not make them ``ordinary''.

piercarl> that is not totally devoid of maths courses like history would
piercarl> be) may not be that familiar with congruential arithmetic.

jsa> So, now no one but PhDs in mathematics can tell time?

I guess this confusion between applications of a theory with the theory
is a good demonstration of what is ridiculous about your suggestion that
(as I understand it) the only admissible use of the word "operator" in
``maths'' is the narrow one used in operator theory to indicate a
particular type of function, and not of symbol.

piercarl> Again, there is a difference between a rigorous definition and
piercarl> theory of any particular mathematical subject, and the notion
piercarl> of ``ordinariness'',

jsa> Again, I think you are confused.

Well, consider addition: ordinary people would be suprised to learn that
adding 1 to 65536 gives may not give 65536 as a result.

piercarl> Also, if one looks at two "congruential arithmetic" chapters
piercarl> in two relevant texbooks, their scope will be rather
piercarl> different. The notion of ``congruential arithmetics'' is
piercarl> rather fuzzy itself, for there are _many_ possible "completely
piercarl> precise and rigorous definition and theory."  of it.

jsa> First, where the scopes overlap, they will be in accord.  This isn't
jsa> opinion, my friend.

But I am not quite sure I want be friends with people that display such
a poor understanding of the understanding of the difference between the
meaning of a term and the formalization of one particular meaning of
that term, and that insistenlty misrepresent what I say, this time by
innuendo:

jsa> Second, all your supposedly different "theories" will in fact be
jsa> equivalent.  One derivable from the other.  Do you really think you
jsa> can just sit there and decide, "Hey, *I'm* going to come up with my
jsa> own theory of congruence and it isn't going to be like the accepted
jsa> one because *I* know better"?  OK, sure if you're Gauss or
jsa> something, but otherwise, you'd be better off sticking with
jsa> fiddling with programming language design.

I have never ever claimed, as you insinuate, that all those different
theories, of different scopes, are in fact non-equivalent to some
(usually large) degree; as I written clearly, and as you ignore, my only
point is the obvious one that the meaning of the words "congruential
arithmetic" is different depending on the author that uses it.

piercarl> day-to-day in combinatorics, finite groups, arithmetic mod
piercarl> 10^50, and so on, for example when figuring out their taxes or
piercarl> planning next year's budget for their practice. :-).

jsa> OK, show me how you would even be able to _tell_ one way or the
jsa> other that someone was or wasn't using a congruence system with
jsa> modulus 10^50 when doing his or her taxes.  That's the point.  For
jsa> some reason you have _assumed_ something about what people are
jsa> doing in your so called "ordinary" and you actually have no
jsa> justification for doing this.

You are again misrepresenting what I have written, for I have assumed
nothing of the sort. I have stated that ordinary people don't even know
that congruential artihmetic exists, not that they cannot use some
aspects of it without realizing it. It's a bit like Moliere's character
that discovered he had written all his life in prose...

piercarl> Well, this is actually quite impossible as literally written
piercarl> :-); the results of any particular "+" operation are in the

jsa> Yes, I see the "smiley", but I'm not sure this distinction is true
jsa> or of any use.

piercarl> It is indeed very useful; for ``computational'' entities

jsa> Well, now you'r just being a Platonist when it comes to "mathematical
jsa> entities" and you are again showing a lot of presupposition with no
jsa> justification.

No, I have done nothing of the sort, as you assume and imply once again;
I have just shown you a feat of an ability that people versed in
mathematics posses, the ability to distinguish entities at different
levels of abastraction. Such an ability does not imply, as you amazingly
suggest, a belief in the ``reality'' of such distinct entities, as
Platonism would have it, simply that they do not belong to the same
level of discourse:

piercarl> and``mathematical'' entities have really intrinsically
piercarl> different properties. The notation may be the same, the syntax
piercarl> even, but one forgetting that ``maths'' and ``computing'' are
piercarl> very different things leads to overoptimism and eventually
piercarl> (pretty quickly) mistakes.

jsa> You realize of course that numerical analysis is a branch of applied
jsa> mathematics don't you?

If you say so... Some people think that it is a branch of applied
computing (computing applied to ``maths''); for some incredibly silly
reason the ACM for example publishes journals devoted to numerical
analysis. Of course it may be fair to regard it as a combination of
maths and computing, whatever that means.

Some people even believe (quite correctly) that the whole of computing
is a branch of applied maths (applied intensional logic). Different
people look upon the terms "maths" and "computing" as having rather
different meanings, and big battles have been though by foundationists
on this subject.

jsa> It would seem to imply that any set of "squiggles" on a blackboard
jsa> or piece of paper are "implementation entities" and have not much
jsa> to do with the mathematical entities they represent.  I don't think
jsa> so...

piercarl> Well, let's say that "not much to do" is an unfair caricature
piercarl> of what nI have written. They are related; the relationship may
piercarl> even be straighforward; but they are rather different things
piercarl> with rather different properties.

jsa> Well, I think the big problem here is that you are uncritically
jsa> presuming the truth of a Platonic view of mathematical entities.
jsa> This is anything but obvious.  And a number of great mathematicians
jsa> would simply disagree with you.

But I have said nothing of the sort -- you are again, making it entirely
up for I have written nothing of the sort, implying something that I
have not meant.

Whether one believes in some sort of independent ``existence'' of
mathematical entities, as ``Platonism'' would have, is a rather
different question from mathemtical entities (say functions) and
computational ones (say procedures) being distinct, and having very
different properties _by construction_. The procedure described by:

  sqr(unsigned u) { return u * u; }

and the function described by:

  x^2 mod 2^N : (x * x) mod 2^N

are related, but they are very different sort of things _by
construction_, not in force of any ``Platonic'' philosophical attitude
as to their reality.

jsa> What I meant was that you can't distinguish the two in any
jsa> meaningful way even if they are "in some sense different".

piercarl> I hope you don't really mean this, for this is quite gross!

jsa> Of course I mean this - it's TRUE for crying out loud.  There are
jsa> cases where you can't distinguish in any meaningful way.

First of all you have rather crassly changed your argument here: you
have stated first that it is impossible to disntiguish the two things;
then that there are some cases in which it impossible. But it does not
matter: they can _always_ be distinguished meaningfully, and very much
so.

piercarl> If you mean it, well, an aversion at distinguishing different
piercarl> sorts of entities, mathematical and computational entities,
piercarl> for example, can be be quickly remedied by reading any sort of
piercarl> nice introductory textbook, I would suggest "Structure and
piercarl> Interpretation of computer programs".

jsa> Well, I would suggest that you pick up a text or two on the
jsa> foundations of mathematics before you start spouting this sort of
jsa> silly stuff.  Get a clue.

Your abysmal ignorance of the simple distinction between a mathematical
entity (say a function) and a computational one (say a procedure) is
appalling. There are whole books devoted to such a relationship, which
is often extremely complex, and in no case one of identity;
computational entities denote/represent mathematical entities, and they
are on _different levels of discourse_, and thus can/must be
distinguished in some very meaningful way.

But much of your arguments seems based on ignoring the distinction
between levels of discourse/abstraction; previously you have based a
number of inanities you have written on ignoring that the meaning of a
word like "arithmetic" is not formally defined in a unique way, even if
some particular theory of arithmetic is, thus demonstrating ignorance of
the distinction between words and the concepts they label.

Then here you demonstrate gross ignorance of the difference between a
number, an abstract entity defined in the theory of mathematics, and its
representation in a computer or on a screen or on a printout:

jsa> Show me how you can distinguish between the answers you would get
jsa> from a computer when computing in a congruence system with modulus
jsa> 16 or 10 and what you'd expect from the same "operations" in the
jsa> "mathematical version".

But they are not the same operations; even beginners are taught that a
computer cannot deal with any sort of mathematical entities like
functions or numbers, only with their repesentations, for example
procedures that compute functions. Such representations have very
different properties from the mathematical entities they actually
represent, and they often represent mathematical entities rather
different from the ``ordinary'' ones they _look like_ representing.

And even primary school kids, at least in the country I was educated in,
is taught that the representation of a number (say a numeral, like the
one represented by the "3" glyph that you see now on your screen) is not
the same thing as a number; that mathematical entities and their
representations in the computational domain can always be dinstuiguished
easily, even if one denotes the other in some model of computation.

You also seem to ignore that the ability to distinguish between levels
of abstraction, between an entity and a representation of that entity,
is not ``Platonism'': it is a basic concept of maths, and it is true _by
construction_, not because of an assumption about the reality of
mathematical ideas, as Platonism would have it.

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <Pine.SGI.3.95.970221115143.12989C-100000@shellx.best.com> Brian Rogoff <bpr@best.com> writes:

> On 21 Feb 1997, Eric W. Nikitin wrote:
> > A language derived from Oberon, Lagoona, goes on to provide an additional
> > feature called categories which are distinct from type, but allow 
> > different types to be related via similar behaviors. ( Categories
> > are similar to protocals in Objective-C and interfaces in Java ).
> 
> 	Something similar to this is provided in Ada by using generic 
> packages with empty bodies. For example

Isn't this Lagoona category aspect basically the same as Class in Ada?
A family of related types?

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <JSA.97Feb21195346@alexandria> jsa@alexandria (Jon S Anthony) writes:

I wrote the following utter rubbish:

>  Cf = set of continuous functions on R
> 
>  ': Cf -> Cf, where f' is the derivative of f

Total _obvious_ BS.  The canonical counter example: |x|.  Fortunately
Brian Rogoff was nice enough to hit me in the head a couple of times
in order to, shall we say, realign my thinking with my saying.

What I was actually thinking was:

   ': Df -> Cf, f' = derivative of f, Df = differentiable functions (*)

Of course, in this context, ' is no longer an operator, so its a bad
example anyway.


I suppose the "right" example here would have been:

   I : Cf -> Cf, I(f) = anti derivative of f with constant c (aka
                        indefinite integral)

This is basically a quick corollary of the FTC.

  proof: since f is continuous, by the FTC, f has an anti
  derivative F with constant term c, i.e., F' = f, so F is obviously
  differentiable => F is continous.


(*) Which claims: if f is differentiable (at a) then f' is continuous
    (at a)

For those who are now wisely skeptical,

proof:

    f'(a+h) = lim  [f((a+h)+k) - f(a+h)]/k
              k->0

   lim  f'(a+h) = lim  lim [f((a+h)+k) - f(a+h)]/k
   h->0           h->0 k->0

                = lim  [lim f((a+k)+h) - lim f(a+h)]/k
                  k->0  h->0             h->0

   since f is differentiable, f is continuous and by f's continuity
   the above is

                lim  [f(a+k) - f(a)]/k
                k->0

                = f'(a)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Richard A. O'Keefe]

jsa@alexandria (Jon S Anthony) writes:

>In article <5eb4s4$jj5$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

>> There is a useful *syntactic* distinction between
>             ^^^^^^
>> "normal functions" f(x), g(x, y)
>> "operators" f x    x g y
>> "special syntax"  <<x>>  x[y]

>I'm not convinced.  Pleasant perhaps, but really useful?  In what way?

What I wrote was ambiguous.
I did not mean that it was useful to _have_ the distinction.
What I meant was that since the distinction has been 
imposed on us, it is useful to have a way of _talking_ about it.

For example, if someone wants to know why the compiler doesn't like
	function +(Left, Right: Group_Element) return Group_Element is ...
then it is handy to be able to say "+ is an operator, so you'll have to
quote it".  Any other word might have done just as well, but "operator"
is the traditional word in programming.

None of the well known programming languages even begins to come close
to using "operator" in anything approximating a mathematical sense.

>> So how on earth is this supposed to make it _not_ an operator?

>Simple.  For Alan the term "operator" should be distinguished by its
>semantic.

Yes, but he has completely failed to come up with a "semantic" that
distinguishes "+" from anything else.

The fundamental point here is that programming languages exist, and we
need ways to talk about them clearly.  It doesn't do anyone any good
to go "whaa, *I* wanna call + a subroutine" or anything like that.
It doesn't even do any good to say "whaa, _mathematicians_ say xyz",
because (a) mathematical usage is by no means uniform, and (b) programming
languages are a different domain of discourse, and the re-use of words
in different domains is a standard feature of English.

Let me cite Burris & Sankappanavar, "A Course in Universal Algebra".
Ch II, Definition 1.1, p23.
	For $A$ a nonempty set and $n$ a nonnegative integer we define
	$A^0 = {\phi}$, and, for $n > 0$, $A^n$ is the set of $n$-tuples
	of elements from $A$.  An $n$-{\it ary operation\/}
	(or {\it function\/) {\it on} $A$ is any function $f$ from
	$A^n$ to $A$; $n$ is the {\it arity} (or {\it rank\/}) of $f$.
	\dots  An operation $f$ on $A$ is called a {\it nullary} operation
	\dots if its arity is zero.  \dots  An operation $f$ on $A$ is
	{\it unary}, {\it binary}, or {\it ternary} if its arity is 1, 2,
	or 3, respectively.

Someone incorrectly claimed that the mathematical word for these things
was "operator".  It is in fact "operation".  I think we can all agree
that "+" is an _operation_ in any reasonable programming language (or
an overloaded family of operations).

I cannot find a definition of "operator" in that book, but on pp60ff it
uses "operator" to refer to a mapping from classes of algebras to
classes of algebras.

Well, if we used _that_ notion of "operator" in programming languages,
only the ML programmers would have anything to talk about.  (And _they_
already call the things "functors".)

Programming languages are a _different_ domain of discourse and we need
a precise way of talking about them.

The C standard defines "operator" (in section 6.1.5) to be the
_syntactic_ notion "one of [ ] ( ) . -> ++ ... + ... ##".  We may like
or dislike this, but the fact remains that when talking about C, 
"operator" is a well-defined _syntactic_ notion.

I'm reading this thread in comp.lang.ada.  The Annotated Ada95 standard says,
in section 4.5 (imagine ellipses almost everywhere):
	1   The language defines the following six categories of operators...
	    The corresponding operator symbols, and only those, can be used
	    as designators in declarations of functions for user-defined
	    operators.  See 6.6, ``Overloading of Operators''.
                                   Syntax
	2   logical operator
	3   relational operator
	4   binary adding operator
	5   unary adding operator
	6   multiplying operator
	7   highest precedence operator
One again, whether you like it or not, this _is_ the standard terminology
for talking about Ada.

The old ISO Pascal standard, 7185, defines four classes of "operators"
in section 6.7.2:
	relational-operator
	adding-operator
	multiplying-operator
	not
The current Pascal standard, 10206, defines five classes of "operators"
in section 6.8.1.  In addition, it distinguishes the comparison _function_
LT (and its relatives) from the relational _operator_ < (and its relatives).
Again, like it or not, if you want to talk precisely about Pascal, you use
the terminology in ISO 10206.

The point that I am making is simply that there is an established word
"operator" used consistently in the standards for many current programming
languages to refer to a small set of built in operatIONS with special
syntax.  This isn't _intended_ to conform to any advanced mathematical
usage.

You may _regret_ the use of the word "operator" for a *syntactic*
category in programming language standards, but it is humptydumptyism
to try to pretend that it isn't so.

-- 
limits on the scope of cooperation are often due to the inability
to recognise the identity or the acts of the other playes.  --R.Axelrod
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Eric W. Nikitin]

Hello!

Brian Rogoff (bpr@best.com) wrote:
>        I can't say for sure, since I don't know Lagoona, and I don't know
> what a Lagoona "category" is. 

An excellent paper on Lagoona is available at,

     http://www.ics.uci.edu/~franz/Lagoona-ics-tr-96-40.ps

> I looked at what it was being used for, and
> thought that it vaguely resembled an ML "signature", which I would
> translate into Ada using a null bodied generic package.
 
I don't know Ada very well, and ML not at all, so I can't really comment
on similarities.

>        "Category" is becoming one of those terms like "operator". I know
> the term from abstract algebra, but software folk use it in at least three
> ways:

It's been way too long since I've studied abstract algebra for me to
relate the term category to it - but why must a term used by "software
folk" have a basis in mathematics? What's wrong with relations to
ordinary English usage?

As far as I can tell, the term category is used in Lagoona because of 
its relationship to the much more overused word "class". From 
Merriman-Webster (WWWebster Dictionary), 

Class
[snip other defns]

   3 : a group, set, or kind sharing common attributes: 

[snip the rest as well]

Category
   1 : any of several fundamental and distinct classes to which 
       entities or concepts belong
   2 : a division within a system of classification 

I'd say 1) relates fairly well to Lagoona's usage of the term, and 
seems to me to be more appropriate than the above defn of class.

> (1) The Lagoona way, new to me, and I still don't get it. Any Lagoona
>    users care to help?

The only thing I can suggest is to read the aforementioned paper. It
describes the differences between specialization and combination 
relationships, and, as I said in my previous post, how these relate 
to structural and behavioral commonalities. ( This paper helped with 
my understanding of Java interfaces, so it is worth reading even 
disregarding the Lagoona aspect ).

Hope this helps :)
-- 
Eric
---
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   _Common Sense_ does not mean that good sense which is common, or commonly 
   needed in the ordinary affairs of life, but the sense which is common to 
   all the five, or the point where the five senses  meet, supposed to be 
   the seat of the soul, where it judges what is presented by the senses, 
   and decides the mode of action. 
	-- The Dictionary of Phrase and Fable 
	-- http://www.bibliomania.com/Reference/PhraseAndFable/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <vwjybcd2794.fsf@cassin.dcs.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:

<<Piercarlo says a _lot_ of stuff.  Some of it more or less sensible,
some of it utter rubbish, most of it uninteresting or otherwise empty
of content.>>

> discussed). Mathematicians do invent notation all the time, and do mean
> different things by the same words.

So what?  I already pointed this out several posts ago.

> Well, it has an enormous :-) importance: that your idea that the notion
> of "ordinary maths" has one formal meaning ("THE formal sense", emphasis
> mine) is entirely bogus.

_Your_ "ordinary maths" is ill defined and uninteresting.


> In the present context it matters, because it is you argument that the
> word "operator", in the one and only formal system of mathematics you

Who said anything about only one formal system of mathematics?  Can
you read?  In basically any context, the notion of "operation" is
defined by its semantic and any "syntax" is completely irrelevant.
Different notations are used all over the place but an operation is an
operation because of its semantic - not any glyph that might be used
for it.  Anyone with even a passing familiarity of mathematics knows
this.


> "operator" commonly labels a type of symbols, while it indicates a type
> of functions only if in the context of discussions on operator theory.

Wrong.  Just completely wrong.  Get a clue.  Let's see here.  I have
MacLane's, _Catagories for the Working Mathematician_; Enderton's _A
Mathematical Introduction to Logic_, and Herstein's _Topics in
Algebra_ sitting here handy.  Looking in each of them I see that _all_
of them define an operator as a function f:A^n->A.  Nond of these is
concerned with operator theory.  You are just plain wrong.

Now, what I'd like to know is _why_ in the face of a mountain of
evidence to the contrary, you still _insist_ that _your_ view of what
"operator" means in mathematics is right.  That it is "defined by
syntax or glyphs".  Do you have an inferiority complex or what?


> Some people even believe (quite correctly) that the whole of computing
> is a branch of applied maths (applied intensional logic). Different

Wow.  Here we actually agree.


> Your abysmal ignorance of the simple distinction between a mathematical
> entity (say a function) and a computational one (say a procedure) is
> appalling. There are whole books devoted to such a relationship, which
> is often extremely complex, and in no case one of identity;


Ahem.  You actually seem to know something about PL design based on
some of your past posts.  But, your abysmal ignorance of mathematics
is appalling when it is coupled with your bizarre wanna be ranting.
Nothing you say in all these rambling rants adds up to one iota of
originality; nothing in them is insightful or even remotely
interesting.  They might be reasonable for a student in a first course
in mathematical foundations or logic or maybe philosophy of
language/mathematics.  But when you add to them your laughable
arrogance you just end up looking like a fool here.

Now, I don't claim to know all there is to know about the foundations
of mathematics.  Not by a long shot.  Not even in my wildest fantasies
of intellectual prowess.  But I spent several years working in the
area and it is what I wrote my thesis in.  So, neither am I clueless
here.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <Pine.SGI.3.95.970224163110.19651B-100000@shellx.best.com> Brian Rogoff <bpr@best.com> writes:

> 	"Category" is becoming one of those terms like "operator". I know 
> the term from abstract algebra, but software folk use it in at least three
> ways:

Right.  Head for the hills!!


> (2) The way I know (and love), from abstract algebra (any number of books
>     discuss this, the one by Hilton&Wu is where I learned it)

Check!  I got it from Saunders MacLane's "classic".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <5etrns$sh3$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

> jsa@alexandria (Jon S Anthony) writes:
> 
> >In article <5eb4s4$jj5$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
> 
> >> There is a useful *syntactic* distinction between
> >             ^^^^^^
> >> "normal functions" f(x), g(x, y)
> >> "operators" f x    x g y
> >> "special syntax"  <<x>>  x[y]
> 
> >I'm not convinced.  Pleasant perhaps, but really useful?  In what way?
> 
> What I wrote was ambiguous.
> I did not mean that it was useful to _have_ the distinction.
> What I meant was that since the distinction has been 
> imposed on us, it is useful to have a way of _talking_ about it.

Ahhh.  Makes perfectly good sense.

> >> So how on earth is this supposed to make it _not_ an operator?
> 
> >Simple.  For Alan the term "operator" should be distinguished by its
> >semantic.
> 
> Yes, but he has completely failed to come up with a "semantic" that
> distinguishes "+" from anything else.

Well.  Yes.  That's true.


> The fundamental point here is that programming languages exist, and we
> need ways to talk about them clearly.  It doesn't do anyone any good
> to go "whaa, *I* wanna call + a subroutine" or anything like that.

Right.  At this point the terminology is set in concrete.  Or as Kosh
would say, "The avalanch has already begun.  It is too late for the
pebbles to vote."


> It doesn't even do any good to say "whaa, _mathematicians_ say xyz",
> because (a) mathematical usage is by no means uniform, and (b) programming
> languages are a different domain of discourse, and the re-use of words
> in different domains is a standard feature of English.

Agreed.  However, note that the mathematical usage in this case (what
an operation is) is pretty uniform.  I have not seen a case where
there has been a real exception.


> Let me cite Burris & Sankappanavar, "A Course in Universal Algebra".
> Ch II, Definition 1.1, p23.
> 	For $A$ a nonempty set and $n$ a nonnegative integer we define
> 	$A^0 = {\phi}$, and, for $n > 0$, $A^n$ is the set of $n$-tuples
> 	of elements from $A$.  An $n$-{\it ary operation\/}
> 	(or {\it function\/) {\it on} $A$ is any function $f$ from
> 	$A^n$ to $A$; $n$ is the {\it arity} (or {\it rank\/}) of $f$.
> 	\dots  An operation $f$ on $A$ is called a {\it nullary} operation
> 	\dots if its arity is zero.  \dots  An operation $f$ on $A$ is
> 	{\it unary}, {\it binary}, or {\it ternary} if its arity is 1, 2,
> 	or 3, respectively.
> 
> Someone incorrectly claimed that the mathematical word for these things
> was "operator".  It is in fact "operation".  I think we can all agree

Despite being mangled by news, I can make out that this conforms with
the usual sense of the term "operation" in mathematics.  As for
"operator", the term is usually applied to the glyph denoting an
operation.  But, in actual practice this is typically slopped over
because it is not a useful working distinction.  Shrug.


> The point that I am making is simply that there is an established word
> "operator" used consistently in the standards for many current programming
> languages to refer to a small set of built in operatIONS with special
> syntax.  This isn't _intended_ to conform to any advanced mathematical
> usage.

Exactly.  You've stated this quite well on other occasions.


> You may _regret_ the use of the word "operator" for a *syntactic*
> category in programming language standards, but it is humptydumptyism
> to try to pretend that it isn't so.

Completely agree.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Mike Klein]

Everybody knows that w.r.t. computers, operators
are the guys who load your card deck, and bring you your printout
when the job is done.

Isn't it yet evident in this thread that a launguage independant
definition of operator will probably have to be *very* ambiguously 
defined.

For example, C has functions, not procedures. Smalltalk has methods,
not functions, not procedures.  Scheme has procedures, although
just about any Lisp programmers would call them functions with nary
a raised eyebrow.  Basic has subroutines.  In language independent
terms, these are all various examples of subprograms.

But using the term subprogram denies all interesting nuances.

Mike Klein
-- 
mailto:mklein@alumni.caltech.edu
http://www.alumni.caltech.edu/~mklein

Re: OO, C++, and something much better!

[Clayton Weaver]

I missed the beginning of this thread, but what's the point here? Isn't
it that operator overloading should not obfuscate the semantic intent of
an expression? Or worse, introduce grammatic indeterminacy in the
intermediate form? The point is not, from what I have seen, that the true
semantic implications of use of an operator can be traced by backtracking
through the code, but rather that the operator should make it clear in the
language implementation or choice of expression from many alternatives
(that all express the same operation-on-args) what semantic production is
invoked by an operator in context.

The inexact mapping (and this is exactly what it is) from mathematics to
computation in both directions appears to me to be debating the
applicability or clarity of expression of an example rather than the
central issues of the original discussion.

Regards, Clayton Weaver  cgweav@eskimo.com  (Seattle)

Re: C++ Class [ not a good answer ]

[Luis Espinal]

> Read about polymorphism and virtual functions.
> 

This is a better answer to the original question.

Lock Minh, what you need is a class that has at least one pure virtual 
function in it. That way, nobody can instantiate an object from it and
still use it as a base class.
.ie.

class MyBase
{
	MyBase(){...}
	virtual ~MyBase(){ ... }
	virtual void SomeFunction() = 0; // a pure virtual function.
};

// you still need to implement the pure virtual func.
void MyBase::SomeFunction(){}

class AChild : public MyBase
{
	... here goes the constructors, destructors, etc.
	// you need to implement the pure virtual function
	// defined in MyBase; otherwise, you won't be 
	// able to instantiate a AChild object either.
	virtual void SomeFunction();
};

void AChild::SomeFunction()
{
// some code in here.
}

AChild someChild; // ok...

MyBase someBase; // eeek! can't compile.
		 // can't instantiate a class with 
		 // a pure virtual function in it.

Hope it helps.

Luis Espinal

p.s. cryptic answers don't help.
-- 
Luis++ lespin03@solix.fiu.edu
What does not kill us, makes us stronger...
What does not break us, makes us...
That which does not break, must bend...

Re: C++ Class [ not a good answer ]

[Tom Plunket]

On Mon, 03 Mar 1997 13:42:16 -0500, Luis Espinal
<lespin03@solix.fiu.edu> wrote:

> Lock Minh, what you need is a class that has at least one pure virtual 
> function in it. That way, nobody can instantiate an object from it and
> still use it as a base class.
> .ie.
> 
> class MyBase
> {
> 	MyBase(){...}
> 	virtual ~MyBase(){ ... }
> 	virtual void SomeFunction() = 0; // a pure virtual function.
> };
> 
> // you still need to implement the pure virtual func.
> void MyBase::SomeFunction(){}

Can't you just create a pure-virtual class, that doesn't
have pure-virtual member functions (if indeed you don't want
that)?  I thought that that was what class ios did.
Something along the lines of:

class CSomeVirtual
{
    CSomeVirtual();
    ~CSomeVirtual();

    MemberFunction();
    AnotherMemberFunc();
} = 0;

???

Then you're forced to derive from it, but everything is
implemented, too.

-Tom

Re: OO, C++, and something much better!

[David Shang]

Jay Martin wrote:
> 
> Heh.  Look at Microsofts API's, requires casts everywhere.  The COM
> model, their ultimate "object-oriented model", requires a cast just
> call a method on a object.  Since, Wintel is on like 90%(?) of
> installed machines, thats practically everyone.  C/C++ programmers
> "cast" more than programmers of other languages.


Please be specific on what sitiuations that C++ requires more casts
than other languages such as Java and Eiffel?

The fact that a system that happens to use C++ has a lot of casts
does not mean that C++ requires more casts. The system may use the same
amount of casts if it is implemented in other languages in the same way.

There are two cases that we need casts:

1. The type of the object from the outside of an open world is
   unknown and must be verified.

2. The type of a declared variable within the world is not precise
   enough to exclude bad cases.

We cannot avoid the first case. But the second case should be avioded
as much as possible.

Unfortunately, C++ as well as other languages does not deal with the
second case perfectly, especially in the csae where types are dependent.

Transframe does better on this issue. It requires fewer casts than any
other languages.

David Shang

Re: OO, C++, and something much better!

[Ronald E Jeffries]

On Fri, 27 Jun 1997 23:14:07 +0100, David Shang <shang@corp.mot.com>
wrote:

>Transframe does better on this issue. It requires fewer casts than any
>other languages.

Fewer than Smalltalk?  Fewer than zero?  When you use Transframe,
casts mysteriously disappear from other programs?

:)

Ron Jeffries
Smalltalker
How do I know what I think until I see what I type?
Remove SPAMBLOCK from my address to reply by email.

Re: OO, C++, and something much better!

[Mike Stark]

David Shang wrote:
> 
> Jay Martin wrote:
> >
> > Heh.  Look at Microsofts API's, requires casts everywhere.  The COM
> > model, their ultimate "object-oriented model", requires a cast just
> > call a method on a object.  Since, Wintel is on like 90%(?) of
> > installed machines, thats practically everyone.  C/C++ programmers
> > "cast" more than programmers of other languages.
> 
> Please be specific on what sitiuations that C++ requires more casts
> than other languages such as Java and Eiffel?
> 
> The fact that a system that happens to use C++ has a lot of casts
> does not mean that C++ requires more casts. The system may use the same
> amount of casts if it is implemented in other languages in the same way.
> 
> There are two cases that we need casts:
> 
> 1. The type of the object from the outside of an open world is
>    unknown and must be verified.
> 
> 2. The type of a declared variable within the world is not precise
>    enough to exclude bad cases.
> 
> We cannot avoid the first case. But the second case should be avioded
> as much as possible.
> 
> Unfortunately, C++ as well as other languages does not deal with the
> second case perfectly, especially in the csae where types are dependent.
> 
> Transframe does better on this issue. It requires fewer casts than any
> other languages.
> 
> David Shang
Another situation (or maybe a variation of one of the above) is in
languages such
as Java that lack generics -- then you are required to have lists and
queues of 
class java.lang.Object, and are required to check "instanceof" and then
cast once
you start looking at an item from that container.  I find that most
annoying.  Ada
generics solve this by allowing you to define precisely what type is
contained,
including a type at the root of a class hierarchy to allow heterogeneous
data.
C++ and Eiffel also provide this (or so I'm told, I haven't used C++
templates, 
or Eiffel at all), and while I like a lot of things about Java, the lack
of
generics and the consequences is most annoying.

Mike

-- 
--------------------------------------------------------------------------------
Michael Stark                                                  
NASA/GSFC                                           
Phone: (301) 286-5048                                   Code 551
Fax:    (301) 286-0245                                   Greenbelt, MD
20771
 e-mail: michael.e.stark@gsfc.nasa.gov
"I don't give them hell.  I tell the truth and they THINK it's hell!" 
Harry S. Truman
--------------------------------------------------------------------------------

Re: OO, C++, and something much better!

[Robert Dewar]

David says

<<David Shang wrote:

> Transframe does better on this issue. It requires fewer casts than any
> other languages.
>>

Since many other languages have no notion of a "cast" or anything similar,
this seems an unlikely claim.

Re: OO, C++, and something much better!

[Mike Anderson]

David Shang wrote:

> Transframe does better on this issue. It requires fewer casts than any
> other languages.

David,

Do you want to rephrase this to make it more accurate?

....Mike

Re: OO, C++, and something much better!

[Kohler Markus]

Robert Dewar wrote:
> 
> David says
> 
> <<David Shang wrote:
> 
> > Transframe does better on this issue. It requires fewer casts than any
> > other languages.
> >>
> 
> Since many other languages have no notion of a "cast" or anything similar,
> this seems an unlikely claim.

David probably wanted to say "fewer  casts than any static typed OOP
language". 

Markus


-- 
+----------------------------------------------------------------------------+
| Markus Kohler                          Hewlett-Packard
GmbH                |
| Software Engineer                      Network & System Management
Division| 
|                                        IT/E Response
Team                  |
+----------------------------------------------------------------------------+