Path: utzoo!attcan!uunet!mcvax!ukc!strath-cs!glasgow!orr
From: orr@cs.glasgow.ac.uk (Fraser Orr)
Newsgroups: comp.lang.forth
Subject: Re: Thinking FORTH
Message-ID: <1552@crete.cs.glasgow.ac.uk>
Date: 1 Aug 88 13:10:31 GMT
References: <8807291946.AA14510@jade.berkeley.edu>
Reply-To: orr%cs.glasgow.ac.uk@nss.ucl.ac.uk (Fraser Orr)
Organization: Comp Sci, Glasgow Univ, Scotland
Lines: 87

In article <8807291946.AA14510@jade.berkeley.edu> Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu> writes:
>
>Agreed.  My programming in all languages has improved since I learned
>FORTH (specifically since I read `Thinking FORTH').  And no, I don't

In what way? Do you mean that since reading the holy book you have been
able to design your programs better? If so, wonderful. But really,
programming language and program design are separate issues. If you want
to know about program design I can recomend several books that deal
with the topic in a lanugage independent way, thus you see how DESIGN
ideas fit (e.g., the concept of a named parameter, or a labeled variable)
and how these fit in with your language of choice (in Forth, no named
parameters, and a rather tacky idea of labeled variables.)
If I gave Kernighan and Richie's book on C, and you read it, you would
undoubtedly learn sopmething about program design (though in K&R's case
not a lot), but you would have to spend a lot of your time ignoring
all the guff about the language. If you want to learn about program
design, read a book about program design, not about Forth program design!

>think we should throw away traditional languages.  When a language is
>suited to a problem, I use that language.  For example, when I want
>to crunch numbers, I use FORTRAN.  If I want to write a UNIX utility
>program, I use C.  There is a limit to the extent to which one can
>apply the `small is better' philosophy in a traditional language,
>however.  At some point the overhead of a subroutine call makes smallness
>impractical.  C's macro facility goes a long way toward alleviating

This is a totally spurious point. The only differences between a forth
subroutine call and a C call is that C has to make a stack frame
(i.e., *allocate* a small amount of memory on the top of the stack),
the parameters have to be put there in but languages, the return address
has to be put in by both langnuages, the PC has to be set in both languages,
in fact C calls are going to be at most 1usec slower than Forth ones,
not in my opinion worth worrying about. This of course assumes that
the forth program has been compiled onto a Forth microprocessor,
if it's interpreted, well ...

>that problem, though.  Yet even when I write what I feel is an
>appropriately sized subroutine in C, it is still larger visually than
>the corresponding FORTH program and therefore harder to grasp and
>think about.  At this level we are talking about a small difference,

:fact dup 0 gt else 1 then dup 1 sub fact if ;

vs
int Fact ( n )
{
  if ( n > 0 )
    return n*fact(n-1)
  else
    return 1 ;
}

If you find the former easier to understand, you've got a twisted
mind! (PS apoligies for my forth, it has been a while since I wrote
any, and after all it is not the most memorable syntax:^)

>>how wonderful it is that you have micro-processors that can run your
>>favorite language. I say this because chips like 68000, 80386 32000
>>etc, are chips specifically designed to run languages like C. I would be
>>interested to see any experimental results comparing the preformance of a
>>Forth chip running forth compared with a 68000 running C.
>
>I'm sorry, I thought that *was* what we were talking about.  But you are
>right, the original poster was probably discussing FORTH-only benchmarks.
>I will reserve my enthusiasm until I hear the kind of comparison you
>request.  (Designing a fair benchmark may be a little tricky though,
>come to think about it.)

I know what you mean. I no great fan of benchmarks, I suppose the best
comparison would be comparing the adequacy of performance of a real
program witten in Forth and a real program written in C. An interesting
idea might be to think of some problem that both Forth'ers and C'ers
claim their language is good at, and measure the time taken to write
the program, the "preformance" of the operational program, and perhaps
if you were keep, the ease of understanding of the program to a programmer
who hadn't seen the program before. (If you really want to see Forth
bite the dust, you could also compare the ease of understanding of the
program to rookie programmers, hmmh...)

P.S. I may have given the impression above that I am a greate fan of C.
Not true, I think C is tacky in the extreme, but Forth has all of the 
problems of forth, and few of the saving graces.

==Fraser Orr ( Dept C.S., Univ. Glasgow, Glasgow, G12 8QQ, UK)
UseNet: {uk}!cs.glasgow.ac.uk!orr       JANET: orr@uk.ac.glasgow.cs
ARPANet(preferred xAtlantic): orr%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk