On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote:
>
> This is the classical divide between pragmatists (I want to get my job with
> with minimal pain so I can go home a play ball with my son) versus the
> idealists (source code management means doing x, y and z and no more and no
> less and I'm sorry that it will take you twice as long to do your job right
> *grin*).
>
> Fossil is caught between the messy world of the pragmatists and the nice
> tidy world of the idealists. There is no one right way to do it. One group
> or the other will be disappointed.
I don't think that's all there is to it. It isn't really fair to those
who prefer automation of the full set of rm tasks to suggest they
necessarily lack a sense of the idea, or to those who oppose that
automation to suggest they lack a sense of pragmatism. I think that the
two sides of this discussion are more sophisticated and complex than
that, with several different types of argument being possible and
presented on each side. The major argument types I have seen so far are:
for rm automation | against rm automation
----------------------------------|----------------------------------
idealist (Unix way) | idealists (airbags way)
pragamtists (POLS way) | pragmatists (backward compat)
trolls (haven't noticed any) | trolls (NIH and "you're dumb")
If you know of any trollish argument forms on the pro-automation side,
please feel free to point them out. I may be suffering some confirmation
bias in this case. Anyway, my explanations of the various arguments, as
I have noticed them, follow.
* Unix way idealists: When you tell it to do something, it damned well
does it.
* airbags way idealists: When you tell it to do something that might be
accidentally applied in an unintentionally destructive manner by an
incautious user, it should second-guess your intentions and try to
convince you to do things differently, on the assumption that is not
what you wanted.
* POLS pragmatists: When you issue a command that seems like it should
perform a given task, you expect it to perform the whole task, and not
only part of it. Tool design should account for that.
* backward compat pragmatists: This is how it has been done so far,
establishing a set of expectations particular to long-time users and
the automation scripts they have written that rely on the behavior in
question. We should not change the tool's behavior to violate those
ingrained expectations because there may be backward incompatibility
problems.
* NIH trolls: You're trying to turn Fossil into Git! Stop it!
* "you're dumb" trolls: Obviously you are all too stupid to understand
the benefits of keeping things the way they are. You are wrong because
you are stupid; you are stupid because you disagree with me.
If we could eliminate those "troll" category participants in the
discussion, I think we would get a lot further in sorting this out.
--
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
