Why Pascal is Not My Favorite Programming Language: what changed

Revision 0 to 1. Removed lines have a minus sign; added lines have a plus sign.

Title: Why Pascal is Not My Favorite Programming Language

New		Line
1	+	"Why Pascal is Not My Favorite Programming Language" is an article (can be found [here](http://www.lysator.liu.se/c/bwk-on-pascal.html)) written about by Brian W. Kernighan, April 2, 1981. The article is often used in language comparison discussions even today, typically by critics of the Pascal-family, despite the fact that the article is talking about a version of Pascal that has been superseded. The description of the language that B Kernighan is referring to in the article can be found [here](http://web.archive.org/web/20210718153204/http://pascal-central.com/docs/pascal1973.pdf).
2	+
3	+	The purpose of this page, is to show that the article is quite outdated. People who are still trying to refer to the article are unaware of the capabilities of current Pascal (Delphi/FPC) implementations.
4	+
5	+	## Genesis
6	+
7	+	## Article
8	+
9	+	### Types and Scopes
10	+
11	+	`Integer variables may be declared to have an associated range of legal values, and the compiler and run-time support `\
12	+	`ensure that one does not put large integers into variables that only hold small ones. This too seems like a service,`\
13	+	`although of course run-time checking does exact a penalty. `
14	+
15	+	It needs to be noted here, that compiler allows to remove the range run-time check completely.
16	+
17	+	### The size of an array is part of its type
18	+
19	+	Without quoting of the article - the complain is about an arrays of different size (though still the same type) are considered a different type. Since Pascal is strict type routines cannot be shared among array of different size. The task of sorting is used as an example in the article.
20	+
21	+	The 1985 Ansi/ISO standards have an (optional) section about conformant arrays fixing this. Currently neither FPC (ISO mode) nor Borland derivatives implement it.
22	+
23	+	[Dynamic](http://www.freepascal.org/docs-html/ref/refsu18.htm) and [Open arrays](http://www.freepascal.org/docs-html/ref/refsu64.html) were introduced in Delphi that overcomes the limitation at the cost of the lower bound always being 0. The desired result could be achieved even back at the time, using pointers.
24	+
25	+	### There are no static variables and no initialization
26	+
27	+	As well as Static variables are just "implementation"-only variables per unit. Global variable initialization were added in some version of Delphi, as well as type constants (which are variables) requires the initialization to be present.
28	+
29	+	Also, each unit provides an initialization section (which is executed in run-time), that provides a very flexible and convenient way for initialization (of dynamic storages).
30	+
31	+	### Related program components must be kept separate
32	+
33	+	No such strict order limitation in Object Pascal.
34	+
35	+	### There is no separate compilation
36	+
37	+	Fixed mid eighties by the module(ISO)/units(UCSD/Borland) system in a way that doesn't need a separate interpreter (make) to manage building and without the infinate header reparsing problem that causes C and C++ compilers to be relatively slow in practice.
38	+
39	+	### Some miscellaneous problems of type and scope
40	+
41	+	`It is not legal to name a non-basic type as the literal formal parameter of a procedure; `
42	+
43	+	This is actually still true.
44	+
45	+	`It is nice to have the declaration 'var' for formal parameters of functions and procedures; `\
46	+	`the procedure clearly states that it intends to modify the argument. But the calling program `\
47	+	`has no way to declare that a variable is to be modified - the information is only in one place,`\
48	+	`while two places would be better.`
49	+
50	+	[const](http://www.freepascal.org/docs-html/ref/refsu63.html) is available to identified unmodified parameter and passing a parameter by reference (where applicable)
51	+
52	+	`Pascal's 'set' construct seems like a good idea, providing notational convenience and some free type checking. `\
53	+	` For example, a set of tests like`\
54	+
55	+	` if (c = blank) or (c = tab) or (c = newline) then ...`\
56	+
57	+	` can be written rather more clearly and perhaps more efficiently as`\
58	+
59	+	` if c in [blank, tab, newline] then ..`
60	+
61	+	And [they're](http://www.freepascal.org/docs-html/ref/refsu20.html)!
62	+
63	+	### There is no escape
64	+
65	+	Type casting is available (and causing issues for some developers)
66	+
67	+	## Control Flow
68	+
69	+	`There is no guaranteed order of evaluation of the logical operators 'and' and 'or' - nothing like && and \|\| in C. `\
70	+	`This failing, which is shared with most other languages, hurts most often in loop control:`\
71	+
72	+	` while (i <= XMAX) and (x[i] > 0) do ...`
73	+
74	+	Conditions are [short-cut evaluated](http://www.freepascal.org/docs-html/ref/refsu53.html). Thus loops can be implemented the way above without a risk breaking out of the range.
75	+
76	+	`With no 'break' statement...`
77	+
78	+	There's [break](http://www.freepascal.org/docs-html/ref/refsu57.htm)
79	+
80	+	`The increment of a 'for' loop can only be +1 or -1, a minor restriction.`
81	+
82	+	Still true.
83	+
84	+	`There is no 'return' statement, again for one in-one out reasons. `
85	+
86	+	There's Exit statement (FPC only Exit() ) available.
87	+
88	+	`The 'case' statement is better designed than in C, except that there is no 'default' clause and the behavior `\
89	+	`is undefined if the input expression does not match any of the cases. This crucial omission renders the 'case' construct `\
90	+	`almost worthless.`
91	+
92	+	There's [else (or otherwise)](https://www.freepascal.org/docs-html/current/ref/refsu56.html#x166-19000013.2.2) in case statement.
93	+
94	+	## The Environment
95	+
96	+	No problems with using System APIs and any I/O routines provided by an underlying environment.
97	+
98	+	## Cosmetic Issues
99	+
100	+	`But if something must be inserted before b, it no longer needs a semicolon, because it now precedes an 'end': `
101	+
102	+	A statement before "end" might have or not have a semicolon. Not-having a semicolon is not enforced.
103	+
104	+	`C and Ratfor programmers find 'begin' and 'end' bulky compared to { and }.`
105	+
106	+	Is still true and there're no plans to change that.
107	+
108	+	`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 `\
109	+	`except by knowing the names of the functions`
110	+
111	+	Is still true, except for FPC/objFPC mode, where a function call must come with ()
112	+
113	+	`In particular, there are no bit-manipulation operators (AND, OR, XOR, etc.). `\
114	+	`I simply gave up trying to write the following trivial encryption program in Pascal:`\
115	+
116	+	` i := 1;`\
117	+	` while getc(c) <> ENDFILE do begin`\
118	+	` putc(xor(c, key[i]));`\
119	+	` i := i mod keylen + 1`\
120	+	` end`
121	+
122	+	Bit-manipulation [operators](https://www.freepascal.org/docs-html/current/ref/refsu45.html) are available.
123	+
124	+	`There is no null string, perhaps because Pascal uses the doubled quote notation to indicate a quote embedded in a string`\
125	+	` `\
126	+	` 'This is a '' character'`\
127	+
128	+	`There is no way to put non-graphic symbols into strings. In fact, non-graphic characters are unpersons in a stronger `\
129	+	`sense, since they are not mentioned in any part of the standard language. Concepts like newlines, tabs, and so on `\
130	+	`are handled on each system in an 'ad hoc' manner, usually by knowing something about the character set `\
131	+	`(e.g., ASCII newline has decimal value 10)`
132	+
133	+	Escape characters are available.
134	+
135	+	` 'new line'#13#10`
136	+
137	+	Needless to say, that Unicode escaping is available too.
138	+
139	+	`There is no macro processor.`
140	+
141	+	God bless Pascal!
142	+
143	+	`The 'const' mechanism for defining manifest constants takes care of about 95 percent of the uses of simple `\
144	+	`#define statements in C, but more involved ones are hopeless. It is certainly possible to put a macro `\
145	+	`preprocessor on a Pascal compiler. This allowed me to simulate a sensible 'error' procedure as`\
146	+
147	+	` #define error(s)begin writeln(s); halt end`
148	+
149	+	Obviously the error(s) should implemented as a function. Since nothing is executed after Halt(). Though these days "raising" an exception might be a better approach.
150	+
151	+	`The language prohibits expressions in declarations, so it is not possible to write things like `\
152	+	` const SIZE = 10;`\
153	+	` type arr = array [1..SIZE+1] of integer;`
154	+
155	+	[Constant expressions](http://www.freepascal.org/docs-html/ref/refse9.html) are allowed as value of an expression.
156	+
157	+	## Perspective
158	+
159	+	`To close, let me summarize the main points in the case against Pascal. `\
160	+	`1. 2. 3. 4. 5. 6. 7. 8. ...`\
161	+	`9. There's no escape `\
162	+
163	+	`This last point is perhaps the most important. The language is inadequate but circumscribed, because there `\
164	+	`is no way to escape its limitations. There are no casts to disable the type-checking when necessary. `\
165	+	`There is no way to replace the defective run-time environment with a sensible one, unless one controls `\
166	+	``` the compiler that defines the ``standard procedures.'' The language is closed. ```
167	+
168	+	Modern Pascals are easily extensible, but still, if you don't like the run-time environment. You can introduce your own. After all, FPC is open source.
169	+
170	+	---
171	+	From the Free Pascal wiki, page "Why Pascal is Not My Favorite Programming Language", as it stood on 2023-11-27 after a change by N7800, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).
172	+	Category: Promotion

Back to history