us anyway, and just before else, which is easy to
remember.
C and Ratfor programmers find begin and end bulky compared to { and }.
A function name by itself is a call of that function; there is no way to
distinguish such a function call from a simple variable except by knowing the
names of the functions. Pascal uses the Fortran trick of having the function
name act like a variable within the function, except that where in Fortran the
function name really is a variable, and can appear in expressions, in Pascal,
its appearance in an expression is a recursive invocation: if f is a
zero-argument function, f:=f+1 is a recursive call of f.
There is a paucity of operators (probably related to the paucity of precedence
levels). In particular, there are no bit-manipulation operators (AND, OR,
XOR, etc.). I simply gave up trying to write the following trivial encryption
program in Pascal:
i := 1; while getc(c) <> ENDFILE do begin putc(xor(c, key[i])); i := i mod
keylen + 1 end
because I couldn''''t write a sensible xor function. The set types help a bit
here (so to speak), but not enough; people who claim that Pascal is a system
programming language have generally overlooked this point. For example, [18,
p. 685]
``Pascal is at the present time [1977] the best language in the public domain
for pur poses of system programming and software implementation.''''''''
seems a bit naive.
There is no null string, perhaps because Pascal uses the doubled quote
notation to indicate a quote embedded in a string:
''''This is a '''''''' character''''
There is no way to put non-graphic symbols into strings. In fact, non-graphic
characters are unpersons in a stronger sense, since they are not mentioned in
any part of the standard language. Concepts like newlines, tabs, and so on are
handled on each system in an ad hoc manner, usually by knowing something about
the character set (e.g., ASCII newline has decimal value 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;
or even simpler ones like
const SIZE = 10; SIZE1 = SIZE + 1;
6. Perspective
The effort to rewrite the programs in Software Tools started in March, 1980,
and, in fits and starts, lasted until January, 1981. The final product 19 was
published in June, 1981. During that time I gradually adapted to most of the
superficial problems with Pascal (cosmetics, the inade quacies of control
flow), and developed imperfect solutions to the significant ones (array sizes,
run-time environment).
The programs in the book are meant to be complete, well-engineered programs
that do non-trivial tasks. But they do not have to be efficient, nor are
their interactions with the operat ing system very complicated, so I was able
to get by with some pretty kludgy solutions, ones that simply wouldn''''t work
for real programs.
There is no significant way in which I found Pascal superior to C, but there
are several places where it is a clear improvement over Ratfor. Most obvious
by far is recursion: several pro grams are much cleaner when written
recursively, notably the pattern-search, quicksort, and expression evaluation.
Enumeration data types are a good idea. They simultaneously delimit the range
of legal values and document them. Records help to group related variables.
I found relatively little use for pointers.
Boolean variables are nicer than integers for Boolean conditions; the original
Ratfor pro grams contained some unnatural constructions because Fortran''''s
logical variables are badly designed.
Occasionally Pascal''''s type checking would warn of a slip of the hand in
writing a program; the run-time checking of values also indicated errors from
time to time, particularly subscript range violations.
Turning to the negative side, recompiling a large program from scratch to
change a single line of source is extremely tiresome; separate compilation,
with or without type checking, is mandatory for large programs.
I derived little benefit from the fact that characters are part of Pascal and
not part of For tran, because the Pascal treatment of strings and non-graphics
is so inadequate. In both lan guages, it is appallingly clumsy to initialize
literal strings for tables of keywords, error messages, and the like.
The finished programs are in general about the same number of source lines as
their Ratfor equivalents. At first this surprised me, since my preconception
was that Pascal is a wordier and less expressive language. The real reason
seems to be that Pascal permits arbitrary expressions in places like loop
limits and subscripts where Fortran (that is, portable Fortran 66) does not,
so some useless assignments can be eliminated; furthermore, the Ratfor
programs declare functions while Pascal ones do not.
To close, let me summarize the main points in the case against Pascal.
1. Since the size of an array is part of its type, it is not possible to
write general-purpose rou tines, that is, to deal with arrays of different
sizes. In particular, string handling is very dif ficult.
2. The lack of static variables, initialization and a way to communicate
non-hierarchically combine to destroy the ``locality'''''''' of a program --
variables require much more scope than they ought to.
3. The one-pass nature of the language forces procedures and functions to be
presented in an unnatural order; the enforced separation of various
declarations scatters program compo nents that logically belong together.
4. The lack of separate compilation impedes the development of large programs
and makes the use of libraries impossible.
5. The order of logical expression evaluation cannot be controlled, which
leads to convoluted code and extraneous variables.
6. The case statement is emasculated because there is no default clause.
7. The standard I/O is defective. There is no sensible provision for dealing
with files or pro gram arguments as part of the standard language, and no
extension mechanism.
8. The language lacks most of the tools needed for assembling large programs,
most notably file inclusion.
9. There is no escape.
This last point is perhaps the most important. The language is inadequate but
circum scribed, because there is no way to escape its limitations. There are
no casts to disable the type checking when necessary. There is no way to
replace the defective run-time environment with a sensible one, unless one
controls the compiler that defines the ``standard procedures.'''''''' The lan guage
is closed.
People who use Pascal for serious programming fall into a fatal trap. Because
the language is so impotent, it must be extended. But each group extends
Pascal in its own direction, to make it look like whatever language they
really want. Extensions for separate compilation, Fortran like COMMON, string
data types, internal static variables, initialization, octal numbers, bit
opera tors, etc., all add to the utility of the language for one group, but
destroy its portability to others.
I feel that it is a mistake to use Pascal for anything much beyond its
original target. In its pure form, Pascal is a toy language, suitable for
teaching but not for real programming.
Acknowledgments
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, Cam bridge 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 Infor matica 4, pp. 231-243 (1975).
10. H. J. Boom and E. DeJong, ``A Critical Comparison of Several Programming
Language Implementa tions,'''''''' 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 Engi neering 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,
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
