Dan Steinberg got me thinking along the lines of the old saying “it’s easier to ask for forgiveness than permission” with a side remark in his article on iCal. What he actually wrote was “With exceptions and strong typing, Java makes you say ‘please’ while Perl makes you say ‘sorry’” A static typed language makes you ask ‘please’ ahead of time, while a dynamic language makes you say ‘sorry’ by waiting until runtime to find some errors. But, of course, a good unit test suite reduces that significantly.
My last entry on this topic discussed the idea of using the ‘safe’ aspects of static typing for writing robust system facilities, while using the ‘easy’ aspects of dynamic typing for business logic that will probably need to change over time. Ted Neward recently wrote about using static and dynamic languages for these different purposes.
In my opinion, one of the generating functions for the whole Agile movement is that requirements from non-technical people are unavoidably vague. These are the people we get the business logic requirements from. However, it is typically other developers that define what the system facilities must do. Recently I wrote a JMX MBean that had to handle retrying communication with an external web service that occasionally goes down. It basically moves JMS Messages to and from a temporary queue with the use of a timer. The MessageDrivenBean that actually performs the communication and business logic just has to rollback the transaction that includes accepting receipt of the message when it can’t communicate with the external service. The MBean system facility takes care of calling it again later.
In writing this MBean, the static typing of Java helped make it robust. The checked exceptions forced me to seriously consider different failure modes and how to handle them without losing any messages from the queue. This is a system facility whose requirements were ultimately driven by developers. Once the requirements were understood they never changed. I propose this is the common behavior for this sort of system facility, and that it is precisely because there is not the typical impedance mismatch of communication between technical and non-technical folks. But for business logic, this mismatch exists, and dynamic typing makes the changes much less painful
I’m on a roll here, so I’ll bring up one more related topic that has come up in recent conversations with coworkers. We’ve been discussing exception handling. Most the developers have been doing Java lately, but there’s a new project being written in .NET, which only has unchecked exceptions. Java gives you the choice of either checked or unchecked exceptions. My position is that checked exceptions go hand in hand with strong typing, and unchecked exceptions go with dynamic typing. Unchecked exceptions help make the code more fungible around business logic, which checked exceptions help make the code more robust around system facilities. Java gives us that choice in the exception arena, but not more broadly for type safety. (Oh, and .NET is really mismatched by having static typing, but unchecked exceptions.)
I forget where I read it lately, but someone proposed a language that would allow you that choice in how types were enforced. If this could be done on a class by class, or component by component level, it would let us avoid the complexity of using two implementation languages for an application, which would happen if we go with a static typed language for system facilities and a dynamically typed language for business logic. Perhaps there already is a non-mainstream language that allows that. Let me know if you’re aware of any.
Previous Topic
