Thank you. I am not technically sufficient to add much to your response. Will the core curriculum become available online?
Your criticism of SICP's use of recursion seems to extend to the method for teaching recursion principles in The Little Schemer series, in that it does just that - teaches principles of (a form of) recursion as an intellectual exercise without translating it into actual program design methods. My own experience with The Little Schemer began to falter in Chapter 5. I felt I understood how recursion worked and how to create simple recursive functions and wondered if, by stalling in Chapter 5, I demonstrated a lack of drive or intellectual ability necessary to learn how to program well. After reading some of your articles I am discovering that perhaps neither of my tentative conclusions were necessarily accurate. Your other criticisms mirror my (no doubt common) experiences: on one hand there are the massive online courses and endless textbooks which tend to amount to nothing more than intros to syntax how-tos and seem to be just a form of data entry. (and now I think perhaps I understand why: syntax without API is just keyboarding and hitting enter. But that is what these courses are about so I completely get the point of the prologue!) Then on the other hand are the curriculum which, like MIT, have me thinking that programming well requires an engineering degree, at least, or is just a subset of engineering. Such has been my experience. On Wednesday, August 1, 2018 at 2:52:55 PM UTC-4, Scott wrote: > > The end of the Prologue to HtDP2e ends with a section titled You Are a > Programmer Now. If you have read it you know what it contains (if you > haven't read it then you are not likely able to respond intelligently to > this question). > > My question is: in that section are the authors describing "programming by > poking"? > On Wednesday, August 1, 2018 at 5:54:14 PM UTC-4, Matthias Felleisen wrote: > > > The idea that we need to deal with software systems as if we were natural > scientists shows up time and again. Gerry is correct about this but this > does not mean we should not teach good attitudes about code and coding etc. > > ;; - - - > > As far as I am concerned, SiCP never served the purpose that Gerry > advertises in his quote. Let me start out by praising SiCP first: > > it is one of those introductory texts that does not belong to the > 99.99% of the syntax-focused pile of XXX. > > Having said that, I also don’t think that SiCP teaches (or 6.001 taught) > programming or sw dev. SiCP presents important ideas in computer science, > sketched out in Scheme, the way you sketch out your dream house to an > architect on a napkin. (Well perhaps more than a napkin.) As such, it was > doomed to fail as a “programming text”. > > HtDP explicitly teaches systematic program design. This means two things: > > — its goal is to teach systematic program design > — and it does so by explicitly spelling out how to go about > program design. > > All of this is spelled out in some detail in > https://www2.ccs.neu.edu/racket/pubs/#jfp2004-fffk > > ;; - - - > > One semester does not make good coders and does not generate good > attitudes about code. I have therefore created a core curriculum of five > courses at Northeastern that reinforce this lesson again and again. The > goal is to get students to see that, if code survives, the cost of code is > distributed over a long period of time. They will rotate into positions > where they take on someone else’s code — possibly their own from N months > or years ago — and that when they create code, they owe the future > developers “well designed code.” How to go from a blank page and a bunch of > APIs to well-designed code isn’t a solved problem, so creating this > curriculum was and remains research — it’s just that nobody recognizes that > this is a central open problem for CS. So I dress up my research results as > text books. > > The details of this curriculum development are spelled out in > http://felleisen.org/matthias/Thoughts/Developing_Developers.html > > From what I can tell, the curriculum is a success story — though possibly > I am a victim of confirmation bias here, like many scientists. So let me > say what I see: > > — our co-op department routinely reports that our students are > considered some of the best student-developers by (large) sw companies > (our co-op department isn’t all that good about tracking > our co-op students in small or midsize companies) > > — students routinely tell me that they get through co-op > interviews by falling back on the design recipe when they encounter hard > questions > > — they also tell me that they get credit when they work with the > design recipe during co-op (even if things don’t work out) > > — they report praise for developing good code. > > For all I know though, all those who don’t report to me (or aren’t covered > by our co-op reports) produce the same kind of bad code that all other devs > develop :-) > > ;; - - - > > Here is what’s missing. In a world where APIs are like hardware > (proprietary, opaque) we need to teach students how to study such APIs and > how to extract useful knowledge from these APIs. Again, most schools who > switch to this new MIT approach don’t teach this explicitly. They do not > provide students with the intellectual tools that help them discover the > meaning of an API. I will also admit that I am _not_ tackling this > question. As far as I know Shriram Krishnamurthi is the only one who is > aware of and working on this question for API = PL. (See his PLAI v2.0 > course at Brown.) > > ;; - - - > > So in the meantime, I am happy to teach our students systematic design and > instill a message of “code quality matters”. I think it helps them get > started in many cases. > > When someone figures out how to deliver the tools of “programming/sw dev > is partly a natural science” to students, then I* will be able to combine > “systematic design” with “API modeling” approaches and we will produce the > best devs ever. > > Your milage will vary, but I won’t give up on teaching good programming > well — Matthias > > > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
