Patterns are signs of weakness in programming languages.

When we identify and document one, that should not be the end of the story. Rather, we should have the long-term goal of trying to understand how to improve the language so that the pattern becomes invisible or unnecessary.

The premise of the post, that patterns compensate for language deficiencies, is quite compelling and certainly worth thinking more about.

(via the excellent lesscode which seems to have sprung to life again)

The key is that although Subtext is a functional language, it has no syntax! Programming is performed via the editor manipulating the data structures using primative operations such as copy and link. The linking is important. Rather than using a tree of operations, Subtext maintains a graph of interlinked functions. In a neat, prolog sort of way, the program you write is always live: results of functions are calculated as you edit the program.

Subtext is cool but ‘out there’ somewhere. It got me thinking about the nature of syntax in programming though, specifically around refactoring. The goal of refactoring is to “improve the design of a program without changing behaviour”. But in a system like Subtext, where you directly manipulate the behaviour: refactoring is impossible. To me, this implies that refactoring is an artifact of syntax. In fact it may just be an artifact of procedural and object oriented syntaxes. I wonder if anyone is busy refactoring in functional languages?

I wondered if there was any way to automate this rather than doing this by hand. The answer is simple: label the old method with an Obsolete attribute. The compiler now issues a warning for each use of the method enabling me to quickly press F4 (I’m using Scite) to step through all the method calls. Here’s what it looks like. The second parameter of the attribute should be set to false so that only a warning is issued. (After all this is a behaviour preserving refactoring, not an error).

[Obsolete("Prefer to use Arc version of this method", false)]
public void addProperty(string uriRef, string literalValue) {
  PlainLiteralNode theObject = new PlainLiteralNode(literalValue);
  ResourceDescription desc = new ResourceDescription(theObject);
  addProperty(new UriRef(uriRef), desc);
}

I was particularly happy to run into the second case I saw - since it involved several of my old friends from C3. They are now building some portal software at Chrysler. Although they started off at the shocking defect rate of one a month, during 2002 they recorded exactly one bug against their system. During this time they were releasing new version of their software every week or two.

He’s careful to point out that adopting XP won’t automatically lower your bug count rate to barely detectable levels, but maybe it helps.

Interesting weblog by the way. One to add alongside Jacques Distler

/*file ut_truncit.pkb */
CREATE OR REPLACE PACKAGE BODY ut_truncit
IS
   PROCEDURE ut_setup
   IS
   BEGIN
      EXECUTE IMMEDIATE
         'CREATE TABLE temp_emp AS SELECT * FROM employee';
   END;

   PROCEDURE ut_teardown
   IS
   BEGIN
      EXECUTE IMMEDIATE
         'DROP TABLE temp_emp';
   END;
   -- For each program to test...
   PROCEDURE ut_TRUNCIT IS
   BEGIN
      TRUNCIT (
            TAB => 'temp_emp'
            ,
            SCH => USER
       );
      utAssert.eq (
         'Test of TRUNCIT',
         tabcount (USER, 'temp_emp'),
         0
         );
   END ut_TRUNCIT;
END ut_truncit;
/

Notice the setup/teardown/test metaphor is all there, hidden under ugly layers of PL/SQL.

The “2 Phase Commit Puzzle” application is a little Windows Forms puzzle that doesn’t use Indigo or the Longhorn bits, but rather employs a little lightweight 2PC transaction manager that Steve Swartz and myself hacked up when we were on our Scalable Applications tour this spring.

The puzzle uses four resource managers (transaction participants). The TileWorker keeps track of the tiles as they are moved around, always votes “yes” on Prepare, does nothing on Commit and rolls all tiles back into their original (shuffled) state on Abort. The TimeoutWorker votes “yes” if the puzzle is completed (pressing the “Done” button) within the preset time-span and “no” otherwise. It does nothing on either Commit or Abort otherwise. The GridWorker votes “yes” on Prepare if the puzzle is completed (order is correct) and otherwise “no”. It also does nothing on Commit or Abort. The OutcomeContingentMessage is a participant that will always vote “yes” on Prepare and shows a “Congratulations” message on Commit and a “You failed!” message on Abort.

It’s worth reading the transaction deck presentation too (not linked since it’s a compressed PowerPoint file. You can find it on Google if you search for the exact phrase “figuring it out on safe ground”)

As software craftsmen, we have rules. Sometimes we feel bad when the rules must be broken. They’re just rules though. What’s important is that we have a moral center, a professional core, that refuses to compromise the quality of our work.

Robert C. Martin, on software quality and professional standards. One of the comments raises an interesting counter-argument: what if the client wants you to ship shit? In that case, there could be a mismatch between yours and their definitions of shit. If the mismatch is too great you’d better start looking for a new client.

The point of TDD is to drive out the functionality the software actually needs, rather than what the programmer thinks it probably ought to have. The way it does this seems at first counterintuitive, if not downright silly, but it not only makes sense, it also quickly becomes a natural and elegant way to develop software.