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.
