On Fri, Jan 29, 2010 at 01:40:18PM -0600, David Young wrote:
> It sounds to me like you may be confusing two ideas.  One idea is a way
> of assembling an application from small programs that perform discrete
> tasks in a script or pipeline.  The other idea is a user's experience
> that an application came with "some assembly required." 

*I'm* not confusing anything with anything. :-)  What I was doing,
however, was attempting to address (what I think are) David's concerns
about some arguments that tend to crop up against adding features in
the name of the Unix Philosophy.  There has been a tendency in some
quarters to blindly and rigidly advocate that following the Unix
Philosophy is the One True Way, which has often hindered progress.

> There is not any reason that an application that is sophisticated
> and complete cannot be assembled from small parts.

True... but, there might be usability reasons why it *shouldn't*.
That's sort of what I'm trying to say [although my main point, which I
may not have made well, is that using the Unix Philosophy as
justification to not implement a beneficial feature in mutt is mostly
kind of lame].  In potentially a lot of ways, it's just easier for
users to deal with monolithic apps.  Especially if you yourself need
to actually assemble the smaller programs into a pipeline (every time
you need to use them), but even if you don't.

> You can distribute a sophisticated and complete application fully
> assembled, no matter how many pieces form it.

Indeed you can... qmail comes to mind, but IMO qmail is a tangled mess
to manage, an example that makes my point above.  The code is elegant
enough, but the flow of mail through the system is complex, which can
make for some difficult troubleshooting.  As I said, I believe that if
you need to have complexity, it should be in the code, not on the user
end.

Often on mutt-dev there are arguments against developing particular
functionality (like, oh, I don't know... SMTP capabilities) because
there's something else out there that does it, and you should just
glue that onto mutt instead.  Usually such features were almost
automatically labeled bloat.  I see instead added user complexity.
Instead of one app to install, configure, and maintain, you now have
two (or 12) -- each with their own quirks to learn and love. :)

Sure, Mutt has SMTP functionality now, but it took about a decade and
a couple of changes of maintainers for that to happen.  The benefit of
adding this functionality seems so obvious; yet it took forever to
convince the devs it was a good idea.  This is, IMO, a fine example of
where a monolithic application wins, and arguing "no way, unix
philosophy!" loses.

This, I believe, was what David was referring to, when he commented:
> I would love to see RFC2369 handling built in to mutt, but have not had
> time to explore this in code.  I'm certain there are others here who
> would cite the Unix Philosophy or whatever, and assert that an external
> program could do this as effectively and with cleaner layering.

Of course, in this case, Mutt could provide its SMTP functionality in
a separate program; as long as that separate program is behind the
scenes, and the user doesn't need to do anything "special" to
configure it, then you can have your Unix Philosophy and eat it too.
But in the grand scheme of things, there's probably little practical
benefit to splitting it off into a separate program, and indeed it was
not implemented that way.  And it's not always that easy to do; it's
generally  much easier to communicate the bits that need to be
communicated via function call, than it would be to implement some
sort of IPC.

> The advantage that assembling an application in the "UNIX-y" way
> has over a monolithic application is that the parts can usually be
> disassembled and reassembled for the purposes of testing, automation,
> creating new and improving old applications.

Absolutely.  The advantage of a monolithic app is that, in cases where
one is called for, most users usually won't care about those issues,
and there's usually a lot less for them to worry about / manage with a
monolithic app than with a bunch of smaller programs.

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

Attachment: pgpjNb68s5z1z.pgp
Description: PGP signature

Reply via email to