3 ms·
At least the "one tool for one job" part has been pronounced dead by Rob Pike himself. http://interviews.slashdot.org/article.pl?sid=04/10/18/1153211 http://in
by sid0 17y ago
At least the "one tool for one job" part has been pronounced dead by Rob Pike himself.
http://interviews.slashdot.org/article.pl?sid=04/10/18/1153211 http://interviews.slashdot.org/article.pl?sid=04/10/18/11532... question 8
- silentbicycle 17y agoIt's worth noting that when you set up a pipeline of processes, each can spawn on its own core. Setting up task-oriented processes is an idea that still has a lot of power in it, whether you're talking about the "lots of tiny C utilities" approach or something more like Erlang. While Pike doesn't mention it explicitly, I think the issue is that the context for "one tool per job" shifted from the shell (with Unix itself doing process management) to the Python runtime, the JVM, etc. This has its advantages and disadvantages. Working at the level of different processes, each can be written in its own language and rely on simple interfaces such as text-streams or structured files for communication. Within other contexts, everything can work with the same object system, process supervisor infrastructure, etc.
- sjs 17y agoPike says that Perl delivered the eulogy for "do one thing, do it well" but perhaps the scope of those things has just increased. Especially since there are so many viable scripting languages today it's more important than ever to create interoperable tools that can be plugged together, for code reuse sake. I think it's great that I can shell out to markdown.pl from a Python or Ruby program rather than rewriting it in the language I happen to be using that day. Let's not throw the baby out with the bath water. Code reuse is good, and so is doing things well.