Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!umd5!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Feeping Creaturism
Message-ID: <8802181921.AA19069@cory.Berkeley.EDU>
Date: 18 Feb 88 19:21:11 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 79

: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.

: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.
:Programmer productivity would climb dramatically.  More good public
:domain and commercial software would be written, in a shorter period of
:time.  Seeing the growing supply of good software for the Amiga, more
:people would buy the machine.  Everyone would be happy, and all good
:things would come to pass.

	What you are advocating would simply remove the load time
for each program.  Considering that RAM: on the Amiga goes at 800K/sec, the time
lost waiting for programs to load compared to the time the programs are actually
working is negligible.  This so called 'reduction' in turnaround time has
nothing whatsoever to do with an integrated vs nonintegrated enviroment, but
to the individual design of the programs in question.  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.

: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.

	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.  With the advent of better operating 
systems, many 'integrated' programs these days are actually completely
separate modules glued together, and thus hardly any more efficient than
loosly coupled systems.  The one advantage integrated systems have is the
ability to quickly flip from one module to another (though frankly, it's just
a mouse click in the enviroment I use).

	To be sure, such monsters as Lotus 1 2 3 and other giants running on
IBM PC's will allow you to quickly flip from one module to another, to move
data from one module to another , etc..., but one might wonder how easy it
is to move data between a module and an external program.  These Giants, after
all, cannot do everything.  The user gets into a hole; he becomes dependant
on the integrated program in question and never progresses any faster than
the company wants him to progress.

	And then there is always the underlying hardware one has.  Ever try
running Lotus from a floppy?  So much for the fast integrated system...  Ever
try running it without extended memory?  I've used various $5K+ CAD systems
on the IBM that are 'integrated'... works fine if you have 2+ Megs in your
system, though there are limitations to what they can do... limitations in
the size of files you can edit in their integrated editor, limitations in how
big a circuit it can handle... limitations mainly due to the fact that the
stupid machine is not intelligently removing modules not currently being used.

	Now you've got me talking about program problems rather than conceptual
problems.  But you can see that many current day integrated enviroment suffer
from problems to.

					-Matt