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.
People who use Pascal for serious programming fall into a
fatal trap. Because the language is impotent, it must be
extended. But each group extends Pascal in its own direction, to
make it look like whatever language they really want. Extensions
for separate compilation, FORTRAN-like COMMON, string data types,
internal static variables, initialization, octal numbers, bit
operators, etc., all add to the utility of the language for one
group but destroy its portability to others.
I feel that it is a mistake to use Pascal for anything much
beyond its original target. In its pure form, Pascal is a toy
language, suitable for teaching but not for real programming.
Pascal has since been almost entirely displaced (by C) from the niches it had acquired in serious
applications and systems programming, but retains some popularity
as a hobbyist language in the MS-DOS and Macintosh worlds.
Node:pastie, Next:patch, Previous:Pascal, Up:= P
=
pastie /pay'stee/ n.
An adhesive-backed label designed to be attached to a key on a
keyboard to indicate some non-standard character which can be
accessed through that key. Pasties are likely to be used in APL
environments, where almost every key is associated with a special
character. A pastie on the R key, for example, might remind the
user that it is used to generate the rho character. The term
properly refers to nipple-concealing devices formerly worn by
strippers in concession to indecent-exposure laws; compare tits on a keyboard.
Node:patch, Next:patch pumpkin, Previous:pastie, Up:=
P =
patch
1. n. A temporary addition to a piece of code, usually as a
quick-and-dirty remedy to
an existing bug or misfeature. A patch may or may not work, and
may or may not eventually be incorporated permanently into the
program. Distinguished from a diff or
mod by the fact that a patch is
generated by more primitive means than the rest of the program;
the classical examples are instructions modified by using the
front panel switches, and changes made directly to the binary
executable of a program originally written in an HLL. Compare one-line
fix. 2. vt. To insert a patch into a piece of code. 3.
[in the Unix world] n. A diff (sense
2). 4. A set of modifications to binaries to be applied by a
patching program. IBM operating systems often receive updates to
the operating system in the form of absolute hexadecimal patches.
If you have modified your OS, you have to disassemble these back
to the source. The patches might later be corrected by other
patches on top of them (patches were said to "grow scar tissue").
The result was often a convoluted patch space and headaches galore. 5.
[Unix] the patch(1) program, written by Larry Wall,
which automatically applies a patch (sense 3) to a set of source
code.
There is a classic story of a tiger
team penetrating a secure military computer that
illustrates the danger inherent in binary patches (or, indeed,
any patches that you can't -- or don't -- inspect and examine
before installing). They couldn't find any trap doors or any way to penetrate
security of IBM's OS, so they made a site visit to an IBM office
(remember, these were official military types who were
purportedly on official business), swiped some IBM stationery,
and created a fake patch. The patch was actually the trapdoor
they needed. The patch was distributed at about the right time
for an IBM patch, had official stationery and all accompanying
documentation, and was dutifully installed. The installation
manager very shortly thereafter learned something about proper
procedures.