wei@princeton.UUCP (P Wei) (12/30/85)
I compared the Eratosthenes sieve benchmark for Lattice C, Microsoft C, TURBO Pascal and HS/Forth for IBMPC. For 10 iterations, the execution looks like : Microsoft C : 13.2 sec (from pc-tech Jan 1986, p91) 8.1 sec (using register) Lattice C : 10.5 sec (from the same place as above) TURBO Pascal: 14.1 sec (from an ad for ZBASIC) HS/Forth : 47.0 sec in interpreter (data from ad) 7.0 sec using code optimizer and improved program Assembler : 5.0 sec Now, the question is : It seems that Forth is as extensible and structured as C and Pascal (to my understanding), and generates more compact and faster execution program. Its interpreter being far more faster than BASIC's makes developement time of a project much less than when using 'edit-compile-link-test' type of language. I wonder why Forth is still less popular (to my impression) than C and Pascal. Is it because : --its somewhat 'awkward' syntax ? (Pascal is closer to human language) --its lack of predefined data structure ? --its putting great responsibilty on the programmer ? (the kernel is so compact and simple that you must first extend the system and create many things which in C and Pascal are taken care of by the compiler-writer.) In this sense, if I compare the simplicity and primitiveness I get: Assembly > Forth > C > Pascal (where > means simpler than). We know power comes from simplicity, however we must pay price for it. For C-lovers, do you think UNIX-like (or operating system in the general sense) can be written in FORTH and possibly has better performance? For Pascal-lovers, is the 'visually' readability and strongly type the primary advantage ? and a must ? For Forth-lovers, do you think Forth is suitable for being used as a general purpose language instead of the one 'exclusively' designed for use in the lab and industry to control the machine... Note: I am not a dedicated C, Pascal or Forth programmer. HP Wei (wei@princeton)
jc@sdcsvax.UUCP (John Cornelius) (12/30/85)
In answer to the question can one "write an operating system in Forth?" You can write anything in anything; Prime proved this by writing an operating system almost entirely in Fortran. Why I even remember when we wrote operating systems in Machine Language (no, not Assembly language, Machine Language). The major comments that I have heard regarding Forth are that it is very fast and compact but it is more cryptic than C (and maybe even Assembler) and that it requires the programmer to do too much of the compilation himself at coding time. The first criticism is probably valid in that I've seen a number of Forth programmers stare at their code for long periods and then just rewrite the whole program/subroutine because they cannot remember what they did. The second criticism is equally valid in any language where portability is not an issue. Languages are a matter of taste and zealots for most of the currently popular languages are indistinguishable from one another. One must simply consider what problem one is trying to solve is and proceed from there for a particular application. Since efficiency of the language is largely a function of the skill of the compiler writer(s) the choice of compilers is probably more important than the choice of language. John Cornelius Western Scientific ....!sdcsvax!westsci!jc
desj@brahms.BERKELEY.EDU (David desJardins) (12/31/85)
In article <1191@princeton.UUCP> wei@princeton.UUCP (P Wei) writes: >I compared the Eratosthenes sieve benchmark for Lattice C, Microsoft C, >TURBO Pascal and HS/Forth for IBMPC. For 10 iterations, the execution looks >like : >Microsoft C : 13.2 sec (from pc-tech Jan 1986, p91) > 8.1 sec (using register) >Lattice C : 10.5 sec (from the same place as above) >TURBO Pascal: 14.1 sec (from an ad for ZBASIC) >HS/Forth : 47.0 sec in interpreter (data from ad) > 7.0 sec using code optimizer and improved program >Assembler : 5.0 sec Note that TURBO Pascal is a "quick and dirty" compiler which does no real optimization. Also, range checking and other slowdowns were probably left on; this invalidates the comparison with versions of C which (I believe) do not include these as defaults. Further, the point of benchmarks is _not_ to improve the program, nor to optimize the code... The meaning of these numbers is certainly open to question. Let us assume that Forth can indeed produce somewhat faster results than C or Pascal. >Now, the question is : >It seems that Forth is as extensible and structured as C and Pascal (to my >understanding), and generates more compact and faster execution program. A structured language is one which imposes structure on the programmer; i.e. forces programs into a pattern. Forth is the antithesis of structure. I like Forth, but in the same way that I like assembly language--it is fast and efficient. It might even be a reasonable alternative to C for some purposes, since in either language the programmer is largely responsible for the integrity of his data structures. (I don't like C much, I'm afraid...) Forth is also _not_ as extensible as Pascal, in that Pascal maintains the integrity of user extensions, whereas Forth leaves the programmer with this responsibility. >Its interpreter being far more faster than BASIC's makes developement time of a >project much less than when using 'edit-compile-link-test' type of language. This is not really true on large projects (large enough to be broken into separate modules). The extent to which it is true is also dependent on programming style. >I wonder why Forth is still less popular (to my impression) than C and Pascal. >Is it because [of]: >--its somewhat 'awkward' syntax ? (Pascal is closer to human language) I like Forth syntax a lot; certainly I would not choose one language over another for its syntax in any case. >--its lack of predefined data structure ? I think this is the main point. Modern programming does involve complicated data abstractions, and while I can believe that structures to represent these can be constructed in Forth, all of the burden of both the construction and the segregation of types falls on the programmer. Maintaining the distinction between data types is half of the purpose of a programming language (especially if you consider the program itself as a data type!). >--its putting great responsibilty on the programmer ? (the kernel is so compact > and simple that you must first extend the system and create many things which > in C and Pascal are taken care of by the compiler-writer.) In this sense, > if I compare the simplicity and primitiveness I get: > Assembly > Forth > C > Pascal (where > means simpler than). > We know power comes from simplicity, however we must pay price for it. I strongly disagree that power comes from simplicity. Power comes from having complex tools in place to support the tasks you wish done, rather than having to do everything by hand. For driving nails a fist is simple; a hammer is powerful. >For C-lovers, do you think UNIX-like (or operating system in the general sense) >can be written in FORTH and possibly has better performance? This seems quite possible. Unfortunately, the tools needed for this do not yet exist (compiler compilers, code generators, etc.). If the same effort is put into developing Forth that was put into C, I believe it is quite possible. With hardware Forth machines, the result could be impressive. But work on the system would still largely be done in high-level languages and perhaps compiled into Forth. (Disclaimer: I perhaps am not qualified to comment on this, as I am not a C-lover.) >For Pascal-lovers, is the 'visually' readability and strongly type the primary >advantage ? and a must ? As I said before, syntax is irrelevant... Strong typing, on the other hand, is invaluable. I don't suppose I'm going to persuade anyone who doesn't already agree, so I'll just say that I see the weak (lack of?) typing in Forth as perhaps its biggest problem, especially as I see no easy solution without substantial changes in the language. >For Forth-lovers, do you think Forth is suitable for being used as a >general purpose language instead of the one 'exclusively' designed >for use in the lab and industry to control the machine... >HP Wei (wei@princeton) As I said, I think it is quite possible Forth or Forth-like languages have a place as system programming languages, provided the proper development tools are created. I don't believe they have a place as general-purpose languages though; I think if anything high-level languages are moving in the opposite direction (Ada...). But then I don't know what people see in C... -- David desJardins (desj@brahms.UUCP)
duane@anasazi.UUCP (Duane Morse) (12/31/85)
> I wonder why Forth is still less popular (to my impression) than C and Pascal. > > Is it because : > --its somewhat 'awkward' syntax ? (Pascal is closer to human language) > --its lack of predefined data structure ? > --its putting great responsibilty on the programmer? (the kernel is so compact > and simple that you must first extend the system and create many things which > in C and Pascal are taken care of by the compiler-writer.) > Note: I am not a dedicated C, Pascal or Forth programmer. > HP Wei (wei@princeton) A few years ago, Forth was popular at the company where I work. The programmers who wrote Forth programs (myself included) liked the language, but the company eventually stopped selling Forth-based systems for two basic reasons: (1) it was next to impossible to find Forth programmers, so the company would have to spend considerable time training programmers in the language (and the company really didn't want to spend the time to do this); (2) when we did half-heartedly try to train people, we found that we had more trouble teaching Forth than any other language -- we plain had to give up on some people! Further, customers didn't have Forth programmers on staff, so they had even greater trouble taking over our software (we sold the source and they maintained and enhanced their systems). Recently our company has jumped on the Unix/C bandwagon, and "portability" is the current watchword. Though I believe that Forth isn't as portable as C can be, it's interesting to note that we dropped Forth long before anyone here started programming in C, and no one cared about portability at the time. -- Duane Morse ...!noao!terak|anasazi!duane or ...!noao!mot!anasazi!duane (602) 870-3330
rsk@pucc-j (Wombat) (12/31/85)
In article <1191@princeton.UUCP> wei@princeton.UUCP (P Wei) writes: >I compared the Eratosthenes sieve benchmark for Lattice C, Microsoft C, >TURBO Pascal and HS/Forth for IBMPC... Benchmarks are not an effective way of judging a language--they serve only to evaluate a particular *implementation* of a language on a particular machine. Additionally, use of runtime benchmarks tends to promulgate the obsolete notion that "running speed is everything"; in most cases, "programmer time" is everything. Now, on to Forth vs. other languages. What follows is a paraphrasing of an artticle I wrote a while back... There are severe problems with Forth that prevent it from being much more than an interesting (failed) exercise in threaded-interpretative language design. It is (1) compact, (2) modifiable at runtime, (3) extensible and (4) hard to read. Some of these are also features/flaws of other languages, depending on your viewpoint. However, I'd like to point out the following: 1. Forth is a lot harder to read than even Lisp or APL; at my former employer, where we used Forth in real-time control and number-crunching applications, we called it a "write-only" language. 2. There are many incompatible implementations of Forth, and even implementations from the same vendor behave radically different on different processors. 3. The debugging support is non-existent. 4. The primitive set of operators is *very* large; and it is not orthogonally constructed; the names are not even *close* to mnemonic; and many operators have uncontrollable side effects outside the modules in which they are used. 5. Forth is not structured, typed, or anything like that. When using Forth, you may forget anything you learned from Software Tools, or Elements of Programming Style, or Niklaus Wirth, or, roughly speaking, the last 15 years of evolution in programming techniques. And now, I'd like to quote another article that appeared at the time: > From: libes@nbs-amrf.UUCP > Newsgroups: net.ai > Subject: Forth for AI? NO! > Date: Sun, 22-Jan-84 19:54:16 EST > > Forth for AI? Don't make me laugh. Here's Forth's really bad points: > > 1) Manipulating programs as data in Forth is difficult. Also > impractical, since it has no garbage collection. You can't expect to > service high-priority interrupts if you've just run out of space! > (Forth's primary use is for real-time control.) > > 2) Can't pass arguments explicitly. You must pass information by > putting it on the stack. Since I pushed the 2nd arg at line 6 and then > used the stack to do something else, what are the odds that at line 23, > I can push the 3rd arg on the stack and then call that function with > confidence? Reading code, trying to find out what the arguments are, is > like counting parens in Lisp, except now imagine that every atom in the > list manipulates the count of ('s and )'s! > > 3) Forward referencing (including recursion) is not normal and must be > done by manipulating compiled code. Bye-bye portability. Indeed, I have > never seen anyone write a recursive Forth routine (although it can be > done). Bye-bye AI. > > 4) Code is generated as you type (or load) in Forth source. Hence you > lose all possible benefits of a good compiler, i.e. type-checking, > optimization, etc. As for syntax checking, forget it. The syntax of > the language is so simple, almost every combination of Forth words is > syntactly correct (although meaningless). If you mistyped that last > word, you'll find out at run-time. > > 5) Scoping, name-space rules are terrible. For example, it is impossible to > write a subroutine that uses variables that are *guaranteed* to be local. > (How can you ever be confident about your code?) > > 6) The emphasis on Forth is on speed at the cost of everything else. For > example, if you can keep track of all data by storing it on the stack, > great, but if you have to use a variable (no less a structure) you start > losing efficiency. Using a variable in Forth is akin to using those > features in PL/I that are great but really slow the runtimes down. And > Forth simply isn't fast to begin with. Any decent compiler can do better > (then "threaded-code"). > > 7) The only messages from the system are "ok", "?" (meaning "I don't > know that word") and "stack empty". (It might check stack-full and some > others, but these are the only msgs I've ever gotten.) This is very > consistent with the Forth philosophy (see 6.) but really unhelpful. > Debugging note: If Forth encounters a word it doesn't know, the stack is > popped. Since the only other error is when the stack is empty, it is > impossible to tell where you died by looking at the stack! > > 8) I hesitate to criticize any language for being unreadable, since I > really like APL, which is also unreadable but in a different sense. > Forth is like Lisp but without parens. Its very hard to figure out what > the functions, args and bindings are without reading the entire > subroutine from the beginning and knowing type info about every word. > And even if you do, glancing at a random line that is manipulating the > stack doesn't tell you at all what is on the stack. To know this, you > also have to understand the function of every word. > > I could go on, but I think you get the idea by now. (No, not that I > hate Forth!) Forth has its good points, but none of them make it a > practical language; most of them are for intellectual stimulation > only. Given a task and my choice of languages, I would never choose > Forth. You shouldn't either. > > Don Libes In summary (speaking for myself, not Don), I strongly recommend that you avoid Forth. If I were you, I'd resort to using assebly language first; you'll have a better chance of producing debuggable, robust, and maintainable code. -- Rich Kulawiec pur-ee!rsk purdue-!rsk rsk@purdue-asc.arpa rsk@asc.purdue.edu
toma@tekchips.UUCP (Tom Almy) (01/02/86)
In article <1191@princeton.UUCP> wei@princeton.UUCP (P Wei) writes: >I compared the Eratosthenes sieve benchmark for Lattice C, Microsoft C, >TURBO Pascal and HS/Forth for IBMPC. For 10 iterations, the execution looks >like : [ various timings ] > >Now, the question is : >It seems that Forth is as extensible and structured as C and Pascal (to my >understanding), and generates more compact and faster execution program. >Its interpreter being far more faster than BASIC's makes developement time of a >project much less than when using 'edit-compile-link-test' type of language. >I wonder why Forth is still less popular (to my impression) than C and Pascal. Well ignorance (and I mean to offend nobody by this) is a problem. Most programmers don't KNOW Forth, and so cannot judge it. "C" is popular amoung UNIX users, because you just about have to use C under UNIX (I have had no good experiences with it in NON-UNIX systems). PASCAL is taught in schools so it has a guarenteed user community -- its rigidity is favored by academic types. I used it for programs heavily into data structures, but only for those that PASCAL supports. There are millions of potential Microsoft BASIC users, since it is built into almost everyone's personal computer. I use Microsoft BASIC when I want to manipulate strings. On the other hand, FORTH takes effort -- you have to go out of your way to obtain it, and you have to learn it on your own. >Is it because : >--its somewhat 'awkward' syntax ? (Pascal is closer to human language) Pascal closer to human language? GAG! If you want to program in human language use COBOL :-). Actually Forth has simpler syntax rules than any other language I know except for un-adulterated LISP; I can explain the syntax rules of Forth much faster than I could appologise for the semicolon rules in PASCAL! >--its lack of predefined data structure ? This is certainly a disadvantage to learning Forth, but the ability to create any data structure you want and placing them anywhere you please (like an array on a remote system accessed via modem), hiding the access method like in Smalltalk, is very powerful indeed. >--its putting great responsibilty on the programmer ? (the kernel is so compact > and simple that you must first extend the system and create many things which > in C and Pascal are taken care of by the compiler-writer.) In this sense, > if I compare the simplicity and primitiveness I get: > Assembly > Forth > C > Pascal (where > means simpler than). But the extensibility of Forth allows making it "less simple" as applications require. If you MUST have infix expressions, you can have them; if you want bounds checking on arrays, or or traps on arithmetic overflow, you can have that too (and be just as invisible to the programmer as in PASCAL). > We know power comes from simplicity, however we must pay price for it. > [...] >For Forth-lovers, do you think Forth is suitable for being used as a >general purpose language instead of the one 'exclusively' designed >for use in the lab and industry to control the machine... Yes, in fact I have seen accounting packages in Forth, and scientific programs in Forth. In the past year I have been rewriting many of my favorite CP/M and MSDOS utilities (mostly filter like programs) in Forth using the Forth compiler I have written, getting typically 2-4x speedups (4x for AZTEC CP/M programs that used "stdio"), and 75% code size reductions. I have implemented a multi-tasking multi-user Forth in CP/M (three users and a printer spooler on a Z-80!). I also have written an IC layout program in Forth. I have used it in "traditional" Forth environments as well. >Note: I am not a dedicated C, Pascal or Forth programmer. >HP Wei (wei@princeton) At different points in time, I used almost exclusively all of these, as well as Fortran, BCPL, LISP and APL. Now I am using Forth almost exclusively. Tom Almy (Usual disclaimer, but you can flame directly at me if you want. Why wear out /dev/null?).
breuel@h-sc1.UUCP (thomas breuel) (01/03/86)
I am not a great friend of FORTH either, but I do not believe that your criticism is justified. > 1. Forth is a lot harder to read than even Lisp or APL; at my former employer, > where we used Forth in real-time control and number-crunching applications, > we called it a "write-only" language. I would argue that that is a question of programming style and of programmer experience. Looking at hacks like the 4.3BSD kernel or readnews, I can assure you that unreadability and bad style aren't restricted to FORTH. The cpp, for example, lets you do some pretty obscure things, and people are doing them... Also, in your posting, you refer to 'reading from the beginning of a FORTH definition' or to 'not knowing what is on the stack on the 23rd line'. If you mean this, it simply shows that your problems with programming in FORTH probably come from bad programming style. FORTH functions shouldn't be long. If they are longer than, say, two or three lines, or contain nested loops and if's, you are probably doing something wrong. > 2. There are many incompatible implementations of Forth, and even > 3. The debugging support is non-existent. > 4. The primitive set of operators is *very* large; and it is not orthogonally > 5. Forth is not structured, typed, or anything like that. When > > impractical, since it has no garbage collection. You can't expect to > > 2) Can't pass arguments explicitly. You must pass information by > > 3) Forward referencing (including recursion) is not normal and must be > > 4) Code is generated as you type (or load) in Forth source. Hence you > > 5) Scoping, name-space rules are terrible. For example, it is impossible to There are implementations of FORTH which provide excellent debugging facilities and will allow you to track down whatever problems you are having with your stack. Other implementations allow object oriented programming. Still others have named local variables or named parameters. There are native code compilers and optimising native code compilers. There are FORTH interpreters with garbage collectors, with floating point numbers, with extensions for 3D graphics or matrix operations. If you want to, you can define your own abstract operator for defining forward references. FORTH is, by the way, of course structured in any sense of the word (or if it isn't yet, you can make it that way :-). And you can call your operators whatever you like to, if the existing names trouble you. Since this is relatively easy to do in any implementation, you don't even necessarily loose portability. Because there is a bewildering number of FORTH systems, any two randomly chosen ones are likely to be incompatible. Your conclusion that therefore FORTH programs must be unportable is simply fallacious, however. If you pick your implementations carefully (or write them yourself -- it only takes a few days), you can have as much portability as with, say, 'C'. ALTOGETHER, I personally don't like FORTH and prefer a decent LISP or 'C' compiler to it for any purpose. This is purely a matter of taste, however. You have not cited a single reason that makes FORTH (I would say, not even any of the standard FORTH's) unsuitable for any particular purpose. Advice like 'stay away from FORTH and use assembly language instead' is simply unfounded and inadequate. In particular, there isn't much point in posting it to net.lang.forth. Thomas.
tlm@pur-phy.UUCP (Timothy Lee Meisenheimer) (01/06/86)
[greetings line muncher!] I have just started following net.lang.forth and have found it helpful as I am just beginning to discover what forth is about. It appears to me that thtere are sources available for fig-forth on an 8080 and 6502. Hoping to use them as learning tools I was hoping that someone would be kind enough to mail me a copy of these sources? Also concerning a posting by Peter da Silva: Do you have a glossary of all the words that could be posted? I am a little puzzled as well about trying to use the editor on the standard screens (if it is possible at all.) I got your forth up and running on a pdp-11/Venix with no problems at all and have enjoyed being able to play around with it a little. I found out quickly that just having "Starting Forth" will not help a lot as a number of the words have different meanings. Thanks in advance..
toma@tekchips.UUCP (Tom Almy) (01/06/86)
Normally I don't bother to flame back at flames, but this one has some errors that I cannot ignore. In article <681@pucc-j> rsk@pucc-j.UUCP (Wombat) writes: > >There are severe problems with Forth that prevent it from being much more than >an interesting (failed) exercise in threaded-interpretative language design. > >It is (1) compact, (2) modifiable at runtime, (3) extensible and (4) hard to >read. Some of these are also features/flaws of other languages, depending on >your viewpoint. However, I'd like to point out the following: I fail to see how item (1) could be considered a "flaw", Forth is no more modifiable at runtime (2) than most other languages except Pascal, (3) is a subjective judgement. >1. Forth is a lot harder to read than even Lisp or APL; at my former employer, >where we used Forth in real-time control and number-crunching applications, >we called it a "write-only" language. A lot of this has to do with programming style. It is possible to write readable Forth code, see the book "Thinking Forth". And it is also possible to write unreadable programs in any language. >2. There are many incompatible implementations of Forth, and even >implementations from the same vendor behave radically different on >different processors. The vendor in question must be Forth, Inc. They strive to be incompatible between their implementations. This is not the case for products of Laboratory Microsystems, MicroMotion, F83, and even the ancient FIG Forths. >3. The debugging support is non-existent. The public domain F83 has an interactive debugger. A display-oriented debugger is an option for Laboratory Microsystems IBM-PC product. >4. The primitive set of operators is *very* large; and it is not orthogonally >constructed; the names are not even *close* to mnemonic; and many operators >have uncontrollable side effects outside the modules in which they are used. > Unfortunately, true, but most names are mnemonic and quite a few others are understandable after you know the naming conventions. For instance "." in a name always means "print", "?" at the beginning of a name means it does something conditionally, and "?" at the end of the name means it leaves a boolean result. >5. Forth is not structured, typed, or anything like that. When >using Forth, you may forget anything you learned from Software Tools, or >Elements of Programming Style, or Niklaus Wirth, or, roughly speaking, >the last 15 years of evolution in programming techniques. > Well it is structured, at least as far as control structures are concerned. There are no "gotos". Provided control structures are: 1. IF statement, with optional ELSE. Never any ambiguity of association between IF and ELSE like in some other languages. 2. DO LOOP structure. Most implementations have a variation which allows skipping the block if it is to be executed zero times. Loop can count up, count down, or count by a varying amount (positive negative or zero on any particular iteration). A command exists to exit a loop in the middle. 3. Two iterative structures, one with conditional exit at the end, and the other with conditional exit anywhere in the middle. 4. Most implementations have a CASE statement. For those that don't, it can be easily (and in an implementation independent way) be added. Data structures can be added as desired. >And now, I'd like to quote another article that appeared at the time: > >> From: libes@nbs-amrf.UUCP >> Newsgroups: net.ai >> Subject: Forth for AI? NO! >> Date: Sun, 22-Jan-84 19:54:16 EST >> >> 1) Manipulating programs as data in Forth is difficult. Also >> impractical, since it has no garbage collection. You can't expect to >> service high-priority interrupts if you've just run out of space! >> (Forth's primary use is for real-time control.) But this was cited as undesirable in (2). >> 2) Can't pass arguments explicitly. You must pass information by >> putting it on the stack. Since I pushed the 2nd arg at line 6 and then >> used the stack to do something else, what are the odds that at line 23, >> I can push the 3rd arg on the stack and then call that function with >> confidence? Reading code, trying to find out what the arguments are, is >> like counting parens in Lisp, except now imagine that every atom in the >> list manipulates the count of ('s and )'s! You can pass arguments in variables and there are several published techniques to create named parameters (so they can be accessed without stack manipulation). But the biggest flaw here is "line 23". The proper Forth programming technique is to have lots of small functions rather than a few big ones because subroutine calls are cheap. I have a 5000 line Forth application, and there is only one function longer than 15 lines and no more than a dozen longer than ten lines. Forth code can also be DOCUMENTED (anybody know what that word means?) with comments as to stack contents. >> >> 3) Forward referencing (including recursion) is not normal and must be >> done by manipulating compiled code. Bye-bye portability. Indeed, I have >> never seen anyone write a recursive Forth routine (although it can be >> done). Bye-bye AI. True, it is not normal, but it can be done in a portable fashion without manipulating compiled code. I have written many recursive Forth routines, and recursion is *VERY* efficient in Forth. Also Forth metacompilers and compiler do allow for forward referencing at the cost of not being interactive (in other words "batch"). >> 4) Code is generated as you type (or load) in Forth source. Hence you >> lose all possible benefits of a good compiler, i.e. type-checking, >> optimization, etc. As for syntax checking, forget it. The syntax of >> the language is so simple, almost every combination of Forth words is >> syntactly correct (although meaningless). If you mistyped that last >> word, you'll find out at run-time. Control structures are checked for syntatic correctness. Compilers can do optimizations and produce code quality comparable with that of C or Pascal. If you mistype a word you find out right away (assuming that the word is not a valid Forth word). >> 5) Scoping, name-space rules are terrible. For example, it is impossible to >> write a subroutine that uses variables that are *guaranteed* to be local. >> (How can you ever be confident about your code?) You CAN write subroutines that use variables guaranteed to be local (technique requires writing of three one-line routines which localize the scoping of selected words (which may not only be variables but also other subroutines). You can also write code without worrying about redefining existing routines (no reserved words or function names) since your definitions do not alter the operation of the existing functions. Thus if your application were so brash as to redefine the operation of "+", the Forth nucleus would continue to use the original version. >> >> 6) The emphasis on Forth is on speed at the cost of everything else. For >> example, if you can keep track of all data by storing it on the stack, >> great, but if you have to use a variable (no less a structure) you start >> losing efficiency. Using a variable in Forth is akin to using those >> features in PL/I that are great but really slow the runtimes down. And >> Forth simply isn't fast to begin with. Any decent compiler can do better >> (then "threaded-code"). Using variables in Forth is frequently faster than stack manipulation. Forth compilers can handle variables with the same efficiency as other compilers. No Forth programmer will ever claim that threaded-code is faster than true compilation, but it is faster than other interpreted languages such as BASIC LISP and Smalltalk. The use of threaded code allows for very fast and incremental compilation which greatly reduces the edit-compile-test cycle time of program debugging. If the final program is insufficiently fast, then portions of it can be compiled or rewritten in assembly language. >> 7) The only messages from the system are "ok", "?" (meaning "I don't >> know that word") and "stack empty". (It might check stack-full and some >> others, but these are the only msgs I've ever gotten.) This is very >> consistent with the Forth philosophy (see 6.) but really unhelpful. >> Debugging note: If Forth encounters a word it doesn't know, the stack is >> popped. Since the only other error is when the stack is empty, it is >> impossible to tell where you died by looking at the stack! Again, this looks like Forth Inc.'s product which is very user unfriendly! Laboratory Microsystem Forth's manual lists 39 error messages. Forth discovers words it doesn't know at compile time, so you know exactly where the error is. Most systems do not tell you where you are when runtime errors occur. Most systems also provide hooks in the error routines so that you can do anything you want (including examining the stack). There are occasions to choose Forth, as well as occasions to avoid it. I find that I can develop programs far faster in Forth than in C or Pascal. But I do use C or Pascal for programs that make heavy use of data structures (that are directly supported by these languages). For character string manipulation I still prefer BASIC. Tom Almy
bill@ubvax.UUCP (Bill Thomas) (01/07/86)
trying to use the mixed mode with Microsoft C is some fun in that the "/Ze" option using their "far" feature does not work on Automatic variables (they are ignored) so one can't get SEG:OFFSET pointers in Calls. This in turn makes the /Axxxw option next to you know what because in the /AM or /AS (SMALL Data) a call could have a 16 bit (offset) pointer which should be SS:offset or DS:offset and if the called routine has ESP your ok!!!!. In addtion in the Large Data model every Global variable gets its own segment. That is they don't collect them to cut down on loading the ES. So the Large Data model is SLOW SLOW & you can't get around it with their funny "/Ze" "far" stuff!
jgray@pilchuckDataio.UUCP (Jerrold Gray) (01/07/86)
> Now, the question is : > It seems that Forth is as extensible and structured as C and Pascal (to my > understanding), and generates more compact and faster execution program. > Its interpreter being far more faster than BASIC's makes developement time of a > project much less than when using 'edit-compile-link-test' type of language. > I wonder why Forth is still less popular (to my impression) than C and Pascal. > *** REPLACE THIS LINE WITH YOUR FORTH ENVIRONMENT *** It has been my experience that whenever speed has been the critical issue, critical components ( if not all ) of a software package should be written in assembly language. This optimizing for speed is at the expense of development time and the general level of support by other developers. I suspect that the reason Forth is not more popular is that software support in Forth is more difficult than in the other languages you cited. The effort expended in support (debugging or adding features) is product of understanding the native language used as well as the architecture and symbology of the orginal author. The "keyword" here is "cryptic". In assembly language the symbology is fairly fixed so you only have to deal with the native language (op codes) and the program structure. Though in a higher level language, the symbology of Fortran and most flavors of BASIC is also pretty much predefined. The languages in between allow a lot of freedom to make software extremely cryptic, with the effect peaking in Forth. I also suspect some people have raised software cryptography to another artform. As an effective test of which language to use. Get good and drunk on several occasions, and write several pages of code ( to do something harmless of course) whilst under the influence. The result doesn't have to be entirely working when finished. Before sobriety returns, hide your source code somewhere where you won't find it for a few weeks. If and when you find it, try to understand it. Better yet... try to fix it. My recommendation is to stick with C or Pascal linked to assembly coded critical routines where necessary. Jerrold L. Gray uw-beaver!telone!dataio!pilchuck!jgray USNAIL: 10525 Willows Road N.E. /C-46 Redmond, Wa. 98052 (206) 881 - 6444 x478 Telex: 15-2167