cwpjr@cbnewse.att.com (clyde.w.jr.phillips) (09/01/90)
I'm sorry that I deleted a little up top but it's still RADIO ACTIVE!: Subject: Re: FORTH info/reply Newsgroups: rec.music.synth Distribution: na Summary: DEBUNK BS POST References: <1990Aug29.170951.1452@cbnewse.att.com> <8637@ccncsu.ColoState.EDU> In article <8637@ccncsu.ColoState.EDU>, rsk@oldfield.cs.colostate.edu (Rich Kulawiec) writes: > In article <33166@cup.portal.com> dbell@cup.portal.com (David J Bell) writes: > >Yes, I'm definately leaning towards a forth engine for the target box. > > Forth was a cute idea, and made an interesting toy, but it's entirely THIS IS WHERE I DELETED A BUNCH O BS, but theres more... > fad and that in ten years Forth would dominate the market. Poor sap.) Toys don't last in the market place and another individual can be as wrong as you are! 8^) Since the level of your diatribe is childish at least smileys are to be considered as mere formalities. > > A few specific comments: > > 1. Forth is a lot harder to read than Lisp, APL, or just about > any other language I've ever seen. Even well-written commented Forth > is *still* hard to read. Diametrically wrong: FORTH is the easiest to read if you know FORTH. Do you or do you believe you do? > > 2. The debugging support is non-existent. It is a DEBUGGER, both in it's support for the most MODULAR, FINE grained HIGH LEVEL language, in it's syntax, ( THE SIMPLEST syntax is the easiest ...) and in it's interpretive/compiler nature. You obviously have no exposure to THE state of this ART. Do you know anything about real-world dev? 8^) > > 3. 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. The primitive set of oporations is 13! Count em. Too large for you? We're talking about a stack machine here, SIMPLER THAN RISK! Get it? > > 4. Forth is *not* fast. It's not even quick. So forget handling > lots of data with it, because you'll get very bored very quickly. This depends, RTX FORTH 15 native MIPS, SC32 FORTH about 25 MIPS, AT&T we32DSP FORTH about 25 mips with 25mFLOPS for free! Who are you foolin? > > 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, rougly speaking, > the last 20 years of evolution in programming techniques. Your comments are less structured than FORTH. Typed is a matter of "what type" Do you imply that typing is unavailable? I beleive the design of FORTH exploits the lessons UNIX/C learned that are typified in SW TOOLS & Plaugher stuff. You might find enlightenment in THINKING FORTH by Leo Brady. SUN. POSTSCRIPT, IBM HP ETC don't use FORTH because it is what you say it is... > > I'd also like to quote an article by Don Libes, posted to net.ai > on January 22, 1984; this article was posted in the midst of a > discussion on the possible use of Forth in AI, but every one of > its points applies to almost any use of Forth... > > --- begin quote --- > > 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.) >O MAINPULATING DATA IS What FORTH excels at. SOME OF THE FIRST and LARGEST AI systems are written in FORTH. Do you have any study skills? IT is THE REAL TIME ENGINE OF PREFERENCE FOR INFERENCE ENGINEs in my BOOK. Developement of the systems is EASY and SIMPLE. The results are dramatic and FAST! > 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! Any one else care to touch this... it's to mor ( oops netiquete please ). > > 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. >O Also wrong, check out ANSI FORTH Homework must be to much... where is your NETIQUETE????????? > 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. No understanding of the interpreter / compiler here... computer sci ... life/// > > 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 playin with free FORTH or what???? > > 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"). > Doesnt this contradict your eealrlier statement about FORTH speed. You are BOTH WRONG! > 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! > This sounds like a five minute exposure to FORTH. IT ( not it's stack ) is too deep for a 5-min critique. > 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. This is a mental problem most people don't seem to have. If you'd like some help there are exercises that can strengthen thar flabby gray stuff 8^). > > 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. > > --- end quote --- What about those things that can ONLY be done reasonable in FORTH. No not even those I suppose... > > -- > Be seeing you, > Rich Kulawiec > rsk@cs.colostate.edu, rsk@ecn.purdue.edu, boulder!rsk For what?