|[13 earlier articles]|
|Re: A lesson for compiler warning writers firstname.lastname@example.org (1992-06-20)|
|Re: A lesson for compiler warning writers email@example.com (1992-06-21)|
|Re: A lesson for compiler warning writers mjr@decuac.DEC.COM (1992-06-22)|
|Re: A lesson for compiler warning writers firstname.lastname@example.org (1992-06-22)|
|Re: A lesson for compiler warning writers email@example.com (1992-06-22)|
|Re: A lesson for compiler warning writers firstname.lastname@example.org (1992-06-23)|
|Re: A lesson for compiler warning writers email@example.com (Ronald Bodkin) (1992-06-23)|
|Re: A lesson for compiler warning writers mjr@decuac.DEC.COM (1992-06-23)|
|Interpreters and computationally intensive programs firstname.lastname@example.org (1992-06-24)|
|From:||Ronald Bodkin <email@example.com>|
|Keywords:||C, interpreter, linker, design|
|Organization:||MIT Lab for Computer Science|
|Date:||Tue, 23 Jun 1992 07:38:21 GMT|
mjr@decuac.DEC.COM (Marcus J. "will do TCP/IP for food" Ranum) writes:
Compilation is (IMHO) the last step in developing code. I want to
develop in an interactive environment that supports and enhances me as
much as I want - compiling should be relegated to the phase where you are
performance tuning and validating before you ship product.
This is sometimes impractical... on any project where there is a serious
amount of computation*, you can't afford to test and run interpreted code
because of the delay involved in testing/using the program. In such
cases, a good incremental compiler+debugger is a necessary adjunct to an
interpreter for high speed development (most modern lisps give you both &
I find that the reduced compile-time is a big plus).
[We've gotten used to slow compilers, but they can be a lot faster than GCC
Aren't Borland C++ and Microsoft's Quick C (it's incremental right?) much
better, given the hardware/OS limitations under which they operate?
* Right now, I'm working on a search program and sometimes bugs appear
after several million nodes are examined. If interpretation slows things
down by 1 order of magnitude, this makes a wait of 3 minutes to recreate a
bug turn into 30...
[Unless they've changed the design recently, neither Turbo nor Quick C are
incremental, just fast. At least one of them has precompiled headers which
you might think of as a rudimentary kind of incremental compilation. -John]
Return to the
Search the comp.compilers archives again.