> At the time I believed we needed to have tools that are composable and that could integrate with other tools, in line with the Unix philosophy. Kamil convince

> At the time I believed we needed to have tools that are composable and that could integrate with other tools, in line with the Unix philosophy. Kamil convinced me to think about the efficiencies of having a single application. The Unix Philosophy is dead today, but I don't believe that's because of any inherent flaw in the principle of "composability". It's that we no longer have a good composition mechanism for the types of programs that people run. In 1975 or 1985, you were running a command-line tool to process some data. (That kind of sucked, but whatever, that's what we had.) The idea of being able to pipe bytes from the output of one to the input of another is pure win. Fewer steps, no temp files, see results as they are completed -- and the cost is literally one character. No wonder it took off. Today, the types of programs people run are native apps (which don't have an obvious I/O mechanism, apart from the filesystem, if that) and web pages (i.e., programs awkwardly split across my computer and some server in Virginia, speaking an ad-hoc protocol). Making them talk to each other takes a developer and a month. I'd love to be able to have a web app, a word processor, my contact list, etc., talk to each other and easily and meaningfully pass data between them (and I'm working on software to do just that -- see my bio). Why can't I pipe my Facebook friends list straight to a spreadsheet, or a map? They speak of the efficiencies of having a single application. It's more the lack of an efficient standardized way to combine different applications. Back when it was "type one character", the efficiency argument went the other way. We need to get back to where sharing data with every other program is the default.