Re: lcc intel backend? compile time?

tchannon@black.demon.co.uk (Tim Channon)
Thu, 21 Oct 1993 15:36:15 GMT

          From comp.compilers
Related articles
Re: lcc intel backend? compile time? rds95@csc.albany.edu (1993-10-13)
Re: lcc intel backend? compile time? graham@pact.srf.ac.uk (1993-10-13)
Re: lcc intel backend? compile time? cliffc@rice.edu (1993-10-13)
Re: lcc intel backend? compile time? rds95@csc.albany.edu (1993-10-13)
Re: lcc intel backend? compile time? pardo@cs.washington.edu (1993-10-20)
Re: lcc intel backend? compile time? henry@zoo.toronto.edu (1993-10-20)
Re: lcc intel backend? compile time? tchannon@black.demon.co.uk (1993-10-21)
Re: lcc intel backend? compile time? henry@zoo.toronto.edu (1993-10-22)
| List of all articles for this month |
Newsgroups: comp.compilers
From: tchannon@black.demon.co.uk (Tim Channon)
Keywords: C, performance, tools
Organization: Compilers Central
Date: Thu, 21 Oct 1993 15:36:15 GMT

> What better tools *actually* do, is make individual differences more
> prominent. Sloppy writers/programmers/etc. do indeed turn out sloppier
> work, because they're not forced to stop and think. But the *better*
> writers/programmers/etc. can spend more time getting things really right,
> instead of having to settle for second best because just getting to that
> point is hard enough.


I suspect that there is truth in both arguments.


A fast crash cycle tends to lead to hacking, not programming.


There seems to be a low takeup of interpreted C which given the lower
reliability of freshly coded source implies that a fast crash cycle isn't
that important or is there anouther explanation?


    TC.
        E-mail: tchannon@black.demon.co.uk or tchannon@cix.compulink.co.uk
--

Post a followup to this message

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