Re: [9fans] Re: the 'science' in computer scienscience

Re: [9fans] Re: the 'science' in computer scienscience

[presotto]

> Anyway, how do you teach someone to think?  I have no idea; your
> suggestions are a good first step, but it seems that the `proper mind
> set' outcome is a side effect of exposure with that method; is there a
> way to directly target the thought process?

It was imbred in me by a Latin teacher whose key phrase was
``why use two when one will do''.  The immediate application
was to avoid flowery language but it the rule applies in general.

With programming, constraints that helped.  I inherited
a course at Princeton from Rob.  The thing I liked the best about
it was an assignment he gave to write a shell.  The constraint was
in the size of the shell.  We said what it was supposed to do (no
job control) and took points off for programs exceeding the size
limits.  I reviewed the best solutions with the students.

But when it comes down to it, the real challenge is imparting some
flavor of your taste to the students by example or by the application
of grades.  Some rules help, as long as you can get them to understand
that the rules are guidelines and not hard.  If you're lucky you can
do it in such a way that doesn't cramp originality on their part.

I've also found it useful to review Plan 9 code and Unix code with
them.  That way they can see different solutions for the same
problems.  I actually find things like the toy operating system
more harmful than helpful.  They come away understanding some of
the concepts, perhaps better than reading them in a book, but
totally lose the perspective of the size of the problems and
the necessity to be careful with minutia.

All this is very interaction intensive.  It's easy if you're a hired
gun doing one course and then running back to your real life.  I
couldn't imagine keeping it up semester after semester.

Re: [9fans] Re: the 'science' in computer scienscience

[Dan Cross]

In article <20010612150943.1AD92199E9@mail.cse.psu.edu> you write:
>With programming, constraints that helped.  I inherited
>a course at Princeton from Rob.  The thing I liked the best about
>it was an assignment he gave to write a shell.  The constraint was
>in the size of the shell.  We said what it was supposed to do (no
>job control) and took points off for programs exceeding the size
>limits.  I reviewed the best solutions with the students.

Hmm, imposing constraints on people, thereby forcing them to think
about the problem, (or expecting them to, as Laura put it) seems to
be a common thread.  Aside from Anthony's comment about brainwashing
(2 + 2 = Plan 9?), I suspect that, coupled with examples of good
style, might be the most effective way to teach good thought patterns.

>But when it comes down to it, the real challenge is imparting some
>flavor of your taste to the students by example or by the application
>of grades.

Oh, I don't know about grading based on one's personal taste; that
seems limiting to me.  We want to teach people a perspective, but
more importantly to think about the problems for themselves.  If we
mold them in our own *style* (as opposed to way of thinking about
the problem), don't we potentially cut off whole new directions for
solutions?

On the other hand, if we don't impose some limits on taste, we run
into the risk of people doing blatantly offensive things.  Where's
the middle ground?  The humanities have been struggling with this for
centuries.  We (computer scientists) have existed for a scant 50
years, in comparison.

Jon Bentley gave a good example of this in one of the Programming
Pearls books; he gave an assignment to write something, I don't know
what, exactly, perhaps binary search.  Two students turned in 10
*page* programs.  He had a great quote, something along the lines
of, ``Turning a 5 line program into a 10 page one was just too much
to award a passing grade.''  [sic]

>Some rules help, as long as you can get them to understand
>that the rules are guidelines and not hard.  If you're lucky you can
>do it in such a way that doesn't cramp originality on their part.

Yes, exactly....

>I've also found it useful to review Plan 9 code and Unix code with
>them.  That way they can see different solutions for the same
>problems.  I actually find things like the toy operating system
>more harmful than helpful.  They come away understanding some of
>the concepts, perhaps better than reading them in a book, but
>totally lose the perspective of the size of the problems and
>the necessity to be careful with minutia.

The same is undoubtedly true for compilers.  Still, there's an
excitement factor for an undergraduate to see his or her OS project
run which is lost when studying a larger system.

>All this is very interaction intensive.  It's easy if you're a hired
>gun doing one course and then running back to your real life.  I
>couldn't imagine keeping it up semester after semester.

Yes; it seems that it would be rather grueling.  However, I think
that's the difference between folks who are excited by teaching and
those who are excited about research.  Hmm, perhaps excited is too
weak; passionate would be a better word.

	- Dan C.

Re: [9fans] Re: the 'science' in computer scienscience

[Boyd Roberts]

> Jon Bentley gave a good example of this in one of the Programming
> Pearls books; he gave an assignment to write something, I don't know
> what, exactly, perhaps binary search.

in the 2nd ed you'll find it in column 12, as problem 6 (the
footnote explains the story):

    I assigned the problem of generating sorted subsets ...

page 130.

the acm had it on some special offer so i just bought it.

[9fans] Re: the 'science' in computer scienscience

[Jim Choate]

How to teach people to learn, to like to solve problems? A major component
is our social environment.

Most folks believe something along the following,

"Genius is 1% inspiration and 99% persperation"

                                T.A. Edison

When we should be teaching them,

"If Mr. Edison had thoght clearer, he wouldn't have had to sweat so much"

                                                Nikola Tesla


 --
    ____________________________________________________________________

              "...where annual election ends, tyranny begins;"

                               Thomas Jefferson & Samuel Adams

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] Re: the 'science' in computer scienscience

[Matt]

for a quick summary

http:/www.proweb.co.uk/~matt/TheElementsofProgrammingStyle.htm

Re: [9fans] Re: the 'science' in computer scienscience

[anothy]

//is there a way to directly target the thought process?

of cource there is. it's called "brainwashing". and i've seen
it be very effective for certain groups.
-α.

Re: [9fans] Re: the 'science' in computer scienscience

[presotto]

Granted that I haven't done circuit design in years, but, modulo
a few fires here and there, it didn't seem that much different than
programming.  There were little tricks like using resistance ratios
to keep the gain on transistor circuits less temperature dependent,
general rules on stage coupling to keep transients in one part of
a circuit, ...  There were rules of thumb, absolute no-no's, etc.
For that matter, I spent a good chunk of my adolescent life laying
bricks and things weren't much different there except that I felt
a lot more tired a the end of the day.

Both science and engineering involve solving problems with
the tools at hand.  Both can be predictive.  With a finite
element analysis of a bridge, I can say pretty definitively
what loads it will take.  The main descriminator is that when
the thinking involves figuring out problems set to us by the
nature of the universe, it tends to be called a science.
When we are thinking about building something, it's called
engineering.  The line is pretty fuzzy unless you are firmly
embedded in one camp or the other.

Mathematics circles both camps.  Mathematics is the
tool used to solve most engineering and science problems.
I like the OED's definition here:

	  (a) in a strict sense, to the abstract science which investigates
	deductively the conclusions implicit in the elementary conceptions
	of spatial and numerical relations, and which includes as its
	main divisions geometry, arithmetic, and algebra; and 

	  (b) in a wider sense, so as to include those branches of physical
	or other research which consist in the application of this abstract
	science to concrete data.  When the word is used in its wider
	sense, the abstract science is distinguished as pure mathematics,
	and its concrete applications (e.g. in astronomy, various branches
	of physics, the theory of probabilities) as applied or mixed
	mathematics.

Some of the best physicists and computer scientists I've met called
themselves mathematicians.  To a certain extent, a scientist or an
engineer is a mathematicion with boundary conditions.

Computer science/engineering/whatever is unique in that the
boundary conditions seem to change a bit faster than in the
other disciplines (though biology may be passing us).
Most disciplines only change due to a new
concept or discovery coming along.  CS has that too; caches,
virtual memory, recursion, type theory, quantum computing
(if it happens), ...  However, we have a constant churn of
our design rules and engineering points caused by Moore's
law and its offshoots.  We're working in a discipline where
everything changes exponentially in time, and a small time
constant at that.  Today's rules are usually out the window
next year.

So bringing this back to education...

This means that we have a hard time imparting anything
from generation to generation that can really be useful
except for how to reason about problems.  The only three
ways I know of doing this are 

(1) studying in depth programs that you believe are
elegantly done, i.e., easily understood, built
with the minimum effort to do the job, and
extensible.
(2) guiding them through programming assignments to
do the same, showing them a better way if they didn't
find it themselves.
(3) get a degree in another discipline so they at
least have a balanced viewpoint.

This is in addition to the fundamental concepts of
programming and design.  However, there are countless
books to teach them that, they could stay home and
read them instead of going to class if that is all
they'ld walk away with.

P.S.  You can tell I'm avoiding real work, can't you.

Re: [9fans] Re: the 'science' in computer scienscience

[Boyd Roberts]

> P.S.  You can tell I'm avoiding real work, can't you.

maybe it just means you've got a gnarly bug :-)

Re: [9fans] Re: the 'science' in computer scienscience

[Dan Cross]

In article <20010612003610.3980A199E9@mail.cse.psu.edu> you write:
>  [...]
>
>This means that we have a hard time imparting anything
>from generation to generation that can really be useful
>except for how to reason about problems.

But knowing how to reason about the problem is a good 75% of the battle
(if not more).  When I was 20 years old, I read, ``The Elements of
Programming Style,'' first edition.  The book is older than I am, but
it _profoundly_ influenced how I thought and worked, even though I've
never programmed in PL/I and only rarely work with FORTRAN.  It was
then that it occured to me that it's the principles, not the specifics,
that are timeless and really important.  The problem with education
these days is that the students want to learn the specifics; mistakenly
assuming that's what's important, and education, hungry for student
currency, is more than happy to cater to them.

Anyway, how do you teach someone to think?  I have no idea; your
suggestions are a good first step, but it seems that the `proper mind
set' outcome is a side effect of exposure with that method; is there a
way to directly target the thought process?

	- Dan C.

Re: [9fans] Re: the 'science' in computer scienscience

[Toby Thain]

Dan Cross wrote:
> 
> In article <20010612003610.3980A199E9@mail.cse.psu.edu> you write:
> >  [...]
> >
> >This means that we have a hard time imparting anything
> >from generation to generation that can really be useful
> >except for how to reason about problems.
> 
> But knowing how to reason about the problem is a good 75% of the battle
> (if not more).  When I was 20 years old, I read, ``The Elements of
> Programming Style,'' first edition.  The book is older than I am, but
> it _profoundly_ influenced how I thought and worked,

Amen to that. I had occasion to quote it a couple of nights ago:
"Do not sacrifice clarity for small gains in 'efficiency' "

Toby