[plt-scheme] Was HTDP 21.1.2 - Why I "don't" use the design recipe
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
message.
> 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
blue.
> 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