| Joe Marshall 2006-07-06, 7:01 pm |
|
Shriram Krishnamurthi wrote:
> I don't have any deep hostility towards types, nor are my opinions
> about them nearly as strong as those of someone like Joe Marshall.
I surprised Arthur Gleckler the other day when I said that I have
essentially a favorable view of static types. I'll probably surprise a
few more people if I mention that it was Matthias Blume who persuaded
me. His argument was this: Why would anyone *not* want the computer
to find bugs *automatically* at compile time? (Ignore the practical
difficulties for a second.) I have no problem with this *in
principle*.
> The problem is getting them to live nicely with the world the rest of
> my code inhabits.
That's the rub. I object to giving the computer hints about types
(especially at the beginning of a project), and I truly object to the
computer refusing to run any part of my program unless it *all* type
checks. I also like to use type-ignorant constructs like lists; the
type checker has a hard time with these.
So while I have no problem with static types in principle, they don't
do an awful lot for me in practice.
Interestingly, I have wanted some static type guarantees in mature
code. In a complex project I was working on, the low-level library
code was quite stable. Certain library routines were able to take
advantage of the fact that all callers passed objects of a particular
representation. By declaring the type to the compiler, we were able to
get it to produce very fast code. We'd provide a generic wrapper
function that would dynamically check that the arguments matched the
required type before calling the fast code (and either calling the slow
code or raising an error otherwise), but I'd have really preferred it
if the compiler could have automatically dispatched to the correct
code, or if it could have raised an error if the caller misused the
library.
I don't like to declare types in experimental code because I really
don't know what the type is at that point. Once the code is fairly
mature and I'm happy with the design, it becomes rather obvious what
the types are. At this point in the process I would welcome more help
from the compiler.
> Neelakantan Krishnaswami wrote:
I've been thinking about this for the past several days. I'm curious
as well. I *think* that there are several common strategies and that
people get used to one or two that are successful for them. Marshall
Spight has questioned me on this as well.
I'd like to do a programming contest where the object is not to be
first, fastest, or best, but to have different groups and people
demonstrate different programming strategies as they build the program.
Static type aficionados seem to want to design the types at the
get-go, while dynamic people seem to want to design the data and
control flow first. I'd like to see how these approaches contrast.
For higher-order functional programming, I think I might be using a
different model than you. I see LAMBDA not so much as specifying a
function, but as marking a code fragment. I see the higher-order
functions not so much as a mapping between function spaces, but rather
as a template. The missing pieces are the code fragments provided by
LAMBDA expressions elsewhere. The type of a higher-order function is
parameterized by the type of the code fragment in a particular
instantiation of that function, so I *think* that my strategy might be
that I'm internally flattening the higher-order type to something
relatively simple. But I'm not really sure --- I just hack.
[color=darkred]
> I program bottom-up. So I'm constantly testing my code as I go.
> Testing early and often makes a huge difference.
I prefer a stratified design strategy. I'll work on a layer at a time
(not necessarily the bottom or the top). I do a lot of playing around
with partially implemented functions and explore how different parts of
the program need to interact with other parts.
> For the most part I program as if I were in ML. I program with a type
> discipline, so I make relatively few type errors.
When I *know* the type (like if it is an index into an array), I put in
explicit type checks. When I don't know the type (it is an `object' of
some sort) I leave them out.
>
> So, it's not that I don't make type mistakes, or that the ones I make
> don't annoy me. But these aren't where my deep bugs are. Presumably
> that's not where your deep bugs are, either, if you're writing
> interesting, modern applications.
The deep bugs I find generally have to do with a misunderstanding
between two parts of the system. It is often hard to localize the bug:
both parts of the system are doing reasonable work, but they don't do
it together.
|