crunch@well.UUCP (John Draper) (10/02/86)
A HYBRED DEVELOPMENT SYSTEM
---------------------------
How many times have you wanted an interactive development system for
testing functions without having to compile and debug an elaborate test
program to run certain functions through their paces, or wait HOURS for
large programs to compile and link.
I am thinking of a hybred of C and FORTH. It is NOT the scope of
this posting to argue which language is BETTER, but to point out an
idea, and open for discussion, a different approach to software
development, taking advantage of the strong points of each language.
Each language has it's advantages and disadvantages. For instance,
C's strong point is it's "modularity" and speed. C's dis-advantage is
that it's not "interactive" and discourages the "Lets try this!!!"
attitude. This makes testing functions more difficult. FORTH, on
the other hand, is interactive. No waits for long compiles. A function
can IMMEDIATELY be tested. Then it can be combined with very little
effort in many different ways with other functions. FORTH is very weak
in readability, and not very good when lots of people are working on
one program. FORTH isn't as STANDARD as C. As far as I know, there
is NO standard in FORTH for simple disk reads or strings.
My proposal is to combine them. It isn't that hard to do, although
it isn't trivial either. Here is how I would combine them.
Lets suppose I need to write an application that might have to undergo
lots of changes. I would initially write the outer shell in a forth
environment. I could change it easily, and very quickly be able to
"generate" many different versions of the program quickly. For the
Amiga, I could let Forth handle all the mundane tasks of opening up
libraries, screens, windows etc. All those nasty structure
initializations go away (At least for now).
As we get into the nitty gritty details of our program, we would
implement all the gory math details in C. Thus, we would not have to
deal with ROT SWAP 4 PICK 3+ OVER + SWAP DO GROG LOOP and all that
other un-readable gobblygook. At least the C "purists" think so.
After the C routines have been compiled into their respective .o files,
we use FORTH as a linker to add them to the "dictionary" and interactivly
"play" with the functions, combine them in many clever ways, using FORTH
as a SHELL for testing and handling all the outer-level tasks. If another
C function is needed, just "flip" over to another window, edit and
and compile the C file. Then flip over to the FORTH window and "include"
the .o file to test it. NO LINKING.
FEATURES OF THE HYBRED SYSTEM
-----------------------------
-- Be able to save a FORTH module as a LIBRARY and link it into a C
program which can call the forth functions.
-- Be able to "include" one or more object module from a C program, and
ADD it to the FORTH dictionary so that the C functions can be
interactivly called or tested.
WHAT IT WOULD TAKE TO HAVE ONE
------------------------------
-- A Fast FORTH system using the same stack usage as C.
-- Knowledge of the .o file format for Manx or Lattice.
I am currently beta testing Jforth from Delta Research which shows
the most promise as being the likely choice. It does the TRUE SIEVE
in 9 seconds on the Amiga (About the same as C). It also has a clean
link to the Amiga Library functions. The people at Delta Research
will probably be setting the C interface as a high priority after it's
released in a month or so. The FIRST C compiler manufacturer that
is willing to release the .o file format will be chosen for the test.
I would like to gather comments from everyone on what they think about
this approach to software development, and what other improvements can
be made.
John Draper
WELL: crunch
BIX: crunch
CIS: 76703,4322
UUCP: ihnp4!acad!well!crunchkearns@garfield.columbia.edu (Steve Kearns) (10/02/86)
What you REALLY want is the equivalent of Lightspeed C or Lightspeed Pascal, which currently run only on the Macintosh. These supply an integrated environment and lightning fast compilation. LSPascal lets you evaluate variables and functions and break at any time. -steve
daveh@cbmvax.cbm.UUCP (Dave Haynie) (10/04/86)
> > > A HYBRED DEVELOPMENT SYSTEM > --------------------------- > I am thinking of a hybred of C and FORTH. It is NOT the scope of > this posting to argue which language is BETTER, but to point out an > idea, and open for discussion, a different approach to software > development, taking advantage of the strong points of each language. Another idea along these lines is a C interpreter. Never used one myself, but I see all kind of them advertised for the PC[lone] family. The speed wouldn't be that much of an issue (certainly slower than a TIL like Forth), its basically a development tool. If you can use the object modules from "debugged" code in it, perhaps inhereting symbolic info like a debugger would, this might be the ultimate solution. I've written lots of code in the traditionally interpreted LISP language, and just the fact that the thing's interpreted dramatically increases the debugging time, and probably results in better though out code. Which is why, I guess, Leo Brody claims that Forth programmers write every program twice. > -- Knowledge of the .o file format for Manx or Lattice. Lattice uses the standard ALink object format, which is cryptically described in the AmigaDOS Technical Reference Guide, I believe (or one of the AmigaDOS books, which are typically much less informative than the RKM series <flames magically appear>). Some of the programming I've done under VAX/VMS got me used to the idea that everything should have a standard object format (one application I worked with linked BLISS, Fortran, Pascal, ISPS, and Assembler modulse together). If a standard object module exists, an interpreter could conceivably access these objects as you mentioned. As for choosing Forth, the idea sounds interesting too; a Forth kernal would only take up a few K, just about everything's stack allocated and thus reentrant, and it can approach the speed of traditionally compiled code while at the same time tending to produce smaller (if not faster) final output than assembled code. How about a forth.library? > John Draper > WELL: crunch > BIX: crunch > CIS: 76703,4322 > UUCP: ihnp4!acad!well!crunch -- ============================================================================ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh These opinions are my own, though if you try them out, and decide that you really like them, a small donation would be appreciated.