Path: utzoo!news-server.csri.toronto.edu!rutgers!ucsd!sdd.hp.com!news.cs.indiana.edu!purdue!bouma From: bouma@cs.purdue.EDU (William J. Bouma) Newsgroups: comp.lang.forth Subject: General Purpose Forth Message-ID: <13837@medusa.cs.purdue.edu> Date: 12 Mar 91 21:43:05 GMT References: <3729.27db5037@iccgcc.decnet.ab.com> Organization: Department of Computer Science, Purdue University Lines: 85 In article <3729.27db5037@iccgcc.decnet.ab.com> schmidtg@iccgcc.decnet.ab.com writes: > bouma wrote: >> Forth down. A language that deals only with characters and integers >> is a joke. It is no coincidence that Forth gravitated to the embedded >> processor area, they don't need to deal with anything besides integers >> ... > >FORTH is an excellent general purpose language for just these reasons! FORTH >provides one with the tools to create more specialized tools which are useful >to solve a given problem. Try adding a new control structure to 'c'! Why do people always try to drag C into the argument? I have never felt the desire to add a new control to C. I can program sufficiently in C given the structures which are provided. In addition C provides me with a wide variety of types and uniform ways to create new ones and deal with intermixing. >Traditional compilers just make too many assumptions about what it is you >want to do. If additional data types are required for your application, FORTH >allows you to easily create them. Perhaps FORTH's expressive power is not >for everyone, but when used with discipline, allows the creation of higher >level languages which are custom tailored to your specific applications. Heck, Assembly language has more "expressive power" than Forth! Does that make it a good general purpose language? Ok, write a floating point package (+ - * / are sufficient) using only Forth. Given a rich variety of integer and character operations this could be done. Now try sharing your code that uses this package with a friend. Good, that works because you have been careful to use only Forth in your package and avoided machine dependencies. Now try com- bining some code that uses your package with your friend's code that uses his package. Trouble. At that point you and your friend are both thinking you should have used the same package to start. Suppose in Forth I want to create a new type which is just a data struc- ture of integers and characters. In doing so I have to think about memory in a concrete sense. Memory allignment, slot access functions, byte size of integers are all considered in writing my code. In any language besides Forth all I gotta do is say I want a type named * which has slots ** of types ***. The compiler takes care of memory offsets, allignment, and access. Memory has become an abstraction with little shape or structure. Personally, I have found the higher the level of abstraction, the farther I am away from the actual machine, the more productive I can be. And I am one who LIKES to program in assembly language and can do so at lightning speed (brag, brag, brag). Forth allows me to program at a high level, but only after I have built a tower with a very concrete base. Having the ability to merge a tool "seamlessly" into the language and having the tool provided are very different things. For one, people are basically lazy and will opt not to write their own given a choice. It takes time and a certain level of expertise to build a solid foundation for the rest of program structure. To build the base in Forth you may have to resort to assembly language to obtain reasonable performance (eg. adding floating point). No other language which calls itself "higher level" would ever require the prog- rammer to know anything about the machine it is running on! Data types is such a basic and fundamental abstraction in programming that it is silly for Forth not to deal with it in a standard fashion, and be done with it. Why should each person that wants to use different types have to first figure out a method, and then implement it individually? It seems proof that Forth was never meant to be general purpose, that the type issue was not dealt with long ago. > bouma said: >> 8^) Perhaps. Perhaps it just isn't that deserving of attention from >> people who aren't tring to interface to hardware or aren't limited to >> 64K of memory. > >Or is it that concepts such as "rapid prototyping" and "extensibility" aren't >"deserving of attention" unless we refer to them in a language like smalltalk, >which originated in a research laboratory? But there are languages provide rapid proto, extensibility, AND a high level of abstraction, plus a rich variety of data types, OO constructs, macros, parallel constructs, automatic memory management, dynamic variables, pattern matching, ... (eg. Common lisp with CLOS) The reason Forth has not gotten any attention is because it has failed to keep up with the latest inovations in computer languages. It has nothing to do with Forth's bastard-like origins. -- Bill