Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ecsvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!mcnc!ecsvax!dgary
From: dgary@ecsvax.UUCP
Newsgroups: net.lang.c
Subject: Re: FORTH, PASCAL, and C--- which one w
Message-ID: <1047@ecsvax.UUCP>
Date: Thu, 9-Jan-86 10:23:07 EST
Article-I.D.: ecsvax.1047
Posted: Thu Jan  9 10:23:07 1986
Date-Received: Sat, 11-Jan-86 07:27:06 EST
References: <1191@princeton.UUCP> <2600032@ccvaxa>
Reply-To: dgary@ecsvax.UUCP (D Gary Grady)
Organization: Duke U Comp Ctr
Lines: 22
Keywords: Forth, APL
Summary: "ideal" development system

Let me jump into this fray with an observation on my biggest
disappointment with Forth:  Unless you use bottom-up development you
have to write in an edit-compile-run fashion, just as in other
languages.  This is because if A calls B you have to define B before A,
and if you later redefine B, A still calls the old version.

APL (and LOGO and a few non-standard Forths) offer a much nicer
approach.  You can write B as a stub routine and redifine it later.
Routine A always calls the latest version of B.  This is the way an
interpretive environment should work!

I became a fanatical convert to this point of view when (many years ago
when I had time for such things) I wrote an adventure game development
system in APL.  I could build a few rooms, meander around in them
awhile, add a few more, toss in a few new verbs and objects, and so on,
all very interactively and with absolutely no waiting for the computer
to do anything.  Programmer heaven!
-- 
D Gary Grady
Duke U Comp Center, Durham, NC  27706
(919) 684-3695
USENET:  {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary