View source for Why Pascal is Not My Favorite Programming Language

"Why Pascal is Not My Favorite Programming Language" is an article (can be found [http://www.lysator.liu.se/c/bwk-on-pascal.html here]) written about by Brian W. Kernighan, April 2, 1981. The article is often used in language comparison discussions even today, typically by critics of Pascal-family. Despite of the fact that the article is talking about the language that is there no more. The description of the language that B Kernighan is referring to in the article could be found [http://www.standardpascal.com/The_Programming_Language_Pascal_1973.pdf here].

The purpose of this page, is to show that the article is quite out-dated. People who are still trying to refer to the article don't know what the current Pascal (Delphi/FPC) are.

==Genesis==
==Article==
===Types and Scopes===
 Integer variables may be declared to have an associated range of legal values, and the compiler and run-time support 
 ensure that one does not put large integers into variables that only hold small ones.  This too seems like a service,
 although of course run-time checking does exact a penalty. 
It needs to be noted here, that compiler allows to remove the range run-time check completely. 
===The size of an array is part of its type===
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.

The 1985 Ansi/ISO standards have an (optional) section about conformant arrays fixing this. Currently neither FPC (ISO mode) nor Borland derivatives implement it.

[http://www.freepascal.org/docs-html/ref/refsu18.htm Dynamic] and [http://www.freepascal.org/docs-html/ref/refsu64.html Open arrays] 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.

===There are no static variables and no initialization===
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.

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).
===Related program components must be kept separate===
No such strict order limitation in Object Pascal.
===There is no separate compilation===

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.

===Some miscellaneous problems of type and scope===
 It is not legal to name a non-basic type as the literal formal parameter of a procedure; 
This is actually still true.
 It is nice to have the declaration 'var' for formal parameters of functions and procedures; 
 the procedure clearly states that it intends to modify the argument.  But the calling program 
 has no way to declare that a variable is to be modified - the information is only in one place,
 while two places would be better.
[http://www.freepascal.org/docs-html/ref/refsu63.html const] is available to identified unmodified parameter and passing a parameter by reference (where applicable)
 Pascal's 'set' construct seems like a good idea, providing notational convenience and some free type checking.  
  For example, a set  of tests like
 
     if (c = blank) or (c = tab) or (c = newline) then ...
 
  can be written rather more clearly and perhaps more efficiently as
 
     if c in [blank, tab, newline] then ..
And [http://www.freepascal.org/docs-html/ref/refsu20.html they're]!

===There is no escape===
Type casting is available (and causing issues for some developers)
==Control Flow==
 There is no guaranteed order of evaluation of the logical operators 'and' and 'or' - nothing like && and || in C.  
 This failing, which is shared with most other languages, hurts most often in loop control:
 
     while (i <= XMAX) and (x[i] > 0) do ...
Conditions are [http://www.freepascal.org/docs-html/ref/refsu53.html short-cut evaluated].  Thus loops can be implemented the way above without a risk breaking out of the range.

 With no 'break' statement...
There's [http://www.freepascal.org/docs-html/ref/refsu57.htm break]
 The increment of a 'for' loop can only be +1 or -1, a minor restriction.
Still true.
 There is no 'return' statement, again for one in-one out reasons. 
There's Exit statement (FPC only Exit() ) available.
 The 'case' statement is better designed than in C, except that there is no 'default' clause and the behavior 
 is undefined if the input expression does not match any of the cases.  This crucial omission renders the 'case' construct 
 almost worthless.
There's [http://www.freepascal.org/docs-html/ref/refsu52.html default] in case statement.
==The Environment==
No problems with using System APIs and any I/O routines provided by an underlying environment.
==Cosmetic Issues==
 But if something must be inserted before b, it no longer needs a semicolon, because it now precedes an 'end': 
A statement before "end" might have or not have a semicolon. Not-having a semicolon is not enforced.
 C and Ratfor programmers find 'begin' and 'end' bulky compared to { and }.
Is still true and there're no plans to change that.
 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 
 except by knowing the names of the functions
Is still true, except for FPC/objFPC mode, where a function call must come with ()

 In particular, there are no bit-manipulation operators (AND, OR, XOR, etc.).  
 I simply gave up trying to write the following trivial encryption program in Pascal:
 
     i := 1;
     while getc(c) <> ENDFILE do begin
             putc(xor(c, key[i]));
             i := i mod keylen + 1
     end
Bit-manipulation [http://www.freepascal.org/docs-html/ref/refsu42.htm operators] are available.

 There is no null string, perhaps because Pascal uses the doubled quote notation to indicate a quote embedded in a string
  
    'This is a '' character'
 
 There is no way to put non-graphic symbols into strings.  In fact, non-graphic characters are unpersons in a stronger 
 sense, since   they are not mentioned in any part of the standard language.  Concepts like newlines, tabs, and so on 
 are handled on each system in an  'ad hoc' manner, usually by knowing something about the character set 
 (e.g., ASCII newline has decimal value 10)
Escape characters are available. 
  'new line'#13#10
Needless to say, that Unicode escaping is available too.
 There is no macro processor.
God bless Pascal! 
 The 'const' mechanism for defining manifest constants takes care of about 95 percent of the uses of simple 
 #define statements in C, but more involved ones are hopeless.  It is certainly possible to put a macro 
 preprocessor on a Pascal compiler.  This allowed me to simulate a sensible 'error' procedure as
 
     #define error(s)begin writeln(s); halt end
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.
 The language prohibits expressions in declarations, so it is not possible to write things like 
   const   SIZE = 10;
   type    arr = array [1..SIZE+1] of integer;
[http://www.freepascal.org/docs-html/ref/refse9.html Constant expressions] are allowed as value of an expression.

==Perspective==
 To close, let me summarize the main points in the case against Pascal. 
 1. 2. 3. 4. 5. 6. 7. 8.  ...
 9. There's no escape 
 
 This last point is perhaps the most important.  The language is inadequate but circumscribed, because there 
 is no way to escape its limitations.  There are no casts to disable the type-checking when necessary.  
 There is no way to replace the defective run-time environment with a sensible one, unless one controls 
 the compiler that defines the ``standard procedures.'' The language is closed.
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.


[[Category:Promotion]]