Can someone explain the concept of testing to Bobby Woolf? I thought he'd get that kind of thing, but not so much:

Declared interfaces, like clean air and clean underwear, are easy to take for granted until you don't have them. I used to do my OO programming in Smalltalk, which is a great language; but one deficiency I always felt (and this is heresy for a Smalltalker to say, but I'm saying it anyway) is the runtime binding -- what I came to think of as extremely weak typing. Smalltalk variables had no declared type/class, so practically any code with correct syntax would compile. It wasn't until runtime, when a client invoked a message on an object, that the environment determined the variable's object's class and looked at the class to see if it implemented a method with that signature. So you didn't really know if your code worked until you ran it, and you got lots of runtime errors that finally uncovered your simple programming mistakes.

That's perhaps the most uninformed paragraph I've read in a long while. Since you can run Smalltalk code at any time, not testing it takes effort - even if you don't have unit tests, ad-hoc testing gets done all the time (I do it with my blog server and with BottomFeeder all the time). That class of error is what static typing advocates are certain Smalltalk must suffer from - but in practice, we just don't see many errors of that sort in a sealed application (and we can deal with the ones that do happen).

Along those lines, there's a kind of testing that's much, much simpler to do in Smalltalk than in the languages Bobby seems to favor now - live testing. Say you are trying to hook up some client tool to your server using a poorly specified API like MetaWebLog API - it's common for person A to interpret the spec one way, while person B interprets it another. What I've done is have someone hit my test server with a client, and had the inbound message break in a debugger - and then I've fixed my code to match the client while it was waiting for a response.

You can have all the declared interfaces you want, but they don't always help in the real world, when you are hooking up disparate pieces that were implemented by different people reading the same spec differently. Maybe in Bobby's ideal world, that doesn't happen:

XML does for data what Java interfaces do for code: It strongly types the data by declaring its schema (much like the DDL for a relational database schema). XML data has to be well formed to be parsed. It can also be valid, meaning that it fits the agreed-upon data structure. That structure is declared in an XML schema which the XML data is validated against. So when the consumer of some XML data can't consume it successfully, the development teams have a much more objective and less political means to determine where the problem is: a validating parser. Either the XML data validates against the schema--in which case the consumer has a bug--or it doesn't--in which case the generator has a bug (or the data validates yet the consumer finds flaws in it, in which case the schema needs to be improved).

*Cough* MetaWebLog API *Cough*. Or RSS. Two widely used XML Specs that demonstrate just how deep the rabbit hole goes - and how far off in WS* fantasy-land Bobby has travelled. Come on back to Smalltalk, Bobby - the water's fine, and we can handle specs that make your Java code pitch fits.