Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!ucsd!sdcc6!ir230 From: ir230@sdcc6.ucsd.edu (john wavrik) Newsgroups: comp.lang.forth Subject: Re: What makes Forth Forth Message-ID: <14789@sdcc6.ucsd.edu> Date: 7 Dec 90 07:11:24 GMT References: <9012051459.AA18739@ucbvax.Berkeley.EDU> <12692@medusa.cs.purdue.edu> Organization: University of California, San Diego Lines: 139 # In article <9012051459.AA18739@ucbvax.Berkeley.EDU> Mitch Bradley # writes: # >> use it over and over again. extensibility without testability # >> is insanity. Spell it `C' (sorry, Mitch: I realize that C is not # untestable. It's just # >> harder for me, and takes longer in general.) # > No argument from me. I too find Forth easier to test than C, and # >prefer to program in Forth than in C. # # Isn't the main reason for this because FORTH is interactive and # the C you are using is not? Interactive languages are always # easier to debug and program. There are other interactive # languages besides FORTH! Bill Bouma's point is well taken. I think that ease of debugging (which comes from persistence of values of variables and the ability to execute parts of a program) is in fact characteristic of all interactive (interpreted) languages. Another feature common to these languages is the ability to produce what Forth programmers call an "application" as distinguished from a program. An application is a collection of commands designed for independent interactive execution. A program is, in essence, an application with a single top-level word (RUN or MAIN or whatever). Conventional compiled languages produce programs. The fact is that for quick development and debugging, an interactive environment is desirable. That other languages also offer this does not negate the fact that Forth does too -- and that it is an asset. 'C' does not have this feature (nor does Pascal, FORTRAN, Modula2, Ada, etc.) While on this subject, "factoring" is a programming technique not a Forth feature. It can be practiced to advantage in all languages (including non-structured languages like FORTRAN and BASIC). I've had some of the graduates from my Forth course tell me that they have used Forth-style programming techniques with good results in their jobs (using 'C') -- they factor more than their 'C' trained counterparts -- and they feel that they can produce correct programs more quickly as a result. In another direction: the programs in the text "Structure and Interpretation of Computer Programs" by Abelson, Sussman, Sussman show as much factoring as typical Forth programs -- and the language used is Scheme. The idea that Forth programmers use (and have used) a technique which is now recognized as "good style" speaks well for Forth and Forth programming techniques --- but is not what makes Forth Forth. # >In promoting Forth, I find that a balanced viewpoint (C has these # >strengths and these weaknesses, Forth has these strengths and these # >weaknesses) is more effective overall than the extreme positions (C # >sucks; it is horrible. Forth is God's gift to programmers) sometimes # >espoused by Forth fans. # # Definitely! "More effective" is exactly the way to put it. # Whenever I encounter the extremist viewpoint from someone, their # credibility goes way down. It says to me they both don't have much # programming language experience, and they are prone to jump to # conclusions. Why should I listen to anything such a person has to # say? It may, rather, be jumping to conclusions to assume that anyone devoted to Forth "don't have much programming language experience". The participants in the discussion at Asilomar all seemed to have had a great deal of programming language experience -- but all sensed a special quality in Forth. It is indeed a subjective matter -- probably one not much studied -- but some people do perceive one programming language to be "better" (more powerful?, more flexible?) than another. The exercise is to identify the qualities of Forth which account for this subjective experience in those who have it. There are some areas of application for which programming in a conventional compiled language (like 'C') seems extraordinarly awkward to some people -- while Forth seems perfectly natural to them. It isn't necessary that everyone have the same experience for the experience to be valid. It isn't necessary for someone who has the experience to be articulate about it. Given the gift that many programmers have with the English language it should not be surprising that some of them summarize their experience by "C sucks, Forth is great". It is not necessary to be articulate about the properties of a programming language to use it. There are two main reasons for wanting to be more articulate about the properties of Forth: 1. To help Forth take its place in the part of the world that talks about programming languages (read "academic acceptance"). 2. To make sure that essential properties of the language are not lost in the process of "popularizing" it or "making it marketable". # C may indeed suck, but try comparing FORTH to the myriads of # other languages out there, including the other interactive ones. # Then tell us what makes FORTH different. I think that the difference will eventually be found to lie in the ability of a user (programmer) to exercise control over the features of the language. This, in turn, will be found to come from the simplicity of the implementation and the access a programmer has to it. I recall a discussion with a 'C' programmer in which I pointed out that 'C' (like many other languages) requires new algebraic objects to be treated with a different syntax than built-in objects. He saw no objection to complex numbers, matrices, polynomials, etc. being "second class citizens" -- with operations using a different syntax than used for primary objects. I *DO* see an objection -- and I regard a strength of Forth as the ability to add new objects with first class status. This ability comes from the fact that the Forth programmer has access to the language at the level at which primary objects are introduced (so it is no surprise that he also has the tools to introduce new objects which are treated like primitive objects). A good example of the distinction between Forth and other languages is the CASE construct. Forth has not had a CASE construct (more exactly, it has had many). Instead, Forth provides the programmer with the ability to add a CASE construct (of any desired form) to an application. The knowledge that a Forth programmer has of what is compiled and how it is compiled allows him to introduce new constructs that affect compilation. Forth, then, has attributes common to all languages (like "factoring") and attributes common to all interactive languages (like persistence of variables) -- but it offers an extraordinary degree of control over the language itself. P.S. The main challenge to the Forth community is to show that putting more control over the language in the hands of the programmer can result in more power without drastically increasing error or increasing the incidence of incompre- hensible programs. John J Wavrik jjwavrik@ucsd.edu Dept of Math C-012 Univ of Calif - San Diego La Jolla, CA 92093