[racket] Sweet expressions; or making it easier to introduce Racket to me and my coworkers :-)

On Jul 20, 2011, at 5:02 PM, Greg Hendershott wrote:

> Spoiler alert: It turned out to be no hurdle at all. The psychic
> whiplash lasted days/weeks, not weeks/months.

When I'm talking to teachers about starting in Scheme-related languages, they always say "but the prefix notation will confuse the students!"  In reality, it's a much bigger problem for teachers than for students: with actual students, it's an issue for a couple of days, and then they have bigger fish to fry :-)

>> ... getting my head to read the deeper
>> nested (if (some thing) (else branch)) structures is somewhat painfull.
> 
> Actually, "control flow" code like that is pretty easy with the right
> editor: The "if", "else" and indentation will be in much the same
> places you're used to. The underbrush will just be () instead of {}.

Right.  Nested conditionals and loops in Racket are no more syntactically painful than nested conditionals and loops in Java/C/C++, if you put braces around the bodies.
( if ( > x y ) (+ x 3 ) ( * 4 y ) )
if ( x > y ) { x = 3 ; } else { y = 4 ; }
[Obviously, these don't do the same thing; I didn't want to be accused of stacking the deck by doing an idiomatically-functional thing in both languages.]
 
> With time you may find yourself doing far fewer nested conditionals
> and loops, at all. Because you're using more-succinct tools like
> match, map, fold, etc.

Amen.  I don't have any data on professional programmers, but my observation from watching students is that imperatively-trained students write long functions that do several different jobs, with I/O and computation all jumbled up, while functionally-trained students write short functions that do exactly one, clearly defined job.

Have you ever read Leo Brodie's _Thinking Forth_?  The examples are in the Forth language, but it's really about principles of good programming, and one of them is "avoid flow-of-control constructs."  Which he acknowledges one can't do entirely, but one can do it more often than one expects, and in particular one can almost always avoid NESTED flow-of-control constructs, using only one per function.


Stephen Bloch
sbloch at adelphi.edu