Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers From: kers@hplb.hpl.hp.com (Chris Dollin) Newsgroups: comp.lang.misc Subject: Re: Dynamic typing (part 3) Message-ID: Date: 14 Mar 91 08:37:51 GMT References: <609@optima.cs.arizona.edu> <25381:Mar1221:07:3891@kramden.acf.nyu.edu> Sender: news@hplb.hpl.hp.com (Usenet News Administrator) Organization: Hewlett-Packard Laboratories, Bristol, UK. Lines: 68 In-Reply-To: brnstnd@kramden.acf.nyu.edu's message of 12 Mar 91 21:07:38 GMT Nntp-Posting-Host: cdollin.hpl.hp.com [Abbreviations: STL - statically typed language; DTL - dyamically T'd L.] Dan Bernstein writes: Compiler writers generally find it convenient to catch type errors. Er ... only if (begging the question) they're dealing with STL's. [Even then, it's not *convenient*, it's *necessary* - otherwise the compiler would be wrong.] Programmers generally find it convenient to know the type of a variable and to have types always checked at compile time (rather than as an optimization that a few compilers might provide). Who are you to argue with taste? Alternative A: I'm not a programmer; I don't find it "convenient to know the type of a variable and to have types always checked at compile time". I am reluctant to endorse this alternative because it seems to leave the majority of my life's income (and the behaviour of a non-empty set of computers) unexplained. Alternative B: It is not true that "programmers generally ...". Programmers in STL's have no choice. (Programmers in DTL's sometimes have the opposite choice.) Since I know several individuals who would satisfy the usual crieria for being programmers who don't "find it convenient ...", alternative B seems plausible. [Other alternatives are imaginable.] Observation: this is all a bit silly anyway. [Didn't we have the B&D debate a few months ago?] The poles of argument seem to be: * one ought to be able to write anything that makes sense in its context * it's much nicer to catch errors at compile-time than run-time, if possible Since I suspect that no-one would seriously disagree with these two poles, we can concentrate on * how much expressiveness are you prepared to give up for the cost of being able to check correctness (be it type-correctness or whatever) at compile-time? Bear in mind that in (say) Pascal, checking that an expression E has type T may require a run-time check (suppose T is 1..10 and E is i+1, i:T), so a presumptive STL may require run-time checks. Given the choice between (say) C and Pop (or Lisp) I'd pick Pop (or, if I had to, Lisp). As David G says, type errors turn out to be just not that frequent, because you just don't write ill-typed code very often, and when you do, it usually surfaces quickly. [The argument that it might not, and remain a logic bomb lurking in your code ready to pounce on an unsuspecting user, is moot; "real" logic errors can so lurk, but because we know they cannot be cheaply detected at compile-time, no-one is upset that thay are not so detected; instead they deploy design, and code reviews, and testing; in short, Software Engineering.] [Of couse, for Pepper (the Pop-like language I'm building at the moment) I'd like to design a static type system which will spot likely type errors at compile-time, but not prevent you from overriding it; since Pepper programs already work quite happily with no static typechecks, I'm in no hurry to build a grotty little pedant rather than a pleasant cardboard cutout.] -- Regards, Kers. | "You're better off not dreaming of the things to come; Caravan: | Dreams are always ending far too soon."