s/rule/guideline/ and maybe you'll be able to see the forest past the trees.
The rules "Avoid captive user interfaces" and "Make every program a filter" mean that you can't write a text editor.
Not true. Some text editors are of the UNIX nature, and some are not.
But, the fact is that you probably shouldn't be writing a text editor today. Editing text is a solved problem, and you'll almost certainly do it worse than emacs or vim if you try.
The rule "Store data in flat text files" means you can't write a (reasonable) MP3 player or video editing program.
Sure you can. Your playlists can be flat text. Your video queue list can be flat text. Your preferences can be flat text. MP3s and video can also be processed in a filter style (and often are conceptually so within the UI). Only problem is compressed data isn't in a form that can be filtered without first decompressing it. But, I regularly batch process music and audio files. If I did a lot of video work, I'm sure I'd also do the same with video.
Your program can certainly be a filter for those types of files. Sox, lame, and the ImageMagick convert utility are good examples of media programs that embrace the UNIX philosophy.
The point is that you shouldn't use a database if you don't need the things that databases provide beyond storage of blobs of data. Don't over-architect your file formats, don't obfuscate them, don't make it harder for users to use your code in ways you didn't envision. This is the UNIX philosophy...not that you aren't allowed to operate on non-text data.
Programs have been working with messy real world problems since before UNIX and the UNIX philosophy existed. The need to interact with non-text data hasn't sprung into existence in the past ten years. Before there were MP3 and video, there was typesetting, and scientific data analysis, and moon landing calculations, and neural networks, and telephone switching, and so on and so forth.
Programming in the UNIX philosophy is always possible, and, as far as I can see from my many years of software development, always wise.
but most of these rules are just good guidelines for writing command shells and compilers -- not coincidentally, two of the main concerns of early Unix developers
Every single problem of note that I can think of would be well-served by breaking it into reusable pieces. Sometimes this just means libraries, rather than small standalone programs, particularly on the desktop...but sometimes separate programs that happen to be used by a "main" program are the right way to go. Things like video and audio compression can be, and often are, performed by separate programs.
This separation is a win on many levels...on a multi-core machine, the new process can have its own resources, while you continue to work away on your media. It can be upgraded or maintained at a specific version more readily. It can be used by other programs or in a batch mode from a script or batch compression utility.
I think it takes someone who doesn't use UNIX on a regular basis (actually uses UNIX; not merely a GUI shell on top) to think these concepts are outdated and not generally applicable.
I like many of these principles, it's just hard to apply more than a few of them to a given program.
Vim and emacs have captive user interfaces. MP3 encoders like LAME write binary data files. That doesn't mean they're bad programs, but it does make the principles tricky to apply, since they seem to be useful in some cases but not others.
I'm on the Linux command line all day at work, without any sort of GUI frontend. It's got its strengths and weaknesses, just like anything else.
With many well-placed escape routes. Again, think of them as guidelines, not hard unbreakable rules. The overarching gestalt is to make tools that can be used by other tools. vim and emacs happen to be the user of other tools (acting as a shell) most of the time, but they can also be used as tools by other programs (mutt opens your editor of choice for composing messages, for instance). They also use all flat text for their configuration and scripting.
MP3 encoders like LAME write binary data files.
So? That's their job. Their configuration is done from the command line and via flat text. They are filters.
Again, the "flat text files" rule is not that you're not allowed to work on non-text data (that would be stupid; a lot of real world data, maybe most of it, is not representable as plain text). It's that when you have the option, you choose flat text, because it is easier to work with from other programs than yet another custom database or file format. Tools using tools is the UNIX philosophy. LAME is used by hundreds or thousands of other tools. It is definitely of the UNIX nature and one of the more successful examples of it.
You're viewing things as some kind of dogma. That's not UNIX-y. Solving problems is UNIX-y, and there are some good rules of thumb that have been developed over the past 30+ years for solving problems in ways that stand the test of time. The fact that grep, sed, and so on, are used more today than 30 years ago is a testament to the strength of those ideas. Just because some folks ignore that wisdom doesn't make it invalid.
The rules "Avoid captive user interfaces" and "Make every program a filter" mean that you can't write a text editor.
Not true. Some text editors are of the UNIX nature, and some are not.
But, the fact is that you probably shouldn't be writing a text editor today. Editing text is a solved problem, and you'll almost certainly do it worse than emacs or vim if you try.
The rule "Store data in flat text files" means you can't write a (reasonable) MP3 player or video editing program.
Sure you can. Your playlists can be flat text. Your video queue list can be flat text. Your preferences can be flat text. MP3s and video can also be processed in a filter style (and often are conceptually so within the UI). Only problem is compressed data isn't in a form that can be filtered without first decompressing it. But, I regularly batch process music and audio files. If I did a lot of video work, I'm sure I'd also do the same with video.
Your program can certainly be a filter for those types of files. Sox, lame, and the ImageMagick convert utility are good examples of media programs that embrace the UNIX philosophy.
The point is that you shouldn't use a database if you don't need the things that databases provide beyond storage of blobs of data. Don't over-architect your file formats, don't obfuscate them, don't make it harder for users to use your code in ways you didn't envision. This is the UNIX philosophy...not that you aren't allowed to operate on non-text data.
Programs have been working with messy real world problems since before UNIX and the UNIX philosophy existed. The need to interact with non-text data hasn't sprung into existence in the past ten years. Before there were MP3 and video, there was typesetting, and scientific data analysis, and moon landing calculations, and neural networks, and telephone switching, and so on and so forth.
Programming in the UNIX philosophy is always possible, and, as far as I can see from my many years of software development, always wise.
but most of these rules are just good guidelines for writing command shells and compilers -- not coincidentally, two of the main concerns of early Unix developers
Every single problem of note that I can think of would be well-served by breaking it into reusable pieces. Sometimes this just means libraries, rather than small standalone programs, particularly on the desktop...but sometimes separate programs that happen to be used by a "main" program are the right way to go. Things like video and audio compression can be, and often are, performed by separate programs.
This separation is a win on many levels...on a multi-core machine, the new process can have its own resources, while you continue to work away on your media. It can be upgraded or maintained at a specific version more readily. It can be used by other programs or in a batch mode from a script or batch compression utility.
I think it takes someone who doesn't use UNIX on a regular basis (actually uses UNIX; not merely a GUI shell on top) to think these concepts are outdated and not generally applicable.