orr@cs.glasgow.ac.uk (Fraser Orr) (08/29/88)
In article <6951@well.UUCP> jax@well.UUCP (Jack J. Woehr) writes: >In article <1581@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >>Jack, are you suggesting that because "industry has taken it >>by storm", that it is necessarily the best (or even appropriate)? If so, >>do you also support COBOL as the best for buisness work, or Fortran for >>sientific work (yes, I know all the arguments about software libraries >>etc, but that's not the point, we're discussing what is the most appropriate >>medium to express your ideas is). >> >>I think though my statment was perhaps too strong though. I don't >>really know how good forth is for this kind of work, since I have >>never done such programming in forth. > > Frase, I write control apps for a living. In Forth. Sometimes >two a day. > [Stuff about how to save you company $8000 deleted] Tell me, would it be fair to say that the majority of control software is the same, with a few device varations? If so I guess (though I could be wrong - believe it or not folks !:^) that the reason these savings can be made and that you can be so productive, is not due to forth but due to a large degree of software reuse. Thus you are in the position of buisness and sientific users, in that in the long term it would be benificial to change (in the very long term), but it would mean rewritting a lot of established software. Now of course is you adopted my suggestion of havinf a preprocessor that converted to forth, you owuld have the best of both worlds, a nice language and all that lovely software. Of coure all of the above could be total rubbish (is there a possibility that someone is about to agree with that last remark, is this the first agreement we have had ? <^:), but I don't know anything about your work. > As a matter of fact, if you have not yet heard, the annual >Forth Interest Group convention has been renamed the Real Time Programming >convention. How very presumptuous of them! :-> > Yes, Forth has found a niche at last! I've never disputed that forth has a niche. I just reckon that niche is the code generated by a preprocessor. ===Fraser Orr (orr%cs.glasgow.ac.uk@nss.ucl.ac.uk)
koopman@a.gp.cs.cmu.edu (Philip Koopman) (08/31/88)
In article <1586@crete.cs.glasgow.ac.uk>, orr@cs.glasgow.ac.uk (Fraser Orr) writes: > Tell me, would it be fair to say that the majority of control software > is the same, with a few device varations? If so I guess (though I could > be wrong - believe it or not folks !:^) that the reason these savings > can be made and that you can be so productive, is not due to forth > but due to a large degree of software reuse. Control software is not necessarily all the same. The amount of re-use between applications should be about the same regardless of the language (or else there really *is* something really wrong with all those other languages.) This is not to say that Forth programmers don't build their own tool boxes -- it's just that all programmers do that. I think one of the great productivity increases is not re-use between applications as much as re-use within the same application. Forth encourages breaking the problem into small enough pieces that most pieces get re-used a lot of times within the same application. I find that my Forth programs better reflect the structure of the solution to the problem, instead of the structure of the way the compiler wants you to solve the problem in other languages. > Now of course is you adopted > my suggestion of havinf a preprocessor that converted to forth, you > owuld have the best of both worlds, a nice language and all that lovely > software. I don't think a preprocessor is the correct answer. Forth works better by building and using tool sets that form extensions to the language. An idea I like better is mating an interactive C compiler into the Forth environment. Use C for those parts of the application that it is appropriate for, and Forth when it is appropriate. This is likely to be what you see emerging as the environment for the new Forth hardware, since C programmers form a much bigger market than Forth programmers. C as a high level language, Forth as the "assembly" language. Phil Koopman koopman@maxwell.ece.cmu.edu Arpanet 5551 Beacon St. Pittsburgh, PA 15217 PhD student at CMU and sometime consultant to Harris Semiconductor. I only speak for me, etc.
wbrown@beva.bev.lbl.gov (Bill Brown) (09/01/88)
I've seen a language (I think it was called "MagicL") which was an attempt to combine "c" and "Forth". I was never in a position where I had to untangle it, and it was before I really started to use "c", but I had the feeling that it combined the worst features of both languages. Please note that this is a personal opinion; it does not reflect the opinion of L.B.L. or any other person, place or thing, living or dead, and nobody around here thinks I know beans about anything. -bill
koopman@a.gp.cs.cmu.edu (Philip Koopman) (09/01/88)
In article <917@helios.ee.lbl.gov>, wbrown@beva.bev.lbl.gov (Bill Brown) writes: > I've seen a language (I think it was called "MagicL") which was an > attempt to combine "c" and "Forth". I was never in a position where > I had to untangle it, and it was before I really started to use "c", > but I had the feeling that it combined the worst features of both languages. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ YES -- that's the point! What you get when you try to force a "normal" infix parser on top of Forth can easily be a mess! From what little I could see of MagicL from the articles I read about it a few years ago, it looked like Fraser's preprocessor idea carried to a full implementation. A preprocessor can be put onto Forth, but that's not the issue. Evaluating complex arithmetic expressions is not what most Forth code does. When I said that I have considered combining C and Forth environments, what I mean is having either: 1) Separate C and Forth compilers that can share routines 2) A C compiler that can include pieces of normal Forth code as "assembly language" insertions, not a hybrid language. The idea is to be able to port existing C code onto a stack machine, then optimize the inner loops using Forth == "machine language." Phil Koopman koopman@maxwell.ece.cmu.edu Arpanet 5551 Beacon St. Pittsburgh, PA 15217 PhD student at CMU and sometime consultant to Harris Semiconductor.