mario@cs.man.ac.uk (Mario Wolczko) (04/05/91)
In article <887@puck.mrcu>, paj@mrcu (Paul Johnson) writes: > Sorry, I am still not convinced. I am currently programming in > Eiffel, and changing my mind about a type is not something I often do. > Also the type declarations carry information which affects the > execution of the rest of the program. Hence other parts of the > program will need changing as well. It seems to me that this will > only result from a fairly major rewrite of some part of the code. This could be a self-fulfilling statement, ie you don't change your mind about types because you know it's going to be hard work to fix the type declarations up, whereas in a declarationless language sorting out the declarations doesn't arise. > Does anyone have any facts relating to the assertion that run-time > failures due to type errors are rare in Smalltalk development? I'm not sure what this means in Smalltalk, much less how you measure it. You can't just count "doesNotUnderstands", because some of these are not type errors (such as asking for the tail of an empty list). As for statistics, do you want "how many Smalltalk programs have ever given a run-time type error in their whole lifetime, after they were declared to be `finished'?" Most Smalltalk programs I have seen are prototypes or research programs, and are rarely declared "finished", so I guess this would be close to 100%. However, if you ask this question of any language, replacing "type error" with "error", then my guess is that the answer is the same. Very few "finished" programs are bug-free, type-checked or not, so it's clear that type checking is only addressing a small part of the problem. Or perhaps you mean "how many runs of Smalltalk programs have resulted in run-time type errors?". This must be close to 0%. Neither of these figures means very much. Speaking from personal experience, I find that after I have written some Smalltalk code (and I have written >10000 lines in the last 18 months) there are a few residual "type errors" which get caught in the first few test runs. The time taken to find and fix these is much smaller than the time it would take me to declare all the variables in such a way as to satisfy a type-checker (even if it were possible with current type systems, which it isn't in many programs). The real problems that take hours to find and fix are undetectable using type-checking, such as writing "x+y" instead of "x-y". Mario Wolczko ______ Dept. of Computer Science Internet: mario@cs.man.ac.uk /~ ~\ The University uucp: mcsun!ukc!man.cs!mario ( __ ) Manchester M13 9PL JANET: mario@uk.ac.man.cs `-': :`-' U.K. Tel: +44-61-275 6146 (FAX: 6280) ____; ;_____________the mushroom project___________________________________
olson@lear.juliet.ll.mit.edu ( Steve Olson) (04/07/91)
In article <887@puck.mrcu> paj@mrcu (Paul Johnson) writes:
Does anyone have any facts relating to the assertion that run-time
failures due to type errors are rare in Smalltalk development?
For years I have been using an object-oriented Lisp (Flavors) to do
things like real-time interpretation of weather radar imagery. For
the purpose of this discussion Lisp plus Flavors is probably equivalent
to Smalltalk. These systems have been deployed at several radar sites
scattered across the country for several years. My only possible reply
is "huh, whats a type error?" Oh yes! I remember now - a type error is
what happens when you are programming in C and you screw up a cast.
Seriously, I get the "message not understood" error from time to time, but
99 times out of a hundred, the problem is caught on the first or second
test run. The other 1 out of hundred? Well, I still get to diagnose and
fix the problem almost instantly because of the usually informative error
messages. Much better than the mystery core dump. I get things which look
like type errors when try to perform math on 'nil' for example, but thats
almost always because I have forgotten to properly calculate the value
of some slot. Getting a type error in those cases is in fact a tremendous
help over what would happen in a typical statically typed language.
In my opinion, the biggest practical problem with dynamically typed languages
is that it is a pain in the butt to lug around the run time envirnoment.
To run a 1 page Common Lisp program on a UNIX system means I have to fire up a
multi-megabyte run time system which consumes vast amounts of core and virtual
memory. Yuk. There are lighter-weight alternatives to Common Lisp, of course,
but you're still going to have some extra baggage to lug around.
People who get endlessly alarmed about the alleged lack of type saftey in
a dynamically-typed languge are not well-informed about how Lisp or Smalltalk
software development actually works.
- Steve Olson
MIT Lincoln Laboratory
olson@juliet.ll.mit.edudiamond@jit345.swstokyo.dec.com (Norman Diamond) (04/08/91)
In article <OLSON.91Apr6172626@lear.juliet.ll.mit.edu> olson@lear.juliet.ll.mit.edu ( Steve Olson) writes: >In my opinion, the biggest practical problem with dynamically typed languages >is that it is a pain in the butt to lug around the run time envirnoment. >To run a 1 page Common Lisp program on a UNIX system means I have to fire up a >multi-megabyte run time system which consumes vast amounts of core and virtual >memory. Yuk. Exactly. The multi-megabyte run time system provides the "message not understood" message and nice debugger instead of mystery core dump. The multi-megabyte run time system would be useful while developing programs in statically typed languages too, and then you'd never see the mystery core dump. Debates between static and dynamic typing should center on the advantages of programming in each kind of language, not on what can be done with multi-megabyte support packages. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
pkr@media01.UUCP (Peter Kriens) (04/08/91)
> Does anyone have any facts relating to the assertion that run-time > failures due to type errors are rare in Smalltalk development? I do not have any hard facts about the number in a larger project, but from my experience it is extremely rare that an end user gets a "does not understand" (The smalltalk equivalent of a typing error). Actually we have experienced much more stable systems using Smalltalk and a dynamic binded version of C (CO2) then original C. I think this results from the fact that when you cannot explicitly type, you cannot make an error in it (e.g. less typing means less typing errors). And our experience shows that Smalltalk and CO2 code is much smaller than comparable C code. But mostly, if you get an error in Smalltalk it informs you about the contex while my experience in C shows me that it justs crashes or stops in a place far far away from the original error. I think this makes testing and quality assurance much easier, resulting in more reliable systems. In C or other static typed language, any error not caught by the compiler can be hidden for a long time and crash the system while it runs for long periods (At least I have had many of thos problems which took a long time to find). In Smalltalk errors are usually caught on the spot. Another reason might be the that IMHO the reuse of dynamic binded code is much better. This means that most applications we have written rely very heavily on a relatively small number of basic classes, which can be small because they are very generic. Peter Kriens pkr@media01.uucp
new@ee.udel.edu (Darren New) (04/09/91)
In article <OLSON.91Apr6172626@lear.juliet.ll.mit.edu> olson@lear.juliet.ll.mit.edu ( Steve Olson) writes: >People who get endlessly alarmed about the alleged lack of type saftey in >a dynamically-typed languge are not well-informed about how Lisp or Smalltalk >software development actually works. Here, Here! I'll second that. And people who say "Well, you could do it just as well in a statically typed language if you had as big a runtime system" I'll answer by saying "why do *most* dynamic languages have huge libraries and great debuggers and *most* static languages have lousy libraries and lousy debuggers?" I suspect that because the static code is so much less reusable that the incentive is to never change the late-60's model of programming lest we break all that software. People rave about GDB, but it looks worse to me than Delta on a 1968 release of CP-V. Then look at the Smalltalk debugger, which is not very big because it resuses most of the code from the editor, browser, and compiler, and it blows any other debugger out of the water. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, FDTs ----- +=+=+ My time is very valuable, but unfortunately only to me +=+=+ + When you drive screws with a hammer, screwdrivers are unrecognisable +
guido@cwi.nl (Guido van Rossum) (04/09/91)
Norman Diamond writes: >The multi-megabyte run time system would be useful while developing >programs in statically typed languages too, and then you'd never see >the mystery core dump. Debates between static and dynamic typing should >center on the advantages of programming in each kind of language, not >on what can be done with multi-megabyte support packages. Maybe I can provide something of a data point here: a comparison of two languages that differ more in their typing system than in other aspects. If you know ABC and Python you can skip to DISCUSSION at the end. Python, which has dynamic typing, was strongly inspired by ABC, which has static typing. In other aspects, the two are much more similar then your average pair of statically/dynamically typed languages: both are interactive and interpreted, and have large runtime packages that replace core dumps by understandable error messages (really exceptions for Python). Both runtime packages implement very-high level data types with roughly the same functionality (only one has bignums -- oddly enough it's the statically typed one). Neither requires or allows declarations, both have polymorphic functions. And now the differences: the type system of ABC determines the type of parameters and variables by inspecting how they are used -- e.g., if it is added to something, it must be a number (there's only one numeric type in ABC), if it is inserted in a list, it must have the same type as the elements of that list, etc. You get polymorphism if the usage of a parameter doesn't give away all the information about a type -- e.g., if a procedure swaps its two arguments but does nothing else, it will accept arguments of any type, as long as the two arguments have the same type. There are interesting problems when you try to write a type-checker for such a language, but they are solvable (for ABC, at least). Python, on the other hand, does all its type checking at run time. E.g., if you try to add two objects, their types are compared, and if they are both strings, or both integers, it succeeds, else you get a type checking exception (which may be caught). Programming in either language is extremely smooth compared to C or other relatively low-level languages. Because of the interpreters, you don't get blinding speed if you can't get the built-in data types to do most of the work for you, so neither language (implementation) is well-suited for programming byte-copying loops or FFT transforms, for example; but if you need efficient, large dynamic data structures, they are available in the runtime system. DISCUSSION There are two questions which can be asked about ABC and Python (in the context of the previous debate about static vs. dynamic typing). 1) Which is more likely to lead to bugfree programs? 2) Which has more flexibility (or: which do you like better)? Re (1), I don't see a significant difference. True, ABC detects certain errors before you start running the program that Python will only catch in a test run, but there remains a significant class of errors that can only be detected at run time, e.g., taking the MIN of an empty list, accessing an associative array with a non-existent key, etc. Both Python and ABC encourage program development in small units that are created and tested bottom-up, and the first test run usually finds any type errors that remain in Python programs. Sometimes the type checker in ABC detects a type error but reports it in such a weird way that you have to stare really long at the piece of code in question before you see what the real problem is; e.g., it may complain that b is not a number in a+b, while the real problem is in the expression assigned to b many lines earlier. In Python I can ask the debugger to print b's value when an exception has occurred, which usually shows immediately what the problem is (the value gives a more precise clue about where it came from than just the type, which ABC reports). Re (2), it can't be a surprise that I like Python better. I actually use heterogeneous lists a lot, e.g., just this weekend I wrote a tree module which stores arbitrary attributes associated with the leaves, keyed on strings chosen by the various modules that use the trees, and an event queue which can store arbitrary events from unrelated modules. These modules would pass ABC's type system alright (except for other features not provided in ABC that don't relate directly to dynamic/static typing), but their callers wouldn't: as soon as two unrelated modules would store differently-typed events in a queue, neither module would type-check. This is caused by the absence of unions in ABC, but notice that they would have to be open-ended unions (David Gudeman's "any" type), since the queue module cannot know what types will be stored in the queue. Any one program will only store a finite number of different event types (hmm, can you prove this?) but I don't see the point of forcing the programmer to find out which union type to use in a particular program (and keeping it up-to-date when the program is extended). CONCLUSION Were all else kept equal, I'd still prefer dynamic typing. Its simplicity in implementation wins over the complexity of a type checker that provides the kind of flexibility I need. ABC is close, but still too limiting for many realistic applications, and its type checker was one of the hardest modules to add to the system. Note that dynamically typed languages can often be optimized using techniques similar to ABC's type checking algorithm -- only they can fall back on the dynamic type system if they can't compute the type of a variable, instead of blaming the user. I would even like it if such an optimizer told me when it could prove that an unchecked exception would certainly occur in a part of the program. But there is no reason why such an optimizer should stop at type checking -- static checks can check for definedness of variables (ABC has this!), apply range checks, in short try to predict every kind of exception that may occur in a program -- but there is no reason to restrict the language to accept only programs for which it can be proven (with known techniques) that no exception will ever occur. Such languages are unnecessarily restricting programmers. --Guido van Rossum, CWI, Amsterdam <guido@cwi.nl> "I can do everything you want in Macro Assembler. No need for Compilers."
olson@lear.juliet.ll.mit.edu ( Steve Olson) (04/09/91)
In article <1991Apr8.085602.5082@tkou02.enet.dec.com> diamond@jit345.swstokyo.dec.com (Norman Diamond) writes:
The multi-megabyte run time system would be useful while developing
programs in statically typed languages too, and then you'd never see
the mystery core dump.
I certainly agree with the first part of your statement - witness Saber-C -
but not the second. The real gut-buster problems I see in my line of work
are when a guy calls up from a remote site and says "It ran great for 3 days,
and then it crashed!!". My experience has been that the dynamically-typed
system fails and you fix it the first time. When the statically typed
system fails ... maybe you get lucky ... maybe you don't. Note: I'm
assuming the statically typed system is "deployed" without the run-time
environment - see below.
Debates between static and dynamic typing should
center on the advantages of programming in each kind of language, not
on what can be done with multi-megabyte support packages.
Agreed in principle, but harder to do than you think. The poster who
talked about "A" and "B" languages accurately described how languages
- in practice - tend to line up. Dynamic typing pretty much implies a
elaborate run-time environment, so to do an "apples-to-apples" comparison
we need a statically-typed language with a elaborate run-time enviroment.
So go off and design one, and report back to this list :-). Or maybe some
exist - enlighten me.
--
Norman Diamond diamond@tkov50.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
- Steve Olson
MIT Lincoln Laboratory
olson@juliet.ll.mit.edudiamond@jit345.swstokyo.dec.com (Norman Diamond) (04/09/91)
In article <3288@charon.cwi.nl> guido@cwi.nl (Guido van Rossum) writes: >Python, which has dynamic typing, was strongly inspired by ABC, which has >static typing. In other aspects, the two are much more similar then >your average pair of statically/dynamically typed languages: both are >interactive and interpreted, and have large runtime packages that >replace core dumps by understandable error messages (really exceptions >for Python). [...] >Were all else kept equal, I'd still prefer dynamic typing. Dynamic typing indeed makes some things easier, as Mr. Rossum explained. It is nice to see real evidence for a change. Anyway, there is a middle ground which has also been suggested by a few others, and which some languages (e.g. Eiffel, and certain constructs in C++) come close to providing anyway. Perhaps some new terms would help explain this. Just as type and class have come to mean different things, perhaps dynamic classing vs. static classing should be recognized. With static classing, a type inference system could determine, or a programmer could specify, that a variable inherits certain known messages, though the precise type need not be known statically. I expect that static classing will have a lot more use than static typing. I would not try to ram either static typing or static classing down anyone's throat, but both can be used by disciplined developers and maintainers to catch some errors early. Although it cannot catch all errors, it certainly helps. Part of the folklore of software engineering is the magnitude of increase in costs as error detection is delayed. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
klimas@iccgcc.decnet.ab.com (04/13/91)
In article <OLSON.91Apr6172626@lear.juliet.ll.mit.edu>, olson@lear.juliet.ll.mit.edu ( Steve Olson) writes: > In article <887@puck.mrcu> paj@mrcu (Paul Johnson) writes: > Does anyone have any facts relating to the assertion that run-time > failures due to type errors are rare in Smalltalk development? Some info that I picked up from a company doing a lot of big project work with C++ (i.e. strong type checking language) was that postmortems on their project revealed only 10% of their errors were captured by strong type checking.
rsw@cs.brown.EDU (Bob Weiner) (04/13/91)
In article <4243.2805b94a@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes: > Some info that I picked up from a company doing a lot of big > project work with C++ (i.e. strong type checking language) was > that postmortems on their project revealed only 10% of their > errors were captured by strong type checking. I doubt that any professional software designers are willing to log every instance that their compiler spits out an error. Their productivity might drop considerably. Hence it is a fair bet that this company did not have an accurate record of errors detected by a compiler for a strongly typed language. They may have only recorded problems found as the software passed from design to quality testing. -- Bob Weiner rsw@cs.brown.edu
cok@islsun.Kodak.COM (David Cok) (04/14/91)
In article <4243.2805b94a@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes: > Some info that I picked up from a company doing a lot of big > project work with C++ (i.e. strong type checking language) was > that postmortems on their project revealed only 10% of their > errors were captured by strong type checking. Did they really count ALL the errors -- including every time a compile failed because of type errors? It seems to me most type errors would be caught before a peice of code even got into some error tracking process. David R. Cok Eastman Kodak Company cok@Kodak.COM
ddean@rain.andrew.cmu.edu (Drew Dean) (04/14/91)
In article <4243.2805b94a@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes: > Some info that I picked up from a company doing a lot of big > project work with C++ (i.e. strong type checking language) was > that postmortems on their project revealed only 10% of their > errors were captured by strong type checking. I think this depends on what you call "strongly typed." Personally, I wouldn't call any C derived language strongly typed, as long as (void *) exists. If you want to see REAL strong typing, try, say Standard ML (Ok, ok, it's a functional language so I shouldn't be mentioning it in this group. :-) I don't want to start the functional vs OOP flamefest.) I'm just using this as an example of a really strong type system: wherever it can, it automatically infers the type of the expression, and won't compile anything that doesn't typecheck. The only experience with dynamically-typed systems I have are Lisp-based systems, just today I crashed one with a type error. It could be that imperative/functional programs are more prone to type-errors that OO programs; (note: this is a conjecture) does anyone have any real data on the subject ? -- Drew Dean Drew_Dean@rain.andrew.cmu.edu [CMU provides my net connection; they don't necessarily agree with me.]
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/14/91)
In article <RSW.91Apr13042119@delay.cs.brown.EDU> rsw@cs.brown.EDU (Bob Weiner) writes: > In article <4243.2805b94a@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes: > > Some info that I picked up from a company doing a lot of big > > project work with C++ (i.e. strong type checking language) was > > that postmortems on their project revealed only 10% of their > > errors were captured by strong type checking. > I doubt that any professional software designers are willing to log every > instance that their compiler spits out an error. Their productivity might > drop considerably. It takes no effort to log every compilation. I do, and I know others who do. It does take effort to log every little change you make to your program, and every run-time error; I don't know of any C++PSE, though the company might have developed one internally. > Hence it is a fair bet that this company did not have > an accurate record of errors detected by a compiler for a strongly typed > language. It's a fair bet that the 10% was fabricated by some programmer who at the last minute was put on the spot and told to produce some statistics. But I'd believe that it was in the ballpark: a language which forces you to know what data types you're using will reduce type errors. ---Dan
diamond@jit345.swstokyo.dec.com (Norman Diamond) (04/15/91)
In article <4243.2805b94a@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes: > Some info that I picked up from a company doing a lot of big > project work with C++ (i.e. strong type checking language) was > that postmortems on their project revealed only 10% of their > errors were captured by strong type checking. This is a perfect example of engineering skills that have been learned through hard efforts and then rejected by practitioners who refuse to be engineers. In any other field of engineering, a 10% increase in safety would always be applied. To reject it would be grounds for lawsuits, at least. (Well, it did take a while before the auto industry accepted that lesson. And one of the fallouts of the Reagan era is lower safety standards in the auto industry. Hmm.....) -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
gudeman@cs.arizona.edu (David Gudeman) (04/16/91)
In article <1991Apr15.065146.16680@tkou02.enet.dec.com> Norman Diamond writes: ]In article <4243.2805b94a@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes: ]> Some info that I picked up from a company doing a lot of big ]> project work with C++ (i.e. strong type checking language) was ]> that postmortems on their project revealed only 10% of their ]> errors were captured by strong type checking. ]... ]In any other field of engineering, a 10% increase in safety would always ]be applied. To reject it would be grounds for lawsuits, at least. How do you get a 10% increase in safety from the above? If they hadn't caught those errors by static typing they would have caught them by testing -- the same way the found the other 90% of the errors. This logic error combined with the strident tone of the article suggests that your convictions are affecting your thinking. -- David Gudeman gudeman@cs.arizona.edu noao!arizona!gudeman
mathew@mantis.co.uk (mathew) (04/16/91)
diamond@jit345.swstokyo.dec.com (Norman Diamond) writes: > In article <4243.2805b94a@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com w > > Some info that I picked up from a company doing a lot of big > > project work with C++ (i.e. strong type checking language) was > > that postmortems on their project revealed only 10% of their > > errors were captured by strong type checking. [...] > In any other field of engineering, a 10% increase in safety would always > be applied. To reject it would be grounds for lawsuits, at least. Possibly true, although I can think of examples in other fields of engineering where 10% increases in safety have NOT been applied. Look at the design of roll-on, roll-off ferries, for example. Or US domestic electrical wiring (no earth, no ELCB!) Also, remember that using a strongly-typed statically typed language is not necessarily the only way to achieve that 10% increase. mathew -- If you're a John Foxx fan, please mail me!
dmg@ssc-vax.uucp (David M Geary) (04/18/91)
] David Gudeman
]] Douglas Surber
]If they hadn't caught those errors by static typing they would have caught
]them by testing -- the same way the found the other 90% of the errors.
]This logic error combined with the strident tone of the article
]suggests that your convictions are affecting your thinking.
]]The real question is how long would it take them to catch those errors
]]by testing? The type checker catches them all first time every time.
]]Admittedly not every error, but reducing the number of errors by 10%
]]before you even begin testing sounds like a win to me.
Sounds like a win to me, also. However, there are two caveats:
1) Since dynamic typing allows more expressiveness and a greater degree
of reusability than a statically typed language, code in a statically
typed language may be 10% (or more) larger than the "same" code in a
dynamically typed language. So, while some errors have been ironed out
before testing, testing may have more to test.
2) Errors caused by circumvention of the type system in a statically typed
language may *not* be caught by the compiler, and are difficult to
track down. In fact, I demonstrated such an error in an earlier posting.
]]Further, the type checker finds type errors even in code that, for one
]]reason or another, is never excersized during testing. Again not every
]]error, but a 10% reduction is still something.
Again, realize that the type checker will not find errors that fall into
category #2 above.bertrand@eiffel.UUCP (Bertrand Meyer) (04/19/91)
From article <3865@ssc-bee.ssc-vax.UUCP> by dmg@ssc-vax.uucp (David M Geary): > 1) Since dynamic typing allows more expressiveness and a greater degree > of reusability than a statically typed language, code in a statically > typed language may be 10% (or more) larger than the "same" code in a > dynamically typed language. So, while some errors have been ironed out > before testing, testing may have more to test. The premise of this sentence (a statically typed language is less expressive) is, I believe, incorrect. With the appropriate typing facilities (in particular genericity, constrained and unconstrained) you lose absolutely nothing in expressiveness. This has been discussed at length in this newsgroup before, and in spite of many efforts and even ``challenges'' I don't think anyone has shown a convincing counter-example - something that could be expressed conveniently in a dynamically typed language but not in a statically typed language. (Again, I am assuming a decent type system; if you don't have genericity, or if arbitrary C-like casts are allowed, this is all meaningless anyway.) Mr. Geary is quite correct, however, that a statically typed language will be slightly more verbose because of the need for declaring entities (attributes, local variables, function results). But this should have at most a negligible effect on testing. Typically, one tests the executable parts of a software system (the instructions), not the declarations. In fact, the presence of declarations may be a significant help in eliminating useless tests and making each individual test more productive. (The same applies to assertions, but that's another story.) It is true, of course, that as soon as you introduce more text (such as declarations) you introduce more possibilities of error. This is because static typing follows the time-honored method of introducing redundancy to make it easier to catch errors. The reason this is a good method is that more redundancy means more likelihood that a conceptual error will become an *inconsistency*, and inconsistencies are always much easier to detect than more general types of errors. The catch is that you may then detect inconsistencies which are *not* original errors: for example, they may result from errors in the elements that have been added for redundancy. (This occurs for example when a variable is used properly, but its declaration is ``wrong'' with respect to the programmer's intent.) This means that when you add redundancy for security there is a risk of false alarm (detecting an apparent error when the original was in fact correct). If, as is the case in the practice of reasonable statically typed languages, such false alarms are rare, the price is acceptable, being justified by all the *real* alarms that redundancy will enable you to catch. As an analogy (offered for what it's worth), in some countries elementary school students are (were?) taught to check an arithmetic operation by ``crossing out nines'' (``preuve par 9''), which is a quick modulo-9 check. Once in a while you will find an inconsistency which results from an error in the crossing-out, not in the original operation. However this occasional nuisance - which merely forces you to redo the operation and the check - is nothing to complain about when compared to all the *real* errors that this type of checking catches. -- -- Bertrand Meyer Interactive Software Engineering Inc., Santa Barbara bertrand@eiffel.uucp
new@ee.udel.edu (Darren New) (04/23/91)
In article <530@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: >I don't think anyone has shown a convincing counter-example - >something that could be expressed conveniently in a dynamically >typed language but not in a statically typed language. I think a "resource manager" is a good example. By this, I mean a module which accepts <name, object> pairs either to be stored or retrieved. Presumedly, the one storing and the one retrieving need to know what the type is, but the resource manager need not. Sort of like an environment-variable list, except that the right-hand side is not restricted to single strings but rather can be any type in the language. - Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware --- ----- Network Protocols, Graphics, Programming Languages, FDTs ----- +=+=+ My time is very valuable, but unfortunately only to me +=+=+ +=+ Nails work better than screws, when both are driven with screwdrivers +=+
dlw@odi.com (Dan Weinreb) (04/28/91)
In article <530@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
The catch is that you may then detect inconsistencies which
are *not* original errors: for example, they may result from errors
in the elements that have been added for redundancy. (This occurs
for example when a variable is used properly, but its declaration
is ``wrong'' with respect to the programmer's intent.)
This means that when you add redundancy for security there is a risk
of false alarm (detecting an apparent error when the original was in
fact correct). If, as is the case in the practice of reasonable
statically typed languages, such false alarms are rare, the price
is acceptable, being justified by all the *real* alarms that
redundancy will enable you to catch.
Yes, I agree completely, and here's another analogy that people might
like. Consider parity checking on computer main memory. Adding
parity bits allows a consistency check, so that you can easily
recognize when one of the stored bits in memory is incorrect. The
catch is that perhaps the parity bit itself might have the wrong
value! In this case, you actually would have been better off without
the parity bit. However, I think most people can see why, despite
this catch, there's quite a lot to be said for the parity bit, and
most people would rather have parity checking than no checking, and
are willing to pay for it.
This isn't a perfect analogy for all aspects of the issue under
discussion, of course. I just think it's a good way to explain the
business about the "catch", and the risk of false alarm, and why that
might not be as bad some people might at first think. Whether the
relative costs for various kinds of software construct are similar
to the relative costs for parity checking is not necessarily obvious,
but the qualitative nature of the tradeoff is similar in this way.cpp@calmasd.Prime.COM (Chuck Peterson) (05/03/91)
I am glad Mr. Meyer and others admit there is a cost to redundancy. Consider that many of the languages users prefer, from novice to theoretician, from Basic to Lisp and Smalltalk, are dynamically typed. Both because it simplifies ad hoc experimenting, reduces code size and manifest complexity, and makes polymorphism natural. Has a cost of additional error and maintenance of dynamically vs. statically typed programming really been proven? No doubt perfectly unmaintainable code has been written either way, and perhaps some of the most challenging of smaller products, such as GNU emacs, have been written with dynamically typed languages. (Perhaps many formidable large products as well.) Even if there is an additional cost, is it not usually outweighed by productivity and inventiveness. Perhaps statically typed languages should be used like assembly language, where the added security (as with performance for assembly) justifies recoding. (Perhaps both security and performance in some measure.)
jacob@gore.com (Jacob Gore) (05/05/91)
/ comp.object / cpp@calmasd.Prime.COM (Chuck Peterson) / May 2, 1991 / > Has a cost of additional error and maintenance of dynamically vs. > statically typed programming really been proven? Proven shmoven. I've spent many hours seeking a bug that a compiler for a strongly typed language would have caught. Proof enough for me. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
rockwell@socrates.umd.edu (Raul Rockwell) (05/06/91)
Chuck Peterson: Has a cost of additional error and maintenance of dynamically vs. statically typed programming really been proven? Jacob Gore: I've spent many hours seeking a bug that a compiler for a strongly typed language would have caught. Proof enough for me. static typing tends to mean compile time type parameterization dynamic typing tends to mean run time time type parameterization strong typing tends to mean sanity checks at the time of function closure Raul Rockwell
chip@tct.com (Chip Salzenberg) (05/06/91)
According to cpp@calmasd.Prime.COM (Chuck Peterson): >Consider that many of the languages users prefer, from novice to >theoretician, from Basic to Lisp and Smalltalk, are dynamically typed. I don't know about Mr. Peterson's experience, but the Basics I've used are all statically typed. For example, A is always a numeric value of some predetermined type, and A$ is always a string. Microsoft Basic adds suffixes: A! single precision, A# double precision, A% integer. (The concept of citing Basic in a comp.object article boggles the mind, doesn't it?) In any case, I doubt the relevance of novice preference. >[Dynamic typing] simplifies ad hoc experimenting, reduces code size >and manifest complexity, and makes polymorphism natural. True enough. But the reduction of "manifest complexity" is hardly a win if all that complexity is really still there, ready to bite the unwary user during execution. -- Brand X Industries Sentient and Semi-Sentient Being Resources Department: Because Sometimes, "Human" Just Isn't Good Enough [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>
kers@hplb.hpl.hp.com (Chris Dollin) (05/09/91)
Jacob Gore says: / comp.object / cpp@calmasd.Prime.COM (Chuck Peterson) / May 2, 1991 / > Has a cost of additional error and maintenance of dynamically vs. > statically typed programming really been proven? Proven shmoven. I've spent many hours seeking a bug that a compiler for a strongly typed language would have caught. Proof enough for me. But were you using a dynamically typed language, and, if so, which? -- Regards, Kers. | "You're better off not dreaming of the things to come; Caravan: | Dreams are always ending far too soon."
jacob@gore.com (Jacob Gore) (05/15/91)
Jacob Gore says: > I've spent many hours seeking a bug that a compiler for a strongly typed > language would have caught. Proof enough for me. / comp.object / kers@hplb.hpl.hp.com (Chris Dollin) / May 9, 1991 / > But were you using a dynamically typed language, and, if so, which? Hmm... good point. I was using C (pre-prototype). Since it wasn't a dormant bug, a dynamically typed language would have caught it. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob