isn't everyone?
as some one that worked for years as a trainer at a tech commercial training company, i eventually came up with two sort of realisations:
a) teaching HOW to program is really, really hard. i was never at all good at it, though i could teach programming languages and system architectures rather well.
b) when you start out, you cannot write too many functions.
i'm not sure that the book in question would entirely agree with this. any course using it for teaching would need lots of input from the physical human instructor.
…
a) teaching HOW to program is really, really hard. i was never at all good at it, though i could teach programming languages and system architectures rather well.
It really is a way of thinking. It takes deliberate practice to develop. Students are often uninterested in developing this kind of soft skill set because it doesn’t provide immediate returns when it comes to finishing assignments.
It’s a real shame. In the long run it pays huge dividends.
The specific concepts in the book translate to other functional programming languages, and almost not at all to imperative programming.
The general thesis of the book, that you should follow a design recipe, is a universal one. It teaches you how to design your functions and write the documentation before you begin the implementation. This is also the part that students are the worst at, in my experience (as a TA for a first year course based on this book, twice).