Why Pascal Is Not My Favorite Programming Language

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

http://cm.bell-labs.com/cm/cs/cstr/100.ps.gz (official)
http://www.lysator.liu.se/c/bwk-on-pascal.html (html)

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:

The size of an array is part of its type.
There are no static variables and no initialization.
No break.
- I rarely have a need for a loop "break" and there are GoodEnough alternatives for those rare cases. I thus would consider this an extremely minor complaint. -t

Some Pascal ideas are actually a good thing:

One-pass compiler => very fast compiler.
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.

I would rather say that this is better than having any random structure in a program.
Bottom up is usually quite superior in code quality than top down.
- I disagree. I like the general stuff on top and more specific below it. That is how English papers, etc. are also supposed to do it. Who wants the Table of Contents on the last page? Who wants the index on the first? I think they should have made Pascal optional two-pass. If you define it bottom-up, then it does not need another pass. But, if it makes a pass and does not have all needed info, then make a second pass. That way the programmer can decide between convenience and speed.

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.

{I don't like having to type ":" all the time, and often forget due to usage of multiple languages throughout the work-day. I've pondered the assignment-versus-equality issue over the years, and have come to conclude that there is no easy way out unless we reboot the Earth and create new conventions and keyboards. C's approach is ugly, but the least evil because it's the devil we know. Given ugly option A versus ugly option B, we go with the most common. Thus, if A is the most common and we go with B, then the habits from A will keep tripping up B usage. If everybody uses A, then there is no B to trip people up via habit mixing. QwertySyndrome perhaps. (VB seems to simplify the issue and using "==" accidentally causes a syntax error instead of run-time surprises, but VB makes other areas of the language more complicated to obtain such.) -t}

(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 CategoryPascal