（感谢 @文艺复兴记（todd） 投递此文）
几个小伙伴在考虑下面这个各个语言都会遇到的问题：
问题：设计一个命令行参数解析API
一个好的命令行参数解析库一般涉及到这几个常见的方面：
1) 支持方便地生成帮助信息
2) 支持子命令，比如：git包含了push, pull, commit等多种子命令
3) 支持单字符选项、多字符选项、标志选项、参数选项等多种选项和位置参数
4) 支持选项默认值，比如：–port选项若未指定认为5037
5) 支持使用模式，比如：tar命令的-c和-x是互斥选项，属于不同的使用模式
经过一番考察，小伙伴们发现了这个几个有代表性的API设计：
1. getopt()：
getopt()是libc的标准函数，很多语言中都能找到它的移植版本。
(58 人打了分，平均分： 4.03 )
Loading...感谢@weidagang （Todd）向酷壳投递本文。
程序设计语言的抽象机制包含了两个最基本的方面：一是语言关注的基本元素/语义；另一个是从基本元素/语义到复合元素/语义的构造规则。在C、C++、Java、C#、Python等通用语言中，语言的基本元素/语义往往离问题域较远，通过API库的形式进行层层抽象是降低问题难度最常用的方法。比如，在C语言中最常见的方式是提供函数库来封装复杂逻辑，方便外部调用。
不过普通的API设计方法存在一种天然的陷阱，那就是不管怎样封装，大过程虽然比小过程抽象层次更高，但本质上还是过程，受到过程语义的制约。也就是说，通过基本元素/语义构造更高级抽象元素/语义的时候，语言的构造规则很大程度上限制了抽象的维度，我们很难跳出这个维度去，甚至可能根本意识不到这个限制。而SQL、HTML、CSS、make等DSL（领域特定语言）的抽象维度是为特定领域量身定做的，从这些抽象角度看问题往往最为简单，所以DSL在解决其特定领域的问题时比通用程序设计语言更加方便。通常，SQL等非通用语言被称为外部DSL（External DSL）；在通用语言中，我们其实也可以在一定程度上突破语言构造规则的抽象维度限制，定义内部DSL（Internal DSL）。
本文将介绍一种被称为流畅接口（Fluent Interface）的内部DSL设计方法。Wikipedia上Fluent Interface的定义是：
A fluent interface (as first coined by Eric Evans and Martin Fowler) is an implementation of an object oriented API that aims to provide for more readable code. A fluent interface is normally implemented by using method chaining to relay the instruction context of a subsequent call (but a fluent interface entails more than just method chaining).
下面将分4个部分来逐步说明流畅接口在构造内部DSL中的典型应用。
如果要输出0..4这5个数，我们一般会首先想到类似这样的代码：
//Java
for (int i = 0; i < 5; ++i) {
system.out.println(i);
}
(19 人打了分，平均分： 2.74 )Loading...[ ———— 感谢 Todd 同学 投递本文，原文链接 ———— ]
话题从下面这段C++程序说起，你认为它可以顺利执行吗？
//C++
class A {
public:
void Hello(const std::string& name) {
std::cout << "hello " << name;
}
};
int main(int argc, char** argv)
{
A* pa = NULL; //!!
pa->Hello("world");
return 0;
}
试试的确可以顺利运行输出hello world，奇怪吗？其实并不奇怪，根据C++对象模型，类的非虚方法并不会存在于对象内存布局中，实际上编译器是把Hello方法转化成了类似这样的全局函数：
void A_Hello_xxx(A * const this, const std::string& name) {
std::cout << “hello “ << name;
}
对象指针其实是作为第一个参数被隐式传递的，pa->Hello(“world”)实际上是调用的A_Hello_xxx(pa, “world”)，而恰好A_Hello_xxx内部没有使用pa，所以这段代码得以顺利运行。
如果是研究C++对象模型，上面的讨论可以到此为止，不过这里我想从另一个层面来继续探讨这个问题。OOP的先驱人物Alan Kay在总结Smalltalk的OO特征时强调：
(13 人打了分，平均分： 3.92 )Loading...不知道大家有没有注意到StakeOverflow的404错误页面？其显示了下面的这个图片：
这个是一个很有意思的图片，不知道你看懂了吗？看上去像Python，又像 Ruby，还像 Perl，当然也有 C的影子，还有Brainfuck。是的，这是一个杂交程序，杂交了Python，Ruby，Perl，C，还有Brainfuck（注意其中的#号），所有的语句都是输出“404”字符串。
关于这种杂交程序，本站以前也发布过《C语言和sh脚本的杂交代码》，大家可以前往一看。这样的有趣的玩法叫“Polyglot”，也就是说，把N种语言写在一个文件中，然后，该文件在任何编译器下都可以运行，上述的那段代码在Python，Ruby，Perl，Brainfuck下都可以正常运行，也可以被C和的编译器编译通过，并被运行。
下面是这个图片的字符码，以供各位试试。
(16 人打了分，平均分： 4.13 )Loading...下图是一个搞笑的图片——程序员眼中的编程语言。
比如说，
其它的大家自己看吧。还有另外一个关于操作系统的《粉丝眼中的操作系统》
(26 人打了分，平均分： 4.31 )Loading...
以前酷壳发布过《操作系统航空公司》戏谑了一下如果操作系统是航空公司会怎么样的一种情况。现在，我们来YY一下编程语言，如果编程语言是汽车，又会怎么样？
(14 人打了分，平均分： 4.00 )Loading...一说起Unix编程，不必多说，最著名的系统调用就是fork，pipe，exec，kill或是socket了（fork(2), execve(2), pipe(2), socketpair(2), select(2), kill(2), sigaction(2)）这些系统调用都像是Unix编程的胎记或签名一样，表明着它来自于Unix。
下面这篇文章，将向大家展示Unix下最经典的socket的编程例子——使用fork + socket来创建一个TCP/IP的服务程序。这个编程模式很简单，首先是创建Socket，然后把其绑定在某个IP和Port上上侦听连接，接下来的一般做法是使用一个fork创建一个client服务进程再加上一个死循环用于处理和client的交互。这个模式是Unix下最经典的Socket编程例子。
下面，让我们看看用C，Ruby，Python，Perl，PHP和Haskell来实现这一例子，你会发现这些例子中的Unix的胎记。如果你想知道这些例子中的技术细节，那么，向你推荐两本经典书——《Unix高级环境编程》和《Unix网络编程》。
(12 人打了分，平均分： 3.33 )Loading...--enable-pthread 有关问一下 Ruby 黑客怎么简单地增加一个线程的Ruby应用程序的性能。也许，这些黑客会告诉你，“小伙，每个人都知道在编译Ruby的时候你需要使用configure 的 --disable-pthread参数”。没错，在configure --disable-pthread 可以让你得到大约 30% 性能提高。但是，这是为什么呢？
所有的这一些我们需要使用 strace 工具，这个工具可以打出所有的真实的操作系统的调用。
下面，是一段我们测试的例程：
(7 人打了分，平均分： 2.43 )Loading...这是一本免费的关于教你如何使用Ruby编程的电子书。作者：Huw Collingbourne， SapphireSteel Software 公司的Technology Directory，他也是一个开发 Visual Studio下的Ruby Steel IDE的程序员。这本书给大家提供非常全面的教程，其涵养了几乎所有主要的Ruby编程的东西。
每一章的代码都可以被下载。如果你是一个 Ruby In Steel 的用户，那么，你可以在一个单一的Visual Studio solution 中载入这些代码，并可以在集成的 Ruby Console 上运行这些代码，并调试之。
(7 人打了分，平均分： 3.29 )Loading...EDC（Evan Data Corporation）发布了一份脚本语言的调查报告，这个调查报告调查了500个以上的开发者和IT专家，在这份调查表中，PHP, Ruby和Python成为了前三强。这个调查总共调查了这些脚本语言：Actionscript, Flex, Javascript, Microsoft F#, Microsoft Powershell, Perl, PHP, Python, Ruby, VB Script。主要评估以下这些方面：
(7 人打了分，平均分： 3.14 )Loading...
