> Close to the Unix ideal of doing one thing, and doing it well.
In my opinion this concept does not work for most non-cli programs. How do you actually define this "one thing"?
Is "reading an email" one thing? And "writing an email" another thing? What about "spellchecking the email"? What about "managing all my email contacts"? What about "back up my emails"? What about "sign email with GPG"?
Do all of these things really need a separate program?
The unix principle works quite well for stuff like grep/find/awk but there is just now way you could make GIMP follow the unix principle.
That's essentially what Mutt does. But you could also use other programs to parse and read each email file if you wish. "Fetching email" can also be a different thing. I use offlineimap for that purpose and store my messages in the Maildir format.
> And "writing an email" another thing?
Yes. Even "sending an email" is another thing. The program that edits my emails (vim) is not the same program which sends them (msmtp).
> What about "spellchecking the email"?
I don't do this (with a program), but I assume you could just do it within Vim.
> What about "managing all my email contacts"?
I use OS X Contacts for that, so there's a command-line tool that allows me to search for and then insert those contacts in Mutt.
> What about "back up my emails"?
Again, another program! I keep my Maildir synchronized to my home server and all my other computers using BitTorrent Sync. Changes are backed up with Arq to Amazon Glacier every day.
> What about "sign email with GPG"?
Definitely its own program, although Mutt includes support for it you still need GPG installed and everything set up for that stuff in order to sign your emails. This is true for every other email client isn't it? I know I have to instal GPGMail to get the same functionality on Apple Mail.
So you see, all of these tools are really separate processes in and of themselves. The benefit to all of this is when newer and better technology comes around, you don't have to wait for your software vendor to support it. Instead, you just use a different program that follows the same standards, which have been around for decades. Some people, probably most, find this to be an unacceptable burden. For that, there are definitely great email clients out there like Nylas N1 and Google Inbox...but if you want total control in the same sense that you get from your shell and your editor, Mutt is the client for you.
Well, in case of mutt, it's just reading email from a local maildir. That is, a MUA (mail user agent) in it's own jargon.
Mostly everything else is outsourced. Composing is done by your $EDITOR, sending is done by an external program, fetching email by an external program too. Even indexing and querying is usually outsourced to a modern xapian-based tool, like mu or notmuch.
My own idea of the Unix ideal—I don't know how it accords with others'—is that there's nothing wrong with having an umbrella program that brings many pieces together, as long as those pieces are modular.
That is, I have no problem with being able to read, write, spellcheck, and sign an e-mail, manage my contacts, and back up my archive from within a single program; but it had better be true that, if I want to use vi instead of Nano to write my e-mails, then I can force the program to respect this wish.
(As is probably apparent, I'm a Pine user by experience; I've never used Mutt, but would like to give it a try.)
ImageMagick is a poor example of "doing one thing right" because every command line tool actually does a million different things with different command line switches. Additionally, it can't do everything GIMP can (which I think you're acknowledging with the winky face).
Imagemagick can't do everything GIMP can do. But everything Imagemagick can do can be scripted.
Need to convert 10, or 100, or 1,000, or 1,000,000 images? You might use GIMP for the first. You'd best give it up for the 2nd and further.
On Linux desktop, I had an Imagemagick command in my command history which would trim off the top n pixels of images to remove extraneous elements. Quick to call that up and run it on a new screenshot, or a series of shots, prior to posting online. The job was completed before GIMP would finish initialising.
> Do all of these things really need a separate program?
Indeed. This is one of the reasons why the unixy "One app does one thing" philosophers dislike the C++ language so much. C++ is built for creating precisely the kind of apps you are describing - Classes are a well-defined compartment or component that does this "one thing" business while the app co-ordinates their working towards a common good.
C, on the other hand, pertains much to their "one thing" philosophy and they like it very much.
> Is "reading an email" one thing? And "writing an email" another thing? What about "spellchecking the email"? What about "managing all my email contacts"? What about "back up my emails"? What about "sign email with GPG"?
>
> Do all of these things really need a separate program?
Yup. I used it for a few years. It also had a Tk-based GUI. Every email message is a single file. "Folders" are directories. So you can use your usual text-processing commandline stuff: grep, sed, awk, etc.
Using MIME or GPG required a little configuration (mostly preset properly) which hooked external programs to preprocess before sending or displaying the message.
> The unix principle works quite well for stuff like grep/find/awk but there is just now way you could make GIMP follow the unix principle.
It seems that the unix principle is most relevant when compiling a C program takes too long and no interpreters exist that are fast enough. So, you figure out all the higher level functionality that you will need for system administration and compile that long before needing to do any sysadmin work. When a problem arises on a system, you can write a shell script that uses those already compiled commands, instead of writing a C program and waiting for it to compile. If your initial code sucks, you don't have to debug and recompile; you just debug and re-run the script.
Compiling C programs is now substantially less time consuming, so you could use C for sysadmin work (shudder). C shell was perhaps a similar attempt to get the benefits of C, but without the downside of compilation times. I seem to recall some essay on the harmfulness of using csh, so C will continue to keep its place.
how about we break down each action one can take in the GUI as its own binary that is part of a larger set? that way the GUI becomes a wrapper that do one thing, wrap the binaries that all their own thing, but that gets composed to do larger jobs.
One IMO important thing that's missing from others' replies: It's extremely simple to integrate other programs for processing your mails. Want to be able to import patches sent to you into some git repository? Just write a small shell script that accepts the mail (or some attachment) as input and then create a keyboard shortcut in mutt that pipes the mail (or attachment) to that script, done. You don't need to extend mutt in order to be able to programmatically process your emails, you simply use standard unix mechanisms (a pipe or maybe a file) and call an external program.
> In my opinion this concept does not work for most non-cli programs. How do you actually define this "one thing"?
I don't see how CLI programs avoid this. "One thing" is a human idea, subject to interpretation. Should grep and sed be consolidated? Does find do too much? Why do we have both echo and printf?
> Is "reading an email" one thing? And "writing an email" another thing?
Mutt says so. You read and sort emails in Mutt, you write emails in $EDITOR and then you can add attachments and such back in mutt.
> What about "spellchecking the email"?
Well since mutt outsources writing the email, I can't really comment on what mutt does. But if you don't want to do spellchecking within your editor for whatever reason, mutt lets you pipe the contents of anything to an external program, so you could write your email, then select the message from the attachments list and type "|aspell -a<CR>" and you'll get a basic spellcheck.
> What about "managing all my email contacts"?
I think that's pretty clearly a seperate program's duty, since contacts are used by other applications as well. Not only does mutt agree with me, so do Google and Apple. Mutt makes it simple to integrate with external contact lists to provide autocomplete for known email addresses.
> What about "back up my emails"?
That should be taken care of by both your email provider and your personal backup solution. I don't see why an email client would care about backups.
> What about "sign email with GPG"?
Well that's a job for GPG isn't it? That again can be accomplished by just piping the message into an external command. If you use it frequently you'd write some config and scripts to automate it. I saddly rarely uses PGP for email so I don't have hands on experience with this, but it looks like mutt has built in support for this kind of automation. A more unix-aligned approach would be to ship an /usr/share/mutt/examples/auto-gpg.muttrc or something like that that users can just source in their config files.
> but there is just now way you could make GIMP follow the unix principle.
No? Represent layers as a bunch of image files in a directory. Have one program check when they change and composite them in realtime. Have another program render the output of that one to the screen. Have a third integrate with the rendering program and manage the creation of selections (represented as a selection mask, so it supports everything from rectangular selection to brush selection). Drawing tools and filters become programs that take an image and a selection and some (interactive) options and output a new image. Then you have a UI program that brings all these programs together.
If this isn't as performant as Gimp, you can optimize it, for example, by replacing pipelines between parts of the standard toolchain with some kind of shared memory IPC or something similar.
It's not that the ideas behind unix don't apply to modern software; people just don't give a fuck.
In fact, sometimes it can be the "only" thing you want. Most often it is the case with open source developers when they want to catch up a huge discussion thread. (Like bugs to email interface). Mutt is excellent here.
If I have something to add to the discussion, I have the option to use the command line or log in to web interface and post my response.
In my opinion this concept does not work for most non-cli programs. How do you actually define this "one thing"?
Is "reading an email" one thing? And "writing an email" another thing? What about "spellchecking the email"? What about "managing all my email contacts"? What about "back up my emails"? What about "sign email with GPG"?
Do all of these things really need a separate program?
The unix principle works quite well for stuff like grep/find/awk but there is just now way you could make GIMP follow the unix principle.