OT: why tar is strange (was: The REALLY bad thing about Python lists ..)

[Grant Griffin]

Thomas Wouters wrote:
> 
> On Thu, May 18, 2000 at 10:30:58PM +0100, Grant Griffin wrote:
> 
> > BTW, why to you Unix people separate your packager gizmo from your
> > compression gizmo?  Very strange...
> 
> Strange ? Really ? I find it strange you would want to put different
> functionality into one program... 
> Packing and compressing are two different
> things, so why force one program to do both ? :)

I dunno...about the only program I know of that does just one thing is
"Hello, World!".  ;-)

I guess I take a "shrink wrap" mentality, both from an author's and a
user's perspective.  The "gizmo" should meet the user's need, as defined
by the user.  (Note, however, that the "user" is partly defined by the
"gizmo", because user's don't use gizmos which don't meet their needs.)

For example, Python has many disparate features and functions, in an
attempt to meet the needs of the Python user.  We would regret it if it
did only one thing, or if it was only allowed to do things which have
some immediate conceptual relationship to each other.  Instead, we
benefit from the holistic integrity it somehow achieves from its
disparate features.

But to go back to tarring and feathering tar, the user has little need
for packaging without compression, so packaging and compression
constitute a single gizmo from the modern user's perspective.  QED

> 
> So much better to seperate the functionality: If you get a new version of
> the compress utility, or a new compress utility that does it so much better,
> you wont have to change anything in the packing utility.

But isn't packaging pretty trivial?  And disk space is cheap.  I mean,
this is the late 1980s, after all!  So why isn't packaging built into
_every_ modern compression utility?

> And the other way
> 'round. And decent packaging utilities provide support to magically include
> compression, by calling the appropriate compress utility itself... GNU tar
> has support for standard unix compress (.Z), gnu zip (.gz) and bzip2 (.bz2)
> this way, and you can tell it to start any program you wish, with the
> '--use-compress=' option.
> 
> Just like there isn't a Wordperfect or Word-alike program on (traditional)
> UNIX; no all-encompassing Word-processor. Instead, you edit using your own
> favorite editor, passing it through your own favorite text formatter, to
> translate it to a file format of your choosing. And just like Mosaic, long
> ago, didn't provide support for all protocols itself, but rather let other
> programs take care of them... You can see a lot has changed in the UNIX
> world, in this regard :-)

I've been teasing you guys a little on this, but in all seriousness, as
I think about it more, it seems like the essential disconnect here is
between the "command line" paradigm and the GUI paradigm.  The "compound
functionality" approach of UNIX makes good sense in a command-line
paradigm (because it allows a lot of flexibility at the cost of a lot of
typing, or writing scripts: more typing), but in a GUI paradigm, it's a
lot more practical simply to build all functionality the user requires
into a single program.  (This is the essence of "shrink wrap".)  And
when that program _doesn't_ meet our needs, we simply get an upgrade, or
find another program which does.  Or better yet, we standardize on a
single format, zip: very simple, very easy.

With all due respect to the Windows-bashers of the world, I personally
think that trading flexibility for convenience is a very good tradeoff:
it makes me productive.

(which-is-why-i-still-think-tar-is-strange-<wink>)-ly y'rs

=g2
-- 
_____________________________________________________________________

Grant R. Griffin                                       g2 at dspguru.com
Publisher of dspGuru                           http://www.dspguru.com
Iowegian International Corporation	      http://www.iowegian.com