Don't get caught up in the hype - the Zen of "The Unix Philosophy"

[jack-rp9/bkPP+cDYtjvyW6yDsg at public.gmane.org (Jack Coats)]

Yes I manage a few small unix based web sites.  Using mainly vi and ftp.
They are not fancy, but IMHO if you are going much beyond just the basic
set of static pages that get updated on occasion, more tools, or better
skills
than I have, are needed.

<soapbox>
The unix philosophy of using small usually single function tools piped
together
to do a big job is proper unix Zen, and we should aspire to it.  I have
worked
with folks that learned just enough to be dangerous in a language and 'had
to
use it' on the production servers.  We had a half dozen or so different
languages
(sh, php, perl, c, java, c++, javascript, postscript, etc) that were used
both procedurally and written
by different languages (mainly php, perl and awk writing HTML, javascript,
and postscript) using
both stored procedures and external procedures, and driving a MySQL
converted
to postgress database that stored the base data. If I remember right it also
drove
imagemagik for batch image processing using its scripting language, and
scribus
but generate printable pages.

Anyway, you get the idea, that there might be a 'right tool for the right
job', but if
we start getting to many 'tools' in the mix, it can make the maintenance of
a system
overwhelming to the maintainer that must come along and do modifications a
year
or more later (yes, I was the poor schmuck that did the maintenance ... and
the
learning curve to get just the basis on each of the tools was overwhelming).

When writing applications, pick a 'small set of tools' that do orthogonal
tasks (tasks
that the 'other' language can't do, or at least the tasks are hard in the
'other language').
Document the 'bejibers' out of the overall systems design, and each
'non-trivial' task.
In-line documentation is great and needed, but overall system and 'system
philosophy'
need to be documented as well.  Write the documentation like you would want
to see
it WHEN you maintain it in 2 years (without using or working on it
in-between).

There is such a thing a 'throw away code'.  I have written it.  But after
some time I found
that taking a few minutes and putting some comments in it could save me a
lot of time
later (as I try to re-use my own code rather than re-write it later...
overall it saves me time,
I believe).

In conclusion, the Zen in programming is great.  Stay with it, but don't get
so tied up in
it you can't use another more productive tool when it is called for.  But
again, don't just
use another tool because O'Reilly published yet another book this week.

>From the battle front of the Code Wars... Jack
</soapbox>