AT&T Bell Laboratories Murray Hill, New Jersey 07974
Computing Science Technical Report No. 100
Why Pascal is Not My Favorite Programming Language
Brian W. Kernighan
April 2, 1981
Why Pascal is Not My Favorite Programming Language
Brian W. Kernighan
AT&T Bell Laboratories Murray Hill, New Jersey 07974
ABSTRACT
The programming language Pascal has become the dominant language of
instruction in computer science education. It has also strongly influenced
lan guages developed subsequently, in particular Ada.
Pascal was originally intended primarily as a teaching language, but it has
been more and more often recommended as a language for serious programming as
well, for example, for system programming tasks and even operating systems.
Pascal, at least in its standard form, is just plain not suitable for serious
pro gramming. This paper discusses my personal discovery of some of the
reasons why.
April 2, 1981
Why Pascal is Not My Favorite Programming Language
Brian W. Kernighan
AT&T Bell Laboratories Murray Hill, New Jersey 07974
1. Genesis
This paper has its origins in two events -- a spate of papers that compare C
and Pas cal 1, 2, 3, 4 and a personal attempt to rewrite Software Tools 5 in
Pascal.
Comparing C and Pascal is rather like comparing a Learjet to a Piper Cub --
one is meant for getting something done while the other is meant for learning
-- so such comparisons tend to be somewhat farfetched. But the revision of
Software Tools seems a more relevant comparison. The programs therein were
originally written in Ratfor, a ``structured'''''''' dialect of Fortran imple mented
by a preprocessor. Since Ratfor is really Fortran in disguise, it has few of
the assets that Pascal brings -- data types more suited to character
processing, data structuring capabilities for better defining the organization
of one''''s data, and strong typing to enforce telling the truth about the data.
It turned out to be harder than I had expected to rewrite the programs in
Pascal. This paper is an attempt to distill out of the experience some
lessons about Pascal''''s suitability for program ming (as distinguished from
learning about programming). It is not a comparison of Pascal with C or
Ratfor.
The programs were first written in that dialect of Pascal supported by the
Pascal interpreter pi provided by the University of California at Berkeley.
The language is close to the nominal standard of Jensen and Wirth, 6 with good
diagnostics and careful run-time checking. Since then, the programs have also
been run, unchanged except for new libraries of primitives, on four other
systems: an interpreter from the Free University of Amsterdam (hereinafter
referred to as VU, for Vrije Universiteit), a VAX version of the Berkeley
system (a true compiler), a compiler purveyed by Whitesmiths, Ltd., and UCSD
Pascal on a Z80. All but the last of these Pascal systems are written in C.
Pascal is a much-discussed language. A recent bibliography 7 lists 175 items
under the heading of ``discussion, analysis and debate.'''''''' The most often
cited papers (well worth reading) are a strong critique by Habermann 8 and an
equally strong rejoinder by Lecarme and Des jardins. 9 The paper by Boom and
DeJong 10 is also good reading. Wirth''''s own assessment of Pas cal is found in
[11]. I have no desire or ability to summarize the literature; this paper
represents my personal observations and most of it necessarily duplicates
points made by others. I have tried to organize the rest of the material
around the issues of
types and scope control flow environment cosmetics
and within each area more or less in decreasing order of significance.
To state my conclusions at the outset: Pascal may be an admirable language for
teaching beginners how to program; I have no first-hand experience with that.
It was a considerable achievement for 1968. It has certainly influenced the
design of recent languages, of which Ada is likely to be the most important.
But in its standard form (both current and proposed), Pascal is not adequate
for writing real programs. It is suitable only for small, self-contained
programs that have only trivial interactions with their environment and that
make no use of any software written by anyone else.
2. Types and Scopes
Pascal is (almost) a strongly typed language. Roughly speaking, that means
that each object in a program has a well-defined type which implicitly defines
the legal values of and operations on the object. The language guarantees
that it will prohibit illegal values and operations, by some mixture of
compile- and run-time checking. Of course compilers may not actually do all
the checking implied in the language definition. Furthermore, strong typing
is not to be confused with dimensional analysis. If one defines types apple
and orange with
type apple = integer; orange = integer;
then any arbitrary arithmetic expression involving apples and oranges is
perfectly legal.
Strong typing shows up in a variety of ways. For instance, arguments to
functions and pro cedures are checked for proper type matching. Gone is the
Fortran freedom to pass a floating point number into a subroutine that expects
an integer; this I deem a desirable attribute of Pascal, since it warns of a
construction that will certainly cause an error.
Integer variables may be declared to have an associated range of legal values,
and the com piler and run-time support ensure that one does not put large
integers into variables that only hold small ones. This too seems like a
service, although of course run-time checking does exact a penalty.
Let us move on to some problems of type and scope.
2.1. The size of an array is part of its type
If one declares
var arr10 : array [1..10] of integer; arr20 : array [1..20] of integer;
then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose
we want to write a procedure sort to sort an integer array. Because arr10 and
arr20 have different types, it is not possible to write a single procedure
that will sort them both.
The place where this affects Software Tools particularly, and I think programs
in general, is that it makes it difficult indeed to create a library of
routines for doing common, general-purpose operations like sorting.
The particular data type most often affected is array of char, for in Pascal a
string is an array of characters. Consider writing a function index(s,c) that
will return the position in the string s where the character c first occurs,
or zero if it does not. The problem is how to handle the string argument of
index. The calls index(''''hello'''',c) and index(''''goodbye'''',c) can not both be
legal, since the strings have different lengths. (I pass over the question of
how the end of a constant string like ''''hello'''' can be detected, because it
can''''t.)
The next try is
var temp : array [1..10] of char;
temp := ''''hello'''';
n := index(temp,c);
but the assignment to temp is illegal because ''''hello'''' and temp are of
different lengths.
The only escape from this infinite regress is to define a family of routines
with a member for each possible string size, or to make all strings (including
constant strings like ''''define'''') of the same length.
The latter approach is the lesser of two great evils. In Tools, a type called
string is declared as
type string = array [1..MAXSTR] of char;
where the constant MAXSTR is ``big enough,'''''''' and all strings in all programs
are exactly this size. This is far from ideal, although it made it possible to
get the programs running. It does not solve the problem of creating true
libraries of useful routines.
There are some situations where it is simply not acceptable to use the
fixed-size array repre sentation. For example, the Tools program to sort
lines of text operates by filling up memory with as many lines as will fit;
its running time depends strongly on how full the memory can be packed. Thus
for sort, another representation is used, a long array of characters and a set
of indices into this array:
type charbuf = array [1..MAXBUF] of char; charindex = array [1..MAXINDEX] of
0..MAXBUF;
But the procedures and functions written to process the fixed-length
representation cannot be used with the variable-length form; an entirely new
set of routines is needed to copy and com pare strings in this representation.
In Fortran or C the same functions could be used for both.
As suggested above, a constant string is written as
''''this is a string''''
and has the type packed array [1..n] of char, where n is the length. Thus
each string literal of different length has a different type. The only way to
write a routine that will print a message and clean up is to pad all messages
out to the same maximum length:
error(''''short message ''''); error(''''this is a somewhat longer message'''');
Many commercial Pascal compilers provide a string data type that explicitly
avoids the problem; string''''s are all taken to be the same type regardless of
size. This solves the problem for this single data type, but no other. It
also fails to solve secondary problems like computing the length of a constant
string; another built-in function is the usual solution.
Pascal enthusiasts often claim that to cope with the array-size problem one
merely has to copy some library routine and fill in the parameters for the
program at hand, but the defense sounds weak at best: 12
``Since the bounds of an array are part of its type (or, more exactly, of the
type of its indexes), it is impossible to define a procedure or function which
applies to arrays with differing bounds. Although this restriction may appear
to be a severe one, the experiences we have had with Pascal tend to show that
it tends to occur very infre quently. [...] However, the need to bind the
size of parametric arrays is a serious defect in connection with the use of
program libraries.'''[1] [2] [3] [4] [5] 下一页 |
