深入剖析Unix编程的挑战与困境
在编程的世界里，不同的语言和工具都有着各自的特点和挑战。今天，我们就来深入探讨一下Unix编程中遇到的种种问题。
解析器编写的语言差异
编写递归下降解析器时，语言的选择会带来巨大的差异。用C语言编写Lisp的递归下降解析器大约需要250行代码，而如果用Lisp本身来编写，可能连一页都写不满。这让人不禁思考，过去的程序员为何会设计、实现和推广那些难以解析的语言。也许他们是为了创造开放性的研究问题，编写这些难解析语言的解析器在当时看来是个不错的选择。
C程序解析的复杂性
编写一个解析C程序的程序，以确定哪些函数调用了哪些函数，以及全局变量在哪里被读取和修改，这相当于实现一个C编译器的前端。然而，C编译器前端是非常复杂的，C语言本身的复杂性以及使用像yacc这样的工具的难度，使得很少有人愿意去编写这样的程序。
一些Unix的忠实爱好者会认为，使用grep工具就可以解决问题，而且还能在shell管道中使用。但实际上，grep会找到所有包含特定字符串的地方，可能会包含很多无关的内容。例如，在查找BSD内核代码中min函数的所有使用时，grep会返回很多包含“min”但并非函数调用的行。
理想编程工具的缺失
理想的编程工具应该既能够快速、轻松地完成常见任务，又要有足够的能力处理超出预期的任务。但很多Unix工具在追求通用性时，忽略了简单易用这一点。
Make工具就是一个典型的例子。Make的输入本质上是一个依赖关系图的描述。依赖关系图中的每个节点都包含一组命令，当该节点相对于其依赖的节点过时了，就会执行这些命令。节点通常对应文件，文件的日期决定了它们是
