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

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/6962a624/attachment.html>