Path: utzoo!utgpu!attcan!uunet!mcvax!ukc!strath-cs!glasgow!orr
From: orr@cs.glasgow.ac.uk (Fraser Orr)
Newsgroups: comp.lang.forth
Subject: Re: Forth "Pre-Compiler"
Message-ID: <1557@crete.cs.glasgow.ac.uk>
Date: 2 Aug 88 12:02:34 GMT
References: <8807221513.AA05347@jade.berkeley.edu> <3d7612e1.13370@dow4.engin.umich.edu> <1533@crete.cs.glasgow.ac.uk> <5703@batcomputer.tn.cornell.edu>
Reply-To: orr@cs.glasgow.ac.uk (Fraser Orr)
Organization: Comp Sci, Glasgow Univ, Scotland
Lines: 121

In article <5703@batcomputer.tn.cornell.edu> olson@tcgould.tn.cornell.edu (olson) writes:
>I was going to let this slide, but given the tone of this posting and the
>next posting (about the Novix chip) by Mr Orr ...
>Mr Orr,
>  Don't you think you are being just a little too viscous?
>  Disagreement is wonderful, but only if all participants refrain
>from attacking each other. (Another "wonderful" "American" discovery)

My appoligies if you found my remarks offensive Mr Olsen. To be honest
I expected an erudite net'er like yourself to be able to recognise
good humoured sarcasm when you saw it.

>>adviasiable to THINK before you code!
>
>  This is always good advice.  But my experience suggests that before you
>can think you have to have some experience.  If you knew nothing about sorting

True.

>can think you have to have some experience.  If you knew nothing about sorting
>how do you know what to think about?  

If you knew nothing about sorting, then you wouldn't be writting
code for it. At the very least you must know the pre and post conditions
(otherwise you haven't done your system analysis properly.)

>My approach would be to try anything...
>with the understanding that it will probably be wrong/bad/etc
>and see what happens.  Then maybe try something else.  
>Then THINK.  and then try some more.  then THINK.   etc...
>(though you might try thinking a bit first also ..)

My approach is, 
  1) think about the problem 
  2) think of any similar algoritims previously seen
     (hence the need for experience and books of algorithims)
  3) if there is a similar algorithim modify and goto 5
  4) code the algorithim in the simplest way possible (with regard
     to your experience of course)
  5) finish the program.
  6) if there is strong evidence that the algorithim is a cause of
     performance problems (i.e., evidence from an execution profile
     of a REAL run, with REAL data) then maybe think about
     another algoritim (i.e., goto 1, with step 4 modified to
     "code the algorithim in as simple a way as possible, with the
     following constraints ...")
Yes I agree that empirical studies are a good idea, but leave them
till the end! Why spend hours fine tuning an algorithim that is
only used twice?
The most important thing we have learned from the study of program
design is -keep your mind focused on the problem, NOT the program.

>
>Maybe you meant "before you write the final production version, THINK"
>to which I would insert, "and explore empirically'.
>

Yes, if necessary.

>Thus one might argue that the advantage to forth is that it lets you
>move from thinking to thinking and experimenting.

This is the crux of the matter, can you justify this statment.

>>>(one class project), I started to think (and dream) in Forth.  (I was under
>>                                   ^^^^^^^^^^^^^^^^
>>My deepest commiserations, you poor backward boy!
>(was there supposed to be a :-) after this?)

Good guess :-)

>Mr Orr, may I ask you to really THINK about the following question.
>How would you compute if the process of calling proceedures had zero overhead?

Are you trying to say forth has zero overhead for calling procedures?
Am I completely missing your point here?

>You might be interested to know that Postscript is very forth like.

Yes I am aware of this. Interestingly as I mentioned before I have
written a preprocessor for PostScript that gives some reasonable syntax
to it. It has consequently become quite a nice language to use. I am
sad that you are all missing out on this because Forth'ers seem
unwilling to use anything but reverse polish notation.

>And that in some sense the Unix "philosophy" is very forth like.

Justification?

>In a subsequent posting Mr Orr made, in a bitting way some observations
>on the Novix forth chip relative to other chips.
>
>One point, the Novix chip does what it does in of order 10,000gates
>other chips that it is compareable to use order 100,000gates
>(i think these # are correct)
>Certainly food for thought.
>
[Other interesting stuff on Forth chips deleted]

I don't think this is a fair representation of my comments at all.
My posting merely asked for any experimental results comparing
Forth chips (like Novix) to essentially C chips (like 68000).
Subsequent communications have indicated that "The Novix chip 
leaves a 68000 coughing in the dust and takes far less silicon."
I accept this without further qualification.

I feel that gorups like comp.lang.forth can become very narrow minded
(the group has a very narrow set of discussion topics, I'm not trying to
suggest that the participants are narrow minded of course!) It is good
to discuss the things that other people are doing, in a way that is
relevant to your subject of interest. As I mentioned previously I have
never understood why Forth'ers are not prepared to use parsers so that
their code is more readable. Lets see what we can learn form each other
instead of indulging in mindless "I think my language is better than yours"
wars. I accept that Forth is fast on Forth chips, I also assert that
C or Pascal are easier to program in. What can I learn from you,  
and what can you learn from me?

==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