[plt-scheme] Imperative programming : missing the flow

From: Marco Morazan (morazanm at gmail.com)
Date: Fri May 11 23:13:30 EDT 2007

Dear John,

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.

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

I hope this helps!



On 5/11/07, John Clements <clements at brinckerhoff.org> wrote:
> I'm hoping that others here can point me to existing work on this
> topic, or help to refine this idea for me.
> I'm teaching Java to first-year students, and we're about to walk off
> a cliff and start programming imperatively.  I've done this
> transition several times now, and it occurs to me that what's most
> irritating to me about the imperative style is the lack of "flow".
> What do I mean by flow?  Simply that each expression produces a
> result that is used by another expression.  In imperative
> programming, by contrast, I feel that I have a bunch of statements
> lying on the floor, and that their order is both important and
> difficult to explain clearly.
> Here's a simple example of the difference: take a functional
> program.  remove a subexpression.  Does it still compile?  Probably
> not. In contrast: take an imperative program.  Remove a statement.
> Does it still compile?  Sure it does, and does the wrong thing.
> This problem is inverted when we're talking about program
> construction (the job of a programming teacher).  How do I write a
> function?  Well, in a functional program I can start "at the top"
> with the outermost constructor for the result and proceed inward.
> How do I know when I'm done?  Well,  the program won't compile until
> I supply all of the pieces.  To construct an imperative function, by
> contrast--especially one of type void--I can simply write "return;".
> How do I know when I've got all the pieces?  I don't have a good
> answer here.
> In fact, a better name for this might not be "functional", but rather
> "algebraic," in the sense that program fragments are combined
> algebraically to form programs.
> Once again; can anyone point me to existing work, or tell me that I'm
> wrong?
> John Clements
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070511/42359763/attachment.html>

Posted on the users mailing list.