landon@Apple.COM (Landon Dyer) (07/20/89)
This is gonna be kind of inflammatory ... you can flame me back, but I've been down in the coding pits with FORTH afficionados a couple of times, and it was NOT pretty. All I can say is, don't take this personally. | Forth isn't getting creamed in the marketplace because of hardware | problems. It's getting creamed because (a) nobody is training | Forth programmers to any significant extent, and (b) the lack | of standardized libraries and usage across different Forth | implementations causes continuous reinvention of wheels; forward | progress is slow in the community sense. I'll sure agree with (a). I've known half a dozen or so FORTH programmers who thought they were any good in the language. Only one of them wrote code I could read; the rest were so caught-up in language features that they forgot to write good programs. Instead they wrote ugly, unmaintainable things that we generally threw away at the first opportunity, or simply ignored. FORTH is also getting creamed in the marketplace because of the snake-oil attitude of some of its proponents. The FORTHies I've encountered tend to push it as totally nifty for doing anything you could imagine. But they turn peculiar colors when I've asked them what products they've SOLD. I'm not bashing FORTH itself here -- I *have* seen some pretty nifty and responsible applications of the language, but they always involved doing customized enviroments to handle the very specific requirements of a small user community. I think those enviroments were just SUPER and that no other language would have done the job as effectively, but that does NOT mean that FORTH will solve everything. I'd like to see fewer claims along the lines of "It's a great floorwax, so it must also be a great toothpaste!" and more stories like "I successfully used FORTH to do an important project X," optionally ending with, "I also made a million bucks doing it," or "... and thus I saved my company's bacon." I'm sick of smug, mindless drivel about nifty language features, the implication being that other languages (and a lot of damn fine language people) lack some divine spark and that FORTH is going to take over the world Real Soon Now. Right. So what have YOU successfully used FORTH for? ---- Landon Dyer, Apple Computer, Inc. "C++ is the FORTH of the 1990s; Development Systems Group (MPW) they don't call it 'Uh-oh' Everything I said here is utter nonsense. programming for nothing!"
RAYBRO%UTRC@utrcgw.utc.COM ("William R Brohinsky", ay) (07/20/89)
To Landon Dyer's remarks about forth as "it must also be a great toothpaste..." I must applaud and simultaneously place a restraining metacarpal. First off, I do not (yet) write things that get sold, certainly not in enough copies to earn millions of bucks off it. I do write things that I could not write with out forth, and then maintain them for years, sometimes with four year gaps in between. I write code I can read and explain to my BASIC-only scientist. I insist that they be fully documented, which annoys him, since he is used to writing in TRS-80/Model 100 basic, where multiple-statement lines with no comments and multiple-statement if-then-elses make code that is terse, compact, efficient, and totally unreadable. So that particular problem is not limited to forth (I've seen equally unreadable/maintainable forth, basic, C, fortran, and perfectly readable programs in Cobol,APL,LISP,and Pascal, or so I'm told, that I couldn't even begin to read. I think all programmers use the languages they use because they understand them in a way that is hard to rationalize...) Secondly, I must say that in the few months that I have been getting mailings from the FIG-L and in the years past that I've spent time on the East Coast Forth Board, I've seen very little of the "it is a great floor wax..." kind of marketing. Lots of it for Pascal, C, and the newer basics. Mostly, I see forthers remarking on how good forth is for control applications, how much easier it is to debug in an interpretive language and how nice it is that it also compiles so that you can debug at speed, and things like that. I also (is this a thirdly, or a zerothly?) must agree that there are not enough educational-system opportunities to assist young programmers in learn- ing FORTH. What else is new? Forth was invented/developed/grown by one man who chose to turn the body and embodiment of his fruits over to the public domain. His reasons for doing it were simple, as he states it. He wanted to write more code than 100 fully-debugged/maintained lines per year over his lifetime. He figured that others would, too. But this sort of distribution does not grow the kind of college-level support that giving product to colleges for reduced price or free can. (I know of a college whose holography lab uses Data Trans- lation data acquisition products exclusively, cause they got them near-free, and now bends experimental method to work within their limitations. It happens, and will continue to.) However, if you wish to have formal teaching in one type of forth which has similar (you almost might say portable) implementations accross many platforms, try Forth Inc.! They have lots of classes, and their prices are competitive with C courses I have seen advertised. Their PolyForth implementations are in the 2 to 5 thousand dollar range, each, though. Hey!--does this qualify as something written in forth that made a lot of money?? -raybro Sorry for the long paragraphs and typographic ugliness- this was off the cuff. I promise to pre-edit my messages in future, unless I forget...
marc@noe.UUCP (Marc de Groot) (07/21/89)
In article <33300@apple.Apple.COM> landon@Apple.COM (Landon Dyer) writes: >So what have YOU successfully used FORTH for? I was the technical brains behind the use of Forth at Unison World, Inc. in Berkeley. We developed and sold video games for the Japanese market. That was 1982, and the hardware platforms were mostly Z80's and CP/M. We wrote and sold about twenty games in the first year, one per programmer. I told the owner that minimum time-to-market was an important goal for us and Forth suited that goal admirably. After some successful games had been written we ported our Forth system to the 6809 and 8086 and put the games right on top. After that I went to a company in Berkeley where I brought in Forth to do the software for a high-end paint box. Forth is still being used by the descendent of that company to do diagnostics and software prototyping. I wrote a compiler for a computer language which produced computer-aided tutorials. I ported the compiler from CP/M to the Apple ][ in one weekend. The other bidder on the project was STILL waiting for his back-ordered C compiler to arrive via Fed Ex by the time I finished the project. I used Forth to write an interactive real-time music editor based around the Roland Compumusic CMU-800. I custom-wired the Apple ][ interface card into my S-100 system. I have written pattern-recognition software in Forth on small systems. Back at a time when interactive debuggers were not available for C, Forth was the ONLY choice. Most programs produce output that is either obviously flawed or not. Some programs, such as my pattern recognition and prediction program, may work "part-way" even though there is an error in coding. The project wouldn't have gotten done if I hadn't had a way to customize the behavior of my software AND MY DEBUGGER on the fly. My most recent success with Forth was as a contract programmer. I worked at a company which produces mass spectrometers. The data acquisition system for the machine was written in Forth. Statistical analyses and matching against a large substance database were parts of the package. Full windowing/ mouse interface software was used. There was 14 megabytes of source, written over six years time by both long-term employees and short-term contractors. It was READABLE. There were comments on every line. The package performed as well or better than other packages written in C or Fortran for other product lines at the company. And here's the kicker: An end-user interface was provided so that the scientists in the field could write their own Forth programs to customize the mass spectrometer. The product has been enthusiastically accepted by their customers! -- Marc de Groot (KG6KF) These ARE my employer's opinions! Noe Systems, San Francisco UUCP: uunet!hoptoad!noe!marc Internet: marc@kg6kf.AMPR.ORG
dunn@uhccux.uhcc.hawaii.edu (John Dunn) (07/21/89)
>This is gonna be kind of inflammatory ... you can flame me back, but I've > >I'd like to see fewer claims along the lines of "It's a great floorwax, so >it must also be a great toothpaste!" and more stories like "I successfully >used FORTH to do an important project X," optionally ending with, "I also >made a million bucks doing it," or "... and thus I saved my company's >bacon." > >So what have YOU successfully used FORTH for? > Well, I wrote a paint package called "Lumena" and founded a company called Time Arts Inc. on the product, and indeed have made several million. (to the IRS: it was folded back into the company, I still have holes in my socks!). I normally don't get on soapboxes, especially on religious issues. To me the proper way to decide what language to use is to decide what kind of project you will be doing with it. Each has its advantages, and none is inherently *better*. But a few words about why I prefer to program in forth might be useful to others. My main area of interest is real-time use of pc's for art applications, including music (I wrote MusicBox, which was reviewed in July's KEYBOARD in 8086 assembley because I needed maximum speed). What I have known from the beginning, and have seen verified many times is that getting the computer to do the tasks I want is the *easy* part. The hard part, the real art of programming, is in writing the interfact between the computer and the artists. Artists work in intuitive, right-brain space. While doing art, it is an imposition to ask them to go into verbal, left- brain mode to pick the next tool, do the next manipulation, etc. This is where FORTH really shines. You can write the basic interface as you (in left-brain space) think it should work. Then keep changing it on the fly until it has the right artistic *feel*. Programming in C or any of the other compiled languages simply does not allow the tight programming-testing loop FORTH gives. I've tried them all, including Turbo-C. The only thing that comes close is LISP, which is also incrementally compiled (or can be), but is too machine-intensive to produce applications on a PC. My rule of thumb is, if the user interface is a large part of what the program is about, program in FORTH. Otherwise a programmer-friendly language such as C would be preferable for portability reasons, and because FORTH tends to be difficult for a project group of more than 2 people to deal with. Often it is a good idea to put FORTH interface code on top of C application code. --John Dunn
LEFF@PITTVMS.BITNET (07/22/89)
There was a recent suggestion that FORTH is too limited to produce successful (i.e. profitable applications)?! Here's one: ALLEGHENY SOFTWARE WORKS (p.o. box 7103. Pgh., Pa. 15213) has a very popular and sophisticated VT100/VT102/VT52 terminal emulator for the Commodore 64 computer written in FORTH. It is the only full featured emulator of its kind for the C64--probably because the speed and efficiency of FORTH were necessary for its development. I helped to write this program, and know it's been very profitable for ASW.
rosenber@ra.abo.fi (Robin Rosenberg INF) (07/22/89)
In article <33300@apple.Apple.COM>, landon@Apple.COM (Landon Dyer) writes: > > I'll sure agree with (a). I've known half a dozen or so FORTH programmers > who thought they were any good in the language. Only one of them wrote code > I could read; the rest were so caught-up in language features that they > forgot to write good programs. Instead they wrote ugly, unmaintainable > things that we generally threw away at the first opportunity, or simply > ignored. It's too much fun to write nifty features, and takes too much time especially when one could do well without them. > I'd like to see fewer claims along the lines of "It's a great floorwax, so > it must also be a great toothpaste!" and more stories like "I successfully > used FORTH to do an important project X," optionally ending with, "I also > made a million bucks doing it," or "... and thus I saved my company's > bacon." I know of a company that made a lot of bucks on a FORTH program. The program was an advanced (at that time) three-dimensional spread sheet. Ever hear of Calc Result for the C64, PET and IBM PC?. They also wrote a word processor in Forth called Word Result. They got a swedish "export award" two years in a row due to these programs. It is a long time since I heard of any software from the same company so I don't know if they produce software at all nowadays. Also, a Finnish ship yard is using Forth for programming marine equipment. > I'm sick of smug, mindless drivel about nifty language features, the > implication being that other languages (and a lot of damn fine language > people) lack some divine spark and that FORTH is going to take over the > world Real Soon Now. Right. No I don't think Forth is going to take over the world. Forth is too hard to learn. The syntax is easy, but thinking Forth is harder. And one also must remember that ones major task is not to invent langauge features unless one NEEDs them. > So what have YOU successfully used FORTH for? ME?. A word processor but I never even attempted to sell it, so that does not count. But it *was* easy to write. So am I going to use Forth? Maybe. I got JForth and it has the wheels so I don't have to invent them. On the other hand I have a C compiler with a source level debugger. Forth has some real stiff competition I would say. ---------- Robin Rosenberg
sabbagh@acf3.NYU.EDU (sabbagh) (07/23/89)
In article <4391@uhccux.uhcc.hawaii.edu> dunn@uhccux.UUCP (John Dunn) writes: >My rule of thumb is, if the user interface is a large part of what the >program is about, program in FORTH. Otherwise a programmer-friendly >language such as C would be preferable for portability reasons, and >because FORTH tends to be difficult for a project group of more than >2 people to deal with. Often it is a good idea to put FORTH interface >code on top of C application code. > Since I kind of started this, I should add my $0.02. I believe that this is the REAL advantage of FORTH -- in implementing systems that are user-interface intensive. It may seem that FORTHs usage in device controllers contradicts this, but it really supports this viewpoint! After all, the reason FORTH is so big in this area is not because it has any different ways of communicating via serial and parallel ports, but because the programmers/scientists/users trying to get data from their equipment can get their hands on it in FORTH better than any other lang- uage. I am happy to hear about non-hardware oriented applications. If FORTH is really going to take its rightful place as a seminal language in Computer Science (next to LISP, FORTRAN, and ALGOL-60) more programmers and software designers must be committed to using it. This means that some real attention should be paid (are you listening, standards committee?) on getting FORTH to exploit features of newer conventional hardware, e.g., 80386/68030/RISC that is being used on conventional machines, e.g., OS/2, Macintosh, Sun, etc. FORTH-based hardware is pretty exciting stuff, but it will either be found in embedded systems or somebody has to build a general-purpose workstation/PC machine. I am now donning my asbestos suit ;^). I await the flames... Hadil G. Sabbagh E-mail: sabbagh@csd27.nyu.edu Voice: (212) 998-3285 Snail: Courant Institute of Math. Sci. 251 Mercer St. New York,NY 10012 186,282 miles per second -- it's not just a good idea, it's the law!
jax@well.UUCP (Jack J. Woehr) (07/23/89)
At Vesta Technology, Inc., we manufacture single board computers
with ROMmed 83-STANDARD on board featuring host disking and ROMmable
autoboot overlays. Our customers include Chrysler, NOAA, IBM and other
Fortune-500 and gov't. orgs., along with a slew of garage enterprises
and hopeful robotocists and inventors!
We also do custom hardware design and custom programming.
Besides the tremendous success of our line of off-the-shelf
easy-to-program SBC's, our custom software development business has
grown by leaps and bounds.
Year-to-date this five-year-old startup enterprise has billed
over $150,000 in custom Forth projects.
Incidentally, our latest largish project involved distributed
processing on four SBC's. Three were programmed in Forth, one in C/ASM.
Guess which three were finished ahead of deadline? Guess which one
we are drumming our fingers while waiting for?
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}
{} {}
{} jax@well ." Sysop, Realtime Control and Forth Board" FIG {}
{} jax@chariot ." (303) 278-0364 3/12/2400 8-n-1 24 hrs." Chapter {}
{} JAX on GEnie ." Tell them JAX sent you!" Coordinator {}
{} {}
{} "If Rat cannot flee fast enough, then let him make way for Tortoise!" {}
{} - Chinua Achebe, _Arrow of God_ Doubleday 1969 {}
{} {}
{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}a342@mindlink.UUCP (John McKechnie) (07/23/89)
I also hear that a certain 123 lookalike was written in Forth. I know of several programs in the TI-99/4A software market (yes there is such an animal - STILL!) written in Forth, which are very successful. I'm looking at writing a BBS in TI Forth, with only very time-critical stuff in assembly. With only 48K to work with, it will be almost as fast as assembly, be maintainable by end users, (which my current all assembly program isn't) and will be modular, something that Forth allows with ease. John McKechnie
andrew@idacom.UUCP (Andrew Scott) (07/29/89)
In article <33300@apple.Apple.COM>, landon@Apple.COM (Landon Dyer) writes: > FORTH is also getting creamed in the marketplace because of the snake-oil > attitude of some of its proponents. > I'm sick of smug, mindless drivel about nifty language features, the > implication being that other languages (and a lot of damn fine language > people) lack some divine spark and that FORTH is going to take over the > world Real Soon Now. Right. I agree, but in deference to Forth programmers, I think they (we?) have developed a complex from the continual bashing the language receives from programmers who don't use the language as it was intended to be used. It is not another Algol/Pascal/C style of language. Our experiences at IDACOM are that newcomers to Forth dislike it at first because they write code as a C programmer would, which doesn't work well for Forth. Words are not really equivalent to functions or subroutines found in procedural languages. We're not taught to factor to the extent that Forth demands. Large Forth words suffer from excessive stack manipu- lation words which lead to frustration with the language. They also can't be interactively debugged as easily. Other features, such as the ability to execute code at compile time, aren't really used because those kinds of things aren't available in the "blessed academic languages". Forth is supposedly easy to learn, but I think that the learning curve to "think Forth" is steep. Learning this language is not just a matter of learning the syntax, but also learning the style and methodology of using the language. -- Andrew Scott andrew@idacom - or - {att, watmath, ubc-cs}!alberta!idacom!andrew
ZMLEB@SCFVM.BITNET (Lee Brotzman) (07/30/89)
<ubc-cs!alberta!idacom!andrew@BEAVER.CS.WASHINGTON.EDU> writes: > >Forth is supposedly easy to learn, but I think that the learning curve to >"think Forth" is steep. Learning this language is not just a matter of >learning the syntax, but also learning the style and methodology of using >the language. >-- >Andrew Scott andrew@idacom > - or - {att, watmath, ubc-cs}!alberta!idacom!andrew I don't think that Forth is easy to learn. But, I think that time spent learning Forth is time well spent. The hard-won Forth mentalilty serves any programmer well in any language. I have used the techniques I gained from an intimate knowledge of Forth in other, "academically accepted", languages. The functions and procedures I write now in C, Pascal, and Rexx are more brief and semantically coherent. They are more easily tested because I try to test them immediately, i.e. instead of testing on the command line like I do in Forth, I write a quick driver program -- and because the procedures are more "Forth-like", the driver programs are easier to write. It isn't as fast or as convenient, but the tests are made in as Forth-like a setting as I can muster given the environment. This may be a harsh statement, but I still think that the only way that Forth can be truly appreciated is to write a Forth interpreter on you own. It isn't as hard as it sounds. The source code for many interpreters are publically available, and all that is needed is to adapt one to your own needs. Don't worry about standards (at least at first) and just plunge in and make a Forth that you like. As a first-year graduate with a Bachelors of Science degree in Astronomy minoring in Computer Science, I had all the expertise needed to create a Forth kernel and most of the high-level extensions to make a complete development environment. At its heart, Forth is extremely simple. In its soul, Forth is something that approaches enlightenment. With a small amount of knowledge about how computers work, and some assembly language programming, Forth is yours. Just remember that Forth is not hard, it is only different. Vive la differance. -- Lee Brotzman (FIGI-L Moderator) -- BITNET: ZMLEB@SCFVM -- Internet: zmleb@scfvm.gsfc.nasa.gov -- The government and my company don't know what I'm saying. -- Let's keep it that way.
nelson@udel.EDU (Mark Nelson) (08/01/89)
In article <8907300608.AA04417@jade.berkeley.edu> ZMLEB@SCFVM.BITNET (Lee Brotzman) writes: > > This may be a harsh statement, but I still think that the only way that >Forth can be truly appreciated is to write a Forth interpreter on you own. >It isn't as hard as it sounds. The source code for many interpreters are >publically available, and all that is needed is to adapt one to your own >needs. Don't worry about standards (at least at first) and just plunge in >and make a Forth that you like. I agree 100%. I was in high school when the Byte Forth issue came out (April, 1979 +-), back before Byte became another PC Rag. Four friends and I scraped up $20 (?) to buy a hard copy listing of the source for 6502 Fig-Forth from FIG. We typed it in page by page, writing our own I/O code for the school's Ohio Scientific micro. One of the first things I did was write a 6502 assembler (on four screens!). When I got to college, in order to learn PDP-10 assembler, I wrote my own Forth-like language totally from memory (no listings or documentation) for the school's DEC 20. This was in my spare time, first semester Freshman year. In retrospect, I made some questionable design decisions, e.g. packing addressed (18-bits) two to a (36-bit) word, but it worked fine, and it taught me quite a bit about the instruction set and system calls. I've since taken parsing and compiler courses, but I still feel like I know the guts of Forth better than any other language, with the nearest competitor being interpreted Lisp. Mark Nelson ...!rutgers!udel!nelson or nelson@udel.edu This function is occasionally useful as an argument to other functions that require functions as arguments. -- Guy Steele
koopman@a.gp.cs.cmu.edu (Philip Koopman) (08/05/89)
In article <8907300608.AA04417@jade.berkeley.edu>, ZMLEB@SCFVM.BITNET (Lee Brotzman) writes: > ... I have used the techniques I gained from > an intimate knowledge of Forth in other, "academically accepted", languages. > The functions and procedures I write now in C, Pascal, and Rexx are more > brief and semantically coherent. ... When I took a compiler design course, we had to write a "baby C" compiler in C without using LEX, YACC, etc. I think that my Forth programming experience helped me write much better C code. My code was done in fewer hours, and in fewer lines of code than any other projects in the course. It also had a whole lot more procedure calls than the others. A typical comment was: "that can't be all of it, it's not thick enough" when handing in a code listing. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior Scientist at Harris Semiconductor. I don't speak for them, and they don't speak for me.
andrew@idacom.UUCP (Andrew Scott) (08/07/89)
In article <8907300608.AA04417@jade.berkeley.edu>, ZMLEB@SCFVM.BITNET (Lee Brotzman) writes: > I don't think that Forth is easy to learn. But, I think that time spent > learning Forth is time well spent. The hard-won Forth mentalilty serves any > programmer well in any language. Agreed. I think Brodie's "Thinking Forth" is the best book about programming that I've ever read. The techniques learned apply to so much more than just the Forth language. > This may be a harsh statement, but I still think that the only way that > Forth can be truly appreciated is to write a Forth interpreter on you own. I agree on this count also. I recently wrote an optimized subroutine threaded Forth. Figuring out how to implement things like DOES> and [COMPILE] makes you appreciate how useful they can be. There's a bit of discovery involved - you don't consider words like those when solving problems if you've never seen anything like them before. Looking at each word in detail when porting or creating a new Forth results in a lot of fresh insight. -- Andrew Scott andrew@idacom - or - {att, watmath, ubc-cs}!alberta!idacom!andrew
trolfs@vax1.tcd.ie (Tommy) (08/08/89)
In article <711@idacom.UUCP>, andrew@idacom.UUCP (Andrew Scott) writes: > In article <8907300608.AA04417@jade.berkeley.edu>, ZMLEB@SCFVM.BITNET (Lee Brotzman) writes: >> I don't think that Forth is easy to learn. But, I think that time spent >> learning Forth is time well spent. The hard-won Forth mentalilty serves any >> programmer well in any language. > > Agreed. I think Brodie's "Thinking Forth" is the best book about programming > that I've ever read. The techniques learned apply to so much more than just > the Forth language. > IMHO, learning Forth is the same as learning to think. The benefits are felt not just in programming! The title, "Thinking Forth", says it all. A really brilliant book. >> This may be a harsh statement, but I still think that the only way that >> Forth can be truly appreciated is to write a Forth interpreter on you own. > > I agree on this count also. I recently wrote an optimized subroutine threaded > Forth. Figuring out how to implement things like DOES> and [COMPILE] makes you > appreciate how useful they can be. There's a bit of discovery involved - It's amazing how Forth encourages you look deep into its workings, while most languages do their best to keep you at arms length. I remember the day that I made a WORD to decompile other Forth WORDS. Up to this point I had no books on Forth nor people whom to ask questions, all I did have was a disassembler and the word DUMP. This new word let me strip bare all the words which before were a mystery. I remember decompiling the INTERPRETER and think "AH! That's how Forth works!". I think it was the closest I'll ever get to a religous experience. I suppose that makes me born again :-) -- Tommy E-mail: trolfs@vax1.tcd.ie // Amiga 500. \\// What's your's called? $P-) -----------------\X----------------------------------------------------- "Indecision is the basis of flexibility" -- button at a Science Fiction convention. "Old age and treachery will beat youth and skill every time." -- a coffee cup