Jim Robertson's blog had a discussion recently about manifest typing and refactoring support. It got rapidly out of hand, but the basic point was interesting. Essentially, given static type information, a refactoring engine can work better. In particular, it's possible to rename methods (with Integer + as the example) which you couldn't in a dynamically typed system because you can't tell which sends are to integers and which to other things.

This is true, but more complicated than it first appears. It's not that the dynamically typed system doesn't have enough information to do the refactoring, but rather that renaming a method implemented by multiple classes incompatibly is not necessarily a behaviour-preserving transformation in a dynamically typed system. If there wasn't enough information, then the refactoring engine would just have trouble finding which call sites needed to be modified. But we can easily have call sites that can't be automatically modified. Consider

   frobnicate: something
      ^something + 7.

The parameter might be an integer, but it might not. I believe that the same issue arises in a statically typed system with type inference, or in a manifestly typed system with templates. Suppose that we created a templated type SummableList<T>. This is just a parameterized collection with a sum operation that returns the sum of all the items in it. Now if we want to rename the + operation, do we change the send of + in our class or not?

More generally, a dynamically typed program will have less information about itself than one with manifest typing (although I presume it would be the same as a statically typed program with type inference). That's part of the point - you don't have to specify as much. At least as far as Smalltalk is concerned, these are part of the reason it has development traditions like test-driven design, and unit testing (and is where the original refactoring tools came from, as well as the original xUnit). These kinds of measures help ensure correctness when the program changes, while preserving the flexibility, terseness, and other advantages of not specifying types up-front. And as well, keyword messages make name collisions that much less likely.

But the nice thing about many of these techniques is that they don't just affect behaviour-preserving transformations. In my opinion, there's too much emphasis on that. While refactoring is wonderful, it's my considered opinion that to be really productive in development, you will eventually have to do something that changes the behaviour of the program. So it's not just the ability to make changes that don't affect behaviour, it's the extent to which changes in one place propogate through the rest of the program. Do they damp out quickly or do they force lots of other code to be changed. Examples of things that I'd consider to propogate are Java's checked exceptions in the method signatures and C++ const. Dynamic typing is an example of something that helps damp out changes.

I remember back in the good old dot-com days, I took one of my recently-ex companies press releases, edited a few words judiciously, and challenged people to guess which decade it was written in. The promises of re-use Nirvana were all centered around components, but it read word-for-word like the kind of nonsense thrown around in the 80's for objects.

Now, I should say that it's a start, and it's a real shame that so few products can live up to it. For example, Gosling apparently admitted this about J2EE recently . The problem is that if you follow this maxim with what I'll call the "wrong attitude" you can end up with "Microsoft usability". What I mean by that is that the underlying product is hideously complicated, but you have pretty bits to handle the really simple cases. So simple things, at least a few of them, are simple because you have wizards to generate them for you. Anything beyond that counts as complex. It's possible, but it sure won't be easy.

Part of the problem is the discontinuity between the simple and the complex. One of the nice things in Smalltalk is that the barriers in "dropping down a level" are relatively small. Simple things are simple, but simple things are also incremental steps towards complex things. Another way of putting this is that magic should be avoided. If the underlying system can do something, the user ought to be able to do it, as easily as possible.

I certainly wouldn't claim that VisualWorks, or Smalltalk in general is somehow the ultimate in this regard. We have lots of excessively complicated or just bad. One thing that helps Smalltalk though is the aesthetic of simplicity. It's by no means universal, but code being complicated is considered a valid criticism and there's just that much more pressure to simplify.

And in the end we get that much closer to the ultimate goal, which is after all the point of software. "Simple things should be simple. Complex things should also be simple"

Update: It appears I was wrong about SmallLint - it's *suggesting* the use of guard clauses, not complaining about them. So I'm agreeing with it, and the ranting was unnecessary.

A small rant. I notice that the SmallLint code checker has a number of things it flags as potential problems. One of them is "guard clauses" - e.g. something of the form.

isSomethingTrue
     someCondition ifTrue: [^true].
     someOtherCondition ifTrue: [^true].
	^thisCondition & thatCondition & theOtherCondition.

I *like* guard clauses. I'd much rather see code like this than complicated boolean expressions. Boolean expressions always confuse me, and are harder to walk through in the debugger. I was going to write out the boolean expression equivalent of the previous, but I'm pretty sure I'd get it wrong anyway.

• Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle
• Testing Extreme Programming, by Lisa Crispin and Tip House
• Test-Driven Development, by Kent Beck

I've heard good things about Scrum from a number of sources, so thought I'd check it out more thoroughly. The other two books, I think come out of a sense that I'm still not really sure how to best write test suites. The suites are tremendously helpful, but I think they could be more so, and better organized. And, though I've probably heard most of Kent's ideas on the subject, he's always interesting to read. The other testing book is written by professional testers, so should have a less programmer-centric view.

Sometimes I'm not sure why I bother buying programming books at all. They're always a problem for me. If they don't have anything interesting to say about programming I tend to stop reading them fairly quickly. If they do have something interesting to say about programming then after a dozen pages or so I am often seized with an overwhelming urge to stop reading and program. So unless I'm in some situation where I can't program (e.g. on a plane with a dead laptop battery) I tend to only get small snippets read. (A friend who I mentioned this to said that he'd just bought two programming books - one on JSP and one on Javascript, and all it made him want to do was quit his job :-)

Despite all that, I've been working my way slowly through the Scrum book, in bathroom-sized chunks, and so far it seems interesting, if harder to put into practice when you work at home.

Martin Fowler comments on Model-Driven Architecture (MDA) .

I've heard a lot of talk about MDA in the last while. I can't say I understand why. I thoroughly agree with Martin on this one