April 4, 2006

Only in America...

Grady Booch (no permalink) quotes Dick Gabriel as pointing out:

I got this from a colleague: "As you may have noted, on Wednesday, at two minutes and three seconds after 1:00 in the morning, the time and date will be 01:02:03 04/05/06. Unless you are very young, or live a very long time, this is probably your one chance to observe this date. Whoop it up."

Much of the rest of the world thinks this is premature and will be waiting for the fourth of May.

Posted by stevef at 10:02 PM

April 2, 2006

On returning from functions

Ivan writes about his reaction to Pragmatic Dave's comments at SPA 2006 on GOTO considered harmful as a Cargo Cult.

I have two conflicting examples.

First:

As a misspent youth, I worked on Stratus minis in PL1, a nice environment in its day that, I believe, had roots going back to Multics. Our convention was to start and end each procedure with a label. If you wanted to return early from the procedure, you would goto the end label. For example (as best I can remember),

make_tea: procedure;
ENTER:
  call boil_water;
  call fill_pot;

  if pot_empty()
  then goto EXIT;

  keep_pouring;

EXIT:
  return;

end make_tea;

We did this because it meant we always had somewhere to hook the debugger (this was before TDD). We could trap the exit and check the return value before popping the stack. Nowadays, we have more powerful debuggers that can trap this kind of thing — and, anyway, who needs debuggers any more. Of course, the other part of the convention was that this was the only acceptable use of goto, so it was just a complicated return statement.

Alternatively:

My version of Ivan's example is to go functional and use the ternary operator that he's avoiding to make his point.

int foo(boolean condition) {
  return condition ? 5 : 6;
}

This is enough to start a religious war in most Java teams, since many people find ternaries hard to read. I like them because they make clear that we're returning something. There's no risk of having to think about state here, nothing else that might slip into a branch of an if statement, just values. I probably go overboard with this, but I tend to wrap up more complex calculations so I can keep my top-level ternary.

int foo(boolean condition) {
  return condition 
         ? barThatReturns5() 
         : barThatReturns6();
}

Now I get to keep a single return point without having a variable messing up the place.

Of course, none of this would be necessary if we were working in decent languages, the only reason for having the ternary operator is that we're not allowed to write:

int foo(boolean condition) {
  return 
    if (condition) { 
      barThatReturns5() 
    } else {
      barThatReturns6();
    }
}



It turns out that Keith Braithwaite has already made the purist's case

Posted by stevef at 4:02 PM | Comments (2)