The REALLY bad thing about Python lists ..

[Tagore Smith]

On Sat, 20 May 2000, Grant Griffin wrote:

> Garry Hodgson wrote:
> > 
> > Grant Griffin <g2 at seebelow.org> wrote:
> > 
> > > (BTW, why to you Unix people
> > > separate your packager gizmo from your compression gizmo?  Very
> > > strange...)
> > 
> > not strange at all.  these are two completely different
> > functions, and thus belong in different programs.
> 
> Well, in the context of a 1970's-style command line OS, which
> synthesizes complex behavior by stringing primitive commands together,
> maybe so.  But surely it causes you people a lot of typing.  (Or maybe
> you people write a shell script to mitigate that.)

   I can type tar -xvzf much faster than winzip can start up. Even with
long commands a good shell has aliasing, command completion and history,
so a few keystrokes is all you need a lot of the time. I find typing
faster than mousing anyway (thus shortcut keys in applications).
 
> But in the context of a modern GUI OS, it makes a lot more sense to have
> all such functionality built into a single program.  I have never seen a
> Windows equivalent of "tar" (that is, a packager, less compression), nor
> have I ever wanted one: if you're packaging, you might as well compress;
> if you're doing both, they might as well both be in the same program.
> 
> Perhaps the '70s approach saved a little disk space or whatever by not
> repeating tar's functionality in each compression program, but clearly
> that isn't worth the extra trouble it causes for users to have to
> repeatedly invoke tar every time they want to de-compresss a package.
> 

   The point isn't really to save disk space. It's to allow you to hook up
a bunch of little tasks into one big task. Say I have 100 small utility
programs, and I can pipe the output of any of them to input of any
other. Then I have 100 * 100 = 10000 possible combinations. Not all of
them are going to makes sense of course, but enough of them will that this
is very useful. And since I can hook up three or four or more it's
actually more dramatic than that. It also means that I can do things with
these utilities that were not thought of by their authors.

   If I _want_ a gui based interface to untarring and decompressing I can
write just the GUI and call the utilities. So what might have been a
pretty serious effort becomes close to trivial. Particularly if I can use
Tk instead of Motif and tcl or python instead of C :-).  

   [snip]

   I'm not bashing windows- there are some things about windows that the
*nices could learn from, and it has gotten a lot better since 3.11- but
one thing I really miss on both the Mac and on Windows is a good shell and
a lot of little utilities that I can easily drive using the scripting
language of my choice. In that respect at least I think that Windows has
yet to catch up to 1970's technology. And though I think that Python and
other scripting languages are valuable on all three major platforms, I
think Unix supports them best by making all these little utilities
available. 

Tagore