The Art of Science

Programming, new media, politics, and a potpourri of assorted rants

Human typing

Posted by Tony Arcieri Wed, 16 Jul 2008 07:27:00 GMT

What a confusing title for this blog post.  I’m certain the programmer community who is reading this can guess what it means.  No, it’s not about humans typing on keyboards, stereotyping, or any of that.  It seems to me that most programming languages enforce certain constraints on their users which aren’t really in line with how humans operate.  I think type systems can be human-sensitive, if designed properly…

The important point is to look at how people reason about problems.  I don’t know about you, but I try to look for what similar problems can relate to the problem I’m presently experiencing, and synthesize that knowledge into a solution that works for me now.  I look for similar solutions to similar problems.  Why can’t programming languages work that way?

Within the traditional statically typed object oriented languages, there’s sort of an obsessive compulsive approrach to solving similar problems: you use inheritence.  CaringForCats is similar to CaringForDogs, right?  I mean, they’re both mammals.  So let’s turn CaringForDogs into a CaringForMammals base class, move the dog-specific behavior into a new CaringForDogs subclass of CaringForMammals (which we abstracted from the original CaringForDogs class) then subclass CaringForCats from that.  I mean, dogs are a mammal, therefore we can abstract our experience with dogs to all mammals then subclass our relationship with cats from that, right?

Unfortunately, that’s not how it works in reality.  Caring for cats is nothing like caring for dogs, even though we’ve made the observation that they’re both mammals.  Despite our ability to classify dogs and cats as both mammals, we’re overlooking the reality of the situation: caring for dogs is nothing like cats, so why are we even trying to make an "abstract" mammals base class when really we’re dealing with two different types altogether?

The thing is: some things that work for dogs works for cats.  There’s certain aspects of the dog experience which translate over.  Maybe not enough to say they’re entirely related, but maybe we can learn what dog things work for cats, then go from there.

So, how do you relate that back to programming?  Well, we have two things which share a minimal degree of similar interfaces, but the dissimilarities are enough that it’s really silly to say that CaringForCats is a subset of CaringForMammals… there really is no general way to care for mammals, but there maybe a few tricks which carry across, to the point you can try to care for a cat as if it were a dog and work your way from there, specifically learning what doesn’t work, simply through trial and error.

Dynamic languages have introduced the idea of "duck typing"… metaphorically, if something behaves like a duck, then treat it like a duck, and things will more or less work out.  Sorry, that’s if it quacks like a duck.  But nothing quacks like a duck except ducks.  So what happens when you try to quack to a cat?

Duck typing tries to cast off the uniformity of abstract base classes by letting you experiment with trial and error and find your own feel for an object which is similar, but expresses many different qualities from what you know.  Mammals don’t quack like ducks, but you perhaps have past experience with the differences between mammals and ducks, and specifically you have experience with dogs.  That doesn’t mean you’ll know how to deal with cats, but you can learn, and some of your experiences with dogs will translate over into cats.  There’s no rigid, formally defined structure relating cats and dogs, but as a human, you can do your best with your past knowledge and try to translate dogthink into catthink.

Bottom line, I think duck types are a powerful, human-friendly concept which is easily written off by the static typing OO purists as some form of impure abstract base class.  Java pursued this approach with Interfaces, which choded the programmer with complaints about not implementing the entire interface definition, even if certain parts didin’t apply.  Even the smartest programmer can’t know beorehand all the ways a particular interface can be abstracted… if you can get 90% of the way there, and leave the remaining incompatibilities for the API user to fix, haven’t you accomplished enough?  By leaving incompatibilities in place, you don’t have to abstract away the best underlying features of some system simply for the sake of compatiblity.

So really, why is it called duck typing?  I think, being as in-tune with the way humans accomplish tasks as it is, it should be called human typing…

9 comments | Tags | atom

Comments

Leave a response

  1. Jean Walker
    4 months later:
  2. Noemi Dominguez
    4 months later:
  3. Robbin Mitchell
    4 months later:
  4. Billy Duran
    4 months later:
  5. Kirby Woodard
    4 months later:
  6. Timothy Steele
    4 months later:
  7. Missy Holder
    4 months later:
  8. Matt Hull
    4 months later:
  9. Raynard Duffy
    4 months later:

Leave a comment