rsk@pucc-j (Wombat) (01/09/86)
In article <444@tekchips.UUCP> toma@tekchips.UUCP (Tom Almy) writes: >Normally I don't bother to flame back at flames, but this one has some >errors that I cannot ignore. Flame?! You must be joking; I didn't even turn the torch on! Oh, well... >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. I did not claim that (1) was a flaw; for that matter, I did not claim that (2), (3), or (4) were flaws either. I claimed that (1) through (4) were properties of the language "Forth" and that they were features or, OR, flaws of other languages. Please read what I wrote, not what you think I wrote. Onwards. (2) is certainly true of Forth, and certainly not true of languages like C or Pascal, unless someone is really determined. However, it appears to be a standard technique in Forth to write modifiable code. It certainly is easy to do--much, much easier than in C or Pascal. I have seen enough examples of such coding (by competent Forth programmers) to convince me that such practices are status quo in the Forth community. Now, then. (3) is most certainly not a subjective judgement; it is the core of the Forth philosophy. If you do not understand this, then you lack a basic understanding of how Forth works. I would be most curious to see an example of a Forth program (of modest size) which did not define any new "words" in order to perform a useful task. >>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. This is certainly true; however, the tendency to write unreadable code is accentuated in Forth because the language itself provides no help whatsoever to aid the programmer in writing clean code. >>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. The vendor in question is *ALL* Forth vendors; the supposed Forth '79 standard would appear to firmly entrenched in quicksand. My experience has been that porting Forth is far worse a nightmare than porting Pascal, C, or Fortran. >>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. I will amend my statement to be "almost 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. > >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. "understandable after you know the naming conventions" is an excuse; it is similar to claiming that the selection of "der", "die" or "das" for the definite article is understandable once one knows the naming conventions of German. Both claims are utter nonsense; knowledge of N Forth operators does not appear to lend significant aid when attempting to decipher the meaning of a newly-encountered operator. [...any more than knowing that doors are feminine and cars are neuter helps predict what German grammar will consider elevators to be...] The problem of operator overlap is even nastier, however; I can't recall ever seeing a language where there are so many ways to do the same thing, each of which has different obscure side effects from the other. >>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. You, my lucky friend, are working with a Forth onto which someone has added some semantic sugar. However, possession of a do-loop, a couple of conditionals, and an iterative structure does not make Forth a structured language. "Date structures can be added as desired", eh? Well, one could argue that they could added to assembly language as well. The point is that Forth does *NOT* have any, and most of us with some programming to do have better ways to occupy ourselves than figuring out how to introduce Forth to concepts like struct{} or union{}, or array[] for that matter. I don't even want to think about what it would take to implement type-checking; I'd rather rewrite tar(1) in Lisp. >>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). Wrong. Also note that manipulate != modify. >>> 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. Oh, bullshit. The point, again, is that Forth, as is, does not have these "published techniques". Such claims are akin to asserting that C has runtime checking because one vendor has an implementation of it. I can't speak for the other correspondent, but I'd prefer to discuss the *language*, not the amalgamation of all available features from all vendors. Let's do some arithmetic. 5000 lines of code; discarding your one very long function and generously assigning a length of 10 to the remaining functions yields a count of 500 functions. 500 FUNCTIONS!! Is *this* the way to write a program?! No thanks. Incidentally, I think the original correspondent's point is valid even if "23" is replaced with "9"; you are once again grasping at straws. "DOCUMENTED...with comments as to stack contents" Hmm, I seem to remember doing a fair amount of that when writing assembler; doesn't sound like much of an improvement to me. >>> 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"). "efficient" is a nice buzzword, but efficiency is not the issue here. The lack of a clean, built-in, and natural way to do recursion in Forth is. >>> 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). The checking of control structures for correctness does not cover all bases; it covers very few of them. There is, as stated, no type-checking either; and mistyping a word that *is* a Forth word is the very problem! >>> 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. Uh-huh. Note that subsequent function definitions would, however, use the new operator "+". Note also that scoping is built in to most languages, so that kludging it in isn't required. >>> 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. Nonsense. Using a variable in Forth results in slow execution, and yields ugly code, since Forth abhors non-stack parameters. The use of threaded code has next-to-zero influence on the edit-compile-test cycle; as most folks familiar with software engineering know, there are a couple of blocks in there marked "think" that represent the largest expenditure of time. Forth does nothing to reduce the time spent there. ---------- To borrow from some anonymous person on the net from a while back, Forth is like falling in a hole, crawling out after a protracted struggle, and then saying "Look at the great thing I've done." I don't think anyone should take this language seriously; it's just too hard to learn, too hard to use, and too antiquated. -- Rich Kulawiec pucc-j!rsk or rsk@asc.purdue.edu
fetrow@entropy.UUCP (David Fetrow) (01/11/86)
At this point the debate seems to be getting nasty. FORTH is certainly
interesting (whether it's "failed" or not) and FIG will GIVE away an
implementation. Whether it's worth using is a matter of taste and application.
If it's useful it's very easy to find out, if it's lousy it's also easy to
find out: try it (on something non-critical).
If nothing else it's an interesting experience, as evidenced by this debate.
--
-"Daphnia Dave" Fetrow
{ ihnp4, fluke, tektronix, uw-june }!uw-beaver!entropy!fetrow :UUCP
entropy!fetrow@uw-june.arpa :ARPAcollinge@uvicctr.UUCP (Doug Collinge) (01/13/86)
In article <703@pucc-j> rsk@pucc-j.UUCP (Wombat) writes: >In article <444@tekchips.UUCP> toma@tekchips.UUCP (Tom Almy) writes: >>Normally I don't bother to flame back at flames, but this one has some >>errors that I cannot ignore. (This issue may cause a net meltdown...) >>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. >>>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. It has to be just as hard to write "readable" C code but no-one calls it a "write-only" language. The difference, perhaps, is that C is written, by and large by university-educated programmers and Forth is not. Let's face it: there are no "readable" languages, only "readable" programs. >>>> 2) Can't pass arguments explicitly. This must be the biggest readability problem - in fact, it is simply horrible. However, when I realized this, I just wrote the code to put named parameters into the language. Try that in your favourite language. Granted, it should be an option in the standard... >>>> 3) Forward referencing (including recursion) is not normal. Bye-bye AI. Recursion is no problem. Mutual recursion IS a problem that can be solved in a portable, albeit horrible, way. Don't do AI in Pascal, C, FORTRAN, or Forth. >>>> 5) Scoping, name-space rules are terrible. Forth programmers don't seem to use vocabularies as extensively as they ought. Using vocabularies we can write nice modules with all the nasty stuff neatly hidden away. >Forth is like falling in a hole. Well, each to his own: Berkeley Unix is the biggest, deepest hole I have ever fallen into and I don't expect to ever make it out. The bottom line is: does it get the job done? I was extremely skeptical about Forth when I started but now I wouldn't use anything else for process control applications like my own, computer-cotnrolled art. -- Doug Collinge School of Music, University of Victoria, PO Box 1700, Victoria, B.C., Canada, V8W 2Y2 decvax!nrl-css!uvicctr!collinge decvax!uw-beaver!uvicctr!collinge ubc-vision!uvicctr!collinge
jim@sivax.UUCP (Jim Boman) (01/13/86)
> > At this point the debate seems to be getting nasty. FORTH is certainly > interesting (whether it's "failed" or not) and FIG will GIVE away an > implementation. Whether it's worth using is a matter of taste and application. > If it's useful it's very easy to find out, if it's lousy it's also easy to > find out: try it (on something non-critical). > If nothing else it's an interesting experience, as evidenced by this debate. Look at it this way....FORTH is one of the top FIVE programming languages (so I've heard). Bauman, sivax
tim@ism780c.UUCP (Tim Smith) (01/15/86)
In article <703@pucc-j> rsk@pucc-j.UUCP (Wombat) writes: > >"efficient" is a nice buzzword, but efficiency is not the issue here. >The lack of a clean, built-in, and natural way to do recursion in Forth is. > I use recursion in Forth. What difference does it make if it is built-in? It is simple to add, and does _exactly_ the same thing that built-in recursion would do. It is clean and natural. Why build something into a language that not everybody wants, and that those who do can easily add? Forth: the Unix V6 of languages. -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
freak@nsc.UUCP (Curt Mayer) (01/15/86)
In article <174@sivax.UUCP> jim@sivax.UUCP (Jim Boman) writes: > > Look at it this way....FORTH is one of the top FIVE programming > languages (so I've heard). > Bauman, sivax let's see... BASIC, FORTRAN, COBOL, RPG... i see that FORTH has great company. not a useful language in the top 5. awwww... go home and control a telescope, will ya? now... Cyber 170 assembler - a real language! curt
farren@well.UUCP (Mike Farren) (01/16/86)
In article <174@sivax.UUCP>, jim@sivax.UUCP (Jim Boman) writes: >> >> At this point the debate seems to be getting nasty. FORTH is certainly >> interesting (whether it's "failed" or not) and FIG will GIVE away an >> implementation. Whether it's worth using is a matter of taste... > > Look at it this way....FORTH is one of the top FIVE programming > languages (so I've heard). > Bauman, sivax Yes, but BASIC is number one. So much for numerical superiority... -- Mike Farren uucp: {your favorite backbone site}!hplabs!well!farren Fido: Sci-Fido, Fidonode 125/84, (415)655-0667
peter@baylor.UUCP (Peter da Silva) (01/17/86)
> Onwards. (2) is certainly true of Forth, and certainly not true of languages > like C or Pascal, unless someone is really determined. However, it appears > to be a standard technique in Forth to write modifiable code. It certainly > is easy to do--much, much easier than in C or Pascal. I have seen enough > examples of such coding (by competent Forth programmers) to convince me > that such practices are status quo in the Forth community. I'm a competant FORTH programmer. I have written a *LOT* of programs in FORTH, including two special-purpose compilers, a screen editor and a display generat- or, and untold numbers of utilities. I have never used self-modifying code. > Now, then. (3) is most certainly not a subjective judgement; it is the core > of the Forth philosophy. If you do not understand this, then you lack a > basic understanding of how Forth works. I would be most curious to see > an example of a Forth program (of modest size) which did not define any > new "words" in order to perform a useful task. I would be happy to post such a program to the net (by new words I assume you mean new control- and data- structures, not just subroutines), but I am not at liberty to do so (trade secrets, copyrights, and other unfunny things stand in the way). > >>1. Forth is a lot harder to read than even Lisp or APL; at my former employer, ... > > This is certainly true; however, the tendency to write unreadable code is > accentuated in Forth because the language itself provides no help whatsoever > to aid the programmer in writing clean code. This is not really true. A better way of putting it would be that the author of FORTH, Chuck Moore, writes horrible code... and this has diffused down into the FORTH community as a whole. WARNING: DO NOT USE FORTH FOR YOUR FIRST LANGUAGE. Learn to *program* first. And if at all possible throw screen files out the window & use regular text files (the UNIX FORTH I posted to the net a while ago does this). > >>2. There are many incompatible implementations of Forth, and even > >>implementations from the same vendor behave radically different on > >>different processors. True. Except that FIG-FORTH is extremely portable (having ported a screen editor between FIG forths in the Apple-][+, CP/M, RSX, and RTE-IVB (HP1000)). Careful non-use of "find", "-find", "?find", and other obscenities can ameliorate this problem considerably. Avoiding assembly language helps a lot too. > >>3. The debugging support is non-existent. That depends. The support for code development is extremely good (how many languages have interactive source-level debuggers built in?). After that, though, you have to fall back on lots of dot-quotes and cross your fingers. > You, my lucky friend, are working with a Forth onto which someone has > added some semantic sugar. However, possession of a do-loop, a couple > of conditionals, and an iterative structure does not make Forth a > structured language. A language in which GOTOS are virtually impossible "unstructured"? Sorry, cheap shot. At least FORTH is more structured than the alternative: assembly. In an application where FORTH is used you generally don't have the option of using another "high" level language. > >>> 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. : recursive-routine blah blah blah [ smudge ] recursive-routine [ smudge ] ( bletch. horrible syntax ) blah blah blah ; > >>> 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. Only in Chuck "syntax checking? that's inefficient!" Moore's implementation. > >>> 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?) vocabulary barvoc immediate barvoc definitions 0 variable var1 ( ... ) forth definitions : bar barvoc blah blah blah var1 blah blah blah ; > Uh-huh. Note that subsequent function definitions would, however, use the > new operator "+". Note also that scoping is built in to most languages, > so that kludging it in isn't required. See above definition. > Nonsense. Using a variable in Forth results in slow execution, and yields > ugly code, since Forth abhors non-stack parameters. The use of threaded > code has next-to-zero influence on the edit-compile-test cycle; as most > folks familiar with software engineering know, there are a couple of blocks > in there marked "think" that represent the largest expenditure of time. > Forth does nothing to reduce the time spent there. No, but reducing the time spent compiling code (and arguing about the latest language at the desk instead of on usenet) is an admirable goal. > ---------- > To borrow from some anonymous person on the net from a while back, > Forth is like falling in a hole, crawling out after a protracted > struggle, and then saying "Look at the great thing I've done." > I don't think anyone should take this language seriously; it's just > too hard to learn, too hard to use, and too antiquated. > -- If you have anothe alternative, by all means use it. Most of the time the only alternative to FORTH is assembly language because of memory constraints and/or the lack of a good host system. In that case, go FORTH and prosper. -- -- Peter da Silva -- UUCP: ...!shell!{baylor,graffiti}!peter; MCI: PDASILVA; CIS: 70216,1076
rodb@tektronix.UUCP (Rod Belshee ) (01/17/86)
In article <3381@nsc.UUCP> freak@nsc.UUCP (Curt Mayer) writes: >let's see... BASIC, FORTRAN, COBOL, RPG... i see that FORTH has great company. >not a useful language in the top 5. > awwww... go home and control a telescope, will ya? > now... Cyber 170 assembler - a real language! > curt I honestly think that people judge Language depending on thier experiance. Unfortunatly, most people's experiance depends on what type of programs they write. I can't see writing a low level device driver in anything else but assembler, but there's nobody, gonna get me to write an accounting package in assembler. Curt Mayer may, find that type of work enjoyable... If he does I have to wonder how may years It's going to take to get his product to market, and when it gets there, what kind of reliability it has. Any one who says One Language is better than another, either hasn't taken the time to learn it, or does not involve himself in the type of programming that best fits that language. Curt Jutzi tektronix!iddic!jutz tektronix!rodb tektronix!gpp1!jutz tektronix!gpp1!golem!jutz