[plt-scheme] Re: HTDP - evidently not for everyone.

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.

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.

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.

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.

My 0.02 cents.
yc

On Wed, Feb 10, 2010 at 5:18 PM, Doug Williams <m.douglas.williams at gmail.com
> wrote:

> 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).
>
> 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.
>
> 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.
>
> 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 ...
>
> Doug (Wishy-Washy) Williams
>
>
> On Wed, Feb 10, 2010 at 4:37 PM, YC <yinso.chen at gmail.com> wrote:
>
>>
>> On Wed, Feb 10, 2010 at 12:49 PM, Doug Williams <
>> m.douglas.williams at gmail.com> wrote:
>>
>>> 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 http://www.the-programmers-stone.com/about and
>>> 'the meat' seems to start at
>>> http://the-programmers-stone.com/the-original-talks/day-1-thinking-about-thinking/-- I'll let you draw your own conclusions about the material.
>>>
>>> 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.
>>
>>
>> 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.
>>
>> Cheers,
>> yc
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20100210/b7a81c81/attachment.html>