wmb@MITCH.ENG.SUN.COM (08/11/90)
> I would be more inclined to put C and Forth at about the same level. > If you look at the language itself and not the libraries. I say that > because while PD or ShareWare versions of Forth are pretty bare bones, > so are most PD or ShareWare C's. Except that why would anybody bother with a PD or shareware C when you can get Turbo C (which is a dynamite product) for about $100? If your time is worth anything at all, the price is worth it many times over. The only freely-available C worth bothering with is Gnu C, which isn't barebones by any stretch of the imagination. (It also doesn't run on PC's). Few people bother with stripped-down C these days. > Anyway, from the ads I've seen, the libraries available for Forth are > comparable to those available for C. With one important difference: the C libraries are all more or less (usually more) compatible with one another, whereas every Forth library is pretty much an island to itself. > As a side note, it tickles me to see the ratio of PD/ShareWare Forths to > C's versus the ratio for commercial products. Actually, it bothers me, because that means that basically nobody can make a living selling Forth, which means that few marketing dollars are going to be spent, which means that Forth may be doomed in the long run. Idealistic principles aside, economics makes the world go round. The only company in recent memory that has spent significant marketing dollars on Forth is Harris. I wonder if they would do it again? Of course, none of this in any way invalidates the author's point, which is that C and Forth are about on the same "level" in some linguistic sense. I'd pretty much agree with this, although I would claim that the "level" of C is more "fixed" than Forth, at least in terms of how people actually use it. Mitch
dwp@willett.pgh.pa.us (Doug Philips) (08/14/90)
In <9008111941.AA11132@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes: > > If you look at the language itself and not the libraries. I say that > > because while PD or ShareWare versions of Forth are pretty bare bones, > > so are most PD or ShareWare C's. > > Except that why would anybody bother with a PD or shareware C when you can > get Turbo C (which is a dynamite product) for about $100? If your time > is worth anything at all, the price is worth it many times over. > > The only freely-available C worth bothering with is Gnu C, which isn't > barebones by any stretch of the imagination. (It also doesn't run on PC's). > > Few people bother with stripped-down C these days. You can also get Power C from Mix Software for $20. An extra $10 gets you the library source. As to why people don't bother with a PD/Shareware C? I think that the answer is that having compatibility is much more important than being able to grow the compiler into your application. Nothing to do with price. Your own counter-example of gcc shows that. > > Anyway, from the ads I've seen, the libraries available for Forth are > > comparable to those available for C. > > With one important difference: the C libraries are all more or less (usually > more) compatible with one another, whereas every Forth library is pretty > much an island to itself. But is that because the various Forth vendors are "Not Invented Here" weenies, or is it an artifact of starting from different Forth platforms in the first place? > > As a side note, it tickles me to see the ratio of PD/ShareWare Forths to > > C's versus the ratio for commercial products. > > Actually, it bothers me, because that means that basically nobody can make > a living selling Forth, which means that few marketing dollars are going > to be spent, which means that Forth may be doomed in the long run. Idealistic > principles aside, economics makes the world go round. The only company in > recent memory that has spent significant marketing dollars on Forth is Harris. > I wonder if they would do it again? I don't know about that part. What I want to know is why commercial Forths are so bloody expensive. You don't usually even get source! With the profane languages that is less of an issue because you don't want to make your compiler incompatible. In the case of Forth, you'd want the source so that you *could* make it compatible. Forth Inc sells polyForth for > $3000 last I heard. I have NEVER seen a C compiler that expensive (I don't read the Cray audience trade rags either though). The main problem with ShareWare Forths is that the level of support. Mix Software can make money selling PC C compilers, debuggers and libraries for extremely reasonable prices. They have customer support. If a cheap Forth came out, I would buy it. If GNU did a Forth, I might use it, but with the CopyLeft, I might not, it depends. -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]
rajuk@umree.isc.umr.edu (Raju Khubchandani) (08/17/90)
In article <1522.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: ( deleted ) .... > >I don't know about that part. What I want to know is why commercial Forths >are so bloody expensive. You don't usually even get source! With the profane >languages that is less of an issue because you don't want to make your >compiler incompatible. In the case of Forth, you'd want the source so >that you *could* make it compatible. Forth Inc sells polyForth for > $3000 >last I heard. I have NEVER seen a C compiler that expensive (I don't >read the Cray audience trade rags either though). The main problem with >ShareWare Forths is that the level of support. Mix Software can make >money selling PC C compilers, debuggers and libraries for extremely reasonable >prices. They have customer support. If a cheap Forth came out, I would >buy it. If GNU did a Forth, I might use it, but with the CopyLeft, I might >not, it depends. >-Doug ( deleted ) I would like to get some comments on $119.00 Forth from RTD ( Real Time Devices, Inc. located in PA ) which they sell for their data acquisition and control IBM-PC plug- in cards. I was developing an application using an applications software package ( not written in Forth ) called LABTECH NOTEBOOK and a plug-in card from "Data Translation, Inc." ( located in MA ), but these proved to be awfully slow in execution. That is, it could give me a very low sampling rate. Although RTD's plug-in card is much cheaper, it involves additional programming labor as compared to LABTECH NOTEBOOK. ( I want to do a PID loop ). Besides, I wonder if RTD will be faster ! If yes, then how much faster ? Any suggestions, info or education will be much appreciated. rajuk@umree.ee.umr.edu
kubiak@crhc.uiuc.edu (Ken Kubiak) (09/25/90)
It seems that there is already some operator overloading going on in C. That is, the expression "a + b" compiles to different code depending on whether a and b are int, short, float, or double. On the other hand, unless you are using some typed extension to forth, you have to specify which operator (and any necessary conversions) to use. However, it is possible to make Forth higher level than C or even C++, if one wishes. But is that language still Forth? -- Ken Kubiak (kubiak@crhc.uiuc.edu) 1101 W. Springfield Ave. Center for Reliable High-Performance Computing Urbana, IL 61801 University of Illinois at Urbana-Champaign (217) 244-7179
RAYBRO%UTRC@UTRCGW.UTC.COM ("William R Brohinsky", ay) (09/25/90)
Ken Kubiak asks ``...it is possible to make Forth higher level than C...But is that language still Forth?'' My answer, based on my own humble opinion, is `yes', as long as the programmer still has access to the inner interpreter and dictionary, and can still create his own structures, constructs, and do the other things that make Forth Forth. If the higher level language implemented in Forth discludes these aspects of programming from the programmer, then you have implemented the higher level language. This is just like writing a C compiler in assembler. It stops being an assembler when you shut off access to the assembler, i.e., assembling the code into the C compiler. If you implement C in forth, but do not shut down the interpreters and limit access to extending the dictionary, it is still Forth, albeit with the additional constructs of C. When I was in communication with ECFB, many years ago (about three...), Someone there told me that they'd implemented LISP on a forth engine, and that it ran faster than any Lisp engine they'd had experience with. I don't know the metrics, and the speed stuff is really peripheral to this message, but his remarks about how it was easier to write the code to make a LISP compiler than to write LISP code got me thinking. If he'd left the FORTH language available under the LISP language (which, in fact, he might just have done) I think it would still be FORTH. What do y'all think? raybro