Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!pds
From: pds@quintus.UUCP (Peter Schachte)
Newsgroups: comp.sys.amiga
Subject: Re: Feeping Creaturism
Message-ID: <682@sandino.quintus.UUCP>
Date: 22 Feb 88 20:59:11 GMT
References: <8802181921.AA19069@cory.Berkeley.EDU>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 112
Summary: You missed my point

In article <8802181921.AA19069@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
> :Sure, the "different tools for different jobs" school has a lot to be
> :said for it.  I agree with the principle.  But until I can compile,
> :link, and load executable into my source level debugger in a second or
> :two with a standard editor-compiler-linker-debugger configuration, the
> :integrated systems are going to have an advantage that will be hard to
> :beat.  The separate tools are too inefficient; they repeat too much
> :work, reparsing, recompiling and relinking stuff that hasn't changed,
> :every time through the modyfy/test cycle.
> 
> 	I could think of several good words to describe your view, but
> I'm afraid they would be unacceptable to the net.  To put it simply,
> you are wrong in every sense of the word.  You blame the method instead
> of the program.

Perhaps you're right, I AM blaming the method rather than the program.
Compilers and linkers COULD get around the problems I'm complaining
about, if they really wanted to.  But they don't.  It's not that the
method makes it impossible, just much more difficult.

In the following quote, you omitted an important part.  I proposed an
IFF form for program source code that would allow an editor to mark
what had changed since the last time the program was compiled.  This
would allow for incremental compilers.  I suppose a current-technology
compiler could make a copy of the source code it compiled most
recently, and diff it against the code it's being asked to compile to
determine what has changed.  It might even be worth it.  But I have yet
to see a compiler that does it.  I have yet to see (or even hear of) an
incremental compiler that was not integrated with an editor.  Do you
have any examples you can cite?  (This is not a rhetorical question:
I'd be very interested to hear of one).
> 
> :Given this approach, you could supply your own editor, compiler, and
> :debugger, as long as they understood this format, and they would still
> :operate efficiently together.  Turnaround time would drop sharply....
> 
> 	What you are advocating would simply remove the load time
> for each program....  Unless you use  
> radically different algorithms (example: incremental compilation vs normal
> compilation), you will not see much of an increase in efficiency no matter
> how integrated your enviroment is.

Of course.  Wasn't I clear?  I'm talking about an incremental compiler.
> 
> :compiler, interpreter, (source level) debugger, profiling tools, etc.
> :Changing code and retesting is almost instantaneous.  And I've been
> :programming the Amiga using emacs, a slow compiler, slow linker, and
> :many visits from the guru.  Turn around is a couple of minutes to try a
> :small experiment.  If the guru stops by, rebooting is another couple of
> :minutes.  I hope it's clear which I find to be the more productive
> :programming enviornment.
> 
> 	You are blaming the lack of an integrated enviroment for the slow
> turnaround time, and comparing it to your lisp machine.  I would like to
> point out that good Lisp machine's usually have incremental compilers.
> I would also like to point out that one does not need to be in an
> integrated enviroment to use an incremental compiler.
> 
Please give an example of an incremental compiler that is not part of
an integrated environment.

> 	Integrated enviroments are for the birds.  Integrated design plays havoc
> on software developers trying to upgrade or port programs to other machines, and
> was originally conceived to combat even longer cycles on machines which had,
> essentially, no operating systems....

Now YOU're talking about programs, rather than conceptual problems.  If
Turbo C or Saber-C (an integrated C interpreter environment on Suns)
programs can't easily be ported to other machines, that's the fault of
Turbo C and Saber-C , not the fault of the concept of an integrated
environment.

But I agree with all your points about integrated environments.  I'd
rather have the OS act as the integrator of my editor, my INCREMENTAL
compiler, and my INCREMENTAL linker, and my source-level debugger, too.
But I'd rather have an integrated environment with an incremental
compiler/assembler than a non-integrated non-incremental setup.  I'm
willing to be stuck with someone else's editor (and other tools) if it
means I can make a change and be testing it in a few seconds, rather
than mintues.

This all started when someone was (I believe) reacting to AssemPro.
They suggested that integrated environments are obsolete, and that no
one should buy such a thing.  I've never seen AssemPro, nor even seen an
ad for it, so I have no idea what it can do.  Perhaps it is truely a
bad package.  But if it will let an assembly language developer build
his code much more quickly, and still present reasonably portable code
(remember that Amiga C code isn't portable between Aztec and Lattice,
either), why should we dismiss it?  Sure, I'd rather use my own editor
(as long as I can customize it for the language I'm coding in, so that
it knows something about the syntax, comment conventions, etc.), and
rather have the flexibility of the OS to tie together the components of
the system.  But loosing that is not such a terribly high price to pay
for a significant improvement in turnaround time.

Again, just to make sure I'm being clear (it seems my writing is not as
clear it should be :-(), I'm not saying that I've seen any Amiga
integrated environments that I think are good things.  Nor am I saying
that I like the concept of an integrated environment.  All I'm saying is
that they have some potential advantages over separate components, since
individual tools within an integrated environment can share information
(parsed code, indications of what has changed, etc.)  more easily than
current purely text-based tools.  (Yes, yes, I know there are advantages
to purely text-based tools.  Let's not start up THIS war.  It just died
down in comp.lang.lisp.)  That is why I proposed a new IFF form for
source code.  This would allow for separate tools from different
suppliers to behave in useful ways as if they were integrated (e.g.,
incremental compilation).
-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds