Forth Application Techniques 260
| Forth Application Techniques | |
| author | Elizabeth D. Rather |
| pages | 148 |
| publisher | Forth, Inc. |
| rating | 5 |
| reviewer | oxgoad |
| ISBN | 0966215613 |
| summary | A concise introduction to the Forth programming language. |
Who & What
Elizabeth D. Rather, president of Forth, Inc., would appear to be the second Forth programmer in the universe. This distinction came about in 1971 when she was brought in at the Kitt Peak NRAO to maintain code written in a quirky language developed by Chuck Moore. Running on a DDP-116 and a H316, this code was responsible for controlling the telescope, data acquisition, and graphical display. After a few years, Moore and Rather, along with Edward K. Conklin, formed Forth, Inc. to attempt commercialization of the language.
Forth Application Techniques attempts to provide a comprehensive introduction to the language for the neophyte Forth programmer. I would say that it pretty much succeeds as such, quietly plodding away through each primitive and feature. It is written in workbook style with various sample problems for the reader to complete. You might not be a Forth coder after reading the book cover to cover; however, you will have a working knowledge of the language and should be able to walk through legacy code with a minimum of difficulty.
If I might step aside from my role as unbiased book observer for a moment, I would like to make a few comments about the state of programming languages in general. It seems that quite often we take for granted essential, but practically invisible, tradesmen such as plumbers and garbage collectors. (Fire your janitor and your web designer -- guess which one you will miss first. Guess which one will still be employable 15 years from now.) Yet, without their services, our daily quality of life would certainly fail to meet our expectations.
Likewise, Forth seems to be an invisible language. No flash, no e-commerce, and no glamour. Such is the nature of embedded systems -- even though every Federal Express delivery driver carries a Forth-based device on his belt. This appears to have resulted in a dearth of quality books dealing with Forth. Search your favorite online book retailer and note the dozens of Forth books that are no longer in print.
While Scheme is from the ivory tower and Forth might be said to be from the machine shop, they do have something in common that is a possible deterrent to the popularity of Forth. Like Scheme, you either get Forth -- or you don't. Stack-based languages leave some programmers dazed and confused. And, as with most languages, it is possible to write some truly obfuscated code. Any language that will allow you to define the number 4 as a word that places the number 3 on the stack can be a frightening weapon in the hands of the contrary.
Kudos
Forth Application Techniques can be commended on its consistency. Careful attention has been given to typefaces to distinguish interpreter output from user input. All primitives and defined words are covered in a clear and unambiguous manner. The book is spiral bound in a plastic binding, and this lay-flat binding is great when using it at your computer or while eating lunch.
Quibbles
The same lay-flat spiral binding that is such a boon when working at the computer can be somewhat of a nuisance when when attempting to hand-hold the book -- the book tends to flop about and feels very insubstantial.
While Forth Application Techniques is very complete and accurate, it is also extremely passionless. You might compare it to a biology textbook discussion of sexual reproduction with no mention of romance. There is no discussion or examples of using Forth in ways that will bring enlightenment. To be fair, in the preface it states that the purpose of the book is to support Forth classes taught at Forth, Inc. This is something that is not entirely clear when examining online retailers' display of the book.
Also of note is that there are occasional features specific to Forth Inc.'s SwiftForth product documented in the book. I would not consider this a real issue as all instances are clearly denoted with an icon. With the exception of chapter 9, which is entirely Forth Inc. specific, the readability is not affected in any way.
Crimes
Forth Application Techniques has no index. With its workbook styling, most will not consider this to be a tragedy. All the same, it would be convenient to look up primitives and defined words.
Conclusions
Should you buy this book? That depends on your desired end result. It is adequate for a quick introduction to Forth. If you are intending to write production code I believe Forth Programmer's Handbook (from the same publisher, review forthcoming) would be a better choice. If possible, I would supplement either with a used copy of Leo Brodie's Starting Forth -- an out-of-print classic.
Where I foresee this book to be a great benefit is in ordering a half-dozen copies for your programming team prior to taking on a legacy project or when considering Forth as a new development platform. The members of your team that "get it" can then enlighten the others with this invisible language.
Table of Contents
- Preface: About This Book
- Introduction
- Simple Forth Primitives
- Structured Programming In Forth
- Data Storage
- Strings And Characters
- Number Conversion
- Vectored Execution
- Advanced Concepts
- Multitasking
- Style Recommendations
Disclosure
I received a review copy of this book from the publisher. Thus, my loyalties and opinions may be completely skewed. Caveat Lector.
Forth Application Techniques is available from Forth, Inc. and from some online merchants like Amazon. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Nice to see some current action (Score:2)
Nice to see recent development is still happening,
as forth always has been the best for what its designed for, controlling stuff. Probably always will.
Plus its sooo cool
Re:Nice to see some current action (Score:2, Informative)
Re:Nice to see some current action (Score:2)
the inevitabele Forth/Jupiter Ace comment (Score:2, Interesting)
Maybe it's time to google up an emulator and indulge in a bit of notsalgia.
Re:the inevitabele Forth/Jupiter Ace comment (Score:3, Informative)
A quick trawl came up with the following 'Nix based
emulator [passagen.se]
Re:the inevitabele Forth/Jupiter Ace comment (Score:2)
For the same reason Smalltalk didn't become the preferred language of writing end-user apps, and for the same reason Windows is the dominant OS, and why the versions of Windows with the widest share of the pie (52%) is based on DOS-
backwards compatibility, of mind and software.
Jupiter Ace (Score:2, Interesting)
So two of us own that book :-) (Score:5, Informative)
If you have any questions for Elizabeth Rather, she can be found on Usenet. When I asked for an "introductory book for modern Forth" I believe she recommended her own book! :-)
Threaded Interpretive Languages (TILs) such as Forth have very elegant inner workings. I even wrote one as a kid. And I actually used it for a few months. Although my Forth-inspired TIL was limited to 16 bit integer math (on an 8086 I think it was), I still managed to get it to draw 3d wireframe graphics in real time on a PLUTO graphics card :-)
RB
Re:So two of us own that book :-) (Score:2)
Remember whipping one up in Qbasic , of all things, to pump code for a little Z80 op system I was working on... Took an afternoon to get the compiler to work.. Toooooo easy.
No Thanks (Score:5, Funny)
Forth was created on punch cards (Score:2, Informative)
Jupiter Ace (Score:3, Informative)
It was basically a Sinclair ZX-80, but with Forth in ROM, instead of BASIC. It was a fun little thing to play with.
I may still have mine in a box in the attic. Must go check.
Re:Jupiter Ace (Score:2, Informative)
ha (Score:2, Funny)
Forth is alive every time you print (Score:5, Informative)
Don't know why a non-printer driver person would want to, but you can...
-LG
Re:Forth is alive every time you print (Score:2, Interesting)
Re:definitions of species (Score:4, Interesting)
Back in the day (crikey was that really 8 years ago???) I wrote PSTab, a guitar tablature typesetter, in postscript. I'd been downloading tab for songs from the (defunct?) OLGA, and wanted to print some for use at home. However, ascii tab looked crap and took lots of space on the page; if you tried to shrink it to use less paper it just left blank space at the sides.
We had an old Apple II laserwriter on the corridor, and I had written simple EPS diagramming tools for my thesis in awk (copy and paste programming)... so armed with borrowed copies of the red, green & blue books, I learned PS properly and wrote a typesetter that you could use as a header on simple input files (I'd spotted this was how the windows PS driver worked). Once I got to the stage I could wrap ascii-tab up to make *nice* output pages my itch was scratched[1].
Best thing about it was getting an email from a guy in NZ who used it to produce camera-ready copy for a book of banjo music - there wasnt anything else out there that could handle 5-stringed instruments
-Baz
[1] I know there are bugs. Some of these didnt show up until I saw the output on a higher quality printer. Bah.
Re:Forth is alive every time you print (Score:3, Interesting)
since it was basically a simple statistical experiment + graphical output, I wrote it in PostScript.
Kinda cool, it was a report with the statistical experiments embedded, so if you printed it twice, all the graphs were different
Re:Forth is alive every time you print (Score:4, Informative)
PostScript isn't really based on Forth. It's just another stack-based language, as is the language used for HP calculators, and virtual machines such as Java bytecode and .Net CIL.
Re:Forth is alive every time you print (Score:4, Interesting)
% fractal iteration -- commented even!
% define constant of 1/sqrt(2)
/Scalefactor 1 2 sqrt div def
% Define Fractal subroutine
% usage: lvl Fractal stroke
% Examples below are as if called with a level of 5
/Fractal { % 5
dup % 5 5
0 eq % 5 false
{
% True condition: draws line segment
pop 300 0 rlineto % -
}
{
% False condition: recurse routine
% set the scale factor
Scalefactor dup scale % 5
% On alternate iterations, level is set negative. When negative, reverse the angles
dup -90 exch % 5 -90 5
0 lt % 5 -90 false
{ neg exch neg exch } if % 5 -90 false
% Recurse one level lower
dup 2 div % 5 -90 -45
rotate exch 1 sub % -90 4
% Actually call myself again
dup Fractal % -90 4
exch dup neg % 4 -90 90
rotate exch neg % -90 -4
% Call second time for second stroke
Fractal % -90
2 div % -45
% set things back to the original scale and rotation
rotate % -
1 Scalefactor div dup scale % -
}
ifelse
} bind def
% Loop to iterate 15 pages of fractal
currentlinewidth 4 div setlinewidth
0 1 15 { 200 400 moveto Fractal stroke showpage } for
Re:Forth is alive every time you print (Score:2)
I prefer keeping some anonymity on Slashdot (lets me rant more easily), but if you come across me on the Internet otherwise, you'll recognize me by my .sig, which is a three-line PostScript program (albeit not nearly as cool as the raytracer).
PostScript is an amazing language - completely changed the way I thought about programming. Bored with systems-level C programming? Give PostScript a try....
Re:Forth is alive every time you print (Score:2)
Re:Forth is alive every time you print (Score:2)
No, it isn't.
You can "program" Postscript...
Yes
Don't know why a non-printer driver person would want to, but you can...
Mainly because it's fun. But also because you can make some useful scripts to process postscript. E.g. 2-up, double-sided to single-sided, adding page numbers, etc...
But back to the first point. Postscript is to Forth as Python is to C (roughly). While Forth is an extremely low-level lanugage, Postscript requires a relatively heavy interpreter. A simple forth implementation can be made in a day, and a useful one in a week. PostScript requires much more effort (at least if you want it to be useful with a typical PostScript file). Forth is untyped, PostScript is dynamically typed. Forth has some nifty features making it a reflective extensible language (create does>), PostScript does not. In Forth, everything is a cell (pointer or signed or unsigned integer), PostScript has high-level datatypes like lists, code-blocks (anonymous functions), strings, fonts, etc... In Forth you typically allocate data on a stack, or once at the start of the program. PostScript is garbage collected. Forth is consistently minimal (whether you like it or not), PostScript is mostly high-level, but has some relatively unfriendly features such as fixed-size dictionaries to make it feel more unusable. Forth is easy to debug, and easy to crash your machine with. PostScript is hopeless to debug, but will rarely break anything serious. Forth is inherently unsafe, and is allowed to read/write any memory location, PostScript can be made safe enough to view random files on the web.
I could go on, but it should be clear by now that about the only resemblance the two languages share is postfix syntax.
Re: Forth is alive every time you print (Score:2)
On the other hand, the idea that an early ancestor of PostScript was more Forth-like doesn't sound too unlikely. Most likely it was, it seems like an obvious thing to use Forth for (embedded software, building a domain-specific language, etc...). Obviously, I wasn't around at that time, so I can't actually judge the truthfullness of your tale.
not really (Score:2)
Ah this is great! (Score:4, Interesting)
I ran Miller Microcomputer Forth on a TRS-80 back in the day and it was amazing.
Forth is totally stack oriented. It is difficult to determine where the OS ends and the language begins.
It is naturally recursive.
DONE RIGHT you can do a LOT in a few lines.
You can shoot yourself in the BULLET with Forth.
And Spiderman would code in Forth because...
Re:Ah this is great! (Score:4, Interesting)
Those old enough to remember early 8-bit home computers like the C64, TI99, and similar, may recall that many of these "booted" straight into a BASIC editor/interpreter that was stored in ROM. Nothing between you and the hardware except for this and some very low level rom code roughly equivalent to a BIOS. A VERY low-fat system. Compare that to the multiple levels of abstraction and bloat we have now.
Ever think it might be sort of cool to run that kind of low-fat system on powerful modern hardware? Sort of like an ultimate C64 with, hundreds of megabytes of RAM, and many hundreds of MIPS. Maybe not pretty, but the raw computing horsepower at your fingertips would be awesome, provided you know the system well enough to use it. Replace that BASIC interpreter with the close-to-the-machine spartan efficiency of Forth, and it gets even leaner and meaner.
Chuck Moore, the inventor of Forth, has created an interesting little critter called colorForth that does just this. Stick the floppy in the drive, turn on the power, and boot straight into colorForth. The system is at your command. No OS, other than colorForth itself. The most bloated piece of software on the machine is the BIOS.
Just you. In complete control of your machine. What a concept.
url for colorForth (Score:3, Informative)
http://www.colorforth.com [colorforth.com]
Re:Ah this is great! (Score:2)
Couldn't you do this by booting a modern PC into DOS? Running compiled C it would be blazingly fast, your program would get literally 100% of the machine's capacity.
Re:Ah this is great! (Score:2)
Wimps!
Re:Ah this is great! (Score:2)
Re:Ah this is great! (Score:2)
"best kept secret" (Score:5, Funny)
Still Worth Learning (Score:5, Interesting)
I also tried a version of Forth-83 for Windows by Ray Duncan's company, LMI. I tried to code up a DDE server, and while it worked, it was painful. I've come to believe that Forth is more trouble than its worth when interfacing to APIs designed for C. Such APIs are often poorly factored (relative to how you'd solve a problem in Forth), and take too many parameters of different sizes as arguments. Even with the Palm you jump through some of these hoops, but in that environment it's often worth the effort.
The underlying principles of Forth are worth knowing no matter what language you program in... there's a lot of simplicity at its core, and it'll help you understand how to program for other stack based languages such as
Public domain pForth (Score:2, Informative)
on your own and for free, take a look at
Phil Burk's [softsynth.com]
public domain pForth [softsynth.com]
Re:Still Worth Learning (Score:4, Insightful)
Forth is also an excellent example of "emergent behavior". Even though the language implementation is simple, the dynamic behavior can quickly becom mind blowing. I still have a hard time completely understanding the way some of the compiling "words" (which dynamically add syntax to the language similar to Lisp macros) work in Forth.
If nothing else, Forth will teach you to factor your code into small procdures, because making a function longer than about 5 lines quickly becomes unreadable :).
Re:Still Worth Learning (Score:2)
True. One line is the recommended length -- but that one line holds something very different from what it would have to hold in C.
Forth also has some interesting design details which result in function calls having much less overhead than function calls in C.
-Billy
Open Firmware (Score:4, Informative)
http://developer.apple.com/hardware/pci/
Oh, huh? I was supposed to make a point? Whoops.
-/-
Mikey-San
Re:Open Firmware (Score:4, Informative)
Ya' know, there's one well-known Forth codebase... (Score:2, Interesting)
As a quick pair of references, check out the ProtoMUCK and FBMuck projects on SourceForge.
and also (Score:3, Informative)
availability ? (Score:2, Informative)
I remember waiting until 4 months to get a copy of "thinking forth", by the way.
Now, if you want to learn forth, there seem to be the gforth manual [tuwien.ac.at], at least...
Re:availability ? (Score:2)
Re:availability ? (Score:2)
This is starting Forth I am interested in.
Forth is a great hacker (classical sense) tool (Score:2, Interesting)
While it wasn't the easiest thing in the world to use for building complete GUI apps, it was a great experimental tool because it was essentially an interpreted assembler/disassembler! You could experiment with OS traps that were recently published but hadn't made it to other compiler implementations, and see what machine opcodes would do the job minimally.
You could then take those opcodes and drop them into, say Turbo Pascal (which was barely supported by Borland) as inline machine instructions. Way cool.
The other place where Forth came in handy was a couple several years later when learning PostScript: as a stack-based language, PostScript was a cinch to pick up. Of course, if you've been using RPN calculators, it shouldn't be too bad either.
Forth may be a little low-level in these days when Perl and Python provide such abstract data types, but it makes you think closer to the hardware. When hardware control is an issue (in devices like telescopes, barcode readers, etc.), Forth beats programming in assembler by a long shot.
Elizabeth Rather (Score:5, Informative)
She now works with Forth, Inc. Check out forth.com [forth.com]. They have an excellent history of the language here [forth.com]. BTW, there are free Forth interpreters for just about every platform out there. It's a cool language.
Chuck Moore's own site is here [colorforth.com]
Modern Forths are compiled, not interpreted (Score:5, Interesting)
So why don't you hear about Forth much? A couple of reasons:
1. Forth doesn't have much in the way of standard libraries, so you'll almost certainly get more bang for your time writing quickie applications in Perl or Python than Forth. Try writing a Forth program to read in a file of strings of arbitrary length and sort them, for example. This is a one liner in Perl.
2. Forth has always been geared toward simplicity, but modern desktop environments (Linux, Windows, MacOS) are hugely complex. Forth arguably isn't the best match for such complexity. Embedded systems are different.
3. Forth is best viewed as an interactive alternative to C or assembly language. Certainly from the interactivity alone Forth is a better choice for incrementally building a application than assembly language. This is why Forth gets a lot of use in embedded systems. But with desktop computer speeds being insanely high, it's hard to justify working on that kind of level under, say, Linux or Windows.
(I fully expect this to be followed by "Not true!" rantings from a Forth zealot or two. But you really do have a hard time pointing to compelling applications written in Forth for modern desktop OSes. Python is a good language, so you see some amazing applications written in it (e.g. Zope), but despite all the religion surrounding Forth, you never see much to show for it on the desktop.)
Re:Modern Forths are compiled, not interpreted (Score:2, Interesting)
You are absolutely right. Here is an example...
I've written four production FORTH compilers for various machines, including m68k PPC and x86 (before that I wrote several threaded and direct interpreters). My compilers never manifest the stacks as stacks, and use state of the art (Briggs Chaiten) register allocators. You won't see these compilers because they are used as back end code generators for other languages! The advantage of FORTH is that the front end of the compiler can be retargeted to any machine with a FORTH compiler. The runtime system and library can be written (somewhat) portably in FORTH. It's an excellent technique, and I heartily recommend it.
Re:Modern Forths are compiled, not interpreted (Score:2)
Why not just use the sort command? Then it would be a no-liner.
Re:Modern Forths are compiled, not interpreted (Score:2)
Re:Modern Forths are compiled, not interpreted (Score:2)
Re: (Score:2)
Re:Modern Forths are compiled, not interpreted (Score:2)
You forgot the most important application (Score:2, Interesting)
[Old Fogey Warning] I programmed in Forth once... (Score:5, Funny)
I did my Forthing many years ago (far, far too many). The usual thing, embedded systems work, but I actually did the programming on an IBM PC (original) using a Forth boot floppy (it had its own environment/OS). Then someone else did integration with the embedded system.
It was a truly weird language, and it made it far too easy to create 'write-once' unmaintainable code. But it was my first introduction to many concepts, including a language that was truly 'cross-platform'. And it led to a short job at Aldus because I already understood stack-based languages, so Postscript wasn't a shock to me.
In many ways Charles Moore is a seriously twisted genious. I have always rooted for him, despite the fact I prefer to use a cleaner, more readable language. (Can we say 'Python'? I knew we could.)
So, in the end, I cannot say I think Forth should be in everyone's toolkit. For that reason I expect this review will be of limited use to most of us. (Attn. Moderators, notice how I managed to get this post on-topic in the last sentence. Now you have to mod me down as 'flamebait' or 'boring' or something.)
Jack William Bell
Re:[Old Fogey Warning] I programmed in Forth once. (Score:2)
Amen to that. A lot of Chuck's work, especially his new ColorForth, borders on the bizarre, but it's never drooling-in-the-corner bizarre -- it's always mad genius bizarre.
That being said, Forth is a lot of fun to work with even if you never do anything remotely useful with it. The underlying dynamics of a Forth environment are simple enough that you can roll your own very quickly, which is not something you're going to do with C or C++ or Java. Ultimately, that's what probably kept Forth from becoming more popular: the temptation to create new Forth-like languages was easily satisfied by Forth programmers. Case in point, of course, is Chuck Moore himself, who apparently despises the standard version of Forth and who has never stuck with one version of the language for very long.
Using Forth and building your own Forth environment is still a fascinating way to gain insight into interpreters and virtual machines, and the kind of thinking required for using Forth well is quite an enjoyable exercise. If you do want to use Forth for "real" work, it is worth bearing in mind that some very complex systems have been built very, very quickly by seasoned Forth programmers -- including air traffic control systems -- and the mode of bottom-up programming used in Forth basically ensures continuous unit testing, so Forth programs tend to require less debugging late in the development process.
Starting Forth is a Must! (Score:3, Informative)
ttyl
Farrell
Re:Starting Forth is a Must! (Score:2, Interesting)
sean
fortune on FORTH (Score:2)
Jupiter Ace! (Score:2)
Fabulous language, but for an uncommon situation (Score:3, Insightful)
The problem is, the situation that FORTH is great in is becoming increasingly rare. Most FORTHs still require programmers to constantly think about how to juggle the stack if they receive a number of parameters (yes, there are some extensions). FORTH has essentially no type-checking, and the combination of these two factors means that it's extremely easy to (1) make a mistake and (2) for that mistake to have nasty consequences.
Many program language implementations generate intermediate stack-based code (think Java class files, Python, Perl, etc.); in FORTH, you're writing the stack-based code yourself, so you are essentially writing in an assembly language for a simulated stack-based system. FORTH thus has some of the similar properties as assembler: fewer development system resources are required, but it's more work for the programmer. This isn't completely true; FORTH is definitely much higher-level than the typical assembly language program, but many programs take more work to implement in FORTH than, say, Python (which is also interactive, and it executes a stack-based program, but lets people express code in a more Algol-like way and then TRANSLATES that code into a stack-based approach).
I do think Forth is a good language to learn, because many systems are built on stack-based intermediate languages (Java, C#, Perl, Python), and being able to directly interact with a stack-based language helps to learn how they really work.
An implementation of Forth for 6502 is freely available. [6502.org]
cellular automata machine application (Score:2)
Most people who were weened on HP RPN calculators like Forth's postfix notation. I find it a bit unnatural but I was a FORTRAN man for a long time.
Groking Forth and stuff (Score:3, Interesting)
The reviewer is correct, someone groks forth or they don't.
Being a person who groked it from the second he saw it in 1978, I can't understand anyone not getting it.
Sure RPN notation is hard for some (apparently most) folks, and boolean logic just doesn't seem to be natural for most people, and then the stack just knocks them in the head, but these are three of the four pillars of what makes forth great.
The fourth pillar of forth is that you can change it to be anything you want, most languages have to be learned, forth is a language that you can teach to learn you... If RPN is just intolerable you could redefine it and still leave the core alone for pre existing words (functions for the non forth crowd).
Leo Brodie's "Starting Forth" and "Thinking Forth" books are great and it's a shame that Brodie no longer has an interest in the language.
As a long time forth user I'm not thrilled with the complexity added in C. Moore's latest version colorForth, it seems to add a new layer of complexity, but then again I may just be unable to Grok it.
Personally I'd love to see Forth brought to the GUI era and don't understand why it hasn't been.
Does anybody remember Urth? (Score:2)
--Jim
Display Forth? (Score:3, Interesting)
Just because a tool like Forth is traditionally used by a single programmer in a very cramped system doesn't mean it couldn't have applications in other places. There are many things I wouldn't write in Forth... and there are many times I find myself writing GDI calls and wishing for a more Forth-like interface.
Forth used in financial market reporting (Score:2, Informative)
A Forth-related anecdote (Score:2, Interesting)
Sometime in the 80s (Germany was still a divided country then), a competition was held for university students from all over Germany. The goal was to write a program to control a robot to perform some predefined tasks, with the team who took the shortest time to finish the program being the winner.
The teams from West Germany used their butt-kickin' (for the time) Intel-based systems (DOS, C, Pascal, harddisks and whatnot).
The competition, however, was won by the only team from East Germany. They used an U880 (a GDR Z80-clone running at 1 or 2 MHz) based Robotron [robotron-net.de] computer which had maybe a tenth of the power of the other teams' computers, and Forth as a programming language.
Yep, it's not the size, it's how you use it
My learning curve (Score:2)
Preferably one that has email built into it.
Re:My learning curve (Score:2)
There is a text editor that allows you to write the macros in FORTH (as per Emacs/LISP). I don't recall the name or details.
Integrating such a beastie would be trivial in Mutt or Elm.
Forth-like natural language, still spoken today (Score:2, Interesting)
Euskera, the native language of the Basque people, has a basic structure that is reminiscent of Forth. Whereas English speakers are used to a caseless prepostional system, Euskera speakers are used to a case-based postpositional system that leans mostly toward a "reverse" sequence of sintagms. Here are some examples in my (now rusty) dialect:[1]
Well, I could go on, but I think you get the point.
You can think of a case postposition (of which there are quite a few and which confer great functional specificity) as a sort of type marker, which makes Euskera a sort of object-oriented, reverse-notation language.[2]
__
[1] Any euskera batua fascists reading this can send their corrections of my grammar and spelling to /dev/null.
[2] Well, reverse for English speakers in any case, ha ha.
Useed forth 18 years ago (Score:2)
when it needs to be small and interactive (Score:2)
But that is probably its main virtue. Once you move development "off board" and use a batch compiler, you might as well use a compiler (C, Modula-2, etc.).
Ah! The memories... (Score:2)
I wrote a decompiler that produced compilable Forth code from competitor's ROMs (and we had loads of laughs looking at their inept examples of programming, such as "1 = if 1 else 0 endif" which basically did nothing at all), and I also managed to squeeze in a 4K bytes ROM an insurance rate table with 10,000 integer entries (the second derivative did fit in three bits or something silly like that).
Forth application in 3D animation (Score:2)
When you think about it, a low level language like Forth is ideal for such an application. Realsoft strives for realtime OpenGL animation playback, with physically correct simulation, particles, deformation hierarchies and tons of geometry thrown at the screen. Forth is fast enough to solve custom animation expressions without getting in the way.
citing FedEx???? (Score:2)
I also know that FedEx still has huge monolithic apps written in COBOL on IBM mainframes, since I get nice descriptions of them from my professor on Monday and Wednesday nights (he works there during the day). COBOL, people, COBOL.
I'll make a blanket statement as a Memphian who knows entirely too many people who are either employed by the company or serve as vendors to it: FedEx is a big slow giant that made a lot of decisions in a hurry that it doesn't want to pay to take back. For example, they just built a nice new world headquarters that consists of some of the most modern buildings in this part of the country (ok, not saying a _whole_ lot, but still) and what do they furnish them with? Yup, the furniture they bought in the '70s and '80s.
So when someone says "FedEx uses ____" I tend to ignore that fact and move on. Not every decision they've made is bad, but very few have anything to do with the technical merits of the choices given.
Re:Have you used COBOL? (Score:2)
Have you worked in the software industry or are you just talking out of a random orifice? I won't argue with COBOL as a language (I've used worse), but more as an environment for solving large scale business problems.
My argument was not against COBOL, but FedEx for using antiquated practices that risk not solving their problems reliably to save a few bucks here or there in the short term, ignoring the long term repercussions of their actions.
For example, if they had bit the bullet and bought new furniture 5-10 years ago, they would have saved money. They are paying a lot more to refurbish their old furniture than they would invested in new furniture that would not require work today. I know this because I used to do tech support at the company that sold and refurbished the furniture.
Or take my friend's application. FedEx put out a bid for new software. My friend and other companies put their proposals out on the table. Sure, some of the solutions were terrible (required private hard networks across the country, etc.) I saw well designed, light weight, easy to manage proposals. Would have required an initial investment, but would have saved a fortune in support costs over the long term. But because of political issues, etc. they stuck with what they had. Then again, I'm happy about that one because my friend can sit happy for the next few years, despite any economic problems elsewhere in the industry.
Apple too. (Score:3, Interesting)
Re:whoo Forth! (Score:2, Informative)
Yep. Sun use Open Firmware [openfirmware.org], as do Apple Macs. Open Firmware (or IEEE-1275 - those wacky IEEE names) uses Forth. Even if the rest of the machine is hosed you'll still be able to use forth. Err - great :-/
Re:whoo Forth! (Score:2)
Seriously, Forth had solid advantages when RAM and processor cycles were at a premium. But these days few people have to develop for a 4k environment.
Re:Sun OpenBoot sucks (Score:2, Insightful)
OpenFirmware is defined for the X86 architecture too - just motherboard manufacturers stick with proprietary PC-BIOS clones like PhoenixBIOS and AmiBIOS instead of OpenFirmware, so card manufacturers keep putting x86 assembly language into their BIOS blocks instead of OpenFirmware code.
Remember, the PC-BIOS and x86-architecture is a massive kludge! Why would you expect a Sun architecture to be able to run, AT BOOT TIME, x86 BIOS drivers?
Re:What they have in common (Score:3, Interesting)
That said, the parent poster is indeed an idiot. Much commercial software is worth buying, and not all products can be economically written and supported as open source.
Incidentally, I interpreted the "give you nothing in return" thing a bit differently wrt Sun -- their machines really don't have the same value proposition as many others (Intel-based systems on the low end, IBM's big iron on the high end), and I took the (great?) grandparent to be painting a somewhat exagerated carciature of that.
Re:Early post (Score:2)
HI and HELLO in forth (depending on flavor) reboot.
Can't wait to get my hands on the new book, we are heavy forth users.
Re:Religious experience to "get Forth"? (Score:4, Insightful)
This power is often what someone refers to when they talk about "getting" it. Forth has also been criticized by some, ironically for that very strength. Why?
At the high levels of your application, you're no longer coding in Forth, but in the language you've designed to solve the problem. Reading that code requires a newcomer to understand that new language, in much more depth than they'd need for something like a C program. When designed by a competent Forth programmer, this code can be quite readable, at least in a general sense, by anyone who understands the problem domain. But a novice Forth programmer, particularly one who thinks in terms of writing a program in Forth (rather than extending Forth to solve the problem), can create a very unreadable mess.
With power comes responsibility (a phrase that predates Spider-Man, by the way
Re:Religious experience to "get Forth"? (Score:2)
Re:Computer languages are all the same (Score:5, Insightful)
Most languages have a focus toward a particular aspect of programming. Some are very good for Object orientation. Some are good for low level hardware I/O. Some are designed to parse input in optimal fashion. Others are designed for terse code.
They all have a purpose. That's why we have software tool chests with lots of languages and tools which can be used in so many ways.
Forth is good for low level I/O work. It's often used in Robotics and control systems. It is a minimalist language and it generates very fast, memory efficient code. These are good traits when dealing with embedded processors. But once you try scaling it up to do more complex tasks, you discover its limitations. That's when higher level languages start to shine.
Re:Computer languages are all the same (Score:2)
I disagree wholeheartedly. While it's true that very many languages don't differ in anything but syntax (e.g. C, Pascal), the interesting differences are the semantic ones (e.g. C++, Prolog, Scheme, Forth, ML, Haskell, Mozart, Perl, M4, Icon). While many features superficially look the same, the meaning of two programs with similar-looking syntax or structure can be radically different. Syntax matters little beyond the initiall "sell".
But I really haven't seen a new concept in computer languages in 20 years.
Interesting. I find new interesting concepts in new languages every day. But I haven't been here for 20 years, and to some degree I believe what you are saying (if you are talking of major new concepts!). Few of the languages on the list above are very young. On the other hand, I guess template metaprogramming and constraint programming are both pretty new.
Re:Computer languages are all the same (Score:2)
I see very little difference between:
[deleted]
Apparently you don't look very hard. There are significant differences even in the examples you have presented. First of all the LISP/Scheme code support introspection (you can determine the contents of my_function with other LISP/Scheme code) which is impossible in the C (and that won't work in C anyway) or assembler model. Secondly the issue of type safety is unaddressed especially in the assembly and C code (what are you adding integers? Reals? Complex values? Inquiring compilers want to know). Finally to paraphrase Larry Wall states a language should make the easy things easy without making the hard things impossible which is the driving impetus behind programming language creation. There are real and fundamental disagreements over what is/should be easy and what's impossible.
Too bad there does not exist a universal computer language compiler system whereby one could code in the computer language they prefer and check the code in and the next guy could check out the code in the language they prefer.
That desire seems to express much of the design behind the .NET CLR. In principle it should be possible to disassemble CLR code into a language other than its original implementation, however the disconnect in features (just how would you disassemble a LISP closure into C code? Or worse yet the entire Smalltalk environment?) makes this less feasible than your simplistic assumptions would indicate.
Re:Computer languages are all the same (Score:2)
set/read variables
conditional, branching and looping constructs
call functions
Let's see: the FORTH textbook I own didn't include anything on variables, as it considered them unnessecary. (Which, to a large extent in FORTH, they are.) Lots of Lisp ('pure' Lisp) doesn't use branching or looping constructs, using recursion for everything. APL is comparitively normal - but looping isn't well supported, instead you do everything in parallel on vectors.
Re:Computer languages are all the same (Score:2)
xdnLoginRsp.addAttribute("Result", strResult);
WebPacXMLUtils.addNotNullChild(xdnLoginRsp, "SessionID", strSessionID);
return new XMLDataDOM(xdnLoginRsp);
Re:Computer languages are all the same (Score:2)
And it was a mistake to post it.
I was having trouble posting, due to DNS propagation times due to the slashdot move, and had saved my post on the clipboard. I decided to try again, pasted it and hit submit. Oops... I had snatched some Java onto the clipboard by mistake.
Oh well, at least it wasn't my bank account number and PIN or something!
Re:Computer languages are all the same (Score:2)
But computer languages vary greatly.
It just boils down to syntax and ease of typing is just nonsense...
how about:
declarative vs procedural
portability
extensibility
testability
formal provability
code compactness
interactive vs. compiled
static vs dynamic memory models
object orientation
???
It is a lot more than syntax.
Forth happens to be very unusual as a language. It is extremely extensible (it is trivial to redefine the meaning of "if" should you want to). It is based on a dictionary concept. It has a compiler and interpreter that together can be written in about 3 lines on an 80 column wide screen (if you don't do pretty-print formatting). It is highly portable because, like LISP, it starts with a very small set of primitives that need to be ported, and then builds itself out of them. Creating an application from it simply continues that extension process.
When you write an application in Forth, the high levels of your application look almost like english text optimized to express your algorithm. It doesn't even have to be recognizable as "Forth." Charles Moore (http://www.colorforth.com/), who invented Forth, is a brilliant and iconoclastic guy who made a real contribution by creating a number of original language concepts.
One thing that is very tricky in Forth is cross-compiling. Because there is no difference between compile time and execution time, cross-compiling is inherently undefined. In order to make it work, you have to play some pretty subtle and head-breaking tricks.
Re:Computer languages are all the same (Score:2)
If you look only at the code the machine actually executes at the CPU level, I suppose one could make an argument that all HLLs are the same, since the code they compile into looks much the same for any given task. The difference, of course, is in what tasks the language lends itself to from the programmer's point of view. People use HLLs because they abstract concepts from implementations; different languages abstract different concepts differently, making some tasks easier to accomplish - from the coder's point of view, of course. The computer doesn't care.
Or, you can look at it another way. There's a vast universe of things a computer can do. At the one operation per instruction level, all those tasks have a probability proportional to their number of operations, given a random program. HLLs, however, group implementation tasks (moving data from memory to a register and back, adding data from one register to another, comparing the contents of two registers, etc.) into logical tasks (square roots, screen repaints, file output), where one instruction means many operations. Hence, a random program will achieve more complex tasks - the probability of any given task occuring will depend upon what sets of operations the HLL generates with one line of code verses multiple lines of code. This means different HLLs will tend to generate programs in different volumes within the total universe of possible programs. This translates into different types of programs being easier to conceive and implement in different languages.
I mean, really: who writes device drivers in VB? Who writes word processors in assembly?
Not quite. (Score:2)
The Forth style is different. Each token is an instruction to be executed in strict order, and performs its function by modifying the machine state in some way. You don't tell the machine, "I want you to find the answer to this problem," you tell it "do this, then that, next this," and in this way you get to know exactly what it's doing. "Returning" multiple values, or making multiple changes to the machine state, is easy and natural. You don't have to put in silly kludges where your return result is a proper answer in some cases and an error code in others, or resort to the absurd COMEFROM of exception handling. There is no limiting syntax to trip over, your own constructs can be as expressive as the ones that are built in.
You don't need to understand algebra to learn Forth. As Chuck Moore says, it should be taught some time after counting and before long division.
In short, Forth is the truly general purpose programming style. It's based on the way computers really work, not some idealized model of how we'd like computers to work. This makes some things a little harder, and makes some things much, much easier.
That said, I don't use Forth much. Everybody uses C, or C-based tools. All the system interfaces are designed and documented for C programmers, and if you want to use them, you have to deal with the workarounds for C's shortcomings regardless of what you actually use. Since interfacing with system libraries is often the biggest and most painful part of a project, this negates the advantage of moving to Forth. Even the processors are designed for C code. Stack machines aren't any less efficient than register machines, but by the time you take advantage of a large register file, your beautifully-simple Forth compiler/interpreter is as monstrous as a C compiler.
Compromise systems, such as ANS Forth, neatly combine the disadvantages of C with the disadvantages of Forth.
And so, Forth ends up restricted to situations where you'd have to build up the kruft yourself if you wanted to use C. Still, I want a T-shirt that says, "I'd rather be programming in Forth!"
Re:Computer languages are all the same (Score:2)
# set/read variables
# conditional, branching and looping constructs
# call functions
1. Most functional languages don't include the concept of setting a variable; reading a variable is also very different from Algol-like languages. Forth isn't functional, but doesn't have much use for variables; the closest thing it provides is essentially direct memory access.
2. Many languages truly do no more than imitate what Fortran finally discovered so many years ago -- but there are also many more which go much, much further, starting with the simple concept of recursion and stretching onward to continuations and preemption. Although anything we know now can be implemented through continuations and preemption, many languages automate some smaller and easier to work with (or optimise) subset, such as Icon, Sather, or J/K/APL. Forth has some really interesting things to contribute here, thanks to the fact that a 'continuation' in Forth is just a single pointer.
3. Finally, you imply that all languages call functions in the same way. You probably only know language which work in the same way; but there's more out there. Consider the differences between the parameter passing styles: C is applicative, Haskell is curried, J is combinatoral and Forth is concatenative. In other words, C depends on lambda theory; Haskell depends on curried lambdas; J depends on dataflow around functions; and Forth depends on dataflow within a stack passed and returned from composed functions. Most modern languages are lambda-based, so more like C; a few are starting to become curried, since that's a very simple change which gives a lot of power and flexibility in parsing.
So no, language can't simply be swapped without regard.
-Billy
Re:Computer languages are all the same (Score:2)
All n-complete languages will share certain similarities in how they handle discrete requirements. How the entire language is used to express solutions to problems will not be the same in all cases. This is probably what most of us respond to when we say we do or do not like a particular language for a given solution (or at all).
A more accurate test would be writing a solution that toggles a bunch of motors on, off and changes direction and speed in any arbitrary combination. Another good test is a word processor or desktop publishing app.
Is your solution expressed well in the language? Does it allow you to build upon previous work? Can you abstract the various small problems well enough to decompose them into small easily tested chunks?
One of the best parts of real-world FORTH is the ability to incrementally build your app, and to build unit-testing and full test-harnesses right into an application. Once the product is shipped, these can be left in (or not, depending on how you want it) with almost no impact on overall performance.
Note that I am not saying this cannot be done in other languages, only that FORTH makes it trivial to develop these handy tools right alongside your regular development activities.
Re:"Starting FORTH" (Score:2)
In 1980 I bought distribution rights for a 12 state territory from Excalibur Inc., which was manufacturing an "artifical intellence" peripheral card for the Apple PC. It was called "SAVVY" and was a powerful and easy to use RDBMS that could be queried using every day English expressions: "Show me my customers who live in Lincoln and have sold over 10 units of widgets". Later, when the IBM PC came out, they produced a software only version that sold on a 5.25" floppy disk. I later moved it to a 1.44MB floppy. I still have a copy of it, and the manuals. But, in order to run it from a HD, it has to be on a partition of less than 10MB. Excaliber went out of business due to mismanagment and got a chance to converted it to do multi-user/multi-tasking.
SAVVY was written using PolyForth, and then later it moved to Forth Inc., IIRC. The first FORTH code I saw was a ream of SAVVY source.
I often return to FORTH and play around, just to remind myself what a threaded, extensible, object oriented, nearly assembler level language is like.
The biggest pain about it was that only integer numbers could be handled without scaling. Some versions included automatic scaling behind the FENCE.
Re:NEON (Score:2)
Still, I have the Brodie book and even published an article in Forth Journal. The elegance of the language is amazing. I like the way that you don't so much program, as extend the compiler to include new words for what you want to do. Eventually, the compiler is so close to your problem domain that a few words in this new language will solve your problem.
I miss it.
MOPS like if honk then (Score:2)
Re:crazy bugs (Score:2)
The best Stupid Forth Trick I ever learned was changing the number based from octal, decimal or hex to an arbitrary number like 128 or 256 (decimal).
Every single printable ASCII character becomes a number. Any language that allows you to define cntrl-G as a valid number you can compute with has to be on a hackers list of all-time favourites.
Of course, changing it back again may be a bit of a challenge. For some reason, all my compiled words keep ending up on the stack...
Re:The Forth bumper sticker (Score:2)