Design Patterns

I've been using Haskell a lot lately.  I wanted a deeper understanding of the interaction of type classes, since the number of type variables in mine is exploding as I try to simulate the ML module system in type classes.  Obviously I'm doing something wrong.  Thus, I've been reading the standard papers on functional dependencies, etc.  For variety, I figured I'd reread some object oriented programming stuff, since they've thought a lot about class relationships.  (Though type classes bear little resemblance to OO classes, there are some similarities.)  So I picked up the Gamma et. al Design Patterns book.  I know I live in a functional programming bubble, but I'm surprised at some of the stuff I'm reading.

  p.22.  On "parameterized types" aka. parametric polymorphism, aka. generics.

  "None of the patterns in this book concerns parameterized types, though we use them on occasion to customize a pattern's C++ implementation.  Parameterized types aren't needed at all in a language like Smalltalk that doesn't have compile-time type checking."

It sounds as if the authors think of compile-time type checking as a scourge on programmers that
forces them to use parameterized types.  
  To be fair, they do say that parametric types are another way (the other two being class inheritance and object composition) to structure your programs, each having strengths and weaknesses.  Interestingly, they point out that you can't change the implementation of a polymorphic function at run time.  That's true (I think) but I'm struggling to understand what they mean.  For instance, you might have two implementations of sorting with different behaviors (e.g. one better on one kind of data, the other on another kind), and you might notice that a chosen sort of an input stream is performing badly and want to switch to the other algorithm.  This is an easy thing to do in ML or Haskell, as I suppose it is in C++.
Thus, I don't know what they mean by saying you can't change the implementation at runtime.  Do they mean, the implementation of a single function?  If so, I have no idea why you would want to do that.  How could you reason about your function f if sometimes it's calling f1 and other times it calls f2?
   The abstractions of design patterns seem interesting, but I'm not seeing yet how to apply the ideas to functional programming.