[plt-scheme] Re: Scheme sources readability

As for GOF patterns, which is what you asked about, please read up on  
the extensive literature. 20 out of 23 GOF patterns aren't macros;  
they have been features in Scheme and LISP for the past 30 years.

As for reading code, I am sorry my brain isn't an algorithm. And I  
dont really have time to explain these things but here is a snippet  
of a function I wrote last week why Scheme code is readable and how  
it's written. Copy it into drscheme, remove the obviously unnecessary  
line breaks introduced by your mail client, and read it.

(BTW, can you imagine ANYONE using the phrase "obviously unnecessary"  
for Java code?)

-- Matthias


;;  
------------------------------------------------------------------------ 
-----
;; Ball Paddle -> Ball
;; compute the point to where the ball travels in one tick, bouncing  
off walls
;; and the stationary horizontal paddle in the middle.

(define P0 (make-posn 0 0))
(define speed0 (+ CNTR 10))

;; hit left only
(check-expect (ball-move (make-ball 10 10 -15 0) P0)
               (make-ball 5 10 +15 0))

;; hit right only
(check-expect (ball-move (make-ball (- SIZE 10) 10 +15 0) P0)
               (make-ball (- SIZE 5) 10 -15 0))

;; hit bottom left corner
(check-within (ball-move (make-ball CNTR CNTR (- speed0) speed0) P0)
               (make-ball 10 (- SIZE 10) speed0 (- speed0)) .1)

;; hit bottom right corner
(check-within (ball-move (make-ball CNTR CNTR speed0 speed0) P0)
               (make-ball (- SIZE 10) (- SIZE 10) (- speed0) (- speed0))
               .1)

;; hit paddle in right corner
(check-within (ball-move (make-ball (- SIZE 1) (- SIZE 1) 1 1)
                          (make-posn SIZE SIZE))
               (make-ball SIZE SIZE 1 -1)
               .1)

;; double bounce: reach bottom first:
;; -- (make-ball (- SIZE 25) SIZE         100 -100) for delta = .25
;; -- (make-ball 0           (- SIZE 25) -100 -100) delta = .25
;; -- (make-ball (- SIZE 50) (- SIZE 75) -100 -100) for delta = .50
(check-within (ball-move (make-ball (- SIZE 50) (- SIZE 25) 100 100) P0)
               (make-ball (- SIZE 50.) (- SIZE 75.) -100 -100) .1)

;; running out of time after bounce
(check-within (ball-move (make-ball (- SIZE 50) 10 50.01 0) P0)
               (make-ball SIZE 10 -50.01 0)
               .1)

;; escape through top
(check-expect (ball? (ball-move (make-ball 10 10 0 -20) P0)) true)

(define P1 (make-posn 10 15))

;; hit paddle from top
(check-within (ball-move (make-ball 10 10 10 10) P1)
               (ball-straight (make-ball 15 15 10 -10) .5)
               .1)

;; hit paddle from bottom
(check-within (ball-move (make-ball 10 20 10 -10) P1)
               (ball-straight (make-ball 15 15 10 10) .5)
               .1)

;; hit goal
(check-within (ball-move (make-ball LGOAL (- SIZE 5) 0 5) P1)
               (ball-straight (make-ball LGOAL (- SIZE 5) 0 5) 2.)
               .1)



(define (ball-move b0 p)
   (local ((define speed (ball->speed b0))
           ;; Time Ball -> Ball
           ;; ball : accumulates the movement for 1.0 - delta
           (define (ball-move delta b)
             (local ((define (move-and-recur hit-location)
                       (ball-move (- delta (/ (distance-traveled b  
hit-location)
                                              speed))
                                  hit-location)))
               (cond
                 [(<= delta 0.01) b]
                 [(thru-top? b delta) (ball-drop 'go)]
                 [(hits-pad-top? b p delta)
                  (move-and-recur (bounce-pad-top b p delta))]
                 [(hits-pad-bot? b p delta)
                  (move-and-recur (bounce-pad-bot b p delta))]
                 [(hits-lft? b delta)
                  (if (hits-bot? b delta)
                      (move-and-recur (bounce-diagonal b delta))
                      (move-and-recur (bounce-lft b delta)))]
                 [(hits-rgt? b delta)
                  (if (hits-bot? b delta)
                      (move-and-recur (bounce-diagonal b delta))
                      (move-and-recur (bounce-rgt b delta)))]
                 [(hits-bot? b delta)
                  (if (hits-goal? b delta)
                      (ball-straight b (* 2 delta))
                      (move-and-recur (bounce-bot b delta)))]
                 [else (ball-straight b delta)]))))
     (ball-move 1.0 b0)))





On Sep 7, 2008, at 12:59 PM, kbohdan at mail.ru wrote:

> Matthias Felleisen wrote:
>
>>> After many years of programming i found new-old
>>> scheme world very fascinating. One thing i still
>>> do not like here is source code readability.
>> Code in Scheme tends to be 1/4 or 1/3 of the size of Java.
>> The indentation structure is far more revealing than there.
>> So I find it as readable as Java or better. You could argue
>> CL is better, I wouldn't respond then.
>
> Yes, agree code size is much smaller, but i'm still not sure
> if it helps me to read it.
> Lets compare with Java: If i see class names like XxxAdapter,
> XxxVisitor, XxxFSM, XxxModel/XxxView/XxxController it only takes
> a seconds to understand what is going on. Can you take any
> non-trivial snippet from DrScheme collects to demonstrate your
> algorithm of code reading?
>
>>> What about docstrings,
>> We consider Help Desk a priority because its linked way
>> of doing docs is superior. As my PhD advisor used to say,
>> a program (he meant module) is only worth writing if you
>> also write a paper about it (he meant documentation).
>
>   "Help Desk" helps me to understand public interface, but
> it doesn't help me too much to understand implementation.
> From your point of view nobody guarantee that it should be
> easy for third person to understand even interface of private
> module not even saying about its implementation. IMHO, this
> is not the case for commercial software development.
>
>>> design patterns (like GoF),
>> The design patterns of GOF were invented to address
>> weaknesses in Java and C++'s expressiveness when compared
>> to Scheme and LISP. Plus, when we discover a "pattern", we
>> just turn it into a construct via syntactic extensions.
>
>   Design patterns (DP) were invented by architect not by programmers.
> In programming DP are addressing history proven successful code
> patterns used both in coding and understanding source code.
> Despite the fact that i can implement most of patterns as macros
> doesn't mean that scheme community should not pay attention on
> architecture and force all starting scheme programmers to
> invent the bike.
>
>
>>> coding conventions. Are those non-applicable to scheme ?
>> Much higher-level coding conventions are applicable. But
>> yes I admit this takes training.
>>> Or scheme evolution is still on its early stages ?
>> Yes it is in its early stages. Fortunately, because it means
>> we have research left to do. Also fortunately, Scheme has far
>> outpaced Java and friends.
>> -- Matthias
>
> --
> Bohdan
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme