书号

如今我很少编写生产代码，但我仍然花很多时间编写代码。这些代码是一种特殊的代码形式，用于在书籍中解释想法。书本代码与真实代码略有不同，在编写时需要考虑一些不同的因素。

一个问题是语言的选择。我需要用尽可能多的读者能够阅读和理解的语言来编写代码。我试图写一些与平台无关的想法，但我需要代码精确。因此，我需要选择一些人们可以理解的广泛可读的语言。

在我早期的日子里，两种最大的面向对象语言是 Smalltalk 和 C++。两者都有缺陷，Smalltalk 对非 Smalltalk 用户来说太奇怪了，而 C++ 充满了难以掌握的尖锐边缘。Java 对我来说是一个天赐之物。任何有 C/C++ 背景的人都可以阅读它。即使大多数 Smalltalk 用户也可以忍住鼻子，理解我正在编写的代码。这就是重构书籍用 Java 编写的理由。

后来出现了 .NET。这里的好处是 C# 与 Java 几乎相同，所以我可以在两者之间相当自由地使用。我喜欢同时使用它们来强调我正在写到的想法在两种情况下都有用。

这种情况现在变得越来越困难，特别是在编写关于 领域特定语言 时。Java 和 C# 正在分化，而我想要说明的一些事情需要它们都没有的功能。我大部分个人编程都在 Ruby 中进行，它非常适合 DSL，因此我将使用 Ruby 作为这种情况下的首选。但其他语言也有贡献。我需要在说明各种语言的 DSL 功能和让书籍成为语言片段的大杂烩之间取得平衡。

书本代码的另一个问题是注意不要使用语言的模糊功能，这里模糊是指对我的普通读者而言，而不是对精通我正在使用的语言的人而言。一个很好的例子是，当我编写使用 Ruby 的示例时，我经常回避使用 集合管道，即使我在自己的 Ruby 代码中大量使用它们。这是因为我认为来自大括号背景的程序员会发现理解这些类型的表达式更难。因此，我牺牲了流畅的 Ruby 来接触这些读者。

同样，这对 DSL 书来说更难。内部 DSL 往往依赖于滥用原生语法来获得可读性。这种滥用很大程度上涉及语言的怪异角落。我再次需要在显示可读的 DSL 代码和沉迷于怪异之间取得平衡。