问Unix的理念是否在Ruby社区中失宠了？

EN

管道和简单工具的Unix哲学是用于文本的。它仍然是相关的，但可能不像以前那么相关了：

• 我们看到越来越多的工具，它们的输出在设计上并不容易被其他程序解析。
• 我们看到越来越多的XML，在这些工具中，通过筛选器传输文本没有什么特别的好处，而正则表达式则是一场冒险的赌博。
• 我们正在看到更多的交互性，而在Unix管道中，信息只是单向流动的。

但是，尽管世界发生了一点变化，我仍然同意Korn的批评。创建不能与其他程序互操作的大型、整体式程序绝对是糟糕的设计，无论使用哪种语言。规则一如既往：

• 记住，你自己程序的输出可能是另一个程序的输入。
• 如果你的程序处理单一类型的数据(例如，学生提交的代码的性能，这是我上周一直在做的)，请确保对该数据的输入和输出使用相同的格式。
• 为了与现有Unix工具进行互操作，输入和输出应该是ASCII码和面向行的。许多IETF Internet协议(SMTP、NNTP、HTTP)都是编写大程序的标准examples.
• Instead，考虑编写几个小程序通过shell管道与现有程序连接。例如，不久前，xkcd blog有一个可怕的管道，可以在/usr/share/dict/words.
• Work中查找变形词，直到逐渐变成shell脚本，使您的交互式shell也可以用来编写脚本。(我使用的是ksh，但任何与POSIX兼容的shell都是一个合理的选择。)

总之，有两种高度相关的重用代码的方法

• 编写的小程序在通过外壳管道连接时能够很好地结合在一起(Unix).
• Write小型库在通过import、#include、load、require或use (Ruby、C++ STL、C Interfaces and Implementations和许多其他)连接时能够很好地结合在一起。

在第一个范例中，依赖关系结构很简单(总是线性的)，因此很容易理解，但您可以表达的内容更有限。在第二种范式中，您的依赖结构可以是任何非循环图-更具表现力的图，但这包括创建不必要的复杂性的能力。

这两种范式仍然是相关和重要的；对于任何特定的项目，您选择哪一个更多地与您的客户和您的起点有关，而不是与该范式的任何内在优点有关。当然，它们并不是相互排斥的！

我认为，随着Emacs的创建，Unix哲学开始失宠。

我投赞成票。主观的，但优秀的编程问题。

这只是一段个人趣闻，当时我们正在为保险公司重写一个批量打印输出程序。我们因为在shell中“编程”而被顾问责备。我们意识到它是如何脱节的，语言也是如此的不同以至于不完整。

也许吧。

突然之间，多处理器Intel boxen变得司空见惯，而fork()在新的应用程序时代(想想VB时代)并没有像每个人总是被警告的那样糟糕。批量打印程序(查询数据库，转换为troff输出，然后通过msgsnd转换为PostScript，然后以数十万计输出到LPD队列)在所有系统上都能很好地扩展，并且在VB运行时发生变化时不需要重写。

Perl回答你的问题：我同意Korn先生的观点，但这不是Perl的错，是Perl程序员认为Perl就足够了。在多进程系统中，它可能已经足够好了。

我希望Ruby、Perl、Python甚至Java开发人员都能在shell管道中保持优势。隐式扩展和接口、职责分离和模块化设计的开发哲学具有内在价值。

如果处理得当，随着我们的大规模核心处理单元的出现，Unix哲学可能会再次获得支持。