Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!boulder!sunybcs!rutgers!rochester!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman From: koopman@a.gp.cs.cmu.edu (Philip Koopman) Newsgroups: comp.lang.forth Subject: Re: Jack Woehr's amazing productivity! Summary: software re-use at a different level Keywords: Parallel, controllers Message-ID: <2842@pt.cs.cmu.edu> Date: 31 Aug 88 13:34:40 GMT References: <8808121826.AA23206@jade.berkeley.edu> <1575@crete.cs.glasgow.ac.uk> <1586@crete.cs.glasgow.ac.uk> Sender: netnews@pt.cs.cmu.edu Organization: Carnegie-Mellon University, CS/RI Lines: 39 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.