19

What were the earliest Forth programming language implementations for 8-bit personal computers? Was it FIG Forth? Or a predecessor? Or some other development?

Why did Forth lose its relative popularity in usage after the advent of 16/32 bit personal computers?

  • 4
    @Chenmunka Huh? If those are actual rumors, then yeah, they would hurt it's popularity. I don't entirely disagree with the "write-only" reputation. Forth can be written just as obliquely as Perl or any other language. Further adding to that is its stack-oriented ("reverse Polish") logic flow that many find foreign. However, your second sentence is entirely false. Forth has two comment types, parenthetical ( in-line ) and backslash \ comment to end of line – RichF Jul 17 '17 at 9:45
  • 1
    @RichF: The Forths that I (briefly) used didn't support either of those comment formats. I'm glad that there were better ones around. – Chenmunka Jul 17 '17 at 9:51
  • 2
    @Chenmunka Classically, there was even a third type of code documentation, the shadow screen. Forth code was originally written in 64-character by 16-line screens, stored on disk as numbered blocks. Blocks 1000 to 1999, say, were assigned to interpretable Forth code. Then 2000 to 2999 were documentation screens. I.e., 1000 (in this example) above every code screen was its documentation screen. // Since more complex file systems are used today, shadow screens are no longer necessary. – RichF Jul 17 '17 at 9:51
  • 2
    @RichF: I'm talking 1973/74. Well before '78 we'd blacklisted Forth as an unusable language. – Chenmunka Jul 17 '17 at 9:58
  • 3
    Just a word of use: Forth is alive and well, and in active use - for deep space probes. The radiation-hardened IBM RAD series of single-chip-computers, which are most popular as deep space probe systems, use Forth as their machine language. – SF. Jul 18 '17 at 16:10
19

I believe FORTH Inc. provided the first microcomputer version:

FORTH, Inc.'s microFORTH was developed for the Intel 8080, Motorola 6800, and Zilog Z80 microprocessors starting in 1976. Ref

It wasn't until 1978 that the FIG-Forth model became available, based on the 6502 implementation developed by one of FIG's founders, Bill Ragsdale. Ref


My professional programming career began with FORTH, Inc.'s version for the PDP-11 family. It gave 100% control of everything all of the time. While it was a multi-tasking and multi-user system, the implementation was such that these features were co-operative. One user or bad application could disrupt the others. Everyone and every application had 100% control of everything all of the time. It sounds contradictory, but in a non-networked environment of people working together, this was a very efficient system with little operating system overhead.

That was the key to early Forths. The operating system was Forth. The development environment was Forth. The language was Forth. The applications were Forth. (You weren't writing separate programs so much as making Forth bigger.)

Computer scientists were probably horrified at these concepts. Sure it was compact, efficient, quick in both development and execution, and many implementations were free. But it wasn't safe. It wasn't structured. It gave everyone 100% control of everything all of the time. Anathema!

Forth lost its popularity because it is seldom taught, and it breaks too many rules. Running under an operating system does give advantages, such as networking, GUI, and a large number of available applications for the computer. But it has lost part of what made it unique.

My next professional job added Unix computers to the Forth stuff I was doing. Partial control of some things when Unix feels like it. The paradigms were opposite, and it felt disconcerting switching from one to the other. Forth, of course, was available on Unix, but as a program controlled by Unix. (This is how most Forth's are today, running under a larger operating system.) If you really like the language, that's cool. Most managers won't allow its use though, because even as a slave app, it is different to almost everything else, and the number of Forth programmers is relatively small.

Formality is another reason it lost its popularity. Sure it results in fast development, but fast development is not part of modern programming philosophy. "Know what you're going to do before you do it" is. Plan everything out ahead of time. Forth was designed for interactive, iterative development. Try something. Fix it, tweak it, improve it. Okay, the telescope can now spin at the speed, direction, and to the location desired. An hour later, move on to controlling the angle of the telescope relative to the ground. Don't already know what you are going to do. Just do it. (I know there are places that encourage iterative development techniques, but as far as I know it is uncommon, especially in large companies.)

  • 3
    Your description of Forth reminds me of one of my favorite quotes from Dan Ingalls' Design Principles Behind Smalltalk: "An operating system is a collection of things that don't fit into a language. There shouldn't be one." – Jörg W Mittag Jul 16 '17 at 22:05
  • 3
    @Tommy I wouldn't say Forth is "dead" -- more like "unpopular and hidden". It is hard for me to imagine a better system for embedded system software development. The problem is so few people know anything about it, and they would rather use something they know. But there still are commercial implementations out there, meaning people still make money with it. – RichF Jul 17 '17 at 6:22
  • 2
    @RichF the designers of the Open Firmware, which originated at Sun but survived in Macintoshes until the Intel transition, agreed with you. That's a tight, embedded system from the modern-enough era that used Forth. The Intel Macs use UEFI instead of the Open Firmware just because the different chip vendor came with a different firmware interface. There was no motivating technical reason to eliminate the Forth. – Tommy Jul 17 '17 at 15:08
  • 1
    IIRC, Forth was fast compared to any non-assembly programming language (Basic, Logo, Pascal P-machine, et.al.) that could be developed and ran well on PCs with less than 64k of memory. Once over 64k of DRAM became affordable (to typical IBM PC buyers), Forth lost that advantage. – hotpaw2 Jul 17 '17 at 18:41
  • 1
    @Tommy You only have to look up words when interpreting or compiling, so the design of the dictionary doesn't affect runtime performance. A linked list will do fine in most cases. – Lars Brinkhoff Nov 29 '17 at 11:23
9

From the Gforth manual section Appendix B Authors and Ancestors of Gforth:

A team led by Bill Ragsdale implemented fig-Forth on many processors in 1979. Robert Selzer and Bill Ragsdale developed the original implementation of fig-Forth for the 6502 based on microForth.

The principal architect of microForth was Dean Sanderson. microForth was FORTH, Inc.'s first off-the-shelf product. It was developed in 1976 for the 1802, and subsequently implemented on the 8080, the 6800 and the Z80.

Regarding Forth on the 6502, Forth Inc's Forth programming language, history and evolution states:

Bill Ragsdale, a successful Bay Area security system manufacturer, became aware of the benefits of microFORTH, and in 1978 asked FORTH, Inc. to produce a version of microFORTH for the 6502. FORTH, Inc. declined, seeing much less market demand for microFORTH on the 6502 than the more popular 8080, Z80 and 6800 CPUs.

Ragsdale then looked for someone with the knowledge of microFORTH and intimate familiarity with the 6502 to port a version of microFORTH to the 6502. He found Maj. Robert Selzer, who had used microFORTH for an AMI 6800 development system on an Army project and was privately developing a standalone editor/assembler/linker package for the 6502. Selzer wrote a 6502 Forth assembler, and used the Army’s microFORTH metacompiler to target compile the first 6502 stand-alone Forth for the Jolt single board computer.

7

Why did Forth lose its relative popularity in usage after the advent of 16/32 bit personal computers?

It didn't have any relative popularity as an 8-bit computer programming language at least, not amongst hobbyists. All 8-bit microcomputers except one came with a BASIC interpreter and BASIC was a much easier language to learn. The one computer that didn't come with BASIC was the Jupiter Ace which had Forth built in instead. The Jupiter Ace was a commercial failure, partly because it didn't have BASIC.

Why was Forth not a success (as a general purpose language)? There are tworeasons, in my opinion:

  1. Forth is a hard language to learn for an absolute beginner. Many people who bought 8-bit micros had never done any programming and so were having to learn how to program. If you're struggling with the basic (sorry about the pun) concepts, an unfamiliar notation is an added difficulty too far.

    BASIC programs were lists of instructions in almost English. They weren't much of a stretch from, say, a recipe or a list of directions. Forth programs were lists of words in reverse Polish notation, which can be tricky to grok.

    Also, expressions in BASIC were not too far removed from expressions as taught in maths at school. Also, also The concept of a stack can be quite tricky to grasp. You can do a lot with BASIC without knowing what a stack is.

  2. The BASIC monoculture was self sustaining. In the age of 8-bit computing, everybody knew BASIC. If you had a problem with a BASIC program, somebody could help you solve it. If you bought computer magazines, they tended to have program listings in the back that you could type in. These were almost invariably in BASIC.

Forth is a great language with a small footprint, but it is quite low level and definitely quirky. It was never going to be a mainstream success.

  • The relative popularity of Forth was certainly not zero. Before the IBM PC, Forth was popular enough for the Forth Interest Group to have regular and well attended meetings in the SF Bay Area, as well as there being multiple in-print publications on Forth(s). But that ended around the time the PC and Mac were introduced. – hotpaw2 Jul 17 '17 at 17:16
  • @hotpaw2 Don't kid yourself, it wasn't popular in the mainstream world of eight bit microcomputing. The existence of interest groups and publications does not mean everybody - or even a significant proportion of people - was using it. And the SF Bay area is not the World. – JeremyP Jul 18 '17 at 8:35
  • I'm guessing that Forth died with the relative popularity of C getting better. – PeterI Jul 18 '17 at 10:19
  • When I was using Sun workstations in the late 90s, the diagnostic language of the machine was Forth. I don't know whether that is still the case. To understand Forth, you need to understand the double stack and indirect threaded code. Once you've worked that out, it is quite simple. – cup Jul 18 '17 at 12:43
  • 1
    @cup Sun used Openfirmware for the initial bootloader (analagous to the BIOS in a PC). It was implemented entirely in Forth. – JeremyP Jul 18 '17 at 16:54
6

That's kind of two questions in one; as to the latter: one of the big benefits of Forth is that it produces threaded code: every new word (/function) is very nearly just an ordered list of of other words to call. So the output tends to be very compact, but not very speedy. Once you've got more RAM, it stops being quite so useful a trade-off.

It's also unusual in being stack based. Postscript is the last surviving stack-based language, as far as I'm aware, and it's rarely used for much beyond data storage. So its swimming against the tide probably didn't help.

As to the former: there were at least two Forths for the Apple II by 1979 — so predating most of the competing machines — Apple Forth by Cap'n Software and AppleFORTH by Programma International. Given the similar names it's probably safe to assume independent but concurrent development, and a lack of preceding competitors.

  • 3
    There are lots of stack based languages that other languages compile into. For instance p-code, used by Pascal, o-code and a-code by BCPL, bytecode by Java. The difference is Forth had 2 stacks: one for return addresses and one for the parameters. Really got me confused when I was implementing a compiler in C. – cup Jul 18 '17 at 19:14
  • Also available for the Apple II, circa 1979, was gforth, reportedly derived from FIG-Forth, reportedly derived from microForth. – hotpaw2 Jul 18 '17 at 21:09
  • I think I know what you mean when you say that Postscript is used mostly for "data storage," but I have trouble thinking of it in such passive terms. Postscript documents that I've had experience with are often quite "active" in computing the printed page, not just conveying it. – Wayne Conrad Jul 19 '17 at 19:16
  • Note that the IL for .Net is also (at least partially) stack based. – NetMage Aug 11 '17 at 23:44
4

Forth was available for many of the microcomputers (and some minis) that could be called personal computers when they shipped. Engineers often constructed small Forth Kernels as the engineering department's debugging monitor for new hardware (including many things not PC), and, depending on the culture of the people they were working for, they often made their work available in the early users groups.

Non-engineers often did not know what do with Forth interpreters, and passed over them looking for BASIC.

Also, managers who didn't understand Forth would not allow the engineering debugging monitor to ship in the product, arranging for a conventional one to ship with the hardware instead. Managers who did understand Forth also took it out, to avoid giving the customers too much for their money.

Now, Forth kernels were useful as post-fix integer calculators, but you really wanted a much more complete development environment. That is part of what drove the creation of the fig-Forths -- helping to demonstrate a common set of definitions that could be used, with minimal porting, to construct a full IDE. (Line editor IDEs were still useful back then because we hadn't been spoiled by full-screen editors.)

Reasons Forth did not catch on? It didn't really lose its popularity, it was just totally eclipsed by the Bill Gates machine.

I think there may have been deliberate misinformation, because some thought Forth would not bring the customers back for the add-ons, etc. Gotta have that business plan that guarantees a cash flow.

But there was also a lot of terminology difference. Today we can describe a Forth as an interactive symbol table with fundamental math libraries. The detail of the split stack doesn't even hit radar level any more. It should, because of the now-well-known problems of the stack crash/smash, but I'm not willing to predict that common sense will prevail, even now. (Especially now.)

The terminology and concept differences were deadly.

"Instruction threading" is generating a list of mixed effective op-codes and procedure calls in a virtual machine that cached the return address to reduce call overhead. But people interested in Forth got all tangled up in details of the threading and wasted a lot of time in work that was mostly theoretical exercises in the limits of call optimization and pre-optimized static register usage patterns. It is actually valuable in an academic sense or in a CPU architecture research environment, but it didn't push product out the door, and sometimes made enemies that didn't need to be made.

(I was one of those who wasted considerable time on that.)

"Words" vs. functions/procedures was another terminology difference which was confusing. "Dual stack" was another. I think a better term now would be "split stack".

Postfix notation is a conceptual gap. You could (and some did) write a prefix or infix interpreter for Forths, but that mostly raised hackles. Other purist issues came up about the use of the stack -- whether to limit direct access to the swap/rot range or allow a generalized pick that could pull in operands from arbitrary depth.

Splitting the stack made post-fix natural and simple to implement in the interpreter, but there was really no real reason to avoid infix or prefix. Shoot, the standard word for defining functions is prefix in standard Forth.

The funny thing is that the non-Forth community has wasted a lot of effort support something called a stack frame that is mostly there to give the interleaved stack enough structure that you can safely use the interleaved stack to hold variables. With the split stack, all of the complexity of the stack frame goes away. If you really want a stack frame, it's just pushing the parameter stack pointer with the instruction pointer. The frame pointer can actually be just thrown away on return in most run-times if the stack is split.

And the other funny thing is that the split stack is still ignored as the primary first step in really dealing with the security problems of stack corruption. If you don't want the return address overwritten, don't store it with the parameters and variables.

The 64K boundary was another point of conflict in concepts. In other languages it was not such a big issue, but many early Forths made use of the 16 bit modularity, and there were some purist arguments about that, as well.

Considering the size of a bit-mapped display frame buffer, no one should ever have taken the 64K arguments seriously, but hind-sight is twenty-twenty.

That brings up one more sticking point, which you refer to.

Moving from 16-bit to 32 required a bit of abstraction, and Forth has always been a bit stand-offish about abstraction. To convert a 6800 or 6809 Forth to the 68000, for instance, many just kept the 64K memory model. (Can you imagine?) The actual conversion required going back through the source code carefully, looking for instances of "2 +" sequences that marked incrementing to a next address and changing those to "CELLWIDTH +" or some such. Not just that, of course, but you really had to understand the low-level source and you really had to take time doing it.

For people who had done it before, implementing a new Forth for a new 8-bit CPU was quick and painless when you had a full IDE to start with. Almost all the heavy lifting was high-level. But you couldn't do that when you jumped from 16-bit addresses to 32-bit. You could still do a lot of high-level, but you had to slow down, and the market was cut-throat enough to scare you about slowing down when you weren't sure how much you'd have to slow down.

Now is that more than you thought you wanted to know about this?

  • 2
    I appreciate your detailed response and knowledge base. // Wasn't an early controversy within the Forth community based on the value of TRUE? IIRC, one of the early provisional standards defined it as -1 (all bits set). Prior to that, some Forths used 1. The -1 choice was ultimately correct. ( 6 TRUE AND returns FALSE should TRUE have a numeric value of 1, but effectively true if it is -1 -- consistent behavior both boolean and binary.) However, the newly required value broke badly written code, code that had treated TRUE as a numeric value with mathematical operators. – RichF Jul 19 '17 at 4:55
  • 1
    Yes, that was one of the arguments that went the rounds. But -1 is only correct for a set true given a set of assumptions found in, as you say, most of the common Forth code in circulation. 1 is correct give the assumptions used in most of the common C code. Both C and Forth share the common read definition of non-zero for true, which is also correct for both. -- I have found that trying to straddle both contexts has at times given me headaches. :-/ – Joel Rees Jul 19 '17 at 8:49

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.