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

Re: dynamic vs. static typing

On 9 Dec 2003, at 5:48, Anton van Straaten wrote:

> On 30 Nov 2003, at 4:36 PM, Pascal Costanza wrote:
>>>> Anton van Straaten wrote:
>>>>> Pierce has a nice description of the subjective effects of
>>>>> static type checks, in TAPL:
>>>>>    "In practice, static typechecking exposes a surprisingly
>>>>> broad range of errors.  Programmers working in richly typed
>>>>> languages often remark that their programs tend to "just work"
>>>>> once they pass the typechecker, much more often than they feel
>>>>> they have a right to expect.  One possible explanation
>>>>> for this is that not only trivial mental slips [...] but also
>>>>> deeper conceptual errors [...] will often manifest as
>>>>> inconsistencies at the level of types."
> ...
>>> Calling it a subjective assessment is a little misleading: it's a
>>> real effect, but it's difficult to describe in a brief summary,
>>> and I doubt many people appreciate how complex it is.  So the
>>> main way in which this effect is communicated is in the subjective
>>> sense, "wow, my programs just work".
>> I doubt it is possible to describe this in a long and detailed
>> analysis. My impression is that you are describing what is essentially
>> an esoteric experience. (My intention is not to use this as a
>> pejorative term, but simply as the opposite of "exoteric".)
> I don't agree with that.  Of course, all experience is subjective, but 
> in
> this case the phenomenon being experienced is something which I 
> believe is
> possible to define quite well.  However, it is a complex and
> multi-dimensional thing: whether it is explicitly identified or not, 
> there
> is a separate program that is threaded intricately through every other
> program, at every value reference and function/method application.  
> This
> separate program operates on types.  In most languages and with most 
> real
> systems, it is at least theoretically possible to run that program 
> before
> runtime, and it will tell you when you've done something wrong with 
> types in
> your program.  Because this affects every value reference and
> functional/method application, the consequences of this are 
> far-reaching.
> Just because no-one has sat down to illustrate this phenomenon and its
> consequences in detail, doesn't mean it's not possible to do so.  In 
> fact, I
> suspect no-one has done it because it is blindingly obvious that the
> phenomenon exists, to anyone who has sufficient experience with both
> dynamically- and statically- typed languages.

OK, but there's still something missing. What you are describing is, 
metaphorically speaking, a web that spans a program and accepts it only 
if it has a certain form. Such a web might, in theory, have one of two 
problems: either it is too coarse, or it is too fine.

The problem with, say, the Java type system (up to JDK 1.4) is that it 
is too fine. It forces you to declare too specific types for code that 
might be useful as generic code.

The problem with static type systems in general, as perceived by DT 
proponents, is that they are too coarse. You cannot express certain 
interesting relationships between runtime values statically.

The experience you are referring to is that HM-style type systems are 
perceived by ST proponents to be "just the right thing". At least, this 
is how I understand it. I don't think that you can rationalize that 
very effect. It might be purely accidental that "we" have found a way 
to express types in a way that seems to be able to capture a large 
range of programs. (Of course, it might not.)

> (Note that I'm not saying
> that it's blindingly obvious that anyone with such experience would 
> prefer
> one over the other, only that they would be aware of the effect I'm 
> talking
> about.  If there are any counterexamples out there, please speak up.)

Same here. I have my personal preferences, but I don't claim to be 
objective wrt to those preferences.

>> There are ways to find out whether such
>> experiences have objective content. See
>> http://www.patternlanguage.com/archive/ieee/ieeetext.htm
> I last read any of that stuff in the '90s.  Rather than re-reading it 
> to
> find out what you mean, perhaps you could be more specific about what 
> sort
> of tests are proposed?

Sorry, you're right. I just quote from that talk:

"The essence of the experiments is that you take the two things you are 
trying to compare and ask, for each one, is my wholeness increasing in 
the presence of this object? How about in the presence of this one? Is 
it increasing more or less?  You might say this is a strange question; 
What if the answer is Don't know or They don't have any effect on me? 
Perfectly reasonable! That can happen. But the resolution is easy. What 
turns out to happen is that if you say to a person “Yes, it is a 
difficult question, it might even sound a bit nutty. But anyway, please 
humor me and just answer the question.” Then it turns out that there is 
quite a striking statistical agreement, 80-90%, very strong, as strong 
a level of agreement as one gets in any experiments in social science. 
[...] It turns out that these kind of measurements do correlate with 
real structural features in the thing and with the presence of life in 
the thing measured by other methods, so that it isn't just some sort of 
subjected I groove to this, and I don't groove to that and so on. But 
it is a way of measuring a real deep condition in the particular things 
that are being compared or looked at."

Please remember that this is a talk about architecture, so its 
terminology doesn't really fit ours. But I think that assessments of, 
for example, ST vs. DT should be measured with methods from social 
sciences, and this is what is deeply lacking in CS. Essentially, I 
think that any argument that tries to show the advantages of ST vs. DT 
by purely technological and/or mathematical means is an example of a 
category error.

> However, in this case, I'm not sure it's necessary.
> I can propose a concrete test that anyone can duplicate, given access 
> to a
> programmer familiar with static typing, and one familiar with dynamic
> typing.  (They can be the same programmer, if he/she is honest and 
> unbiased,
> like me ;)
> The test is this: write a non-trivial program in a DT language, and 
> every
> time a bug is encountered during testing or in production, examine 
> whether
> and how that bug would have been caught by a static type system.  Make 
> a
> list of all such instances.  It is guaranteed that there will be a 
> long list
> of such bugs.  The experience I'm talking about is the experience of 
> quickly
> and provably finding all such bugs, prior to ever running the program.

You have just described a recipe how to recreate such an experience, 
which might or might not work. However, this is far from giving an 
exoteric explanation of why this works when it works.


Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."