玻璃市警句#22 的意义
From Epigrams in Programming by Alan J. Perlis:
22. A good system can't have a weak command language.
What does this mean? What are good examples of this principle?
Where can I learn more on how to implement a command langauge that meets this criteria?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您必须了解制定该内容的一些背景。链接的文章于 1982 年才发表，其中任何一篇警句都可能有几十年前的历史。然而，即使 1982 年也比我的时代早，我对当时的相关印象是：
“命令语言”只是意味着 shell 脚本今天。请记住，在 shell 提示符处输入“commands”。
抛开这些基础知识，这是我在谈论 The Unix Way™。
相比之下，Windows 程序在自动化方面要困难得多，而且许多程序（甚至操作系统）需要 GUI 来更改某些设置。 （对于 Microsoft PowerShell 的态度有所改变，但它仍然缺少其他操作系统在遵循这一原则方面数十年的经验。）
此外，当任何用户的基本操作模式是你系统的命令语言（就像 1982 年的 Unix 一样），那么你的命令语言在另一个方面很强大：所有用户都知道如何使用它，而不必学习单独的工具。在这种情况下，系统所能做的事情都是命令语言无法完成的，因为命令语言实际上就是系统。
据我所知，没有任何资源可以阐明所有这些想法，并且您可以将其用作实现您自己的命令语言的路线图。这个概念比写在石头上更空灵，就像其他警句一般也是如此。我鼓励您阅读一般的 Unix、shell（例如 POSIX 的 sh 标准，以及 bash 等其他标准）、其他 shell 脚本语言（任何带有 shebang 行的语言，例如 Perl 和 Python）等等。
You have to know some of the context in which that was formulated. The linked article was only published in 1982 and any single one of those epigrams could be decades older. However, even 1982 was before my time, and my relevant impressions of then are:
The "command language" just means shell scripting today. Remember that at a shell prompt you enter "commands".
Those basics out of the way, this is speaking to me about The Unix Way™.
Compare to how Windows programs can have a much harder time with automation and many programs (and even the OS) require a GUI to change some settings. (The attitude towards that is somewhat changing with Microsoft PowerShell, but it's still missing the decades of experience in following this principle that other operating systems have.)
Futhermore, when the basic mode of operation for any user is your system's command language (as it was for Unix in 1982), then your command language is strong in another way: all users know how to use it and don't have to learn separate tools. In that situation there's nothing the system can do which the command language can't accomplish, because the command language effectively is the system.
I know of no single resource that spells out all of these ideas and that you can use as a roadmap to implement your own command language. The concept is more ethereal than written in stone, as the other epigrams also are in general. I encourage you to read about Unix in general, shells (e.g. POSIX's standard for sh, and others such as bash), other shell scripting languages (anything with a shebang line, such as Perl and Python), and so forth.