[geeks] learning script/prog [was: search and replace]

[Jonathan C. Patschke]

On Fri, 5 Sep 2003, N.Miller wrote:

Warning: I'm coming at this problem from the other direction.  I'm a
programmer who's been pushed into system administration because of the
job market, so be warned that this may all sound like it's coming from
another planet.

> I get syntax.  I get functional specification, generally.
> But there's a glue that goes between those two that I seem
> to be have no clues about.  I know I have a similar problem
> with writing, and I think the two are related, but that's
> speculation on my part.

Programming is like dealing with the most smart-assed kid you can
imagine, or, if you like, the Federal Government.  Computers are
stupid, literal, and will do exactly what you tell them to do, right up
the point of "halt and catch fire".

Functional specifications, properly written, are software for people.
Code is software for computers.  Coverting from the former to the latter
is a process of explaining yourself in terms that a simple device made
of sand and copper can figure out but not stumble over when taken
literally.  Unfortunately, this sometimes involves expressing things in
a different way, since people rarely talk to each other in terms of
clearly defined states and conditions.

> Caveat: low on cash, so classes are right out. (Though I always
> make A's in programming classes, so that says something right
> there.)  I've been considering working my way through _How to
> Design Programs_, since it's available on-line, followed by
> _Simply Scheme_.

HtDP is really really great, if you don't live or work in the real
world.  I have nothing but the greatest respect for the people who wrote
it, and I've met pretty-much everyone involved with that project.  I
have, in fact, taken classes from several of those people, and they're
all extremely brilliant, but the book itself isn't very practical and
gets bogged down in the academics of computer science rather than the
practical skills you'll need in scripting.

That is, it's a good start, but take some of the academic stuff lightly
if you're learning programming in the context of system administration.
I'd still recommand reading it (espeically if you're a fast reader),
though, since it covers two topics that I haven't seen covered better
anywhere else:

  1) Design-by-contract
  2) Data-driven design

If those two things were applied universally, roughly 90% of the bugs
and bloat in software would vanish nearly overnight.  Getting these
things down will make you a better programmer than most of the people
I've met in the field, even if you don't know any computer language
particularly well.  Scripting, in particular, can benefit from
design-by-contract, since shell scripts, by their very nature, are
independent units relying on each to not move each other's cheese.

After HTdP, I'd recommend:

  1) _The_Pragmatic_Programmer_, by Andrew Hunt and David Thomas,
     published by Addison-Wesley, ISBN 0-201-61622-X
  2) _The_Practice_of_Programming_, by Brian W. Kernighan and Rob
     Pike, published by Addison-Wesley, ISBN 0-201-61586-X
  3) _Code_Complete_, by Steve McConnell, published by Microsoft
     Press, ISBN 1-55615-484-4

_The_Pragmatic_Programmer_ is a fun read.  It's cut up into tiny topics,
each of which can be read and understood in about 10 minutes.  However,
the topics are important things designed to make you avoid unnecessary
work and heartache.  It tackles things like managing software revisions,
debugging, feature separation, and designing code that behaves itself.

_The_Practice_of_Programming_ isn't nearly as fun a read.  It goes into
the minutae of variable names, style, and other things that a lot of
people overlook, but it attacks them from the point of view of
leveraging them to reduce bugs and minsunderstandings by improving the
clarity of the software you design and write.

_Code_Complete_ is really excellent; don't let the Microsoft name fool
you.  This book is huge, and is stuffed full of extremely good
information and practices, only some of which is useful in a scripting
environment.  Most of it assumes you're working on big projects, and
it's geared towards that audience.  Steve positions his book as a
handbook of software construction, which he defines as the translation
from design spec to code.  Design is covered, but only under a
microscope--the actual overreaching design of the project is assumed to
be out of your hands.  Local things like code design (when to use a
function, when to create a new datatype) are hit on pretty well.

The great thing about all these books is that they're just as great used
as they are new.  Software design doesn't change nearly as quickly as
the software itself does.

-- 
Jonathan Patschke   )  "Gamer weenies...are the sludge at the bottom
Elgin, TX          (    of the user swamp."           --Gary Nichols