Does anyone have a PDF of this?
s/PDF/epub?
How to Design Programs, Second Edition
21–28 of 28 posts
Re: How to Design Programs, Second Edition
#22What 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.
Re: How to Design Programs, Second Edition
#23if 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.
Re: How to Design Programs, Second Edition
#24Eesh 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.
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.
Re: How to Design Programs, Second Edition
#25Earlier quoted context omitted.
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…
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
Re: How to Design Programs, Second Edition
#26Earlier quoted context omitted.
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 gett…
I agree with everything you just said.
Re: How to Design Programs, Second Edition
#27Interesting, 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.
(do-something (create-something height width7))
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.Re: How to Design Programs, Second Edition
#28Eesh 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 Sche…
Are these two different issues or one?