[plt-scheme] Was HTDP 21.1.2 - Why I "don't" use the design recipe

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Thu Jul 13 10:32:32 EDT 2006

On Jul 13, 2006, at 5:31 AM, wooks . wrote:

> For the benefit of anybody reading who thinks JSP stands for Java  
> Server Pages,
> JSP (Jackson Structured Programming) is a data structure based  
> approach to program design. You diagrammize your input data  
> structures according to some very simple conventions then you merge  
> the data structure diagrams  into a program structure.  ... Etc.

The data dimension of the design recipe is analogous to the Jackson  
Design. I have known JSP since the very early 1980s; I am that old,  
too. Michael and I (and Shriram and Robby) have met several times  
since (by accident) and the first time we had a fruitful discussion  
bringing out some of the commonalities and some of the differences.  
JSP is the closest thing to rational design with COBOL; Noel has  
pinpointed the exact nature of the data dimension of the DR in his  

>  It had come back with all the JSP parephanalia and  used  program  
> inversion (a technique for resolving clashes between the input data  
> structures in your program) for it's print routine. Program  
> inversion  results in impenetrable code (at least in COBOL) so you  
> are wholly dependent on the structure diagrams for its maintenance

Program inversion is closely related to CPS, continuation-passing  
style. Assume you have f : A -> B and g : almostB -> C and you want  
(more or less) g o f for functionality, how do you do it? If there is  
a natural relation between B and almostB you produce B piecemeal via  
f and feed it into g, after a bit of munging possibly. So f and g go  
back and forth. Why piecemeal? Machines weren't big enough and you  
don't want to write things to a tape and read it back in.

So you invent coroutines for COBOL, which doesn't have any. How do  
you get coroutines? With continuations. Inversion gives you just  
enough of them to do the things you want.

Since the transformation is systematic, it is most definitely  
something that trained programmers can spot, read, and modify as  
desired. I have been in this situation. I am not talking out of the  

> Needless to say that is not a situation a  Project Team Leader  
> would want to be in - so do you think he  changed the programming  
> "standards" to conform with J ...

If the team had used JSP from the beginning, making the changes and  
maintaining the software would be -- EASY. But they didn't. They  
mumbled around like most programmers. So they had s't on their hands.  
And instead of starting with a good, high standard and convert other  
pieces on a by need basis, they continue to muddle thru and create  
more s't. 

Our goal is to first train programmers on how to do it right and then  
confront them with bad code and show them how to add decent modules  
to that.

;; ---

Comments are BAD. Beginning Scheme and R6RS don't have the expressive  
power, however, to formulate and check "contracts". When we wrote the  
book, we didn't have the background to do things properly. Now we do.  
So for now you are writing comments.

;; ---

Do I follow the DR for every thing I write? No. But guess what, every  
time I spent major time on a bug, it's because I didn't follow it.  
And then I hate myself.

Now here is a secret. A few years back, one of the major members of  
the team was visiting NU and I asked him to help us figure out a bug  
in his code for a language level. He had no problems spotting the  
problem but ... he couldn't run the functions from his module because  
he couldn't figure out from the provide what the function consumed in  
what order. No comments, no contracts, no purpose statements. He had  
to read the code itself before he could run the help function and  
determine that it was its mistake. That took quite some time. Imagine  
what would have happened if he had written:

  ;; f : Nat S-expr Symbol Symbol String -> S-expr
  ;; (f x y z w) inserts ...

I won't tell you who that was but I am just pointing out that yes  
comments are often out of sync with the code but if the maintainer is  
meticulous then comments help a lot in a Dynamically Typed Language  
such as Scheme.

Thanks for accepting the design recipe. -- Matthias

Posted on the users mailing list.