Thanks alot for that link, it lead me to this very interesting talk by Brent Victor, as kind of a counter argument to that principle: http://vimeo.com/36579366. And holy shit does he have a point. Many of today's programmers seem to be trapped in the thinking that the unix and vim principles are the holy grail, forever to be pursued, never to be changed. Isn't it time we stand up and reassess the tools we have? And I'm not just talking about the teleprompt generation tools like unix and vim, but also today's IDEs that have basically evolved as extensions to those tools.
I would argue that very few of today's programmers really follow the Unix philosophy, but those I know who do would likely agree that our tools should be reassessed. But you seem to be conflating the idea of reassessing our tools and reassessing our principles. In my opinion the core principles [1] are eternal, however transient the programs themselves.
I'd argue that the tools (if they're 'good' in itself) reflect the principles with which they have been designed. And no, I don't think that these principles are eternal. We should look at the context under which these principles have been formulated or evolved, compare it to today's context, pick out the principles that still apply and throw the rest out. As an example, building small programs to do well defined, easily testable tasks and chain them together, is certainly still a good design principle. Strings as the universal interface, however, is not in my opinion, since it just doesn't reflect how most of today's UIs are built on objects - thus we have today's disconnect between the terminal and the GUI.
You believe that text as a universal interface isn't a good design principle because it doesn't reflect how other UIs, built upon completely different principles, behave? Is it not possible that it remains a good principle that WIMP GUIs simply do not adhere to? (Also related, "everything is a file.")
Unformatted text (as in text that doesn't follow a machine-understandable format like xml or json) is not a good interface today, I absolutely believe that. Imagine if "ls" would return an xml table that you could easily reuse in other programs, including graphical editors. Imagine that the OS could understand what every column represents and give it a name. You could do something like
ls | showtable in.modified in.filename --sort:1.
Of course you can do this today with sed, but in a very unintuitive way not easily accessible for beginners.
That's a great talk (see also chris granger's "light table", inspired by it), but is an example of a key truth of tools: the right "tool for the job". Like products with usages, tools are more or less appropriate for specific usages.
IDE's are great for navigating huge codebases, and massive libraries with long informative names (intellisense), integrated debuggers that can step into libraries, refactoring tools, etc. The visual gui builders are also really pretty cool - and a wysiwyg example not that far from Bret Victor. They require less effort (and skill) for these specific common tasks.
Bret's use of time is great for games, but not appropriate for all programming tasks. There's been extensive discussion of light table (here and on progit), about how it seems more suited to smaller, experimental coding (not large codebases) - but this remains to be seen, as the tool's not yet available.
I use vim myself, because I'm writing parsers and related code, an example of pure code (non-library, non-gui, non-web), leaning toward the algorithmic, which vim grew up around and was shaped by. Vim/emacs are still the deepest most fundamental level of coding - but that's only appropriate if you need to be working from first principles. Most of the time, for most high-value development, you're not. I think that for specific domains, where custom tools can get some leverage, it's more productive to use those tools. Tool for the job.
I also recommend the following talk about "subtext": http://www.subtextual.org/subtext2.html.