<div dir="ltr"><br><br><div class="gmail_quote">On Tue, Aug 12, 2008 at 3:25 PM, Bill <span dir="ltr"><<a href="mailto:william.wood3@comcast.net">william.wood3@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Tue, 2008-08-12 at 15:09 -0400, Matthias Felleisen wrote:<br>
> P.S. David, I appreciate your Navy experience. I was a paratrooper<br>
> myself. What distinguishes this situation so much from the one in<br>
> school and college is that your life depends on learning and<br>
> performing well. (We lost 10-20% of the "students" in paratrooping<br>
> school due to accidents, some really really bad. Nobody died.)<br>
<br>
</div></div>I think the nature of the subject matter is relevant here. Matthias'<br>
point is valid when considering jumping out of "perfectly good"<br>
airplanes, but the sight of a manual presenting Ohm's Law with the<br>
preface "The material in this document conforms to Department of the<br>
Army doctrine" gives one pause -- suppose it didn't; would they repeal<br>
the laws of nature? My training as an electronics technician was fast<br>
and thorough in some sense, but it gave me first-hand experience of the<br>
difference between "education" and "training".<br>
<br>
</blockquote></div>Of course, all the military wants is someone that can efficiently and reliably maintain and repair their ever growing pile of complicated toys. The important part of the basic electronics was not learning things like Ohm's law, or how waveguides worked[1], the important part was learning the process of <br>
<br>1) Recognizing and understanding the problem, <br>2) Collecting more detailed data to isolate the problem to the appropriate part.<br>3) Finally, whacking the appropriate part with a 12" crescent wrench.<br><br>These steps pretty much reflect a HTDPish appraoch to writing programs which I will paraphrase as<br>
<br>1) Understanding and describing the problem, writing test cases, making an initial template of functions and classes.<br>2) Breaking the problem into more detailed classes and functions.<br>3) Writing the code to fill in the functions and classes.<br>
<br>The problem that I see with K-12 computer education is that they concentrate on step 3 in silly overcomplicated languages like java, maybe occasionally touching on step 2, and totally ignoring step 1 (and then they wonder why their students are confused).<br>
<br>Step 1 would be simple if students had an adequate mathematics education (see <a href="http://www.de.ufpe.br/~toom/articles/engeduc/index.htm">http://www.de.ufpe.br/~toom/articles/engeduc/index.htm</a> [2]), but unfortunately they don't.<br>
<br>I believe that if they want to change K-12 computer science education, they are more likely to succeed if they circumvent the educational establishment than if they try to confront it.<br><br>The point that I was trying to make is that the military manages to teach precisely the problem solving skills that HTDP endeavors to with minimal human intervention. Whatever instructors we had were esentially equivalent to us, just four years or so older and hapless enough to reenlist. <br>
<br>I do not think that programming per se is or needs to be a particularly difficult endeavor. With a scant few exceptions, we are not engineers or scientists, we are file clerks, heirs to the world of Bob Cratchit and Bartelby. There is nothing wrong with that. The job needs doing, and it deserves to be done well. Judging from the scope and nature of the software disasters we are lacking even in competent file clerks.<br>
<br>[1] On the subject of waveguides we were all but lied to, but the knowlege we recieved was sufficient for us to muddle through.<br>[2] These are by Andrei Toom of Toom-Cook fame. Yes, it sometimes appears that he has an axe to grind, but his points on the complete lack of problem solving in american K-12 education appear valid from where I sit.<br>
<br></div>