[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: merge multi symbol components
> I'm all in favor of this. But the right way to do that with a
> toolkit is usually to wrap the tools with high level scripts. Adding
> features to the tools themselves is the "cat -v" approach, the road
> to bloat and inflexibility.
As much as I agree with the basic point, I think cat -v is not a good
poster child for it.
To quote http://harmful.cat-v.org/cat-v/, mentioned upthread,
cat isn't for printing files with line numbers, it isn't for
compressing multiple blank lines, it's not for looking at
non-printing ASCII characters, it's for concatenating files.
Quite aside from the "who died and made _you_ god of what cat is for?"
question (which actually carries comparatively little force in Rob
Pike's case :), this is just silly. Presumably this means Rob Pike
(and, I gather, you) would prefer to have a separate program for adding
line numbers (let's call it cat-n, to avoid the need to think of a
better name now), one for compressing blank lines (cat-s), and one for
visiblifying nonprinting characters (cat-v). These will need to
duplicate (almost?) all of cat's functionality, with additional code
for their particular functionality. How is this better than sharing
that common code by making them flags to cat? What flexibility is lost
by turning cat-n, cat-s, and cat-v into options to cat? What gain
would splitting them out into separate programs bring?
In general, I agree with the hamster approach - "each program does one
well-isolated thing well". But I even more believe in using a few
brain cycles, looking at the tradeoffs in a particular case, rather
than dogmatically applying dogma everywhere.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse@xxxxxxxxxxxxxxxxxxxx
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user