我见过很多人抱怨 GNU Autotools 太复杂。事实上它比求解一元二次方程简单多了。学习 GNU Autotools，最好的办法就是动手搭建一个项目，然后根据自己的需求去查 GNU Autotools 的文档与教程，整个过程只是很简单的『加法』运算。

如果你对 UTF-8 编码不是非常了解，就不要试图在 C 程序中徒手处理 UTF-8 文本。如果你对 UTF-8 非常了解，就更没必要这样做。找一个提供了 UTF-8 文本处理功能并且可以跨平台运行的 C 库来做这件事吧！

有言在先，本文仅仅是从 C 语言的角度来看『接口』与『泛型』之间的关系，无意于证明 C 语言有多么『强大』，以致于它连『接口』与『泛型』都能支持，也无意于贬低那些从语法层面就支持接口与泛型的语言在贩卖概念。

主要是下半年，因为上半年的兴趣不在计算机与编程方面，而在与计算机与编程八杆子打不着的各种刀具方面——猎刀、战术刀、生存刀、口袋刀之类，最大的收获是学会了磨刀。改天失业了，就走街串巷磨剪子戗菜刀赖以糊口……

每一盒香烟的包装上都会写『吸烟有害健康』。白酒瓶上也写了『过度饮酒,有害健康』。本文的外包装上写的则是『阅读有害健康』，特别是『甩掉强迫症』那一节，它适合我自己阅读，但不一定适合你。

面向对象编程，面向设计模式编程（亦即设计模式），面向接口编程，面向模板编程（亦即泛型编程），面向函数编程（亦即函数式编程），面向多核时代的并行编程，面向大数据的机器学习编程……这么多年，大家要面向的东西已经够多了，然而我看到的现象是，很多编程语言让大家面向 xxx 的同时在竭力回避指针。我可不想面向这么...

在『Vala 语言中一些好玩的』中介绍了 Vala 语言的外在特征。那么 Vala 的内涵是怎样的？毕竟一门编程语言不能只图外表光鲜，它还得实用。衡量一种编程语言是否实用，主要就是看它的语法表现力以及所编写的程序的运行效率。

由于我对不同的编程语言涉足不广，因此文中我认为是好玩的东西可能在其他语言中早已存在。可以这样理解我说的『好玩』，由于 Vala 语言是编译到 C 的，因此凡是 C 语言中没有的东西，在我看来都可能是好玩的……这个基线可能真的是太低了，C 语言似乎除了指针之外，似乎没有什么特性 :)

对于自己定义的宏，建议先在你的大脑中对它进行逐步展开，确信自己完全理解这个展开过程。如果大脑的堆栈不够用，可以用纸和笔记录展开过程。这样可以在很大程度上提高宏定义的正确性。

现在再强调一次，m4 会将当前宏的展开结果插入到待读取的输入流的前端。也就是说，m4 会对当前宏的展开结果再次进行扫描，以处理嵌套的宏调用。这个性质决定了可以写出让 m4 累死的递归宏。

上一篇见：[链接] 注释符 # 符号是行注释符。不过，与我们所熟悉的注释文本不同，m4 的注释文本会被发送到输出流。例如： {代码...} 会被展开为： {代码...} 可以用 changecom 宏修改 m4 默认的注释符，例如 {代码...} 这样，@@ 就变成了注释符。 如果你需要块注释符，也可以做到，例如： {代码...} 如果不向 changecom ...

say_hello_world 是宏名，Hello World 是宏体。如果在宏定义之后的文本中出现了 say_hello_world，例如：

这个文档系列是我第一次认真学习 GNU m4 并进行了一些实践之后的一些总结。由于我在撰写此文的过程中充满着像 m4 展开一个又一个宏一般的耐心，因此这篇文章会比较长。在这个信息碎片化的时代，似乎没有很多人愿意去看很长的文章，大家更喜欢干货。为了节省大家的时间，必须声明，这个文档系列没有干货，它是写给我自己...

Autoconf 可以产生一份 Shell 脚本。对于大部分类 Unix 系统，这份 Shell 脚本能够自动配置软件源码包的构建环境。这份 Shell 脚本就是 Linux 系统中大名鼎鼎的 configure 脚本。

Donald Knuth 说：『选择 WEB 作为名字，部分因为它是英语中很少的几个没有用于计算机的三字词语之一。但随着时间流逝，我越来越喜爱这个名字，因为我认为最好把一个复杂的软件确确实实地看成由简单材料以精巧的方式拼出来的一张网。我们通过理解复杂系统的各个简单部分和这些部分与其直接邻居的简单关系来理解复杂系统...

文学编程的思想非常简单，就是将那些为了能被编译器/解释器正确识别而编写的代码打碎，然后用人类语言将它们编织到文档中，这种文档就是文学编程的源文件。这一概念第一次被完整的实现，是 Knuth 开发的 WEB 工具（此 WEB 并非现代漫天飞舞的那个 Web）。Knuth 的神作——TeX 系统便是借助 WEB 开发的。

这篇文章与『理解 GLib 的单元测试框架』一文有些渊源，因为后者在几个示例中使用了 libtool 产生库文件与应用程序文件。 田园时代 我要写一个叫做 foo 的库，它提供一个什么也不做的函数。这个库的头文件为 foo.h： {代码...} foo.c 是这个库的实现： {代码...} 用 gcc 编译生成共享库文件 libfoo.so： {代码...} 如果...

单元测试，那些似乎从来都不怎么有用的软件工程教科书里有关于它的确切定义。在本文中，只是将其视为检验某个函数是否正确的一种手段。可将单元测试想象为质检员，将要检验的函数想象为待出厂的零件。

现在，你已经知悉函子是什么了，并且也见识了它的一些例子。本文要做的事，是用一些小函子构造出大函子。更有趣的是，你可以看到哪种类型构造子（相当于一个范畴内部对象之间的映射）能够被扩展为函子（态射之间的映射）。

听起来是要破记录，我要讲讲函子：简单又强大的主意。范畴论中充满了这样简单又强大的主意。函子是范畴之间的映射。给定的两个范畴，C 与 D，函子 F 可以将 C 中的对象映射为 D 中的对象——函子是对象上的函数。如果 C 中有一个对象 a，它在 D 中的像即为 F a（省略了括号）。但是范畴中不仅仅存在对象，还有连接对象的态...

我们已经了解了两种类型组合方式：积与余积。编程中，仅通过这两种类型就可以构造出大部分数据结构。正是因为这一点，保证了数据结构的许多性质都是可复合的。例如，如果知道如何比较两种基本类型的值是否相等，并且知道如何将这种比较方法推广到积与余积类型，那么你就能够自动派生出支持相等运算的复合类型。在 Haskel...

古希腊剧作家 Euripides 曾说过：『每个人都像他尽力维护的同伴』。我们被我们的人际关系所定义。在范畴论中更是这样。如果想刻画范畴中的一个对象，只能通过描述这个对象与其他对象（或其自身）之间的关系模式来实现。

你已经见识了如何将类型与纯函数塑造为一个范畴。我还提到过，在范畴论中，有办法构造副作用或非纯函数。现在有一个像这样的例子：具有运行日志的函数。这种东西，用命令式语言可以通过对一些全局状态的修改来实现，像这样：

最小的范畴是拥有 0 个对象的范畴。因为没有对象，自然也就没有态射。这个范畴挺悲哀的，因为它只拥有自己。不过，对于其它范畴而言，它可能是挺重要，例如所有范畴的范畴（对的，有这么一个范畴）。如果你觉得空集是有意义的，那么为何会觉得空的范畴无意义？

关于静态 vs 动态，强类型 vs 弱类型，似乎存在着一些争论。下面我用一个思想实验让这些选择变得更直观一些。想象一下，无数只猴子在快乐的随机敲打着键盘，产生程序，编译，然后运行。

上一篇文章，即《写向程序猿的范畴论》的序言，发布之后得到的正面反馈让我有些不知所措。同时，它也激励了我，因为我感受到了大家付诸于我的殷切期望。不过，我担心的是无论我如何努力，依然众口难调。有些读者希望这本书偏于现实，有些人则希望它能抽象一些。有些憎恨 C++ 的人希望所有的示例都是 Haskell 的，而那些...

我打算为程序猿们写一本讲范畴论的书已经有一段时间了。注意，受众不是计算机科学家，而是程序猿——是工程师，而不是科学家。这听起来挺疯狂，我也有些诚惶诚恐，但是我无法容忍科学与工程之间存在着巨大的鸿沟，更何况我自身的工作也是经常需要我在这两个世界中穿梭。不过，要解释一些东西，总让我感觉非常窘迫。我非常...

当你用 Emacs 打开或新建一份扩展名为 .c 的文件时，Emacs 会自动开启内置的 C 模式。这个模式提供了语法高亮、自动缩进等基本功能。同时 Emacs 也允许用户深度定制符合自己使用习惯的代码编辑功能，前提是你需要对 Emacs Lisp 扩展语言有一定了解。

来我们这个实验室里读研的学生可能自从来到这里的第一天就觉得自己的命运很苦逼。他们读本科时主修的是机械设计、制造以及自动化之类的专业，毕业时的简历上也顶多是写写擅长 MS Word、PowerPoint、UGNX、AutoCAD 之类的应用软件。他们有限的学习生涯里，怎么也不会想到来到这里竟然要首先重新学习 C 语言，然后还要学 C...

写完『泛型与闭包』这篇文章后，暗自感慨了一番，要是 C 语言能够从语言层面支持闭包，而不是借助函数指针去进行繁琐的模拟，那么用 C 写程序就一定会有趣很多。