[Edu-sig] Low Enrollments - programming as anti-intellectualism

[Scott David Daniels]

Arthur wrote:
> As, for example, noted by Rob Malouf's recent post:
> 
> """
> We're not training our
> students to be programmers, we're just trying to give them the basic
> computational skills necessary to study language, genes, etc.
> """
> 
> There is - as I think John pretty much put - learning to program - to
> program, and learning to program - to learn. 
> 
> My own experience is more toward the learning to program to learn - in my
> case - mathematical ideas. But ultimately, to get to where I want to get, I
> realize that "basic computational skills" are not sufficient - that I need
> to get somewhat beyond the basics.  I think that the linguist, or geneticist
> might also find the same to be true - eventually.  Where are those needs to
> be services under current academic structures?

   This is why I'd call programming a writing skill.  Not only should our
geneticist be able to read and write programs, he should be able to know
when he needs the services of a professional programmer.

   If you want to really understand the core, I'd suggest starting with
MMIX, Knuth's new assembly/machine language.  The book is slow going;
a page a day is a good pace.  It _does_ have answers to exercises, and
some material is only presented in the exercises.  If you get through
the Fascicle (93 pages of presentation, 126 through the answers), you
will actually have a good handle on the architecture of modern machines
(one that should last you for a good 20 years) from the point of view of
a programmer.  It is not enough to help you design chips or wire up a
machine.  I wouldn't bother learning the MIX machine -- a great machine
to know in the 70s and 80s because its architecture was typical of
machines in those days.

   Once you've digested that, the rest of his works use that machine as
the measure of what makes code fast or slow.  You then have a great
base to learn how sorting or .... 'll have an appreciation

   If you'd rather an easier start, I like "Concrete Mathematics" --
by Graham, Knuth, and Patashnik.  Reads much faster and covers the
mathematics needed to analyze algorithms.  This path is a much more
abstract approach to the problem.  I remember in the introduction to
the class (upon which this book was based), he claimed "we call it
Concrete Mathematics because it is hard."



--Scott David Daniels
Scott.Daniels at Acm.Org