[theemptiness]

I was fortunate enough to encounter this book in a first-year programming course (Informatik, RWTH Aachen). The years before, they had used Modula-3 and in the years afterwards they switched to Java.

While it certainly changed my life - first encounter with functional programming - and I will always appreciate it, it is now 23 years later and I think it is time to acknowledge some shortcomings.

The thing that comes to my mind first is the lack of any discussion pertaining to coding against interfaces, with components (and their interfaces) evolving over time.

Data abstraction gets discussed very early on, but the evolution of interfaces, its twin sister topic, does not get much air time. This is a pity since the goal of data abstraction (avoiding making assumptions on data representation) is pretty much the same, being able to change things later when the need arises.

[yomly]

There is an exercise - 2.29 where you implement a tree-like structure of objects.

Part d of the question is:

" d. Suppose we change the representation of mobiles so that the constructors are

(define (make-mobile left right) (cons left right)) (define (make-branch length structure) (cons length structure))

How much do you need to change your programs to convert to the new representation? "

It may not be discussed in depth - I suspect they decided it was out of scope for the book, but they were definitely thinking about it...

[zelphirkalt]

Actually I think interfaces are discussed in Chapter 2, when you write "packages".

What bugged me more about that part is, that no code is given for running solutions to the exercises. I know there is a "framework" online somewhere, written in Racket, but it would be nice to have it in Scheme instead, in a very large part portable to many Scheme dialects.