Why Pascal is Not My Favorite Programming Language: what changed

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

Old	New		Line
1	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	2
3	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	4
5	5		## Genesis
6	6
7	7		## Article
8	8
9	9		### Types and Scopes
10	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. `~~
	11	+	```text
	12	+	Integer variables may be declared to have an associated range of legal values, and the compiler and run-time support
	13	+	ensure that one does not put large integers into variables that only hold small ones. This too seems like a service,
	14	+	although of course run-time checking does exact a penalty.
	15	+	```
14	16
15	17		It needs to be noted here, that compiler allows to remove the range run-time check completely.
16	18
17	19		### The size of an array is part of its type
18	20
19	21		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	22
21	23		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	24
23	25		[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	26
25	27		### There are no static variables and no initialization
26	28
27	29		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	30
29	31		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	32
31	33		### Related program components must be kept separate
32	34
33	35		No such strict order limitation in Object Pascal.
34	36
35	37		### There is no separate compilation
36	38
37	39		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	40
39	41		### Some miscellaneous problems of type and scope
40	42
41		-	~~`It is not legal to name a non-basic type as the literal formal parameter of a procedure; `~~
	43	+	``` pascal
	44	+	It is not legal to name a non-basic type as the literal formal parameter of a procedure;
	45	+	```
42	46
43	47		This is actually still true.
44	48
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	+	``` pascal
	50	+	It is nice to have the declaration 'var' for formal parameters of functions and procedures;
	51	+	the procedure clearly states that it intends to modify the argument. But the calling program
	52	+	has no way to declare that a variable is to be modified - the information is only in one place,
	53	+	while two places would be better.
	54	+	```
49	55
50	56		[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	57
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`\~~
	58	+	``` pascal
	59	+	Pascal's 'set' construct seems like a good idea, providing notational convenience and some free type checking.
	60	+	For example, a set of tests like
54	61
55		-	~~` if (c = blank) or (c = tab) or (c = newline) then ...`\~~
	62	+	if (c = blank) or (c = tab) or (c = newline) then ...
56	63
57		-	~~` can be written rather more clearly and perhaps more efficiently as`\~~
	64	+	can be written rather more clearly and perhaps more efficiently as
58	65
59		-	~~` if c in [blank, tab, newline] then ..`~~
	66	+	if c in [blank, tab, newline] then ..
	67	+	```
60	68
61	69		And [they're](http://www.freepascal.org/docs-html/ref/refsu20.html)!
62	70
63	71		### There is no escape
64	72
65	73		Type casting is available (and causing issues for some developers)
66	74
67	75		## Control Flow
68	76
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:`\~~
	77	+	```text
	78	+	There is no guaranteed order of evaluation of the logical operators 'and' and 'or' - nothing like && and \|\| in C.
	79	+	This failing, which is shared with most other languages, hurts most often in loop control:
71	80
72		-	~~` while (i <= XMAX) and (x[i] > 0) do ...`~~
	81	+	while (i <= XMAX) and (x[i] > 0) do ...
	82	+	```
73	83
74	84		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	85
76		-	~~`With no 'break' statement...`~~
	86	+	```text
	87	+	With no 'break' statement...
	88	+	```
77	89
78	90		There's [break](http://www.freepascal.org/docs-html/ref/refsu57.htm)
79	91
80		-	~~`The increment of a 'for' loop can only be +1 or -1, a minor restriction.`~~
	92	+	```text
	93	+	The increment of a 'for' loop can only be +1 or -1, a minor restriction.
	94	+	```
81	95
82	96		Still true.
83	97
84		-	~~`There is no 'return' statement, again for one in-one out reasons. `~~
	98	+	```text
	99	+	There is no 'return' statement, again for one in-one out reasons.
	100	+	```
85	101
86	102		There's Exit statement (FPC only Exit() ) available.
87	103
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.`~~
	104	+	```text
	105	+	The 'case' statement is better designed than in C, except that there is no 'default' clause and the behavior
	106	+	is undefined if the input expression does not match any of the cases. This crucial omission renders the 'case' construct
	107	+	almost worthless.
	108	+	```
91	109
92	110		There's [else (or otherwise)](https://www.freepascal.org/docs-html/current/ref/refsu56.html#x166-19000013.2.2) in case statement.
93	111
94	112		## The Environment
95	113
96	114		No problems with using System APIs and any I/O routines provided by an underlying environment.
97	115
98	116		## Cosmetic Issues
99	117
100		-	~~`But if something must be inserted before b, it no longer needs a semicolon, because it now precedes an 'end': `~~
	118	+	``` pascal
	119	+	But if something must be inserted before b, it no longer needs a semicolon, because it now precedes an 'end':
	120	+	```
101	121
102	122		A statement before "end" might have or not have a semicolon. Not-having a semicolon is not enforced.
103	123
104		-	~~`C and Ratfor programmers find 'begin' and 'end' bulky compared to { and }.`~~
	124	+	``` pascal
	125	+	C and Ratfor programmers find 'begin' and 'end' bulky compared to { and }.
	126	+	```
105	127
106	128		Is still true and there're no plans to change that.
107	129
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`~~
	130	+	``` pascal
	131	+	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
	132	+	except by knowing the names of the functions
	133	+	```
110	134
111	135		Is still true, except for FPC/objFPC mode, where a function call must come with ()
112	136
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:`\~~
	137	+	``` pascal
	138	+	In particular, there are no bit-manipulation operators (AND, OR, XOR, etc.).
	139	+	I simply gave up trying to write the following trivial encryption program in Pascal:
115	140
116		-	~~` i := 1;`\~~
117		-	~~` while getc(c) <> ENDFILE do begin`\~~
118		-	~~` putc(xor(c, key[i]));`\~~
119		-	~~` i := i mod keylen + 1`\~~
120		-	~~` end`~~
	141	+	i := 1;
	142	+	while getc(c) <> ENDFILE do begin
	143	+	putc(xor(c, key[i]));
	144	+	i := i mod keylen + 1
	145	+	end
	146	+	```
121	147
122	148		Bit-manipulation [operators](https://www.freepascal.org/docs-html/current/ref/refsu45.html) are available.
123	149
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'`\~~
	150	+	``` pascal
	151	+	There is no null string, perhaps because Pascal uses the doubled quote notation to indicate a quote embedded in a string
	152	+
	153	+	'This is a '' character'
127	154
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)`~~
	155	+	There is no way to put non-graphic symbols into strings. In fact, non-graphic characters are unpersons in a stronger
	156	+	sense, since they are not mentioned in any part of the standard language. Concepts like newlines, tabs, and so on
	157	+	are handled on each system in an 'ad hoc' manner, usually by knowing something about the character set
	158	+	(e.g., ASCII newline has decimal value 10)
	159	+	```
132	160
133	161		Escape characters are available.
134	162
135		-	~~` 'new line'#13#10`~~
	163	+	```text
	164	+	'new line'#13#10
	165	+	```
136	166
137	167		Needless to say, that Unicode escaping is available too.
138	168
139		-	~~`There is no macro processor.`~~
	169	+	```text
	170	+	There is no macro processor.
	171	+	```
140	172
141	173		God bless Pascal!
142	174
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`\~~
	175	+	``` pascal
	176	+	The 'const' mechanism for defining manifest constants takes care of about 95 percent of the uses of simple
	177	+	#define statements in C, but more involved ones are hopeless. It is certainly possible to put a macro
	178	+	preprocessor on a Pascal compiler. This allowed me to simulate a sensible 'error' procedure as
146	179
147		-	~~` #define error(s)begin writeln(s); halt end`~~
	180	+	#define error(s)begin writeln(s); halt end
	181	+	```
148	182
149	183		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	184
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;`~~
	185	+	``` pascal
	186	+	The language prohibits expressions in declarations, so it is not possible to write things like
	187	+	const SIZE = 10;
	188	+	type arr = array [1..SIZE+1] of integer;
	189	+	```
154	190
155	191		[Constant expressions](http://www.freepascal.org/docs-html/ref/refse9.html) are allowed as value of an expression.
156	192
157	193		## Perspective
158	194
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 `\~~
	195	+	``` pascal
	196	+	To close, let me summarize the main points in the case against Pascal.
	197	+	1. 2. 3. 4. 5. 6. 7. 8. ...
	198	+	9. There's no escape
162	199
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. ```~~
	200	+	This last point is perhaps the most important. The language is inadequate but circumscribed, because there
	201	+	is no way to escape its limitations. There are no casts to disable the type-checking when necessary.
	202	+	There is no way to replace the defective run-time environment with a sensible one, unless one controls
	203	+	the compiler that defines the ``standard procedures.'' The language is closed.
	204	+	```
167	205
168	206		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	207
170	208		---
171	209		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	210		Category: Promotion

Back to history