Why Pascal Sucks

Brought to you by the writeup-sometimes-does-mean-reply foundation.

The original teaching language called Pascal may suck bigtime for real-world programming, but I don't think that it is in use for that any more. You are more likely to come across a language that is called Pascal, but is actually an extended version or child language of Pascal, such as Object Pascal, Delphi or Kylix. And most likely you'll agree that it doesn't suck.

The Pascal programming language specification was formed in the days before the 1990s, when a complete class and function library was not yet so important to a new language's success. In some cases, function names chosen in the late 1960s or early 1970s are overly general by today's standards, for instance Copy for string slicing or Open to open a file handle. These are usually kept for backward compatibility, and superseded by more descriptively named functions such as StrMid or FileOpen. In most cases, functions are more intuitively named than their C counterparts.

The layout and maximum length of a string is not cast in stone either. Ever since the move to 32-bit operating systems (i.e. the mid 1990s), Delphi as a modern Pascal has had strings with a 4-byte length indicator, i.e. up to 2Gb in string length. Pascal strings are easier to work with in almost every respect than the counterpart in C of manually-managed pointers to character arrays

ssd's reasons, which draw heavily on Kernighan's Why Pascal is Not my Favorite Programming Language (see the writeups there) are also not relevant anymore. See also when to use a semicolon in Pascal.

As for SSD's list of issues, Delphi addresses numbers 1 partly through optional and array parameters, and 2, 3, 5 (via a hard typecast), 8, 9, 10, 11, and 12. The ones that look to me like differences to how a programmer who understands only C might narrowly view the world, but are not problems in Pascal, are 3 (the type aliases part), 4, 6, 7.

Pascal has a number of flaws. Naming of internal functions I don't count as one of them--that's a quirk, not a flaw. I can deal with irregular function names. (And Even the unix creators admit that creat was one of their biggest mistakes.)

No, pascal has much more serious problems. As others have noted, Borland's Turbo Pascal fixed a lot of problems with pascal. Most of these complaints are more relevant to UCSD pascal and BSD pascal. Let me repeat myself, since Strawberry Frog didn't read the previous comment the first time. These complaints refer to the original pascal made available by UCSD, BSD, and others. Even late versions of Turbo Pascal, prior to Delphi fixed some of these, and no, Delphi is Delphi, NOT pascal. It's a different language. That's like saying that complaints about C are wrong because C++ fixes them. No. As to moving this to the the node on Kernighan's paper, that would be wrong too, as this is NOT a summary of his complaints, but my own list, in my own priority order, with a few of his (that I agree with) added.

Here's the flaws I remember and some fragments from Brian Kernighan's paper Why Pascal is Not my Favorite Programming Language which is well worth reading, and better organized than this rant.

1. The standard library has functions with a variable number of arguments, but the language doesn't support creating new ones.
2. The standard library has a very limited number of useful functions, and not enough to make it easy to add new ones. (Borland fixed this well.) Overall, pure pascal is not extensible, and any attempts to fix this make it unportable.
3. The syntax of the language is weak in the area of function/procedure declarations and array types, and thus forces you to create type aliases just so you can pass arrays and other complex types. Variable sized arrays are not supported. Even ForTran does this better.
4. Sometimes you need a ; and sometimes you don't. Putting in an extra one could change the meaning of the statement (like in C), but usually it's a syntax error. The rules for this are non-trivial, and confusing to many beginning students. Perhaps it makes them pay attention to detail, but it's very annoying.
5. If you separately create two type aliases that are identical, you still can't assign a variable of one type to the other, even though they are identical. Some implementations may fix this.
6. Some input formats are impossible or nearly impossible to read with pascal's I/O primitives. Similar things can be trivial in C. (Specifically, reading an input stream with unpredictable mixed numbers and text is impossible without reading it character by character and reimplementing pascal's number reading primitives.) But at least you don't have to do an implied do loop to read in an array from a file, like in ForTran.
7. A well kept secret: pascal has pointers. They are horrible to work with. The syntax is ugly and confusing, and they don't do very much. (And I *like* pointers in C.)
8. String handling in pascal is cumbersome, at best. Not because of misnamed functions, but because of strict type checking. Some pascal implementations add a string type, which helps slightly.
9. Initializing an array must be done by individual assignments. You can't have a big blob of pre-initialized data, like in C. This is unbelievably annoying when it is needed. Even ForTran did better than this.
10. Kernighan complaints about lack of goto, break, and return. I can excuse goto, but break and return are very important, and the lack of them causes more contorted code than the presence of goto.
11. Kernighan complains about lack of short cut logic operators (like && and || in C), which makes it impossible to do both bounds checking on an array index and check a value in the array in the same logic expression.
12. Kernighan complains about lack of default in case, undefined loop indexes outside of the loop, total lack of type casting, and missing bitwise operators. The last two prevent pascal from being a good systems programming language (along with the other flaws). Pascal was designed to be a learning language. It is fairly good for that, although it is being displaced by something better -- Java. Pure pascal without Borland's extensions is completely useless for anything else, mostly because it has no means for extending the language. Even with Borland's extensions, most of the problems above are not fixed, but it is at least usable outside of the teaching environment.

    The strongest measure of a language is, of course, can you write a compiler for it in itself. I think it is telling that most pascal compilers are written in C.

    Kernighan's biggest complaint about pascal is that there is no way to extend it--including separately compilable or externally linkable object code. His next biggest complaint is that all attempts to fix these problems were non-standard and therefore unportable. Delphi fits into this latter catagory. As to Turbo Pascal fixing most of these, last I checked, it hadn't, and if it fixes any of 1, 3, 4, 7, 8, 10, or 12 above, it has mangled it beyond it being pascal (which would be a good thing admittedly).