Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!ut-sally!seismo!rochester!ritcv!cci632!ccird1!rb From: rb@ccird1.UUCP (Rex Ballard) Newsgroups: net.arch,net.lang Subject: Re: What's so good about FORTH? Message-ID: <502@ccird1.UUCP> Date: Thu, 19-Jun-86 21:29:03 EDT Article-I.D.: ccird1.502 Posted: Thu Jun 19 21:29:03 1986 Date-Received: Sat, 28-Jun-86 07:50:26 EDT References: <201@pyuxv.UUCP> <3700003@uiucdcsp> <132@vaxb.calgary.UUCP> Reply-To: rb@ccird1.UUCP (Rex Ballard) Organization: CCI Rochester Development, Rochester NY Lines: 170 Keywords: FORTH Xref: watmath net.arch:3604 net.lang:2512 Summary: Pro's and Con's In article <2199@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >> When coding in Forth, you do all the coding in the high level language >> (and can interactively test the code). > >I'm not entirely sure what this has to do with net.arch, but aside from >that, this raises an issue that's been puzzling me for several years. >In fact, I've even written a couple of postings in the past on it, then >usually cancelled them because the question was so ambiguous. > >The question is, *why* is Forth described in such glowing terms, when the >attributes that are listed as the reason for such a description are not >particularly unusual? > >Thus my question... what is the real *advantage* of FORTH? Good parts of forth: Interactive - imagine, you don't have to go through a make/compile/assemble phase to test your code. In fact you can experiment with a few variations to find the best answers. It completely eliminates the need to "patch" in machine code. Small - On a machine such as the 8085 or the 6502, a fully servicable Kernal can fit in as little as 2K, including multi-tasking. On a machine with a more powerful instruction set, as little as 1K can be used. For controllers and special purpose boxes, or in a situation where a large kernal is not desired, this is another win for forth. Fast - Compared to hand-written assembler, FORTH is slow, as much as 4 to 10 times slower. However compared to interpreters, and compilers that lack good optimization, it is very fast, often 100 times faster than BASIC. Forth is also quite easy to benchmark, since you are basicly timing about 26 primitives and an "inner interpreter". Maintenence - Most forth applications are subject to frequent change without notice. Not so much bug fixes as things like "yesterday I tracked one star, now I want a different one". Robotics, Laser fusion labs, and a variety of other situations can't wait three weeks between runs while the enhancements are re-checked. Modular - Because the programmer is responsible for the parameter stack large functions are seldom used. The result is that routines are build on other routines, much the way a VLSI circuit can be built up from simpler circuits. You can make a DQ flipflop with just a few gates, use the macro 8 times to make a register, use the register macro a few times to make bus controllers, add a little "glue", and have a CPU on one chip. Forth tends to do the same thing in software. Another advantage is that if you wish to change a time-out value to tune the system, you can change or expand the original definition and the "callers" won't need to be "re-linked". Obviously, an archetecture with fast "calls" can easily capture the same market. Builds/Does -This is the one novices scratch their heads over for days. It is also a very powerful concept. If I want to add subroutine and call it using a macro, I could write the subroutine, then write the macro. Effectively, I would be enhancing the language. Forth has a mechanism to do this for you. This allows you to build operators that define their own storage, and even perform their own operations, just by referencing them. Design Discipline/Creativity - Because forward referencing is very difficult, there are two basic ways to aproach a project in forth. On is to have a truly complete design, in which common modules have already been identified, or you can "create" your way up to an incomplete design. Things like "transform structure A to structure B" have to be done field by field, which often means that similar fields can use the same routines. If the structure is complex enough, it may even be broken down into smaller substructures. As a result, a complex record can be transformed in as little as 100 lines of code, where normally a 2000 line 'C' program might have been tried. This bottom up approach often leads to very tight "macro-level" designs. If the programmer wishes, he can design his way up, identifying common types of data and common operations that could be performed on it. This ultimately leads to an Object Oriented Design, almost by accident. Forth is not an object oriented language, but Object Oriented Design is definitely a valuable skill. Hardware functions can be done in software - Demand paged memory, various types of caching, management of various tasks, and peripheral control can be efficiently done in software. Even tricks like multi-computing (each with their own ram and storage, working on different parts of the problem at the same time), can be almost trivial in forth. This is often done in Robotics where "fingers" and the "arm" are controlled by different processors under the direction of a master processor. Extensibility - Not only can the language be extended, but the Forth "operating system" can be extended as well. Of course other languages, such as Lisp, Smalltalk, and Prolog have many of these features (smalltalk classes are very similar to forth builds/does clauses). They also require powerful machines to run them effectively. The main advantage of forth is it's "elegent simplicity". Many of these other languages almost look like decendants of forth. Forth has disadvantages too: No OBJECT modules - There is no such thing as an object code library. Everything depends on the user's access to the source. Without it, there is little one can do to change the system. It is possible to "decompile" the object, but the source must be reloaded. Object can be saved as a whole unit, but not in loadable pieces. Some Forths are able to do this, but the tradeoffs are efficiency and memory size. No OBJECT level portability - Although the source code to a forth application can be made to run on practically any machine, everything, including the kernal must also be loaded. Any Operating System vectors are unique to the system. Organization - There is almost no organization and little documentation to a standard forth Kernal. You can do a "vlist" and every word it knows about spews out, in the order of definition. Source is organized in terms of "screens", which makes things easy to read, but requires a good associative memory on the part of the programmer. Here Smalltalk or NEON are ultimately better. Information - Since there are no libraries in forth, and most people have little desire to give away source to their favorite utilities, the wheel is often re-invented, or at least hand entered. You can get some utilities via compuserve and various bulletin boards, but the good stuff, like animation graphics are well protected from telephones. Rumor has it that Atari and Activision have some of the best forth libraries. Religion - Forth programmers defend their language like fundamentalist preachers defend the "7 day creation". Infix notation, parameter management, class definitions, object oriented design, hierarchal "definition directories", and "standard entry points" have all been proposed, and rejected. It took 4 years for the '83 standard to accept the existance of DTL's and STL's, which run 8 to 50 times faster than the '79 standard on some machines (not all, but some). Many valuable contributions to general languages are made by people who get "fed up" with the forth camp and create their own languages. NEON is a good example. Archetecture - Any machine which can support the incredible depth of calls generated by forth, could also run other languages almost as quickly. Forth is usually used to hide the archetectural deficencies of the host chip, this is what makes it so popular on 8080's and 6502's, but a "toy language" on 8086's and 68K's. Advantages are better elsewhere - You can get all the advantages of a Forth language in assembler. Just write the primitives as calls. You can even eliminate the "load register" instructions. You sacrifice the interactive nature, but a good symbolic debugger will give you that. Summary: Anyone who is designing system level archetectures, operating systems, or languages, and has not looked at forth, should spend about as long with that "system" as they spent in the learning stages of C and Unix, say a month or two, working in forth on an "El Cheapo" computer like an Atari or a C-64, preferably doing something like "McPaint in Forth" or some similarly trivial task involving graphics. You can almost write your own forth in about three months (part time) just by reading Brodie. FORTH isn't a panacea, it's more of a Pandora's Box, but there are some good principles, concepts, and disciplines that can greatly increase your effectiveness as a software (or hardware) engineer. It is also a veritable Gold Mine of ideas, but to get to the gold, you've gotta move some dirt.