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: <692@sandino.quintus.UUCP> Date: 25 Feb 88 23:22:46 GMT References: <655@nuchat.UUCP> <657@sandino.quintus.UUCP> <670@nuchat.UUCP> Organization: Quintus Computer Systems, Mountain View, CA Lines: 121 Summary: Wrong level of granularity... In article <670@nuchat.UUCP>, peter@nuchat.UUCP (Peter da Silva) writes: > In article <657@sandino.quintus.UUCP>, pds@quintus.UUCP (Peter Schachte) writes: > > In article <655@nuchat.UUCP>, peter@nuchat.UUCP (Peter da Silva) writes: > > > I thought editor/assemblers went out back when 1K monitors stopped being > > > state-of-the-art... > > I thought BATCH compilers went out of style a year or two ago (:-). > I'm sure they went out of style, but then "in style" is usually not a good > reason for buying a product. After all, the IBM-PC is much more "in style" > than the Amiga... > > > ... 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. > > Let's turn that around... > > But until I can *enter the environment*, *load the source*, compile, link, and > load executable without having to read all my source files off the disk, > the modular systems are going to have an advantage that's hard to beat. The > integrated systems are too inefficient; they require too much stuff to be > resident in RAM through your whole modify-crash-debug cycle. They require > you to reload the system after the crash stage. Modular tools work very well > with this simple-yet-briliant tool called "make"... Hey, I use 'make' too (thanks Fred). But the level of granularity is wrong. I want to be recompiling PROCEDURES not FILES. Sure, I could put one procedure in each file, but it would be a real pain to change things. Often changes made in one procedure require changes in several other procedures. Perhaps a real EMACS with the TAGS package would make that easier. I don't know, I've never used TAGS. But even besides that, it would still be terribly inefficient, since the compiler would then have to read in all the includes FOR EACH PROCEDURE. If I change 10 procedures, I have to do 10 compiles. Even ignoring the time to load the compiler (which should be negligible when REZ comes out!), and even with precompiled includes, this would still be slower than having all that include information and linkage information already around, so all we have to do is modify the few things that have changed, and recompile the 10 procedures. If they're small procedures, that shouldn't take long. More on this below.... > > I've used a nice integrated Lisp environment with a structure editor, > > compiler, interpreter, (source level) debugger, profiling tools, etc. > > Lisp is a whole different kind of flying altogether. Could you also use > C, Fortran, and Modula-2 on the same machine? Nope. But Lisp isn't as different as you think. The thing Lisp has that C doesn't is dynamic typing. That makes it difficult to pass data structures between them. And Lisp has the ability to create code on the fly and run it. C can't do that either. So what? Just because the languages are different doesn't mean that the development styles have to be. There's nothing in my favorite development environment (the Xerox Lisp environment, if you're interested) that couldn't be done for C. At least nothing really important. > Ever worked with UNIX? :-> > > Or do you just read news here? It's a whole different kind of flying > altogether. Yea, I've been using UNIX for about 3 years, although not exclusively. That doesn't mean I like it. I find it too big and baroque. > I haven't seen an integrated environment on the PC that was worth the disk > it came on. Neither have I. In fact I haven't seen any integrated PC environments. Maybe none of them ARE any good. But that doesn't mean that they couldn't be. That you'll have to prove. > Perhaps you should try the Manx environment. I might just do that. I've been using Lattice 3.03 (came with my Amy), and am trying to decide between the $75 upgrade to 4.0 and switching to Manx. SDB (if the reviews I see here are positive enough) might just sway me to Manx. (Unless Lattice has plans for a source-level debugger of their own. Any comments, Lattice? :-) But, according to the Transactor review of Lattice, which compared it to Manx (3.4, I think), Manx compile times aren't all that much better. How long does it take you to compile and link, say, a 400 line (not counting comments) program? I'd really like to know. If it's in the 30-45 second range, that might be ok. 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. I thought so. I still stick to my assertion that the usual development style wastes an awful lot of work. Remember the two rules of computer science: (1) Don't do it. (2) Don't do it again. Of course, sometimes you have to brake rule (1). But the usual scheme breaks rule (2) all the time, too. Let's brake down our development cycle into these steps: 1. editing 2. parsing 3. compiling, optimizing, and assembling 4. load and linking 5. debugging Once a procedure is compiled, there's no reason to parse or compile, or relocate it again, or change any other procedure's calls to it unless it (or a macro it uses) changes. If a procedure changes, you only NEED to parse, compile, and load it, and then go back-patch everyone else's calls to it. I can't believe this would take a second for a, say, 50 line procedure (I'd welcome accurate figures from a compiler writer). And if you use a structure editor (calm down. it'll be okay. no one will MAKE you use it), you can drop the parsing phase, too. I don't care whether my environment is "integrated" or not. In fact, I'd rather it weren't. I'd rather use the OS, and multiple processes, to tie it all together. As long as it's fast. It's just that it seems easier to have a system that takes the kind of short-cut I propose above in an integrated environment. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds