A New Job for John Cleese

The Ministry of Silly Walks is my favorite Monty Python sketch. I would try to lookup a link to a transcript, but it’s such visual humor that the transcript would be useless to anyone who hasn’t seen it. Well, as an example of life imitating humor, the Pentagon is researching how to identify people by analyzing the way they walk. Note the irony of finding this story about the US government at a British news source.

Well, maybe if John Cleese did get involved, Total Information Awareness could have some entertainment value.

potential differences [/fun] permalink

Forgiveness or Permission

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.

potential differences [/development] permalink

Educational Tests

Brian Marrick comments on Mike Clark’s blog entry Staying Fit With Learning Tests . I’m quite interested since I noticed some of my own backsliding behavior recently when I was writing code against a new API. I was writing my first JMX MBean, and had no one experienced with JMX around for guidance. I didn’t write it test first :-O

I did, however, go back and give it a full unit test suite after-the-fact, and it has been rock solid in production. It did take some refactoring to get it in shape to be easy to unit test, so the late testing step did improve the design. Anyway, back on topic: I attributed my backsliding to the fact that I was exploring/learning a new API.

I think there’s a well-known compromise between Brian and Mike’s approaches, and I’m waiting for a Smalltalker to go into more details — the Inspector. My first development job was for the Apple Newton PDA, which used a custom language called NewtonScript that had features from a number of languages (I’ll try really hard not to bore everyone with all the details, but suffice it to say that it was really a great language to program in, but I was too inexperienced to really realize it at the time).

One of the features the NewtonScript IDE copied from Smalltalk was the Inspector. I’m sure I never used it to its full potential due to being young and dumb at the time, but it allowed the sort of interactive exploration Brian is mentioning, and stored these “lessons learned” in a file that could easily be reopened and re-executed at any time. Mike’s learning tests don’t sound like they’re going to be included in the regular source tree and build process. The only reason they would be saved is to review the lesson and copy/paste some of it into the real system.

Eclipse has the concept of scrapbook pages, which are essentially renamed Inspector pages. It’s not too surprising considering Eclipse’s Visual Age roots, however, I was coding in IntelliJ IDEA so I didn’t think of a scrapbook until I read Brian’s blog. The advantage of an inspector/scrapbook page over Mike’s practice is that you don’t need the overhead of a full compilation unit. You don’t have to have a class and method in which to place executable lines of code. The ‘run’ function of the scrapbook handles that for you.

I suppose I need to explore some more nooks and crannies of IntelliJ to see if scrapbooks are available, but I had looked briefly when I first switched from Eclipse and did not find them. Perhaps it is time to file a feature request.

potential differences [/testing] permalink

iLoo

I first saw an AP story on this, but I thought it had to be a hoax until I found this on Microsoft’s own website. They’re creating an Internet connected port-a-potty!

Must…….resist……..toilet…….humor……. but it’s such fertile ground.

potential differences [/fun] permalink

Hackers and Painters

I know I gave Paul Graham a bit of a hard time earlier, but I have nothing negative to say about his latest essay, Hackers and Painters. He weighs into the dynamic vs. static languages with this great characterization:

… a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you’ve already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that’s not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.

I’m seeing writings all about dynamic vs. static languages all over blogspace. In the meta-sense, it’s really interesting to see a common topic over such a wide variety of individual writers. Good writers, must first be good readers.

I also was quite struck by this insightful, but disheartening observation:

Big companies want to decrease the standard deviation of design outcomes because they want to avoid disasters. But when you damp oscillations, you lose the high points as well as the low. This is not a problem for big companies, because they don’t win by making great products. Big companies win by sucking less than other big companies.

The only slightly contrary point I’d make about the whole essay is that experimental scientific research is a lot more like debugging than he realizes.

potential differences [/lang] permalink

Rsync Your Referrer log

I had thought about this the other day, but it didn’t immediately work as easily as I expected. On my webhost, I’ve added a symlink to my referrer log file in my blosxom directory. I also made a custom shell script that Blapp executes to synchronize my blog entries. That script does a two way rsync so not only does it publish my latest entries from the laptop to the webhost, but it also copies the referrer log from my webhost to my laptop. The script looks like this (with some mods to protect the innocent and a line continuation backslash for presentation):

#! /bin/sh
rsync -Cavz -e ssh --delete /Users/gvaughn/Sites/gigavolt.net/blosxom/ \
userid@webhost.com:/WebSite/gigavolt/blosxom/

rsync -urptgovLz -e ssh --copy-unsafe-links \
userid@webhost.com:/WebSite/gigavolt/blosxom/ \
/Users/gvaughn/Sites/gigavolt.net/blosxom/ 

potential differences [/blogging] permalink

Dynamic vs. Static Languages

Bob Martin asks Are Dynamic Languages Going to Replace Static Languages. I replied:

A couple of months ago my mind went down this same path. I do believe that TDD compensates for many of the things static typing helps with. Over an IM conversation with Glenn Vanderburg, he came up with a good counter-point. The pointcut concept introduced by AOP is very powerful, and relies on static typing. I haven’t gotten my hands into AOP enough to be sure, but my impression is that it could be viewed as a compensation for the lack of meta-programming. Since weakly typed languages are more likely to offer meta facilities, this may be a moot point.

I’m glad to read the article to refresh this idea in my mind, because I think it may tie into the other direction my mind has been going lately (and I love those connections between ideas). I’ve recently began emphasizing the difference between the business logic classes, and the system infrastructure classes and how the different goals imply the different approaches we should use. Now I’m confronted with the question: Is system infrastructure best with static typing, and business logic with weak typing? I think I’ll start up a new background thread..

potential differences [/development] permalink

Finding Bugs is Easy

I’m referring to a paper describing the utility FindBugs. It appears to be developed by a student of Bill Pugh, who is best known for discovering why double-checked locking is not completely safe in Java. I haven’t had the time to play with it yet, but judging from the paper, it looks very promising. It uses heuristics to find typical bug “patterns”. Yes, it’ll have false positives, but it could also prove invaluable in tracking down real bugs before they bite.

potential differences [/tools] permalink

XP or Agile

Brian Marick writes:

Similarly, people attempt to discount XP by saying “XP is crucially dependent on the myth of the on-site acceptance-test-writing customer”

I’m one of those people Brian is talking about, but I wouldn’t put it quite as pejoratively. I was a regular reader of Ward Cunningham’s original c2 wiki from about ‘98 - ‘00 when much of how to explain XP was being hashed out. The goals of XP are very theoretically pure — to create high quality software as efficiently as possible, and it assumes a high level of control of the environment, both physically and politically. It really is critically dependent on an “on-site acceptance-test-writing customer”. That’s great for an initial theoretical model, but it is not practical in most development situations.

Additionally, the personalities of various founders of XP were such that they presented things in a very absolute sense and were unwilling to make compromises. If you’re not doing all the core XP practices, then you’re not doing XP.

I’m so glad that the Agile movement came along. It’s dependent on XP as an initial theoretical model, but Agility is where the reconciliation with those messy real world details happen in order to come up with practical practices in those cases where we don’t have complete control over the environment (i.e. most cases).

I see strong parallels to the uncompromising moral stance of the Free Software movement, and the Open Source movement created in response to it that has grown larger and subsumed Free Software to the extent that it can be considered a subcategory of Open Source precisely because Open Source focuses more on practicality.

Now that I’ve gone through the exercise of writing my thoughts down, I can actually tie it back into the larger point of Brian’s blog entry. The Agile world is where the reconciliation with things like Maxwell’s equations is happening, not under the XP umbrella. In my opinion XP is a shark that has stopped moving (to use Brian’s analogy). Please correct me if I’m wrong. After I first realized the problem of XP’s uncompromising purity, my attention has been focused on those associating themselves with the Agile movement.

I’ve emailed Brian a bit about how to persuade people to adopt an Agile testing stance before he made that blog entry. In this context, an uncompromising adherence to purity is a deterrence to getting the “old guard” to change their minds.

potential differences [/development] permalink