koopman@a.gp.cs.cmu.edu (Philip Koopman) (01/01/90)
Recently I have discerned a dichotomy in various discussions about Forth and Forth-based environment. On the one hand, it appears that the only place where Forth is (or may be, depending on who you ask) widely used is in embedded control systems. This is not to say that it is not used elsewhere, merely that it is not widely used in the context of all programmers working on a class of applications. This is really no surprise, because classical Forth is at its strongest in a constrained system with tough specifications to meet. On the other hand, much of the discussions and proposals on how to change, improve, and modify Forth is based around large system considerations. Where will this lead? I could see that it might lead to a situation where embedded control applications diverge from the "mainstream" of the Forth community in order to keep their systems lean, while the others go on to evolve fat systems for Unix use. And, don't be so fast to give the argument about being able to simply subset the Unix Forth for use in embedded systems. The assumptions and structure of a fat Forth system, unless special care is taken, run a little bit too deep in the implementation to be able to just strip out major features without a lot of work as well as a qualitative shift to the way the language looks and feels. Of course, one is then left to ask whether the real mainstream would then be the embedded systems folks or the Unix system folks. Forth has many things to offer in tightly constrained embedded systems that no other language can. And, "cheap" memory not withstanding, there will *always* be tightly constrained environments where resources, especially memory, are in very short supply. Forth may not have much to offer the average programmer (i.e. the non-elitist non-creative 9-5'er referred to in earlier posts) in a Unix environment. Perhaps, if we want to see Forth get acceptance with the rest of the world, we should make a concerted effort to make it very usable for embedded control applications. Right now, only folks who are desperate in embedded control applications will turn to Forth to get a job done (as opposed to learning it for aesthetics or fun). If we can make it the *language of choice* in some application area, then we will have gained a foothold in the rest of the world. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior Scientist at Harris Semiconductor. I don't speak for them, and they don't speak for me.
wmb@SUN.COM (01/03/90)
> fat systems for Unix use. And, don't be so fast to give > the argument about being able to simply subset the Unix > Forth for use in embedded systems. The assumptions and > structure of a fat Forth system, unless special care is taken, > run a little bit too deep in the implementation to be able > to just strip out major features without a lot of work as well > as a qualitative shift to the way the language looks and > feels. From experience with my own rather "fat" Forth implementations, I can confirm that it does indeed require care to structure an implementation so that it can be "subsetted". However, it is not really all that difficult. Furthermore, having taken such care, the implementation becomes more modular, which has many useful side effects, such as increased portability and ease of maintenance. For example, my "fat" systems have a sophisticated input stream mechanism, with abstract stream types that resolve to files or devices or memory or whatever. However, since the interface between that and the rest of the system is fairly modular, I can replace that with a very small "keyboard only" input stream implementation, or anything in between. > Perhaps, if we want to see Forth get acceptance with > the rest of the world, we should make a concerted effort > to make it very usable for embedded control applications. Here's the trend that I see: Most programmers' habits and strategies are set by the environment that they use on general purpose computers. Then they tend to want to continue to use that development environment to write code for the embedded system. It seems to me that this is causing C to encroach into the embedded systems world, rather than having Forth expand into the general computing world. They may pay a penalty for this, but they are often willing to pay that penalty in exchange for not having to learn a new language or environment. Furthermore, hardware technology keeps improving so fast that, in many cases, the penalty may be erased in 6 months time. You can always counter that there will be always be a "lower-end", but that would seem to consign Forth to an ever-decreasing part of the market. My preferred solution is to increase the number of standardized "add-on" packages. A "lean and mean" subset implementation can always be built "from the ground up"; one does not have to get there by stripping down a fat implementation. Mitch
jax@well.UUCP (Jack J. Woehr) (01/03/90)
In article <7436@pt.cs.cmu.edu> koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: > > >Recently I have discerned a dichotomy in various discussions >about Forth and Forth-based environment. On the one hand, >it appears that the only place where Forth is (or may be, >depending on who you ask) widely used is in embedded control >systems. It's definitely a big portion of the Forth dollar. Of course, some authorities estimate that 90% of the American computer dollar goes to embedded systems. ,,, <stuff deleted> ,,, > >On the other hand, much of the discussions and proposals >on how to change, improve, and modify Forth is based >around large system considerations. Disturbing thought, eh? I've decided to start attending ANSI meetings with just that thought in mind. > >Where will this lead? I could see that it might lead to a >situation where embedded control applications diverge from >the "mainstream" of the Forth community in order to keep >their systems lean, while the others go on to evolve >fat systems for Unix use. And, don't be so fast to give >the argument about being able to simply subset the Unix >Forth for use in embedded systems. The assumptions and >structure of a fat Forth system, unless special care is taken, >run a little bit too deep in the implementation to be able >to just strip out major features without a lot of work as well >as a qualitative shift to the way the language looks and >feels. Well, that may be too general. In a sense we are already there, Phil. The thought that the average SBC programmer is going to metacompile a target application from FPC Forth, for instance, is pretty humourous. But increasingly there are systems available that are "fat" on your PC but are able to target compile fairly simply for a ROM project. So you can have your cake and eat it, it seems. >Of course, one is then left to ask whether the real >mainstream would then be the embedded systems folks or >the Unix system folks. > Hey, wherever ya stand is the center of the universe, right? In what language community is this as true as with Forth? ,,, <stuff deleted> ,,, >we should make a concerted effort >to make it very usable for embedded control applications. That's what we do every day at Vesta Technology, Inc. Our SBC's based on 8088, 80188, 68000 with onboard F83 featuring host-PC diskserving and autostart compiled overlays do the trick! <<<end of plug>>> >Right now, only folks who are desperate in embedded control >applications will turn to Forth to get a job done (as opposed >to learning it for aesthetics or fun). If we can make it the >*language of choice* in some application area, then we will >have gained a foothold in the rest of the world. > You're kidding, right? Among the cognoscenti, Forth *IS* the language of choice for embedded control. Keep up the Good Work, Sir Phil de L'Harris, and the heathen will yet see the light! {}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{} {} jax@well ." Sysop, Realtime Control and Forth Board" FIG {} {} jax@chariot ." (303) 278-0364 3/12/2400 8-n-1 24 hrs." Chapter {} {} JAX on GEnie ." Tell them JAX sent you!" Coordinator {} {} jax@well.sf.ca.us {} {}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}