How to Design Programs, Second Edition
ccs.neu.eduEveryone,
if you don't have time to read the book, do read the sections with 'design' in their title. Compare with Josh Bloch's apologia for the Java API and then ponder why HtDP[2e] preps readers for OOP anyway. I will try to clarify in HtDComponents (forthcoming, eventually, if I live long enough) and HtDSystems (ditto).
I chose small languages -- rejecting powerful Racket features such as define-datatype and pattern matching -- precisely so that the thinking reader and student would be able to adapt the design recipe to almost any language, but especially the popular "scripting languages", the wanna-be Lisps.
Once you program long enough, the design recipe will become second nature and you won't notice it anymore. Well, until some "guru" coins a slogan for some aspect of it -- say TDD or Extreme Programming -- and you think "I have seen this before, I just can't recall where." Conversely, I think I have extracted what experienced programmers taught me about programming and what has been at their and my finger tips for a long time.
If it helps some, great. If others know it all better, fine.
-- Matthias, at it since 1984
p.s. If the first sentence seems juvenile, you haven't been to a physical book store in a while. When I see those books disappear, the sentence will disappear too. In the meantime, I stand by its essence.
From my cursory glance at the book, I always felt the title was misleading. It is more a general introduction to programming through Scheme, with a focus on good practice than a treatise on software architecture.
HtDP, unlike SICP, begins with a purely functional subset of Scheme, BSL (Beginning Student Language). While this obviously means students will learn Scheme from the course, the purpose is to remove syntax and imperative programming from the equation - there is no set! and no macros. There is not even (list...) or lambda or closures or local functions.[1]
In short, BSL is pretty neutral from a language holy war standpoint. Which is not to say that those who self-select to engage with the book as teachers and students are not likely to be somewhat biased toward the Lisp camp - clean syntax and functional style programming are standard arguments in favor of Lisp in language wars.
The other distinction of HtDP is that is definitely not OOP based. The analog in terms of pedagogy might be MIX - there are certain ideas which it is desirable for the language to expose, and OOP hides a lot of those things.
[1] O.K. There is lambda in BSL, actually. But it can only be used in the body of a function definition like this:
Outside this (define...) form, lambda is not allowed in BSL.(define (foo x) (lambda (x) (* 1 x)))
As a student having gone through a class for introductory programming with this book (1st addition), I can say this was the best way to get into programming, and the lessons in here lead to a beautiful understanding of computer programming.
I think Coursera Systematic Program Design is largely based on HtDP, if so, I agree it's one of the most balanced introduction to programming, where their definition of programming is more thinking through the problem instead of writing LoC or learning syntax. All this without complex problems (whereas SICP first chapters can drive non-math lovers away)
The course is based on the general principles which underlay HtDP. But HtDP is Matthies Felliesen's particular approach, and Gregor Kiczales (CLOS, Aspect Oriented Programming, The Meta-Object Protocol) has his own points of emphasis.
What both share is a general approach to programming pedagogy - that of the larger Racket community. It includes starting with a simple functional language, BSL, in order to avoid getting hung up on language syntax and to provide better error messages during debugging. BSL prevents FORTRAN in any languages, everything has to be functional. Because it only has
But notcons
BSL programs tend to make structure explicit - don't worry, list is added when appropriate.listAt first this seems like a lot more training wheels than necessary, but it allows the course to focus on writing signatures, descriptions, and templates in the first weeks, and pays off handsomely when the material hits recursion - there were very few questions about it in the forums, and the answer when those who couldn't picture it felt stuck was, for now just trust the template.
The big idea of the course is to teach a design method. It does so by looking at recursive algorithms and presenting recipes for applying them. The second theme is functional style programming - and it is dictated by necessity. The third theme is model-view-controller through Racket's "worlds".
I've taken a lot away from it, your milage may vary.
I agree with everything you just said.
Then you are doing it wrong.
Yeah, I went through the Coursera course. Honestly, it was amazing. I had read through several programming books, but this was systematic. The "design recipes" help you to write clean, testable functions, and to think about your design before you start typing. I actually found it to be one of the best introductions to programming in Haskell. I had read 'Learn You A Haskell', and 'Real World Haskell' but this course made the whole approach to types, and pure functions really click.
I remember two times where learning a language that didn't embed the full paradigm (ADA objects) made me understand it better (Class OOP as in Java), the other one was monads in emacs lisp, so I think I understand your point.
The design recipes felt a little bit dull at first, but for a newcomer it's probably the good rhythm anyway. And now I often 'construct' my function through stubs, tests and then full code. Kudos to the authors.
Interesting, I like the use of arrows used to explain scope in section 7.
It's actually used in Dr Racket. Although to be honest, I don't find that I use it very often. It's still a nice feature to have - for example to see where arguments are used inside a scope block and where values leak into scope e.g. when mis-typing a name.
Arrows are also useful while studding unknown code. For example, if the code is
I use the arrows to connect the appearances of the unknown functions do-something and create-something with their definition and then read the definitions, and perhaps add more arrows there to previously defined functions. I usually remove the arrows when I understand that the function is not related to my problem or when I understand what the function does.(do-something (create-something height width7))
Is second edition complete?
>Is second edition complete?
Chapters 9-12 are still empty in the stable release, and only partially done in the draft version.
http://www.ccs.neu.edu/home/matthias/HtDP2e/Draft/index.html
Does anyone have a PDF of this?
s/PDF/epub?
Calibre does a decent job converting HTML into ePub, if you download all the pages, though sometimes the navigation on every page can get annoying.
why do words like 'idiots' and 'dummies' need to be on the first page.
They are referring to the Dummies Guide and other books that claim you can learn to program in a very short period of time.
Yes, the three italicized words/phrases are references to the names of popular programming book series:
Programming for Dummies: http://www.dummies.com/store/Computers-Internet/Programming....
Sams Teach Yourself X in 21 Days: http://www.informit.com/search/index.aspx?query=21+days
The Complete Idiot's Guide to X: e.g. http://www.help4web.net/webmaster/Java/NewJS/JavaScriptIdiot...
Maybe those series are no longer as well known as they used to be? They were household names in the '90s and everyone would've gotten the references, but it's possible they're now dated and better removed from the intro.
[Self-response]
The draft version (linked by edmccard in another comment) now has a brief explanation in the margin note that these are references to programming books: http://www.ccs.neu.edu/home/matthias/HtDP2e/Draft/index.html
Agreed, it adds nothing and makes the authors seem juvenile. I am not someone sensitive to language either, if it added value I would be open to the most vile introduction imaginable.
Eesh
What a horrible title. This is a book about how to program in scheme, not how to design programs. Nothing on architecture or common patterns. Nothing on how to abstract a domain or analyze a problem. Just solutions for common programming a tasks.
Not knocking it but its far from design.
HtDP is all about a particularly useful common pattern, recursion and a fairly useful practice, unit testing. It is also somewhat about a fairly useful pattern, templating. Finally, it takes an unpopular stance on a religious issue and asserts that programs should be documented.
The choice of Scheme, makes getting to recursion easier, and allows for it to be free of arguments regarding language idioms - i.e. the Scheme dialect, BSL does not allow iterative looping (Scheme of course does).
The Racketeers have spent careers looking at the process of teaching languages.
>Finally, it takes an unpopular stance on a religious issue and asserts that programs should be documented.
Are these two different issues or one?