* Re: OO, C++, and something much better! @ 1997-01-27 0:00 Ell 0 siblings, 0 replies; 391+ messages in thread From: Ell @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better!
@ 1997-01-28 0:00 Snowball Info
0 siblings, 0 replies; 391+ messages in thread
From: Snowball Info @ 1997-01-28 0:00 UTC (permalink / raw)
Cc: Stephen J Bevan
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-----------------------------
^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! @ 1997-01-28 0:00 Ell 0 siblings, 0 replies; 391+ messages in thread From: Ell @ 1997-01-28 0:00 UTC (permalink / raw) 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 : ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! @ 1997-01-22 0:00 Ell 0 siblings, 0 replies; 391+ messages in thread From: Ell @ 1997-01-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! @ 1997-01-21 0:00 Ell 1997-01-21 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 0 siblings, 1 reply; 391+ messages in thread From: Ell @ 1997-01-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 Ell @ 1997-01-21 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 0 siblings, 0 replies; 391+ messages in thread From: Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-01-21 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better!
@ 1997-01-16 0:00 Jon S Anthony
1997-01-17 0:00 ` Don Harrison
` (10 more replies)
0 siblings, 11 replies; 391+ messages in thread
From: Jon S Anthony @ 1997-01-16 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 Jon S Anthony @ 1997-01-17 0:00 ` Don Harrison 1997-01-16 0:00 ` Matthew Heaney ` (8 more replies) 1997-01-21 0:00 ` Joachim Durchholz ` (9 subsequent siblings) 10 siblings, 9 replies; 391+ messages in thread From: Don Harrison @ 1997-01-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Don Harrison @ 1997-01-16 0:00 ` Matthew Heaney 1997-01-17 0:00 ` Alan Lovejoy 1997-01-22 0:00 ` Don Harrison 1997-01-20 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB ` (7 subsequent siblings) 8 siblings, 2 replies; 391+ messages in thread From: Matthew Heaney @ 1997-01-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 ` Matthew Heaney @ 1997-01-17 0:00 ` Alan Lovejoy 1997-01-17 0:00 ` Norman H. Cohen 1997-01-19 0:00 ` Keith Thompson 1997-01-22 0:00 ` Don Harrison 1 sibling, 2 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-17 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Alan Lovejoy @ 1997-01-17 0:00 ` Norman H. Cohen 1997-01-17 0:00 ` Alan Lovejoy 1997-01-19 0:00 ` Keith Thompson 1 sibling, 1 reply; 391+ messages in thread From: Norman H. Cohen @ 1997-01-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Norman H. Cohen @ 1997-01-17 0:00 ` Alan Lovejoy 1997-01-18 0:00 ` Fergus Henderson ` (2 more replies) 0 siblings, 3 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-17 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Alan Lovejoy @ 1997-01-18 0:00 ` Fergus Henderson 1997-01-17 0:00 ` Alan Lovejoy ` (14 more replies) 1997-01-21 0:00 ` Norman H. Cohen 1997-01-27 0:00 ` Jon S Anthony 2 siblings, 15 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson @ 1997-01-17 0:00 ` Alan Lovejoy 1997-01-20 0:00 ` Fergus Henderson ` (3 more replies) 1997-01-19 0:00 ` Soren Skogstad Nielsen ` (13 subsequent siblings) 14 siblings, 4 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-17 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Alan Lovejoy @ 1997-01-20 0:00 ` Fergus Henderson 1997-01-19 0:00 ` Alan Lovejoy 1997-01-20 0:00 ` Damon Feldman ` (2 subsequent siblings) 3 siblings, 1 reply; 391+ messages in thread From: Fergus Henderson @ 1997-01-20 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Fergus Henderson @ 1997-01-19 0:00 ` Alan Lovejoy 0 siblings, 0 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-19 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Alan Lovejoy 1997-01-20 0:00 ` Fergus Henderson @ 1997-01-20 0:00 ` Damon Feldman 1997-01-19 0:00 ` Alan Lovejoy ` (15 more replies) 1997-01-25 0:00 ` Robert Dewar 1997-01-25 0:00 ` Robert Dewar 3 siblings, 16 replies; 391+ messages in thread From: Damon Feldman @ 1997-01-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman @ 1997-01-19 0:00 ` Alan Lovejoy 1997-01-20 0:00 ` David Hanley ` (4 more replies) 1997-01-25 0:00 ` Jon S Anthony ` (14 subsequent siblings) 15 siblings, 5 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-19 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-19 0:00 ` Alan Lovejoy @ 1997-01-20 0:00 ` David Hanley 1997-01-21 0:00 ` Alan Lovejoy 1997-01-20 0:00 ` Bill Gooch ` (3 subsequent siblings) 4 siblings, 1 reply; 391+ messages in thread From: David Hanley @ 1997-01-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` David Hanley @ 1997-01-21 0:00 ` Alan Lovejoy 1997-01-22 0:00 ` Fergus Henderson 0 siblings, 1 reply; 391+ messages in thread From: Alan Lovejoy @ 1997-01-21 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 ` Alan Lovejoy @ 1997-01-22 0:00 ` Fergus Henderson 1997-01-22 0:00 ` Alan Lovejoy 1997-01-23 0:00 ` Bob Jarvis 0 siblings, 2 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Fergus Henderson @ 1997-01-22 0:00 ` Alan Lovejoy 1997-01-23 0:00 ` Bob Jarvis 1 sibling, 0 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-22 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Fergus Henderson 1997-01-22 0:00 ` Alan Lovejoy @ 1997-01-23 0:00 ` Bob Jarvis 1 sibling, 0 replies; 391+ messages in thread From: Bob Jarvis @ 1997-01-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-19 0:00 ` Alan Lovejoy 1997-01-20 0:00 ` David Hanley @ 1997-01-20 0:00 ` Bill Gooch 1997-01-20 0:00 ` Graham Hughes ` (2 subsequent siblings) 4 siblings, 0 replies; 391+ messages in thread From: Bill Gooch @ 1997-01-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-19 0:00 ` Alan Lovejoy 1997-01-20 0:00 ` David Hanley 1997-01-20 0:00 ` Bill Gooch @ 1997-01-20 0:00 ` Graham Hughes 1997-01-21 0:00 ` Alan Lovejoy 1997-01-22 0:00 ` Damon Feldman 1997-01-29 0:00 ` Joachim Durchholz 4 siblings, 1 reply; 391+ messages in thread From: Graham Hughes @ 1997-01-20 0:00 UTC (permalink / raw) -----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----- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Graham Hughes @ 1997-01-21 0:00 ` Alan Lovejoy 1997-01-21 0:00 ` Matt Kennel ` (2 more replies) 0 siblings, 3 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-21 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 ` Alan Lovejoy @ 1997-01-21 0:00 ` Matt Kennel 1997-01-21 0:00 ` Marc Robertson 1997-01-22 0:00 ` Fergus Henderson 2 siblings, 0 replies; 391+ messages in thread From: Matt Kennel @ 1997-01-21 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 ` Alan Lovejoy 1997-01-21 0:00 ` Matt Kennel @ 1997-01-21 0:00 ` Marc Robertson 1997-01-24 0:00 ` Mark Windholtz ` (2 more replies) 1997-01-22 0:00 ` Fergus Henderson 2 siblings, 3 replies; 391+ messages in thread From: Marc Robertson @ 1997-01-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 ` Marc Robertson @ 1997-01-24 0:00 ` Mark Windholtz 1997-01-27 0:00 ` David Hanley 1997-01-28 0:00 ` Alan Lovejoy 1997-01-29 0:00 ` Jun Nolasco 2 siblings, 1 reply; 391+ messages in thread From: Mark Windholtz @ 1997-01-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Mark Windholtz @ 1997-01-27 0:00 ` David Hanley 1997-01-28 0:00 ` Eric Clayberg ` (2 more replies) 0 siblings, 3 replies; 391+ messages in thread From: David Hanley @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` David Hanley @ 1997-01-28 0:00 ` Eric Clayberg 1997-01-28 0:00 ` David Hanley [not found] ` <32EE2FEE.62FE@p <32EE8415.2F5B@netright.com> 2 siblings, 0 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` David Hanley 1997-01-28 0:00 ` Eric Clayberg @ 1997-01-28 0:00 ` David Hanley [not found] ` <32EE2FEE.62FE@p <32EE8415.2F5B@netright.com> 2 siblings, 0 replies; 391+ messages in thread From: David Hanley @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
[parent not found: <32EE2FEE.62FE@p <32EE8415.2F5B@netright.com>]
* Re: OO, C++, and something much better! [not found] ` <32EE2FEE.62FE@p <32EE8415.2F5B@netright.com> @ 1997-01-28 0:00 ` Eric Clayberg 1997-01-29 0:00 ` David Hanley 0 siblings, 1 reply; 391+ messages in thread From: Eric Clayberg @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Eric Clayberg @ 1997-01-29 0:00 ` David Hanley 1997-01-29 0:00 ` Eric Clayberg 0 siblings, 1 reply; 391+ messages in thread From: David Hanley @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` David Hanley @ 1997-01-29 0:00 ` Eric Clayberg 0 siblings, 0 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 ` Marc Robertson 1997-01-24 0:00 ` Mark Windholtz @ 1997-01-28 0:00 ` Alan Lovejoy 1997-01-29 0:00 ` Matt Kennel 1997-01-29 0:00 ` Jun Nolasco 2 siblings, 1 reply; 391+ messages in thread From: Alan Lovejoy @ 1997-01-28 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Alan Lovejoy @ 1997-01-29 0:00 ` Matt Kennel 1997-01-30 0:00 ` Alan Lovejoy 0 siblings, 1 reply; 391+ messages in thread From: Matt Kennel @ 1997-01-29 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` Matt Kennel @ 1997-01-30 0:00 ` Alan Lovejoy 1997-01-30 0:00 ` David L. Shang 0 siblings, 1 reply; 391+ messages in thread From: Alan Lovejoy @ 1997-01-30 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-30 0:00 ` Alan Lovejoy @ 1997-01-30 0:00 ` David L. Shang 0 siblings, 0 replies; 391+ messages in thread From: David L. Shang @ 1997-01-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 ` Marc Robertson 1997-01-24 0:00 ` Mark Windholtz 1997-01-28 0:00 ` Alan Lovejoy @ 1997-01-29 0:00 ` Jun Nolasco 2 siblings, 0 replies; 391+ messages in thread From: Jun Nolasco @ 1997-01-29 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 ` Alan Lovejoy 1997-01-21 0:00 ` Matt Kennel 1997-01-21 0:00 ` Marc Robertson @ 1997-01-22 0:00 ` Fergus Henderson 1997-01-22 0:00 ` Eric Clayberg ` (4 more replies) 2 siblings, 5 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Fergus Henderson @ 1997-01-22 0:00 ` Eric Clayberg 1997-01-22 0:00 ` Graham Hughes ` (4 more replies) 1997-01-22 0:00 ` Fergus Henderson ` (3 subsequent siblings) 4 siblings, 5 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Eric Clayberg @ 1997-01-22 0:00 ` Graham Hughes 1997-01-23 0:00 ` Eric Clayberg ` (2 more replies) 1997-01-23 0:00 ` Robb Nebbe ` (3 subsequent siblings) 4 siblings, 3 replies; 391+ messages in thread From: Graham Hughes @ 1997-01-22 0:00 UTC (permalink / raw) -----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----- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Graham Hughes @ 1997-01-23 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Claus Reinke 1997-01-24 0:00 ` Don Harrison 1997-01-23 0:00 ` Mark Woodruff 1997-01-24 0:00 ` Richard A. O'Keefe 2 siblings, 2 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Eric Clayberg @ 1997-01-23 0:00 ` Claus Reinke 1997-01-25 0:00 ` Eric Clayberg 1997-01-24 0:00 ` Don Harrison 1 sibling, 1 reply; 391+ messages in thread From: Claus Reinke @ 1997-01-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Claus Reinke @ 1997-01-25 0:00 ` Eric Clayberg 1997-01-24 0:00 ` Static vs. Dynamic typing again (was Re: OO, C++, and something much better!) Robb Nebbe ` (3 more replies) 0 siblings, 4 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: Static vs. Dynamic typing again (was Re: OO, C++, and something much better!) @ 1997-01-24 0:00 ` Robb Nebbe 1997-01-25 0:00 ` OO, C++, and something much better! David N. Smith 0 siblings, 1 reply; 391+ messages in thread From: Robb Nebbe @ 1997-01-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Static vs. Dynamic typing again (was Re: OO, C++, and something much better!) Robb Nebbe @ 1997-01-25 0:00 ` David N. Smith 0 siblings, 0 replies; 391+ messages in thread From: David N. Smith @ 1997-01-25 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Eric Clayberg 1997-01-24 0:00 ` Static vs. Dynamic typing again (was Re: OO, C++, and something much better!) Robb Nebbe @ 1997-01-25 0:00 ` Fergus Henderson 1997-01-25 0:00 ` Lawrence G. Mayka 1997-01-28 0:00 ` Claus Reinke 3 siblings, 0 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-25 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Eric Clayberg 1997-01-24 0:00 ` Static vs. Dynamic typing again (was Re: OO, C++, and something much better!) Robb Nebbe 1997-01-25 0:00 ` Fergus Henderson @ 1997-01-25 0:00 ` Lawrence G. Mayka 1997-01-28 0:00 ` Claus Reinke 3 siblings, 0 replies; 391+ messages in thread From: Lawrence G. Mayka @ 1997-01-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Eric Clayberg ` (2 preceding siblings ...) 1997-01-25 0:00 ` Lawrence G. Mayka @ 1997-01-28 0:00 ` Claus Reinke 3 siblings, 0 replies; 391+ messages in thread From: Claus Reinke @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Claus Reinke @ 1997-01-24 0:00 ` Don Harrison 1997-01-24 0:00 ` Eric Clayberg 1 sibling, 1 reply; 391+ messages in thread From: Don Harrison @ 1997-01-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Don Harrison @ 1997-01-24 0:00 ` Eric Clayberg 1997-01-28 0:00 ` Don Harrison 0 siblings, 1 reply; 391+ messages in thread From: Eric Clayberg @ 1997-01-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Eric Clayberg @ 1997-01-28 0:00 ` Don Harrison 0 siblings, 0 replies; 391+ messages in thread From: Don Harrison @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Graham Hughes 1997-01-23 0:00 ` Eric Clayberg @ 1997-01-23 0:00 ` Mark Woodruff 1997-01-24 0:00 ` Richard A. O'Keefe 2 siblings, 0 replies; 391+ messages in thread From: Mark Woodruff @ 1997-01-23 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Graham Hughes 1997-01-23 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Mark Woodruff @ 1997-01-24 0:00 ` Richard A. O'Keefe [not found] ` <E4voIF.86o@world.std.com> 2 siblings, 1 reply; 391+ messages in thread From: Richard A. O'Keefe @ 1997-01-24 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
[parent not found: <E4voIF.86o@world.std.com>]
* Re: OO, C++, and something much better! [not found] ` <E4voIF.86o@world.std.com> @ 1997-02-12 0:00 ` Ulf Schuenemann 0 siblings, 0 replies; 391+ messages in thread From: Ulf Schuenemann @ 1997-02-12 0:00 UTC (permalink / raw) [-- 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/ ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Eric Clayberg 1997-01-22 0:00 ` Graham Hughes @ 1997-01-23 0:00 ` Robb Nebbe 1997-01-23 0:00 ` David Hanley 1997-01-25 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Matt Kennel ` (2 subsequent siblings) 4 siblings, 2 replies; 391+ messages in thread From: Robb Nebbe @ 1997-01-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Robb Nebbe @ 1997-01-23 0:00 ` David Hanley 1997-01-25 0:00 ` Eric Clayberg 1 sibling, 0 replies; 391+ messages in thread From: David Hanley @ 1997-01-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Robb Nebbe 1997-01-23 0:00 ` David Hanley @ 1997-01-25 0:00 ` Eric Clayberg 1 sibling, 0 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Eric Clayberg 1997-01-22 0:00 ` Graham Hughes 1997-01-23 0:00 ` Robb Nebbe @ 1997-01-23 0:00 ` Matt Kennel 1997-01-25 0:00 ` Eric Clayberg 1997-01-27 0:00 ` Jon S Anthony 1997-01-24 0:00 ` Fergus Henderson 1997-01-24 0:00 ` Richard A. O'Keefe 4 siblings, 2 replies; 391+ messages in thread From: Matt Kennel @ 1997-01-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Matt Kennel @ 1997-01-25 0:00 ` Eric Clayberg 1997-01-27 0:00 ` Jon S Anthony 1 sibling, 0 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Matt Kennel 1997-01-25 0:00 ` Eric Clayberg @ 1997-01-27 0:00 ` Jon S Anthony 1 sibling, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Eric Clayberg ` (2 preceding siblings ...) 1997-01-23 0:00 ` Matt Kennel @ 1997-01-24 0:00 ` Fergus Henderson 1997-01-24 0:00 ` Alan Lovejoy ` (5 more replies) 1997-01-24 0:00 ` Richard A. O'Keefe 4 siblings, 6 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-24 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Fergus Henderson @ 1997-01-24 0:00 ` Alan Lovejoy 1997-01-26 0:00 ` Fergus Henderson ` (4 subsequent siblings) 5 siblings, 0 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-24 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Fergus Henderson 1997-01-24 0:00 ` Alan Lovejoy @ 1997-01-26 0:00 ` Fergus Henderson [not found] ` <32E9BAAC. <5ce8t3$6gv@mulga.cs.mu.OZ.AU> ` (3 subsequent siblings) 5 siblings, 0 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-26 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
[parent not found: <32E9BAAC. <5ce8t3$6gv@mulga.cs.mu.OZ.AU>]
* Re: OO, C++, and something much better! [not found] ` <32E9BAAC. <5ce8t3$6gv@mulga.cs.mu.OZ.AU> @ 1997-01-28 0:00 ` Alan Lovejoy 0 siblings, 0 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-28 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Fergus Henderson ` (2 preceding siblings ...) [not found] ` <32E9BAAC. <5ce8t3$6gv@mulga.cs.mu.OZ.AU> @ 1997-01-28 0:00 ` Alan Knight 1997-01-29 0:00 ` Nick Leaton 1997-01-29 0:00 ` Fergus Henderson 1997-01-30 0:00 ` Alan Lovejoy 5 siblings, 1 reply; 391+ messages in thread From: Alan Knight @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Alan Knight @ 1997-01-29 0:00 ` Nick Leaton 0 siblings, 0 replies; 391+ messages in thread From: Nick Leaton @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Fergus Henderson ` (3 preceding siblings ...) 1997-01-28 0:00 ` Alan Knight @ 1997-01-29 0:00 ` Fergus Henderson 1997-01-30 0:00 ` Alan Lovejoy 5 siblings, 0 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Fergus Henderson ` (4 preceding siblings ...) 1997-01-29 0:00 ` Fergus Henderson @ 1997-01-30 0:00 ` Alan Lovejoy 5 siblings, 0 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-30 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Eric Clayberg ` (3 preceding siblings ...) 1997-01-24 0:00 ` Fergus Henderson @ 1997-01-24 0:00 ` Richard A. O'Keefe 4 siblings, 0 replies; 391+ messages in thread From: Richard A. O'Keefe @ 1997-01-24 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Fergus Henderson 1997-01-22 0:00 ` Eric Clayberg @ 1997-01-22 0:00 ` Fergus Henderson 1997-01-25 0:00 ` Joachim Durchholz ` (2 subsequent siblings) 4 siblings, 0 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Fergus Henderson 1997-01-22 0:00 ` Eric Clayberg 1997-01-22 0:00 ` Fergus Henderson @ 1997-01-25 0:00 ` Joachim Durchholz 1997-01-27 0:00 ` Rolf Breuning 1997-01-27 0:00 ` Ed Shirk 4 siblings, 0 replies; 391+ messages in thread From: Joachim Durchholz @ 1997-01-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Fergus Henderson ` (2 preceding siblings ...) 1997-01-25 0:00 ` Joachim Durchholz @ 1997-01-27 0:00 ` Rolf Breuning 1997-01-27 0:00 ` Ed Shirk 4 siblings, 0 replies; 391+ messages in thread From: Rolf Breuning @ 1997-01-27 0:00 UTC (permalink / raw) 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 - * ********************************************************************** ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Fergus Henderson ` (3 preceding siblings ...) 1997-01-27 0:00 ` Rolf Breuning @ 1997-01-27 0:00 ` Ed Shirk 4 siblings, 0 replies; 391+ messages in thread From: Ed Shirk @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-19 0:00 ` Alan Lovejoy ` (2 preceding siblings ...) 1997-01-20 0:00 ` Graham Hughes @ 1997-01-22 0:00 ` Damon Feldman 1997-01-29 0:00 ` Joachim Durchholz 4 siblings, 0 replies; 391+ messages in thread From: Damon Feldman @ 1997-01-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-19 0:00 ` Alan Lovejoy ` (3 preceding siblings ...) 1997-01-22 0:00 ` Damon Feldman @ 1997-01-29 0:00 ` Joachim Durchholz 4 siblings, 0 replies; 391+ messages in thread From: Joachim Durchholz @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman 1997-01-19 0:00 ` Alan Lovejoy @ 1997-01-25 0:00 ` Jon S Anthony 1997-01-25 0:00 ` Eric Clayberg ` (13 subsequent siblings) 15 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman 1997-01-19 0:00 ` Alan Lovejoy 1997-01-25 0:00 ` Jon S Anthony @ 1997-01-25 0:00 ` Eric Clayberg 1997-01-26 0:00 ` Robert Dewar 1997-02-08 0:00 ` Robin Rosenberg 1997-01-27 0:00 ` Eric Clayberg ` (12 subsequent siblings) 15 siblings, 2 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Eric Clayberg @ 1997-01-26 0:00 ` Robert Dewar 1997-01-27 0:00 ` Samuel S. Shuster ` (2 more replies) 1997-02-08 0:00 ` Robin Rosenberg 1 sibling, 3 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-26 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Robert Dewar @ 1997-01-27 0:00 ` Samuel S. Shuster 1997-01-27 0:00 ` Richard Kenner ` (2 more replies) 1997-01-27 0:00 ` Bob Jarvis 1997-01-28 0:00 ` Robert I. Eachus 2 siblings, 3 replies; 391+ messages in thread From: Samuel S. Shuster @ 1997-01-27 0:00 UTC (permalink / raw) 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. ============================================================================ ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Samuel S. Shuster @ 1997-01-27 0:00 ` Richard Kenner 1997-01-29 0:00 ` Robert Dewar 1997-01-28 0:00 ` Jun Nolasco 1997-01-29 0:00 ` Robert Dewar 2 siblings, 1 reply; 391+ messages in thread From: Richard Kenner @ 1997-01-27 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Richard Kenner @ 1997-01-29 0:00 ` Robert Dewar 1997-01-30 0:00 ` Eirik Mangseth 0 siblings, 1 reply; 391+ messages in thread From: Robert Dewar @ 1997-01-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` Robert Dewar @ 1997-01-30 0:00 ` Eirik Mangseth 0 siblings, 0 replies; 391+ messages in thread From: Eirik Mangseth @ 1997-01-30 0:00 UTC (permalink / raw) 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 / ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Samuel S. Shuster 1997-01-27 0:00 ` Richard Kenner @ 1997-01-28 0:00 ` Jun Nolasco 1997-01-29 0:00 ` Robert Dewar 2 siblings, 0 replies; 391+ messages in thread From: Jun Nolasco @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Samuel S. Shuster 1997-01-27 0:00 ` Richard Kenner 1997-01-28 0:00 ` Jun Nolasco @ 1997-01-29 0:00 ` Robert Dewar 1997-01-29 0:00 ` Richard Kenner 2 siblings, 1 reply; 391+ messages in thread From: Robert Dewar @ 1997-01-29 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` Robert Dewar @ 1997-01-29 0:00 ` Richard Kenner 1997-01-29 0:00 ` David Hanley 1997-01-30 0:00 ` Nick Leaton 0 siblings, 2 replies; 391+ messages in thread From: Richard Kenner @ 1997-01-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` Richard Kenner @ 1997-01-29 0:00 ` David Hanley 1997-01-29 0:00 ` Richard Kenner 1997-01-30 0:00 ` Nick Leaton 1 sibling, 1 reply; 391+ messages in thread From: David Hanley @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` David Hanley @ 1997-01-29 0:00 ` Richard Kenner 0 siblings, 0 replies; 391+ messages in thread From: Richard Kenner @ 1997-01-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` Richard Kenner 1997-01-29 0:00 ` David Hanley @ 1997-01-30 0:00 ` Nick Leaton 1997-01-30 0:00 ` Richard Kenner 1997-01-30 0:00 ` Robert Dewar 1 sibling, 2 replies; 391+ messages in thread From: Nick Leaton @ 1997-01-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-30 0:00 ` Nick Leaton @ 1997-01-30 0:00 ` Richard Kenner 1997-01-30 0:00 ` Nick Leaton 1997-01-30 0:00 ` Robert Dewar 1 sibling, 1 reply; 391+ messages in thread From: Richard Kenner @ 1997-01-30 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-30 0:00 ` Richard Kenner @ 1997-01-30 0:00 ` Nick Leaton 0 siblings, 0 replies; 391+ messages in thread From: Nick Leaton @ 1997-01-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-30 0:00 ` Nick Leaton 1997-01-30 0:00 ` Richard Kenner @ 1997-01-30 0:00 ` Robert Dewar 1 sibling, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-30 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Robert Dewar 1997-01-27 0:00 ` Samuel S. Shuster @ 1997-01-27 0:00 ` Bob Jarvis 1997-01-27 0:00 ` Robert Dewar 1997-01-28 0:00 ` Robert I. Eachus 2 siblings, 1 reply; 391+ messages in thread From: Bob Jarvis @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Bob Jarvis @ 1997-01-27 0:00 ` Robert Dewar 1997-01-27 0:00 ` Robert A Duff ` (3 more replies) 0 siblings, 4 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-27 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Robert Dewar @ 1997-01-27 0:00 ` Robert A Duff 1997-01-29 0:00 ` Robert Dewar 1997-01-27 0:00 ` Eric Clayberg ` (2 subsequent siblings) 3 siblings, 1 reply; 391+ messages in thread From: Robert A Duff @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Robert A Duff @ 1997-01-29 0:00 ` Robert Dewar 0 siblings, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Robert Dewar 1997-01-27 0:00 ` Robert A Duff @ 1997-01-27 0:00 ` Eric Clayberg 1997-01-29 0:00 ` Robert Dewar 1997-01-27 0:00 ` Matthew Heaney 1997-01-27 0:00 ` Eric Clayberg 3 siblings, 1 reply; 391+ messages in thread From: Eric Clayberg @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Eric Clayberg @ 1997-01-29 0:00 ` Robert Dewar 1997-01-29 0:00 ` Robert A Duff 0 siblings, 1 reply; 391+ messages in thread From: Robert Dewar @ 1997-01-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` Robert Dewar @ 1997-01-29 0:00 ` Robert A Duff 1997-01-29 0:00 ` Eric Clayberg 0 siblings, 1 reply; 391+ messages in thread From: Robert A Duff @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` Robert A Duff @ 1997-01-29 0:00 ` Eric Clayberg 0 siblings, 0 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-29 0:00 UTC (permalink / raw) Robert A Duff wrote: > What's "GD&R"? Grinning, Ducking & Running. Often used to signify a cheap shot. ;-) -Eric ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Robert Dewar 1997-01-27 0:00 ` Robert A Duff 1997-01-27 0:00 ` Eric Clayberg @ 1997-01-27 0:00 ` Matthew Heaney 1997-01-27 0:00 ` Eric Clayberg 3 siblings, 0 replies; 391+ messages in thread From: Matthew Heaney @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Robert Dewar ` (2 preceding siblings ...) 1997-01-27 0:00 ` Matthew Heaney @ 1997-01-27 0:00 ` Eric Clayberg 3 siblings, 0 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Robert Dewar 1997-01-27 0:00 ` Samuel S. Shuster 1997-01-27 0:00 ` Bob Jarvis @ 1997-01-28 0:00 ` Robert I. Eachus 2 siblings, 0 replies; 391+ messages in thread From: Robert I. Eachus @ 1997-01-28 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Eric Clayberg 1997-01-26 0:00 ` Robert Dewar @ 1997-02-08 0:00 ` Robin Rosenberg 1 sibling, 0 replies; 391+ messages in thread From: Robin Rosenberg @ 1997-02-08 0:00 UTC (permalink / raw) 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 | ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (2 preceding siblings ...) 1997-01-25 0:00 ` Eric Clayberg @ 1997-01-27 0:00 ` Eric Clayberg 1997-01-29 0:00 ` Joachim Durchholz 1997-01-29 0:00 ` Fergus Henderson 1997-01-27 0:00 ` Jon S Anthony ` (11 subsequent siblings) 15 siblings, 2 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Eric Clayberg @ 1997-01-29 0:00 ` Joachim Durchholz 1997-01-29 0:00 ` Fergus Henderson 1 sibling, 0 replies; 391+ messages in thread From: Joachim Durchholz @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Eric Clayberg 1997-01-29 0:00 ` Joachim Durchholz @ 1997-01-29 0:00 ` Fergus Henderson 1 sibling, 0 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (3 preceding siblings ...) 1997-01-27 0:00 ` Eric Clayberg @ 1997-01-27 0:00 ` Jon S Anthony 1997-01-27 0:00 ` David Hanley ` (10 subsequent siblings) 15 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (4 preceding siblings ...) 1997-01-27 0:00 ` Jon S Anthony @ 1997-01-27 0:00 ` David Hanley 1997-01-29 0:00 ` Joachim Durchholz 1997-01-28 0:00 ` Eric Clayberg ` (9 subsequent siblings) 15 siblings, 1 reply; 391+ messages in thread From: David Hanley @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` David Hanley @ 1997-01-29 0:00 ` Joachim Durchholz 1997-01-29 0:00 ` Dennis Smith 0 siblings, 1 reply; 391+ messages in thread From: Joachim Durchholz @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` Joachim Durchholz @ 1997-01-29 0:00 ` Dennis Smith 0 siblings, 0 replies; 391+ messages in thread From: Dennis Smith @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (5 preceding siblings ...) 1997-01-27 0:00 ` David Hanley @ 1997-01-28 0:00 ` Eric Clayberg 1997-01-28 0:00 ` Matt Kennel 1997-01-28 0:00 ` David Hanley ` (8 subsequent siblings) 15 siblings, 1 reply; 391+ messages in thread From: Eric Clayberg @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Eric Clayberg @ 1997-01-28 0:00 ` Matt Kennel 0 siblings, 0 replies; 391+ messages in thread From: Matt Kennel @ 1997-01-28 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (6 preceding siblings ...) 1997-01-28 0:00 ` Eric Clayberg @ 1997-01-28 0:00 ` David Hanley 1997-01-28 0:00 ` Jacqueline U. Robertson 1997-01-29 0:00 ` Joachim Durchholz 1997-01-28 0:00 ` Robert I. Eachus ` (7 subsequent siblings) 15 siblings, 2 replies; 391+ messages in thread From: David Hanley @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` David Hanley @ 1997-01-28 0:00 ` Jacqueline U. Robertson 1997-01-29 0:00 ` David Hanley ` (2 more replies) 1997-01-29 0:00 ` Joachim Durchholz 1 sibling, 3 replies; 391+ messages in thread From: Jacqueline U. Robertson @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Jacqueline U. Robertson @ 1997-01-29 0:00 ` David Hanley 1997-01-29 0:00 ` Fergus Henderson 1997-01-30 0:00 ` Robert C. Martin 2 siblings, 0 replies; 391+ messages in thread From: David Hanley @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Jacqueline U. Robertson 1997-01-29 0:00 ` David Hanley @ 1997-01-29 0:00 ` Fergus Henderson 1997-01-30 0:00 ` Robert C. Martin 2 siblings, 0 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Jacqueline U. Robertson 1997-01-29 0:00 ` David Hanley 1997-01-29 0:00 ` Fergus Henderson @ 1997-01-30 0:00 ` Robert C. Martin [not found] ` <5cr068$gpa@uni.library.ucla.edu> 2 siblings, 1 reply; 391+ messages in thread From: Robert C. Martin @ 1997-01-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
[parent not found: <5cr068$gpa@uni.library.ucla.edu>]
* Re: OO, C++, and something much better! [not found] ` <5cr068$gpa@uni.library.ucla.edu> @ 1997-06-27 0:00 ` David Shang 1997-06-28 0:00 ` Ronald E Jeffries ` (2 more replies) 0 siblings, 3 replies; 391+ messages in thread From: David Shang @ 1997-06-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-06-27 0:00 ` David Shang @ 1997-06-28 0:00 ` Ronald E Jeffries 1997-06-28 0:00 ` Mike Stark 1997-06-29 0:00 ` Mike Anderson 2 siblings, 0 replies; 391+ messages in thread From: Ronald E Jeffries @ 1997-06-28 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-06-27 0:00 ` David Shang 1997-06-28 0:00 ` Ronald E Jeffries @ 1997-06-28 0:00 ` Mike Stark 1997-06-29 0:00 ` Mike Anderson 2 siblings, 0 replies; 391+ messages in thread From: Mike Stark @ 1997-06-28 0:00 UTC (permalink / raw) 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 -------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-06-27 0:00 ` David Shang 1997-06-28 0:00 ` Ronald E Jeffries 1997-06-28 0:00 ` Mike Stark @ 1997-06-29 0:00 ` Mike Anderson 1997-06-29 0:00 ` Robert Dewar 2 siblings, 1 reply; 391+ messages in thread From: Mike Anderson @ 1997-06-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-06-29 0:00 ` Mike Anderson @ 1997-06-29 0:00 ` Robert Dewar 1997-06-30 0:00 ` Kohler Markus 0 siblings, 1 reply; 391+ messages in thread From: Robert Dewar @ 1997-06-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-06-29 0:00 ` Robert Dewar @ 1997-06-30 0:00 ` Kohler Markus 0 siblings, 0 replies; 391+ messages in thread From: Kohler Markus @ 1997-06-30 0:00 UTC (permalink / raw) 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 | +----------------------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` David Hanley 1997-01-28 0:00 ` Jacqueline U. Robertson @ 1997-01-29 0:00 ` Joachim Durchholz 1 sibling, 0 replies; 391+ messages in thread From: Joachim Durchholz @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (7 preceding siblings ...) 1997-01-28 0:00 ` David Hanley @ 1997-01-28 0:00 ` Robert I. Eachus 1997-01-28 0:00 ` Luther Hampton ` (6 subsequent siblings) 15 siblings, 0 replies; 391+ messages in thread From: Robert I. Eachus @ 1997-01-28 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (8 preceding siblings ...) 1997-01-28 0:00 ` Robert I. Eachus @ 1997-01-28 0:00 ` Luther Hampton 1997-01-28 0:00 ` David Hanley ` (5 subsequent siblings) 15 siblings, 0 replies; 391+ messages in thread From: Luther Hampton @ 1997-01-28 0:00 UTC (permalink / raw) 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 > ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (9 preceding siblings ...) 1997-01-28 0:00 ` Luther Hampton @ 1997-01-28 0:00 ` David Hanley 1997-01-29 0:00 ` David Hanley ` (4 subsequent siblings) 15 siblings, 0 replies; 391+ messages in thread From: David Hanley @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (10 preceding siblings ...) 1997-01-28 0:00 ` David Hanley @ 1997-01-29 0:00 ` David Hanley 1997-01-29 0:00 ` Eric Clayberg ` (3 subsequent siblings) 15 siblings, 0 replies; 391+ messages in thread From: David Hanley @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (11 preceding siblings ...) 1997-01-29 0:00 ` David Hanley @ 1997-01-29 0:00 ` Eric Clayberg 1997-01-29 0:00 ` Jon S Anthony ` (2 subsequent siblings) 15 siblings, 0 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (12 preceding siblings ...) 1997-01-29 0:00 ` Eric Clayberg @ 1997-01-29 0:00 ` Jon S Anthony 1997-01-29 0:00 ` Eric Clayberg 1997-01-29 0:00 ` Rolf Breuning 15 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (13 preceding siblings ...) 1997-01-29 0:00 ` Jon S Anthony @ 1997-01-29 0:00 ` Eric Clayberg 1997-01-29 0:00 ` Rolf Breuning 15 siblings, 0 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Damon Feldman ` (14 preceding siblings ...) 1997-01-29 0:00 ` Eric Clayberg @ 1997-01-29 0:00 ` Rolf Breuning 15 siblings, 0 replies; 391+ messages in thread From: Rolf Breuning @ 1997-01-29 0:00 UTC (permalink / raw) > > 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 - * ********************************************************************** ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Alan Lovejoy 1997-01-20 0:00 ` Fergus Henderson 1997-01-20 0:00 ` Damon Feldman @ 1997-01-25 0:00 ` Robert Dewar 1997-01-27 0:00 ` Bob Jarvis 1997-01-28 0:00 ` Alan Lovejoy 1997-01-25 0:00 ` Robert Dewar 3 siblings, 2 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-25 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Robert Dewar @ 1997-01-27 0:00 ` Bob Jarvis 1997-01-27 0:00 ` Robert Dewar 1997-01-28 0:00 ` Alan Lovejoy 1 sibling, 1 reply; 391+ messages in thread From: Bob Jarvis @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Bob Jarvis @ 1997-01-27 0:00 ` Robert Dewar 0 siblings, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-27 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Robert Dewar 1997-01-27 0:00 ` Bob Jarvis @ 1997-01-28 0:00 ` Alan Lovejoy 1 sibling, 0 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-28 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Alan Lovejoy ` (2 preceding siblings ...) 1997-01-25 0:00 ` Robert Dewar @ 1997-01-25 0:00 ` Robert Dewar 1997-01-26 0:00 ` James O'Connor ` (2 more replies) 3 siblings, 3 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-25 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Robert Dewar @ 1997-01-26 0:00 ` James O'Connor 1997-01-26 0:00 ` George Wolke ` (2 more replies) 1997-01-28 0:00 ` Alan Lovejoy 1997-01-28 0:00 ` Jon S Anthony 2 siblings, 3 replies; 391+ messages in thread From: James O'Connor @ 1997-01-26 0:00 UTC (permalink / raw) To: Robert Dewar 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 -------------------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` James O'Connor @ 1997-01-26 0:00 ` George Wolke 1997-01-26 0:00 ` Robert Dewar 1997-01-27 0:00 ` Jerry van Dijk 2 siblings, 0 replies; 391+ messages in thread From: George Wolke @ 1997-01-26 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` James O'Connor 1997-01-26 0:00 ` George Wolke @ 1997-01-26 0:00 ` Robert Dewar 1997-01-27 0:00 ` Jerry van Dijk 2 siblings, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-26 0:00 UTC (permalink / raw) "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! ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` James O'Connor 1997-01-26 0:00 ` George Wolke 1997-01-26 0:00 ` Robert Dewar @ 1997-01-27 0:00 ` Jerry van Dijk 1997-01-28 0:00 ` Robert A Duff 2 siblings, 1 reply; 391+ messages in thread From: Jerry van Dijk @ 1997-01-27 0:00 UTC (permalink / raw) : 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 | +----------------+-------------------------------+ ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Jerry van Dijk @ 1997-01-28 0:00 ` Robert A Duff 1997-01-28 0:00 ` Jerry van Dijk 1997-01-29 0:00 ` Stanley R. Allen 0 siblings, 2 replies; 391+ messages in thread From: Robert A Duff @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Robert A Duff @ 1997-01-28 0:00 ` Jerry van Dijk 1997-01-29 0:00 ` Stanley R. Allen 1 sibling, 0 replies; 391+ messages in thread From: Jerry van Dijk @ 1997-01-28 0:00 UTC (permalink / raw) 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 | +----------------+-------------------------------+ ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Robert A Duff 1997-01-28 0:00 ` Jerry van Dijk @ 1997-01-29 0:00 ` Stanley R. Allen 1997-01-30 0:00 ` Robert A Duff 1 sibling, 1 reply; 391+ messages in thread From: Stanley R. Allen @ 1997-01-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` Stanley R. Allen @ 1997-01-30 0:00 ` Robert A Duff 0 siblings, 0 replies; 391+ messages in thread From: Robert A Duff @ 1997-01-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Robert Dewar 1997-01-26 0:00 ` James O'Connor @ 1997-01-28 0:00 ` Alan Lovejoy 1997-01-28 0:00 ` Jon S Anthony 2 siblings, 0 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-28 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Robert Dewar 1997-01-26 0:00 ` James O'Connor 1997-01-28 0:00 ` Alan Lovejoy @ 1997-01-28 0:00 ` Jon S Anthony 1997-01-29 0:00 ` Robert A Duff 2 siblings, 1 reply; 391+ messages in thread From: Jon S Anthony @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Jon S Anthony @ 1997-01-29 0:00 ` Robert A Duff 0 siblings, 0 replies; 391+ messages in thread From: Robert A Duff @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson 1997-01-17 0:00 ` Alan Lovejoy @ 1997-01-19 0:00 ` Soren Skogstad Nielsen 1997-01-20 0:00 ` Joachim Durchholz ` (12 subsequent siblings) 14 siblings, 0 replies; 391+ messages in thread From: Soren Skogstad Nielsen @ 1997-01-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson 1997-01-17 0:00 ` Alan Lovejoy 1997-01-19 0:00 ` Soren Skogstad Nielsen @ 1997-01-20 0:00 ` Joachim Durchholz 1997-01-26 0:00 ` Joachim Durchholz 1997-01-21 0:00 ` Matthew S. Whiting ` (11 subsequent siblings) 14 siblings, 1 reply; 391+ messages in thread From: Joachim Durchholz @ 1997-01-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-20 0:00 ` Joachim Durchholz @ 1997-01-26 0:00 ` Joachim Durchholz 0 siblings, 0 replies; 391+ messages in thread From: Joachim Durchholz @ 1997-01-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson ` (2 preceding siblings ...) 1997-01-20 0:00 ` Joachim Durchholz @ 1997-01-21 0:00 ` Matthew S. Whiting 1997-01-21 0:00 ` Matthew S. Whiting ` (10 subsequent siblings) 14 siblings, 0 replies; 391+ messages in thread From: Matthew S. Whiting @ 1997-01-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson ` (3 preceding siblings ...) 1997-01-21 0:00 ` Matthew S. Whiting @ 1997-01-21 0:00 ` Matthew S. Whiting 1997-01-22 0:00 ` Fergus Henderson 1997-01-24 0:00 ` Tansel Ersavas ` (9 subsequent siblings) 14 siblings, 1 reply; 391+ messages in thread From: Matthew S. Whiting @ 1997-01-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 ` Matthew S. Whiting @ 1997-01-22 0:00 ` Fergus Henderson 1997-01-22 0:00 ` Alan Lovejoy ` (2 more replies) 0 siblings, 3 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-22 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Fergus Henderson @ 1997-01-22 0:00 ` Alan Lovejoy 1997-01-22 0:00 ` Eric Clayberg 1997-01-22 0:00 ` Don Harrison 2 siblings, 0 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-22 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Fergus Henderson 1997-01-22 0:00 ` Alan Lovejoy @ 1997-01-22 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Don Harrison ` (2 more replies) 1997-01-22 0:00 ` Don Harrison 2 siblings, 3 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Eric Clayberg @ 1997-01-23 0:00 ` Don Harrison 1997-01-27 0:00 ` John Woods 1997-01-24 0:00 ` Andy Bower 1997-01-27 0:00 ` Robert C. Martin 2 siblings, 1 reply; 391+ messages in thread From: Don Harrison @ 1997-01-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Don Harrison @ 1997-01-27 0:00 ` John Woods 1997-01-28 0:00 ` Alan Lovejoy 0 siblings, 1 reply; 391+ messages in thread From: John Woods @ 1997-01-27 0:00 UTC (permalink / raw) 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 " ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` John Woods @ 1997-01-28 0:00 ` Alan Lovejoy 0 siblings, 0 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-28 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Don Harrison @ 1997-01-24 0:00 ` Andy Bower 1997-01-25 0:00 ` Robert Dewar 1997-01-25 0:00 ` Robert Dewar 1997-01-27 0:00 ` Robert C. Martin 2 siblings, 2 replies; 391+ messages in thread From: Andy Bower @ 1997-01-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Andy Bower @ 1997-01-25 0:00 ` Robert Dewar 1997-01-26 0:00 ` William Clodius 1997-01-25 0:00 ` Robert Dewar 1 sibling, 1 reply; 391+ messages in thread From: Robert Dewar @ 1997-01-25 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Robert Dewar @ 1997-01-26 0:00 ` William Clodius 0 siblings, 0 replies; 391+ messages in thread From: William Clodius @ 1997-01-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Andy Bower 1997-01-25 0:00 ` Robert Dewar @ 1997-01-25 0:00 ` Robert Dewar 1997-01-26 0:00 ` Eric Clayberg 1 sibling, 1 reply; 391+ messages in thread From: Robert Dewar @ 1997-01-25 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Robert Dewar @ 1997-01-26 0:00 ` Eric Clayberg 1997-01-26 0:00 ` Robert Dewar 1997-01-26 0:00 ` Robert Dewar 0 siblings, 2 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Eric Clayberg @ 1997-01-26 0:00 ` Robert Dewar 1997-01-26 0:00 ` Robert Dewar 1 sibling, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-26 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Eric Clayberg 1997-01-26 0:00 ` Robert Dewar @ 1997-01-26 0:00 ` Robert Dewar 1 sibling, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-26 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Don Harrison 1997-01-24 0:00 ` Andy Bower @ 1997-01-27 0:00 ` Robert C. Martin 1997-01-29 0:00 ` Robert Dewar 2 siblings, 1 reply; 391+ messages in thread From: Robert C. Martin @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Robert C. Martin @ 1997-01-29 0:00 ` Robert Dewar 1997-01-29 0:00 ` Robert A Duff 0 siblings, 1 reply; 391+ messages in thread From: Robert Dewar @ 1997-01-29 0:00 UTC (permalink / raw) 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 ... ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` Robert Dewar @ 1997-01-29 0:00 ` Robert A Duff 0 siblings, 0 replies; 391+ messages in thread From: Robert A Duff @ 1997-01-29 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Fergus Henderson 1997-01-22 0:00 ` Alan Lovejoy 1997-01-22 0:00 ` Eric Clayberg @ 1997-01-22 0:00 ` Don Harrison 1997-01-22 0:00 ` John Kuszewski 2 siblings, 1 reply; 391+ messages in thread From: Don Harrison @ 1997-01-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Don Harrison @ 1997-01-22 0:00 ` John Kuszewski 1997-01-23 0:00 ` Don Harrison 1997-01-24 0:00 ` Fergus Henderson 0 siblings, 2 replies; 391+ messages in thread From: John Kuszewski @ 1997-01-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` John Kuszewski @ 1997-01-23 0:00 ` Don Harrison 1997-01-23 0:00 ` Tansel Ersavas 1997-01-23 0:00 ` Travis Griggs 1997-01-24 0:00 ` Fergus Henderson 1 sibling, 2 replies; 391+ messages in thread From: Don Harrison @ 1997-01-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Don Harrison @ 1997-01-23 0:00 ` Tansel Ersavas 1997-01-23 0:00 ` Travis Griggs 1 sibling, 0 replies; 391+ messages in thread From: Tansel Ersavas @ 1997-01-23 0:00 UTC (permalink / raw) 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----------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Don Harrison 1997-01-23 0:00 ` Tansel Ersavas @ 1997-01-23 0:00 ` Travis Griggs 1 sibling, 0 replies; 391+ messages in thread From: Travis Griggs @ 1997-01-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` John Kuszewski 1997-01-23 0:00 ` Don Harrison @ 1997-01-24 0:00 ` Fergus Henderson 1 sibling, 0 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-24 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson ` (4 preceding siblings ...) 1997-01-21 0:00 ` Matthew S. Whiting @ 1997-01-24 0:00 ` Tansel Ersavas 1997-01-25 0:00 ` Damon Feldman 1997-01-28 0:00 ` Robert C. Martin 1997-01-24 0:00 ` Tansel Ersavas ` (8 subsequent siblings) 14 siblings, 2 replies; 391+ messages in thread From: Tansel Ersavas @ 1997-01-24 0:00 UTC (permalink / raw) 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----------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Tansel Ersavas @ 1997-01-25 0:00 ` Damon Feldman 1997-01-26 0:00 ` Felix Beer 1997-01-28 0:00 ` Robert C. Martin 1 sibling, 1 reply; 391+ messages in thread From: Damon Feldman @ 1997-01-25 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Damon Feldman @ 1997-01-26 0:00 ` Felix Beer 0 siblings, 0 replies; 391+ messages in thread From: Felix Beer @ 1997-01-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Tansel Ersavas 1997-01-25 0:00 ` Damon Feldman @ 1997-01-28 0:00 ` Robert C. Martin 1997-01-28 0:00 ` Matt Kennel 1997-01-29 0:00 ` Del Archer 1 sibling, 2 replies; 391+ messages in thread From: Robert C. Martin @ 1997-01-28 0:00 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Robert C. Martin @ 1997-01-28 0:00 ` Matt Kennel 1997-01-29 0:00 ` Del Archer 1 sibling, 0 replies; 391+ messages in thread From: Matt Kennel @ 1997-01-28 0:00 UTC (permalink / raw) 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: ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Robert C. Martin 1997-01-28 0:00 ` Matt Kennel @ 1997-01-29 0:00 ` Del Archer 1 sibling, 0 replies; 391+ messages in thread From: Del Archer @ 1997-01-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson ` (5 preceding siblings ...) 1997-01-24 0:00 ` Tansel Ersavas @ 1997-01-24 0:00 ` Tansel Ersavas 1997-01-25 0:00 ` Robert A Duff 1997-01-25 0:00 ` Fergus Henderson 1997-01-24 0:00 ` Tansel Ersavas ` (7 subsequent siblings) 14 siblings, 2 replies; 391+ messages in thread From: Tansel Ersavas @ 1997-01-24 0:00 UTC (permalink / raw) 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----------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Tansel Ersavas @ 1997-01-25 0:00 ` Robert A Duff 1997-01-26 0:00 ` Robert Dewar 1997-01-26 0:00 ` Bob Haugen 1997-01-25 0:00 ` Fergus Henderson 1 sibling, 2 replies; 391+ messages in thread From: Robert A Duff @ 1997-01-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Robert A Duff @ 1997-01-26 0:00 ` Robert Dewar 1997-01-26 0:00 ` James O'Connor 1997-01-26 0:00 ` Bob Haugen 1 sibling, 1 reply; 391+ messages in thread From: Robert Dewar @ 1997-01-26 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Robert Dewar @ 1997-01-26 0:00 ` James O'Connor 1997-01-26 0:00 ` TanselErsavas 0 siblings, 1 reply; 391+ messages in thread From: James O'Connor @ 1997-01-26 0:00 UTC (permalink / raw) To: Robert Dewar 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 -------------------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` James O'Connor @ 1997-01-26 0:00 ` TanselErsavas 1997-01-26 0:00 ` Robert Dewar 0 siblings, 1 reply; 391+ messages in thread From: TanselErsavas @ 1997-01-26 0:00 UTC (permalink / raw) 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----------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` TanselErsavas @ 1997-01-26 0:00 ` Robert Dewar 1997-01-27 0:00 ` Eric Clayberg 0 siblings, 1 reply; 391+ messages in thread From: Robert Dewar @ 1997-01-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Robert Dewar @ 1997-01-27 0:00 ` Eric Clayberg 1997-01-28 0:00 ` Antoine Trux 1997-01-29 0:00 ` Robert Dewar 0 siblings, 2 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Eric Clayberg @ 1997-01-28 0:00 ` Antoine Trux 1997-01-29 0:00 ` Robert Dewar 1 sibling, 0 replies; 391+ messages in thread From: Antoine Trux @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Eric Clayberg 1997-01-28 0:00 ` Antoine Trux @ 1997-01-29 0:00 ` Robert Dewar 1 sibling, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Robert A Duff 1997-01-26 0:00 ` Robert Dewar @ 1997-01-26 0:00 ` Bob Haugen 1997-01-26 0:00 ` Robert Dewar ` (2 more replies) 1 sibling, 3 replies; 391+ messages in thread From: Bob Haugen @ 1997-01-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Bob Haugen @ 1997-01-26 0:00 ` Robert Dewar 1997-01-26 0:00 ` TanselErsavas 1997-01-27 0:00 ` Samuel S. Shuster 1997-01-26 0:00 ` Larry J. Elmore 1997-01-27 0:00 ` David Hanley 2 siblings, 2 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-26 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Robert Dewar @ 1997-01-26 0:00 ` TanselErsavas 1997-01-27 0:00 ` Samuel S. Shuster 1 sibling, 0 replies; 391+ messages in thread From: TanselErsavas @ 1997-01-26 0:00 UTC (permalink / raw) 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----------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Robert Dewar 1997-01-26 0:00 ` TanselErsavas @ 1997-01-27 0:00 ` Samuel S. Shuster 1 sibling, 0 replies; 391+ messages in thread From: Samuel S. Shuster @ 1997-01-27 0:00 UTC (permalink / raw) 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. ============================================================================ ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Bob Haugen 1997-01-26 0:00 ` Robert Dewar @ 1997-01-26 0:00 ` Larry J. Elmore 1997-01-26 0:00 ` Eric Clayberg 1997-01-27 0:00 ` David Hanley 2 siblings, 1 reply; 391+ messages in thread From: Larry J. Elmore @ 1997-01-26 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Larry J. Elmore @ 1997-01-26 0:00 ` Eric Clayberg 0 siblings, 0 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Bob Haugen 1997-01-26 0:00 ` Robert Dewar 1997-01-26 0:00 ` Larry J. Elmore @ 1997-01-27 0:00 ` David Hanley 2 siblings, 0 replies; 391+ messages in thread From: David Hanley @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Tansel Ersavas 1997-01-25 0:00 ` Robert A Duff @ 1997-01-25 0:00 ` Fergus Henderson 1 sibling, 0 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-25 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson ` (6 preceding siblings ...) 1997-01-24 0:00 ` Tansel Ersavas @ 1997-01-24 0:00 ` Tansel Ersavas 1997-01-27 0:00 ` David Hanley ` (6 subsequent siblings) 14 siblings, 0 replies; 391+ messages in thread From: Tansel Ersavas @ 1997-01-24 0:00 UTC (permalink / raw) 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----------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson ` (7 preceding siblings ...) 1997-01-24 0:00 ` Tansel Ersavas @ 1997-01-27 0:00 ` David Hanley 1997-01-28 0:00 ` Al Christians ` (5 subsequent siblings) 14 siblings, 0 replies; 391+ messages in thread From: David Hanley @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson ` (8 preceding siblings ...) 1997-01-27 0:00 ` David Hanley @ 1997-01-28 0:00 ` Al Christians 1997-01-28 0:00 ` Alan Lovejoy ` (4 subsequent siblings) 14 siblings, 0 replies; 391+ messages in thread From: Al Christians @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson ` (9 preceding siblings ...) 1997-01-28 0:00 ` Al Christians @ 1997-01-28 0:00 ` Alan Lovejoy 1997-01-29 0:00 ` Alan Lovejoy ` (3 subsequent siblings) 14 siblings, 0 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-28 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson ` (10 preceding siblings ...) 1997-01-28 0:00 ` Alan Lovejoy @ 1997-01-29 0:00 ` Alan Lovejoy 1997-02-21 0:00 ` Chris Bitmead ` (2 subsequent siblings) 14 siblings, 0 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-01-29 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson ` (11 preceding siblings ...) 1997-01-29 0:00 ` Alan Lovejoy @ 1997-02-21 0:00 ` Chris Bitmead 1997-02-21 0:00 ` Eric W. Nikitin 1997-02-24 0:00 ` Jon S Anthony 14 siblings, 0 replies; 391+ messages in thread From: Chris Bitmead @ 1997-02-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson ` (12 preceding siblings ...) 1997-02-21 0:00 ` Chris Bitmead @ 1997-02-21 0:00 ` Eric W. Nikitin 1997-02-21 0:00 ` Brian Rogoff 1997-02-24 0:00 ` Jon S Anthony 14 siblings, 1 reply; 391+ messages in thread From: Eric W. Nikitin @ 1997-02-21 0:00 UTC (permalink / raw) 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-21 0:00 ` Eric W. Nikitin @ 1997-02-21 0:00 ` Brian Rogoff 0 siblings, 0 replies; 391+ messages in thread From: Brian Rogoff @ 1997-02-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-18 0:00 ` Fergus Henderson ` (13 preceding siblings ...) 1997-02-21 0:00 ` Eric W. Nikitin @ 1997-02-24 0:00 ` Jon S Anthony 1997-02-24 0:00 ` Brian Rogoff 14 siblings, 1 reply; 391+ messages in thread From: Jon S Anthony @ 1997-02-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-24 0:00 ` Jon S Anthony @ 1997-02-24 0:00 ` Brian Rogoff 1997-02-25 0:00 ` Eric W. Nikitin 0 siblings, 1 reply; 391+ messages in thread From: Brian Rogoff @ 1997-02-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-24 0:00 ` Brian Rogoff @ 1997-02-25 0:00 ` Eric W. Nikitin 0 siblings, 0 replies; 391+ messages in thread From: Eric W. Nikitin @ 1997-02-25 0:00 UTC (permalink / raw) 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/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Alan Lovejoy 1997-01-18 0:00 ` Fergus Henderson @ 1997-01-21 0:00 ` Norman H. Cohen 1997-01-22 0:00 ` Eric Clayberg 1997-01-23 0:00 ` James O'Connor 1997-01-27 0:00 ` Jon S Anthony 2 siblings, 2 replies; 391+ messages in thread From: Norman H. Cohen @ 1997-01-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 ` Norman H. Cohen @ 1997-01-22 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Norman H. Cohen 1997-01-23 0:00 ` James O'Connor 1 sibling, 1 reply; 391+ messages in thread From: Eric Clayberg @ 1997-01-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Eric Clayberg @ 1997-01-23 0:00 ` Norman H. Cohen 1997-01-24 0:00 ` Eric Clayberg ` (2 more replies) 0 siblings, 3 replies; 391+ messages in thread From: Norman H. Cohen @ 1997-01-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Norman H. Cohen @ 1997-01-24 0:00 ` Eric Clayberg 1997-01-27 0:00 ` Norman H. Cohen 1997-01-24 0:00 ` traymond 1997-01-25 0:00 ` Tansel Ersavas 2 siblings, 1 reply; 391+ messages in thread From: Eric Clayberg @ 1997-01-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Eric Clayberg @ 1997-01-27 0:00 ` Norman H. Cohen 1997-01-28 0:00 ` Tim Ottinger 0 siblings, 1 reply; 391+ messages in thread From: Norman H. Cohen @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Norman H. Cohen @ 1997-01-28 0:00 ` Tim Ottinger 1997-01-29 0:00 ` Ted Dennison 0 siblings, 1 reply; 391+ messages in thread From: Tim Ottinger @ 1997-01-28 0:00 UTC (permalink / raw) 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 ------------------------------------------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-28 0:00 ` Tim Ottinger @ 1997-01-29 0:00 ` Ted Dennison 0 siblings, 0 replies; 391+ messages in thread From: Ted Dennison @ 1997-01-29 0:00 UTC (permalink / raw) 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 | ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Norman H. Cohen 1997-01-24 0:00 ` Eric Clayberg @ 1997-01-24 0:00 ` traymond 1997-01-27 0:00 ` Norman H. Cohen 1997-01-25 0:00 ` Tansel Ersavas 2 siblings, 1 reply; 391+ messages in thread From: traymond @ 1997-01-24 0:00 UTC (permalink / raw) 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 =========================================================== ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` traymond @ 1997-01-27 0:00 ` Norman H. Cohen 1997-01-28 0:00 ` traymond 0 siblings, 1 reply; 391+ messages in thread From: Norman H. Cohen @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Norman H. Cohen @ 1997-01-28 0:00 ` traymond 0 siblings, 0 replies; 391+ messages in thread From: traymond @ 1997-01-28 0:00 UTC (permalink / raw) 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 =========================================================== ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Norman H. Cohen 1997-01-24 0:00 ` Eric Clayberg 1997-01-24 0:00 ` traymond @ 1997-01-25 0:00 ` Tansel Ersavas 1997-01-27 0:00 ` Norman H. Cohen 2 siblings, 1 reply; 391+ messages in thread From: Tansel Ersavas @ 1997-01-25 0:00 UTC (permalink / raw) 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----------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` Tansel Ersavas @ 1997-01-27 0:00 ` Norman H. Cohen 1997-01-27 0:00 ` Brian Rogoff 0 siblings, 1 reply; 391+ messages in thread From: Norman H. Cohen @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Norman H. Cohen @ 1997-01-27 0:00 ` Brian Rogoff 1997-01-30 0:00 ` Tim Ottinger 0 siblings, 1 reply; 391+ messages in thread From: Brian Rogoff @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Brian Rogoff @ 1997-01-30 0:00 ` Tim Ottinger 0 siblings, 0 replies; 391+ messages in thread From: Tim Ottinger @ 1997-01-30 0:00 UTC (permalink / raw) 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 ------------------------------------------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 ` Norman H. Cohen 1997-01-22 0:00 ` Eric Clayberg @ 1997-01-23 0:00 ` James O'Connor 1997-01-29 0:00 ` Stanley R. Allen 1 sibling, 1 reply; 391+ messages in thread From: James O'Connor @ 1997-01-23 0:00 UTC (permalink / raw) To: ncohen 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 -------------------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` James O'Connor @ 1997-01-29 0:00 ` Stanley R. Allen 1997-01-30 0:00 ` Robert A Duff 0 siblings, 1 reply; 391+ messages in thread From: Stanley R. Allen @ 1997-01-29 0:00 UTC (permalink / raw) Cc: James O'Connor 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-29 0:00 ` Stanley R. Allen @ 1997-01-30 0:00 ` Robert A Duff 0 siblings, 0 replies; 391+ messages in thread From: Robert A Duff @ 1997-01-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Alan Lovejoy 1997-01-18 0:00 ` Fergus Henderson 1997-01-21 0:00 ` Norman H. Cohen @ 1997-01-27 0:00 ` Jon S Anthony 2 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Alan Lovejoy 1997-01-17 0:00 ` Norman H. Cohen @ 1997-01-19 0:00 ` Keith Thompson 1 sibling, 0 replies; 391+ messages in thread From: Keith Thompson @ 1997-01-19 0:00 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 ` Matthew Heaney 1997-01-17 0:00 ` Alan Lovejoy @ 1997-01-22 0:00 ` Don Harrison 1997-01-23 0:00 ` Norman H. Cohen 1997-01-23 0:00 ` Robert I. Eachus 1 sibling, 2 replies; 391+ messages in thread From: Don Harrison @ 1997-01-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Don Harrison @ 1997-01-23 0:00 ` Norman H. Cohen 1997-01-24 0:00 ` Don Harrison 1997-01-23 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 391+ messages in thread From: Norman H. Cohen @ 1997-01-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-23 0:00 ` Norman H. Cohen @ 1997-01-24 0:00 ` Don Harrison 1997-01-27 0:00 ` Norman H. Cohen 0 siblings, 1 reply; 391+ messages in thread From: Don Harrison @ 1997-01-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-24 0:00 ` Don Harrison @ 1997-01-27 0:00 ` Norman H. Cohen 0 siblings, 0 replies; 391+ messages in thread From: Norman H. Cohen @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Don Harrison 1997-01-23 0:00 ` Norman H. Cohen @ 1997-01-23 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 391+ messages in thread From: Robert I. Eachus @ 1997-01-23 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Don Harrison 1997-01-16 0:00 ` Matthew Heaney @ 1997-01-20 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-01-24 0:00 ` Jon S Anthony ` (6 subsequent siblings) 8 siblings, 0 replies; 391+ messages in thread From: Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-01-20 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Don Harrison 1997-01-16 0:00 ` Matthew Heaney 1997-01-20 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-01-24 0:00 ` Jon S Anthony 1997-01-26 0:00 ` Eric Clayberg ` (5 subsequent siblings) 8 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Don Harrison ` (2 preceding siblings ...) 1997-01-24 0:00 ` Jon S Anthony @ 1997-01-26 0:00 ` Eric Clayberg 1997-01-27 0:00 ` Jon S Anthony ` (4 subsequent siblings) 8 siblings, 0 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Don Harrison ` (3 preceding siblings ...) 1997-01-26 0:00 ` Eric Clayberg @ 1997-01-27 0:00 ` Jon S Anthony 1997-01-27 0:00 ` Jon S Anthony ` (3 subsequent siblings) 8 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Don Harrison ` (4 preceding siblings ...) 1997-01-27 0:00 ` Jon S Anthony @ 1997-01-27 0:00 ` Jon S Anthony 1997-01-27 0:00 ` Jon S Anthony ` (2 subsequent siblings) 8 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Don Harrison ` (5 preceding siblings ...) 1997-01-27 0:00 ` Jon S Anthony @ 1997-01-27 0:00 ` Jon S Anthony 1997-01-28 0:00 ` Jon S Anthony 1997-01-29 0:00 ` Stephen J Bevan 8 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Don Harrison ` (6 preceding siblings ...) 1997-01-27 0:00 ` Jon S Anthony @ 1997-01-28 0:00 ` Jon S Anthony 1997-01-29 0:00 ` Stephen J Bevan 8 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-17 0:00 ` Don Harrison ` (7 preceding siblings ...) 1997-01-28 0:00 ` Jon S Anthony @ 1997-01-29 0:00 ` Stephen J Bevan 8 siblings, 0 replies; 391+ messages in thread From: Stephen J Bevan @ 1997-01-29 0:00 UTC (permalink / raw) 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 } ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 Jon S Anthony 1997-01-17 0:00 ` Don Harrison @ 1997-01-21 0:00 ` Joachim Durchholz 1997-01-22 0:00 ` Richard A. O'Keefe 1997-01-27 0:00 ` John Woods 1997-01-22 0:00 ` Eric Clayberg ` (8 subsequent siblings) 10 siblings, 2 replies; 391+ messages in thread From: Joachim Durchholz @ 1997-01-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 ` Joachim Durchholz @ 1997-01-22 0:00 ` Richard A. O'Keefe 1997-01-27 0:00 ` Robert A Duff 1997-01-27 0:00 ` Robert Dewar 1997-01-27 0:00 ` John Woods 1 sibling, 2 replies; 391+ messages in thread From: Richard A. O'Keefe @ 1997-01-22 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Richard A. O'Keefe @ 1997-01-27 0:00 ` Robert A Duff 1997-01-27 0:00 ` Bob Jarvis ` (2 more replies) 1997-01-27 0:00 ` Robert Dewar 1 sibling, 3 replies; 391+ messages in thread From: Robert A Duff @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Robert A Duff @ 1997-01-27 0:00 ` Bob Jarvis 1997-01-28 0:00 ` Travis Griggs 1997-01-28 0:00 ` Norman H. Cohen 1997-01-28 0:00 ` Russ McClelland 2 siblings, 1 reply; 391+ messages in thread From: Bob Jarvis @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Bob Jarvis @ 1997-01-28 0:00 ` Travis Griggs 0 siblings, 0 replies; 391+ messages in thread From: Travis Griggs @ 1997-01-28 0:00 UTC (permalink / raw) Cc: krg, rfazzari, fskorina 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Robert A Duff 1997-01-27 0:00 ` Bob Jarvis @ 1997-01-28 0:00 ` Norman H. Cohen 1997-01-28 0:00 ` Russ McClelland 2 siblings, 0 replies; 391+ messages in thread From: Norman H. Cohen @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Robert A Duff 1997-01-27 0:00 ` Bob Jarvis 1997-01-28 0:00 ` Norman H. Cohen @ 1997-01-28 0:00 ` Russ McClelland 2 siblings, 0 replies; 391+ messages in thread From: Russ McClelland @ 1997-01-28 0:00 UTC (permalink / raw) > >>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). ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-22 0:00 ` Richard A. O'Keefe 1997-01-27 0:00 ` Robert A Duff @ 1997-01-27 0:00 ` Robert Dewar 1997-01-27 0:00 ` Robert A Duff 1 sibling, 1 reply; 391+ messages in thread From: Robert Dewar @ 1997-01-27 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Robert Dewar @ 1997-01-27 0:00 ` Robert A Duff 1997-01-29 0:00 ` Robert Dewar 0 siblings, 1 reply; 391+ messages in thread From: Robert A Duff @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Robert A Duff @ 1997-01-29 0:00 ` Robert Dewar 0 siblings, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-29 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-21 0:00 ` Joachim Durchholz 1997-01-22 0:00 ` Richard A. O'Keefe @ 1997-01-27 0:00 ` John Woods 1 sibling, 0 replies; 391+ messages in thread From: John Woods @ 1997-01-27 0:00 UTC (permalink / raw) 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 " ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 Jon S Anthony 1997-01-17 0:00 ` Don Harrison 1997-01-21 0:00 ` Joachim Durchholz @ 1997-01-22 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Joachim Durchholz ` (7 subsequent siblings) 10 siblings, 0 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 Jon S Anthony ` (2 preceding siblings ...) 1997-01-22 0:00 ` Eric Clayberg @ 1997-01-23 0:00 ` Joachim Durchholz 1997-01-24 0:00 ` Joachim Durchholz ` (6 subsequent siblings) 10 siblings, 0 replies; 391+ messages in thread From: Joachim Durchholz @ 1997-01-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 Jon S Anthony ` (3 preceding siblings ...) 1997-01-23 0:00 ` Joachim Durchholz @ 1997-01-24 0:00 ` Joachim Durchholz 1997-01-25 0:00 ` Eric Clayberg ` (5 subsequent siblings) 10 siblings, 0 replies; 391+ messages in thread From: Joachim Durchholz @ 1997-01-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 Jon S Anthony ` (4 preceding siblings ...) 1997-01-24 0:00 ` Joachim Durchholz @ 1997-01-25 0:00 ` Eric Clayberg 1997-01-25 0:00 ` Tansel Ersavas ` (4 subsequent siblings) 10 siblings, 0 replies; 391+ messages in thread From: Eric Clayberg @ 1997-01-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 Jon S Anthony ` (5 preceding siblings ...) 1997-01-25 0:00 ` Eric Clayberg @ 1997-01-25 0:00 ` Tansel Ersavas 1997-01-25 0:00 ` James O'Connor ` (3 subsequent siblings) 10 siblings, 0 replies; 391+ messages in thread From: Tansel Ersavas @ 1997-01-25 0:00 UTC (permalink / raw) 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----------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 Jon S Anthony ` (6 preceding siblings ...) 1997-01-25 0:00 ` Tansel Ersavas @ 1997-01-25 0:00 ` James O'Connor 1997-01-26 0:00 ` Lawrence G. Mayka 1997-01-27 0:00 ` Norman H. Cohen ` (2 subsequent siblings) 10 siblings, 1 reply; 391+ messages in thread From: James O'Connor @ 1997-01-25 0:00 UTC (permalink / raw) To: Joachim Durchholz 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 -------------------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-25 0:00 ` James O'Connor @ 1997-01-26 0:00 ` Lawrence G. Mayka 1997-01-26 0:00 ` James O'Connor 0 siblings, 1 reply; 391+ messages in thread From: Lawrence G. Mayka @ 1997-01-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-26 0:00 ` Lawrence G. Mayka @ 1997-01-26 0:00 ` James O'Connor 0 siblings, 0 replies; 391+ messages in thread From: James O'Connor @ 1997-01-26 0:00 UTC (permalink / raw) To: Lawrence G. Mayka 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 -------------------------------------- ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 Jon S Anthony ` (7 preceding siblings ...) 1997-01-25 0:00 ` James O'Connor @ 1997-01-27 0:00 ` Norman H. Cohen 1997-02-07 0:00 ` Richard A. O'Keefe 1997-02-25 0:00 ` Jon S Anthony 10 siblings, 0 replies; 391+ messages in thread From: Norman H. Cohen @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 Jon S Anthony ` (8 preceding siblings ...) 1997-01-27 0:00 ` Norman H. Cohen @ 1997-02-07 0:00 ` Richard A. O'Keefe 1997-02-07 0:00 ` Alan Lovejoy ` (18 more replies) 1997-02-25 0:00 ` Jon S Anthony 10 siblings, 19 replies; 391+ messages in thread From: Richard A. O'Keefe @ 1997-02-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe @ 1997-02-07 0:00 ` Alan Lovejoy 1997-02-12 0:00 ` Piercarlo Grandi 1997-02-13 0:00 ` Richard A. O'Keefe 1997-02-15 0:00 ` Jon S Anthony ` (17 subsequent siblings) 18 siblings, 2 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-02-07 0:00 UTC (permalink / raw) 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 |==============================================| ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Alan Lovejoy @ 1997-02-12 0:00 ` Piercarlo Grandi 1997-02-13 0:00 ` Alan Lovejoy 1997-02-13 0:00 ` Richard A. O'Keefe 1 sibling, 1 reply; 391+ messages in thread From: Piercarlo Grandi @ 1997-02-12 0:00 UTC (permalink / raw) >>> "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... ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-12 0:00 ` Piercarlo Grandi @ 1997-02-13 0:00 ` Alan Lovejoy [not found] ` <yf3ybcsm5ce.fsf@sabi.demon.co.uk> 0 siblings, 1 reply; 391+ messages in thread From: Alan Lovejoy @ 1997-02-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
[parent not found: <yf3ybcsm5ce.fsf@sabi.demon.co.uk>]
* Re: OO, C++, and something much better! [not found] ` <yf3ybcsm5ce.fsf@sabi.demon.co.uk> @ 1997-02-14 0:00 ` Alan Lovejoy 1997-02-16 0:00 ` Piercarlo Grandi 0 siblings, 1 reply; 391+ messages in thread From: Alan Lovejoy @ 1997-02-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-14 0:00 ` Alan Lovejoy @ 1997-02-16 0:00 ` Piercarlo Grandi 1997-02-16 0:00 ` Alan Lovejoy 0 siblings, 1 reply; 391+ messages in thread From: Piercarlo Grandi @ 1997-02-16 0:00 UTC (permalink / raw) >>> "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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-16 0:00 ` Piercarlo Grandi @ 1997-02-16 0:00 ` Alan Lovejoy 1997-02-17 0:00 ` Piercarlo Grandi 0 siblings, 1 reply; 391+ messages in thread From: Alan Lovejoy @ 1997-02-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-16 0:00 ` Alan Lovejoy @ 1997-02-17 0:00 ` Piercarlo Grandi 0 siblings, 0 replies; 391+ messages in thread From: Piercarlo Grandi @ 1997-02-17 0:00 UTC (permalink / raw) >>> "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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Alan Lovejoy 1997-02-12 0:00 ` Piercarlo Grandi @ 1997-02-13 0:00 ` Richard A. O'Keefe 1997-02-13 0:00 ` Alan Lovejoy 1 sibling, 1 reply; 391+ messages in thread From: Richard A. O'Keefe @ 1997-02-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-13 0:00 ` Richard A. O'Keefe @ 1997-02-13 0:00 ` Alan Lovejoy 1997-02-18 0:00 ` Richard A. O'Keefe 0 siblings, 1 reply; 391+ messages in thread From: Alan Lovejoy @ 1997-02-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-13 0:00 ` Alan Lovejoy @ 1997-02-18 0:00 ` Richard A. O'Keefe 1997-02-19 0:00 ` richard ` (2 more replies) 0 siblings, 3 replies; 391+ messages in thread From: Richard A. O'Keefe @ 1997-02-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-18 0:00 ` Richard A. O'Keefe @ 1997-02-19 0:00 ` richard 1997-02-19 0:00 ` Mike Klein 1997-02-19 0:00 ` William Clodius 2 siblings, 0 replies; 391+ messages in thread From: richard @ 1997-02-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-18 0:00 ` Richard A. O'Keefe 1997-02-19 0:00 ` richard @ 1997-02-19 0:00 ` Mike Klein 1997-02-19 0:00 ` William Clodius 2 siblings, 0 replies; 391+ messages in thread From: Mike Klein @ 1997-02-19 0:00 UTC (permalink / raw) To: Richard A. O'Keefe 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-18 0:00 ` Richard A. O'Keefe 1997-02-19 0:00 ` richard 1997-02-19 0:00 ` Mike Klein @ 1997-02-19 0:00 ` William Clodius 1997-02-19 0:00 ` Mike Klein 2 siblings, 1 reply; 391+ messages in thread From: William Clodius @ 1997-02-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-19 0:00 ` William Clodius @ 1997-02-19 0:00 ` Mike Klein 0 siblings, 0 replies; 391+ messages in thread From: Mike Klein @ 1997-02-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe 1997-02-07 0:00 ` Alan Lovejoy @ 1997-02-15 0:00 ` Jon S Anthony 1997-02-16 0:00 ` Piercarlo Grandi 1997-02-16 0:00 ` Jon S Anthony ` (16 subsequent siblings) 18 siblings, 1 reply; 391+ messages in thread From: Jon S Anthony @ 1997-02-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-15 0:00 ` Jon S Anthony @ 1997-02-16 0:00 ` Piercarlo Grandi 0 siblings, 0 replies; 391+ messages in thread From: Piercarlo Grandi @ 1997-02-16 0:00 UTC (permalink / raw) >>> "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 :-) ... ] ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe 1997-02-07 0:00 ` Alan Lovejoy 1997-02-15 0:00 ` Jon S Anthony @ 1997-02-16 0:00 ` Jon S Anthony 1997-02-18 0:00 ` Richard A. O'Keefe 1997-02-17 0:00 ` Alan Lovejoy ` (15 subsequent siblings) 18 siblings, 1 reply; 391+ messages in thread From: Jon S Anthony @ 1997-02-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-16 0:00 ` Jon S Anthony @ 1997-02-18 0:00 ` Richard A. O'Keefe 1997-02-20 0:00 ` Matt Kennel 0 siblings, 1 reply; 391+ messages in thread From: Richard A. O'Keefe @ 1997-02-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-18 0:00 ` Richard A. O'Keefe @ 1997-02-20 0:00 ` Matt Kennel 1997-02-20 0:00 ` Anders Pytte 0 siblings, 1 reply; 391+ messages in thread From: Matt Kennel @ 1997-02-20 0:00 UTC (permalink / raw) 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.'' ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-20 0:00 ` Matt Kennel @ 1997-02-20 0:00 ` Anders Pytte 0 siblings, 0 replies; 391+ messages in thread From: Anders Pytte @ 1997-02-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (2 preceding siblings ...) 1997-02-16 0:00 ` Jon S Anthony @ 1997-02-17 0:00 ` Alan Lovejoy 1997-02-17 0:00 ` Jon S Anthony ` (14 subsequent siblings) 18 siblings, 0 replies; 391+ messages in thread From: Alan Lovejoy @ 1997-02-17 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (3 preceding siblings ...) 1997-02-17 0:00 ` Alan Lovejoy @ 1997-02-17 0:00 ` Jon S Anthony 1997-02-19 0:00 ` Piercarlo Grandi 1997-02-17 0:00 ` Jon S Anthony ` (13 subsequent siblings) 18 siblings, 1 reply; 391+ messages in thread From: Jon S Anthony @ 1997-02-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-17 0:00 ` Jon S Anthony @ 1997-02-19 0:00 ` Piercarlo Grandi 0 siblings, 0 replies; 391+ messages in thread From: Piercarlo Grandi @ 1997-02-19 0:00 UTC (permalink / raw) >>> "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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (4 preceding siblings ...) 1997-02-17 0:00 ` Jon S Anthony @ 1997-02-17 0:00 ` Jon S Anthony 1997-02-19 0:00 ` Piercarlo Grandi 1997-02-17 0:00 ` Jon S Anthony ` (12 subsequent siblings) 18 siblings, 1 reply; 391+ messages in thread From: Jon S Anthony @ 1997-02-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-17 0:00 ` Jon S Anthony @ 1997-02-19 0:00 ` Piercarlo Grandi 1997-02-19 0:00 ` Mike Klein 0 siblings, 1 reply; 391+ messages in thread From: Piercarlo Grandi @ 1997-02-19 0:00 UTC (permalink / raw) >>> "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 :-) :-) :-) ... ] ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-19 0:00 ` Piercarlo Grandi @ 1997-02-19 0:00 ` Mike Klein 0 siblings, 0 replies; 391+ messages in thread From: Mike Klein @ 1997-02-19 0:00 UTC (permalink / raw) [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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (5 preceding siblings ...) 1997-02-17 0:00 ` Jon S Anthony @ 1997-02-17 0:00 ` Jon S Anthony 1997-02-18 0:00 ` Bernard Badger ` (11 subsequent siblings) 18 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-02-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (6 preceding siblings ...) 1997-02-17 0:00 ` Jon S Anthony @ 1997-02-18 0:00 ` Bernard Badger 1997-02-18 0:00 ` Jon S Anthony ` (10 subsequent siblings) 18 siblings, 0 replies; 391+ messages in thread From: Bernard Badger @ 1997-02-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (7 preceding siblings ...) 1997-02-18 0:00 ` Bernard Badger @ 1997-02-18 0:00 ` Jon S Anthony 1997-02-19 0:00 ` Piercarlo Grandi 1997-02-19 0:00 ` Piercarlo Grandi 1997-02-21 0:00 ` Jon S Anthony ` (9 subsequent siblings) 18 siblings, 2 replies; 391+ messages in thread From: Jon S Anthony @ 1997-02-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-18 0:00 ` Jon S Anthony @ 1997-02-19 0:00 ` Piercarlo Grandi 1997-02-19 0:00 ` Piercarlo Grandi 1 sibling, 0 replies; 391+ messages in thread From: Piercarlo Grandi @ 1997-02-19 0:00 UTC (permalink / raw) >>> "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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-18 0:00 ` Jon S Anthony 1997-02-19 0:00 ` Piercarlo Grandi @ 1997-02-19 0:00 ` Piercarlo Grandi 1 sibling, 0 replies; 391+ messages in thread From: Piercarlo Grandi @ 1997-02-19 0:00 UTC (permalink / raw) >>> "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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (8 preceding siblings ...) 1997-02-18 0:00 ` Jon S Anthony @ 1997-02-21 0:00 ` Jon S Anthony 1997-02-24 0:00 ` Piercarlo Grandi 1997-02-22 0:00 ` Jon S Anthony ` (8 subsequent siblings) 18 siblings, 1 reply; 391+ messages in thread From: Jon S Anthony @ 1997-02-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-21 0:00 ` Jon S Anthony @ 1997-02-24 0:00 ` Piercarlo Grandi 0 siblings, 0 replies; 391+ messages in thread From: Piercarlo Grandi @ 1997-02-24 0:00 UTC (permalink / raw) >>> "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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (9 preceding siblings ...) 1997-02-21 0:00 ` Jon S Anthony @ 1997-02-22 0:00 ` Jon S Anthony 1997-02-22 0:00 ` Jon S Anthony ` (7 subsequent siblings) 18 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-02-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (10 preceding siblings ...) 1997-02-22 0:00 ` Jon S Anthony @ 1997-02-22 0:00 ` Jon S Anthony 1997-02-25 0:00 ` Richard A. O'Keefe 1997-02-22 0:00 ` Jon S Anthony ` (6 subsequent siblings) 18 siblings, 1 reply; 391+ messages in thread From: Jon S Anthony @ 1997-02-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-22 0:00 ` Jon S Anthony @ 1997-02-25 0:00 ` Richard A. O'Keefe 0 siblings, 0 replies; 391+ messages in thread From: Richard A. O'Keefe @ 1997-02-25 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (11 preceding siblings ...) 1997-02-22 0:00 ` Jon S Anthony @ 1997-02-22 0:00 ` Jon S Anthony 1997-02-22 0:00 ` Jon S Anthony ` (5 subsequent siblings) 18 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-02-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (12 preceding siblings ...) 1997-02-22 0:00 ` Jon S Anthony @ 1997-02-22 0:00 ` Jon S Anthony 1997-02-22 0:00 ` Jon S Anthony ` (4 subsequent siblings) 18 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-02-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (13 preceding siblings ...) 1997-02-22 0:00 ` Jon S Anthony @ 1997-02-22 0:00 ` Jon S Anthony 1997-02-25 0:00 ` Jon S Anthony ` (3 subsequent siblings) 18 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-02-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (14 preceding siblings ...) 1997-02-22 0:00 ` Jon S Anthony @ 1997-02-25 0:00 ` Jon S Anthony 1997-02-27 0:00 ` Clayton Weaver 1997-02-25 0:00 ` Jon S Anthony ` (2 subsequent siblings) 18 siblings, 1 reply; 391+ messages in thread From: Jon S Anthony @ 1997-02-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-25 0:00 ` Jon S Anthony @ 1997-02-27 0:00 ` Clayton Weaver 0 siblings, 0 replies; 391+ messages in thread From: Clayton Weaver @ 1997-02-27 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (15 preceding siblings ...) 1997-02-25 0:00 ` Jon S Anthony @ 1997-02-25 0:00 ` Jon S Anthony 1997-02-25 0:00 ` Jon S Anthony 1997-02-26 0:00 ` Mike Klein 18 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-02-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (16 preceding siblings ...) 1997-02-25 0:00 ` Jon S Anthony @ 1997-02-25 0:00 ` Jon S Anthony 1997-02-26 0:00 ` Mike Klein 18 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-02-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-02-07 0:00 ` Richard A. O'Keefe ` (17 preceding siblings ...) 1997-02-25 0:00 ` Jon S Anthony @ 1997-02-26 0:00 ` Mike Klein 18 siblings, 0 replies; 391+ messages in thread From: Mike Klein @ 1997-02-26 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 Jon S Anthony ` (9 preceding siblings ...) 1997-02-07 0:00 ` Richard A. O'Keefe @ 1997-02-25 0:00 ` Jon S Anthony 10 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-02-25 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! @ 1997-01-08 0:00 Sazonov Cyril 1997-01-11 0:00 ` Bjarne Stroustrup 0 siblings, 1 reply; 391+ messages in thread From: Sazonov Cyril @ 1997-01-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-08 0:00 Sazonov Cyril @ 1997-01-11 0:00 ` Bjarne Stroustrup 0 siblings, 0 replies; 391+ messages in thread From: Bjarne Stroustrup @ 1997-01-11 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: What is wrong with OO ?
@ 1997-01-01 0:00 Jon S Anthony
1997-01-02 0:00 ` Robert C. Martin
` (8 more replies)
0 siblings, 9 replies; 391+ messages in thread
From: Jon S Anthony @ 1997-01-01 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: What is wrong with OO ? 1997-01-01 0:00 What is wrong with OO ? Jon S Anthony @ 1997-01-02 0:00 ` Robert C. Martin 1997-01-03 0:00 ` Eirik Mangseth ` (4 more replies) 1997-01-04 0:00 ` Pieter Schoenmakers ` (7 subsequent siblings) 8 siblings, 5 replies; 391+ messages in thread From: Robert C. Martin @ 1997-01-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: What is wrong with OO ? 1997-01-02 0:00 ` Robert C. Martin @ 1997-01-03 0:00 ` Eirik Mangseth 1997-01-03 0:00 ` What is wrong with OO O X g Greg Comeau 1997-01-08 0:00 ` Robert I. Eachus ` (3 subsequent siblings) 4 siblings, 1 reply; 391+ messages in thread From: Eirik Mangseth @ 1997-01-03 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: What is wrong with OO O X g 1997-01-03 0:00 ` Eirik Mangseth @ 1997-01-03 0:00 ` Greg Comeau 1997-01-04 0:00 ` OO, C++, and something much better! John (Max) Skaller 0 siblings, 1 reply; 391+ messages in thread From: Greg Comeau @ 1997-01-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* OO, C++, and something much better! 1997-01-03 0:00 ` What is wrong with OO O X g Greg Comeau @ 1997-01-04 0:00 ` John (Max) Skaller 1997-01-04 0:00 ` vlad ` (3 more replies) 0 siblings, 4 replies; 391+ messages in thread From: John (Max) Skaller @ 1997-01-04 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-04 0:00 ` OO, C++, and something much better! John (Max) Skaller @ 1997-01-04 0:00 ` vlad 1997-01-05 0:00 ` Mike Anderson ` (2 subsequent siblings) 3 siblings, 0 replies; 391+ messages in thread From: vlad @ 1997-01-04 0:00 UTC (permalink / raw) 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 * ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-04 0:00 ` OO, C++, and something much better! John (Max) Skaller 1997-01-04 0:00 ` vlad @ 1997-01-05 0:00 ` Mike Anderson 1997-01-06 0:00 ` Chris Brand 1997-01-06 0:00 ` Stanley Allen 3 siblings, 0 replies; 391+ messages in thread From: Mike Anderson @ 1997-01-05 0:00 UTC (permalink / raw) To: skaller 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-04 0:00 ` OO, C++, and something much better! John (Max) Skaller 1997-01-04 0:00 ` vlad 1997-01-05 0:00 ` Mike Anderson @ 1997-01-06 0:00 ` Chris Brand 1997-01-06 0:00 ` Stanley Allen 3 siblings, 0 replies; 391+ messages in thread From: Chris Brand @ 1997-01-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-04 0:00 ` OO, C++, and something much better! John (Max) Skaller ` (2 preceding siblings ...) 1997-01-06 0:00 ` Chris Brand @ 1997-01-06 0:00 ` Stanley Allen 1997-01-09 0:00 ` Jon S Anthony 3 siblings, 1 reply; 391+ messages in thread From: Stanley Allen @ 1997-01-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-06 0:00 ` Stanley Allen @ 1997-01-09 0:00 ` Jon S Anthony 0 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-02 0:00 ` Robert C. Martin 1997-01-03 0:00 ` Eirik Mangseth @ 1997-01-08 0:00 ` Robert I. Eachus 1997-01-09 0:00 ` Bertrand Meyer ` (2 subsequent siblings) 4 siblings, 0 replies; 391+ messages in thread From: Robert I. Eachus @ 1997-01-08 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-02 0:00 ` Robert C. Martin 1997-01-03 0:00 ` Eirik Mangseth 1997-01-08 0:00 ` Robert I. Eachus @ 1997-01-09 0:00 ` Bertrand Meyer 1997-01-27 0:00 ` Richard Riehle 1997-01-10 0:00 ` Robert I. Eachus 1997-01-10 0:00 ` Robb Nebbe 4 siblings, 1 reply; 391+ messages in thread From: Bertrand Meyer @ 1997-01-09 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-09 0:00 ` Bertrand Meyer @ 1997-01-27 0:00 ` Richard Riehle 0 siblings, 0 replies; 391+ messages in thread From: Richard Riehle @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-02 0:00 ` Robert C. Martin ` (2 preceding siblings ...) 1997-01-09 0:00 ` Bertrand Meyer @ 1997-01-10 0:00 ` Robert I. Eachus 1997-01-10 0:00 ` Robb Nebbe 4 siblings, 0 replies; 391+ messages in thread From: Robert I. Eachus @ 1997-01-10 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-02 0:00 ` Robert C. Martin ` (3 preceding siblings ...) 1997-01-10 0:00 ` Robert I. Eachus @ 1997-01-10 0:00 ` Robb Nebbe 4 siblings, 0 replies; 391+ messages in thread From: Robb Nebbe @ 1997-01-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-01 0:00 What is wrong with OO ? Jon S Anthony 1997-01-02 0:00 ` Robert C. Martin @ 1997-01-04 0:00 ` Pieter Schoenmakers 1997-01-06 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB ` (6 subsequent siblings) 8 siblings, 0 replies; 391+ messages in thread From: Pieter Schoenmakers @ 1997-01-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-01 0:00 What is wrong with OO ? Jon S Anthony 1997-01-02 0:00 ` Robert C. Martin 1997-01-04 0:00 ` Pieter Schoenmakers @ 1997-01-06 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-01-06 0:00 ` Michael F Brenner ` (3 more replies) 1997-01-07 0:00 ` Stanley Allen ` (5 subsequent siblings) 8 siblings, 4 replies; 391+ messages in thread From: Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-01-06 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-06 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-01-06 0:00 ` Michael F Brenner 1997-01-06 0:00 ` Tucker Taft 1997-01-08 0:00 ` Robert Dewar 1997-01-07 0:00 ` Jay Martin ` (2 subsequent siblings) 3 siblings, 2 replies; 391+ messages in thread From: Michael F Brenner @ 1997-01-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-06 0:00 ` Michael F Brenner @ 1997-01-06 0:00 ` Tucker Taft 1997-01-07 0:00 ` Robert Dewar 1997-01-08 0:00 ` Robert Dewar 1 sibling, 1 reply; 391+ messages in thread From: Tucker Taft @ 1997-01-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-06 0:00 ` Tucker Taft @ 1997-01-07 0:00 ` Robert Dewar 0 siblings, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-06 0:00 ` Michael F Brenner 1997-01-06 0:00 ` Tucker Taft @ 1997-01-08 0:00 ` Robert Dewar 1 sibling, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-08 0:00 UTC (permalink / raw) 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 ... ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-06 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-01-06 0:00 ` Michael F Brenner @ 1997-01-07 0:00 ` Jay Martin 1997-01-08 0:00 ` Ken Garlington 1997-01-07 0:00 ` Andrew Koenig 1997-01-12 0:00 ` Richard Riehle 3 siblings, 1 reply; 391+ messages in thread From: Jay Martin @ 1997-01-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-07 0:00 ` Jay Martin @ 1997-01-08 0:00 ` Ken Garlington 1997-01-08 0:00 ` Robert Dewar 0 siblings, 1 reply; 391+ messages in thread From: Ken Garlington @ 1997-01-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-08 0:00 ` Ken Garlington @ 1997-01-08 0:00 ` Robert Dewar 1997-01-08 0:00 ` Robert Dewar 1997-01-09 0:00 ` Ted Dennison 0 siblings, 2 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-08 0:00 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-08 0:00 ` Robert Dewar @ 1997-01-08 0:00 ` Robert Dewar 1997-01-09 0:00 ` Ted Dennison 1 sibling, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-08 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-08 0:00 ` Robert Dewar 1997-01-08 0:00 ` Robert Dewar @ 1997-01-09 0:00 ` Ted Dennison 1 sibling, 0 replies; 391+ messages in thread From: Ted Dennison @ 1997-01-09 0:00 UTC (permalink / raw) 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 | ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-06 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-01-06 0:00 ` Michael F Brenner 1997-01-07 0:00 ` Jay Martin @ 1997-01-07 0:00 ` Andrew Koenig 1997-01-10 0:00 ` Norman H. Cohen 1997-01-12 0:00 ` Richard Riehle 3 siblings, 1 reply; 391+ messages in thread From: Andrew Koenig @ 1997-01-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-07 0:00 ` Andrew Koenig @ 1997-01-10 0:00 ` Norman H. Cohen 0 siblings, 0 replies; 391+ messages in thread From: Norman H. Cohen @ 1997-01-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-06 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB ` (2 preceding siblings ...) 1997-01-07 0:00 ` Andrew Koenig @ 1997-01-12 0:00 ` Richard Riehle 3 siblings, 0 replies; 391+ messages in thread From: Richard Riehle @ 1997-01-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-01 0:00 What is wrong with OO ? Jon S Anthony ` (2 preceding siblings ...) 1997-01-06 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-01-07 0:00 ` Stanley Allen 1997-01-07 0:00 ` Robert Dewar 1997-01-08 0:00 ` Jon S Anthony ` (4 subsequent siblings) 8 siblings, 1 reply; 391+ messages in thread From: Stanley Allen @ 1997-01-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-07 0:00 ` Stanley Allen @ 1997-01-07 0:00 ` Robert Dewar 1997-01-07 0:00 ` Bertrand Meyer 1997-01-10 0:00 ` Keith Thompson 0 siblings, 2 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-07 0:00 ` Robert Dewar @ 1997-01-07 0:00 ` Bertrand Meyer 1997-01-08 0:00 ` Ken Garlington 1997-01-08 0:00 ` Matthew Heaney 1997-01-10 0:00 ` Keith Thompson 1 sibling, 2 replies; 391+ messages in thread From: Bertrand Meyer @ 1997-01-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-07 0:00 ` Bertrand Meyer @ 1997-01-08 0:00 ` Ken Garlington 1997-01-08 0:00 ` Matthew Heaney 1 sibling, 0 replies; 391+ messages in thread From: Ken Garlington @ 1997-01-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-07 0:00 ` Bertrand Meyer 1997-01-08 0:00 ` Ken Garlington @ 1997-01-08 0:00 ` Matthew Heaney 1 sibling, 0 replies; 391+ messages in thread From: Matthew Heaney @ 1997-01-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-07 0:00 ` Robert Dewar 1997-01-07 0:00 ` Bertrand Meyer @ 1997-01-10 0:00 ` Keith Thompson 1997-01-10 0:00 ` Robert Dewar 1997-01-15 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1 sibling, 2 replies; 391+ messages in thread From: Keith Thompson @ 1997-01-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-10 0:00 ` Keith Thompson @ 1997-01-10 0:00 ` Robert Dewar 1997-01-10 0:00 ` Robert Dewar 1997-01-15 0:00 ` Richard Kenner 1997-01-15 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1 sibling, 2 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-10 0:00 ` Robert Dewar @ 1997-01-10 0:00 ` Robert Dewar 1997-01-15 0:00 ` Richard Kenner 1 sibling, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-10 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-10 0:00 ` Robert Dewar 1997-01-10 0:00 ` Robert Dewar @ 1997-01-15 0:00 ` Richard Kenner 1997-01-15 0:00 ` Fergus Henderson ` (2 more replies) 1 sibling, 3 replies; 391+ messages in thread From: Richard Kenner @ 1997-01-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-15 0:00 ` Richard Kenner @ 1997-01-15 0:00 ` Fergus Henderson 1997-01-20 0:00 ` Andrew Koenig 1997-01-25 0:00 ` Robert Dewar 2 siblings, 0 replies; 391+ messages in thread From: Fergus Henderson @ 1997-01-15 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-15 0:00 ` Richard Kenner 1997-01-15 0:00 ` Fergus Henderson @ 1997-01-20 0:00 ` Andrew Koenig 1997-01-25 0:00 ` Robert Dewar 2 siblings, 0 replies; 391+ messages in thread From: Andrew Koenig @ 1997-01-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-15 0:00 ` Richard Kenner 1997-01-15 0:00 ` Fergus Henderson 1997-01-20 0:00 ` Andrew Koenig @ 1997-01-25 0:00 ` Robert Dewar 2 siblings, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-25 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-10 0:00 ` Keith Thompson 1997-01-10 0:00 ` Robert Dewar @ 1997-01-15 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1 sibling, 0 replies; 391+ messages in thread From: Ole-Hjalmar Kristensen FOU.TD/DELAB @ 1997-01-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-01 0:00 What is wrong with OO ? Jon S Anthony ` (3 preceding siblings ...) 1997-01-07 0:00 ` Stanley Allen @ 1997-01-08 0:00 ` Jon S Anthony 1997-01-08 0:00 ` Mark A Biggar 1997-01-09 0:00 ` Don Harrison 1997-01-08 0:00 ` David Emery ` (3 subsequent siblings) 8 siblings, 2 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-08 0:00 ` Jon S Anthony @ 1997-01-08 0:00 ` Mark A Biggar 1997-01-09 0:00 ` Don Harrison 1997-01-09 0:00 ` Don Harrison 1 sibling, 1 reply; 391+ messages in thread From: Mark A Biggar @ 1997-01-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-08 0:00 ` Mark A Biggar @ 1997-01-09 0:00 ` Don Harrison 1997-01-10 0:00 ` Roy Phillips 0 siblings, 1 reply; 391+ messages in thread From: Don Harrison @ 1997-01-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-09 0:00 ` Don Harrison @ 1997-01-10 0:00 ` Roy Phillips 1997-01-27 0:00 ` Nick Leaton 0 siblings, 1 reply; 391+ messages in thread From: Roy Phillips @ 1997-01-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-10 0:00 ` Roy Phillips @ 1997-01-27 0:00 ` Nick Leaton 1997-01-28 0:00 ` matthew mclellan 0 siblings, 1 reply; 391+ messages in thread From: Nick Leaton @ 1997-01-27 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-27 0:00 ` Nick Leaton @ 1997-01-28 0:00 ` matthew mclellan 0 siblings, 0 replies; 391+ messages in thread From: matthew mclellan @ 1997-01-28 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-08 0:00 ` Jon S Anthony 1997-01-08 0:00 ` Mark A Biggar @ 1997-01-09 0:00 ` Don Harrison 1997-01-09 0:00 ` Robert Dewar 1997-01-10 0:00 ` Jon S Anthony 1 sibling, 2 replies; 391+ messages in thread From: Don Harrison @ 1997-01-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-09 0:00 ` Don Harrison @ 1997-01-09 0:00 ` Robert Dewar 1997-01-10 0:00 ` Bart Samwel ` (3 more replies) 1997-01-10 0:00 ` Jon S Anthony 1 sibling, 4 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-09 0:00 ` Robert Dewar @ 1997-01-10 0:00 ` Bart Samwel 1997-01-10 0:00 ` Robert Dewar 1997-01-10 0:00 ` Ken Garlington ` (2 subsequent siblings) 3 siblings, 1 reply; 391+ messages in thread From: Bart Samwel @ 1997-01-10 0:00 UTC (permalink / raw) 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. ;-) ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-10 0:00 ` Bart Samwel @ 1997-01-10 0:00 ` Robert Dewar 0 siblings, 0 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-10 0:00 UTC (permalink / raw) 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 :-) ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-09 0:00 ` Robert Dewar 1997-01-10 0:00 ` Bart Samwel @ 1997-01-10 0:00 ` Ken Garlington 1997-01-10 0:00 ` Norman H. Cohen 1997-01-13 0:00 ` Don Harrison 3 siblings, 0 replies; 391+ messages in thread From: Ken Garlington @ 1997-01-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-09 0:00 ` Robert Dewar 1997-01-10 0:00 ` Bart Samwel 1997-01-10 0:00 ` Ken Garlington @ 1997-01-10 0:00 ` Norman H. Cohen 1997-01-13 0:00 ` Don Harrison 3 siblings, 0 replies; 391+ messages in thread From: Norman H. Cohen @ 1997-01-10 0:00 UTC (permalink / raw) (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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-09 0:00 ` Robert Dewar ` (2 preceding siblings ...) 1997-01-10 0:00 ` Norman H. Cohen @ 1997-01-13 0:00 ` Don Harrison 1997-01-13 0:00 ` Ken Garlington 1997-01-13 0:00 ` Robert Dewar 3 siblings, 2 replies; 391+ messages in thread From: Don Harrison @ 1997-01-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Don Harrison @ 1997-01-13 0:00 ` Ken Garlington 1997-01-13 0:00 ` Norman H. Cohen ` (3 more replies) 1997-01-13 0:00 ` Robert Dewar 1 sibling, 4 replies; 391+ messages in thread From: Ken Garlington @ 1997-01-13 0:00 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Ken Garlington @ 1997-01-13 0:00 ` Norman H. Cohen 1997-01-13 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 0 replies; 391+ messages in thread From: Norman H. Cohen @ 1997-01-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Ken Garlington 1997-01-13 0:00 ` Norman H. Cohen @ 1997-01-13 0:00 ` Robert Dewar 1997-01-15 0:00 ` Ken Garlington 1997-01-16 0:00 ` Keith Thompson 1997-01-14 0:00 ` Michael F Brenner 1997-01-14 0:00 ` Don Harrison 3 siblings, 2 replies; 391+ messages in thread From: Robert Dewar @ 1997-01-13 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Robert Dewar @ 1997-01-15 0:00 ` Ken Garlington 1997-01-17 0:00 ` Keith Thompson 1997-01-16 0:00 ` Keith Thompson 1 sibling, 1 reply; 391+ messages in thread From: Ken Garlington @ 1997-01-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-15 0:00 ` Ken Garlington @ 1997-01-17 0:00 ` Keith Thompson 0 siblings, 0 replies; 391+ messages in thread From: Keith Thompson @ 1997-01-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Robert Dewar 1997-01-15 0:00 ` Ken Garlington @ 1997-01-16 0:00 ` Keith Thompson 1997-01-16 0:00 ` Ken Garlington 1 sibling, 1 reply; 391+ messages in thread From: Keith Thompson @ 1997-01-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-16 0:00 ` Keith Thompson @ 1997-01-16 0:00 ` Ken Garlington 0 siblings, 0 replies; 391+ messages in thread From: Ken Garlington @ 1997-01-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Ken Garlington 1997-01-13 0:00 ` Norman H. Cohen 1997-01-13 0:00 ` Robert Dewar @ 1997-01-14 0:00 ` Michael F Brenner 1997-01-14 0:00 ` Don Harrison 3 siblings, 0 replies; 391+ messages in thread From: Michael F Brenner @ 1997-01-14 0:00 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Ken Garlington ` (2 preceding siblings ...) 1997-01-14 0:00 ` Michael F Brenner @ 1997-01-14 0:00 ` Don Harrison 3 siblings, 0 replies; 391+ messages in thread From: Don Harrison @ 1997-01-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Don Harrison 1997-01-13 0:00 ` Ken Garlington @ 1997-01-13 0:00 ` Robert Dewar 1997-01-14 0:00 ` Don Harrison 1 sibling, 1 reply; 391+ messages in thread From: Robert Dewar @ 1997-01-13 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Robert Dewar @ 1997-01-14 0:00 ` Don Harrison 0 siblings, 0 replies; 391+ messages in thread From: Don Harrison @ 1997-01-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-09 0:00 ` Don Harrison 1997-01-09 0:00 ` Robert Dewar @ 1997-01-10 0:00 ` Jon S Anthony 1997-01-13 0:00 ` Don Harrison 1 sibling, 1 reply; 391+ messages in thread From: Jon S Anthony @ 1997-01-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-10 0:00 ` Jon S Anthony @ 1997-01-13 0:00 ` Don Harrison 1997-01-13 0:00 ` Robert I. Eachus 1997-01-13 0:00 ` Don Harrison 0 siblings, 2 replies; 391+ messages in thread From: Don Harrison @ 1997-01-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Don Harrison @ 1997-01-13 0:00 ` Robert I. Eachus 1997-01-15 0:00 ` Don Harrison 1997-01-13 0:00 ` Don Harrison 1 sibling, 1 reply; 391+ messages in thread From: Robert I. Eachus @ 1997-01-13 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Robert I. Eachus @ 1997-01-15 0:00 ` Don Harrison 0 siblings, 0 replies; 391+ messages in thread From: Don Harrison @ 1997-01-15 0:00 UTC (permalink / raw) Robert I. Eachus writes: : Casting in C normally maps to type conversions in Ada: Okay. Don. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Don Harrison 1997-01-13 0:00 ` Robert I. Eachus @ 1997-01-13 0:00 ` Don Harrison 1997-01-14 0:00 ` Jeff Carter ` (2 more replies) 1 sibling, 3 replies; 391+ messages in thread From: Don Harrison @ 1997-01-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Don Harrison @ 1997-01-14 0:00 ` Jeff Carter 1997-01-15 0:00 ` Don Harrison 1997-01-18 0:00 ` Patrick Doyle 1997-01-20 0:00 ` Jon S Anthony 2 siblings, 1 reply; 391+ messages in thread From: Jeff Carter @ 1997-01-14 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-14 0:00 ` Jeff Carter @ 1997-01-15 0:00 ` Don Harrison 1997-01-17 0:00 ` Jon S Anthony 1997-01-17 0:00 ` Norman H. Cohen 0 siblings, 2 replies; 391+ messages in thread From: Don Harrison @ 1997-01-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-15 0:00 ` Don Harrison @ 1997-01-17 0:00 ` Jon S Anthony 1997-01-17 0:00 ` Norman H. Cohen 1 sibling, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-15 0:00 ` Don Harrison 1997-01-17 0:00 ` Jon S Anthony @ 1997-01-17 0:00 ` Norman H. Cohen 1 sibling, 0 replies; 391+ messages in thread From: Norman H. Cohen @ 1997-01-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Don Harrison 1997-01-14 0:00 ` Jeff Carter @ 1997-01-18 0:00 ` Patrick Doyle 1997-01-20 0:00 ` Jon S Anthony 2 siblings, 0 replies; 391+ messages in thread From: Patrick Doyle @ 1997-01-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-13 0:00 ` Don Harrison 1997-01-14 0:00 ` Jeff Carter 1997-01-18 0:00 ` Patrick Doyle @ 1997-01-20 0:00 ` Jon S Anthony 2 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-01 0:00 What is wrong with OO ? Jon S Anthony ` (4 preceding siblings ...) 1997-01-08 0:00 ` Jon S Anthony @ 1997-01-08 0:00 ` David Emery 1997-01-09 0:00 ` Don Harrison 1997-01-08 0:00 ` Kohler Markus ` (2 subsequent siblings) 8 siblings, 1 reply; 391+ messages in thread From: David Emery @ 1997-01-08 0:00 UTC (permalink / raw) >> - 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> ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-08 0:00 ` David Emery @ 1997-01-09 0:00 ` Don Harrison 1997-01-10 0:00 ` Marky Mark 0 siblings, 1 reply; 391+ messages in thread From: Don Harrison @ 1997-01-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-09 0:00 ` Don Harrison @ 1997-01-10 0:00 ` Marky Mark 1997-01-14 0:00 ` Don Harrison 0 siblings, 1 reply; 391+ messages in thread From: Marky Mark @ 1997-01-10 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-10 0:00 ` Marky Mark @ 1997-01-14 0:00 ` Don Harrison 0 siblings, 0 replies; 391+ messages in thread From: Don Harrison @ 1997-01-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-01 0:00 What is wrong with OO ? Jon S Anthony ` (5 preceding siblings ...) 1997-01-08 0:00 ` David Emery @ 1997-01-08 0:00 ` Kohler Markus 1997-01-10 0:00 ` Jon S Anthony 1997-01-10 0:00 ` Matt Austern 8 siblings, 0 replies; 391+ messages in thread From: Kohler Markus @ 1997-01-08 0:00 UTC (permalink / raw) >>>>> "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 | +----------------------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-01 0:00 What is wrong with OO ? Jon S Anthony ` (6 preceding siblings ...) 1997-01-08 0:00 ` Kohler Markus @ 1997-01-10 0:00 ` Jon S Anthony 1997-01-10 0:00 ` Matt Austern 8 siblings, 0 replies; 391+ messages in thread From: Jon S Anthony @ 1997-01-10 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 391+ messages in thread
* Re: OO, C++, and something much better! 1997-01-01 0:00 What is wrong with OO ? Jon S Anthony ` (7 preceding siblings ...) 1997-01-10 0:00 ` Jon S Anthony @ 1997-01-10 0:00 ` Matt Austern 8 siblings, 0 replies; 391+ messages in thread From: Matt Austern @ 1997-01-10 0:00 UTC (permalink / raw) [-- 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." ^ permalink raw reply [flat|nested] 391+ messages in thread
end of thread, other threads:[~1997-06-30 0:00 UTC | newest] Thread overview: 391+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-01-27 0:00 OO, C++, and something much better! Ell -- strict thread matches above, loose matches on Subject: below -- 1997-01-28 0:00 Snowball Info 1997-01-28 0:00 Ell 1997-01-22 0:00 Ell 1997-01-21 0:00 Ell 1997-01-21 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-01-16 0:00 Jon S Anthony 1997-01-17 0:00 ` Don Harrison 1997-01-16 0:00 ` Matthew Heaney 1997-01-17 0:00 ` Alan Lovejoy 1997-01-17 0:00 ` Norman H. Cohen 1997-01-17 0:00 ` Alan Lovejoy 1997-01-18 0:00 ` Fergus Henderson 1997-01-17 0:00 ` Alan Lovejoy 1997-01-20 0:00 ` Fergus Henderson 1997-01-19 0:00 ` Alan Lovejoy 1997-01-20 0:00 ` Damon Feldman 1997-01-19 0:00 ` Alan Lovejoy 1997-01-20 0:00 ` David Hanley 1997-01-21 0:00 ` Alan Lovejoy 1997-01-22 0:00 ` Fergus Henderson 1997-01-22 0:00 ` Alan Lovejoy 1997-01-23 0:00 ` Bob Jarvis 1997-01-20 0:00 ` Bill Gooch 1997-01-20 0:00 ` Graham Hughes 1997-01-21 0:00 ` Alan Lovejoy 1997-01-21 0:00 ` Matt Kennel 1997-01-21 0:00 ` Marc Robertson 1997-01-24 0:00 ` Mark Windholtz 1997-01-27 0:00 ` David Hanley 1997-01-28 0:00 ` Eric Clayberg 1997-01-28 0:00 ` David Hanley [not found] ` <32EE2FEE.62FE@p <32EE8415.2F5B@netright.com> 1997-01-28 0:00 ` Eric Clayberg 1997-01-29 0:00 ` David Hanley 1997-01-29 0:00 ` Eric Clayberg 1997-01-28 0:00 ` Alan Lovejoy 1997-01-29 0:00 ` Matt Kennel 1997-01-30 0:00 ` Alan Lovejoy 1997-01-30 0:00 ` David L. Shang 1997-01-29 0:00 ` Jun Nolasco 1997-01-22 0:00 ` Fergus Henderson 1997-01-22 0:00 ` Eric Clayberg 1997-01-22 0:00 ` Graham Hughes 1997-01-23 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Claus Reinke 1997-01-25 0:00 ` Eric Clayberg 1997-01-24 0:00 ` Static vs. Dynamic typing again (was Re: OO, C++, and something much better!) Robb Nebbe 1997-01-25 0:00 ` OO, C++, and something much better! David N. Smith 1997-01-25 0:00 ` Fergus Henderson 1997-01-25 0:00 ` Lawrence G. Mayka 1997-01-28 0:00 ` Claus Reinke 1997-01-24 0:00 ` Don Harrison 1997-01-24 0:00 ` Eric Clayberg 1997-01-28 0:00 ` Don Harrison 1997-01-23 0:00 ` Mark Woodruff 1997-01-24 0:00 ` Richard A. O'Keefe [not found] ` <E4voIF.86o@world.std.com> 1997-02-12 0:00 ` Ulf Schuenemann 1997-01-23 0:00 ` Robb Nebbe 1997-01-23 0:00 ` David Hanley 1997-01-25 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Matt Kennel 1997-01-25 0:00 ` Eric Clayberg 1997-01-27 0:00 ` Jon S Anthony 1997-01-24 0:00 ` Fergus Henderson 1997-01-24 0:00 ` Alan Lovejoy 1997-01-26 0:00 ` Fergus Henderson [not found] ` <32E9BAAC. <5ce8t3$6gv@mulga.cs.mu.OZ.AU> 1997-01-28 0:00 ` Alan Lovejoy 1997-01-28 0:00 ` Alan Knight 1997-01-29 0:00 ` Nick Leaton 1997-01-29 0:00 ` Fergus Henderson 1997-01-30 0:00 ` Alan Lovejoy 1997-01-24 0:00 ` Richard A. O'Keefe 1997-01-22 0:00 ` Fergus Henderson 1997-01-25 0:00 ` Joachim Durchholz 1997-01-27 0:00 ` Rolf Breuning 1997-01-27 0:00 ` Ed Shirk 1997-01-22 0:00 ` Damon Feldman 1997-01-29 0:00 ` Joachim Durchholz 1997-01-25 0:00 ` Jon S Anthony 1997-01-25 0:00 ` Eric Clayberg 1997-01-26 0:00 ` Robert Dewar 1997-01-27 0:00 ` Samuel S. Shuster 1997-01-27 0:00 ` Richard Kenner 1997-01-29 0:00 ` Robert Dewar 1997-01-30 0:00 ` Eirik Mangseth 1997-01-28 0:00 ` Jun Nolasco 1997-01-29 0:00 ` Robert Dewar 1997-01-29 0:00 ` Richard Kenner 1997-01-29 0:00 ` David Hanley 1997-01-29 0:00 ` Richard Kenner 1997-01-30 0:00 ` Nick Leaton 1997-01-30 0:00 ` Richard Kenner 1997-01-30 0:00 ` Nick Leaton 1997-01-30 0:00 ` Robert Dewar 1997-01-27 0:00 ` Bob Jarvis 1997-01-27 0:00 ` Robert Dewar 1997-01-27 0:00 ` Robert A Duff 1997-01-29 0:00 ` Robert Dewar 1997-01-27 0:00 ` Eric Clayberg 1997-01-29 0:00 ` Robert Dewar 1997-01-29 0:00 ` Robert A Duff 1997-01-29 0:00 ` Eric Clayberg 1997-01-27 0:00 ` Matthew Heaney 1997-01-27 0:00 ` Eric Clayberg 1997-01-28 0:00 ` Robert I. Eachus 1997-02-08 0:00 ` Robin Rosenberg 1997-01-27 0:00 ` Eric Clayberg 1997-01-29 0:00 ` Joachim Durchholz 1997-01-29 0:00 ` Fergus Henderson 1997-01-27 0:00 ` Jon S Anthony 1997-01-27 0:00 ` David Hanley 1997-01-29 0:00 ` Joachim Durchholz 1997-01-29 0:00 ` Dennis Smith 1997-01-28 0:00 ` Eric Clayberg 1997-01-28 0:00 ` Matt Kennel 1997-01-28 0:00 ` David Hanley 1997-01-28 0:00 ` Jacqueline U. Robertson 1997-01-29 0:00 ` David Hanley 1997-01-29 0:00 ` Fergus Henderson 1997-01-30 0:00 ` Robert C. Martin [not found] ` <5cr068$gpa@uni.library.ucla.edu> 1997-06-27 0:00 ` David Shang 1997-06-28 0:00 ` Ronald E Jeffries 1997-06-28 0:00 ` Mike Stark 1997-06-29 0:00 ` Mike Anderson 1997-06-29 0:00 ` Robert Dewar 1997-06-30 0:00 ` Kohler Markus 1997-01-29 0:00 ` Joachim Durchholz 1997-01-28 0:00 ` Robert I. Eachus 1997-01-28 0:00 ` Luther Hampton 1997-01-28 0:00 ` David Hanley 1997-01-29 0:00 ` David Hanley 1997-01-29 0:00 ` Eric Clayberg 1997-01-29 0:00 ` Jon S Anthony 1997-01-29 0:00 ` Eric Clayberg 1997-01-29 0:00 ` Rolf Breuning 1997-01-25 0:00 ` Robert Dewar 1997-01-27 0:00 ` Bob Jarvis 1997-01-27 0:00 ` Robert Dewar 1997-01-28 0:00 ` Alan Lovejoy 1997-01-25 0:00 ` Robert Dewar 1997-01-26 0:00 ` James O'Connor 1997-01-26 0:00 ` George Wolke 1997-01-26 0:00 ` Robert Dewar 1997-01-27 0:00 ` Jerry van Dijk 1997-01-28 0:00 ` Robert A Duff 1997-01-28 0:00 ` Jerry van Dijk 1997-01-29 0:00 ` Stanley R. Allen 1997-01-30 0:00 ` Robert A Duff 1997-01-28 0:00 ` Alan Lovejoy 1997-01-28 0:00 ` Jon S Anthony 1997-01-29 0:00 ` Robert A Duff 1997-01-19 0:00 ` Soren Skogstad Nielsen 1997-01-20 0:00 ` Joachim Durchholz 1997-01-26 0:00 ` Joachim Durchholz 1997-01-21 0:00 ` Matthew S. Whiting 1997-01-21 0:00 ` Matthew S. Whiting 1997-01-22 0:00 ` Fergus Henderson 1997-01-22 0:00 ` Alan Lovejoy 1997-01-22 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Don Harrison 1997-01-27 0:00 ` John Woods 1997-01-28 0:00 ` Alan Lovejoy 1997-01-24 0:00 ` Andy Bower 1997-01-25 0:00 ` Robert Dewar 1997-01-26 0:00 ` William Clodius 1997-01-25 0:00 ` Robert Dewar 1997-01-26 0:00 ` Eric Clayberg 1997-01-26 0:00 ` Robert Dewar 1997-01-26 0:00 ` Robert Dewar 1997-01-27 0:00 ` Robert C. Martin 1997-01-29 0:00 ` Robert Dewar 1997-01-29 0:00 ` Robert A Duff 1997-01-22 0:00 ` Don Harrison 1997-01-22 0:00 ` John Kuszewski 1997-01-23 0:00 ` Don Harrison 1997-01-23 0:00 ` Tansel Ersavas 1997-01-23 0:00 ` Travis Griggs 1997-01-24 0:00 ` Fergus Henderson 1997-01-24 0:00 ` Tansel Ersavas 1997-01-25 0:00 ` Damon Feldman 1997-01-26 0:00 ` Felix Beer 1997-01-28 0:00 ` Robert C. Martin 1997-01-28 0:00 ` Matt Kennel 1997-01-29 0:00 ` Del Archer 1997-01-24 0:00 ` Tansel Ersavas 1997-01-25 0:00 ` Robert A Duff 1997-01-26 0:00 ` Robert Dewar 1997-01-26 0:00 ` James O'Connor 1997-01-26 0:00 ` TanselErsavas 1997-01-26 0:00 ` Robert Dewar 1997-01-27 0:00 ` Eric Clayberg 1997-01-28 0:00 ` Antoine Trux 1997-01-29 0:00 ` Robert Dewar 1997-01-26 0:00 ` Bob Haugen 1997-01-26 0:00 ` Robert Dewar 1997-01-26 0:00 ` TanselErsavas 1997-01-27 0:00 ` Samuel S. Shuster 1997-01-26 0:00 ` Larry J. Elmore 1997-01-26 0:00 ` Eric Clayberg 1997-01-27 0:00 ` David Hanley 1997-01-25 0:00 ` Fergus Henderson 1997-01-24 0:00 ` Tansel Ersavas 1997-01-27 0:00 ` David Hanley 1997-01-28 0:00 ` Al Christians 1997-01-28 0:00 ` Alan Lovejoy 1997-01-29 0:00 ` Alan Lovejoy 1997-02-21 0:00 ` Chris Bitmead 1997-02-21 0:00 ` Eric W. Nikitin 1997-02-21 0:00 ` Brian Rogoff 1997-02-24 0:00 ` Jon S Anthony 1997-02-24 0:00 ` Brian Rogoff 1997-02-25 0:00 ` Eric W. Nikitin 1997-01-21 0:00 ` Norman H. Cohen 1997-01-22 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Norman H. Cohen 1997-01-24 0:00 ` Eric Clayberg 1997-01-27 0:00 ` Norman H. Cohen 1997-01-28 0:00 ` Tim Ottinger 1997-01-29 0:00 ` Ted Dennison 1997-01-24 0:00 ` traymond 1997-01-27 0:00 ` Norman H. Cohen 1997-01-28 0:00 ` traymond 1997-01-25 0:00 ` Tansel Ersavas 1997-01-27 0:00 ` Norman H. Cohen 1997-01-27 0:00 ` Brian Rogoff 1997-01-30 0:00 ` Tim Ottinger 1997-01-23 0:00 ` James O'Connor 1997-01-29 0:00 ` Stanley R. Allen 1997-01-30 0:00 ` Robert A Duff 1997-01-27 0:00 ` Jon S Anthony 1997-01-19 0:00 ` Keith Thompson 1997-01-22 0:00 ` Don Harrison 1997-01-23 0:00 ` Norman H. Cohen 1997-01-24 0:00 ` Don Harrison 1997-01-27 0:00 ` Norman H. Cohen 1997-01-23 0:00 ` Robert I. Eachus 1997-01-20 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-01-24 0:00 ` Jon S Anthony 1997-01-26 0:00 ` Eric Clayberg 1997-01-27 0:00 ` Jon S Anthony 1997-01-27 0:00 ` Jon S Anthony 1997-01-27 0:00 ` Jon S Anthony 1997-01-28 0:00 ` Jon S Anthony 1997-01-29 0:00 ` Stephen J Bevan 1997-01-21 0:00 ` Joachim Durchholz 1997-01-22 0:00 ` Richard A. O'Keefe 1997-01-27 0:00 ` Robert A Duff 1997-01-27 0:00 ` Bob Jarvis 1997-01-28 0:00 ` Travis Griggs 1997-01-28 0:00 ` Norman H. Cohen 1997-01-28 0:00 ` Russ McClelland 1997-01-27 0:00 ` Robert Dewar 1997-01-27 0:00 ` Robert A Duff 1997-01-29 0:00 ` Robert Dewar 1997-01-27 0:00 ` John Woods 1997-01-22 0:00 ` Eric Clayberg 1997-01-23 0:00 ` Joachim Durchholz 1997-01-24 0:00 ` Joachim Durchholz 1997-01-25 0:00 ` Eric Clayberg 1997-01-25 0:00 ` Tansel Ersavas 1997-01-25 0:00 ` James O'Connor 1997-01-26 0:00 ` Lawrence G. Mayka 1997-01-26 0:00 ` James O'Connor 1997-01-27 0:00 ` Norman H. Cohen 1997-02-07 0:00 ` Richard A. O'Keefe 1997-02-07 0:00 ` Alan Lovejoy 1997-02-12 0:00 ` Piercarlo Grandi 1997-02-13 0:00 ` Alan Lovejoy [not found] ` <yf3ybcsm5ce.fsf@sabi.demon.co.uk> 1997-02-14 0:00 ` Alan Lovejoy 1997-02-16 0:00 ` Piercarlo Grandi 1997-02-16 0:00 ` Alan Lovejoy 1997-02-17 0:00 ` Piercarlo Grandi 1997-02-13 0:00 ` Richard A. O'Keefe 1997-02-13 0:00 ` Alan Lovejoy 1997-02-18 0:00 ` Richard A. O'Keefe 1997-02-19 0:00 ` richard 1997-02-19 0:00 ` Mike Klein 1997-02-19 0:00 ` William Clodius 1997-02-19 0:00 ` Mike Klein 1997-02-15 0:00 ` Jon S Anthony 1997-02-16 0:00 ` Piercarlo Grandi 1997-02-16 0:00 ` Jon S Anthony 1997-02-18 0:00 ` Richard A. O'Keefe 1997-02-20 0:00 ` Matt Kennel 1997-02-20 0:00 ` Anders Pytte 1997-02-17 0:00 ` Alan Lovejoy 1997-02-17 0:00 ` Jon S Anthony 1997-02-19 0:00 ` Piercarlo Grandi 1997-02-17 0:00 ` Jon S Anthony 1997-02-19 0:00 ` Piercarlo Grandi 1997-02-19 0:00 ` Mike Klein 1997-02-17 0:00 ` Jon S Anthony 1997-02-18 0:00 ` Bernard Badger 1997-02-18 0:00 ` Jon S Anthony 1997-02-19 0:00 ` Piercarlo Grandi 1997-02-19 0:00 ` Piercarlo Grandi 1997-02-21 0:00 ` Jon S Anthony 1997-02-24 0:00 ` Piercarlo Grandi 1997-02-22 0:00 ` Jon S Anthony 1997-02-22 0:00 ` Jon S Anthony 1997-02-25 0:00 ` Richard A. O'Keefe 1997-02-22 0:00 ` Jon S Anthony 1997-02-22 0:00 ` Jon S Anthony 1997-02-22 0:00 ` Jon S Anthony 1997-02-25 0:00 ` Jon S Anthony 1997-02-27 0:00 ` Clayton Weaver 1997-02-25 0:00 ` Jon S Anthony 1997-02-25 0:00 ` Jon S Anthony 1997-02-26 0:00 ` Mike Klein 1997-02-25 0:00 ` Jon S Anthony 1997-01-08 0:00 Sazonov Cyril 1997-01-11 0:00 ` Bjarne Stroustrup 1997-01-01 0:00 What is wrong with OO ? Jon S Anthony 1997-01-02 0:00 ` Robert C. Martin 1997-01-03 0:00 ` Eirik Mangseth 1997-01-03 0:00 ` What is wrong with OO O X g Greg Comeau 1997-01-04 0:00 ` OO, C++, and something much better! John (Max) Skaller 1997-01-04 0:00 ` vlad 1997-01-05 0:00 ` Mike Anderson 1997-01-06 0:00 ` Chris Brand 1997-01-06 0:00 ` Stanley Allen 1997-01-09 0:00 ` Jon S Anthony 1997-01-08 0:00 ` Robert I. Eachus 1997-01-09 0:00 ` Bertrand Meyer 1997-01-27 0:00 ` Richard Riehle 1997-01-10 0:00 ` Robert I. Eachus 1997-01-10 0:00 ` Robb Nebbe 1997-01-04 0:00 ` Pieter Schoenmakers 1997-01-06 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-01-06 0:00 ` Michael F Brenner 1997-01-06 0:00 ` Tucker Taft 1997-01-07 0:00 ` Robert Dewar 1997-01-08 0:00 ` Robert Dewar 1997-01-07 0:00 ` Jay Martin 1997-01-08 0:00 ` Ken Garlington 1997-01-08 0:00 ` Robert Dewar 1997-01-08 0:00 ` Robert Dewar 1997-01-09 0:00 ` Ted Dennison 1997-01-07 0:00 ` Andrew Koenig 1997-01-10 0:00 ` Norman H. Cohen 1997-01-12 0:00 ` Richard Riehle 1997-01-07 0:00 ` Stanley Allen 1997-01-07 0:00 ` Robert Dewar 1997-01-07 0:00 ` Bertrand Meyer 1997-01-08 0:00 ` Ken Garlington 1997-01-08 0:00 ` Matthew Heaney 1997-01-10 0:00 ` Keith Thompson 1997-01-10 0:00 ` Robert Dewar 1997-01-10 0:00 ` Robert Dewar 1997-01-15 0:00 ` Richard Kenner 1997-01-15 0:00 ` Fergus Henderson 1997-01-20 0:00 ` Andrew Koenig 1997-01-25 0:00 ` Robert Dewar 1997-01-15 0:00 ` Ole-Hjalmar Kristensen FOU.TD/DELAB 1997-01-08 0:00 ` Jon S Anthony 1997-01-08 0:00 ` Mark A Biggar 1997-01-09 0:00 ` Don Harrison 1997-01-10 0:00 ` Roy Phillips 1997-01-27 0:00 ` Nick Leaton 1997-01-28 0:00 ` matthew mclellan 1997-01-09 0:00 ` Don Harrison 1997-01-09 0:00 ` Robert Dewar 1997-01-10 0:00 ` Bart Samwel 1997-01-10 0:00 ` Robert Dewar 1997-01-10 0:00 ` Ken Garlington 1997-01-10 0:00 ` Norman H. Cohen 1997-01-13 0:00 ` Don Harrison 1997-01-13 0:00 ` Ken Garlington 1997-01-13 0:00 ` Norman H. Cohen 1997-01-13 0:00 ` Robert Dewar 1997-01-15 0:00 ` Ken Garlington 1997-01-17 0:00 ` Keith Thompson 1997-01-16 0:00 ` Keith Thompson 1997-01-16 0:00 ` Ken Garlington 1997-01-14 0:00 ` Michael F Brenner 1997-01-14 0:00 ` Don Harrison 1997-01-13 0:00 ` Robert Dewar 1997-01-14 0:00 ` Don Harrison 1997-01-10 0:00 ` Jon S Anthony 1997-01-13 0:00 ` Don Harrison 1997-01-13 0:00 ` Robert I. Eachus 1997-01-15 0:00 ` Don Harrison 1997-01-13 0:00 ` Don Harrison 1997-01-14 0:00 ` Jeff Carter 1997-01-15 0:00 ` Don Harrison 1997-01-17 0:00 ` Jon S Anthony 1997-01-17 0:00 ` Norman H. Cohen 1997-01-18 0:00 ` Patrick Doyle 1997-01-20 0:00 ` Jon S Anthony 1997-01-08 0:00 ` David Emery 1997-01-09 0:00 ` Don Harrison 1997-01-10 0:00 ` Marky Mark 1997-01-14 0:00 ` Don Harrison 1997-01-08 0:00 ` Kohler Markus 1997-01-10 0:00 ` Jon S Anthony 1997-01-10 0:00 ` Matt Austern
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox