From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: Alan Lovejoy Subject: Re: OO, C++, and something much better! Date: 1997/01/30 Message-ID: <32F07418.29FC@concentric.net> X-Deja-AN: 213195234 references: <32DF458F.4D5C@concentric.net> <32DF94DC.6FF8@watson.ibm.com> <32DFD972.37E4@concentric.net> <5bphq4$5js@mulga.cs.mu.OZ.AU> <32E05FAF.47BA@concentric.net> <5buodl$bci@boursy.news.erols.com> <32E2FEC7.2F7B@concentric.net> <5bvncj$gqg$1@A-abe.resnet.ucsb.edu> <32E47B4B.56D9@concentric.net> <5c4fr0$27j@mulga.cs.mu.OZ.AU> <32E67751.4AFC@parcplace.com> <5caqo5$k5l@mulga.cs.mu.OZ.AU> <32E9BAAC. content-type: text/plain; charset=us-ascii organization: Modulation mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object x-mailer: Mozilla 2.01Gold (Win95; U) Date: 1997-01-30T00:00:00+00:00 List-Id: Fergus Henderson wrote: > > Alan Lovejoy 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 |==============================================|