<div>Dear John,</div> <div> </div> <div>It is my belief that you have hit the imperative programming problem on the nail. There is, however, work that might be useful in making sense of what is going on for both the students and the instructor. To write/develop a function start with a specification ( i.e. preconditions for the input and a postcondition for the output and, yes, we can adapt for arguments passed by reference :-). As code is developed insert Hoare Logic-like assertions as comments between statements to describe the state of the computation. Very broadly, Precondition + code + assertions = Postcondition. This approach avoids "leaving statements out" and indicates why the order of statements is important. It takes time to get good at doing this in a classroom, but I have used it effectively in the past. </div> <div> </div> <div>The technique applied to Java has been polished by Doug Troeger of The City College of New York. You may want to contact him for ideas and sample course material.</div> <div> </div> <div>I hope this helps!</div> <div> </div> <div>Cheers,</div> <div> </div> <div>Marco<br> </div><br><br> <div><span class="gmail_quote">On 5/11/07, <b class="gmail_sendername">John Clements</b> <<a href="mailto:clements@brinckerhoff.org">clements@brinckerhoff.org</a>> wrote:</span> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I'm hoping that others here can point me to existing work on this<br>topic, or help to refine this idea for me. <br><br>I'm teaching Java to first-year students, and we're about to walk off<br>a cliff and start programming imperatively.  I've done this<br>transition several times now, and it occurs to me that what's most <br>irritating to me about the imperative style is the lack of "flow".<br><br>What do I mean by flow?  Simply that each expression produces a<br>result that is used by another expression.  In imperative<br>programming, by contrast, I feel that I have a bunch of statements <br>lying on the floor, and that their order is both important and<br>difficult to explain clearly.<br><br>Here's a simple example of the difference: take a functional<br>program.  remove a subexpression.  Does it still compile?  Probably <br>not. In contrast: take an imperative program.  Remove a statement.<br>Does it still compile?  Sure it does, and does the wrong thing.<br><br>This problem is inverted when we're talking about program<br>construction (the job of a programming teacher).  How do I write a <br>function?  Well, in a functional program I can start "at the top"<br>with the outermost constructor for the result and proceed inward.<br>How do I know when I'm done?  Well,  the program won't compile until <br>I supply all of the pieces.  To construct an imperative function, by<br>contrast--especially one of type void--I can simply write "return;".<br>How do I know when I've got all the pieces?  I don't have a good <br>answer here.<br><br>In fact, a better name for this might not be "functional", but rather<br>"algebraic," in the sense that program fragments are combined<br>algebraically to form programs.<br><br> Once again; can anyone point me to existing work, or tell me that I'm<br>wrong?<br><br>John Clements<br><br><br><br>_________________________________________________<br>For list-related administrative tasks:<br><a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme"> http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a><br><br><br></blockquote></div><br>