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

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!

[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!

[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: 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!

[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: 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!

[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!

[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!

[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!

[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!

[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!

[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!

[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: 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!

[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!

[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!

[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: 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!

[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!

[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!

[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!

[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 |==============================================|

Black box or white box (Re: OO, C++, and something much better!)

[David L. Shang]

In article <32F07705.289C@concentric.net> Alan Lovejoy  
<alovejoy@concentric.net> writes:
> Matt Kennel wrote:
> > Alan Lovejoy (alovejoy@concentric.net) wrote:
> > : 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.
>

Be careful. Black boxes are not suitable for all the situiations.
Sometimes white boxes are required, especiallly in the situiation
where the clients want to have a touch and feel inside the box, not
just to use the functionality of the box.

Making all boxes black sometimes may complicate the usage of the
box. For example, if I get a 3D model boxes with an built-in
camera object, I would like to manipulate the camera by a direct
touching and feeling the camera, rather than by some indirect
handles (function interfaces) presented outside of the box.
Have a look at the following code:

   class My_3DScene is World3D
   {
	with Camera
	{	style = Perspective;
		position = (-1.0, 2.00, 8.0);
		orientation = (-0.2, -0.9, -1.5, 1.1);
		focalDistance = 12.5;
	};
	with Background
	{	style = Picturesque;
		scenery = "bluesky.jpg"
	};
	object Light is DirectionalLight
	{
		direction = (0.0,-0.2,-1.0);
	};
	object RollingFrame is Frame3D
	{
		object SphereFrame is Sphere
		{	position = (0.0,0.0,0.0);
			radius = 8.0;
			draw_attr = DrawWire;
		};
		object BlueCylinder is Cylinder
		{	with Material
			{	style = PerPart;
				diffuseColor = (0,0,1);
				specularColor = (0.5,0.5,1);
				shiness = 0.5;
				transparency = 0.6;
			}	
			position = (1.0,0.0,0.0);
			radius = 1.0;
			hight = 3.0;
		};
	}
   }
		
It is certainly better than the the following:

   class My_3DScene is World3D
   {
	DirectionalLight Light;
	Frame3D RollingFrame;
	Sphere SphereFrame;
	Cylinder BlueCylinder;
	Material material;

	My_3DScene() // constructor
	{
		Camera.SetStyle(Perspective);
		Camera.SetPosition(-1.0, 2.00, 8.0);
		Camera.SetOrientation(-0.2, -0.9, -1.5, 1.1);
		Camera.SetFocalDistance(12.5);
		Background.SetStyle(Picturesque);
		Background.SetScenery("bluesky.jpg");
		Light = new DirectionalLight (this);
		Light.SetDirection(0.0,-0.2,-1.0);
		RollingFrame = new Frame3D (this);
		SphereFrame = new Sphere (RollingFrame);
		SphereFrame.SetPosition(0.0,0.0,0.0);
		SphereFrame.SetRadius(8.0);
		SphereFrame.SetDrawAttr(DrawWire);
		BlueCylinder = new Cylinder (RollingFrame);
		material = BlueCylinder.GetMaterial();
		material.SetStyle(PerPart);
		material.SetDiffuseColor(0,0,1);
		material.SetSpecularColor(0.5,0.5,1);
		material.SetShiness(0.5);
		material.SetTransparency(0.6);
		BlueCylinder.SetPosition(1.0,0.0,0.0);
		BlueCylinder.SetRadius(1.0);
		BlueCylinder.SetHight(3.00);
	};
   };

The latter code hard to understand and manipulate.

The class "World3D" is not designed to be used through its
functionality, rather, it is designed for clients who can
touch and feel the inside of the world!

David Shang

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!

[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]

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!

[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!

[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!

[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!

[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

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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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: 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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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 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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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 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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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 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!

[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!

[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!

[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: 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!

[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!

[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!

[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!

[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: 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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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                  |
+----------------------------------------------------------------------------+

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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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 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!

[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!

[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]

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

[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!

[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!

[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: 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!

[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!

[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!

[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!

[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!

[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!

[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!

[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: Multiple Type Interfaces

[Jon S Anthony]

In article <5cm4raINN6ru@snoopy.cis.ohio-state.edu> dgibson@snoopy.cis.ohio-state.edu (david scott gibson) writes:

> Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>
> >If a package provides two types, T1 and T2, you cannot declare a
> >subprogram in the package that has both a controlling operand (i.e., a
> >parameter or a function result) of type T1 and one of type T2, because
> >it would not be obvious in this case which operand's tag should control
> >dispatching.  However, you can have one operand of type T1 (controlling
> >dispatching) and one of type T2'Class (not controlling dispatching) or
> >the other way around.
> 
> Okay, but then assume you want to extend this *package* by adding some
> new operations to T2 (but not T1).  If you extend T2, what happens to
> the operation which had T2'Class as a parameter.

Nothing.  It is a primitive operation of T1 not T2.  Since T1 was not
extended, nothing happens with it.


> My understanding is that it would not be present in the interface of
> the new package, thus the new package would not be a true extension
> of the original one.  What I was talking about (as applied to Ada)
> is really package extension, not type extension.

Hmmmm, that is a slippery point.  A package extension is part of the
same scope as its parent (and all the way up), but not part of its
"immediate" scope.  So, the operation is "there" in the extension in
the sense that it can be directly used in the extension without any
"with" or anything.  If you are an outside client, and you want the
extension stuff for T2 and the T1 stuff, you only have to with the
child (with A.B).  But, if you want direct visibility to both the new
T2 stuff and the T1 stuff, you have to "use" them both (use A, A.B).


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

Re: Multiple Type Interfaces

[Norman H. Cohen]

Dave Gibson wrote:

> When Ada83 evolved into Ada95, the concept of multiple type components (packages)
> survived, but was excluded when it came to OO-style (extendable) tagged types.

Not true.  It's perfectly possible for an Ada-95 package to provide two
different tagged types.  This might be done, for example, because the
two types share parts of their (hidden) implementations. 

If a package provides two types, T1 and T2, you cannot declare a
subprogram in the package that has both a controlling operand (i.e., a
parameter or a function result) of type T1 and one of type T2, because
it would not be obvious in this case which operand's tag should control
dispatching.  However, you can have one operand of type T1 (controlling
dispatching) and one of type T2'Class (not controlling dispatching) or
the other way around.

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

Re: Multiple Type Interfaces

[david scott gibson]

In article <32EE6EF2.2487@watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>Dave Gibson wrote:
>

>> When Ada83 evolved into Ada95, the concept of multiple type
>> components (packages) survived, but was excluded when it came to
>> OO-style (extendable) tagged types.

>
>Not true.  It's perfectly possible for an Ada-95 package to provide two
>different tagged types.  This might be done, for example, because the
>two types share parts of their (hidden) implementations. 
>
>If a package provides two types, T1 and T2, you cannot declare a
>subprogram in the package that has both a controlling operand (i.e., a
>parameter or a function result) of type T1 and one of type T2, because
>it would not be obvious in this case which operand's tag should control
>dispatching.  However, you can have one operand of type T1 (controlling
>dispatching) and one of type T2'Class (not controlling dispatching) or
>the other way around.

Okay, but then assume you want to extend this *package* by adding some
new operations to T2 (but not T1).  If you extend T2, what happens to
the operation which had T2'Class as a parameter.  My understanding is
that it would not be present in the interface of the new package, thus
the new package would not be a true extension of the original one.
What I was talking about (as applied to Ada) is really package
extension, not type extension.

Dave
--
dgibson@cis.ohio-state.edu

Re: Multiple Type Interfaces

[Matthew Heaney]

In article <5cm4raINN6ru@snoopy.cis.ohio-state.edu>,
dgibson@snoopy.cis.ohio-state.edu (david scott gibson) wrote:


>Okay, but then assume you want to extend this *package* by adding some
>new operations to T2 (but not T1).  If you extend T2, what happens to
>the operation which had T2'Class as a parameter.  My understanding is
>that it would not be present in the interface of the new package, thus
>the new package would not be a true extension of the original one.
>What I was talking about (as applied to Ada) is really package
>extension, not type extension.

Yes, but if you have an operation that takes T2'Class in the same package
as the declaration of type T2, then what you're saying is that that
operation is non-primitive, and you specifically *don't* want it to be
inherited by types that derive from T2.

I wouldn't bother trying to make the operation directly visible to clients
of the child package - let clients get it from the parent package, where
it's declared - but if you insist, then you could simply rename it in the
child (I think).

I don't think it's such a big deal that the operation isn't directly
visible from the child package, because clients of the child package have
to with the parent anyway, so they've got the non-primitive operation if
they really want it:

with P.C;
package body Q is
...
   P.Op (<object of T2'Class>)

vs.

   P.C.Op (<object of T2'Class>)

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

Re: Multiple Type Interfaces

[david scott gibson]

In article <mheaney-ya023280002801972134070001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>Yes, but if you have an operation that takes T2'Class in the same package
>as the declaration of type T2, then what you're saying is that that
>operation is non-primitive, and you specifically *don't* want it to be
>inherited by types that derive from T2.

Right, but I *do* want it to be "primitive" in the sense that it would be
included in the interface of package extensions.  I *don't* want it
to be a primitive operation associated with only the single controlling
operand type (as Ada95 requires).  Declaring an operand at T2'Class
was just a suggestion to try getting around the rule prohibiting
multiple controlling operands.

>I wouldn't bother trying to make the operation directly visible to clients
>of the child package - let clients get it from the parent package, where
>it's declared - but if you insist, then you could simply rename it in the
>child (I think).

If adding new T2 operations in the extension package required
declaring a new type derived from T2 (perhaps implicitly), then the
operation would probably have to be "inherited" in some sense so that
it would be available for calls with operands of types T1 and the new
type derived from T2.  Also, T1, T2, and the operation with T1 and T2
as operands might all be abstract in the parent unit and concrete in
the child unit.  In this case, I'd like both operations available
to the client.

Dave
--
dgibson@cis.ohio-state.edu

Re: Multiple Type Interfaces

[Robert A Duff]

In article <5cnl86INNam9@snoopy.cis.ohio-state.edu>,
david scott gibson <dgibson@snoopy.cis.ohio-state.edu> wrote:
>In article <mheaney-ya023280002801972134070001@news.ni.net>,
>Right, but I *do* want it to be "primitive" in the sense that it would be
>included in the interface of package extensions.  I *don't* want it
>to be a primitive operation associated with only the single controlling
>operand type (as Ada95 requires).  Declaring an operand at T2'Class
>was just a suggestion to try getting around the rule prohibiting
>multiple controlling operands.

What you suggest leads to multi-dispatch, no?  ALthough in a more
limited, and perhaps easier-to-deal-with form than CLOS.  The whole
point of disallowing an operation to be primitive on two tagged types
was to avoid confusions related to multi-dispatch.  I mean, what you're
asking for (package derivation) means that two (or more) types get
simultaneously derived, respectively, so you end up with ops on the two
(or more) derived types.  Double (or multi) dispatch.  Like I said, the
idea has occurred to me, but I haven't though it through.  I *suspect*
it adds a fair amount of complexity.

Note that the package derivation suggested here is very different from
the normal "packages as objects" and "package types" idea that various
people have proposed, as a (not good, IMHO) way of extending Ada 83 to
be OOP.

- Bob

Re: Multiple Type Interfaces

[david scott gibson]

In article <E4s5z9.5rH@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:

>What you suggest leads to multi-dispatch, no?

If it must support run-time dispatching, I think so.  However, I'm
still interested in a purely static binding system where late
binding is primarily achieved through parametric polymorphism
(generics in Ada).  

>ALthough in a more
>limited, and perhaps easier-to-deal-with form than CLOS.  The whole
>point of disallowing an operation to be primitive on two tagged types
>was to avoid confusions related to multi-dispatch.  I mean, what you're
>asking for (package derivation) means that two (or more) types get
>simultaneously derived, respectively, so you end up with ops on the two
>(or more) derived types.  

Yes.  I think that's a reasonable way of looking at it.  But how about
a package which only exports a single operation and no types.  The
same package extension mechanism would automatically include that
operation with an identical type signature.  In this case the
operation would not be dispatching, at least not in the usual sense,
but would still could be "inherited" through a package extension.  It
seems like child units support this part of package extension now.

>Double (or multi) dispatch.  Like I said, the
>idea has occurred to me, but I haven't though it through.  I *suspect*
>it adds a fair amount of complexity.

I'm wonder if you were to handle dynamic binding with a completely
separate mechanism, if you could factor off any additional complexity
which might result from package extension. 

BTW, I never did get any response on comp.object to my question about
the need for dynamic dispatching.  Aside from the issues of ease and
flexibility of development and maintenance, are there any other
compelling arguments for dynamic dispatching?  That is, are there
certain applications where the run-time dispatching approach is much
more natural that any purely static alternatives?  I think someone
once told me that run-time dispatching is very useful for "call-back"
applications or applications requiring execution of user-supplied
code.  Can anyone give me a more specific example and justification?

Dave
--
dgibson@cis.ohio-state.edu

Multiple Type Interfaces

[Dave Gibson]

From another very long thread:

> > There are subtle differences between 'type', 'interface', and 'class'
> > and the terms get used somewhat interchangebly around here.

They are used interchangebly by some and with completely different meanings
by others.  In general, 'type' and 'interface' are not used with precisely 
defined meanings outside of the context of specific programming languages.

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

Here's another view.  A type is a name for a mathematical set of values or a name
for a programming language- and environment-specific set of values.  For formal
reasoning about program behavior, it is convenient to model `program types' by
purely `mathematical' types.  An interface describes the externally-observable
elements of a component which consist of a structural signature and behavior
(ideally explicitly specified).  In general, an interface may include any
number of types.  A class is the common name for a programming langauge
component in some OO langauges where it defines a programming language type, an
interface, and may include other elements not part of the interface.

I am curious about "inheritance-like" relationships between components which export
multiple types.  Languages like Ada, Modula 2, ML, and others, support component 
interfaces that may include zero or more program types.  It seems like it should 
be possible to define behavioral substitutability relationships between such
components.  For example, if component A "includes" all of component B's interface,
then component A should be behaviorally substitutable for component B in some
informal sense.  This seems reasonable to me independently of whether component B's 
interface includes zero, one, or more types.   

When Ada83 evolved into Ada95, the concept of multiple type components (packages)
survived, but was excluded when it came to OO-style (extendable) tagged types. 
Clearly packages exporting multiple tagged types would not fit the common OO model
in which the concepts of "class" and program type are tightly coupled.  Nevertheless,
why not define a language so components can export multiple types which may be
extended in other related "derived" components?  Was this ever considered?  Was it 
just not considered the OO way by Ada95 language designers?  Perhaps it would 
be extremely complicated to implement with little perceived gain.  I'd appreciate any
comments on this topic.

Dave
--
dgibson@cis.ohio-state.edu

Re: Multiple Type Interfaces

[Robert A Duff]

In article <32EE352A.167EB0E7@cis.ohio-state.edu>,
Dave Gibson  <dgibson@cis.ohio-state.edu> wrote:
>Clearly packages exporting multiple tagged types would not fit the
>common OO model in which the concepts of "class" and program type are
>tightly coupled.  Nevertheless, why not define a language so components
>can export multiple types which may be extended in other related
>"derived" components?  Was this ever considered?  Was it just not
>considered the OO way by Ada95 language designers?  Perhaps it would be
>extremely complicated to implement with little perceived gain.  I'd
>appreciate any comments on this topic.

I've pondered this idea a little bit, since Ada 95 was designed.  It
sounds like it might be a good idea, but might also introduce a lot of
complexity.  I didn't really think it all through, though.  I don't know
if Tucker ever thought about it this way, before I joined the Ada 9X
project.

- Bob

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!

[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!

[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: 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:
> 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

Combining dynamic and static typing

[Don Harrison]

Dynamic and static typing both seem to have their place. Devotees of the former
extol the virtues of rapid development and devotees of the latter praise
its greater reliability.

What I'm wondering is whether it would be useful to have a development 
environment in which you had the option of using either. For example,
you may choose to write a system that may be completely dynamically-typed,
or partly dynamic and partly static, or completely static. For increased 
reliability, the development environment would come along after and fill in 
the missing types for you. It might do this by type inference and by using
data retained from individual executions. Inferred types might be displayed 
in a different colour in a visual programming environment and, if confirmed 
by the developer, displayed as though the developer had supplied them.

I know Cecil allows combined some form of dynamic/static typing but I'm not
sure how it works.


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

Re: Combining dynamic and static typing

[Erik M. Buck]

In <E4G92y.1CD@syd.csa.com.au> Don Harrison wrote:
> Dynamic and static typing both seem to have their place. Devotees of the 
former
> extol the virtues of rapid development and devotees of the latter praise
> its greater reliability.
> 
> What I'm wondering is whether it would be useful to have a development 
> environment in which you had the option of using either. 

Objective-C enables either!

Re: Combining dynamic and static typing

[Nathan M. Urban]

In article <01bc0b21$6a8293e0$7df2ad80@wkst01.milagro.austin.tx.us>, =?ISO-8859-1?Q?=22Jes=FAs_Eugenio_S=E1nchez=22_=3Cjesp@milagro.austin.?=
	=?ISO-8859-1?Q?tx.xx=3E?= wrote:

> Erik M. Buck <embuck@palmer.cca.rockwell.com> wrote in article =
> <5c8u2j$jvo@castor.cca.rockwell.com>...

> > In <E4G92y.1CD@syd.csa.com.au> Don Harrison wrote:

> > > What I'm wondering is whether it would be useful to have a development
> > > environment in which you had the option of using either.

> > Objective-C enables either!

> Where can we find a specific example? Or where is it documented?

For examples, look at NeXT's OpenStep libraries, among other things.
Objective-C will let you statically type objects in your code.  For
example, instead of creating a string with

     id str = [NSString alloc];

you can do

     NSString* str = [NSString alloc];

Then, if you have a line of code to send a message like

     [str notAStringMessage];

where "notAStringMessage" is a method which the NSString class does not
respond to, there will be a compile-time error.

HOWEVER, it is actually the case that the object is still dynamic,
since messages still go through the runtime system.  For example, you
could read in the name of a method, turn that into a selector, and send
a message with that name to 'str', even if NSString doesn't respond to
that message.  That would generate a runtime exception, unless you had
'str's "forward:" method handle it.  Which you might want to be able to
do, and which C++ would not let you do.

Thus, Objective-C gives you all the safety of C++'s static type
checking, while retaining all the advantages of a dynamic language.
-- 
Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech

Re: Combining dynamic and static typing

[David L. Shang]

In article <5celpp$n3r@csugrad.cs.vt.edu> nurban@csugrad.cs.vt.edu (Nathan M.  
Urban) writes:
> Thus, Objective-C gives you all the safety of C++'s static type
> checking, while retaining all the advantages of a dynamic language.

The advantage of static type checking is type error prevention:
to prevent type errors before it can happen.

Therefore, Objective-C cannot give the benefit of a static typing
system. Objective-C detects the type errors such as "Not a String"
at run-time. It does detection, not prevention! Detection is usually
not a solution to a problem. It is like an irresponsible doctor saying:
"Now I find what is wrong with you, it's your responsibility to figure
how to fix it. Want my suggetion? -- peace die -- crash!"

David Shang

Re: Combining dynamic and static typing

[Nathan M. Urban]

In article <1997Jan28.160420.28915@schbbs.mot.com>, shang@corp.mot.com wrote:
> In article <5celpp$n3r@csugrad.cs.vt.edu> nurban@csugrad.cs.vt.edu (Nathan M. 
> Urban) writes:

> > Thus, Objective-C gives you all the safety of C++'s static type
> > checking, while retaining all the advantages of a dynamic language.

> The advantage of static type checking is type error prevention:
> to prevent type errors before it can happen.

> Therefore, Objective-C cannot give the benefit of a static typing
> system. Objective-C detects the type errors such as "Not a String"
> at run-time. It does detection, not prevention! Detection is usually
> not a solution to a problem. It is like an irresponsible doctor saying:
> "Now I find what is wrong with you, it's your responsibility to figure
> how to fix it. Want my suggetion? -- peace die -- crash!"

Compile-time detection _is_ prevention.  If you get build errors all
over the place, you fix them.  Now, there are circumstances under which
you need to generate method dispatches at runtime -- which C++ cannot
do -- that can't be detected at compile-time.  Objective-C gives you
the power to do that, and if you send a bad message, you can trap the
exception and do something with it.  You can even check to see if an
object responds to a message before you send it, if you don't want to
trap it.  This is a better solution than not being able to have that
power at all.  Programs don't have to crash on a runtime exception.

If you want total safety without the possibility of generating a
runtime exception, then if you don't need dynamic message generation in
your program, it is trivial to write code that does not generate method
dispatches at runtime, just like C++; if you don't need the extra power
of Objective-C, then you don't have to write your code to use it.

If you are writing code that needs dynamic message generation, then
sending the wrong message is almost never something that should crash
the program, anyway..  suppose you have an application that gets passed
unknown object, and its job is to print that object.  It send that
object the "print" message.  If that object does not respond to print,
it's not crash-and-burn time, it's just something that can't be
printed.  So you come back and say, "This object can't be printed", and
go about your business.  I'd like an example of a case in which dynamic
message generation would produce a fatal error in a program.
-- 
Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech

Re: Combining dynamic and static typing

[Russ McClelland]

I think the real problem is that the C++ compiler is really stupid about
types and type checking.  When you create templates, it forces you to
declare what class to use as your template parameter.

Example:

	vector< Object * > v;

Of course this isn't bad in this case, but how about this:

	vector< Object * > v;
	vector< Object * > y( v );

The stupid compiler should already know what type vector y should be,
because it already knows what vector x is, and I'm invoking a copy
constructor.

Re: Combining dynamic and static typing

[David L. Shang]

In article <5cloqm$9kn@csugrad.cs.vt.edu> nurban@csugrad.cs.vt.edu (Nathan M.  
Urban) writes:
> In article <1997Jan28.160420.28915@schbbs.mot.com>, shang@corp.mot.com wrote:
> 
> > The advantage of static type checking is type error prevention:
> > to prevent type errors before it can happen.
> 
> > Therefore, Objective-C cannot give the benefit of a static typing
> > system. Objective-C detects the type errors such as "Not a String"
> > at run-time. It does detection, not prevention! Detection is usually
> > not a solution to a problem. It is like an irresponsible doctor saying:
> > "Now I find what is wrong with you, it's your responsibility to figure
> > how to fix it. Want my suggetion? -- peace die -- crash!"
> 
> Compile-time detection _is_ prevention.  If you get build errors all
> over the place, you fix them.  Now, there are circumstances under which
> you need to generate method dispatches at runtime -- which C++ cannot
> do -- that can't be detected at compile-time.  Objective-C gives you
> the power to do that, and if you send a bad message, you can trap the
> exception and do something with it.  You can even check to see if an
> object responds to a message before you send it, if you don't want to
> trap it.  This is a better solution than not being able to have that
> power at all.  Programs don't have to crash on a runtime exception.
> 
> If you want total safety without the possibility of generating a
> runtime exception, then if you don't need dynamic message generation in
> your program, it is trivial to write code that does not generate method
> dispatches at runtime, just like C++; if you don't need the extra power
> of Objective-C, then you don't have to write your code to use it.
>

There are some confusions about run-time type check or dynamic
dispatch with static type safety. They are not contradictory.
When a language uses run-time type check or allows dynamic
dispatch,  the language does not necessariy have to report type
errors at run-time.

A language should use run-time type check for type-error prevention.
But unfortunately, most dynamic languages use run-time type check
for error detection only. Objective-C is among them.

"type error" is a kind of soft definition to human beings.
When a type check fails, is that a type error? some people
would say yes, some people would say no. Consider a example.
Suppose we select oranges from a heterogeneous fruit bag:
take out a fruit, check whetehr it is an orange, if it is,
accept it. If it is not, throw it away. When the orange-
type check fails, is it a type error? No! It is an expected
situation. Consider another example. Imagine we want to put
an orange into a fruit box that accept orange. Now we got
a box with a lable telling us that it is a fruit box. Since
an orange is a fruit, of cause we can put the orange in.
But it happens to be a box accept apples only. Is this
a type error? Yes! It is an unexpected event.

Fortunately, we have a formal definition for what is a
type error. A type error is such an incorrect binding of
an object to a name that the type of the object does not
conform to the declared type of the name.

With this definition, let's review the above two examples:

1. Selecting Orange (in Transframe):

	fruit_bag: 	bag of Fruit;
	orange_bag:     bag of Orange;
	foreach (fruit in fruit_bag)
	{
	   inspect (typeof(fruit))
	   {
		case Orange: orange_bag.put(fruit);
		default: // do nothing
	   }
	}

The above code uses run-time type check, but should not raise
a run-time type error. 

2. Put Orange (in Java):

	Fruit[] fruit_box;
	Orange  orange;
	if (some_condition) fruit_box = new Apple[100]; ...
	fruit_box[0] = orange;

The above code will raise a run-time type error. The problem is
that "Apple[100]" is not a subtype of "Fruit[]":

   Fruit[]: an array whose elements can be any kinds of fruits
   Apple[]: an array whose elements can be apples only

Think for a while. You'll find even by your intuitive logic, Apple[]
should not be a subtype of Fruit[]! (Perhaps Java designers have
a uncommon logic than our ordinary people).

If I ask my 7-year old daugther to bring me a box that can hold any
kinds of fruit, she would certainly not bring me the box that can
hold apples only!

In Transframe, the code

	fruit_box: Fruit[] ;
	Orange  orange;
	if (some_condition) fruit_box := Apple[100](); ...
	fruit_box[0] := orange;

cannot get compiled, because the binding:

	fruit_box := Apple[100]();

is invalid. It is definitely (even my 7-year old daugther can judge)
a wrong binding.

So where can we get the array polymorphism? Transframe allows
correct array polymorphism only. Consider the following (in
Transframe):

	fruit_box: array #(ElementType: type of Fruit);
	orange: Orange;
	apple:  Apple;
	new_kind_of_fruit: Fruit;

	if (some_condition2) fruit_box := Apple[100] ();
	else if (some_condition2)  fruit_box := Orange[100] ();
	else fruit_box := Fruit[100] ();

	inspect (typeof(fruit_box).ElementType)
	{
		case Orange:
			fruit_box[0]:= orange;
		case Apple:
			fruit_box[0]:= apple;
		case Fruit:
			fruit_box[0]:= new_kind_of_fruit;
			fruit_box[1]:= orange;
			fruit_box[2]:= apple;
	}
	
The above code is correct. "fruit_box" is a polymorphic array
variable. It can represent a fruit_box that contains oranges
only, or a fruit_box that contains apples only, or a fruit_box
that contains any kinds of apples.

When you put an orange into the fruit box, you have to check
whether the fruit box accept an orange or not! It is the basic
requirement!

If you have a 7-year old kid, make a test. Tell him or her that
there are some fruit boxes, some may contain apples only, some
may contain orange only. And ask him or her to put an orange
into on of the fruit boxes. See whether she or he check the
contents of the box before puting the orange in.

David Shang

Re: Combining dynamic and static typing

[Luther Hampton]

David L. Shang wrote:
> 
> In article <5celpp$n3r@csugrad.cs.vt.edu> nurban@csugrad.cs.vt.edu (Nathan M.
> Urban) writes:
> > Thus, Objective-C gives you all the safety of C++'s static type
> > checking, while retaining all the advantages of a dynamic language.
> 
> The advantage of static type checking is type error prevention:
> to prevent type errors before it can happen.
> 
> Therefore, Objective-C cannot give the benefit of a static typing
> system. Objective-C detects the type errors such as "Not a String"
> at run-time. It does detection, not prevention! Detection is usually
> not a solution to a problem. It is like an irresponsible doctor saying:
> "Now I find what is wrong with you, it's your responsibility to figure
> how to fix it. Want my suggetion? -- peace die -- crash!"
> 
> David Shang

You must use a different Objective-C than I do. The Objective-C compiler
supplied by Next performs type checking to the maximum extent possible
at compile time. It's only when the compiler encounters the type "id"
that it gives up type checking.  If you wrote your entire Objective-C
program without referencing the type "id" (admittedly pretty impossible
in the Next environment), you would get complete compile-time type
checking.  These errors would be reported as warnings, but reported
nonetheless.  There is runtime checking to, but it is hardly the only
thing available.

Luther Hampton

Re: Combining dynamic and static typing

[Marc De Scheemaecker]

Luther Hampton wrote:
> 
> You must use a different Objective-C than I do. The Objective-C compiler
> supplied by Next performs type checking to the maximum extent possible
> at compile time. It's only when the compiler encounters the type "id"
> that it gives up type checking.  If you wrote your entire Objective-C

Even if you use the "id" type, you still get a warning if you send a 
message that's nowhere defined.
If you type e.g. [myObject relaese] (typo!) and "relaese" is nowhere
defined, you will get a warning.

> program without referencing the type "id" (admittedly pretty impossible
> in the Next environment), you would get complete compile-time type
> checking.  These errors would be reported as warnings, but reported
> nonetheless.  There is runtime checking to, but it is hardly the only

If you want them to be reported as errors, use the -Werr compile flag.
This works in gcc and I think also in the NeXTstep compiler (which is
based on gcc).

Marc
-- 
                      | Marc De Scheemaecker
                      | Jr. Development Engineer
                      | 
             NetVision nv
        marc@netvision.be
  http://www.netvision.be
                      |
                      | T. 016-31.00.15
                      | F. 016-31.00.29

  Geek Code: http://www.netvision.be/marc/geekcode.html

Re: Combining dynamic and static typing

[daniel damian burden]

well said don.

Re: Combining dynamic and static typing

[Robert I. Eachus]

In article <E4G92y.1CD@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

  > Dynamic and static typing both seem to have their place. Devotees
  > of the former extol the virtues of rapid development and devotees
  > of the latter praise its greater reliability.

  > What I'm wondering is whether it would be useful to have a development 
  > environment in which you had the option of using either...

    There are several languages which support this.  In particular
Ada 95 tagged types were designed so that it takes explicit coding to
create a situation where a dynamic type check must be made that could
fail.  You can of course create Ada 95 programs where all type
checking is static.  In fact, it is quite easy to do this by
recompiling Ada 83 programs. ;-)

    This is not to say that an Ada 95 program won't have dynamic
dispatching all over, just that cases where the type check must be
dynamic and can fail are rare.  Basically the compiler makes a type
check once at a known point, when a method is called with an object
whose type is (explicitly in Ada) dynamic.  Nested calls are
implicitly dynamic, and often dispatch in practice.  But the language
rules insure that implicit dispatches can be statically checked, even
though the call may require run-time dispatching.

     Hmmm... An example may be required.  (Note this is for example
purposes, not how I recommend implementing Matrix operations in Ada):

     type Matrix(Height, Width: Integer := 0) is tagged ...;

     function "+" (L,R: Matrix) return Matrix;
     ...

     type Square_Matrix is new Matrix with ...;

     function Inverse(S: in Square_Matrix) return Square_Matrix;
     function Discriminant(S: in Square_Matrix) return Float;
     ...

     X: Matrix'Class := ...;
     Y: Matrix'Class := Inverse(X);

     There must be a type check on the call to Inverse, since X is not
known to be of type Square_Matrix.  Within Inverse, there may be many
calls to operations, perhaps some recursive.  But as long as the type
mark is not class wide, there is no need to do an additional check.
This is true even if Inverse contains a call to Discriminant on the
result of a call to (the derived) "+".  (Again, I'd probably use LUP
decomposition, but this is not about how to implement matrix
operations.)
     
--

					Robert I. Eachus

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

Re: Combining dynamic and static typing

[David L. Shang]

In article <E4G92y.1CD@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison)  
writes:
> Dynamic and static typing both seem to have their place. Devotees of the  
former
> extol the virtues of rapid development and devotees of the latter praise
> its greater reliability.
> 
> What I'm wondering is whether it would be useful to have a development 
> environment in which you had the option of using either. For example,
> you may choose to write a system that may be completely dynamically-typed,
> or partly dynamic and partly static, or completely static. For increased 
> reliability, the development environment would come along after and fill in 
> the missing types for you. It might do this by type inference and by using
> data retained from individual executions. Inferred types might be displayed 
> in a different colour in a visual programming environment and, if confirmed 
> by the developer, displayed as though the developer had supplied them.
> 
> I know Cecil allows combined some form of dynamic/static typing but I'm not
> sure how it works.

For comprehensive technology of combining dynamic and static typing,
you may check the Transframe language at http://www.transframe.com
at the Technology/RapidDevelopment page. For technical detail, you
may check the page Research/TransframeLanguage.

David Shang

Re: Combining dynamic and static typing

[Robert C. Martin]

In article <E4G92y.1CD@syd.csa.com.au>, donh@syd.csa.com.au wrote:

> Dynamic and static typing both seem to have their place. Devotees of the
former
> extol the virtues of rapid development and devotees of the latter praise
> its greater reliability.
> 
> What I'm wondering is whether it would be useful to have a development 
> environment in which you had the option of using either.

C++ uses static typing for member function dispatch, but uses dynamic
typing (of a sort) for template dispatch.  I say (of a sort) because
the type are still checked at compile time, even in templates.  However,
templates can call member functions without the need to specify the
*type* in which those member functions are declared.  Indeed, there
need be no supertype contains the common declaration.  Thus, in that
regard, template invocation is similar to ST dynamic types.

-- 
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: Combining dynamic and static typing

[David L. Shang]

In article <rmartin-2801971315170001@pool11-019.wwa.com> rmartin@oma.com  
(Robert C. Martin) writes:
> 
> C++ uses static typing for member function dispatch, but uses dynamic
> typing (of a sort) for template dispatch. 

I am surprised to hear that C++ template uses dynamic typing (even
it is a sort of).

What is dynamic typing after all? We need a definition here because
people use this term for different concepts, and there is always
a confusion without an explicit definition.

Anyway, C++ template has nothing to do with "dynamic".

> I say (of a sort) because
> the type are still checked at compile time, even in templates.  However,
> templates can call member functions without the need to specify the
> *type* in which those member functions are declared.  Indeed, there
> need be no supertype contains the common declaration.  Thus, in that
> regard, template invocation is similar to ST dynamic types.
> 

The type check for a class parameter in a C++ template is done at
the time of the template is expanded. This is still at compile
time, not at run-time.

If we have to compare C++ templates with SmallTalk classes, yes, they have
one common property: late-type-error-detection, that is, the error
is detected at the time they are used, but not at the time they are
designed and developed. However, SmallTalk classes are released to
clients in executable form, so the use time is run-time. But C++
templates is presented to clients in source form, and the use time
is still compile-time.

David Shang

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!

[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!

[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!

[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!

[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: 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]

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!

[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!

[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!

[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 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!

[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 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!

[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!

[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]

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!

[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!

[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!

[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, 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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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 more and more useless arguments!

[Robert C. Martin]

In article <32ED07B7.7E77@netright.com>, david_nospam@netright.com wrote:

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

Neither of the three languages "suck".  Nor do ST, Self or Java.  They
are just *languages*; each useful and each with its own set of problems.

Java is a nice language; but its not perfect.  There are things about 
Java that I don't happen to like.  (e.g. the lack of MI, manually called
destructors, lack of manual memory management; to name a few).  C++
is a nice language too, but there are some things about it that I don't
like. (e.g. using destructors to clean up after exceptions, virtual
inheritance, Array/Pointer confusion, etc).  Smalltalk is a nice language
too, but there are some things about it that I don't like (dynamic typing,
lack of declarable interfaces (same thing), lack of module system, difficulty
in creation of shared libraries or distributable programs, etc.)

There is no perfect language.  And *no* language is going to solve all
your software problems, or multiply your productivity by a factor of 10,
or help you to write bug free code.  Good engineering skills are not
intrinsic to languages.  Rather they are within the engineers who weild
those 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: 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!

[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!

[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 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: 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!

[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!

[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!

[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!

[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!

[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!

[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

Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Richie Bielak]

Eric Clayberg wrote:
 
[...]
> 
> 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.
> 

The short answer to you comment is:
	
	"Testing only proves existence of errors, not their absence"
				
but static typing _proves_ absence of certain kinds of errors.

What is the largest piece of Smalltalk code you worked on? How many
lines of code and how many developers?

...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: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Bill Gooch]

Richie Bielak wrote:
>  
> The short answer to you comment is:
> 
>         "Testing only proves existence of errors, not their absence"
> 
> but static typing _proves_ absence of certain kinds of errors.

No, it does not.  In Java, for example, it is quite
easy to fool the compiler by casting to Object and
back to <whatever>.  Obviously this isn't intentional,
but it will happen in the midst of attempts to regain
some of the flexibility that static typing has taken
away.  The ensuing *runtime* exception isn't exactly
the same as a "messageNotUnderstood" in Smalltalk (it's
a casting error), but the effect is just the same.

-- 
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: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Eric Clayberg]

Richie Bielak wrote:
> but static typing _proves_ absence of certain kinds of errors.

That's all well and good, but if the percentage of those kinds of errors
is absurdly low in your application to begin with, it doesn't buy you
very much. Furthermore, if the benefits provided by static typing (and I
don't dispute that there are benefits) outweigh the costs (which can be
considerable in some languages), then it can be a net loosing
proposition.

I'm actually somewhat ambivalent about static typing. I find it to be
very useful in a language like C++ where the syntax is complex and the
function invocation syntax makes it easy to transpose (or even leave
out) arguments. Languages that have lots of rigid rules provide lots of
opportunities to break them. I have never felt the need for a static
typing system in Smalltalk (except maybe to provide better compile-time
optimizations). The syntax is simple, the rules are few, and I just
don't find myself making the same kinds of mistakes that are made all
too frequently in other languages. I imagine that if you were to ask
other folks who have programmed extensively in statically types
languages (like C++) as well as Smalltalk, I suspect that you would get
the same result.

> What is the largest piece of Smalltalk code you worked on? How many
> lines of code and how many developers?

The largest Smalltalk project I worked on was well over a million lines
of code and had 10-30 people working on it at any one time. The largest
Smalltalk project that I worked on by myself had over 100,000 lines of
code in it. I have personally written over 400,000 lines of commercial
Smalltalk code (ranging from shrink-wrapped apps to mission critical MIS
apps).

Why do you ask?

-Eric

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Richie Bielak]

Eric Clayberg wrote:
> 
> Richie Bielak wrote:
> > but static typing _proves_ absence of certain kinds of errors.
> 
> That's all well and good, but if the percentage of those kinds of errors
> is absurdly low ...

That hasn't been my experience. I've used PASCAL, Modula-2 and now
Eiffel.
But that's only hearsay.

> 
> I'm actually somewhat ambivalent about static typing. I find it to be
> very useful in a language like C++ where the syntax is complex and the
> function invocation syntax makes it easy to transpose (or even leave
> out) arguments. 

What do you think about Eiffel?

[...]

> 
> The largest Smalltalk project I worked on was well over a million lines
> of code and had 10-30 people working on it at any one time. The largest
> Smalltalk project that I worked on by myself had over 100,000 lines of
> code in it. I have personally written over 400,000 lines of commercial
> Smalltalk code (ranging from shrink-wrapped apps to mission critical MIS
> apps).
> 

I'm impressed.

> Why do you ask?
> 

I find that static typing helps a lot on large projects. Let's say 
I change one of my classes (say, I add an argument to a routine). I
change
my code and then attempt to compile. The compiler will find all the
places
where my routine is used and will complain. Even routines that
get hardly ever executed (like error handlers or end of year processing
etc).

How do you handle this type of change in Smalltalk? How do you find
the dependancies? 

...richie

P.S. When I worked in Modula-2 our applications ranged 100,000 to
500,000 LOCs,
     and the current Eiffel project I'm working on is about 700K LOC.

-- 
* 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: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Eirik Mangseth]

Richie Bielak wrote:
> 
> Eric Clayberg wrote:
> >
> > Richie Bielak wrote:
> > > but static typing _proves_ absence of certain kinds of errors.
> >
> > That's all well and good, but if the percentage of those kinds of errors
> > is absurdly low ...
> 
> That hasn't been my experience. I've used PASCAL, Modula-2 and now
> Eiffel.
> But that's only hearsay.
> 
> >
> > I'm actually somewhat ambivalent about static typing. I find it to be
> > very useful in a language like C++ where the syntax is complex and the
> > function invocation syntax makes it easy to transpose (or even leave
> > out) arguments.
> 
> What do you think about Eiffel?
> 
> [...]
> 
> >
> > The largest Smalltalk project I worked on was well over a million lines
> > of code and had 10-30 people working on it at any one time. The largest
> > Smalltalk project that I worked on by myself had over 100,000 lines of
> > code in it. I have personally written over 400,000 lines of commercial
> > Smalltalk code (ranging from shrink-wrapped apps to mission critical MIS
> > apps).
> >
> 
> I'm impressed.
> 
> > Why do you ask?
> >
> 
> I find that static typing helps a lot on large projects. Let's say
> I change one of my classes (say, I add an argument to a routine). I
> change
> my code and then attempt to compile. The compiler will find all the
> places
> where my routine is used and will complain. Even routines that
> get hardly ever executed (like error handlers or end of year processing
> etc).
> 
> How do you handle this type of change in Smalltalk? How do you find
> the dependancies?

One approach might be (this may not be the *optimal* approach though):

 when in the Class Hierarchy Browser, click on the method you're about
to change or have just changed, then choose the Methods menu. There
you'll find a menu item called Senders. Choosing this will bring up a
window displaying a list of all classes with the respective methods
calling the modified method. Click on one of the class>>method entries
and you'll be able to edit the code immediately.

By the way, there's also a menu item called implementors which displays
a list of classes implementing the method you're about to change.

Anyone care to share some more light on this?

> 
> ...richie
> 
> P.S. When I worked in Modula-2 our applications ranged 100,000 to
> 500,000 LOCs,
>      and the current Eiffel project I'm working on is about 700K LOC.
> 
> --
> * 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)          *

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: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Paul Perkins]

Eric Clayberg <clayberg@parcplace.com> wrote:

>That's where Smalltalk really shines. All of the commercial Smalltalk
>environments have fantastic cross-referencing and associated reflective
>tools built in. I can get a list of all senders or implementors of a
>method (either local to the hierarchy I'm in or global to the system) or
>all references to a class in a second or two. The built-in cross
>referencing tools come in handy all the time this way.

I agree, the interactive cross-referencing features of Smalltalk
environments are wonderful, much faster and better than I have seen
for other languages (Microsoft C++ is pretty good, except for being
slow). They do have one weakness that is related to dynamic typing: if
two or more semanticly unrelated methods have the same name, you have
to manually sort out the senders of the one you care about from
senders of the other methods. Such name collisions get harder to avoid
as the program size and project duration increase. It seems to me that
either (optional) static type declarations, or namespace management
features, or both, would help here.

Another reason to think that some kind of declarative type feature
could be useful in Smalltalk is that good Smalltalk programmers
typically use naming conventions and sometimes even comments to
indicate what kinds of values are expected to be bound to each
variable. The idea of formalizing this just enough so that the
information is available to automated tools is appealing to me.


Paul Perkins (paul.perkins@pobox.com)
Who are you? What do you want? Tick or Tock?

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Robert A Duff]

In article <32ec94c5.12380906@news.ipass.net>,
Paul Perkins <paul.perkins@pobox.com> wrote:
>Another reason to think that some kind of declarative type feature
>could be useful in Smalltalk is that good Smalltalk programmers
>typically use naming conventions and sometimes even comments to
>indicate what kinds of values are expected to be bound to each
>variable. The idea of formalizing this just enough so that the
>information is available to automated tools is appealing to me.

Indeed.  The Smalltalk programmer writes

    grindOn: aString and: anotherString

whereas the Ada programmer writes

    procedure Grind_On(X, Y: String);

Obviously both programmers think its useful to know what type is
expected for a formal parameter.  The latter has the advantage that it
can't accidentally be incorrect information.

Note that this has nothing to do with static vs. dynamic type checking
-- Smalltalk doesn't check that aString and anotherString are indeed
Strings -- it doesn't check statically *or* dynamically.

- Bob

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[John Gale]

In <E4n2rn.n4@world.std.com>, Robert A Duff wrote:

} In article <32ec94c5.12380906@news.ipass.net>,
} Paul Perkins <paul.perkins@pobox.com> wrote:
} >Another reason to think that some kind of declarative type feature
} >could be useful in Smalltalk is that good Smalltalk programmers
} >typically use naming conventions and sometimes even comments to
} >indicate what kinds of values are expected to be bound to each
} >variable. The idea of formalizing this just enough so that the
} >information is available to automated tools is appealing to me.
} 
} Indeed.  The Smalltalk programmer writes
} 
}     grindOn: aString and: anotherString
} 
} whereas the Ada programmer writes
} 
}     procedure Grind_On(X, Y: String);
} 
} Obviously both programmers think its useful to know what type is
} expected for a formal parameter.  The latter has the advantage that it
} can't accidentally be incorrect information.

Granted, however, tools can easily be developed to check that aString and
anotherString are always passed Strings.  The tools can be set to run in the
background so that you can do something else while they are working et voila.
BUT this does require that the programmer always have the word String where a
string is wanted.

I am not trying to get any religious war going here. Each system seem to have
challenges and benefits.  I want the benefits of both without any of the
challenges. :)

<snip>
________________________________________________
John Gale                   john@peacesummit.com
Creativity & imagination are more to be 
         valued than obediance & ambition

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Robert A Duff]

In article <32f40669.218760080@news.jumppoint.com>,
John Gale <john@peacesummit.com> wrote:
>} Obviously both programmers think its useful to know what type is
>} expected for a formal parameter.  The latter has the advantage that it
>} can't accidentally be incorrect information.
>
>Granted, however, tools can easily be developed to check that aString and
>anotherString are always passed Strings.  The tools can be set to run in the
>background so that you can do something else while they are working et voila.
>BUT this does require that the programmer always have the word String where a
>string is wanted.

I'm not sure what, exactly, these tools are supposed to do.  I mean,
what does it make of notAString (which is anything but a String)?  More
realistically, what does it make of lengthOfTheNameString, which is (of
course) an integer?  (In Smalltalk, I mean.)

Besides, "tools can easily be developed" is hardly a useful argument,
unless it's actually been done.

>I am not trying to get any religious war going here.

I fear it's too late.  (But I still think it's fun to discuss particular
language features, if people don't get too caught up in "My language is
better than yours.")

>...Each system seem to have
>challenges and benefits.  I want the benefits of both without any of the
>challenges. :)

Me too.

- Bob

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Damon Feldman]

In article <32E85588.1978@parcplace.com>, clayberg@parcplace.com wrote:

>That's where Smalltalk really shines. All of the commercial Smalltalk
>environments have fantastic cross-referencing and associated reflective
>tools built in. I can get a list of all senders or implementors of a
>method (either local to the hierarchy I'm in or global to the system) or
>all references to a class in a second or two.

Yes, but the cross-referencing is by name only.  So you get all implementors 
of a method with that name, even if they are completely unrelated.  Since the 
receiver is not known statically there is no way to know who *really* sends to 
the method -- you can only tell the superset built of all methods that send to 
a method with the same name.

Damon

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Eric Clayberg]

Damon Feldman wrote:
> Yes, but the cross-referencing is by name only.  So you get all implementors
> of a method with that name, even if they are completely unrelated.

So? In practice, all implementors of a method with the same name usually
*are* related. It is rare indeed that you would have a method #foo that
meant a dozen different things to a dozen different classes.

> Since the receiver is not known statically there is no way to know who 
> *really* sends to the method

Presumably, if *you* are writing the code, then *you* probably do have a
good idea who is sending the message. If you don't, it is probably a
good idea that you are presented with the set of all implementors (even
if one or two might be spurious).

Don't knock it 'til you try it.

-Eric

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Richie Bielak]

Eric Clayberg wrote:
> 
> Richie Bielak wrote:
> > but static typing _proves_ absence of certain kinds of errors.
> 
> That's all well and good, but if the percentage of those kinds of errors
> is absurdly low in your application to begin with, it doesn't buy you
> very much. 

[...]

What also wanted to say in my previous post is that static typing
proves that there is no call in the program that will cause
the "message not understood" error.

Is the chance of this kind of error "absurdly low"?

...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: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Eric Clayberg]

Richie Bielak wrote:
> What also wanted to say in my previous post is that static typing
> proves that there is no call in the program that will cause
> the "message not understood" error.

So a static type check can prove that a message wont be sent to an
object whose memory has been freed up prematurely, huh? I don't think
so. A static type check would certainly catch *some* "message not
understood" problems (in particular, those that corresponded to actual
type errors), but by no means all or even most of them. Most "message
not understood" errors are caused by messages being sent to nil (e.g.,
an uninitialized variable or a prematurely freed variable). Furthermore,
the static type checker would not be able to detect errors that were
caused by dynamic message creation and dispatch (e.g., the message
selector is constructed dynamically based on runtime data).
 
> Is the chance of this kind of error "absurdly low"?

For "message not understood" errors that correspond to actual type
errors, yes.

Static type checkers have been developed for Smalltalk (e.g., the
StrongTalk system). They have not been commercially successful so far.
Although they work fine, they are attempting to solve a problem that in
practice isn't really a problem. Smalltalk has been around for a long
time. Techniques for adding static type checking to it have been
available for a long time. If static typing had ever become an important
issue for the Smalltalk community, the Smalltalk vendors (IBM included)
would have provided that capability. It hasn't, so they haven't.

-Eric

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Robb Nebbe]

Eric Clayberg wrote:
> ... Smalltalk has been around for a long
> time. Techniques for adding static type checking to it have been
> available for a long time. If static typing had ever become an important
> issue for the Smalltalk community, the Smalltalk vendors (IBM included)
> would have provided that capability. It hasn't, so they haven't.
> 
> -Eric

Designing a language with typing in mind is not the same as
retro-fitting a type system onto a language like Smalltalk. In the
papers I read they usually wound up with some hybrid half static/half
dynamic type system. If you don't consider typing from the start I would
expect lots of problems with decidability issues. I guess that I don't
share your confidence that Smalltalk vendors could follow the market if
it moved torwards static typing.

Robb Nebbe

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: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Richie Bielak]

Eric Clayberg wrote:
 
[...]

> Most "message
> not understood" errors are caused by messages being sent to nil (e.g.,
> an uninitialized variable or a prematurely freed variable). Furthermore,
> the static type checker would not be able to detect errors that were
> caused by dynamic message creation and dispatch (e.g., the message
> selector is constructed dynamically based on runtime data).
> 

OK. Sending a message to nil is not what I think of as a typing error
and of course a static type checker would not catch that.

There seems to be a cultural gap between the static-typing and 
dynamic-typing crowds. I was raised on statically typed languages
and feel lost in a dynamically typed language (I fiddled little
with Smalltalk and now I'm playing with Python). I mean, I read the
code and can't tell what type a variable is...

On the other hand, I have seen people used to other languages
bang the keyboard and curse the Pascal compiler for not letting
them do something that seemed obviously correct. 

No easy answers.

...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: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Bob Jarvis]

Richie Bielak <richieb@calfp.com> wrote in article <32E8BCE3.3029@calfp.com>...
> There seems to be a cultural gap between the static-typing and 
> dynamic-typing crowds. I was raised on statically typed languages
> and feel lost in a dynamically typed language (I fiddled little
> with Smalltalk and now I'm playing with Python). I mean, I read the
> code and can't tell what type a variable is...

As were many of us ("raised" on statically-typed languages).  I guess that
after a while you just shrug your shoulders and say, "Oh, nuts.  If the dang
object responds properly to the messages I send it, what do *I* care what
its actual type or class is?".

This discussion reminds me of an analogous situation I encountered when
making the transition from mainframes to PCs.  I'd worked with mainframes
for about ten years before I first encountered PCs and was used to and
comfortable with mainframe concepts for accessing disk files.  When I got
my first PC I wanted to write a program to randomly access records in a
file, so I started trying to figure out how to specify access method, record
length, block size, record format, and all the other "mainframe-isms" I was
used to.  Needless to say I was somewhat confused for a while until I 
figured out that on a PC *all that crap didn't matter*!  Files were accessed by
byte offset from the start of the file - period.  If you wanted to start reading at 
the beginning, fine.  If you wanted to start reading or writing from/to somewhere
else in the file, fine also.  But you *didn't* have to muck with all the other
garbage I'd come to think of as "normal".  It just didn't matter!

Perhaps the difference between statically and dynamically typed languages
is similar.
-- 
Bob Jarvis
Mail addresses hacked to foil automailers!
Send replies to jarvisb@timken.com

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Richie Bielak]

Bob Jarvis wrote:
> 
> Richie Bielak <richieb@calfp.com> wrote in article <32E8BCE3.3029@calfp.com>...
> > There seems to be a cultural gap between the static-typing and
> > dynamic-typing crowds. I was raised on statically typed languages
> > and feel lost in a dynamically typed language (I fiddled little
> > with Smalltalk and now I'm playing with Python). I mean, I read the
> > code and can't tell what type a variable is...
> 
> As were many of us ("raised" on statically-typed languages).  I guess that
> after a while you just shrug your shoulders and say, "Oh, nuts.  If the dang
> object responds properly to the messages I send it, what do *I* care what
> its actual type or class is?".

But static type checking guarantees that the object, whatever its type, 
*will* respond properly to the message we sent it. Of course provided
the object is there (i.e. we're not sending to 'nil').


[...mainframe vs. PC discussion trimmed out...]

I'm not sure your analogy works, but in a way you maybe right. 
I believe that programming languages of the future must be
more dynamic than let's say Pascal. You can see an little of that
in Java. In the future an application will not be an excutable file
loaded into memory from disk, but bits of code loaded at runtime
from anywhere on the network. 

...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: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Eric W. Nikitin]

Richie Bielak (richieb@calfp.com) wrote:
: But static type checking guarantees that the object, whatever its type, 
: *will* respond properly to the message we sent it. Of course provided
: the object is there (i.e. we're not sending to 'nil').

[snip]

: I believe that programming languages of the future must be
: more dynamic than let's say Pascal. You can see an little of that
: in Java.

Strong static typing does not preclude dynamic dispatch of messages. 
The programming language Oberon demonstrates this to a certain 
degree, and a variant of Oberon - Lagoona - provides an even more
flexible method of message delegation. 

(* I hope I'm not contributing to the "my language is better than
   your language" tone of this thread :)
*)

-- 
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: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Robert A Duff]

In article <01bc0a1e$faed8ce0$c318b993@jarvisb>,
Bob Jarvis <nospam@thankyou.net> wrote:
>As were many of us ("raised" on statically-typed languages).  I guess that
>after a while you just shrug your shoulders and say, "Oh, nuts.  If the dang
>object responds properly to the messages I send it, what do *I* care what
>its actual type or class is?".

Fine, but you want to be able to know that "the dang object responds
properly to the messages I send it" by doing a purely static analysis of
the program.  In fact, this is exactly what many people call "type" --
the concept of type, in this sense, embodies what messages the objects
of that type respond to.

>Perhaps the difference between statically and dynamically typed languages
>is similar.

I think it's a bit misleading to say that Smalltalk is dynamically typed
versus Ada/C++/etc being statically typed.  I mean, Smalltalk does not
check the type of an object when passing it as a parameter.  Not even
dynamically.  There's no way to even say what the type is supposed to
be.  Smalltalk doesn't check on assignment, either.  Not statically, and
not dynamically.  The *only* thing Smalltalk checks is the *target* of
the message.  In other words, Smalltalk has less type checking -- it's
not just a matter of moving type checking from compile time to run time,
for the added flexibility.  It's a matter of eliminating certain type
checks entirely.

This makes a big difference: when I was writing Smalltalk code, there
would sometimes be nasty bugs, where a message parameter called aString
was passed something other than a String, and then this is saved in some
data structure, and passed around a bit more, until some time later,
somebody trips over the bogus object by sending it a message that only
Strings understand.

- Bob

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Damon Feldman]

>I think it's a bit misleading to say that Smalltalk is dynamically typed
>versus Ada/C++/etc being statically typed.  I mean, Smalltalk does not
>check the type of an object when passing it as a parameter

Statically typed means that types are *determined* at compile time.
Dynamically typed means types are *determined* at runtime.

Static type *checking* means checking done at compile time.
Dynamic type *checking* means checking at run time, I suppose.

"Checking" catches errors, "determining" types determines what class a 
variable is (and therefore how it handles messages and what data it has access 
to).

To my knowledge all statically-typed languages do static type checking.
Since the programmer was forced to commit to fixed types at compile time
it would be dumb not to check for errors in this cheap and easy-to-debug way.

But dynamically typed languages just generate errors rather than explicitly do 
dynamic type-checking.  (This is a bit of a simplification, but that's the 
idea.) 

So Smalltalk is dynamically typed because objects can get different types at 
runtime depending on execution, even though it is not type checked 
explicitly beyond generating an error or automatically expanding collection 
sizes, etc.

Damon

Defintion, again, was Re: Static vs. Dynamic typing again

[David L. Shang]

In article <5covaj$l0@boursy.news.erols.com> feldmand@erols.com (Damon Feldman)  
writes:
> 
> >I think it's a bit misleading to say that Smalltalk is dynamically typed
>
> Statically typed means that types are *determined* at compile time.
> Dynamically typed means types are *determined* at runtime.
> 
> Static type *checking* means checking done at compile time.
> Dynamic type *checking* means checking at run time, I suppose.
> 

I would like to make more definitions here.

Dynamically Typed (con: statically typed). An argument (variable,
 reference, or formal parameter) is dynamically typed if the type
 of the object to which the argument can be bound cannot be
 determined statically (at compile or link time). Examples of
 dynamically typed arguments are:
  Untyped without static type inference: the type is not given before 
    run-time. It can be bound to an object of any type at run-time.
    This is an extreme case of the dynamically typed. The example is
    a SmallTalk variable.
    Note that a variable in ML is also untyped, but the exact type of
    its bound object is inferred (guaranteed!) before run-time.
    Therefore, an ML variable, though untyped at the time of
    declaration, but typed at the time before running. It is not
    dynamically typed by this definition.
  Polymorphically typed: the type is given at the time the argument
    is declared. It can be bound to an object of any subtype of the
    given type at run-time. A Java's variable (non-primitive) falls
    into this case. 
  Tagged Union: a set of possible types are given at the time the
    argument is declared. It can be bound to one of the given types
    at run-time.

Dynamic Typing (con: static typing). A type system is a dynamic
 typing system if new types can be defined/created at run-time.
 CLOS and Dylan support dynamic typing while C++, Java, Eiffel,
 and Ada95 are static typing languages. In a dynamic typing
 system, the class hierarchy can be dynamically expanded by
 adding new subclasses at the time the programming is running.
 But the class hierarchy is fixed at runtime in a static typing
 system.

Dynamic Type (con: static type). A type is a dynamic type if its
 definition can be changed after its creation. Therefore, we can
 add/delete methods or slots in a dynamic type at run-time.
 A static type is fixed since it is created. A simulation of dynamic
 type by dynamic typing system can be done by considering a new type
 is created whenever the existing type changes.  

Dynamic Type Checking (con: static type checking): checking the
 type of a dynamically typed argument at run-time.

Dynamic Type Safe: All type errors, if cannot be not prevented from
 happening at compile time or link time, should be detected at
 run-time.

   [ A type error is such an incorrect binding of
     an object to a name that the type of the object does not
     conform to the declared type of the name.
   ]

Static Type Safe (stronger): All type errors can be prevented
 from happening before run-time.

Strong Type Safe (further stronger): All type errors can be
 prevented from happening before the software is released. This
 is a new definition. By this definition, C++ templates is
 static type safe but not strong type safe. C++ templates are
 released to clients in the form of source code. The type error
 is detected at the time it is used by clients, not at the
 time the template is designed or developed.

My comments:

Dynamic type checking is not only for dynamic type safe. It
can be used for error prevention and produce a strong type
safe language!

For how and why, you may refer to my language compariosn
document:

	Transframe, Java & C++: A Critical Comparison
	http://www.transframe.com,
	at Research/TransframeLanguage page

David Shang


  

  

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Fergus Henderson]

feldmand@erols.com (Damon Feldman) writes:

>To my knowledge all statically-typed languages do static type checking.

Uh, what about K&R C?

Well, I guess even K&R C did _some_ static type checking.
It didn't do much, though.

--
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: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Robert A Duff]

In article <5covaj$l0@boursy.news.erols.com>,
Damon Feldman <feldmand@erols.com> wrote:
>Statically typed means that types are *determined* at compile time.
>Dynamically typed means types are *determined* at runtime.
>
>Static type *checking* means checking done at compile time.
>Dynamic type *checking* means checking at run time, I suppose.

OK.

>"Checking" catches errors, "determining" types determines what class a 
>variable is (and therefore how it handles messages and what data it has access 
>to).

OK.

>But dynamically typed languages just generate errors rather than explicitly do 
>dynamic type-checking.  (This is a bit of a simplification, but that's the 
>idea.) 

Heh?  Smalltalk does a type check on the *target* of the message.  It
does not do a type check on the (other) parameters of the message.

>So Smalltalk is dynamically typed because objects can get different types at 
>runtime depending on execution,

This is true of Ada tagged types, and Eiffel types, too.

>... even though it is not type checked 
>explicitly beyond generating an error or automatically expanding collection 
>sizes, etc.

My point was that the difference between Ada/C/C++/Eiffel and Smalltalk
is not merely *when* the checks are done (compile-time vs. run-time),
but that Smalltalk does fewer checks.  In particular, it does not check
the type of each parameter of a message (not at run time, not at compile
time).  So, it's wrong to view the difference between these languages as
compile-time-type-checks vs. run-time-type-checks.

- Bob

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Piercarlo Grandi]

>>> "feldmand" == Damon Feldman <feldmand@erols.com> writes:

>> I think it's a bit misleading to say that Smalltalk is dynamically
>> typed versus Ada/C++/etc being statically typed.  I mean, Smalltalk
>> does not check the type of an object when passing it as a parameter

feldmand> Statically typed means that types are *determined* at compile
feldmand> time.

Consider:

  class A { ... }; class B : A { ... };
  class A a; class B b; class B *bp;

  bp = (randomNumber() > 0.5) ? &a : &b;

Here there is no question that 'bp' has a static type constraint, and
also no question that it is impossible statically to infer the type of
object denoted by 'bp' after the assignment above.

The rest of your arguments are consistent with the one above :-).

feldmand> Dynamically typed means types are *determined* at runtime.

Please give even a single example of runtime determination of types in
any popular language. All popular languages have statically manifest
variable types, and statically manifest constraints (if any) on
variables; it's the type of the objects attached to a variable that may
be only apparent at runtime.

It would be interesting to be given an example of any popular
(non-research) language in which the type of a variable can change
dynamically, or even just its constraint can change dynamically.

feldmand> Static type *checking* means checking done at compile time.
feldmand> Dynamic type *checking* means checking at run time, I suppose.

feldmand> "Checking" catches errors, "determining" types determines what
feldmand> class a variable is (and therefore how it handles messages and
feldmand> what data it has access to).

In all popular languages all variables belong to the same ``class''
(which is usually, like in Smalltalk-80, not reified), and all have
exactly the same operators; in particular in languages like Smalltalk-80
variables do not have access to any message, but only to the assignment
(and dereferencing) operator.

feldmand> To my knowledge all statically-typed languages do static type
feldmand> checking.  Since the programmer was forced to commit to fixed
feldmand> types at compile time it would be dumb not to check for errors
feldmand> in this cheap and easy-to-debug way.

feldmand> But dynamically typed languages just generate errors rather
feldmand> than explicitly do dynamic type-checking.  (This is a bit of a
feldmand> simplification, but that's the idea.)

feldmand> So Smalltalk is dynamically typed because objects can get
feldmand> different types at runtime depending on execution,

I am curious to be told which version of ``Smalltalk'' you are talking
about, because even beginners know that in classic versions like
Smalltalk-80 it is absolutely impossible to do as you say. Once
instantiated, the type of an object cannot be validly changed in
Smalltalk-80 (nor in most of its successors/derivatives).

feldmand> even though it is not type checked explicitly beyond
feldmand> generating an error or automatically expanding collection
feldmand> sizes, etc.

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Matt Kennel]

Piercarlo Grandi (piercarl@sabi.demon.co.uk) wrote:
: >>> "feldmand" == Damon Feldman <feldmand@erols.com> writes:

: >> I think it's a bit misleading to say that Smalltalk is dynamically
: >> typed versus Ada/C++/etc being statically typed.  I mean, Smalltalk
: >> does not check the type of an object when passing it as a parameter

: feldmand> Statically typed means that types are *determined* at compile
: feldmand> time.

: Consider:

:   class A { ... }; class B : A { ... };
:   class A a; class B b; class B *bp;

:   bp = (randomNumber() > 0.5) ? &a : &b;

: Here there is no question that 'bp' has a static type constraint, and
: also no question that it is impossible statically to infer the type of
: object denoted by 'bp' after the assignment above.

I don't know for sure, but what about a system where a
'routine feature' could be added to a class during the execution
of a program, so that at one point in time, an object of such class
would not be compatible with some interface (e.g. not ''type'' T)
but at a later time the 'same object' (forbearing us the common delusion
that objects have identity :) ) would be compatible with that interface. 

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Piercarlo Grandi]

>>> "kennel" == Matt Kennel <kennel@lyapunov.ucsd.edu> writes:

kennel> I don't know for sure, but what about a system where a 'routine
kennel> feature' could be added to a class during the execution of a
kennel> program, so that at one point in time, an object of such class
kennel> would not be compatible with some interface (e.g. not ''type''
kennel> T) but at a later time the 'same object' (forbearing us the
kennel> common delusion that objects have identity :) ) would be
kennel> compatible with that interface.

Well, it's hard for me to contemplate such an option, for there are two
assumptions here that are pretty hard to agree with: that the interface
to a module is the ``type'' of an instance of the type encapsulated in
that module, and that one can alter the definition of a class and the
instances of the class as previosuly defined become automagically
instances of the new modified class.

Consider:

  class C // bounded stack
  {
    unsigned m;
    unsigned b,t;
    void *e;
  public:
    void *pop() { .... };
    void push(void *) { .... };
  };

This defines a class and a type encapsulated within it. Now suppose we 
just added something like the following two procedures:

  class C // bounded deque
  {
    unsigned m;
    unsigned b,t;
    void *e;
  public:
    void *pop() { .... };
    void push(void *) { .... };
    void *get();
    void put(void *) { .... }
  }

is the second 'C' the same type as the first 'C", only updated? To me
they are completely different types, for they have different semantics,
as well as different interface. Instances of one 'C' are not instances
of the other 'C'.

If one creates a batch of instances of the first 'C', and then changes
the definition of 'C' so that it looks like that the second one above,
one has not changed in any meaningful sense the type of the first batch
of instances; one has merely created confusion by giving the same name
to two different entities at different times.

The opposite seems a rather extraordinary assumption, that I think is
induced but not justified by the ease with which one can, in some
implementations, change the ``class pointer'' from an object to the
_representation_ of its class to point to a new class object.

  In some language implementations, e.g. typical ``Smalltalk''
  implementations, if there any such thing, objects that represent
  classes are held, quite amazingly, in (anonymous) variables (like all
  objects actually), and objects that are instances of a class are
  linked not to the object that represents it, but to a _variable_ that
  holds that object; this means that one can, in some ``Smalltalk''s for
  example, change the class object that is attached to that variable,
  and thus have an object denote a the representation of a class of
  which it is not the instance; such hackery does not amount to changing
  the ``type''/type of the object.

The common delusion that objects have identity in non actor languages is
not quite relevant.

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Pieter Schoenmakers]

In article <vwjk9obnph4.fsf@cassin.dcs.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:

   Consider:

     class C // bounded stack
     ...

   This defines a class and a type encapsulated within it. Now suppose we 
   just added something like the following two procedures:

     class C // bounded deque
     ...
       void *get();
       void put(void *) { .... }


   is the second 'C' the same type as the first 'C", only updated? To me
   they are completely different types, for they have different semantics,
   as well as different interface. Instances of one 'C' are not instances
   of the other 'C'.

There are (many, very) valid examples of adding methods to a class,
which do not change the semantics of the object.  In the example, only
adding a `print' method, with the obvious functionality, would not
change the semantics of the existing stack objects.  Nor would it create
a new class.  The stack objects would just be able to print themselves.

Objective-C (at least the GNU and NeXT implementations) allows methods
to be added to a class in a running program.  NeXT's runtime library
allows method replacement.

Cecil allows (library) classes to be extended.  `The Cecil language,
specification and rationale' does not specify to what extent this is
allowed at run time.

TOM allows, both at compile time and at run time, methods to be added
and replaced.  Since the implementation of such methods may need some
state to be maintained in the object, instance variables can be added as
well.  --Tiggr

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Piercarlo Grandi]

>>> "tiggr" =3D=3D Pieter Schoenmakers <tiggr@es.ele.tue.nl> writes:

tiggr> In article <vwjk9obnph4.fsf@cassin.dcs.aber.ac.uk> pcg@aber.ac.uk
tiggr> (Piercarlo Grandi) writes:

piercarl> Consider:
piercarl> class C // bounded stack [ ... ]

piercarl> This defines a class and a type encapsulated within it. Now
piercarl> suppose we just added something like the following two
piercarl> procedures:

piercarl> class C // bounded deque [ ... ]
piercarl> void *get(); void put(void *) { .... }

piercarl> is the second 'C' the same type as the first 'C", only
piercarl> updated? To me they are completely different types, for they
piercarl> have different semantics, as well as different interface.
piercarl> Instances of one 'C' are not instances of the other 'C'.

tiggr> There are (many, very) valid examples of adding methods to a
tiggr> class, which do not change the semantics of the object.

I and tempted to be flippant here, as I am occasionally :-) when reading
this sort of "=A3$%^&* statement, and comment "think harder".

Actually instead I will agree with you, by saying that this statement
may well be regarded as being true if one considers that by adding any
number of procedures computing the identity function to a class, the
algebra it implements does not ``really'' change.

But surely your statement clashes _badly_ with your subsequent example:

tiggr> In the example, only adding a `print' method, with the obvious
tiggr> functionality, would not change the semantics of the existing
tiggr> stack objects.  Nor would it create a new class.  The stack
tiggr> objects would just be able to print themselves.

Here we have the fantastic notion that "just able to print themselves"
("just"!) computes such a ``minuscule'' function that the algebra
implemented by the class has not ``really'' changed. This is profoundly
wrong. Plese spare me illustrating the reasons why...

Let me just state that I can hardly imagine altering a class in such a
way that it does not implement a new algebra, except for the trivial
cases (adding no-op procedures, rewriting a procedure but having it
still compute the same function).

Also, in some important way this is beyond the point: in most languages
out there ``type'' equivalence is not based on equivalence of the
denotations of two types, but on ``name'' identity (not even
``structural'' identity, for even this involves subtle problems).

tiggr> Objective-C (at least the GNU and NeXT implementations) allows
                                              =3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
tiggr> methods to be added to a class in a running program.  NeXT's
tiggr> runtime library allows method replacement.
       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

This is not quite the case, to put it mildly, and the underlined bits
indicate why: some ``Objective-C'' *implementations* allow programs to
``reflect'' on their runtime support structures, and even to alter them;
programs can add pointers to method *representations* to data structures
*representing* classes, which is quite (!) a different thing from
allowing the addition of methods to classes. I am not aware of any
``Objective-C'' variants (or any popular, non-research-only) languages
out there that allow programs to do the latter, but perhaps I am just
behind the times (actually on reflection FORTH allows just that, but
arguably by blurring the distinction between the language and its
representation, and arguably CLOS does too, but then I would not call
CLOS a popular language).

One reason is perhaps that research in self-modifying programs is not
popular, for it is not easy. The ability to alter classes, or any other
part of a program, at runtime involves a number of hard conceptual
problems; they can be sidestepped, or at least so it might seem, by
providing (useful) implementation hacks, which are however a way for
language designers to pass the bucket for the solution of those
difficult problems to the programmers that use the hacks.

Note that even bits of research that seriously address representation
and semantics issues, like the relational model(s), only provide hints
towards handling things like schema evolution for databases; and much of
the popular stuff out there that might allow to do that is based on
seat-of-the-pants ``concepts''.

This is sad, but then addressing maintainability concerns seems to win
less sales and publish less papers than delivering ``new and improved''
features. :-)

tiggr> [ ... Cecil and TOM may/may not allow hacking implementations or
tiggr> rather their language-level constructs ... ]

I am not sure either; they are mostly research-in-progress, and I have
not used either.

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Rolf Breuning]

Richie Bielak wrote:
> 
> Eric Clayberg wrote:
> >
> > Richie Bielak wrote:
> > > but static typing _proves_ absence of certain kinds of errors.
> >
> > That's all well and good, but if the percentage of those kinds of errors
> > is absurdly low in your application to begin with, it doesn't buy you
> > very much.
> What also wanted to say in my previous post is that static typing
> proves that there is no call in the program that will cause
> the "message not understood" error.
> 
> Is the chance of this kind of error "absurdly low"?
Yes, it is, if you don't count sending messages to nil.
[ I've been programming in Smalltalk for over 6 years now. As Eric
stated, the usual reason for a "message not understood" is a message
send to nil ]



**********************************************************************
* Rolf Breuning                             breu@eecs.rwth-aachen.de *
* Bahnhofstr.7                                     using OS/2 Warp 4 *
* D-52064 Aachen                             - standard disclaimer - *
**********************************************************************

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Jun Nolasco]

Richie Bielak wrote:
> What also wanted to say in my previous post is that static typing
> proves that there is no call in the program that will cause
> the "message not understood" error.
> 
> Is the chance of this kind of error "absurdly low"?


	In my experience, quite low. I don't know if "absurdly low."



						Jun Nolasco
						nolasco@inx.net

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Mark Windholtz]

Richie Bielak wrote:
> 
> but static typing _proves_ absence of certain kinds of errors.
>

> What also wanted to say in my previous post is that static typing
> proves that there is no call in the program that will cause
> the "message not understood" error.
> 

  Unless you CAST anywhere in your program.
  Then the static language version of "message not understood"
  is either an exception or a core dump.

  I would rather see a "message not understood"
  than a core dump or even an unhandled exception.

  In other words, static typing does not _prove_
  that all objects understand all messages sent to them.
  Because casting is a way to defeat the compiler.
   
  This is my experience with C++ anyway.  Please
  comment if casting in Eiffel provides the same
  opportunity for run-time errors.

  The consequences of such runtime errors are
  less severe in Smalltalk because it will not
  core dump (mostly).
 
 ~Mark
 -----------------------------------------
 Cincinnati Smalltalk Users Group
 http://www.infinet.com/~mwind/st_users.htm  
 -----------------------------------------
 Mark.Windholtz@sdrc.com   (513) 576-5626

Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Richie Bielak]

Mark Windholtz wrote:
> 
> Richie Bielak wrote:
> >
> > but static typing _proves_ absence of certain kinds of errors.
> >
> 
> > What also wanted to say in my previous post is that static typing
> > proves that there is no call in the program that will cause
> > the "message not understood" error.
> >
> 
>   Unless you CAST anywhere in your program.
>   Then the static language version of "message not understood"
>   is either an exception or a core dump.
> 

[...]
 
>   This is my experience with C++ anyway.  Please
>   comment if casting in Eiffel provides the same
>   opportunity for run-time errors.
> 
>   The consequences of such runtime errors are
>   less severe in Smalltalk because it will not
>   core dump (mostly).
> 

Eiffel has no C-style casting. Instead Eiffel provides the "reverse
assigment 
attempt" operator to do safe "downcasting" when needed.

...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: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!)

[Alan Knight]

In article <32E764D0.23D9@calfp.com>, Richie Bielak <richieb@calfp.com> wrote:
>The short answer to you comment is:
>        
>        "Testing only proves existence of errors, not their absence"
>                                
>but static typing _proves_ absence of certain kinds of errors.

.. which is why all production systems should be using formal verification 
techniques to prove their programs correct. After all, provable correctness, 
no matter what the cost, is the ultimate goal, right?


--
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: Static vs. Dynamic typing again (was Re: OO, C++, and something mu

[Joachim Durchholz]

Mark wrote:

>   This is my experience with C++ anyway.  Please
>   comment if casting in Eiffel provides the same
>   opportunity for run-time errors.

Casting in Eiffel is possible (via the assignment attempt - you assign,  
and if the run-time check doesn't work, the assigned-to variable will hold  
"void" as a value).
There is no core dump or exception involved, except if you use the  
assigned-to variable afterwards without checking wether the assignment  
attempt worked.
Anyway Eiffel exceptions are somewhat more disciplined than C++ exceptions  
(though they are quite different than "message not understood").

>   The consequences of such runtime errors are
>   less severe in Smalltalk because it will not
>   core dump (mostly).

Same holds for Eiffel programs :)

Regards,
-Joachim

--
Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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

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

[Norman H. Cohen]

[Distribution for this post trimmed to comp.lang.ada]

Brian Rogoff wrote:

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

Not clear to me.  I think the existence of tags as run-time values is a
good head start.  An important missing piece, though, is the ability,
given a tag, to create an object of the corresponding type, as one can
do in Java with java.lang.Class.newInstance.  There are no technical
obstacles to providing a similar facility in Ada 95; T'Class'Input
already has to do essentially the same thing (albeit with an external
rather than internal tag).

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

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

[Eric W. Nikitin]

Norman H. Cohen (ncohen@watson.ibm.com) wrote:
: [Distribution for this post trimmed to comp.lang.ada]
: 
: Brian Rogoff wrote:
: 
: >         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.
: 
: Not clear to me.  I think the existence of tags as run-time values is a
: good head start.  An important missing piece, though, is the ability,
: given a tag, to create an object of the corresponding type, as one can
: do in Java with java.lang.Class.newInstance.  There are no technical
: obstacles to providing a similar facility in Ada 95; T'Class'Input
: already has to do essentially the same thing (albeit with an external
: rather than internal tag).
: 

There is certainly no technical obstacle simply because Ada provides
static typing. In fact, a thorough discussion of how such a feature
can be added to Oberon is available at,

ftp://ftp.inf.ethz.ch/pub/publications/dissertations/th10655.ps

I'm afraid I don't know enough about Ada to suggest how to apply
such a facility to it. 
-- 
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: 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: 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!

[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!

[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!

[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!

[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: 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!

[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!

[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!

[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

"(Sub)type" -safety

[Don Harrison]

Thread renamed and cross-posting restricted to cle and cla.
 
Norman H. Cohen writes:

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

Not "confused by", but thanks for the suggestion :)

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

Yes, it's true that the closest analogue of Eiffel "subtypes" in Ada is 
probably derived types. Also, I acknowledge that the analogue of Ada subtypes 
is not Eiffel "subtypes". A better analogue might be preconditions on 
routines. These effectively create (in my mind, if no-one else's :)) an 
anonymous "(sub)type". 

eg. do_something (a: INTEGER) is
    require in_range: a >= 1 and a <= 10
    ...

This may be what Matthew had in mind.
 
: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), 

Eiffel's actually a bit different here. This occurs implicitly in two types
of reattachment: 

1) Reserse assignment attempt (which doesn't cause a runtime error), and
2) Operation parameter substitution (which may).

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

Fair enough.

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

I wasn't but accept that it's true.

:In either Eiffel or Ada, conversion downwards in a type hierarchy should
:be rare in a good object-oriented design.  

True.

:(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.)

Hopefully, we've reached some agreement and you can get back to aguing with
the Smalltalkers. :)


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

Re: "(Sub)type" -safety

[Jon S Anthony]

In article <E4r6EJ.F95@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Yes, it's true that the closest analogue of Eiffel "subtypes" in Ada
> is probably derived types.

A bullseye!

> Also, I acknowledge that the analogue of
> Ada subtypes is not Eiffel "subtypes". A better analogue might be
> preconditions on routines. These effectively create (in my mind, if
> no-one else's :)) an anonymous "(sub)type".
>
> eg. do_something (a: INTEGER) is
>     require in_range: a >= 1 and a <= 10
>     ...

And another!!!! :-) Really, this is pretty much exactly the right way
of comparing the two in this area.  It's just that Ada subtypes don't
have the flexibility and range (sic) of Eiffel assertions.  They are a
relatively simple subcase.


> :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), 
> 
> Eiffel's actually a bit different here. This occurs implicitly in two types
> of reattachment: 
> 
> 1) Reserse assignment attempt (which doesn't cause a runtime error), and

Right - I think the Ada analogue here is really its "in" operator:

    if X in C'Class then -- do something like convert away from root

> 2) Operation parameter substitution (which may).

And this one is just like converting in Ada without first checking, and
can result in a runtime CE.


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

Re: "(Sub)type" -safety

[Don Harrison]

Jon S Anthony writes:

:In article <E4r6EJ.F95@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:
:
:> Yes, it's true that the closest analogue of Eiffel "subtypes" in Ada
:> is probably derived types.
:
:A bullseye!

:)

:> Also, I acknowledge that the analogue of
:> Ada subtypes is not Eiffel "subtypes". A better analogue might be
:> preconditions on routines. These effectively create (in my mind, if
:> no-one else's :)) an anonymous "(sub)type".
:>
:> eg. do_something (a: INTEGER) is
:>     require in_range: a >= 1 and a <= 10
:>     ...
:
:And another!!!! :-) 

:) :)

:Really, this is pretty much exactly the right way
:of comparing the two in this area.  It's just that Ada subtypes don't
:have the flexibility and range (sic) of Eiffel assertions.  They are a
:relatively simple subcase.
:
:
:> :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), 
:> 
:> Eiffel's actually a bit different here. This occurs implicitly in two types
:> of reattachment: 
:> 
:> 1) Reserse assignment attempt (which doesn't cause a runtime error), and
:
:Right - I think the Ada analogue here is really its "in" operator:
:
:    if X in C'Class then -- do something like convert away from root

Agree.

:> 2) Operation parameter substitution (which may).
:
:And this one is just like converting in Ada without first checking, and
:can result in a runtime CE.

Agree.

Jon, I'm speechless! We actually seem to agree. :)


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

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!

[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: 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!

[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!

[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!

[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 <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 <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!

[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!

[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!

[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!

[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 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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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: Multiple Type Interfaces

[Joachim Durchholz]

Dave wrote:

> tightly coupled.  Nevertheless, why not define a language so components can
> export multiple types which may be extended in other related "derived"
> components?

This is quite along some lines I've been thinking too, for totally  
unrelated reasons. It is one of the solutions being considered in the OO  
language research community for the problems that arise around the  
following keywords:
- parallel type hierarchies
- binary methods
- covariant vs. contravariant parameter redefinition
Unfortunately, no definite answer has been presented yet.

I'm about to relocate, so I can't give any references right now, but mail  
me in a week or two and I may be able to dig up a few names and URLs.

Regards,
-Joachim

--
Joachim Durchholz, Hans-Herold-Str. 25, D-91074 Herzogenaurach, GERMANY

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!

[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!

[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!

[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!

[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!

[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!

[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: 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!

[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]

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: 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]

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

[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]

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!

[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!

[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!

[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!

[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!

[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!

[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!

[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 :-) ... ]

Definition of "operator" (was: OO, C++, and something much better!)

[Alan Lovejoy]

Jon S Anthony wrote:
> 
> 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".

Ok.

So here's a theory:  the term "operator" in programming languages was 
coined by applying it to those built-in procedures which were intended
to 
be analogs of math functions that formally qualify as "operations." 
Later, 
other "built-in" procedures also got called "operators" by (uninformed) 
analogy.

If the theory is true, then a case could be made that a procedure should 
be called an "operation" (and its name an "operator") if its math analog 
formally qualifies as an "operation" (a function whose domain is an
n-order 
set and whose range is a 1-order set, such as "f(Complex, Complex):
Complex").

I'm not advocating this definition for use in computer science, but just
suggesting it as a point of discussion.  It could be criticised as an 
ill-advised attempt to pretend that math functions and program
procedures 
are equivalent (perhaps Piercarlo would like to comment?).  It could
also be 
criticized as not in accord with current practice in various programming 
languages (but whether that matters is debatable, since the terminology
of 
language-independent computer science can differ from that of any
particular 
programming language).

Also, if the proposed definition of "operator/operation" is adopted,
what 
would be a good term for tokens such as "return" (in C or C++), or the
return 
("^") and assignment (":=") symbols in Smalltalk, that represent "built
in" 
actions whose semantics are defined by the language? Such have
frequently been 
called "operators" in the past.  Is that the "right" term, or should
some other 
term be used instead?  

So the question is: shat should the terms "operator" and "operation"
mean in 
computer science?  Do  you think the meaning of these terms should or
should
not be anologous to their meaning in math?  Why or why not?

--
Alan L. Lovejoy		| Why Smalltalk?
Smalltalk Consultant    | Because I don't want to follow the crowd,
alovejoy@concentric.net	| but to lead it.

Re: Definition of "operator" (was: OO, C++, and something much better!)

[Dave Schaumann]

Alan Lovejoy <alovejoy@concentric.net> wrote in article
<330789FA.40A5@concentric.net>...
> 
> So here's a theory:  the term "operator" in programming languages was 
> coined by applying it to those built-in procedures which were intended
> to 
> be analogs of math functions that formally qualify as "operations." 

Yeah, probably.  Certainly one of the first uses of computers was to
model mathematical things.  The problem is, computers (at least from
an OO point of view) model things in terms of what services they provide,
while mathematics models things in terms of what properties they have.
In mathematics, the statement "1 + 1 = 2" really means there is a set
called "+" containing the value (<1, 1>, 2).  In the computer realm,
"1 + 1 = 2" means the ALU object provides an addition service, which
when given the inputs 1 and 1 results in 2.

> If the theory is true, then a case could be made that a procedure should 
> be called an "operation" (and its name an "operator") if its math analog 
> formally qualifies as an "operation" (a function whose domain is an
> n-order 
> set and whose range is a 1-order set, such as "f(Complex, Complex):
> Complex").

> [...]  It could be criticised as an ill-advised attempt to pretend
> that math functions and program procedures are equivalent

Just so.  There are some similarities between CS and mathematics that
can be usefully exploited, but it's not hard to go past what these
similarities warrant (take, for example, the "circle is/is not an ellipse
argument on another thread).

> So the question is: shat should the terms "operator" and "operation"
> mean in computer science?

What do you mean "in computer science"?  If you mean "within a programming
language", then an operator is whatever the language definition says it
is.

> Do  you think the meaning of these terms should or should
> not be anologous to their meaning in math?

Certainly not.

> Why or why not?

Because "CS operators" are fundamentally different from "Math operators".
CS operators perform calculations.  Math operators express a relationship.

-Dave

Re: Definition of "operator" (was: OO, C++, and something much better!)

[Anders Pytte]

In article <01bc1eb2$8fdb7ef0$5f030514@dschauma>, "Dave Schaumann"
<dschauma@csci.csc.com> wrote:

> Alan Lovejoy <alovejoy@concentric.net> wrote in article
> <330789FA.40A5@concentric.net>...
> > 
> > So here's a theory:  the term "operator" in programming languages was 
> > coined by applying it to those built-in procedures which were intended
> > to 
> > be analogs of math functions that formally qualify as "operations." 
> 
> Yeah, probably.  Certainly one of the first uses of computers was to
> model mathematical things.  The problem is, computers (at least from
> an OO point of view) model things in terms of what services they provide,
> while mathematics models things in terms of what properties they have.
> In mathematics, the statement "1 + 1 = 2" really means there is a set
> called "+" containing the value (<1, 1>, 2).  In the computer realm,
> "1 + 1 = 2" means the ALU object provides an addition service, which
> when given the inputs 1 and 1 results in 2.
> 
> > If the theory is true, then a case could be made that a procedure should 
> > be called an "operation" (and its name an "operator") if its math analog 
> > formally qualifies as an "operation" (a function whose domain is an
> > n-order 
> > set and whose range is a 1-order set, such as "f(Complex, Complex):
> > Complex").
> 
> > [...]  It could be criticised as an ill-advised attempt to pretend
> > that math functions and program procedures are equivalent
> 
> Just so.  There are some similarities between CS and mathematics that
> can be usefully exploited, but it's not hard to go past what these
> similarities warrant (take, for example, the "circle is/is not an ellipse
> argument on another thread).
> 
> > So the question is: shat should the terms "operator" and "operation"
> > mean in computer science?
> 
> What do you mean "in computer science"?  If you mean "within a programming
> language", then an operator is whatever the language definition says it
> is.
> 
> > Do  you think the meaning of these terms should or should
> > not be anologous to their meaning in math?
> 
> Certainly not.
> 
> > Why or why not?
> 
> Because "CS operators" are fundamentally different from "Math operators".
> CS operators perform calculations.  Math operators express a relationship.
> 
> -Dave

Recall that "mathematics" is a different beast than "arithmetic". I
believe the term "operation", implying an action, and the term "operand",
implying the thing acted upon, were used in arithmetic much the way they
are now used in computer lingo, before computers were around.

The terms necessarily have different use in mathematics than in
arithmetic, since the actions being performed are more on the order of
"transformations".

To bring in set theory unnecessarily complicates the issue, although I
suppose it impresses some of us. People have been adding and subtracting
for a long time with out any underlying set theoretical formulation of
what they were doing.

You know, words had meaning before computers were around. Why is there
such reluctance to be matter of fact common sense practical about these
things? I guess that would make boring conversation.

Anders.

-- 
Anders Pytte            Milkweed Software
RR 1, Box 227           Voice: (802) 472-5142
Cabot VT 05647          Internet: milkweed@plainfield.bypass.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!

[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!

[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: 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!

[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!

[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!

[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!

[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!

[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 <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: Definition of "operator" (was: OO, C++, and something much better!)

[Alan Lovejoy]

Jon S Anthony wrote:
> 
> In article <330789FA.40A5@concentric.net> Alan Lovejoy <alovejoy@concentric.net> writes:
> > So here's a theory: the term "operator" in programming languages was
> > coined by applying it to those built-in procedures which were
> > intended to be analogs of math functions that formally qualify as
> > "operations."  Later, other "built-in" procedures also got called
> > "operators" by (uninformed) analogy.
> 
> That's probably pretty much what happened.  It would be interesting to
> hear from Robert Dewar on this as he seems to have a lot of insight
> (inside info?) on the history of programming language design.
> 
> > If the theory is true, then a case could be made that a procedure
> > should be called an "operation" (and its name an "operator") if its
> > math analog formally qualifies as an "operation" (a function whose
> > domain is an n-order set and whose range is a 1-order set, such as
> > "f(Complex, Complex): Complex").
> 
> Just to be clear, the range is not just any ol' "1-order set" it's the
> same set used in defining the n-order domain set.

Understood. My statement was unintentionally incomplete.

> What I'm having trouble with here (and in the discussion that prompted
> this new thread) is what distinguishing the notions of "operator" and
> "operation" buys you in the context of CS/PLs.  I'm not saying it's
> worthless, I'm just not clear on why people think it is useful here.

The terms are already used--inconsistently, and without formal
precision.
At a minimum, the "value add" is to clean that up.  And hopefully, to
also benefit from some well-chosen definition of the terms.

> > Also, if the proposed definition of "operator/operation" is adopted,
> > what would be a good term for tokens such as "return" (in C or C++),
> > or the return ("^") and assignment (":=") symbols in Smalltalk, that
> > represent "built in" actions whose semantics are defined by the
> > language?
> 
> "Intrinsics"?  But then, I think this term is already used for various
> other things...

"Intrinsic" works better as an adjective.

> > So the question is: shat should the terms "operator" and "operation"
> > mean in computer science?  Do you think the meaning of these terms
> > should or should not be anologous to their meaning in math?  Why or
> > why not?
> 
> Shouldn't the first questions be: What use is there in distinguishing
> these terms in CS/PLs?  And, why would you want to do that (what's the
> point)?

Yes, the qustion of utility should be the primary motivator.

The point is to get rid of inconsistency and to establish the agreed
upon 
usage of common terms--and perhaps to also formally define them, if
possible.

--
Alan L. Lovejoy		| Why Smalltalk?
Smalltalk Consultant    | Because I don't want to follow the crowd,
alovejoy@concentric.net	| but to lead it.

Re: Definition of "operator" (was: OO, C++, and something much better!)

[David L. Shang]

In article <33091940.55A8@concentric.net> Alan Lovejoy  
<alovejoy@concentric.net> writes:

> The point is to get rid of inconsistency and to establish the agreed
> upon usage of common terms--and perhaps to also formally define them, if
> possible.
> 

Have a look at Transframe's expression design. Just a few syntax rules
result in a more powerful and flexible expressions than C++'s. The definition
of operators in Transframe is simple, consistent and user-definable.
For detail, check

	http://www.transframe.com/

at Research/TransframeLanguage page, especially, the article

	The Expressive Function of a Language

David Shang

Re: Definition of "operator" (was: OO, C++, and something much better!)

[Jon S Anthony]

In article <1997Feb19.163312.4426@schbbs.mot.com> shang@corp.mot.com (David L. Shang) writes:

> In article <33091940.55A8@concentric.net> Alan Lovejoy  
> <alovejoy@concentric.net> writes:
> 
> > The point is to get rid of inconsistency and to establish the agreed
> > upon usage of common terms--and perhaps to also formally define them, if
> > possible.
> > 
> 
> Have a look at Transframe's expression design. Just a few syntax rules
> result in a more powerful and flexible expressions than C++'s. The definition
> of operators in Transframe is simple, consistent and user-definable.

You've completely missed the point.  That any _particular_ language
has a so called "consistent use" of the terms "operator" and
"operation" is irrelevant.  After all, any formally defined one will
and _most_ standards defined ones will (as these two sets are not in
a subset relation).

/Jon

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

Re: Definition of "operator" (was: OO, C++, and something much better!)

[David L. Shang]

In article <JSA.97Feb21152149@alexandria> jsa@alexandria (Jon S Anthony)  
writes:
> In article <1997Feb19.163312.4426@schbbs.mot.com> shang@corp.mot.com (David  
L. Shang) writes:
> > Have a look at Transframe's expression design. Just a few syntax rules
> > result in a more powerful and flexible expressions than C++'s. The 
> > definition of operators in Transframe is simple, consistent and 
> > user-definable.
> 
> You've completely missed the point.  That any _particular_ language
> has a so called "consistent use" of the terms "operator" and
> "operation" is irrelevant.  After all, any formally defined one will
> and _most_ standards defined ones will (as these two sets are not in
> a subset relation).
> 

Please be specific. Few people can understand what you stated above,
I guess. Perhaps, we are talking about different things.

David Shang

Re: Definition of "operator" (was: OO, C++, and something much better!)

[Jon S Anthony]

In article <1997Feb24.144102.8669@schbbs.mot.com> shang@corp.mot.com (David L. Shang) writes:

> L. Shang) writes:
> > > Have a look at Transframe's expression design. Just a few syntax rules
> > > result in a more powerful and flexible expressions than C++'s. The 
> > > definition of operators in Transframe is simple, consistent and 
> > > user-definable.
> > 
> > You've completely missed the point.  That any _particular_ language
> > has a so called "consistent use" of the terms "operator" and
> > "operation" is irrelevant.  After all, any formally defined one will
> > and _most_ standards defined ones will (as these two sets are not in
> > a subset relation).
> > 
> 
> Please be specific. Few people can understand what you stated above,
> I guess. Perhaps, we are talking about different things.

??  How specific can I get?  You are saying that Transframe has some
consistent (maybe even nice) notions and syntax for "operators" and
"operations".  Shrug.  The discussion has _not_ been about any
_specific_ language's use/form/definition of these terms, but about
whether there is any general notion for them in CS/PL land.

Specific enough?

/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 <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!

[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!

[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: Definition of "operator" (was: OO, C++, and something much better!)

[Jon S Anthony]

In article <330789FA.40A5@concentric.net> Alan Lovejoy <alovejoy@concentric.net> writes:

> Jon S Anthony wrote:
> > 
> > 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".
> 
> Ok.
> 
> So here's a theory: the term "operator" in programming languages was
> coined by applying it to those built-in procedures which were
> intended to be analogs of math functions that formally qualify as
> "operations."  Later, other "built-in" procedures also got called
> "operators" by (uninformed) analogy.

That's probably pretty much what happened.  It would be interesting to
hear from Robert Dewar on this as he seems to have a lot of insight
(inside info?) on the history of programming language design.


> If the theory is true, then a case could be made that a procedure
> should be called an "operation" (and its name an "operator") if its
> math analog formally qualifies as an "operation" (a function whose
> domain is an n-order set and whose range is a 1-order set, such as
> "f(Complex, Complex): Complex").

Just to be clear, the range is not just any ol' "1-order set" it's the
same set used in defining the n-order domain set.

What I'm having trouble with here (and in the discussion that prompted
this new thread) is what distinguishing the notions of "operator" and
"operation" buys you in the context of CS/PLs.  I'm not saying it's
worthless, I'm just not clear on why people think it is useful here.


> Also, if the proposed definition of "operator/operation" is adopted,
> what would be a good term for tokens such as "return" (in C or C++),
> or the return ("^") and assignment (":=") symbols in Smalltalk, that
> represent "built in" actions whose semantics are defined by the
> language?

"Intrinsics"?  But then, I think this term is already used for various
other things...


> So the question is: shat should the terms "operator" and "operation"
> mean in computer science?  Do you think the meaning of these terms
> should or should not be anologous to their meaning in math?  Why or
> why not?

Shouldn't the first questions be: What use is there in distinguishing
these terms in CS/PLs?  And, why would you want to do that (what's the
point)?

/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 <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!

[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 <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!

[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 <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 <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 <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!

[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: Definition of "operator" (was: OO, C++, and something much better!)

[Richard Katz]

Alan Lovejoy wrote:
> 
> So the question is: shat should the terms "operator" and "operation"
> mean in
> computer science?  Do  you think the meaning of these terms should or
> should
> not be anologous to their meaning in math?  Why or why not?

Alan,

I think you're on to something.  You could say that operators are simply
operations for which there is a character infix rather than a functional
prefix notation.  

I'm concerned with something slightly different: the hierarchy of
operators.  But I think the discussion is ueeful in telling us something
about operators themselves.  If we look at "operator" in it's historical
context 1) in it's mathematical history 2) as a computer language
implementation, and 3) in terms of methods of computation, we find:

1)  In a historical context, the hierarchy of operators came from
trade.  It was easier to represent 52 sheep as "5 10's plus 2", 5 x 10 +
2 because this was the way they were counted off at both send and
delivery.  

So mathematical operators, and their hierarchy have a historical
context.  But we would have to look very hard to find a similar history
for other operators or operations such as ssy, string operators.  

But what about logical operators?  In human terms, "or" is usually local
(applied first) while "and" is global (applied later).  "Doctors or
Nurses in Minnesota or Wisconsin" in human terms means (Doctor or Nurse)
AND (Minnesota or Wisconsin).  

But this hierarchy is rarely if ever represented in computer language. 
If any hierarchy exists, it usually that AND is local and so defeats the
human intent, thereby making computer languages (including SQL) less
tractable to the average human.  

2)  Early attempts at implementing computer language operators in the
FORTRAN language were to capture human mathematics.  Thus the human
hierarchy of mathematical operators was also emulated in FORTRAN, and
numerous follow-on languages.  

Whether this needs to be so or not is a matter of language purpose. 
Other languages have different purposes and philosophies.  Note that the
APL language extends the operator notation but eliminates hierarchy. It
considered that all kinds of operations were symbolized by single or
short multiple characters and could be used as infix or prefix.  
Between C and C++ there is a major difference.  The "routing" purpose of
operators built into both C and UNIX is extended in C++ so that the
concept of overloading makes operators into methods with different
notation.  In the PROLOG language, many non-PROLOG constructs and
operator hierarchies can be represented.  

As a result, my answer to your question becomes: 1) There need be no
fundamental difference between operators and operations.  2) However,
operators have a historical context which the language may or may not
choose to represent, and 3) within that context operators have hierarchy
which might be difficult to extend to all operations or even all
operators.

3) Computation. The definition of "computing machine" and "computing
language" have grown concurrently.  Realize, that idea "virtual
machine," or machine concept in no way belongs strictly to Java. 
Pascal, C, Prolog, and LISP have or have had machine concepts or VMs. 
Both FORTRAN as a mathematical represntation, and simply "internally
programmmed computer" were based on a machine concept - not on a
machine.  The machine and how it would be programmed grew over a twenty
year process before one was actually created and programmed.

Due to computation method, representations such as FORTRAN, while
useful, are not totally compatible with human mathematics,  "Assignment"
is not the same as "premise."  As a premise you might state:

    X = 7
    3*Y = X+4

    PRINT Y

However, in Fortran, you could never state "3*Y = X+4" because the equal
operator is simply an assignment, and you can't assign something to "3
times Y."  This being an unsatisfactory outcome of FORTRAN, computer
scientists went on to define symbolic processing languages such as
FORMAC, FORMAL, and other mathematical languages.  

Even so, while other computation operators have a math heritage, the "="
operator generally does not. Instead, "=" most generally conveys the
placement of a value into a memory location.  The fact that this memory
location is referred to as a "variable" makes it so only in the context
of a complete program, not in the context of expressing mathematical
formula.  

Thus, if you were to try to change the meaning of "=" to denote premise
equality, you would want a machine that likewise conveys premise
equality rather than assignment and variables to be real variables
rather than memory locations.  I would suggest that premise equality,
operator hierarchy, and thus operators themselves belong to the study of
NL, in that they are representations of reality expressed in language.  

If some OO implementation chose to try to do the same thing, that would
be quite interesting.  One question I would have is whether some of the
extensions would be culturally and even memetically bound.  The near
universal acceptance of "=" to mean assignment in computer language
might be a meme which is itself an example and subclass of the historic
relationship between machine and language.  Attempts to redefine
"operator" within an OO language would be well advised to consult
history and human usage.


Richard Katz

Re: Definition of "operator" (was: OO, C++, and something much better!)

[David L. Shang]

In article <3310948B.29C1@earthlink.net> Richard Katz <richkatz@earthlink.net>  
writes:
> 
> Whether this needs to be so or not is a matter of language purpose. 
> Other languages have different purposes and philosophies.  Note that the
> APL language extends the operator notation but eliminates hierarchy. It
> considered that all kinds of operations were symbolized by single or
> short multiple characters and could be used as infix or prefix.  
> Between C and C++ there is a major difference.  The "routing" purpose of
> operators built into both C and UNIX is extended in C++ so that the
> concept of overloading makes operators into methods with different
> notation.  In the PROLOG language, many non-PROLOG constructs and
> operator hierarchies can be represented.  
> 

Transframe extents the operator notation further by allowing an arbitory
combination of operator strings as well as maintain a hierarchy via
a set of priority and association rules. An operator could be prefix
or non-prefix (which include infix,surfix, and any other dovetail-style
operators). Promotions are defined by mutiple operation interfaces which
is also used to replace the contentious concept of overloading.

> As a result, my answer to your question becomes: 1) There need be no
> fundamental difference between operators and operations. 

I agree. Operators are not specific built-in things in Transframe.
Like other normal operations, they are user-defined, including the
format of its usage. For example:

    function operator repeat (b: block)
		      every (t: float) second ()
		      until (k: int) times;

This user-defined operator provides a iterative construct that
repeats a block statement once every t second(s) until k times.
We can have an expression like:

   repeat
   {	bird.chirp();
	bunny.hop();
	pig.flop();
   } every 0.8 second until 15 times;

David Shang

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!

[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!

[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!

[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: 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!

[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!

[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!

[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!

[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!

[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!

[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!

[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!

[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: 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 ?

[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

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!

[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!

[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!

[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!

[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: 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!

[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!

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

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!

[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!

[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!

[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: 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!

[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!

[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: 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: 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: 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]

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!

[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!

[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!

[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!

[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: 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!

[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!

[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!

[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!

[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!

[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: 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!

[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!

[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!

[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: 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: 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!

[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!

[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: 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: 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: 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: 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!

[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: 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: 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: 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: 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: 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!

[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: 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: 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!

[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!

[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!

[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: 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!

[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]

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: 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!

[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!

[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!

[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!

[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!

[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!

[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: 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: 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: 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: 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: 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: 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: 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: 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!

[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