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.) :-)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=magik@chinet.UUCP (Ben Liberman) (06/14/86)
The following was recently posted to net.arch It seems that someone here could probably give him a better reply than the stuff that is showing up in net.arch Ben Liberman ihnp4!chinet!magik or ihnp4!homebru!magik --------------------------------------------------------------------------- From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.arch Subject: What's so good about FORTH? Message-ID: <2199@peora.UUCP> Date: 12 Jun 86 12:49:12 GMT References: <201@pyuxv.UUCP> <3700003@uiucdcsp> <132@vaxb.calgary.UUCP> <1193@terak.UUCP> <455@cad.BERKELEY.EDU> <333@anasazi.UUCP> Organization: Concurrent Computer Corporation, Orlando, Fl Lines: 34 Keywords: FORTH > 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? In my (obviously personal) opinion, Forth seems to be a language best suited to very small machines, e.g., programmable calculators, where it indeed does give benefits over things like BASIC, but that if you have a machine sufficiently large (in terms of fast primary and secondary storage to support a compiler) and with a reasonable architecture to support a HLL, without an excessive "semantic gap" between the HLL and the machine, then one of the more conventional HLLs seems more expressive and "powerful". I have wondered whether there might be some demographic property of FORTH enthusiasts that's not immediately apparent -- e.g., maybe they run machines without any random-access mass storage device, or with very small memory; or maybe they are used to programming in BASIC and an assembler language, and then discover FORTH -- but since these attributes *aren't* things apparent, it's hard to know. Thus my question... what is the real *advantage* of FORTH? If you answer, please avoid terms like "incremental compilation" and "threaded" unless you actually explain an implementation to show why these concepts are really beneficial, and what architectural properties of a machine they would fit well with. -- E. Roskos "Winds allow other skylines to hold you."
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
gregl@tekgen.UUCP (Greg Lacefield) (06/16/86)
In article <369@chinet.UUCP> magik@chinet.UUCP (Ben Liberman) writes: >From: jer@peora.UUCP (J. Eric Roskos) > >I have wondered whether there might be some demographic property of >FORTH enthusiasts that's not immediately apparent -- e.g., maybe they >run machines without any random-access mass storage device, or with >very small memory; or maybe they are used to programming in BASIC and >an assembler language, and then discover FORTH -- but since these >attributes *aren't* things apparent, it's hard to know. Is this supposed to be a knock on Forth programmers (BTW, "Forth" is _not_ an acronym, unlike COBOL or BASIC, so should not be spelled with all caps)? I am not "used to programming" in BASIC and assembler (although I have used both quite a few times in the past); in fact, before I started programming in Forth, I primarily used Pascal and C. For the last two years I have been a Forth programmer and love it. >Thus my question... what is the real *advantage* of FORTH? If you answer, >please avoid terms like "incremental compilation" and "threaded" unless >you actually explain an implementation to show why these concepts are >really beneficial, and what architectural properties of a machine they would >fit well with. As I said earlier, I _do_ love Forth. And it can be highly advantageous in certain situations. I was exposed to it through the need to develop a prototype system for a project at work. We looked at quite a few products in trying to choose a language for the prototype (to be implemented on an IBM PC). Cs, Pascals, Prologs (the system was to involve some AI techniques), and Forths. We chose Forth for several reasons: o "Incremental compilation". There. I said it. Just one situation under which this is beneficial (since you asked) -- prototyping. Developing a prototype requires a development environment in which ideas can be represented, implemented, and extended quickly. The environment also needs to be flexible enough to tailor it to one's own needs. Forth offers ALL of the above, and no other language can come CLOSE to Forth for doing this. o Compactness. We ended up using Forth for the full-scale system, and the source code turned out to be a little over 1 1/2 meg (which, BTW, we believe is one of the larger if not the largest Forth program ever designed), written virtually entirely in high-level Forth (excluding a small amount of the nucleus and just TWO other code words: one to turn the vertical retrace on, one to turn it off). This whole thing compiled down to 113K and runs in 128K (could be 64K if we trimmed down the amount allocated for the stack segment). And it's VERY fast. We calculated that the C code required to produce the same system would have been 3-4 TIMES the size, would have compiled down to perhaps TWICE the size, and run in nowhere NEAR the space. So you can see (can you? :-) that Forth can be a full-scale development language/environment as well. I'm not going to go into "threaded" and machine architectures. I'm a software guru, not a hardware one, so I'll leave that up to those with more qualifica- tions in those areas. (Tom Almy, care to comment? :-) I will say in closing that my beliefs as an engineer involve fitting a language to a given problem, not the other way around, so I am not one of those people who does absolutely EVERYTHING in one language, be it Forth, C, or otherwise. The reasons listed above are, I feel, some of Forth's primary attractions. And I will continue to use it when I feel the situation is appropriate (which is quite often :-) ------------------------------------------------------------------------------- Greg (can you say LAYOFF?? There, I knew you could :-) Lacefield ...!tektronix!tekgen!gregl ^^^^^^^^^ maybe not for long :-<
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
ulf-d@obelix.UUCP (Ulf Dahle'n) (06/17/86)
In article <432@astroatc.UUCP> philm@astroatc.UUCP (Phil Mason) writes: > >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. > Does FORTH really have a future now when most micros have 512K or more (in a few years memory for micros will probably be measured in Megabytes instead), and could easily run more flexible languages such as LISP. I would say FORTH is for those who want LISP but run out of memory... Well, what do you say about that? ------------------------------------------------------------------------- Ulf Dahle'n Dept of Computer Science, University of Linkoping, Sweden email: ... enea!liuida!obelix!ulf-d or ulf-d@obelix.UUCP mail: Bjornkarrsgatan 15A:22, S-58248 LINKOPING, SWEDEN phone: 46 13 176291 or 46 13 171903 or 46 431 72604 "The beginning is a very delicate time. Know then that it is the year 10191... In this time the most precious substance in the universe is the spice Melange. The Spice extends life. The Spice expands consciousness. The Spice is vital to space travel... Oh yes, I forgot to tell you: the Spice exists on only one planet in the entire universe... The planet is Arrakis, also known as Dune." -------------------------------------------------------------------------
toma@tekgvs.UUCP (Thomas Almy) (06/17/86)
In article <173@tekgen.UUCP> gregl@tekgen.UUCP (Greg Lacefield) writes: >In article <369@chinet.UUCP> magik@chinet.UUCP (Ben Liberman) writes: >>From: jer@peora.UUCP (J. Eric Roskos) >> >>I have wondered whether there might be some demographic property of >>FORTH enthusiasts that's not immediately apparent -- e.g., maybe they >>run machines without any random-access mass storage device, or with >>very small memory; or maybe they are used to programming in BASIC and >>an assembler language, and then discover FORTH -- but since these >>attributes *aren't* things apparent, it's hard to know. > Currently I run Forth on an IBM PC AT with a hard disk. In the past I used a 68000 based workstation and a VAX. Prior programming experience include (in chronological order) Fortran, IBM 360 Assembler, BCPL (predecessor to C), LISP, PDP 11 Assembler, BASIC, Pascal, C, STOIC (related to Forth), Forth, Logo, and Smalltalk. Most of my programming is in Forth. > >>Thus my question... what is the real *advantage* of FORTH? If you answer, >>please avoid terms like "incremental compilation" and "threaded" unless >>you actually explain an implementation to show why these concepts are >>really beneficial, and what architectural properties of a machine they would >>fit well with. > >I'm not going to go into "threaded" and machine architectures. I'm a software >guru, not a hardware one, so I'll leave that up to those with more qualifica- >tions in those areas. (Tom Almy, care to comment? :-) > Basically, threaded code refers to a technique where the function definitions consist of pointers to other definitions rather than machine code itself. This allows fast compilation, compact code, but some performance loss. This technique was used by PDP-11 Fortran, and by most (if not all) interactive languages such as LISP and Smalltalk, also UCSD Pascal. Tom Almy
philm@astroatc.UUCP (Phil Mason) (06/17/86)
In article <139@obelix.UUCP> ulf-d@obelix.UUCP (Ulf Dahle'n) writes: >In article <432@astroatc.UUCP> philm@astroatc.UUCP (Phil Mason) writes: >> >>FORTH represents a different kind of computing environment. . . . >Does FORTH really have a future now when most micros have 512K or more >(in a few years memory for micros will probably be measured in Megabytes >instead), and could easily run more flexible languages such as LISP. >I would say FORTH is for those who want LISP but run out of memory... >Well, what do you say about that? There will always be those nitty-gritty situations where size and versatility are the main issues. I can't see having a real-time situation wait for a LISP garbage collection, do you? No matter how big the "micros" become, there will always be the small machines, whether it be from a cost standpoint or due to necessary development time. There is always a need for distributed control, embedded control, self-contained diagnostic tools and small computer development systems. FORTH reduces the design cycle to the point where complex, compact applications are quite easy to build - for a single software engineer. FORTH is one of the last, true, seat-of-the-pants languages where a single software engineer can build something quite large, quickly and unaided. LISP is one of the other languages that this is true of as well; however, LISP is not as simple as FORTH internally and performance is definitely an issue. I would think it would be difficult to embed assembly language code amongst LISP object code. Garbage collection and memory management are major complexities and are absolutely "too much" for a real-time environment. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 . . . =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
greg@utcsri.UUCP (Gregory Smith) (06/18/86)
In article <5654@alice.uUCp> ark@alice.UucP (Andrew Koenig) writes: >> FORTH appears to be the only major language that uses threaded code as the >> primary means of expressing algorithms internally. Other languages and >> applications do use threaded code but by no means even close to the extent >> that FORTH does. Threaded code is used for compactness and simplicity. > >Have a look at the Spitbol compilers sometime. Some DEC pdp-11 FORTRAN compilers do this too, usually as an option. For those interested, I will try to show the mechanics of this: Suppose the program is I=1 K=350 J=J+1 A=B CALL FOO The compiled output would be: .WORD MOI$1M,I ; move-int-1-to-mem .WORD MOI$IM,350,K ; move-int-immediate-to-mem .WORD ADI$1M,J ; add-int-1 to mem .WORD MOF$MM,A,B ; move-float-mem-to-mem .WORD CAL$,FOO ; call foo. There were a *lot* of operations defined, as you can imagine. This is executed with R4 pointing to the above list of words. The routines used are as follows ( more or less) MOI$1M: MOV #1,@(R4)+ JMP @(R4)+ MOI$IM: MOV (R4)+,@(R4)+ JMP @(R4)+ ADI$1M: INC @(R4)+ JMP @(R4)+ MOF$MM: MOV (R4)+,R0 ; get source MOV (R4)+,R1 ; dest MOV (R0)+,(R1)+ ; move one word MOV (R0),(R1) ; move the other JMP @(R4)+ CAL$: MOV (R4)+,R0 ; get subr. address MOV R4,-(SP) ; save threaded PC JSR PC,(R0) ; call it MOV (SP)+,R4 ; get R4 back JMP @(R4)+ Thanks to JMP @(R4)+ the threading overhead is minimal. However, for integer operations, this overhead is almost half of the instructions executed. The win comes with floating point stuff, especially double prec. and complex. The complex multiply A=B*C can be done by .WORD MOC$MS,B ; mov-cplx mem to stack .WORD MUC$MS,C ; mul-cplx mem to stack .WORD MOC$SM,A ; mov-cplx stack to mem. Of course, the advantage is only in code size. ( the definitions of MOC$MS, MUC$MS and MOC$SM are left as an exercise for the reader :-) ) Another interesting point is that JMP @(R4)+ does not modify condition codes, so comparison routines like CMI$MI ( CMP @(R4)+,(R4)+/ JMP @(R4)+) can set condition codes, to be used by a conditional threaded branch ( which does either MOV (R4),R4 if the branch is taken or TST (R4)+ if not). This would not be possible on, say, an 8080, where the code to go to the next handler would be fairly long and would trash the c. codes. Sorry for those of you who don't read PDP-11. A 68K can't do anything like JMP @(R4)+. It would have to do something like this at the end of each handler: MOVA.L (A6)+,A0 ; get next in A0 JMP (A0) ; go do it. Condition codes are still unaffected, but the threading overhead is now that much bigger. All of this is from memory, so I may have spelled a few of the threaded names wrong. This method can obviously be used by any language, and is especially attractive on horrible CPUs like the 6502 where in-line code is impractical (no 16-bit regs, except PC :-( ) -- "Shades of scorpions! Daedalus has vanished ..... Great Zeus, my ring!" ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
jad@lanl.UUCP (06/19/86)
Once upon a time I was using a machine with limited resources - it did, however, have a floppy drive and 6k of ROM space. Into that space, using a variant of FORTH I was able to put a programming environment and a disk-based text editor. Not much, perhaps, but enough to get the Christmas letters out on time one year, with variations to each recipient. This justified (for that year, at least) the expenditures that went into that system. What impresses me more are the FORTH-based (or FORTH-like) systems that implement things undreamed-of only a few years ago, things that you can hold in your hand and run from batteries . . .
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 . . . =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
rb@cci632.UUCP (07/12/86)
In article <468@astroatc.UUCP> philm@astroatc.UUCP (Phil Mason) writes: >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. This is very significant. Forth gives a great deal of power to a small number of people. One of the reasons you don't see lot's of discussion about forth generally, is because so few people are NEEDED to build a system with the same level of complexity. >Forth is great for reusable software tool writing. This can also be a disadvantage in some ways. Without careful management and good communications, it is very easy to have literally hundreds of almost identical wheels, all re-invented by different people. >>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. THIS is the BIGGEST advantage of Forth. Just as a great artist can take the primary colors plus white, and produce pictures that may have a thousand different colors, so the Forth programmer can take a very small number of primitives, and produce software two to three orders of magnitude more complex. >>Of course, Lisp programming environments have provided >>these features for nearly two decades, but have only become generally >>available fairly recently. >>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. For ANY given amount of memory and speed, it will always be possible to pack more functionality in Forth than in a "sophisticated" language. The secret here is coding STYLE, rather than the language itself. The first Forth implementation I worked with had 26 primatives in machine language. Everthing else was Forth. How much can you do with 26 letters and a little punctuation? >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. If Forth programmers could find a good way to package their byproducts into something that organized the BULK of GOOD DOCUMENTATION, and good routines, Forth might be more accepted for general use. I've seen "image mode" documentation for some BASIC IMPLEMENTATIONS that make the UNIX manuals look like well organized "quick reference guides". Many such documents have come out organized by SCREEN. Alphabetical order helps when you are trying do decode someone elses code, but "packages" are needed for using tools and routines not built "in house" (by the original programmer). Unfortunately, Forth is SO easy and SO flexible, that efforts such as "object oriented design" techniques longer than the "code/test/integrate" phase. >Think Big, Build Small, Port Everywhere - - - > > Control the World with Forth. Just make sure that someone else knows what you're controlling :-).