[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dynamic vs. static typing

From: "Anton van Straaten" <anton@appsolutions.com>

Hi Anton,

First of all: I've seen this type of discussion before and I don't expect
that at the end of it we will happily agree on some position acceptable to
all ;-)). Still, I like to learn about what others are thinking in this
area, this will help improve my own clarity about the topic.

> 1. Without early typechecking, the proportion of type errors which
> during testing and at runtime rises significantly.

You are comparing languages with and without early typechecking. You are
comparing the stage of development at which, in each language, the type
errors are going to manifest themselves.

Implicitly, you are assuming that the type errors that will occur are the
same (or so alike that the difference is of no importance). Do you agree
that you are implicitly assuming that? Is it intended?

[Just ignore the following questions if you don't agree up to this point.]

If it is intended, do you really believe that on these different languages,
essentially the same type errors will be coded into the programs?

Related question: Do you believe that the nature of type errors in both
language categories is essentially the same? If you do believe that, what
are your reasons? I'm not asking for your evidence, I don't care about that

[Note: My own experience with the dynamically typed language Smalltalk,
leads me to think that type errors, inasfar they manifest themselves as
errors, are of a rather different nature than the kind of errors type
checkers find.]

> 2. Often, the nature of those type errors isn't identified as clearly
> testing or at runtime as it would be by a type-checker, so they take
> to track down.

See above; again this assumes the programmers make essentially the same

> 3. Looking at these errors in terms of what percentage they are of all
> possible errors is misleading at best.


> Repeating myself, I'm not arguing that ST is the best choice in all cases.
> But it has benefits which many people, including myself, have experienced.
> We also know it's possible to provide more of those benefits in DT
> languages.  What I've mostly been arguing against is the rejection of
> typechecking without exploring or understanding what that can mean, beyond
> what e.g. C++/Java or even ML/Haskell provide, and especially when that
> rejection seems to be based on misconceptions about what static
> is capable of.

One of the things I don't like about Smalltalk is that there is quite some
information that I know when I'm coding, but don't (can't) tell the program
about. Then later, when someone reads the code, it is more difficult to
understand my intention than if I had been able to put that information in
the program, and when I made a mistake, it is more difficult for the
execution engine to guess what my mistake might have been.

If the language offered me the opportunity to (formally) express some of
this information that I currently can't put in, I would of course like the
system to check whether I was inconsistent in what I expressed, and tell me
as soon as it could detect that inconsistency ("I don't care if you call it
static, dynamic or whatever: I just want it checked ASAP").

[Note: Sometimes the information I cannot express, but would like to (and
would like to have checked for consistency), is about the types of variables
or functions. This is especially the case when the type is a basic one, such
as integer, number, or boolean. More often, the information is about the
type of operations (which imply their semantics). I've never seen a language
that allows me to specify that. Anyone?]