[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Toby Thain]

On 2017-08-31 10:38 PM, Dan Cross wrote:
> On Thu, Aug 31, 2017 at 3:47 PM, Toby Thain <toby at telegraphics.com.au
> <mailto:toby at telegraphics.com.au>> wrote:
> [snip] 
> 
>     > But the problem was that in those days, because Wirth had designed it
>     > for complete small student programs, it was hard to write large real
>     > programs (as Brian points).  So people fixed it and every fixed it
>     > differently.  Pascal was hardly standardized. ...
>     >
>     > And this was the root of the real problem.
>     >
>     > You could not write “real” programs in it and really make them run on
>     > actual systems.   Brian was writing that paper, after an exercise in
> 
> 
>     Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal
>     (using his literate programming toolset, but that did not extend the
>     language much).
> 
> 
> To be fair, I think that Knuth originally wrote both TeX and METAFONT in
> the SAIL language for the PDP-10. He switched to Pascal (again on the
> PDP-10) later.
> 
> I've often wondered to what extent (natural) language shapes thought ...

> I have long suspected that it is true of programming. 

I don't think any of the above is in doubt.


> While most of the
> languages we use are Turing complete (I suppose that in the limit one
> can write a Common Lisp implementation in C, for example), it is
> unarguable that some languages make it *easier* to express some things
> than other languages. In some cases this is deliberate: consider
> languages with strong, static type systems versus dynamic but strongly
> typed languages (or statically but weakly typed). Here the language
> designers have intentionally made it hard to escape the tyranny of the
> type system in order to prevent bugs.

(Tyranny is not the word I would use. A more modern viewpoint would
include topics like parametric polymorphism, typeclasses and so on.)

> 
> Anyway, I wonder if Knuth would have produced the same TeX and METAFONT
> had he started in Pascal; perhaps he would have, but maybe he would have
> given up on some of the more ambitious parts of both because the
> language made it much less convenient (not knowing SAIL, I'm


It seems inconceivable to me that there are "ambitious parts" of TeX and
METAFONT that Professor Knuth had to omit because he was using Pascal.
Knuth has shown himself in various ways (including MIX, but also his
literate programs in Pascal and C) to prefer programming at low levels
(by modern standards) but his code amply shows that Pascal barely
presented any impediment to doing so -- though he now uses literate C.

Of course his programs would look different in, say, Haskell or Ocaml.

I have not compared the codebases but wouldn't one expect that the final
production TeX rewrite is *more* ambitious than the early SAIL version?
(By the time I began using/porting TeX in the 1980s, the older version
was completely obsolete.)


> speculating). Perhaps having gone through the exercise of producing TeX
> in SAIL gave him insight that inspired him to work around Pascal's
> expressive limitations. Or perhaps the opposite is true.

I honestly don't know what limitations you mean. If you mean "different
style of expression," sure. (Maybe if SAIL had lexically scoped lambda
closures, there'd be a difference worth talking about...)

> 
> Regardless, comparing the work of a Knuth to the industry average is
> more than a bit unfair. :-)
> 
>     I suppose Apple's Pascal and Object Pascal -- used for Lisa and
>     Macintosh applications and systems software -- comes under the "so
>     people fixed it" category?
> 
> 
> Object Pascal, Delphi and Free Pascal (which seeks to implement the best
> of both) seem to have definitely fallen into that category.

I'm not sure if the Apple compiler used circa 1983 was *Object* Pascal
but it was certainly extended with many intrinsics, casts, and pointer
operations, bringing it essentially into parity with C for systems and
application programming.

--Toby


> 
>         - Dan C.
>