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

Graham Bleach itdcgb at its.hants.gov.uk
Fri May 19 18:01:27 CEST 2000


"Grant Griffin" <g2 at seebelow.org> wrote in message
[lots of snipping]

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

I think the difference may be where you define 'thing' (as in task).

> 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.)

Very true.

> 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.

Hmm, I think you miss the point a little. The built-ins may be the most-used
bits of Python functionality. When you use extensions they are generally
small extra packages which can be taken or left. But they are grouped
together in small *logical units of functionality*.

> 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.

> >
> > 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?

Someone will surely correct me anyway, but I have an inkling that tar can
also use the gunzip libraries to decompress the files (?) It is just not
used that way as often, because traditionally UNIX bods wanted to seperate
the functionality. After all, it's part of the UNIX philosophy that's
written in the first chapter of every *nix book I've looked at.

[big snip]

> 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.

For a few weeks I had this idea in the back of my mind to make UNIX
pipelines accessible to non-programmers. They would be able to visually join
logical operations together in some way. Anyway some other idea evicted this
from my mind until I read your post and now it's back :) My main problem is
that I have little GUI design/programming experience and that generally I
have not enjoyed creating user interfaces :)

> 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.

Now I've tasted the power of the command line on mainframes and UNIX I can
never go back to my old ways.

> (which-is-why-i-still-think-tar-is-strange-<wink>)-ly y'rs
>
> =g2
> --
[sig snipped]

I could go on a mission to revolutionise the computing world, but I'll
probably just go for a drink.

G

[*] I would consider them programmers, but they'd be a very different sort
of programmer than today's.





More information about the Python-list mailing list