Multimethods, reduce(), April First, and overly long expressions
Guido wrote (about an example of dynamic type dispatching code that used explicit isinstance calls), "... This pattern gets tedious. (It also isn't very OO, but then, neither are multimethods, despite the name, IMO.)
I've long held the thought that multimethods are less object-oriented than traditional single dispatch code. I've never quite figured out why that feels like it matters. Probably something to do with code clarity, although a visitor pattern is certainly clearer with multimethods than without. Maybe it's the extra implicit crud that most multimethod implementations add -- CLOS' call-next-method et al.
Note that I do agree that multimethods are more powerful; I'm just claiming that they are less object oriented. And suspecting that this makes most MM code less clear: most code doesn't require or benefit from the presence of MMs. Are there any languages which have MMs but require that they be marked differently from the more common single dispatched code? Hmmm...
IMO, Guido was three weeks early in suggesting that reduce() be removed from Python.
Shriram Krishnamurthi agrees about the timing.
It's not all that closely related, but I have lately decided that one of the style issues that most clearly distinguishes Lisp fans from Python programmers is that the former seem to like to write extremely long and convoluted expressions, nested many levels deep, while the latter tend to prefer to name the intermediate values.
I tend to side with the latter. Consider last month's posting about Programming as Teaching. The programmer who is writing his program as if he's teaching someone about its algorithms will provide more clues about the intent of that code, than the one who isn't thinking about teaching. Taking the time and mental effort to think up meaningful names for some of those intermediate results can often help with code clarity. (And with debuggability.)
11:34:16 PM
Random radio Weblog