Why Pascal Is Not My Favorite Programming Language

A famous and infamous paper from 1981, in which BrianKernighan talks objectively about PascalLanguage.


Note that Brian is criticizing Pascal as it existed in 1981. Even slightly extended versions, like TurboPascal (which debuted in 1983), don't have the same problems and are equivalent to C in most respects. Ditto for DelphiLanguage (the modern descendant of TurboPascal).
The most annoying design errors in Pascal according to me, and also pointed by BrianKernighan:

  1. The size of an array is part of its type.
  2. There are no static variables and no initialization.
  3. No break.

Some Pascal ideas are actually a good thing:

  1. One-pass compiler => very fast compiler.
  2. One-pass compiler => a typical Pascal program reads from the bottom up, but this is essentially opposite to the order in which the functions are designed and used.

Now that parametric-typing, polymorphism, and the like are in vogue, the Pascal concept of array-size-as-type becomes reasonable again. An unsized array as an abstract class with all the methods of an array, plus one pure-virtual concept: "GetSize()". Compile-time sized arrays are then parametric-types that are a subclass of the unsized array with a SIZE const member, which is returned by the GetSize implementation. Run-time sized arrays are a different subclass of the Array class, but they store their size as an instance member and return that on GetSize(). Size-unknown arrays are a third subclass (for optimization nuts who store the size elsewhere or don't care) return -1 (or throw an exception if you prefer) on GetSize(). You could provide casting methods to test-and-convert a run-time-sized array into a compile-time-sized array. Thus you could both have functions that take array[] or array[7]. Since most array operations work the same, you'd only need indirection for the GetSize() operation, which wouldn't even be needed in cases where you're using them Pascal-style.

Too bad C++'s aggregate syntax is useful only for normal dumb arrays. -- MartinZarate
Interestingly, many of Kernighan's objections to Pascal are things that Knuth also found it necessary to address in his LiterateProgramming tool "Web", which he used in the development of TexTheProgram and Metafont. It is fair to say that the Web system is only half about LiterateProgramming; the other half is just workarounds for the shortcomings of the Pascal dialects of its day. Most notably, Web provides a mechanism to allow the use of variable-length strings in things like error messages.
I definitely agree with all Brian's criticisms of Pascal, which is a pity really since Pascal's English-like syntax is very nice. -- ChrisHandley

I've never heard it called "English-like". I take it you've never dealt with COBOL or SQL, the two most infamously "English-like" languages, but what are you referring to? The fact that it uses English words as keywords??

I can't speak for Chris, but I think it's that terseness was not a priority: there's if..then instead of if(..); there isn't the temptation to cram as much into an expression as possible; fancy type definitions are less obscure; and so on. It isn't English-like, but it's generally easier to read.

Hmm, well, these characteristics derive from Algol. The standard phrasing is that such things are "Algol-like", not "English-like". Cobol is "English-like".

C is part of the Algol syntactic family, but it is straying away from being a central prototype of the category due to using braces instead of begin/end, etc.

While I generally dislike the begin..end compared to {}, I do have to say that I prefer Pascal assignment := and equality = over C's ugly == equality. The catch is that unless you force the user to explicitly say "ignore the return value" when calling functions, you create a risk for the reverse of the C '='/'==' bug, where you just dump an equality test boolean result to the nowhere instead of assigning to the variable.
(Note: this paper deserves its own page because (a) it's famous, (b) there are several WikiWikiWeb references to it, and (c) the BrianKernighan WikiHomePage refers to it.)
CategoryPaper, CategoryRant

EditText of this page (last edited August 7, 2010) or FindPage with title or text search