Re: Compiler and interpreter origins (Nick Maclaren)
9 Aug 2004 00:38:36 -0400

          From comp.compilers

Related articles
Compiler and interpreter origins (Lauri Alanko) (2004-07-28)
Re: Compiler and interpreter origins (Jeff Kenton) (2004-08-04)
Re: Compiler and interpreter origins (Dick Weaver) (2004-08-05)
Re: Compiler and interpreter origins (glen herrmannsfeldt) (2004-08-05)
Re: Compiler and interpreter origins (Rodney M. Bates) (2004-08-09)
Re: Compiler and interpreter origins (Nick Roberts) (2004-08-09)
Re: Compiler and interpreter origins (2004-08-09)
Re: Compiler and interpreter origins (John Slimick) (2004-08-09)
Re: Compiler and interpreter origins (Martin Ward) (2004-08-10)
Re: Compiler and interpreter origins (Scott Moore) (2004-08-10)
Re: Compiler and interpreter origins (2004-08-11)
Re: Compiler and interpreter origins (Dave Thompson) (2004-08-23)
Re: Compiler and interpreter origins (Jeremy Wright) (2004-08-25)
[2 later articles]
| List of all articles for this month |

From: (Nick Maclaren)
Newsgroups: comp.compilers
Date: 9 Aug 2004 00:38:36 -0400
Organization: University of Cambridge, England
References: 04-07-077 04-08-023
Keywords: history, comment
Posted-Date: 09 Aug 2004 00:38:36 EDT

Dick Weaver <> wrote:
>Some mindsets that come to mind (reading over this list, I can't really
>distinguish between mindset and environment):
>1. Compilers were thought of as "Automatic Programming". An early
>report on Fortran, 1957, was "The Fortran Automatic Coding System"

Only in the sense of "automatic macro expansion". Remember that was
in the days when analysts wrote flow-charts and programmers coded them
into assembler.

>2. There was only one criterion for good vs. bad compilers:
efficiency of >the generated code.

Absolutely NOT! Certainly by the early 1960s, the concept of
debugging compilers existed, which were expected to have thorough
diagnostics, insert good checking and compile very fast. What
happened to that concept, I wonder? :-(

Even in the early 1950s, the memory and time requirements of a
compiler were an issue. I should have to ask whether anyone can
remember the relevant priorities.

> 5. Users with problems requiring computer solutions took their
>problem to a programmer. Only after high-level languages "advented"
>(in particular, FORTRAN) did it become COMMON for users to write
their own >programs.

Not in Cambridge! Here, users programmed in machine code and autocode
before Fortran was invented. EDSAC I was the first practical general
purpose computer, and EDSAC II was used by a wide spectrum of the
university (including Arts and Humanities). Of course, I am relying
on my seniors' claims, as as a mere stripling of 56 :-)

>6. Cascading compilers. For example, FORTRANSIT (IBM 650) input was
>FORTRAN, the compiler output was an IT program. The IT compiler
>produced SOAP (the 650s assembly language) output. The SOAP processor
>produced your object deck.

Yup. IAL on Titan - not a bad assembler. Typical optimising compilers
had half a dozen passes, often implemented as separate programs, and
some of them had external specifications.

>7. Languages were sometimes designed/implemented by people trying to
>solve their own problems. IPL, LISP being examples.

Aren't they still? Perl, Python, Java ....

Nick Maclaren.

[The original Fortran computer emitted extremely good code because the
conventional wisdom was that compiled scientific code would be too
slow to be useful. I gather that not long after it was shipped, they
added an option to compile faster by skipping some of the optimization
and generate worse code, which everyone always used. Code speed
wasn't a big issue for Cobol, since commercial programs are invariably
I/O bound, but I don't know what the adoption issues were. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.