I do agree with you that such processes do exist and it can be formalized and studied, and anyone who is willing to put in the effort and persistence to study programming will be able to become competent - everyone has the problem solving gene. <br> <br>What I would caution against is that there are many out there who would look at that and say programming can be reduced to a set of processes that anyone can read and follow and thus programming can be commoditized/eliminated. <br> <br>The issue isn't whether programming is art or science, but that like any non-trivial human endeavors, it is a skill, and it takes time and dedication to learn and master the ever-growing list of tools/techniques/patterns to the point where one can use them competently to solve problems. That's craft. There is no other way to achieve mastery. <br> <br>What should/can teachers do? I would guess it is to increase the potential that the student will muster enough interest, motivation, and will power so they will push through the inevitable growing pain that would come with achieving mastery, and supply them with the tools. Beyond that it's all up to the students; give them the red pill but they will still have to take it and see how deep the rabbit hole goes themselves. <br> <br>My 0.02 cents. <br>yc<br><br><div class="gmail_quote">On Wed, Feb 10, 2010 at 5:18 PM, Doug Williams <span dir="ltr"><<a href="mailto:m.douglas.williams@gmail.com">m.douglas.williams@gmail.com</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;">I'm as concise on this as Brett Farve is on retiring. Every human endeavour can have creative elements to it and associated process elements. All programmers have (internal) processes that somehow build internal models of problems, form data abstractions, develop control flows to manipulate the data abstractions in accordance with their internal models, etc. Most programmers do those things without thinking about the processes -- and often denying that such processes even exist. Those are the ones who claim it's an innate ability. I believe those process do exist and, at a minimum, can be discussed and formalized. I am not an HTDP expert by any means -- although I did buy the book, Matthias -- but I see that as an attempt to do that formalization (for certain classes of problems) as design patterns. Over time, I think we will see that mechanization pushed more toward to the abstract problem statement and further from the concrete language syntax. At that point we will be able to teach people the process of problem abstraction (the creative/thinking part of programming) and not worry (much) about the mechanical process of converting that into some executable form (the mundane part of programming).<br> <br>So, I have the 'programmer's gene' and I am pretty good at programming. I do not know how to mechanize much of what I do as a programmer. I do believe many elements of what I do can be formalized. I believe that HTDP is the start of that formalization (for some classes of problems) with the manual conversion to Scheme code. [I see the goal of HTDP as being able to teach anybody how to perform that process of converting some abstract problem description to Scheme code -- i.e., how to program.] That is where I think we are today.<br> <br>The person who wrote "The Programmer's Stone" has an interesting view and I pointed to it primarily for historical reasons -- it was discussed to death two decades ago. I actually like the basic mapper/packer distinction in some fashion, but I look at that as describing two classes of mental processes that people may use. They're still processes that can be discussed and, hopefully, understood, formalized, and potentially mechanized.<br> <br>So, yes I'm going to retire after this year. I feel pretty beat up after that New Orleans game. Well, you know Arizona does have nicer winter weather than Green Bay, I mean Minnesota ... <br><br>Doug (Wishy-Washy) Williams<div> <div></div><div class="h5"><br> <br><div class="gmail_quote">On Wed, Feb 10, 2010 at 4:37 PM, YC <span dir="ltr"><<a href="mailto:yinso.chen@gmail.com" target="_blank">yinso.chen@gmail.com</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;"> <br> <div class="gmail_quote"><div>On Wed, Feb 10, 2010 at 12:49 PM, Doug Williams <span dir="ltr"><<a href="mailto:m.douglas.williams@gmail.com" target="_blank">m.douglas.williams@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">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" target="_blank">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/" target="_blank">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.</blockquote> <div> </div> </div><div>I am a bit unclear whether you are saying programming is an art/science, or that you are saying that we can have a scientific method toward teaching programming. As the links you cited (mappers vs packers) sits in the camp of programming being a heavily intellectual and creative activity that aren't easily duplicated by coming up with and following more ever more complex processes. </div> <div> </div> <div>Cheers,</div> <div>yc</div> <div> </div> <div> </div></div> </blockquote></div><br> </div></div></blockquote></div><br>