似乎提醒可以同样适用于Ruby社区。 Ruby通过popen，STDIN，STDOUT，STDERR，ARGF等与其他Unix工具配合使用，具有很强的功能，但是Rubyists越来越多地选择使用Ruby绑定和Ruby库并构建单片Ruby程序。
我明白，在某些情况下，在一个Ruby进程中可能会出现性能原因，并且在一个Ruby进程中执行所有操作，但是确实有很多离线和异步任务可以很好地处理Ruby程序与其他小程序在Unix时代，这个方法提供了所有的优势。
也许我只是缺少一些明显的东西。 Unix哲学与10年前的今天仍然如此相关吗？
>我们看到更多的工具，其输出不能被其他程序容易解析。
>我们看到更多的XML，通过过滤器来管道文本没有特别的优势，而正则表达式是冒险的赌博。
>我们看到更多的交互性，而在Unix管道中，信息只在一个方向上流动。
但是尽管世界发生了一些变化，但我仍然同意科恩的批评。无论什么语言，创建大型，单一的程序是绝对差的设计，无法与其他程序互操作。规则与以往一样：
记住你自己的程序的输出可能是另一个程序的输入。
>如果您的程序处理单一类型的数据(例如，由学生提交的代码执行，这是我在上周所做的工作)，请确保对该数据的输入和输出使用相同的格式。
>为了与现有的Unix工具进行互操作，输入和输出应为ASCII和面向行。许多IETF Internet协议(SMTP，NNTP，HTTP)都是纯粹的例子。
而不是编写一个大的程序，考虑用shell管道编写与现有程序相关的几个小程序。例如，在xkcd blog之前，有一个可怕的管道在/ usr / share / dict / words中找到卦。
通过制作你的交互式shell，你也可以用脚本来逐步处理shell脚本。 (我使用ksh但是任何POSIX兼容的shell是一个合理的选择。)
总而言之，真正有两种高度相关的方式来重用代码：
>通过shell管道(Unix)连接时编写一个很好的组合的程序。
>通过import，#include，load，require或use(Ruby，C STL，C Interfaces and Implementations等等)连接时，编写可以很好地组合的小型库。
在第一个范例中，依赖关系结构很简单(总是线性的)，因此易于理解，但是您在表达方式上的限制更为有限。在第二个范式中，您的依赖关系结构可以是任何非循环图 – 更具表现力的功能，但这包括创建无偿复杂性的能力。
两种模式仍然是相关和重要的;对于任何特定的项目，您选择哪一个更多与您的客户和您的起点相比，具有范式的任何内在优点。当然他们不是互相排斥的！
