Re: Erlang type system and static vs. dynamic types

[Shriram Krishnamurthi <address@hidden>]

Howard Stearns wrote:

> I'm also not comfortable about my program's correctness without knowing
> which execution paths are not covered by my test suite. Again, I haven't
> been exposed to such profiling tools in static type languages.

1. Type systems don't establish correctness, only the absence of
certain kinds of errors.  So you're conflating two highly unrelated
things here.  

  NB: The folk statement than Jan-Willem and others refer to is a
  common observation many people have made about languages such as ML
  and Haskell.  Curiously, I've rarely heard such remarks made by
  Java/C++ programmers.  In part, I think this is because the process
  of type *inference* introduces a redundancy (and hence a check) that
  declaring types doesn't quite accomplish.  But there are also ther
  likely reasons for this, such as the complexity of some of the tasks
  (most traditional type systems tell you relatively little if
  anything about concurrency, and traditionally imperative work that
  can't be expressed elegantly in a functional way just doesn't get
  that much out of the types).

2. There's absolutely no reason a test suite coverage tool can't work
with a statically-typed language, and indeed the large slew of
coverage-related tools for Java, Ada, C/C++ [again, caveats apply],
etc bear witness to that.  In contrast, I don't know of great coverage
tools for Scheme and their ilk.  How good are the coverage tools for
Curl?  Are they in the Surge Lab?  Where?

  There are of course good reasons why commercial languages tend to
  have better tools, and there is an innate conservatism amongst
  programmers that makes commercial languages all look a bit ur.

3. The type checker gives you a level of coverage that compensates for
a poorer test suite.  If your checks are only conducted dynamically,
then a test suite without adequate coverage leaves many paths
untested.  In a certain sense, the type checker "tests all paths" (but
note #1).

Okay, enough.  I doubt anyone learned anything from this ...

Shriram