Re: [Groff] Introduction

[Clarke Echols]

Miklos Somogyi wrote:
 
> On 19/10/2005, at 7:19 AM, Meg McRoberts wrote:

> The vast majority could put up with frequent crashes, with long
> printing times
> of very simple documents, with the fact that things did not really
> looked like they should have,
> that they had to do repeat jobs one-by-one, etc.
> 
> But they could not put up with a lot of learning of things not directly
> related to
> their jobs. "I am working on the flows in this precipitator.. Are you
> telling me that I should stop
> for a few days to learn .br .pg .sp etc? And all the blazing commands
> of Unix?"
> So they looked at SGI workstations as monsters and embraced their PCs.

When I was working on the man pages for HP-UX graphics libraries
about 1987 or 88, I was faced with about 5 weeks of work using vi
to clean up the inconsistencies of format coding inside the files
so they would look like they came out of the same shop.

Being the lazy sort, I decided to spend about 5 hours learning
how to use sed.  I finally cooked up a script I though was
suitable, loaded it up with a shell script, and fired it off.
I took a walk, thinking it would take 20 minutes or so.  I was
back in about 5 minutes and it not only was done, it worked!

The problem is that these engineers don't have managers with
sense enough to lean on them to learn to use better tools to
get more done in less time.  By learning to use the tools, and
nothing more complicated than simple shell scripts (I don't
have the skills to get fancy because I don't think they're all
that necessary when an easier approach works well), I was
able to consistently get more done than any 4-10 people
around me without straining myself.  This is not to brag, but
people waste an incredible amount of time and productivity
by not learning to exploit the capabilities of a Unix-like
machine instead of really dumb PCs.

I often use the analogy that working with a PC versus a Unix
box is like using a Nissan 1/2-ton pickup and a shovel to move
a great big pile of gravel, versus using an 18-wheeler with
a dump trailer and a great big 4-wheeled loader.

But many people would rather stick with the familiar than to
risk actually learning a better way because change usually
requires getting out of one's comfort zone, and most people
-- especially highly detail-oriented engineers and CPAs --
avoid getting out of their comfort zone like the plague.  But
unwillingness to change makes one a victim of change when the
environment around the individual changes and he or she is
no longer needed because they haven't kept sharpening their
peripheral skills needed to remain competitive.

To the novice, Unix and troff is intimidating.  Yet once you
learn it, it is beautiful in its graceful simplicity.  When
you want to blow away a file, just use 'rm', rather than
opening "My Computer", finding your way to the folder where the
file is located, clicking on a menu to delete it, then having
to answer that yes, you really do want to remove the file, and
yes, you are aware that it will be gone, but with Unix, it's
really GONE, not sitting in some trash can in case you want to
retrieve it.  I prefer getting the computer out of my face
when I have work to do.  But I may have some advantage, having
worked on Unix man pages and tutorials for most of 10 years.

I had a simple shell script (about 15 pages) that took 1450
source files from RCS, built 50 filesets of online man pages,
and built a 3000 page HP-UX Reference in about 20 minutes on
a 30 MHz processor using HP-UX and troff.  I expect that my
1.6 GHz machine could do the same job now in 5 minutes or less,
given that it builds a 380-page novel in PostScript in about
8 seconds running groff on Windows 98 in a Cygwin environment
that preserves my sanity.

Clarke