russ (03/24/83)
#N:hp-cvd:6400001:000:2556 hp-cvd!russ Mar 22 16:08:00 1983 What you are really arguing about is the usefulness of programming enviornments. BASIC, APL, Lisp, Logo, TRAC are generally used in programming enviornments. Algol, Fortran, C, and Pascal are generally not integrated into their enviornments. In other words, you need to explicitly compile the latter while the former enviornments hide the compiliation from you. What you are not arguing about is interpreters/compilers. There are two ends of the spectrum: a 100% interpreter runs the source code, while a 100% compiler produces absolute machine code. Anything other than these blurs the distinction. What do you call a system which compiles the source to produce p-codes and then interprets them? Opinion (he says, implying that the latter was fact): I feel that a programming enviornment is always better for the disciplined programmer. Note the qualifier "disciplined". When I sit down in front of whichever computer I am using, I usually know what I'm trying to accomplish. I usually know how I'm going to accomplish it. I find that when I don't know \exactly/ what I'm trying to do, I discover that very quickly. My code reflects that fact that I don't know what I'm doing. In short, I get diherrea of the fingers. When this happens, I go off bicycling, juggling, read notes or whatever amuses me. For I know that there's no way that I'm going to be doing any productive programming. Note that I'm not goofing off. What I'm trying to do is get my brain working "in the background". By presenting my brain with the problem and then getting out of the way, the solution usually pops right up in a while. This is how I program. I never "run" programs by hand. The computer is a far better computer than I. I haven't always done it this way. I have discovered this method over a long period of time (nine years). Once, I wrote a disassembler for the PDP-8 completely on paper. This was over summer vacation when I didn't have access to a computer and had lots of free time at my summer job. Amazingly, the program had only two bugs: one fell out trivially and the other was caused by a bug in the assembler. So don't think that I haven't tried all sorts of programming styles. I'm curious to see how other people program. I'm sure you're just waiting (with hot hands) to tell me. I'm also confident, after reading the "hiding the compiler" series, that other people are interested, so post replies to the net. I don't think that too many people will respond. Russ Nelson ...hp-pcd!hp-cvd!russ aka kirk!russ
idhopper (03/30/83)
This technique works well for problems in which it is possible to have a clear and unambiguous idea of what you want to do and how to do it. Where it fails is in the writing of programs to solve ill-defined problems with ill-defined algorithms (e.g artificial intelligence, sophisticated interactive systems). In this case, you want to shorten the edit-run-debug cycle as much as possible because you cannot evaluate the system except by making a prototype, seeing how it works, and then modifying it according to how it appears to work. Compiled languages (e.g. C, esp. Ada) tend to require much redundant information in your program in order to check that you have properly formulated your program; whenever you make a change to your program, you have to change all this extra material to reflect your changes. Furthermore, after a few iterations of the solution-approximation process, the once-modular structure of your program no longer reflects the structure of the solution you are now using, but still get in the way of making further changes. That's why late-binding, very flexible languages like LISP and Smalltalk are good for this kind of work; the reason they are "interpretive" is that this flexibility can't be built in to a compiler. On a slightly different tack, I think that it would be well-nigh impossible to build an integrated program environment of the sophistication of Smalltalk in a compile-oriented language like Ada. Being able to smoothly meld in new features that act like the current ones (e.g. new types of windows) and also being able to incrementally modify the tools you are using depends upon the malleability of a language very heavily. Computopia now! --ravi