Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!sdcc6!ir230 From: ir230@sdcc6.ucsd.edu (john wavrik) Newsgroups: comp.lang.forth Subject: Thoughts on Forth Message-ID: <6025@sdcc6.ucsd.edu> Date: 11 Jan 90 16:56:31 GMT Organization: University of California, San Diego Lines: 154 The quotes below come from an exchange between John Wavrik and Doug Philips: # In <6001@sdcc6.ucsd.edu>, john wavrik writes: # . Its most permanent feature # is its adaptability. I don't disagree with your 'strong and beautiful' # assesment, perhaps I'm just saying that Forth's strengths and beauties # are different from most other languages, and as such the casual # observer/novice is going to be looking in the wrong places for the wrong # things. One of the problems with describing Forth to others is that we tend to use similes and metaphors to describe the subjective experience we have with the language rather than the objective features which account for the experiences. [It's a bit like trying to explain to someone who has never tasted sauerbraten why you think sauerbraten tastes good.] A desert, to me, is a wasteland. There are, perhaps, a few sparse patches of vegetation -- but mostly it's bare sand. You can't build much with sand, and what you build doesn't last very long. Comparing Forth to a desert strikes a very negative chord. I try to compare Forth with mathematics (which, to me, is a subject where vast edifices are built from a few simple ideas by using the mathematician's understanding of how the system works). Unfortunately, this seems to provide, for 50% of the people I talk to, an opportunity for them to tell me why they got a "D" in differential equations -- and how much they hate math. That's the problem with metaphors: "It's like mathematics" is the most positive thing I could think of to say about a computer language (and Forth is the only one I can say it about) -- but to a lot of people this seems to make negative associations. I hope we both agree, however, that the importance of Forth lies more in the ways in which it differs from other languages rather than the similarities. # That isn't what I was trying to say. The problem is that the buses are # finding it profitable to put in lines where it hadn't been profitable # to put them in before. What were once the refuges of the frontiersman # are now becoming the tourist traps of the bus tours. The frontiersman # hasn't changed. Perhaps the wilderness has. It isn't as hostile as it # used to be, nor as inaccesible to other forms of traffic. [If embedded # systems can cheaply provide the resources for C's bus lines, then they # aren't the same kind of embedded systems that they were.] It isn't # 'frontier' anymore. The frontier has moved. I guess my problem is with the analogy. I'm using Forth because I need an interactive computing environment. I also need the ability to add my own data structures and operations. Experimenting with algorithms and implementation of data structures is as much a part of my work as obtaining the results of computations. Using a conventional language would be a matter of "making do". Forth, to me, is a language for building languages. I don't think that any other language you care to mention has this property. Mathematics will never run out of data structures that no one knows how to represent or computations for which good algorithms are not known. Mathematics will also never cease to be an area that benefits from an interactive environment. I don't, therefore, see Forth as a language for cutting paths which will eventually be taken over by another language -- I see it as providing an alternative type of computing. Phil Koopman, on the other hand, sees Forth as the perfect language for small systems to control hardware. While his view of Forth as "the language for embedded systems" is quite different than mine of Forth as "the language for building languages", we both share the view that Forth is important because it does something different than other languages. Forth offers unique (and permanent) capabilities that are not within the nature of other languages to offer. # It strikes me as amazing that, given Forth's adapability, it wouldn't # have found other niches over a 10 year period (to use your time frame). # I get the impression that despite all the other changes in the computer # industry, Forth is like a little kid refusing to grow up. The world is # always changing. Forth is, seemingly, ideally suited to track change and # adapt with it, to 'follow the frontier'. Where is Forth going? Its # following the frontier! And where is the frontier? Forth is not a little kid refusing to grow up, it is brilliant idea waiting for people to understand and use it properly. Suppose someone provides you with a language that does something, but has a few deficiencies. After you study the cause of these deficiencies, you may create a new language (which does essentially the same things in the same way as the original language) to fix the deficiencies. I hope that I am not saying anything too controversial by claiming that 'C' is just Pascal with a few deficiencies fixed. (It doesn't look like Pascal because begin..end has been replaced by { .. }, etc. -- but the fact is that programs have been written to translate Pascal programs to 'C', so the visual differences are more cosmetic than real). Most languages are part of a progression starting with FORTRAN and ALGOL and inherit a body of understanding (and misunderstanding) of what a computer language should be and how it should work. Now suppose that someone gives you a language which allows a radically expanded range of capabilities. Suppose, for example, that you can even add your own control structures --- so, essentially, programming can involve altering the language itself. It can take years to understand what can be done with this expanded capability, what should be done, what should not be done, etc. Some experts will tell you "a programmer should never be allowed to invent control structures" or "a user should not be concerned with how a language is implemented" -- and there are good reasons for saying this -- but also good reasons for feeling that, if used properly, this could be beneficial. A radically new concept cannot be expected to bear fruit quickly -- it needs to be explored. It should not be surprising that such a language encourages a variety of perversions. Without any conventions for the writing of clear code, there is no doubt that many examples of "write only" code will be produced [adding fuel to the fire of critics who claim that writing clear code in such a language is impossible]. A very flexible language also encourages a form of masturbation -- people become preoccupied with modifying the language rather than doing anything with it [adding fuel to the fire of critics who claim that nothing can be done with it]. 1. The whole issue of how to use and not abuse the freedom that the language provides must be addressed. 2. Can such a language be standardized so that it retains its flexibility for each user yet achieves a high degree of portability? 3. What is necessary to allow a community to jointly add powerful features to such a language as portable extensions? 4. What is the best approach for setting standards for such a language? 5. The language must become portable enough, well understood enough, established enough so that it can be taught. How can these goals be best achieved. These are just of the few of the issues that need to be addressed. Since Forth is not just a reworking of a conventional language, some of these issues may need to be dealt with in a novel way. It may be that Forth is having a problem with Standards right now because the approach used to set standards for conventional languages is inappropriate to Forth. A brilliant idea doesn't automatically thrive -- it all depends upon the people to whom it has been entrusted for development. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093