[plt-scheme] Imperative programming : missing the flow

From: Joe Marshall (jmarshall at alum.mit.edu)
Date: Fri May 11 17:43:04 EDT 2007

Since no one else answered yet, and I have an opinion (and I'm not
afraid to use it!), I'll suggest something.

One advantage to functional programming is that the pieces fit
together like puzzle pieces:  the output of A must match the input of
B to make it work.  An imperative program is like the puzzle with
every piece being a perfect square.  Anything can go anywhere.

In an imperative program, the different pieces have pre- and post-
conditions that have to match up, but the problem is that these
conditions are implicit, and the language gives you no help at all in
manipulating them.  In most imperative languages you can't even
*express* them, let alone manipulate and check them.

You *can* find an analagous problem in a functional program, it is
just a bit trickier.  Suppose you wanted to sort a list and you wrote

(define (sort predicate list)

This is just the functional version of your `void' program -- the one
that does nothing and returns --  this does nothing and returns
something of the right type.

That's my rambling.

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


Posted on the users mailing list.