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: <714@sandino.quintus.UUCP>
Date: 1 Mar 88 00:14:35 GMT
References: <655@nuchat.UUCP> <657@sandino.quintus.UUCP> <670@nuchat.UUCP> <709@nuchat.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 103

In article <709@nuchat.UUCP>, peter@nuchat.UUCP (Peter da Silva) writes:
> Compiling in RAM:, with libraries and includes in VD0:, no precompiled
> includes (for this program thay'd save about 15 seconds)... 150 lines
> in... 36 seconds. Let me try something bigger... how about browser?
> 
> info.c                       945 rwed Today     20:45:25
> pointer.c                    873 rwed Today     20:45:24
> vollist.c                    733 rwed Today     20:45:17
> menu.c                      7340 rwed Today     20:45:15
> browser.c                  48862 rwed Today     20:45:07
> toolmenu.c                  2621 rwed Today     20:44:54
> copy.c                      5913 rwed Today     20:44:53
> 
> As you can see, I don't really practice what I preach about small files.

Few people do.  For reasons I cited before:  too much work to make a
change to one procedure that requires changes to others.  That, and the
fact that one often adds "just this one more procedure" to the file.
It never seems to make sense to start a whole file for a single
procedure....

> Let's time a full RAM: compile, eh?
> 
> 20:47:00 at start. Doing a bit of blitting around...
> 20:49:46 when browser.c has finished compiling. 2:46 for ~50K of code.
> 20:51:00 when all the rest have compiled. Another 1:14.
> 20:51:47 and it's all linked. Total of 4 minutes and 47 seconds. I guess
> I could take at most about a minute off for precompiled includes. I keep
> promising myself I'll chop browser.c up one of these days. Judge for yourself
> if this is fast enough.

A bit slow, but not too bad IF I DON'T HAVE TO DO IT VERY OFTEN.

> > And after you compile and link your program, and you edit it and change
> > one variable name somewhere, how long does it take you to compile and
> > link again.
> 
> Maximum of 5 minutes for a sizable program. More like a minute if I was
> being totally cool about modularization, and none of the files were over
> the 6K of copy.c.
> 
> If you have an incremental compiler, that goes down to 47 seconds, absolute
> minimum.

Why?  I still claim that a small change that only affects two or three
procedures needn't take more than a few seconds to recompile and
relink.  Remember, I'm talking about an INCREMENTAL compiler and
INCREMENTAL linker.  They would only parse the few procedures that have
changed (which, let's assume, are on ram disk of some sort), and
compile them.  This can't take more than a second or two, can it?  If
so, why?  Let's assume you're generating machine code directly (why
waste the time of generating assembler?), so now all you have to do is
modify the executable to include the new machine code, and back-patch
in the new addresses.  That can't take long, either.  I know I'm
glossing over some issues of how to extend an existing executable.  But
in principle it should be possible, and remember I'm talking about what
is POSSIBLE.  An integrated environment (let me hasten to repeat:  I'm
not endorsing the idea of integrated environments, just pointing out
again that they have some advantages) would not have to produce an
executable until you ask for one.  It could compile right into memory,
back-patch, free up the memory consumed by the old version of changed
procedures, and fire up the debugger.  That would be FAST, much faster
than 47 seconds.  Where'd the 47 number come from, anyway?

> 
> > 	1.  editing
> > 	2.  parsing
> > 	3.  compiling, optimizing, and assembling
> > 	4.  load and linking
> > 	5.  debugging
> 
> 	6.  documenting. Don't forget that one.

Actually, this should be 1.5, or even a part of 1.  Or maybe 0.

You mentioned that languages like Basic, FORTH, LISP, Smalltalk, etc.,
that are interactive are basically different from languages like C,
Modula-2, Pascal, Assembler, etc., that are batch-oriented.  Why?  It's
really the environments that are different, not so much the language.
Basic is pretty much an interactive FORTRAN environment.  Languages are
not batch, environments are.  There's no reason you can't have a C or
Pascal interpreter, and in fact such things exist.

In fact, you can even have an interactive development system without an
interpreter.  I've used a Lisp system that didn't have an interpreter,
only a compiler.  When you type in an expression, it compiles and
executes it.  This could be done for C, as well (and maybe it has).
This would make it MUCH easier to prototype things on the Amiga.  How
many times have you gone through the edit-compile-link-execute cycle
for short experiments?  Ones that really COULD have been run in not
much longer than it takes to type them?

It's not the language that makes development slow.  We CAN have speed,
and portability, and still have a decent development and
experimentation environment.  When the program is tested, THEN you
produce the stand-alone takes-5-minutes-to-compile-and-link version.
This should be possible.  At least in principle.

I hope JimG and JohnT are listening :-).
-- 
-Peter Schachte
pds@quintus.uucp
...!sun!quintus!pds