Article: 23775 of comp.lang.forth Path: news.tuwien.ac.at!03-newsfeed.univie.ac.at!01-newsfeed.univie.ac.at!Austria.EU.net!EU.net!enews.sgi.com!news.mathworks.com!nntp.primenet.com!winternet.com!clio.trends.ca!worldlinx.com!news.bellglobal.com!news From: Brad Rodriguez Newsgroups: comp.lang.forth Subject: Re: Hang on, isn't Forth out of date now? Date: Sat, 10 Aug 1996 04:39:02 -0700 Organization: Bell Global Solutions Lines: 67 Message-ID: <320C74D6.7BEA@headwaters.com> References: NNTP-Posting-Host: remote_114.headwaters.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) Andy, thanks for the provocative question. It's helped me compose my thoughts for a flyer I'm writing. No, Forth isn't out of date. Forth is still great because of the following benefits: 1. It is simple to build from the bottom up. 2. You can get an _application_ to run in a miniscule amount of RAM. 3. You can try things out in real time as you build your system. 4. Compared to any other interpreted language, it is fast. Allow me to elaborate: 1. Forth remains one of the few environments which is totally comprehensible by one person. This is a big plus when you're working in safety-critical systems, or whenever you need to verify program correctness. 2. Forth does indeed make "the best out of a slow microprocessor with little RAM." Such processors are more common than PCs -- they're called embedded systems. It will be a long time before your car's fuel- injection system has 16 MB and a 1.25 GB hard disk. (And most embedded processors are NOT supported by Borland C++.) 3. There is simply NO substitute for an interactive interpreter when debugging. Even an edit-compile-test cycle of 5 seconds feels clumsy, after you're used to testing any subroutine by typing its name. Can your debugger let you manually try different input parameters? (My Borland compiler can't.) And you should try a modern interactive Forth to learn how easy it makes testing embedded hardware! I've yet to meet the in-circuit emulator that lets me exercise I/O as easily as a few simple lines of Forth code. (Or lets me test multiprocessors or distributed systems at all!) 4. Forth is still fast. Modern compilers produce code as good as any other language -- not all Forths use threaded code! (I could relate a horror story I heard about an engine control system written in C++.) Forth is certainly the fastest interpretive language around; and besides the debugging advantage, I've found interpretive Forth to be superior for incremental development. However, I have other reasons for using Forth: 5. Forth is _extensible_. This means that if the language does not support some feature or capability you need, you can add it...not as a subroutine package, but as part of the language itself. Can you imagine writing object-oriented code, if every reference to an object had to be through a function call? That's how I feel about other languages' implementations of multitasking, multiprocessing, and networking. Only in Forth can these be truly transparent. 6. Forth lets me work at a high level of _abstraction_. Between language extension and "active" data structures, when I write a Forth application, I am really writing in the language of the application -- not the language of the compiler. This makes the program easier for a newcomer to read, and easier to maintain. Like most programmers, my choice of language is based on personal preference. I find that I think more clearly in Forth, and from past experience I estimate I'm 5 to 10 times more productive in Forth than in C. Others may not share this preference or facility. Forth may not be your preference, but it's certainly "relevant" -- now more than ever. -- Brad Rodriguez bj@forth.org Computers on the Small Scale This brain for rent! See http://www.forth.org/fig/homes/brodriguez.html Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj Director, Forth Interest Group........... http://www.forth.org/fig.html