I generally stay out of the academic discussions, but this one reminds me a lot of the old discussions that would crop up about "The Programmer's Stone" white paper years ago. I wasn't able to find the original white paper in a quick search, but the (I assume original) author has a blog with what seems to be the same material repackaged and possibly/probably revised. It seems the history is at <a href="http://www.the-programmers-stone.com/about">http://www.the-programmers-stone.com/about</a> and 'the meat' seems to start at <a href="http://the-programmers-stone.com/the-original-talks/day-1-thinking-about-thinking/">http://the-programmers-stone.com/the-original-talks/day-1-thinking-about-thinking/</a> -- I'll let you draw your own conclusions about the material.<br>
<br>I guess my own view is that programming (e.g., methodologies, languages, tools, etc) has been defined by people who 'are good at it'. Unfortunately, we also tend to lack the introspective ability to know why we are 'good at it' or really even how we do it. Because of this, many people believe that it is an art -- with some kind of innate ability associated with it -- rather than a science or engineering discipline based on processes that can be taught successfully. I applaud the efforts of those people who are tying to do the latter.<br>
<br>I would also offer from my previous academic experience and numerous short courses taught to government and industry that (within the current programming framework) I am generally guilty of grouping potential developers into three groups: a minority that really get it and enjoy it (the ones we all want to teach/hire); a majority that get it but wonder why anyone would want to program (the untapped potential); and those that really don't get it (which may be as much lack of motivation due to the 'why would I ever want to' factor). While the people in the first group may do the vast majority of the actual development of software, the others are as often as not the ones with the ideas that need to be encoded in the resulting applications.<br>
<br>Unfortunately, programming is often defined by the languages, tools, and techniques that programmers use. Industry expects academia to give them individuals with exactly those skills. So we perpetuate the schism between 'programmers' and 'everyone else'.<br>
<br>Doug<br><br><div class="gmail_quote">On Wed, Feb 10, 2010 at 12:44 PM, Shriram Krishnamurthi <span dir="ltr"><<a href="mailto:sk@cs.brown.edu">sk@cs.brown.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">> I don't think it is fair to extrapolate the argument to any X.<br>
<br>
</div>I don't see much in their argument that is CS-specific. Hence I<br>
*speculated* that it might be possible to extrapolate.<br>
<div class="im"><br>
> The argument is that programming ability is a naturally occurring<br>
> attribute that humans either possess or don't, hence the appropriate<br>
> comparison would be with some other naturally occurring human<br>
> attribute rather than one, like spelling or reading that are skills<br>
> generally acquired through teaching.<br>
<br>
</div>This phrasing reminds me a great deal of the behavioral psychology<br>
work of Carol Dweck, which aims to address (and show as ill-founded)<br>
precisely such opinions. I find her work quite compelling, and indeed<br>
it has been influential in the way I've re-thought my teaching style.<br>
<font color="#888888"><br>
Shriram<br>
</font><div><div></div><div class="h5">_________________________________________________<br>
For list-related administrative tasks:<br>
<a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a><br>
</div></div></blockquote></div><br>