为什么Pascal不是我最喜欢的程序设计语言

 

为什么Pascal不是我最喜欢的程序设计语言
Why Pascal is Not My Favorite Programming Language

Brian W. Kernighan, April 2, 1981
AT&T Bell Laboratories,  Murray Hill, New Jersey 07974

翻译：[email protected]
为了学习计算机英语，我根据google的自动翻译，再加润色，本文并未完成，但我会随时更新，如有更好的翻译，请发给我。谢谢。

摘要
Pascal程序设计语言已成为计算机科学的教育教学的主要语言。它还强有力的影响了其后语言的开发，特别是后来的Ada语言。

Pascal最初的主要目的是作为教学语言，但它已被越来越多的被建议用来进行严肃的程序设计。而且，如对于系统程序设计任务，甚至是操作系统的编写。

Pascal，至少在它的标准形式，简单的说来，不适合进行严肃的程序设计。本文讨论了我个人的一些原因。

1. 起源

本文起源于两个事件：有大量的论文来比较C语言和Pascal（1，2，3，4）语言，和我个人决定用Pascal重写《软件工具》（5）一书。

比较C和Pascal是有点像比较Learjet（喷气式飞机）和Piper Cub（微型活塞式飞机），一个是获取工作，而另一种是学习如何工作。所以这种比较往往是有点牵强。但是，《软件工具》一书的修正版本会有更多相关的比较。那里的程序起始是用Ratfor语言编写，一个“结构化的”Fortran方言的预处理器实现。由于Ratfor是伪装的Fortran，它有一些Pascal的东西：数据类型更适合于字符处理，数据结构能力更强，和强类型用来强制数据的真实可靠。

结果是，用Pascal重写程序，比我预期的更难。本文就是试图提取有关Pascal的编程适宜性（不同于编程学习）的一些的经验教训。这不是拿C或Ratfor与Pascal进行的比较。

程序最早的应用是用pascal方言用来解释圆周率，由加州大学伯克得分校提供。语言接近Jensen和Wirth名义上的标准（6），具有良好的诊断和细心的运行时检查。此后，程序已经可以运行，除了新的基本函数库不用改变，还在其他四个系统：一阿姆斯特丹自由大学（以下简称VU为自由大学）的解释器，一个伯克利系统的VAX版本（一个真正的编译器），一个Whitesmiths责任公司供应编译器，和加州大学圣地亚哥分校在Z80上的Pascal。但所有这些Pascal系统最后都用C编写。

Pascal是讨论得最多的语言。最近书目（7）列出了175项讨论、分析和辩论的标题。最经常引用的论文（值得一读）是Habermann的强烈批判（8）和Lecarme和Desjardins同样强烈的反驳（9）。Boom和DeJong的文章（10）也是良好的读物。Wirth自己对Pascal的评价在[11]。我没有想要或能力来概括这些文字;本文代表我个人的意见和大部分重复别人提出的意见。我试着组织围绕问题的其他材料

    ·类型和作用域
    ·控制流
    ·环境
    ·修饰
   
并在每个方面或多或少减少顺序的重要性。

我先表示我的结论：Pascal可能是一种令人钦佩教初学者如何编程的语言；我没有第一手经验。这是1968年的一个相当大的成就。这无疑影响了最近的语言的设计，其中Ada很可能是最重要的设计。但在它的标准形式（包括现有的和计划的），Pascal不能足够的胜任编写真正的程序。它仅适用于小型的，独立的程序，并且与环境交互能力差。这使人写出的软件都没有多大用。

2. 类型和作用域
Pascal（差不多）是强类型语言。粗略地说，这意味着每一个程序对象具有良好定义的类型，它隐式的定义了操作对象的合法值。语言的保证，它会禁止一些非法值和操作，通过编译和运行时检查。当然，编译器可能不会完成所有的语言定义的隐含检查。此外，强类型不会与量纲分析相混淆。如果一个定义类型的'apple'和'orange'

    type
        apple = integer;
        orange = integer;

然后涉及apple和oranger的任意数学表达式，都是完全合法的。

强类型有不同的方式。例如，函数和过程的参数的类型匹配检查。在过去，Fortran自由的传递浮点参数到子程序会被认为是一个整数。我认为Pascal的这个特性是令人满意的，因为这样构造的话肯定会导致错误警告。

整型变量可以被声明为有一个范围的合法值，编译器和运行时支持确保一个大的整型变量不能放进一个小的整型变量，这也似乎是一种服务，虽然运行时检查是一种强制的处罚。

让我们继续前进的类型和作用域的一些问题。

2.1  数组的大小是其类型的一部分

如果一个声明

     var     arr10 : array [1..10] of integer;
             arr20 : array [1..20] of integer;

然后arr10和arr20分别是10和20个整数的数组。假设我们要编写一个过程'sort'来排序一个整数数组。由于arr10和arr20有不同的类型，它是不可能编写一个简单的过程来将它们排序。

这些地方会特别影响软件工具，我想一般的程序是，可以创建一个程序库，它可以真正的做一些一般的事和通用流行的操作，比如排序。

在特定的数据类型最常见的影响是 'array of char'，在Pascal的字符串是一个字符数组。考虑编写一个函数'index(s,c)'，将返回字符c在字符串s第一次出现的位置，如果它不存在就返回0。问题是如何处理'index'的字符串参数。调用"index('hello',c)"和调用"index('goodbye',c)"不能同时是合法的，因为字符串有不同的长度。 （我忽略的是如何检测像'hello'常量字符串结尾的问题，因为它不能。）接下来的尝试是

    var     temp : array [1..10] of char;
            temp := 'hello';

            n := index(temp,c);

但对赋值给'temp'非法的，因为'hello'和'temp'的长度不同。

从这个无限的倒退中逃脱的唯一方法就是要为每个可能的字符串的大小定义一个成员函数，或者使所有字符串具有相同长度的（包括常量字符串'define'）。

后一种方法是两大害中较轻的。在'Tools'中，'string'类型被声明为

     type    string = array [1..MAXSTR] of char;

其中常数“MAXSTR”是"足够大"，所有程序的所有字符串，都恰好正是这种大小。这是很不理想，虽然它使人们有可能获得程序的运行。它不解决创造真正有用的例程库的问题。

在一些情况下，根本不能接受的使用固定大小的数组表示。例如，使用'Tools'程排序文本行就要用一些文本行来填充内存，它的运行时间在很大程度上取决于如何充分的填充内存。

因此，对于'sort'，另一种是用来表示一个字符数组和一个到这个数组索引：

     type    charbuf = array [1..MAXBUF] of char;
             charindex = array [1..MAXINDEX] of 0..MAXBUF;

但是，过程和函数处理固定长度的形式不能使用可变长度的形式，一个完整的程序集需要复制和比较这种表示的字符串。这在Fortran或C中,一个函数就够了。

如上所述，一个常量字符串写成

     'this is a string'

并有型'packed array [1..n] of char'，其中n是长度。因此，不同长度的字符串具有不同的类型。唯一的方法是,把输出的消息都处理成一样的最大长度。

     error('short message                    ');
     error('this is a somewhat longer message');

许多商业Pascal编译器提供一个'string'的数据类型，来明确避免这个问题;'string'被视为同一类型而无论大小。这解决了这一单个数据类型的问题，仅此而已。但它也未能解决第二个问题，比如计算一个常量字符串的长度，另外，内置的功能是通常的解决方案。

Pascal爱好者经常声称，为应对数组大小的一个问题不过是复制一些库程序和填写参数的程序在手。但这种抵御的声音大都是微弱的：（12）

``由于数组的边界是类型（或更确切地说是它的索引类型）的一部分，它不可能定义一个过程或函数应用于数组的不同边界上。虽然这种限制可能会成为一个严重的问题，我们使用Pascal的经验表明，它发生的非常频繁。[...]然而，需要绑定的参数数组的大小是使用有关的程序库严重缺陷。''
这种笨拙是Pascal最大的一个问题。我相信，如果它能被修复，语言的应用将会扩大一个数量级。建议的ISO标准为Pascal（13）提供这样一种修复（``符合性数组模式''），但接受这个作为标准的一部分显然仍存在疑问。

2.2  没有静态变量和初始化

一个'static'变量（在使用Algol的地方通常被称为一个'own'变量）对一些程序是私有的，并保留其值从一个程序调用到下一个调用。事实上，Fortran的变量是内部静态的，除了COMMON;在C语言里“static”声明，可以应用到局部变量。 （严格地说在Fortran 77，必须使用SAVE强制静态属性。）

Pascal没有这样的存储类。这意味着，如果一个Pascal函数或过程打算从一个调用到另一个调用之间记住一个值时，必须使用具有外部变量的函数或过程。因此，对于其他程序它必须是可见的，其名称必须在更大的范围内是唯一的。这种问题的一个简单的例子是一个随机数发生器：用于计算输出值必须保存到计算下一个，所以它必须是一个变量，其生存期包含了随机数生成所有调用存储。实际上，这通常是最外层的程序块。因此，这样的变量声明是远离它实际使用的地方。

一个例子来自于《工具(Tools)》一书第7章所描述的文本格式化。变量 'dir' 控制从行调整插入多余的空白行，获得左，右交替插入的方向。在Pascal中，代码如下：

     program formatter (...);

     var
             dir : 0..1;     { direction to add extra spaces }
             .
             .
             .
     procedure justify (...);
     begin
             dir := 1 - dir; { opposite direction from last time }
             ...
     end;
             ...

     begin { main routine of formatter }
             dir := 0;
             ...
     end;

变量'dir'的声明、初始化和使用分散在各处，相距数百行。在C或Fortran里，'dir'可在程序需要时做成私用的：
              ...
     main()
     {
             ...
     }
             ...

     justify()
     {
             static int dir = 0;

             dir = 1 - dir;
             ...
     }

当然，还有一个更大的规模上相同的问题很多其他的例子，对函数缓冲I/O，存储管理和符号表中的所有映入脑海。
至少有两个相关的问题。Pascal没有提供方法来初始化静态变量（即在编译时），也没有什么类似于Fortran的DATA语句或类似的初始化：

     int dir = 0;

在C语言里，这意味着，一个Pascal程序必须包含明确的赋值语句来初始化变量，如：

     dir := 0;

这使得程序的源代码文本更大，而且在运行时体积也更大。

此外，缺乏初始化加剧了大范围的问题，这都归因于缺乏静态存储类。初始化的时机是在开始的时候，所以无论是主程序本身带有大量的初始化代码，或者调用一个或多个程序做初始化。在这两种情况下，要初始化的变量必须是可见的，这实际上意味着在层次结构的最高水平。其结果是，任何变量，必须在全局范围进行初始化。

第三个困难是，没有两个例程来共享一个变量的方式，除非它是至少达到或超过他们的共同祖先声明。 FORTRAN COMMON和C的外部静态存储类都提供了两个例程私下合作的方式，没有分享他们的祖先的信息。

新标准不提供静态变量，初始化或无层级的通讯。

2.3 相关程序的组件必须分开

由于原始的Pascal是用一单遍编译器实现的，语言坚信在使用前先声明。特别是，过程和函数必须先声明（函数体和所有），然后再使用它们。其结果是，一个典型的Pascal程序从下往上读 - 所有的程序和功能显示在代码的各级调用之前。其中的功能设计和使用的顺序基本上是相反的。
C和Ratfor的设施#include在一定程度上可以缓解：源文件可以在需要时导入进来,而不使程序杂乱。 #include不是标准Pascal的一部分，虽然UCB，VU和Whitesmiths编译器都提供了。

还有一种'forward'的声明，允许在Pascal分离的功能还是从机构的议事头声明，它是定义相互递归程序之意。当身体被声明以后，关于该声明头可能只包含函数的名称，不得重复从第一个实例的信息。

一个相关的问题是，Pascal有着严格的顺序，它愿意接受声明。每个过程或函数包括

label label declarations, if any
const constant declarations, if any
type type declarations, if any
var variable declarations, if any

procedure and function declarations, if any
begin
body of function or procedure
end

这意味着为了编译器的方便，类型的所有声明必须组合在一起的，即使程序员想保持在一起的逻辑相关，以便了解程序更好的东西。由于方案将提交给编译器一次全部，它几乎是不可能保持的声明，初始化和变量的类型和并拢的使用。即使是最敬业的Pascal的一些支持者同意：（14）
``由于无法使这些组件构建大型程序，这是Pascal的最令人沮丧的限制之一。'
一个文件包含工具帮助这里只有一点点。
新标准不放松对声明的顺序的要求。

2.4  不能分开编译（There is no separate compilation）

官方的Pascal语言不提供单独的编译，要做什么取决于实现。有些（例如伯克利的实现）完全禁止它，这是最接近语言的精神和字面意义上完全匹配的。许多人提供了一个声明，表示指定一个函数体外部定义。在任何情况下，所有这些机制不规范，不同的系统又不同。
从理论上讲，没有单独编译的需要 - 如果一个编译器是非常快的（如果所有程序源总是可用的，如果一个人的编译器有一个文件包含工具，而不需要源的多个副本），则重新编译一切是等价的。在实践中，当然，编译器永远不会足够快，而源通常是隐藏的，文件包含是不是语言的一部分，所以这种变化是费时的。

有些系统允许单独编制，但不验证跨边界类型的一致性。这将创建一个强类型的巨洞。 （大多数其他语言做无交叉编译检查要么??，所以Pascal没有这方面的劣势。）我已经看到至少有一个文件（大发慈悲未公布）上页严惩未能在单独的编译边界检查类型C同时建议第N +1的办法，以应付Pascal是编译程序分开，以避免类型检查。

新标准不提供单独编译。

2.5  类型和作用域的一些杂项问题（Some miscellaneous problems of type and scope）

以下几点大多是轻微的刺激，但我在某个地方坚持这几点。
这是不合法的名称，过程的文字名形参不是基本类型，下面是不允许的：

     procedure add10 (var a : array [1..10] of integer);

相反，我们必须发明一种类型的名称，做一个类型声明，并宣布正式参数是一个该类型的实例：

     type    a10 = array [1..10] of integer;
     ...
     procedure add10 (var a : a10);

当然，如果是类型声明是从过程上物理分离的。该发明的类型名称是对于那些经常使用的类型是有帮助的，但它是一个只使用一次的麻烦。
我很高兴可以声明“var”作为函数或过程的形参;过程中明确指出，它打算修改参数。但调用程序没有办法声明一个修改的变量 - 信息只在一个地方，而两地会更好。 （半个面包总比没有好，虽然 - Fortran告诉用户不需要变量。）

这也是一个小麻烦，数组是按值传递的默认-净效果是，每个数组参数声明“VAR”所没有的思维程序员或多或少。如果“VAR”申报不小心忽略，由此产生的错误是潜移默化的。

Pascal的“set”构造似乎是一个好主意，概念上的便利，并提供一些免费的类型检查。例如，一组测试，如

    if (c = blank) or (c = tab) or (c = newline) then ...

可写，而更清楚，也许更有效地为

     if c in [blank, tab, newline] then ...

但在实践中，集合类型是没有用的远不止这些，因为一个集大小强烈依赖于实现（可能是因为它是在原来的疾病预防控制中心的执行情况，59位）。例如，它很自然地尝试写功能“isalphanum（三）”（``是c字母？''）作为

     { isalphanum(c) -- true if c is letter or digit }
     function isalphanum (c : char) : boolean;
     begin
             isalphanum := c in ['a'..'z', 'A'..'Z', '0'..'9']
     end;

但在许多实现Pascal（包括原）这段代码会失败，因为集只是太小了。因此，一般最好设置闲置如果打算编写可移植程序。 （这个具体的例行还运行了一个数量级的集速度比射程试验或数组的引用。）

2.6  没有逃脱

在必要时没有覆盖类型的机制，没有类似C语言的"cast（转型）"机制，这意味着它是不可能用Pascal写出这样的存储分配器或I/O系统的方法，因为没有这样谈论的对象的类型，他们的回报，也没有办法强迫到另一个使用任意类型的对象等。 （严格地说，是有近似变量记录的类型检查是个大漏洞，使得一些其他形式的非法类型可以匹配。）

3. 控制流

Pascal控制流的缺陷是次要的，但很多 - 无数个死亡点，而不是单一的朝向至关重要的地方。
不存在的逻辑运算符“and”与“or”来保证求值的顺序 -不像在C里的&&和无||，它会与大多数其他语言共享，伤害通常在于闭环控制：

     while (i <= XMAX) and (x[i] > 0) do ...

使用Pascal是极不明智的，因为没有办法保证，i是在X[i]之前测试的。

顺便说一下，在这个代码中的括号是强制性的语言已与底部有关联的只有四个运算符优先级的水平。

退出循环没有“break”为语句。这与结构化编程的支持者所信奉的一个入口，一个出口的理念一致，但它确实导致累赘或重复的代码，特别是在与无法控制的，其中的逻辑表达式的计算顺序耦合。考虑这种常见的情况，在C或Ratfor表示：

     while (getnext(...)) {
             if (something)
                     break
             rest of loop
     }

由于没有“break”语句，使用Pascal的第一次尝试是

     done := false;
     while (not done) and (getnext(...)) do
             if something then
                     done := true
             else begin
                     rest of loop
             end

但是这样并不能工作，因为没有办法迫使“not done”是前“getnext”下次调用评估。这导致，经过多次错误的开始，到

     done := false;
     while not done do begin
             done := getnext(...);
             if something then
                     done := true
             else if not done then begin
                     rest of loop
             end
     end

当然惯犯可使用“goto”和一个标签（数字仅它必须声明）退出循环。否则，提前退出是一个痛苦，几乎总是需要一个布尔变量的发明和一定量的狡猾。比较发现在一个Ratfor数组的最后一个非空白：

     for (i = max; i > 0; i = i - 1)
             if (arr(i) != ' ')
                     break

使用Pascal：

     done := false;
     i := max;
     while (i > 0) and (not done) do
             if arr[i] = ' ' then
                     i := i - 1
             else
                     done := true;

一个'for'循环指数为外循环定义，所以它不可能找出一个人是否到了最终还是没有。一个'for'循环增量只能是+1或-1，未成年人的限制。
有没有“回报”的说法一出原因再于一身。函数返回值通过设置一个伪变量（如FORTRAN）值，然后脱落函数结束。这有时会导致扭曲，以确保所有路径实际得到的与正确的价值函数结束。也没有标准的方法来终止除非到达最外层块结束的执行，虽然许多实现提供了一个“停止”，导致立即终止。

在“案例”的说法是更好的设计比C，除了没有“default”条款和行为是不确定的，如果输入的表达式不匹配任何个案。这一重要遗漏呈现“案例”构造几乎一文不值。在超过6000行Pascal在“Software Tools in Pascal(Pascal软件工具)”，我用它只有四次，但如果出现了一个“default”，一个“case”将服务至少在十几个地方。

新标准的机制对这些问题没有任何的帮助。

4. 环境

在Pascal运行时环境相对稀少，而且没有扩展机制，也许除了“官方”语言的源码库机制。

Pascal的内置I/O有一个当之无愧的坏名声。它坚信面向记录的输入和输出。它也有一个超前约定交互环境中是很难实现的。基本上，问题是，I/O系统认为，它必须读取正在处理的记录一个记录之前。在一个互动系统，这意味着，当一个程序启动时，它的第一个操作就是尽量阅读前，本身已执行程序的任何为输入的第一线终端。但在计划

     write('Please enter your name: ');
     read(name);
     ...

预读导致程序挂起，等待输入打印前的提示，它要求。
它可以逃脱这个I/O设计的恶果最受非常认真执行，但不是所有的Pascal系统，这样做，而且在任何情况下，它是相对昂贵。

在I/O设计体现了原有的操作系??统赖以Pascal的设计，甚至沃斯承认偏见，虽然不是它的缺陷（15）假设该文本文件的记录组成，也就是说，文本行。当一行的最后一个字符被读取后，内置的功能“eoln”变为真;在这一点上，我们必须称之为“readln来启动一个新的阅读线和复位??”eoln“。同样，当最后一个字符的文件被读取时，内置的“EOF”变为真。在这两种情况下，“eoln”和“EOF”必须进行测试之前每个“读”，而不是之后。

鉴于此，相当大的痛苦，必须采取合理的模拟输入。这样的“GETC”工程大学伯克利分校和VU I/O系统，但实施可能并不一定为别的：

     { getc -- read character from standard input }
     function getc (var c : character) : character;
     var
             ch : char;
     begin
             if eof then
                     c := ENDFILE
             else if eoln then begin
                     readln;
                     c := NEWLINE
             end

             else begin
                     read(ch);
                     c := ord(ch)
             end;
             getc := c
     end;

类型“字”是不一样的“字符”一样，因为ENDFILE也许NEWLINE不是一个“字符”变量的合法值。
目前并没有获得除命名（有效）的逻辑中的“程序”声明，每个程序单元号开始预定义文件到文件系统中的所有概念。这显然??反映了疾病预防控制中心批制度，最初是Pascal。文件变量

     var fv : file of type

是一种非常特殊的对象 - 它不能被分配??到，也只有通过使用内置的像“EOF”，“eoln”，“读”，“写”，“复位”和“重写”过程的调用。 （“重设”倒回一个文件，使它成为重读准备;'重写'使文件编写做好准备。）
Pascal的大多数实现提供了一个逃生舱口就允许名称文件从外部环境，而不是方便，而不是standardly。例如，许多系统调用允许在文件名参数“复位”和“重写”：

     reset(fv, filename);

但是，“复位”和“改写”是过程，不是函数 - 有没有地位，没有办法返回重新获得控制，如果由于某种原因，试图访问失败。 （UCSD提供了编译时间标志，禁用正常中止。）而且，由于FV的不能在表达式中出现像
    
     reset(fv, filename);
     if fv = failure then ...

有没有朝这个方向逃跑或者。这基本上是不可能的束缚使得编写程序，从错误中恢复的文件名拼写，等我从来没有解决的“工具”修订它充分。
没有获得命令行参数，可能再次反映Pascal的批处理起源的概念。本地程序可以允许添加非的标准程序的环境中。

既然是不可能写在Pascal一般用途的存储分配器（那里是没有办法谈的类型，这样的函数将返回），语言有一个从一个内置的所谓“新”的过程，分配空间堆。只有定义类型可以分配，所以它是不可能的分配，例如，任意大小的数组来保存字符串。由“新”返回的指针可能被传递而不是操纵：没有指针运算。有没有办法重新获得控制权，如果储存耗尽。

新标准提供了在这些领域没有任何变化。

5. 修饰问题

这些问题大多是有经验的程序员厌烦，一些可能还会滋扰初学者。它们都可以连在一起。
Pascal，与大多数其他以Algol为灵感的语言一样，使用分号而不是结束（在PL/I和C）作为语句分隔。因此必须有一个什么样的声明是把复杂的概念，合理妥善分号。也许更重要的是，如果一个人大约在适当的地方使用它们严重，相当数量的滋扰编辑需要。考虑第一个程序片段：

     if a then
             b;
     c;

但如果事情必须在b之前插入，它不再需要一个分号，因为它现在前面一个“结束”：

     if a then begin
             b0;
             b
     end;
     c;

现在，如果我们添加一个'else'，就必须消除对'end'的分号：

     if a then begin
             b0;
             b
     end
     else
             d;
     c;

以及等等等等用分号上下翻飞的方案来进行下去。

一个普遍接受的程序员心理学实验的结果是，分号作为分隔约10倍更容易比分号作为结束符错误（16）（在Ada，（17）最重要的语言基础上Pascal，分号结束符。）幸运的是，Pascal可以几乎总是闭一只眼，并逃脱分号作为结束符。例外的是在像声明，其中与终端分离问题似乎并不严重反正地方，就在“其他”，这是很容易记住。

C和Ratfor程序员发现'begin'和'end'笨重相比，{和}。

一个函数名本身是该函数调用，而没有办法区分从一个简单的变量除非知道该函数的名称，如函数调用。Pascal采用了具有像在函数变量函数的名称的行为Fortran的把戏，但如在Fortran函数的名字真的是一个变量，并可以出现在表达式中，在Pascal，其表达式的外观是一个递归调用：如果f是一个零参数的函数，'F：= F +1为F的递归调用

有一个经营者缺乏（可能涉及到优先级的缺乏）。特别是，有没有位操作运算符（AND，OR，XOR等）。我只是放弃了试图写下面的Pascal中琐碎的加密程序：

     i := 1;
     while getc(c) <> ENDFILE do begin
             putc(xor(c, key[i]));
             i := i mod keylen + 1
     end

因为我不能写一个合理的“异或”的功能。设置的类型有点帮助这里（这么说），但还不够，声称Pascal是一个系统编程语言的人一般都忽略了这一点。例如，[18，第685]``Pascal是目前[1977]系统编程和软件实现最好的语言，似乎有点天真。
有没有空字符串，也许是因为Pascal使用翻了一番引用符号来表示字符串中嵌入一个报价：

     'This is a '' character'

有没有办法投入字符串非图形符号。事实上，非图形字符在unpersons感更强，因为它们不属于任何标准语言的一部分提及。如换行符，制表符等概念的处理系统在每一个“专案”的方式，通常是通过了解有关字符集（如ASCII换行符的十进制值10）的东西。

There is no macro processor.  The 'const' mechanism for defining manifest constants takes care of about 95 percent of the uses of simple #define statements in C, but more involved ones are hopeless.  It is certainly possible to put a macro preprocessor on a Pascal compiler.  This allowed me to simulate a sensible 'error' procedure as

     #define error(s) begin writeln(s); halt end

('halt' in turn might be defined as a branch to the end of the outermost block.) Then calls like

     error('little string');
     error('much bigger string');

work since 'writeln' (as part of the standard Pascal environment) can handle strings of any size.  It is unfortunate that there is no way to make this convenience available to routines in general.
The language prohibits expressions in declarations, so it is not possible to write things like

      const   SIZE = 10;
      type    arr = array [1..SIZE+1] of integer;

或者简单的就像

      const   SIZE = 10;
              SIZE1 = SIZE + 1;

6. 观点

在努力重写《软件工具》一书的程序从1980年3月开始，间歇的持续到1981年1月。最终此书（19）在1981年6月发布。那段时间我逐渐适应了与Pascal（修饰，控制流不足）表面的问题，并并发着不完善的解决方案（数组的大小，运行时环境）来使它好用。

要完成书里的程序，还要有良好的设计，是个不平凡的任务。但他们没有被有效的，也不是非常复杂的操作系统及其相互作用，使我能够得到一些漂亮的杂牌解决方案，那些根本就没有真正的解决方案。

没有明显的地方显示出Pascal优于C，但也有它是一个多Ratfor明显改善的几个地方。迄今为止最明显的就是递归：几个节目更清洁的书面递归时，特别是模式搜索，快速排序，评价和表达。

枚举数据类型是一个好主意。同时，他们划定的合法值的范围和文档中。记录有助于组相关的变量。我发现使用相对较少的指针。

布尔变量是整数比布尔条件更好;原Ratfor方案中有些不自然，因为Fortran的建设的逻辑变量的设计不当。

偶尔Pascal的类型检查会警告的手滑书面方案;价值观的运行时检查还表示不时的错误，特别是下标范围的行为。

至于消极的一面，重新编译一个从无到有的大型计划，以改变源一行是非常烦人;独立编译或没有类型检查，是对大型程序的强制性。

我来自一个事实，字符被部分Pascal和Fortran的部分不小的好处，因为字符串和非图形Pascal治疗等不足。在这两种语言，这是令人吃惊笨拙初始化的关键字，错误信息，如表和文字字符串。

完成的项目是在对他们的Ratfor等同的源代码行数相同的一般。起初这让我很吃惊，因为我的偏见是，Pascal是一个冗长，少表达语言。真正的原因似乎是在像Pascal许可证限制并在Fortran的循环（即，便携式的Fortran 66）没有，所以一些无用的分配可以消除标地任意表达式;此外，Ratfor程序申报功能，而Pascal的做没有。

临结束，让我总结一下反对Pascal的要点。

1.由于数组的大小是其类型的一部分​​，它是不可能写出通用例程，也就是要处理不同大小的阵列。特别是，字符串处理是非常困难的。
变量需要更多的范围比他们应该 -

2.在静态变量的初始化和通信方式的非层次相结合，破坏当地的`` ''程序缺乏。
各申报散射程序组件，逻辑上属于一起执行分开，将语言的力量的过程和函数是在一个不自然顺序排列一通的性质。

3.单独编制的缺乏阻碍了大型项目的发展，而不能使用的库。
逻辑表达式的计算顺序不能得到控制，从而导致复杂的代码和随机变量。

6.在“案例”的说法是被阉割的，因为没有违约条款。

7.标准I/O是有缺陷的。没有与文件或程序参数作为标准语言的一部分，并没有合理的处理提供扩展机制。

8.语言缺乏用于装配大型程序所需的工具最多，最显着的文件包含。

9.没有逃脱。

最后这一点也许是最重要的。语言是不足，但界限清楚，因为没有办法逃脱它的局限性。有没有转换禁用类型检查时必需的。有没有办法更换明智的做法有缺陷的运行时环境，除非控制编译器定义了``标准程序。''的语言是封闭的。
人们谁使用严重的编程陷入致命的陷阱Pascal。

因为语言是如此的无能，它必须扩展。但各组扩展了自己的方向Pascal，使它看起来像任何一种语言，他们真正想要的。单独编译，Fortran语言类常见，字符串数据类型，内部静态变量的初始化，八进制数，位域等扩展，都增加了语言的工具为一组，而破坏其移植性性。

我觉得做超出Pascal原定目标的事是一种错误。在它的形式看来，Pascal是一个玩具语言，适合教学，但不适合真正的编程。

致谢

I am grateful to Al Aho, Al Feuer, Narain Gehani, Bob Martin, Doug McIlroy, Rob Pike, Dennis Ritchie, Chris Van Wyk and Charles Wetherell for helpful criticisms of earlier versions of this paper.

[1] Feuer, A. R. and N. H. Gehani, ``A Comparison of the Programming Languages C and Pascal - Part I: Language Concepts,'' Bell Labs internal memorandum (September 1979).

[2] N. H. Gehani and A. R. Feuer, ``A Comparison of the Programming Languages C and Pascal - Part II: Program Properties and Programming Domains,'' Bell Labs internal memorandum (February 1980).

[3] P. Mateti, ``Pascal versus C: A Subjective Comparison,'' Language Design and Programming Methodology Symposium, Springer-Verlag, Sydney, Australia (September 1979).

[4] A. Springer, ``A Comparison of Language C and Pascal,'' IBM Technical Report G320-2128, Cambridge Scientific Center (August 1979).

[5] B. W. Kernighan and P. J. Plauger, Software Tools, Addison-Wesley, Reading, Mass. (1976).

[6] K. Jensen, Pascal User Manual and Report, Springer-Verlag (1978). (2nd edition.)

[7] David V. Moffat, ``A Categorized Pascal Bibliography,'' SIGPLAN Notices 15(10), pp. 63-75 (October 1980).

[8] A. N. Habermann, ``Critical Comments on the Programming Language Pascal,'' Acta Informatica 3, pp. 47-57 (1973).

[9] O. Lecarme and P. Desjardins, ``More Comments on the Programming Language Pascal,'' Acta Informatica 4, pp. 231-243 (1975).

[10] H. J. Boom and E. DeJong, ``A Critical Comparison of Several Programming Language Implementations,'' Software Practice and Experience 10(6), pp. 435-473 (June 1980).

[11] N. Wirth, ``An Assessment of the Programming Language Pascal,'' IEEE Transactions on Software Engineering SE-1(2), pp. 192-198 (June, 1975).

[12] O. Lecarme and P. Desjardins, ibid, p. 239.

[13] A. M. Addyman, ``A Draft Proposal for Pascal,'' SIGPLAN Notices 15(4), pp. 1-66 (April 1980).

[14] J. Welsh, W. J. Sneeringer, and C. A. R. Hoare, ``Ambiguities and Insecurities in Pascal,'' Software Practice and Experience 7, pp. 685-696 (1977).

[15] N. Wirth, ibid., p. 196.

[16] J. D. Gannon and J. J. Horning, ``Language Design for Programming Reliability,'' IEEE Trans. Software Engineering SE-1(2), pp. 179-191 (June 1975).

[17] J. D. Ichbiah, et al, ``Rationale for the Design of the Ada Programming Language,'' SIGPLAN Notices 14(6) (June 1979).

[18] J. Welsh, W. J. Sneeringer, and C. A. R. Hoare, ibid.

[19] B. W. Kernighan and P. J. Plauger, Software Tools in Pascal, Addison-Wesley (1981).