MATLAB and Greenspun’s 10th Rule

Just to get this disclaimer out of the way, let’s remind everyone that this is my personal website. Even though I may write some of the articles at work about things I’ve done at work, they aren’t in anyway supervised or endorsed by my employer. I’m only including this disclaimer because this article is meant to be self-deprecating in that “I had the best of intentions, but now I feel a little silly” way.

Several years ago I read Greenspun’s Tenth Rule of Programming: “Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.” Basically it’s a joke about feature creep in software. I was reminded of this quotation today when I started reading Joshua Kerievsky’s Refactoring to Patterns. He describes the perils of over-engineering, which is basically the same as wasting money.

You see, about seven or eight years ago, I added a Lisp parser to a feature in MATLAB’s Image Processing Toolbox. If you have the toolbox, just take a look in toolbox/images/iptformats/private/dicom_create_IOD.m. There you’ll see a part of the code that looks like this:

function tf = check_condition(expr, metadata)
%CHECK_CONDITION  Determine whether a condition is true.
%
%   Conditions are LISP-style cell arrays.  The first element
%   is a conditional operator, remaining cells are arguments
%   to the operator.
%
%   Conditions can be nested.  Each cell array in expr indicates
%   a new conditional expression.

%[snip]

%
% Process conditional expressions recursively.
%
switch (lower(operator))
case 'and'
   
    % This AND short circuits.
    for p = 1:numel(operands)
        tf = check_condition(operands{p}, metadata);
       
        if (~tf)
            return
        end
    end

[snip]

So why did I do this? The DICOM file format has conditional elements, which only show up in the file if other elements are present, are absent, or have a particular value. I wanted to create a general-purpose, reusable, extensible mechanism for describing these conditions so that I didn’t actually have to write code for all of those conditionals. Moreover, I wanted our customers to be able to write the conditions in a nice tabular form rather than writing code, because — you know — one day they would want to write more of the dozens of kinds of DICOM information objects from scratch than we supported right out of the box.

You probably see where this is going. We ended up extending the product in a different direction after we learned more about how our customers actually wanted to use the DICOM export functionality. So, if you need a Lisp-like algebraic Boolean logic parser in MATLAB, just go look in the previously mentioned file. (Also take a look at the dicom_modules.m file in the same directory to see how to express those conditions.) But for g-d’s sake, ask yourself if you really, really need that, or if you aren’t just fooling yourself into over-engineering your code.

This entry was posted in Computing, Life Lessons, MATLAB, Software Engineering. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>