🚀 go-pugleaf

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