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

[Grant Griffin]

Graham Bleach wrote:
> 
> "Grant Griffin" <g2 at seebelow.org> wrote in message
...
> > 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
> 
> This mindset has been formed BY the use of the gizmo. It is actually quite
> convenient to group related files together into an archive. It just happens
> that your tool for packaging happens to also do the compression and you
> don't have much choice in the matter.

I just learned from Gordon McMillan that I do, though I have never
sought such a capability, and I can't ever see why I would use it. (The
zip process is just so darn "zippy" <sorry> that I can't think of why I
wouldn't use it.)

...
> 
> > 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.
> 
> One of the most interesting ideas I have had recently was provoked by an
> article I read (I think by one of the leading Gnome developers). He argued
> that it should indeed be possible to do all that is possible on the command
> line in a GUI, with the same flexibility. The idea was to have a visual
> toolkit containing lots of snap-together tools, that would allow
> non-programmers* to complete their tasks.

Well, I 'spoze...

But the Holy Grail of shrink-wrap is for the gizmo to do just what the
user wants, right out of the box.  The problem with any sort of
stringing-together system--even if graphical--is that it implies that
the user has some understanding of what the components are, what they
do, and, most importantly, how you use them together effectively*.  But
the shrink-wrap user just wants something that does what he wants it to
do, and it is an explicit goal to know and understand as little about
the software as possible; therefore, it is the shrink-wrap designer's
goal to provide a ready-made solution.

Erector Sets are delightful to Bright Young Minds for the creative
challenges they present, and especially for the endless configurability
they offer.  One can fine tune down to the last nut and bolt.  But an
Erector Set's flexibility comes at the cost of the fact it's pretty hard
to use compared to other, more special-purpose toys.  And let's face it,
an Erector Set isn't cuddly.  But most importantly, note that an Erector
Set doesn't do anything at all when you first take it out of the box.

unlike-GUI-programs-that-run-on-The-World's-Most-Popular
   -Operating-System-<wink>-ly y'rs,

=g2
*Having recently learned Python's syntax, I have now graduated to the
more challenging stage of my Python journey, the
learning-how-to-string-the-gadgets-together-effectively part.  If my
experience with other programming languages holds true, this will take
maybe a year.
-- 
_____________________________________________________________________

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