The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <>
To: Ralph Corderoy <>
Subject: Re: [TUHS] ratfor vibe
Date: Tue, 1 Feb 2022 11:58:02 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 5192 bytes --]

On Tue, Feb 1, 2022 at 10:53 AM Ralph Corderoy <>

> I agree the original Software Tools is a must read, but having done so,
> why would I suffer working through the hurdles put in place by Pascal
> compared to Ratfor?

I'll take a stab.  Again set Arnold's  Way-Back machine to the late '60 and
through the mid 1970s.  The Algol vs. FTN war was raging.   FTN had 'won'
the Science and Engineering communities and Algol was the Math/CS types
[I'm over simplifying].   In fact, when I was at CMU in the mid-70s; my
professors all said *FTN was dead*  ( mind you production quality FTN code
has paid my salary in the HPC world my entire career ).  At CMU, the
compromise is all engineers were required to take an intro to computing
using in FTN/WATFIV course and then all other 200 level or greater CS
course after that were usualy based using an Algol/ or later Pascal.

The point being any reasonable computer system being brought to market
by a *credible
systems vendor* had at least an implementation of FTN4 that could pass the
ANSI test suite and many started to have one that support F77 [although
thank you DEC VMS FTN != F77].   But ... because of the push from the
teaching/CS side in most places, Pascal started to show up as a standard
offering [C did not - yet - have that backing].   I suspect if you check my
generation and for the next 10-20 years after, you will see Pascal was the
first language you saw in college.

So by the late 70s/early 80s, [except for MIT where LISP/Scheme reigned]
Pascal had become the primary teaching language for the CS communities at
most schools.   C was considered a tad 'dirty' [not as bad as assembler --
but close].  It might have been used in an OS or Compiler course.  In fact
in the grad Graphics course I took, which was taught by Xerox folks, I had
to get a special exception to use C.

But the fact is, at that time, if you read the literature, you would
believe that Pascal was going to be the future. Hence the concept of doing
the SWT in Pascal made sense >>in theory<<. Another important fact was that
while the P4 system made moving Pascal easier than many other languages, as
Rob pointed out, the Pascal I/O was so screwy and frankly not well bound to
the host OS, that every new implementation messed with it in some manner
[see Brian's wonderful tome for more details].   Similarly, the lack of
standardized way to do separate compilation for support libs (which had
been a prime idea in FTN and allowed a rich market for libraries), really
had a huge effect.  Again it was solved many times with each compiler
implementation, but each scheme tended to be a little different.

Fortran, of course, had been around long enough and had an ANSI standard
(and a test suite for it) at least made portable FTN possible.

So the theory was good -- Pascal was a 'better' language in theory and
everyone was coming out of school knowing it.

Again, reality ...  since UNIX came with C and was 'open source' in the
sense that everyone that had it, had the AT&T source code.  One of the
first things that happened was C was retargeted to a number of processors
-- often not by either the manufacturer or by the system vendor.
Interestingly, this was about 50/50 between Academics/Research and
Industry.   So while all the world's ISA were not a PDP-11, the fun part is
the code *could be made reasonably* portable - in fact *in practice*
[partly because C had a pre-processor which Pascal did not and of course is
what ratfor is] have one source base that could compile for different

The problem (as you note) these issues are >>obvious<< in hindsight, but
during that time -- it was not.  It certainly seems like Pascal had a lot
of momentum. They were a lot compilers for a lot of systems.   Look, it was
the language Apple used for the Lisa and Mac.  Things like UCSD Pascal was
being made by the press as 'the answer for 8 bit processors' [note MSFT had
a FTN for the 8080 on CPM in those days].   Turbo Pascal was, in fact,
an excellent compiler.  But C was starting to come on strong.

FWIW:  In the end, I personally believe that C 'won' because the practical
side made it cheaper to use (economics always beat architecture).  The
cynical part of me thinks that a big reason why C++ caught on is because a
lot of the pro-Pascal community got to sing the praises of OOP with C++ and
they could change sides without claiming C beat Pascal.  Hey, Microsoft
made a pretty good C for DOS and finally going C++ probably helped.  It
sold more than the FORTRAN and my guess is that people using FORTRAN at
that point were scientists and needed the address space that 8086 did not
have. The 386 with a linear address for using things like the PharLap tools
made it possible and frankly the Intel 8087 started to make that processor
a better target for science.

In the end, Pascal never had a code base like the FTN Scientific code base
or todays C and C++ code base.   FWIW: I can think of few production Pascal
codes from those days that are still being used [other than the Front-End
of the DEC/Intel FORTRAN compiler - which was moved from BLISS to Pascal
for all the same 'C is dirty' issues BTW].

[-- Attachment #2: Type: text/html, Size: 7504 bytes --]

  reply	other threads:[~2022-02-01 16:59 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 20:46 Will Senn
2022-02-01 15:37 ` arnold
2022-02-01 15:52   ` Ralph Corderoy
2022-02-01 16:58     ` Clem Cole [this message]
2022-02-01 17:02     ` silas poulson
2022-02-02  7:47     ` arnold
2022-02-03  5:47       ` [TUHS] more about Brian Rich Morin
2022-02-03  7:44         ` markus schnalke
2022-02-03  8:18           ` Rich Morin
2022-02-04  2:23           ` Adam Thornton
2022-02-04  2:34             ` [TUHS] more about Brian... [really Rust] Jon Steinhart
2022-02-04 13:07               ` Thomas Paulsen
2022-02-04 23:18               ` Dan Cross
2022-02-04  3:28             ` [TUHS] more about Brian Dan Stromberg
2022-02-04  5:11             ` Rich Morin
2022-02-04 21:22               ` [TUHS] Go vs. Rust, and etc. (was: more about Brian...) Greg A. Woods
2022-02-04 21:37                 ` Richard Salz
2022-02-04 22:32                   ` Steffen Nurpmeso
2022-02-04 23:05                   ` Thomas Paulsen
2022-02-04 23:15                   ` Seth J. Morabito
2022-02-05  1:41                     ` Adam Thornton
2022-02-04  7:38             ` [TUHS] more about Brian Andy Kosela
2022-02-04  8:10               ` Steve Nickolas
2022-02-04  8:44                 ` markus schnalke
2022-02-04  9:16                   ` Steve Nickolas
2022-02-04 18:54                 ` John Cowan
2022-02-04 19:45                   ` Thomas Paulsen
2022-02-04 20:28                     ` Hellwig Geisse
2022-02-04 21:03                       ` Jim Capp
2022-02-04 22:30                         ` Steffen Nurpmeso
2022-02-04 22:25                       ` Steffen Nurpmeso
2022-02-06  0:56                       ` Larry McVoy
2022-02-06  1:10                         ` Will Senn
2022-02-06  4:52                           ` Rob Pike
2022-02-06  4:58                             ` Dan Halbert
2022-02-06  5:06                             ` Will Senn
2022-02-06  6:19                             ` Ed Carp
2022-02-06  6:27                               ` Rob Pike
2022-02-06  6:40                                 ` Stuart Remphrey
2022-02-06  6:44                                 ` Bakul Shah
2022-02-06 19:08                                   ` Steffen Nurpmeso
2022-02-06 12:52                                 ` Ralph Corderoy
2022-02-06 13:14                                 ` Ed Carp
2022-02-06 14:13                                   ` Dan Cross
2022-02-06 14:15                                   ` Larry McVoy
2022-02-06 16:31                                     ` Warner Losh
2022-02-06 18:36                                     ` [TUHS] more about Brian... [ really GC vs malloc/free languages ] Jon Steinhart
2022-02-06 19:27                                     ` Jon Steinhart
2022-02-06 19:33                                       ` Warner Losh
2022-02-06 19:37                                         ` Jon Steinhart
2022-02-06 20:21                                           ` [TUHS] COFF is over there Ralph Corderoy
2022-02-06 16:16                           ` [TUHS] more about Brian Brad Spencer
2022-02-08  5:22                             ` Ed Carp
2022-02-03 18:57       ` [TUHS] ratfor vibe silas poulson
2022-02-04  8:26         ` arnold
2022-02-04 19:41           ` John Cowan
2022-02-10 15:18       ` Ralph Corderoy
2022-02-03  4:00 ` Will Senn
2022-02-03  4:31   ` Al Kossow
2022-02-03  5:16     ` Warner Losh
2022-02-03 20:00   ` Adam Thornton
2022-02-04  6:06     ` Ori Idan
2022-02-04 17:35       ` Adam Thornton
2022-02-04 17:44         ` Will Senn
2022-02-01 18:19 Noel Chiappa
2022-02-01 18:47 ` Clem Cole
2022-02-01 19:10   ` Dan Cross
2022-02-01 19:39     ` Clem Cole
2022-02-01 21:21       ` Dan Cross
2022-02-01 21:33         ` Clem Cole
2022-02-01 23:12           ` John Cowan
2022-02-01 19:39   ` Richard Salz
2022-02-01 22:30   ` Erik E. Fair
2022-02-02  0:54     ` Yeechang Lee
2022-02-01 21:50 ` Win Treese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).