philm@astroatc.UUCP (Phil Mason) (06/13/86)
As Chuck Moore (the inventor of FORTH) says :
"You may have noticed that FORTH is a polarizing concept. It is
just like religion and politics, there are people who love it
and people who hate it and if you want to start an argument,
just say, "Boy, FORTH is a great language."
Well, I take a more positive view where FORTH is concerned.
FORTH represents a different kind of computing environment. It is its own
operating system, compiler, assembler, generic user-interface, development
system - you name it. FORTH can be thought of as a set of software tools, a
development system, a high-level language, a low-level language, or even an
application specific language. It depends on the viewpoint of the actual
user/programmer and the specific application whether or not FORTH fits into
any category at all. FORTH is easily extensible in a way that few other
computer languages are. You customize it for the application at hand.
FORTH was designed at a time that memories and mass-storage devices were
small. FORTH was created to match several criteria :
* small size : theaded-code is about a small as you can get.
* simplicity : FORTH's structure IS simple when it really comes down to it.
* versatility : if you need to customize, no problem. Need speed? Embed
assembly code among your actual FORTH source using a built-in
assembler.
FORTH really wasn't designed to make intelligent use of large memories,
handle large applications, manage large mass-storage devices; but, FORTH
CAN be customized, if desired, to tackle these enviroments. The only reason
I would bother to extend FORTH for big machines would be for portability of
applications from/to ANY micro-, mini- or super-computer. I have witnessed
the same EXACT source code run on a big computer, a workstation and a
microcomputer. Then again, you can do this with other languages as well,
if you are careful. You generally can't do it with operating systems due
either to the nature or size of them or copyright/proprietary/license hang-ups.
There are three main dialects of the language : FIG, 79-Standard,
and 83-Standard. Because FORTH is easily customized, there are literally
THOUSANDS of unique installations of the language around the world. This
can cause problems with portability unless code was based on one of the
major dialects. FORTH is easy to bring up on most computer systems.
A small amount of assembly coding is necessary for the innermost interpreter
and I/O, then the vast majority of FORTH is written in FORTH itself.
Only when you have really tried to learn a language and its methods and
meaning, can you appreciate its strong points and shortcomings. Your first
computer language was probably to hardest for you to learn. FORTH is different
enough in philosophy to present an intellectual challenge to those who want it.
You can write bad, unreadable, undocumented and thoroughly icky code in ANY
language you choose.
If you want to have an small, simple, extensible, self-contained development
environment that will run on almost anything, FORTH is probably for you.
If you want to go the regular route of C or PASCAL with a relatively hard
to customize operating system that you can't run on your micro at home, fine.
I happen to prefer using the enviroment suited for my application. It just so
happens that I see applications for FORTH where others may not.
---
Sorry for you guys in net.arch who are getting tired of HLL-->Assembly
discussions, but I think that FORTH is an interesting topic in the context
of direct treaded-code engines and self-contained environments as well as
a language for describing algorithms.
Flames (obnoxious or not) to /dev/null.
Intelligent criticism accepted.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Kirk : Bones ? Phil Mason, Astronautics Technical Center
Bones : He's dead Jim. {Your Favorite System}!uwvax!astroatc!philm
My opinions are mine and not necessarily those of my employer.
(I would like to think that my employer believes in them too.) :-)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=faustus@ucbcad.BERKELEY.EDU (Wayne A. Christopher) (06/16/86)
Please explain to us how some of the features you mention work. What is "threaded"? How can forth be both a "high level language" and "low level language"? How can it be customized? And most importantly, what does it look like? Can you include a short program in both C and forth so we can compare them? Thanks, Wayne
chad@anasazi.UUCP (Chad R. Larson) (06/16/86)
In article <2199@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: > >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. >...what is the real *advantage* of FORTH? You're right, it probably doesn't belong here, so I've directed followups to net.lang.forth, where it may start a new discussion and/or flame war. The two main advantages of Forth are user extensibility and interactive development. Most of the stuff about threaded dictionaries and all that you hear are there to bring about the two above features. (I'm talking about a true Forth here, not just a compiler that can handle Forth syntax. A true Forth is an environment for the programmer, not only a set of tools.) The interactive environment is one where you can test each new function or primitive (called "words") right from your keyboard as you enter it. There is not (at least in the usual sense) an edit-compile- link-load-debug cycle. You figure out a function you need, type it in and test it. If it works as you wish, it is now available to be used in any new words _right_now! You can test any portion of your program from the highest level definition to the lowest primitive at any time to satisfy yourself on their working. Not under a debugger... just as you are working along. You don't have to wait several minutes for MAKE to do its thing in order to test a one word change. The user extensibility is the real productivity aid, and the thing that gives Forth its "Forthness". Programming in Forth is actually developing a new language, specifically tailored to your application. You start with the set of primitive words all Forth's come with and string them together to define new words that do some function you need done. Those new words are used to define higher function words until you eventually have a rich vocabulary of functions keyed exactly to what you are trying to do. When your program is done, and the user inevitably requests "just one more thing", you can frequently add it in a couple of minutes by creating another word made up of six or eight words you already have, since those words are so well fitted to what you are up to. Programs only grow by a dozen or so bytes when you do this. Sometimes Forth fans tend to take on religious fervor. This sometimes is off-putting to interested people, but in many ways Forth is a religion (or at least a state of mind). When you put your Forth hat on, you tend to look at programming problems in a different light. If I haven't bored you yet, some good books are "Starting Forth" and "Thinking Forth" by Leo Brodie. The first deals with the language and an implementation of it, the second with how good Forth programmers tend to approach problems. Disclaimer: Others undoubtably have their own Favorite Forth Features. Remember the religious aspects. : ?DISAGREE IF FLAME ELSE :-) THEN ; -- "I read the news today...oh, boy!" -John Lennon _____________________________________________________________________ UUCP: {mot}!anasazi!chad Voice: Hey, Chad! Ma Bell: (602) 870-3330 ICBM: N33deg,33min Surface: International Anasazi, Inc. W112deg,03min 7500 North Dreamy Draw Drive Suit 120 Phoenix, AZ 85020
rb@ccird1.UUCP (Rex Ballard) (06/20/86)
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.
philm@astroatc.UUCP (Phil Mason) (07/01/86)
Follow-ups to net.lang.forth. Subscribe now, if interested. In article <3700005@uiucdcsp> johnson@uiucdcsp.CS.UIUC.EDU writes: > >The main reason that Forth is popular is its programming environment. >Interactive programming environments that support an incremental >development of an application is the best way for one or two people. >If they have not built such an application before then they can quickly >fix bad design decisions and are essentially using the language as a >rapic prototyping tool. If they have, then they can reuse most of the >code from the earlier application. Forth is great for reusable software tool writing. With Forth, it is possible to give each sofware engineer much more of the entire application to work on since the development time is much shorter. There is a very good principle to follow when trying to get an efficient implementation : write two versions, throw the first one away. With Forth it is quite easy to implement an application one way, decide how it should be, and then do it over. You will still beat the more traditional design philosophy hands-down. Most other languages and operating systems don't give you the time and energy to make multiple implementations of an application before your deadline. >Forth has other advantages, as has been mentioned, principally its >efficiency, ability to run on small machines, and ability to do low-level >I/O. However, I think that its primary advantage is its programming >environment. Of course, Lisp programming environments have provided >these features for nearly two decades, but have only become generally >available fairly recently. Scheme compilers have the potential to produce >extremely efficient code, and Lisp-machine Lisp is used to write the >entire operating system. As memory becomes cheaper, there will be no >good reason not to use these other languages instead of Forth, and the >many, many disadvantages of Forth will kill it. I really enjoy LISP. There's nothing wrong with it; but, I'd never want to write real-time software in it and I'd never want to port the langauge to another computer. I've never seen a standard implementation of LISP that deals with the low-level environment of the machine it runs on. With Forth, you can reach the low-level, high-performance end of the machine and still have a self-contained environment that is stand-alone. No operating system needed, no monitor ROM - Forth is ROMmable and self-contained. On the other hand, Forth can be made to run under any operating system, if desired. Think Big, Build Small, Port Everywhere - - - Control the World with Forth. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kirk : Bones ? | Phil Mason, Astronautics Technical Center Bones : He's dead Jim. | Madison, Wisconsin - "Eat Cheese or Die!" - - - - - - - - - - - - - - - -| ...seismo-uwvax-astroatc!philm | I would really like to believe that my ...ihnp4-nicmad/ | employer shares all my opinions, but . . . =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=