|Compiler and interpreter origins firstname.lastname@example.org (Lauri Alanko) (2004-07-28)|
|Re: Compiler and interpreter origins Jeffrey.Kenton@comcast.net (Jeff Kenton) (2004-08-04)|
|Re: Compiler and interpreter origins email@example.com (Dick Weaver) (2004-08-05)|
|Re: Compiler and interpreter origins firstname.lastname@example.org (glen herrmannsfeldt) (2004-08-05)|
|Re: Compiler and interpreter origins email@example.com (Rodney M. Bates) (2004-08-09)|
|Re: Compiler and interpreter origins firstname.lastname@example.org (Nick Roberts) (2004-08-09)|
|Re: Compiler and interpreter origins email@example.com (2004-08-09)|
|Re: Compiler and interpreter origins firstname.lastname@example.org (John Slimick) (2004-08-09)|
|Re: Compiler and interpreter origins Martin.Ward@durham.ac.uk (Martin Ward) (2004-08-10)|
|Re: Compiler and interpreter origins email@example.com (Scott Moore) (2004-08-10)|
|Re: Compiler and interpreter origins firstname.lastname@example.org (2004-08-11)|
|Re: Compiler and interpreter origins email@example.com (Dave Thompson) (2004-08-23)|
|Re: Compiler and interpreter origins firstname.lastname@example.org (Jeremy Wright) (2004-08-25)|
|[2 later articles]|
|From:||email@example.com (Nick Maclaren)|
|Date:||9 Aug 2004 00:38:36 -0400|
|Organization:||University of Cambridge, England|
|Posted-Date:||09 Aug 2004 00:38:36 EDT|
Dick Weaver <firstname.lastname@example.org> 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
>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 ....
[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]
Return to the
Search the comp.compilers archives again.