[racket] syntax, differently

I think that's a very good point. Racket encourages students
(correctly, I think) to create fairly complex expressions. The same is
true in Java, but the syntax convinces you that a single if { ... }
else if { ... } else { ... } isn't really a single expression and
fakes you out by having you write little one-line statements in the
... areas. Because Racket expressions are often multi-lined
monstrosities, students make messes of them.

There are a couple of things we could do to help with the underlying
cause. I've been looking at OCaml recently, and the construct they
have for copying and updating a record is something that maybe Racket
could use. Something like (update my-struct (<- a-field new-val) ...)
might make things less nasty to write. (Of course, since structs don't
maintain a list of their field names, this would be a pain to code
up.)

I'd also like to push for earlier introduction of (local ...) in
HtDP/2e. We all know that code duplication is a bad thing and that
giving complex constructs names is one of the easiest forms of
abstraction, but we can't use local definitions to handle these cases
until we've already done a lot of really complicated stuff. I'd like
to be able to contrast:

(define (distance p1 p2)
  (sqrt (+ (sqr (- (posn-x p1) (posn-x p2)))
           (sqr (- (posn-y p1) (posn-y p2))))))

and

(define (distance p1 p2)
  (local
    [(define x1 (posn-x p1))
     (define y1 (posn-y p1))
     (define x2 (posn-x p2))
     (define y2 (posn-y p2))]
    (sqrt (+ (sqr (- x1 x2)) (sqr (- y1 y2))))))

fairly early, so that I can emphasize that, while the first has fewer
keystrokes, the latter is easier for most people to read.

To weigh in on the points in debate:

1. Auto-wrap at eighty characters in student languages would be
lovely. Since comment boxes cut off the right hand side when printed,
I sometimes lose code that's not working when my students print their
assignments. In addition, even nicely indented code is hard to read
when it's printed if the lines are too long. Have a check-box if
people really want to turn the feature off, but it should be the
default in the student languages.

2. Auto-indenting code on Run strikes me as not a bad idea. Since the
first thing I have to do when I try to help a student who's just hit
Run and gotten a weird error is to auto-indent the code anyway, it
seems like doing it when they think the code is ready shouldn't screw
things up too badly. Again, just for the student languages and with a
check-box to turn it off for idiosyncratic indenters like Eli. :-)

Todd

On Sun, Aug 1, 2010 at 2:44 PM, Mathew Kurian <bluejamesbond at gmail.com> wrote:
> Matthias Felleisen: "What do you mean with that? When I have students write
> large programs, my Racket programs are routinely a factor of 3 or more
> shorter than those of the best of my students (5Kloc in Racket vs 15Kloc in
> Java or C# or C++), tend to perform more tasks, and are more stable."
> Reply: I apologize for not being more precise with my statement and what i
> meant was slightly different. Students, like myself, and especially those in
> the beginning of their programming career have challenges optimizing the
> code. So what most students would like to do (i have had to help many at my
> school with their code and have seen this directly) is actually write
> whatever they can to make the program work. For instance, they write a
> program with over 100 lines of code which actually only requires 50 lines of
> code. In both cases, the program works, although optimization is overlooked
> in the former case. Then realizing that their code is actually too long and
> too hard to work with, these same kids go back and edit their code, cutting
> down the number of lines in order to increase both optimization and ease of
> program growth.
> My statement: "it is important for students to be able to keep the code very
> neat."
> Matthias Felleisen' Reply to the above statement: That is true in all
> languages, period.
> Reply: I agree with Matthias in this case if one is not coding with
> universe/world teachpacks. The basic Racket including the gui components and
> the other basic components look very clean and easy to understand in a large
> program. Usually these codes, like Matthias said, can be put in sets maxing
> at 3 lines, and is very neat and easy to read to a third-party. However, in
> the case of universe/world teachpacks, where the use of states is a vital
> component, a set of code can get very long, especially if the program is
> very complex and contains multiple structures (in some cases structures
> inside structures inside structures) within the states. With that said, I
> was trying to emphasize that it may be harder to students to keep their code
> neater compared to some other languages which usually have code that rarely
> exceed 1 line.
> Example:
> Racket using the universe teachpack:
> (define (s-mouse-engine s x y event)
>   (cond
>     [(and
>       (and (> x 248)           (< x 424))
>       (and (> y 570)           (< y 649)))
>         (make-S-STATE
>          (get-s-background s)                ;;I have made methods here to
> reduce length, but other wise it would be longer.
>          (make-button
>           (s-mouse-engine-worker1 event "button-img")
>           (get-s-button-x s)                   ;;I have made methods here to
> reduce length, but other wise it would be longer.
>           (get-s-button-y s)                   ;;I have made methods here to
> reduce length, but other wise it would be longer.
>           (s-mouse-engine-worker1 event "button-initiate")))]
> I hope I have clarified any of the questions and i will try to put a mock-up
> of what i am talking about in my previous comment.
> PS: I am sorry for my error in the statement about drracket compilation.
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>