sstewart@x102a.harris-atd.com (stewart scot 63920) (02/07/90)
SYNOPSIS: Several weeks ago I asked for information concerning Amiga Forth....... to all those who responded thanks. I am new to Forth so I apologize for any misconceptions I might give below. Sorry I could not respond to everyone directly but our gateway is finicky about some return-paths. (I haven't figured it out yet). SUMMARY: I am sure this will raise a response or two, but it seems that Forth can do everything that C can do (graphics, sound, analysis, etc.). The Forth standard seems to be F83. Good reference books are: _Starting Forth_, Leo Brodie, Prentice-Hall, 1987. _Thinking Forth_, Leo Brodie, Prentice-Hall, ?. _Threaded Interpretive Languages_, Loeliger, BYTE Books, 1981. Commercial Packages: JForth seems to be everyone's favorite (Version 2.0, $150). Lots of people suggested getting JForth's demo fish disks. JForth V2.0 contains an all in one code developer package: editors, debuggers, the clone utility etc. Version 2.0 contains the Clone utility which takes a JForth compatable program and compilies it to form a stand-alone application that you can run from AmigaDOS. I understand that the speed and size of a cloned application is comparable to a C-coded application. Public Domain: I obtained a public domain Forth package (A4th version 1.5) from cs.utah.edu. A4th is a Laxen and Perry clone. Laxen and Perry wrote a Forth system for the PC-DOS machines some time ago. From what I can tell, A4th is a good package although I wish it had more documentation on how to just load and run something. If you are interested in Forth, A4th would be a good place to start. - Scot H. Stewart (407) 729-3223 sstewart@x102a.harris-atd.com uunet!x102a!sstewart
scott@wilbur.uucp (Scott Beckstead) (02/08/90)
Let me say this about that. I am a professional programmer who has Programmed in Forth and C. While Forth can do anything that C can do I don't particularly recomend trying to write all your aplications in Forth. Both languages have advantages and weaknesses. Forth is particularly well suited to internal control (embedded systems) software and C is optimized for systems level support and development. Though I have used both in the other aplication it was a poor fit. The package you get also will tend to be specialized for one aplication or the other. Forth is extremely fast for an interpreted language but not quite as fast as most C programs. The difference is admittedly small and you could I suppose spend a lot of extra effort to eliminate it alltogether. Lest some of you get the wrong idea writing in Forth requires a special kind of thinking called RPN or reverse polish notation. ie. FORTH: 1 2 + C: 1 + 2 the result from Forth is left on the stack and to assign the value to a variable requires yet another construct. C merely requires that you affix a (var) = to the equation. So enough soap boxing let's just say That C is a lot easier to learn but Forth can be a lot of fun. Scott -- Scott Beckstead | Sew Crates was a grate greek. CIS 76106,3720 | Dang that one got right by the spelling checker FIDO 1:206/2814 | don't look at me YOU wrote it!
bts@sas.UUCP (Brian T. Schellenberger) (02/13/90)
In article <1990Feb8.154759.21230@wilbur.uucp> scott@wilbur.UUCP (Scott Beckstead) writes: |Forth is extremely fast for an interpreted language but not |quite as fast as most C programs. The difference is admittedly small This is true of MOST FORTH IMPLEMENTATIONS, but not an inherent property of the language. In fact, JForth (which the original artical primarily discussed is not a threaded interpreted (traditional Forth) at all. It compiles each word directly to 68000 assembly (JSR-threaded), *and* it supports in-line expansion of simple words based on the length of the definitions. Thus, it produces code just like a C compiler for it is, in fact, a compiler. It lacks only an optimizer. In Forth, this not all that serious, though; optimizers mostly optimize out common subexpressions (rarely a problem in Forth; this is a real benefit of the stack approach) and other common code (also rarely a problem because of the ease of factoring problems sufficiently. All in all, the difference is likely to be miniscule when comparing C to JForth. Certainly, being able to compile in about 1/100 of the time more than makes up for whatever slight difference there might be. Now, the *other* point, about the paradigm differences is certainly valid. Forth requires a different kind of approach to problems. I think that it is just plain more fun, and certainly better suited to tasks like graphics and user interfaces because of the ability to test as you develop and the ease with which you can re-compile small sections interactively. On the other hand, C code is a lot easier to share. But that's only because it's more popular, and if you were into popularity, you'd have bought a PC, not an Amiga anyway. Right? (Actually, C *is* better [modern C, anyway, like Lattice] for applications which can't easily be verified by testing--eg, low-level stuff that must deal with extreme situations. With C, you can use prototypes and various static, compile-time verification to be sure that you are doing what you thought you were doing.) (Also, if you need to run on more than one machine, C would be my recommendation for almost any application; Forth is, alas and alak, a tower of Babel. Great fun for your own, one-machine stuff but a nightmare to port.) -- -- Brian, the Man from Babble-on. ...!mcnc!rti!sas!bts -- (Brian Schellenberger) "No one will ever write a song called 'Nitro Burning Funny Cars'" -- THE DEAD MILKMEN, "Nitro Burning Funny Cars"