Path: utzoo!attcan!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Forth in the Marketplace
Message-ID: <1415.UUL1.3#5129@willett.UUCP>
Date: 28 Jul 90 23:32:29 GMT
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 75


 Date: 07-27-90 (03:40)              Number: 3572 (Echo)
   To: W.BADEN1 [WIL]                Refer#: 3558
 From: GENE LEFAVE                     Read: NO
 Subj: PUZZLES AND PROBLEMS          Status: PUBLIC MESSAGE

 WW>Every language has areas of application in which it is superior, even
 WW>Basic, Cobol, and Ada.  I'm trying to discover just what is Forth's 
 WW>domain of

 I can't resist getting into this discussion, so here goes.

 I find FORTH to be excellent in small companies or departments where pro-
 grams are developed by a couple of programmers or software engineers on 
 tight schedules.  Granted, it's not that great for algebraic stuff, but that
 is such a small percentage of anything I've done it's irrelavant.  The 
 program where I needed to do an FFT was just 3 blocks out of 200 or so.

 FORTH allows blocks of code to be easily reused.  It allows an easy 
 division of labor.  I've found that it is fairly easy to read given shadow
 blocks.  We brought in a summer student.  After two weeks he was 
 working on device drivers and terminal emulators.  He had worked with FORTH
 on an old S-100 sytem before, and had no problem learning polyFORTH and 
 brought up an 8 channel intelligent communications board driver.   I've had
 clients bring in consultants who were able to work with our program after a
 couple of days, and produce custom reports for them.   

 FORTH is excellent in applications that requires an interpretter.  In my 
 application that does page composition I use essentially three nested 
 interpretters.  The outer one gets data, a second one interprets the page 
 formats, and the final one interprets embedded typesetting commands and puts
 the letters on the page.

 FORTH, once extended with about 200 block buffers, makes a good database 
 language.  Since data resides in the block buffers and isn't being shuffled 
 around all the time, my response time is generally an order of magnitude 
 better then database languages on similar equipment.  FORTH allows the fact 
 that one is working with addresses to be easily hidden.  So most of our work
 is actually done directly in the block buffers rather then in record buffers.

 The block interface to data files has proven extremely reliable, especially 
 under DOS.  This is because we allocate blocks in batches of 100K at a time,
 then close and reopen the file, forcing DOS to update it's directory.
 Therfore, very little changing to the FAT table.  No changes to FAT 
 means fewer DOS problems.

 Our product is very much like a 4GL.  Blocks are loaded that provide high 
 level descriptions of reports.  These descriptions then control the loading 
 of the words needed to actually generate the report.   Finally, we can 
 add a custom layer, which redefines our standard words for unigue require-
 ments. We can out bid any of our competitors that use standard database
 products when custom changes are required, because all we do is modify the 
 "custom" blocks for that customer.  No time consuming compiles, and NO 
 changes to the standard "core" of the application.  We don't have to build 
 in "hooks" and predict in advance what will need to be customized.

 I find that the block interface to DOS makes polyFORTH especially good at 
 handling file conversions.  Open up a file of blocks.  Read it with a 
 special interpretter, ie DBASE, WORD, etc.  Spit stuff out to DOS.  I've 
 spent nearly $1000.00 on data conversion programs, I've found its always 
 faster using FORTH.

 In general, I've found  FORTH is appropriate for any dedicated application.
 That is, those applications that are running 99% of the time.  It's fast, it
 allows you to bid minimum equipment, (at maximum profit), and it lets you 
 quickly add the custom stuff with a minimum of fuss.  And the fact that you
 can call in on a modem, and interactively, in real time, work out a problem
 is icing on the cake.

 I just hope my competitors don't find out.
 ---
  ~ EZ-Reader 1.13 ~ 
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu