On the 'do one thing and do it well' issue, there seem to be two spectrums:<p><pre><code> 1. suitability of a tool to multiple tasks
2. number of features a tool has
</code></pre>
This makes for sort of a field with four quadrants:<p><pre><code> 1. simple but flexible tools
2. complex and featureful tools
3. specialized but simple tools,
4. highly specialized and highly featureful tools
</code></pre>
So take a tool like grep and it clearly belongs in the first quadrant. You can do a lot with it, but it's pretty simple to learn and use. Emacs (or Eclipse) belongs in the second quadrant as it can basically be used for anything and is complicated to learn. Something like MyPaint belongs in the third category and there are numerous domain specific tools that belong in the fourth.<p>So the question that remains when one is asking for a tool that 'does one thing well' is, do you mean for it to be specialized, or simple, or both?
I had two thoughts while reading this.<p>1 - The need for the web to be profitable in some way makes 'single tools' hard to build. You have to grow users, add features, etc, etc. So even if you have an API or something useful it likely won't scale economically. Unless it's government supported or behind a foundation of some sort. The Twitter API comes to mind here.<p>2 - This is tricky because for the web to meet the UNIX philosophy, everyone has to agree. You can't have the team that manages the equivalent of the `ls` website decide to change their output, or strike up a deal with the `diff` team to force `diff3` out.<p>Once again, capitalism ruins everything fun. That's hyperbole, kinda :-)
I'm definitely guilty of holding onto a philosophy and thinking it applies universally, so I can't blame people that hold onto the Unix philosophy extremely strongly. But I can't help but think that the world requires a hell of a lot more pragmatism than the Unix philosophy can provide.<p>The first problem I see is that "One Thing" is really subjective. Some people might see Postgres as doing one thing really well (It is, after all, an incredible Relational Database). But others might look at Postgres entirely differently: It is a client and a server. It is a data protection and credential management system. It is an in memory caching layer. It is a NoSQL key value engine. It is a SQL database. It is a data retrieval operation optimization system. It is a storage format. Hell, it does a million SQL things that other SQL databases don't...databases that probably also qualify as doing "One Thing" in other people's eyes.<p>The second problem is that the world is really fucking complex, and sometimes doing one thing well is impossible unless you also do one other thing well. Rich's big example in this article is Evernote, and his claim was that Evernote did one thing well, which was note synchronization. But notes are almost always more than just text...which was why they added photos and tables and web clippings. Who would ever want just the text aspect of their notes synchronized across devices, but not their photos that they took of powerpoint slides, their data tables, their diagrams, their emails, etc.? If Evernote wanted to do "Note Taking" well, they couldn't just stop at text synchronization across devices. So they should have stopped trying to do "Note Taking" well, because someone only used them for the text synchronization that they already did? Evernote is dying, that's for sure...but its not because it did more than one thing, it is because it didn't do them well.<p>I get it. People like simplicity. But the world is complex, everybody's view of the world is different, and that means that sometimes you just end up not being the target market. And I also get that some things actually do do one thing and do it extremely well. But trying to extrapolate that out infinitely across all things (or even just across all software things) just doesn't pan out in reality. And what does that mean for the philosophy? It should probably just be extended to "Do things well". But that is no longer a distinctive philosophy, is it?
It sounds like what he's actually arguing for is cohesion, not just simplicity. And if that's the case, I'm with him.<p>Cohesion is achieved when the degree of complexity is determined by both domain and audience, so Photoshop's relative complexity and Pixelmator's relative simplicity are both fine - in each case the domain is satisfactorily handled for the needs of the respective audience. They're both cohesive tools. Now if Photoshop decided to throw in a chat client (hello gmail), we'd be having a different conversation.<p>However, if the author is actually advocating breaking up Photoshop into a thousand pluggable little tools that everyone would have to piecemeal assemble into some sort of shared "workspace," that's where we (and most non-geeks) part company.
1. Unix shell solved one thing very well: (unary) function composition based on a text protocol. It gets complicated already when you want to beyond a pipe - e.g. A graph like a makefile. Then you need to leave the pipe metaphor in nost cases and deal with artifacts like files. Even more so, map-reduce was a big shift that went beyond the unic metaphor.<p>2. There was a different metaphor that had its merits: object composition through standard interfaces, e.g. OLE/COM and the likes. One might argue about its implementation (embedding a Visio object in a Word document still produces crashes, 25 years later), but as a UI metaphor it was very powerful.<p>3. The web's metaphor is coupling of disparate content through URLs and HTTP (and HTML). One of the most mind-boggling metaphors ever introduced to man (talk about doing one thing well). Today we use REST APIs as the atomic pieces (do one thing well) and Javascript/ObjectiveC/Java as glue. Same thing.<p>4. As for application it goes, "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp" (Greenspuns tenth rule). Slightly updated this means that as programs get more complex, they tend to become more integrated abd customizable, to the point where you use a high-level language to glue the different parts. If you're lucky they may have replaced a custom common lisp with a mature V8 engine, but the lore is still the same.<p>5. Outside of academia, people (product managers in particular) tend to be focused on solutions, not abstractions. And for good reason: solutions are often shortcuts for common applications of abstractions, and therefore they provide lots of value. File.ReadAllLines() vs. doing the same with 3-4 Java classes in the old days is the best example.<p>6. In the end, we need people to think about abstractions: unix pipes, map-reduce, URLs. And we need other people who think about solutions: The IPhone, the Google world etc.<p>7. As for the OP: curl might be a good start of a pipe. Add a program that parses tables, and a program that posts to REST APIs...
<i>> That philosophy was great, but hasn’t survived into the Web age.</i><p>The modern "web operating system" is Amazon's AWS, and I'd argue that the unix philosophy survived surprisingly well there. AWS has many services; each one does a specific job really well, and they interoperate very well together. That's the very embodiment of the unix philosophy.
I would like to propose a "cloud" addendum to Zawinski's law, which states that "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can".<p>My addendum is: "Every cloud app expands to the point where it can host group chat. Those apps which cannot so expand are replaced by ones which can."<p>I think it's also possible that I may have to augment the addendum to "group chat and screen sharing."
Unix pipes only work in the CLI with a text based interface and even then they break down when the applications aren't able to parse the data.<p>So one always ends up massaging the data to make them be understood.<p>Piping concept was actually more powerfull in Xerox PARC systems by using the respective language REPL and do LINQ style data transformations.<p>However the problem of the article is that once you scale out of the CLI, you need a standard communications API to this type of stuff.<p>One that is able work in distributed systems, dealing with all types of failure issues.<p>If anything, native programming on the mobile offers some kind of piping thanks to intents, contracts and extensions.
I am a great fan of the Unix philosophy and can sympathize with the author and his points, but I really don't know how realistic the whole "make the Internet a new Unix"-scheme is.<p>As others have pointed out, there are great practical difficulties in integrating different web services. Unix has pipes built into the core of the OS - anything analogous would have to be "bolted on" to the Internet, and thus probably turn out to be not as powerful or simple to use. And how about the UI and user friendliness? On Unix, every program has more or less the same UI - a couple of lines of text on a black background. The Internet? Everybody has a different fancy graphic layout. If you can do everything within the same "walled garden", that reduces confusion on this count.<p>For these (and other reasons, such as the aforementioned capitalism), I do not think that the mainstream Internet is ever going to behave the way the author envisions. What I could imagine, however, is a sort of parallel Internet that displays this property to some extent - a range of services explicitly targeting technical users (who are more likely to value the "do one thing well" approach and less likely to care if the GUI isn't quite as snazzy). These services would never grow big, but they could build up a loyal following. Kind of like HN, really...
I agree on the face of things, but what the web is missing from the unix philosophy is an equivalent to |.<p>Without the ability to string multiple, focused tools together even tools that did one thing well(i.e., Evernote) will continue to add features until it does a bunch of things meh.
There is some merit to "doing one thing well", but taken to the extreme it can be horrible in a different way:<p><i>tar cvf - FILE-LIST | gzip -c > FILE.tar.gz</i><p>(<a href="https://xkcd.com/1168/" rel="nofollow">https://xkcd.com/1168/</a>)
Since no one mentioned Plan 9, I thought I will mention one of the many features that makes Plan 9, one notch above Unix to make it easy in the web era.<p>In Plan 9, literally everything has a file abstraction. This also includes sockets. So, even shell programs can be network programs without external programs like curl or wget or anything like that. For anyone interested, look at webfs(4). You may say that this <i>can be</i> implemented with fuse. But having something first class, designed to operate well within the file abstraction, is very different from something that has been added as an afterthought. In some sense, the BSD folks who added sockets into Unix really screwed it up and missed the Unix philosophy altogether.
Ironically, his own blog includes a screen reader that appears whenever you select some text. Don't blind people already have good screen readers? I select text to remind me the place I'm up to, and get annoyed when little buttons pop up.
economic incentives typically lead firms to look for new sources of revenue. they hope to achieve this extra revenue with minimal cost, ideally by not creating new products or developing new customer relationships. the natural side-effect of this situation for software companies is that they add feature-upon-feature to existing products in an endless quest for growth. at the very end of the road this situation doesn't usually work out well for the product, the user, or the company.<p>on the other hand there are plenty of services/applications that keep stable interfaces for many years at a time. they do not extend themselves too far beyond solving the problem they originally tried to solve. we can all imagine what craigslist would look like in the hands of short-term profiteers, endlessly tweaking the interface for more ad clicks and "user engagement".<p>the success of sites like the original google search, craigslist, and HN proves that the "do one thing, keep it simple" model is successful and can often be very profitable in the long term. sadly, it is very easy to forget about such ideals when people are constantly dangling fresh money in your face and/or you have salaries to pay. while page rank might be considered the key element to google's genesis and explosion, we also owe much respect to the people that decided and continually insisted that the UI stay clean and minimal.
There is always <iframe>. You can easily embed a youtube or vimeo video even if your core product is not displaying videos. I always felt that iframe is a bit of lost potential, what it needs is a javascript api so that you can communicate back and forth with the frame/plugin, last time I checked this was not allowed due to same origin policy.<p>After the communication channel is in place it needs a few standard interfaces, maybe there could be some video player interface with play/pause/seek functions. These dont have to be included in any w3 standard, its more of a de facto standard or agreement that if you make a video player and don't implement the IAwesomeVideoplayerInterface, websites will not allow embedding of your product.<p>What's sad is that it seems like vendors are trying to move away from this model, Facebook is the prime example of this with hosting of a copy of embedded videos and displaying linked news inline in their own format.
IMO there is a limited market for mature ideas that is often much smaller than the previous prediction. When startups start meeting this boundary, instead of reigning in expectations and become an efficient tool serving a small market, it's "go big or go bust" with desperate attempts to validate the previous market size predictions.<p>Sooner or later, you're bumping into the markets of other companies and it's impossible to compete against them b/c you're using your weaknesses against their strengths.<p>There is only so much money and attention (time) in the world for people to spend on things. The low hanging fruit in developed countries has already been plucked clean so it's quite hard to 'grow' new markets. Your new tv series better be REALLY good if you're competing with game-of-thrones and breaking-bad.<p>Interestingly enough, the Chinese companies actually have many more features and are often better (for their users) than the american counterparts. The population is more homogenous and has more of a crowd mentality. Network effects are huge. Monopoly-like companies also prevent too much fragmentation meaning technology as a tool becomes standardized. Rather than 20 different things competing for the attention of everyone, there is one big company with apps that do everything that is trusted and reliable and thus the 'best'.<p>While american companies compete for slices of a certain size of pie, one chinese company owns the entire huge pie. As long as the users have pie, they are happy.<p>In allocation of limited resources, this usually fails as equal distribution of resources leaves everyone poor which creates huge incentive for corruption and hoarding. For abundant resources that can be duplicated infinitely and have network effects to boot this is perhaps a better strategy.<p>After all, it's all about everyone having an abundance of pie, not who has more or less pie.
There is nothing inherently wrong with complexity. Complex things can be made to appear simple, usable and open too. It is just that, when it comes to software, we haven’t yet figured out a way of building complex systems that are beautiful (in a very broad sense of the term). Whenever we try to create anything complex in software it inevitably turns into a mess.<p>Also software engineering sounds unglamorous today and research in the field seems to have stalled. And therefore the craving for the simplicity of the Unix philosophy. Not that the Unix way of working actually solves the problems posed by software complexity, it just asks us to avoid complexity.
> The first person to create a tool that can pipe a table from a browser into a spreadsheet...<p>Wait a minute. This is called the clipboard. Try it -- you can just copy and paste the table into a Google Doc and it Just Works. What's missing?
Evernote never even did the one thing well. I would add an item to a list on my computer, and then later add another one on my phone, and the next day both sources would be missing one of the edits.
Hardware suffers from the same "walled garden" mentality. Why the heck would I want a "smart TV"? A TV exists to display video. It should have lots of inputs and maybe some outputs for audio. If I want to get video from a VCR, a flash drive, or a web service, I should be able to plug in a device to do that. And unplug it when it becomes obsolete.
> I’ve been lamenting the demise of the Unix philosophy: tools should do one thing, and do it well.<p>1983 was a while ago: <a href="http://harmful.cat-v.org/cat-v/" rel="nofollow">http://harmful.cat-v.org/cat-v/</a>. That's a long time to lament something.
>The first person to create a tool that can pipe a table from a browser into a spreadsheet, a Google doc, or even a text file without massive pain will be my hero.<p>Pigshell.com
Everyone wants to be the walled garden <a href="https://xkcd.com/927/" rel="nofollow">https://xkcd.com/927/</a>
"That philosophy was great, but hasn’t survived into the Web age."<p>As one who still writes shell scripts for my work that do such a thing, and programs, too, I disagree as every Unix and BSD coder I know still does these things. It still serves us very well; far better than the glut of so-called package managers that pretend they can do better than 'make'.<p>I chalk a large portion of this up to those creating web pages without any real programming knowledge, training or background. Those who only know how to cut/past/npm everything they do. These are the same who think Unix is old and not modern.<p>I took an interview with a small company yesterday. There the creative director asked me what tools I knew and spewed out everything but the kitchen sink that they use. I was aware of all of them but questioned why he needed any of them.<p>You see, I've been running a web dev company for 11 years and have never found an advantage to any of it. He asked how we survived without npm or bower or etc. but, when I asked him if he knew how to write a Makefile, he didn't even know what it was or what it did.<p>A lot of the tools we use are things we built up over time ... or last week. Today's "modern" tools may be "instant on" for those who can't write a Makefile either but that's a fault and not a feature. If you need npm or bower to manager these things then what happens when something breaks, goes away, or becomes unsupported?<p>I stuck with npm and bower cause, when I tried to write about Angular and other things it got too long winded.<p>One of my points is, all the tools you need are already built into any Unix/BSD system so why look elsewhere? Those who do are only looking for quick fixes, as I pointed out earlier, and not interested in the science behind it. Creatives who want to build a web site but have no interest in the technology. They can get it to work, eventually, but "it works" is good enough.<p>No it's not. That's why smart companies hire mine.
People mean a lot of things when they say "one thing". "Do one thing" can mean "replace all occurrences of one string with another". Or it could mean "browse the web", which of course isn't really one thing but a thousand things.