FORTH - Better than BASIC? 

I am 70 years old, and often use TurboForth on my TI-99/4a which has been my slow-but-faithful tinkering companion for over 40 years. A quirky programming language for the world's most quirky hiome computer! 'grey beard' is absolutely applicable (slowly turning white - at which time I will supplement my pension as a retail Santa). I can say with confidence that you will still be doing creative things when you reach my age. Passions slip away far more slowly than life does. Excellent video. Thank you!

I wrote a Forth system in a 4k eeprom based on Threaded Interpretive Languages on a Z80 starter kit in the 80s after implementing a video terminal on the breadboard area and using the on board ctc. It was eye opening and influenced my thought processes all the way through my career.

Forth is very much used today in embedded systems, on FPGA Forth CPUs , we had a nice video conference this month ( in our c h a n n e l ) about all these fascinating themes. Forth is not only used in retro activities but in the ESP32 & RPI PICO for IOT and robotics, for home and industrial automation, the big advantage of Forth is you can put a whole development environment (interpreter compiler assembler and editor) inside a chip, and still have space for your application, and to debug and update firmware on site. Any other language that we know can´t do the same.

We did a big project for the Astronomy community and worked with some of their programmers. Forth was used a lot in Astronomy and at least the programmers that we were working with had come to the point of outlawing Forth on their projects. What they said tended to happen with Forth was that each time a new programmer came to support a Forth program they ended up rewriting it into their own "dialect" of Forth. The lack of standardization of higher level functions meant everyone had their own flavor of them and made it difficult to work on someone else's code, or to use or integrate someone else's code. It was useful for small projects, but didn't scale well, they said.

You often hear how the 8-bit era was the last time you could understand a whole system top to bottom. FORTH is an interpreter equivalent of that - it's so simple even mere mortals could write one... and they often do. It's like some sort of rite of passage. I've written one in numerous languages from perl, C, to C# and also assembly on 6502 and x86. The kicker: I suck at FORTH.

There may be many reasons not to want to use basic but it not being Turing complete isn't one of them? What on earth makes you think that? Fwiw, I've seen forth implemented in basic, which would an impossibility if forth was turing complete and basic was not. As you might expect, such an implementation is not fast, demonstrating yet again that implementation makes a huge difference for any language.

I am using Forth today so I can upload custom programs into a "programmable controller" over LoRaWAN radio links. Could do that with Firmware-Update-Over-The-Air, but would quickly saturate available bandwidth. The added benefit in development is the "edit-compile-flash-test" cycle pretty much becomes "test-test-test-test-edit" since everything is tested over serial port and in RAM on target before being added to "source code repository". Very different mentality and approach.

The Jupiter Ace was released after the Spectrum, and it was created by a couple of people who had previously worked on the Spectrum for Sinclair. I bought one when it came out, and I later created my own version of Forth at university. The compiler uses something called threaded interpretation, and it’s seriously clever. You can start from a tiny number of words and build the entire language out of those words. You can also, in some implementations, edit words after you’ve created them. As to why anyone would use Forth now, it might be that you need to create a fast application which works on the most most minimal hardware and you’d prefer to write in a higher level language than assembler. It’s also possible that you’re creating applications in an environment where there’s already a tonne of existing Forth code. The other reason to use Forth is because it’s weird, different, and it’s fun.

"Forth is a difficult language..." Yawn. If I had a nickel for every time I heard this claim... In my career as a software engineer, I would often use Forth in my interviews when hiring candidates, precisely because of this wide-spread yet false belief. Who, coming out of a university today, would ever know of Forth, let alone ever have used it? The goal was simple: given a piece of code in a language you've never used/heard of, how do you go about debugging it? What a perfect way to exercise a candidate's abstract debugging skills? So I'd give them a puzzle or buggy piece of Forth code, act as their "interface to Google" if they had questions, and they had to debug it. NOTE: Not fix it! Not add new features! JUST debug it -- tell me where it is wrong. Of all the people I interviewed, ALL of them found the errors that I deliberately injected, and more than half went on to CORRECTLY introduce new features. Forth is not difficult; certainly no more difficult than C in practice. I really wish people would put this misconception where it belongs: in the recycle bin.

Did I hear you say BASIC isn't Turing complete? I'm just going to pretend I didn't hear that.

75 yo Canadian man here. In the autumn of 1981 I had recently purchased an Osborne O1 which was a 'luggable' computer that was based on a Zilog Z80, running the then-well-known CP/M OS. I had access through some friends to the source code of a version of Forth written in 8080 assembly, and following in the footsteps of a buddy I translated that Forth into a version to run on the Osborne making full use of the extra commands available in a Z80 processor. Great fun, and I still have my Osborne & the floppies I used to hold all those Forth development tools. About 15 years ago I rescued the Osborne from a closet & fired it up. One of the two 5 1/4" floppy drives no longer turns, but I was able to boot from the second floppy & check that my Forth disks were still viable, along with Wordstar & SuperCalc, the two programs I used the most in the early 1980s. Ancient history of course. BTW, the Osborne will cause my nearby boombox to mute its FM radio. This was before the FCC made rules about RF emissions from consumer & office equipment! That same buddy a few years later [mid-1980s] created a 16-bit version of Forth to run on IBM-compatible machines, and I have that version running on a 2004 WinXP machine in WinXP's underlying DOS 6.22. No floating point operations, but screamingly fast integer arithmetic. I still have, and occasionally use, a home-made coil-winding machine that is driven from that 2004 WinXP box's parallel {printer} port by code written in Forth. Byte-wide codes sent to the winder increment/decrement the shaft position of two stepper motors simultaneously, one nibble per motor. One big stepper motor rotates the coil bobbin at a variable speed to turn rectangular bobbins while maintaining {approximately} constant wire tension. The other, smaller, stepper drives a lead screw for wire positioning synchronized in Forth software to the angular position of the bobbin.

11:30 Why do you say that BASIC is not Turing Complete? It seems you misunderstand something...

Wrote my own version of FORTH, back in the 80s. I went to Kit Peak and saw the original telescopes Charles Moore wrote the first version. I still have a disk with a floating point library I wrote. I still have feelings of nostalgia about FORTH, what a great language!

Forth is indeed commonly used today, as PostScript is a dialect of Forth. I’m sure it’s still used elsewhere, but I figured PostScript (and PDF that largely replaced much of its use cases, but I’m unsure if PDF *ACTUALLY* uses Forth, even though it’s a binary version of PostScript) are still in pretty wide use. I hope this helped. -Loren

Also, it was called FORTH, not fourth because the 1130 file system only had 5 letter file names.

This is very nostalgic for me! In 1980 I used a Forth interpreter I wrote for a undergrad project to implement a message based language as a way to understand Smalltalk as it was described in Byte. Fun times.

This was written by Chuck Moore : 1) FORTH is an amplifier. A good programmer can do a fantastic job with FORTH; a bad programmer can do a disastrous job. 2) FORTH is a polarizing concept. There are people who love it and people who hate it. It's just like religion and politics. If you want to start an argument, say, „Boy, FORTH's really a great language.“ 😂-- ( and this is me : This concepts have not changed in over 50 years of Forth existence, so we should say Chuck was right ! 🙏)

A former coworker of mine has moved on to work at NASA and he writes FORTH for a living. He writes other stuff to be sure, but he does also get paid to write FORTH.

BASIC was never difficult to fit in to 64K. Like Forth, there was an underlying OS tied in to the BASIC ROM. Standard versions of the ubiquitous MS BASIC were usually only 8 or 9 KB, and Sinclair's ZX80 BASIC and OS were crammed in to a 4K ROM. Compilers for most languages on old 8 bit home computers were quite cumbersome and/or memory intensive.

As a teenager in the 80's I learned BASIC, Z80 Assembler/machine code and Forth on my ZX81. After that I got a Jupiter Ace after I think it went into administration and the stock was sold off cheap. It was a great unique forth experience as you could edit already stored words (that you had entered) without using the clunky page system other forth implementations used. The ACE failed as Forth was never going to be mainstream, and the Spectrum came along with colour and sound. After that I got an Amstrad CPC464 and I typed in the FIG-Forth source code (About 43KB!) to get Forth running on it. Doing that was very educational as about 5% of the code was Z80 Assembler and the rest was in Forth - nearly all the source code is written in Forth itself! It was so bloody elegant! The attraction of Forth for me was it ran close to machine code speed but still being a high(ish) level language.

I had the high honor of working for Randy Dumse at New Micros back in the 80's. I was the sole developer for the first version of Max FORTH which was the FORTH embedded in Motorola's 68F11. Randy had previously written Rockwell's 65F11 FORTH and had to have a clean room implementation for Motorola. He was strictly hands-off the coding but a tireless mentor in the philosophy of FORTH. Your thoughts are right on point. If I may add a little, one of the beauties of FORTH is its utter transparency. The dictionary, for example, isn't a mystery. It's a linked list, grown in a linear fashion. When you begin a colon definition, for example, a new head is linked to the dictionary and FORTH shifts from immediate mode to a compile mode. The words (commands) you enter aren't executed. Instead, the address of each word's body is added to the end of the dictionary. There are variations, of course, for things like headless dictionaries. A head is basically a name, a dictionary link, and a link to a body. A body is a pointer to an interpreter followed by whatever data the interpreter will like. Since a word has an interpreter pointer followed by data for the interpreter, I've always thought of FORTH as an unheralded precursor to object programming. Writing interpreters is a little like writing class methods, sort of, if you squint a little, and the body can be structured data like class attributes. The two traditional stacks, data and address, are an indispensable part of FORTH's power. Another wonderful thing is the inner interpreter, NEXT, which may only be a half dozen (or fewer!) assembly language instructions. That's also tribute to the elegance of FORTH's W and IP pointers and creative use of indirection. FORTH may be lost to the mainstream today, but it is a highly effective tool. I've often thought if I were stranded on a desert island with a PDP-8 without an OS, I would write a FORTH system via the PDP-8's front panel toggle switches. Then I would write a word processor in FORTH. Then, of course, I could finally write my message in a bottle in proper style. Far-fetched? Nah, I've never been marooned but I've already done that sort of coding. Fun fact - to this day, Oracle servers (formerly Sun) boot to an "ok" prompt. The Sun/Oracle lights out manager has always been written in FORTH. It's also fun to horrify coworkers by adding new words on the fly. Detailed knowledge always has its perks!

Yes, I also still have a Jupiter Ace (as many do here). It was from an era where Forth did make sense, as a programming language/tool. And especially before 1983, too. But then later on memory got cheaper, processors could handle more bits, and so on. Forth lost its shine, the languages moved on from the compactness and other qualities of Forth. One prominent sample from history, that I haven't seen below commented upon, is the word processor/personal computer: the Canon Cat. It was designed by Jef Raskin, and as we all know really was the man behind the Apple Mac. It used Forth. Another example is a game, of which I can't remember the name, but the programmer used Forth throughout. So, is it useful today? I would argue as a learning tool/language yes. Why not? It gives another access to the machine, which perhaps the ordinary imperative languages do not. It gives you insight into constructions and ideas you might not otherwise have had. That also goes for Prolog, or e.g. lambda calculus, of which I am at this moment trying to make into an assembler standing on a non-von Neuman machine ... probably someone else already did that. But the point to me is that I learn something, to me, new!

> humans naturally think in procedures _citation needed_ For me it's much easier to think in functions. So I'd guess it's more of what we're used to than what is natural. Like yeah, some problems are inherently procedural. But the vast majority of data processing is way better served by composing data transforming functions. Shell pipelines are a limited example of that, but for an undeniable proof just look at Excel.

Regarding why you'd need Forth today on these new fast, Raspberry Pi RP2040, I can't help feel that using something like MicroPython on the RP2040 is like throwing its power away. Precisely because it has more power, I'd rather harness its power with Forth.

(11:30) did he say that BASIC isn't turing complete? Of course BASIC is turing complete. In order to be TC all you need is the ability to simulate a turing machine. ie a piece of tape with symbols drawn on it, and the ability to move around on the tape, and edit it based on the internal state of the machine and the symbol on the tape. All a language really needs to be turing complete is the ability to execute code and define and maintain a state whether through memory, variables, registers, whatever, a jmp, goto, or gosub command or some mechanism to change the program counter/move code execution to somewhere else in the code, and some sort of if/then or switch command which allows the machine to make decisions based on the state (a for or while loop also would work for this), all of which BASIC has many times over. You could actually cut it down hard, just have "if", "goto", some variables, and a bitwise nor, and you could do anything computable (given enough time and memory that is) I'd be curious as to what the argument would be to say that BASIC isn't turing complete.

FORTH can teach the modern programmer 3 things. The first is how to name functions well. The second is not to write functions that are overly long, The third is not to have to many levels of nested logic within a function. Classical FORTH is written with a block editor that is designed around 16 line of code where each line is 64 characters long. The trick to writing functions that are less than 16 lines of code long. The trick to this is to decompose the project into very short and well named functions. If you tired to write more than 16 lines of code in a function, it was natures way of warning you that were approaching the problem wrong.

I've dealt with FORTH a few times over the decades and enjoyed it. Knew some people that purchased SPARC based systems with no O/S just for the OBP FORTH interpreter. P.S. Good shirt.

I used to use a HP48 calculator during the college days, programmable in a FORTH+LISP derivative (Reverse Polish Lisp). Man, it got ingrained in my brain.

Re: The mid 80's and FORTH (and FIGFORTH and FILEFORTH)... At the time a late 60's early 70's CT Scanner system was getting a modern refit into the next generation of CT machines. Taking an older idea and adding all the newest technology available, allowed a massive reduction in footprint, noise, thermal output and amazingly, cost. When using custom made system controllers and mini-mainframes, you had to design the artwork, research the components, write complex software in multiple languages, create sometimes lengthy and incredibly hard to follow electronic flow charts and timing diagrams, source hundreds if not thousands of discrete components AND making changes later was a costly and time consuming nightmare. Enter the age of 32 bit Motorola 68K processors and its little brother the MC6809. The off the shelf 68K boards were a fraction of the cost of a Data General or Elmer Perkin 16/32 bit processor/memory/chassis and storage. This is when one of the fastest 192Mb hard drives the size of a washing machine cost $37,000 w/Controller. Interconnecting the systems required tedious hardware interfaces and in some cases, an intermediary interface. $$$$ TIME TIME TIME... The off the shelf 68K and 6809 systems had available interface cards for driving every kind of load, interfacing with all known data transfer methods and storage system. One of the nice things about FORTH is along with the speed, an entire interconnected very complex system can be put together with 3 or 4 wire serial links and instead of having to dig through volumes of machine specific schematics and documentation, you had a same as card cage in each subsystem, using the same basic control cards, doing the same job, just with different FORTH coding. And the cost was almost 1/10 over design and implementation of custom control systems. And with the dictionary method, commands came as meaningful statements of what you wanted to do. Recalibrate (moves a device to a known ZERO position) Set_Position_To_+10 (moves a device to 10 degrees / units / inches...) Set_Position_To_First_Index Increment_Index Decrement_Index 10 1 Auto_Index_Test 10 1 Auto_Index_With_Scan etc... Diagnostic variations might be: 10 5 Recalibrate_Loop (runs the Recalibrate routine 10 times with a 5 second pause between each cycle) 10 1 Auto_Index_Test_Loop Generate_Index_Fault And so on. A single output could be designated as an oscilloscope trigger for each command execution, allowing a technician to easily follow what is happening. And, a lot of the control modules, even though they controlled vastly different subsystems, would have the same basic program structure, making it much easier to understand for troubleshooting. A subsystem microprocessor (6809) running FORTH might have a serial command input from a remote system AND multiple serial inputs and outputs to other subsystems, as well as a keyboard connection for local diagnostic purposes. What can it do? Everything the main control system does and sometimes more. Setting up diagnostic loops becomes a simple task and if done properly, as well as working the same on each subsystem. The method of building commands from the ground up creates a clear and repeatable way of doing things. Where with custom machine control modules, you end up with something unique for every subsystem.

A first cousin of Forth is Postscript. It''s so old fashioned that every PDF document uses it,

Back in the day , every time we designed a z80 , 6800, 6502 based board the first thing we did was install an eprom forth. This allowed us to exercise / test the hardware - enter on a serial terminal and then test with the oscilloscope . Was great 👍

Saying that BASIC isn't Turing-complete is only true in the most pedantic sense, in that most implemented forms of BASIC are not unbounded. Most languages aren't Turing-complete in that sense.

I loved Forth, we were introduced at university by a chap called Professor Sartori-Angus. Back in the day Byte magazine had an international game competition where you could submit your code for a game and he won this for his creation "Cosmic Conquest" which was written in Forth. I still have the game on a floppy disk, it was written for Apple II computers and I still have a couple of those old machines as well. Jeez that really dates me.

In 1976 I bought the recommended calculator for my university physics class, an HP-25, and discovered RPN. In the 80s, i played with Forth for a while.

Forth is the basis of “script” which is Bitcoin’s smart contracting language. Bitcoin is very much like an embedded system - every byte and cycle is very expensive.

A very cool application of FORTH is in the book ‘Cellular Automata Machines’ by Toffoli and Margolus. You can use the book to, among other things, to set up very compact models of things like gas diffusion, magnetic domains in iron, and surface tension. It’s a very hands-on (keyboard) way to learn some tricky physical concepts.

I met Chuck once, at the M.F. Software Development Conference in 1989. As I was a fellow speaker and featured writer at M.F., I got to hang out with him a bit.

Thanks for this! For some reason, I was just thinking about all of the languages I know, and I thought of Forth. I was a tech working at Texas Instruments in the mid 1980s. (I was at DSEG, on the team that designed TI's 1750A chipset.) At the time, before TI migrated fully to more industry standard design tools (Cadence, Mentor Graphics, Synopsys, etc), many of the design tools we used were developed in-house, and at some level, programmable using Forth. Memory fades after 40 years, but IIRC, aspects of the GUI could be customized using this language. I remember it was fun learning and working with this very unique language.

Thanks for the interesting video. I wonder if my very brief experience of FORTH is shared by any others? I was fortunate enough to have access to a BBC B from my father's work. So access to BBC Basic and any other language of the time I cared to use. Even with BBC Basic I soon wanted more speed, couldn't be bothered with assembler, so gave FORTH a go... quickly changed my mind, and started using BBC Basic's inline assembler for speed-ups. I suspect FORTH is still used a surprising amount because those who get on with it it's probably very convenient for a bit of quick code. Also people are creatures of habit, so why change what you are doing if you still make it work? ...and damn the inconvenience!

FORTH is a technique, its not really a language in the sense that BASIC is. Most people think its "the world's first write only language" that was developed for tiny processors, an antique for retro diehards. Its actually a handy way to implement specialized command languages -- think of the simplest program being just "MAKE IT WORK" with the programmer merely having to define "MAKE", "IT" and "WORK" for the user. Incidentally, the simplest version of BASIC I've come across is implemented in a couple of screens of FORTH.

I still have a working Jupiter Ace with the add on 16k memory pac. The reason it failed to gain acceptance was the monochrome video output which was more ZX80/81 in quality rather than the capabilities of the Forth language, the competing BBC micro and ZX Spectrum of course had colour. The ZX Spectrum had its own Forth package later on, who remembers White Lightning? Although intended as a games development package, it also did the more mundane stuff really well. Most of the BBC broadcast engineers in the 1980s & 90s were taught Forth on a Zilog Z80 as part of their engineering course. The system was designed and developed in-house and took everyone from the basics of programming to hardware control. I'm guessing those skills came in useful when other embedded systems became more common. I find a standard calculator hard to use after years of using a Sinclair Scientific and a HP35S. RPN is difficult to get out of your mind once it's got in and I still play with Forth on a Raspberry Pi Pico.

There is a guy called tsoding daily who created his own version of forth and bootstrapped it with python, why it is called porth ❤

Forth is one of the most concise languages ever devised. It consumes microscopic amounts of RAM, and for constrained environments could be very effective. It was developed for motion control, and takes almost no resources. It was embedded into the IBM PC Microchannel addon boards, as IBM licensed Data Generals FORTH based system that allowed board makers to write a small program that would allocate interrupt addresses, etc.. A much better interface board than PCI, but IBM insisted on a royalty so the industry did not adopt microchannel. FORTH is one of those "write only" languages which are super hard to read. However, a fancy IDE would make it a lot more tractable. It is possible for a devious programmer to redefine the meaning of the symbol + which will confuse the heck out of the reader. Just like LISP, it permits someone looking for job security to ensure nobody else will ever figure it out. One of the reasons it isn't employed much. That 1% of malicious authors ruined it for everyone.

Surprisingly, this ticks every box that I need for an onboard programming language that I will need for an OS project I have been planning for years. It will run on the TI-84+ line of graphing calculators - a Z80 based embedded platform that looks like a supercomputer compared to the other Z80 based computers in this list, so I can be confident it will run splendidly there too.😊

My strong belief is that Forth only _really_ makes sense if the person implementing the language is also the person writing the Forth program. They should evolve together. The reason the standard Forth vocabulary is so alien is because it wasn't primarily designed to be easy to use, it was designed to be easy to *implement*. If you can figure out how to make the program work with existing simple pieces, _and_ avoid having to add a complex new feature to the language at the same time, that's a win-win scenario from Forth's perspective. And if you have a full understanding of how your Forth system works, then you have total control - you can extend it arbitrarily, to include exactly the features you need. You can add a cooperative multitasking system to a Forth in an afternoon - I've done it several times. Try that in C.

Forth was a joy to use back in the day. Compact, fast, and easy to code when you got the knack. On embedded systems with limited speed and memory, an application could be far more sophisticated than would be the case with any other high level language. If your code was well designed, at the top level it would read easily for even a non-Forth programmer to understand. These reasons are also why Forth is still used today in microcontrollers and hobbyist SBC applications.

I doubt it, however, I've seen big industry keep on using 486's as they are super stable, cheep and don't have spectre and meltdown problems. Industry, where the parts of the machine are 100's thousands of dollars, want to keep the old controllers as long as possible, ensuring no possible outlier bug from a newer revamped PCB and the programming there of.

My introduction to FORTH was back in the 1980's when I was working with a researcher at NASA GSFC, who was developing applications for the joint Goodyear/NASA project, the Massively Parallel Processor (MPP), a 16,386 single-instruction, multiple-data computer. The researcher (or maybe someone else working with him...my memory is fuzzy) had written a "parallel" implementation of FORTH to run on the MPP. The "parallel" features implemented support for the MPP's architecture, which was a 128x128 array of CPUs, with a variable word size. Each CPU had access RAM that was configured as any grouping of individual, sequential bits. The FORTH implementation exposed variables on the MPP as 128x128 arrays of data with a configurable number of bits for each element of the array to match the architecture of the computer. Operations on such an array would take place on all 16K CPUs at once. Of course, the language also had "scalar" variables that were just local to the CPU, but the bread and butter were these large arrays of data where all the interesting processing took place. As noted, because of the way it works, including the use of RPN, FORTH is relatively simple to implement as compared to other languages and frameworks. I believe that was the motivation for using FORTH in this application, as it allowed for a much more interactive/immediate way to program the MPP as compared to the "Parallel C" that was also in use at the time. Personally, I found FORTH very easy to learn. I picked it up quickly and was able to be very productive in it in a short period of time. I always admired the choice that group had made to use it, and the way it enabled rapid development of a variety of applications for that unique hardware. Oh, and speaking of RPN, you can pry my HP-16C calculator from my cold, dead hands.

The extremes to which you can take forth's minimalism are absurd - someone fit a forth system into a 512 byte boot sector. Granted you needed to punch in some wizardry to get from the inital system to something usable, but you could bootstrap a full-featured system from it with enough effort

First contact with Forth was back in '76 when a couple advanced students who'd implemented or ported it there announced its availability on the time-sharing mainframe powering the optional computers classes of the high schools in my city -- adding to Fortran IV, Dartmouth BASIC, and assembly language that were available on it. There was respectable attendance at the initial presentation, on the order of 40 to 50 people, dominated by math teachers who were teaching computer classes on the side, and otoh interested students like myself. The presentation quickly turned into the successive detailing of Forth verbs. After an hour, people were tiring from busily taking notes. My fond memory is that of a collective gasp when I reflexively asked about the verb EQU just presented as the means to attach a symbolic name to an integer (interpreted as a pointer) what the difference was with the verb CONSTANT that had been presented 45 minutes earlier as the means to attach a symbolic name to an integer (interpreted as such). [the response I got is that these indeed were aliases]. A couple points on what you present. First off, it's not accurate to imply that Forth isn't a procedural language. While salient and somewhat difficult to wrap one's head around (depending among other things on the word order in your native language), Forth's RPN substitutes for the syntactic services provided in more familiar languages which typically hide it or an equivalent under the hood. It doesn't really change the underlying programming model (with the caveat that IIRC it doesn't provide the infamous GOTO). Second, it's a bit of a pity you don't dwell into the implementation, beyond pointing out its compactness and efficiency. My memory of reading the source is one of extraordinary simplicity. On top of an astonishingly thin bootstrap assembly language layer, most of the interpreter/compiler is written in Forth itself and is extremely straightforward (once overcome a first blush impression that RPN is antithetic to "straightforward"). Although simpler, it prefigures the meta-circular interpreters exhibited as teaching devices for the likes of Scheme or Smalltalk.

I used to use Micro Motion Forth on a single board CP/M computer. We also programmed our spectrometer equipment in Forth and it was setup so that users could make their own routines using Forth. It was an amazing program, more of an operating system in itself, and very easy for users to make modifications to their routines just by defining new routines (called protocols).. We stored the programs and a user modifications on tiny cassette tapes that would take 5 minutes or so to load. I suppose I still have a dusty Kaypro computer in the lab with forth still on the 10 Megabyte hard drive!.

I not only use it - I still write Forth systems from scratch. My whole early career revolved around embedded development, and there's really no better language for dickering around with new systems than Forth. It has its limitations, but down there at the bare metal layer it can't be beaten. A *good* Forth will include an assembler wordset, so it lets you do anything you'd think about doing in assembly. And there's no limit to how much you can extend it. If you want advanced capabilities not present in the system "out of the box," create them. You can have literally anything you want - you just have to build it.

I wish i had a Jupiter Ace ZX81 Style forth machine.

"Banks dont need to change their software"? Are you forgetting the time an entire bank crashed because someone put an emoji in their password?

I wrote a Forth in Z80 assembly for a TRS-80 in the 80s then couldn't figure out what to do with it.

I'm a little surprised, but I didn't notice any mention of Apple, Sun, and HP who all used Forth for their firmware for quite awhile. Boot up an old PowerMac into firmware and you're in a Forth interpreter. BTW, I truly enjoy the channel, keep up the great work!

Forth is a little before my time, but we were one of the last years to learn about it at school in computer science. I grew up in the 80s and started with Atari basic. People ask me how their children should get into programming - I'm often tempted to suggest buying them an 8bit computer, so they learn to program and understand the computer's limits, performing big tasks with small code. It's easy to become complacent writing inefficient code knowing a fast processor will still rip through it. I now program a lot of JavaScript based Adobe After Effects expressions that are interpreted as you scrub the timeline, so efficiency is important when the animations become very complex. Often wish Adobe offered a way to compile them! Always good to have a few spare sheets of melamine! 😀

Back in the 1980s we had an amazing film motion control camera called an Elicon that ran Forth 79. It ran on a PDP11 with 16k or RAM and total storage was 2 x 8 inch floppies which each held 500kb and were really sensitive to dust which was unfortunate because the motion control stage was very dusty and every now and then the system would crash. These things were fast and powerful - Roger Corman's studio bought one and put a 35mm movie camera through a wall within days. The UI was text based a dumb terminal and not very friendly. It was all 16bit integer based and did a nifty sleight of hand with decimal points to fake floating point numbers. The capabilities of the thing were amazing for the day. If you knew a little basic Forth programming you could get it to pivot a camera around the tip of a 12 inch borescope (optical device rather like a medical endoscope). By and large the only real issues we had were with the analog servo drive hardware. The software worked well. Thanks for the video. I assumed Forth was dead by now.

I think Forth is categorized as concatenative language. I don't think it is only about live code compilation and threaded code. Otherwise languages like Cat or Factor would appear. It brings that unusal symmetry between inputs and outputs that many languages don't have.

Like the deadpan delivery and remember forth fondly, but you talking about greybeards and sunken cost fallacy, flashing emacs as an example, and then talking about undo as an example of stacks is the kind of self-own one can unleash without ever knowing he's done it, because you've dismissed the greybeard tools without having sunk that cost. emacs (and vim, from which it took the feature) left undo stacks behind for undo trees decades ago. Type a paragraph or whatever, think better of it, then continue on, five minutes later you realize no, that was exactly what was needed and want it back, but without losing your work since? Yeah. I can do that easily. You can't. Because I've got a grey beard and good tools.

In 1976, I bought a Hewlett-Packard HP-25 programmable calculator (I still have it but its rechargeable batteries are dead and its display is broken), the first such commercially available. It used Reverse Polish Notation (RPN) and was fairly easy to use. It had a 49-steps long programming space, enough to hold a four-variables, four-non-linear-transcendent-equations Newton-iteration-method numeric-approximation system solver, that I programmed to solve a non-linear electronic circuit's activity variables. Each program step contained a key code. Goto instructions occupied two step spaces. It was not a Forth language machine but its programming capability made use of RPN and, so, was compact. I loved it. I wish I had known of Forth much earlier, as it would have made my life much simpler when I programmed a Motorola 6802 in the 1980's in Assembler for the system and application programs of a microcomputer I designed, built, and sold to more than 1,200 small businesses. I had to make them dedicated; Forth could have allowed them to be more general-purpose.

12:25 I know one reason why someone would use it : It is hard , it forces discipline. Programming is all about discipline. Languages based on Algol (like C) are not disciplined in any way. You can point everywhere in the memory, you can convert any bit stream to anything. You can poke anywhere. There's no separation of responsibilities, as C is stored program language, instead of an architecture that separates memory from code. People using C talk about "freedom", that's the problem, they want freedom to do whatever, freedom from discipline. The idea that the programmer is wise enough to choose not to blow up its feet with a loaded shotgun. If you have a shotgun, you're going to blow up things, don't have a shotgun. Yet, at the same time they talk about the perfect discipline required to correctly manage memory, which IS basically impossible discipline, which is why all software made with that language has security problems and memory overflow problems. So that's why Forth , to learn discipline, but for real.

Excellent video. Subscribed. I really need to learn Forth. Been meaning to for ages. It will be an interesting bit of history. Now to watch your RPN video.

I think that, once you've got used to Forth and RPN, it is an extremely elegant language and there is probably a nerd cachet in being able to understand it and expound on why it is so much better than anything else, when it clearly isn't :) great video - thank you!

Everything is better than BASIC!

I sill used FORTH in the 2000s, I see no reason why they wouldn't have taken it forward and they may still be using it now. The company would have trained up everyone when they first started using it and probably had to learn themselves. I see no reason why using FORTH wouldn't be viable today and if you have 30 years using the language, why would you change and lose that huge codebase.

After programming my dad's HP calculator to do engineering calculations, I independently invented my own language, Reverse Polish Notation Interpreter, and ported it several different mini computers and later micro computers. It was useful for plotting, primarily.

There is a version of FORTH on MSDOS that's called ForthCMP. You write your entire program in a text file as you would in, say, BASIC or Pascal or assembler. It compiles the whole thing into an executable program. I once used a debugging package for the Amstrad CPC6128 called Laser Genius, which used a version of FORTH to control the execution of an assembler program you wanted to debug. I wrote various programs on a TRS80, but never actually used FORTH for anything seriously practical. Interesting though.

It's probably more useful for embedded systems like a PIC or AVR where you can easily write a driver for a peripheral and debug it, but less so for something like STM32. The biggest drawback on modern CPUs is the way Forth stores code in the dictionary causes it to jump around, effectively nullifying the advantages of those CPUs with branch prediction and prefetch. Great video!

1. It is pronounced Fourth. 2. Basic is Turing complete and yes you can write other languages in Basic. You can even write compilers in Basic. The reason why basic was slow is that it was interpreted. Even that issue was reduced with the advent of basic compilers. Yes Forth was a hot new thing. I never found it my cup of tea. I often said that it was harder than assembly language. 3. The Jupyter Ace was based on the ZX-81. It even used the same nightmare of a keyboard. It really was a neat idea but there just wasn't a market for it. Too bad really since the back connector was the Z-80 bus you could have interfaced a lot of stuff too it. I could have been the RPI of the day except the cost was too high.

Years ago I worked for s company named Data General. One of their products was a modular system… At our office was one running a demo… creating kaleidoscope images… while playing with the system I accidentally broke out of the program… the code I found looked strange… Found out it was FORTH. Learned enough to view the dictionary, write my own simple code to modify the output to the screen . The interesting thing was that this demo was probably written by some developer to only help sell the product since FORTH was lot listed as supported… Years past…. I had a commodore 64… bought FORTH for it…. Implementation was very bad… ran slower than Basic… Enjoyed your video… brought back these memories :-)

I got a Forth cartridge for C64 as a teenager in the mid-80s. It was fun for a while but I moved on to C when I got a Amiga 500 shortly afterwards. Still cannot help feeling nostalgic about it, though.

I use Forth regularly on both modern and retro machines. Besides being fast and lean, Forth also is one of the most flexible languages I know (and I've seen and used a lot). It "morphs" into the language you need for the project during programming. My last (published) project was an assembler for the CHIP-8 architecture (CHIP-8 is another retro rabbit hole to follow)

Reminded me of White Lightning I bought for Commodore 64. I never did anything substantial though, instead using the extended BASIC and my friend's Machine Lightning assembler.

I'd say its main use these is for embedded systems. It can generate very tight extremely efficient code, either as threaded code or some other abstracted representation of the code that you (as the human) write or directly into machine code.

GO FORTH AND PROSPER

Got an IDACOM PT-520 protocol tester (by HP), that has five (sic!) MC68C000 processors inside, each of them running its own FORTH interpreter. They share the memory space, at least partially, and each can do its own thing. MAIN is doing all the peripherals interactions (disk, floppy, screen, keyboard, printer…), and the rest is running applications. Then there are two MC68EC030-25 doing some protocol-specific things. Unfortunately the MFM hard disk failed soon after I got the machine, so now I'm stuck not sure what I should do with it. Still, I was surprised to see a very professional (and very expensive in 1990s) machine running FORTH. Fun thing was that even during operation one could easily drop down to FORTH and do various stuff, like formatting a floppy, displaying some strings, creating files, doing math…

May the forth be with you.

For those who like to play MUCKs, many of them still use a FORTH dialect for one of their scripting backends! Fuzzball MUCK supports two scripting languages, MUF (Multi-User FORTH) and MPI (no idea what it stands for but it's vaguely LISP-like). Also, older PowerPC Macs used OpenFirmware for their BIOS-equivalent. This, too, is written in FORTH. Java bytecode is also a FORTH variant under the hood. So anyone who's writing Java or Kotlin is indirectly programming in FORTH at some point (although on Android it gets recompiled to Android's own intermediate bytecode).

Back in about 1980 my degree project was to write a forth interpreter and it was really fun to do, the uni stipulated that all projects were to be written in Pascal, the language of choice back then, but the odd thing about forth is that it's mainly written in, yes, forth! My Pascal part was a text editor and some very basic primitives, after that everything was written in forth. Since nobody at the uni was clued up at all on such a whacky language they could only judge by results - it worked, and I passed with flying colours!

I am massive FORTH enthusiast... I loved my Jupiter Ace back all those years ago and have always been impressed by how FORTH gives you such a complete environment with so little. "Files? Nah, we don't bother, we just edit the disk one block at a time!"... but.... do I still use it? Naaaah!

I regular use PostScript as a 2D CAD programming language. Similar to forth it is a stack language. Probably for similar reasons (easy to interpret by marginal computers in early printers), but very much useful to the present day as it is still used to talk to printers (albeit these days often replaced by PDF, with at its heart is PostScript with the Turing-completeness ripped out).

If I recall correctly, the firmware on Sun workstations was Forth. That's about the only time I've encountered it. I gather that embedded systems use it a lot more though.

About the COBOL mainframe thing. No banks do not emulate mainframes. They buy the new IBM Z mainframes which, indeed costs 1-10 mio but its hardware compatible to ALL its predecessors. AS400 s390 s360 way back into the 60s. And yes it’s implemented in hardware. They still run COBOL and jcl unchanged from back then.

No idea why this was recommended. I remember Z80, Sharp MZ800, CP/M, Basic, TurboPascal 5.5, but never heard about this.

FORTH runs happily on a Raspberry Pi Pico, as does BASIC, and many of the current Pico-like microcontroller cards. The BBC Micro used a 6502, not a Z80.

All Barcrest fruit machine games in the late 80's, early 90's were written in Forth....The CPU was a 6809 which has two hardware stacks. One for the CPU and a user stack. Ideal for a Forth implementation.

When you talked about the simplicity and elegance achievable by using the Stack, I knew you were one of us!

I recently got back to my VIC-20 and started looking at FORTH. I think it's pretty awesome to have any kind of language other than BASIC V2 on the VIC.

A lot of current technology can trace its lineage back to FORTH, such as postscript, web assembly, the programming languages Factor, Uiua, Clojure (threading macro), etc...

Why do you state that BASIC is not Turing complete? If Forth is Turing complete, so is BASIC, because a Forth interpreter can be written in BASIC.

I still use FORTH on occasion, but maybe that's mostly because I once wrote a Forth for both NASCOM 2 and CP/M. It was a very nice language on small computers with limited ressources. Got the FORTH calculator Pro app on my phone. Am I old or what ;)

Adobe, the stranglehold company (Postscript, PDFs, Photoshop), used Forth in Postscript, the language that became indispensable in the early days of laser printers (doing amazing things which very few print jobs actually made use of), by which Adobe effectively charged an insidious tax that substantially raised the price of every laser printer sold, until manufacturers scrambled for ways to circumvent it. Forth was used as the built-in programming language of IBM CAD, a rival to AutoCAD during the 1980s/1990s. (Where is it now?) However AutoCAD was just as bad, it used a variant of Lisp as its built-in language, as does the infernal EMACS, a cult religion disguised as a text editor, that many programmers live entirely inside of, and never want to escape.

[Disclaimer: No offence intended, this is just a little rant about times gone by...] I don't know where you learned programming in the 80s, but I (growing up in Germany) learned how to program in Forth on my Commodore 64 in the early 80s already (after I first learned BASIC and Assembler on the VIC-20), and still used it from time to time on my Atari STM in the mid-80s (once I had learned the newer GFA and Omikron BASIC variants on that one, and Pascal, Lattice-C and 68K-Assembler as well). That's pretty much what a typical German computer geek like me (I took part in the first Atari computer camp in Germany as well, btw.) did learn in the 80s, most of my (not-so-)local computer club (there weren't too many of us around in the early 80s in Germany) friends learned all these languages as well. The fun thing was that I actually read the whole UNIX System V documentation (over one meter of books - or over 3 feet of books for you US people 😉 ) as well (yep, the ones with all the hardware and assembler related stuff for low level driver development etc. in them, too), while doing an internship in 1985/86 at a local computer company which used 16 and 32 terminal UNIX machines from Sperry (Series 5000 - the smaller one did already cost more than my parents' house at that time, and that was only the base system price with a single VT220 terminal! And it was my job as intern to install and test it, since everybody else was too busy... 🤓 ). Later on I read all the standard X11 books as well, but that was in the early 90s after I started working full time at SIEMENS (in automation). So yeah, learning Forth (and some other more specialized programming languages and operating systems, ever heard of "RTOS UH Pearl"? One of the best real-time operating systems for automation which I've ever used, and it ran on the ATARI ST! And the Pearl programming language - Process and experiment automation realtime language - was just fun to use. 🥸 ) was really not that special in computer geek circles in Germany in the 80s. If one of course went to a German university instead to study IT in the 80s, one literally only learned mathematics (and maybe some electronics, too), and that was that. Most of the real computer freaks I know from back at that time had never seen a university from the inside, or at least didn't study IT, but some other engineering (I for example attended something which can probably be translated as "technical college" or "vocational college" for IT for four semesters) - we never needed to, to be honest (one of the teachers at that college literally told me that I already knew more than he did, while another one was happy to have the four of us close enough to his level to discuss some advanced topics - he had his own successful company working in the parallel computing industry, and did the teacher job for "parallel programming" on the side), and as far as I know, most of the other club members are still working in research and development departments at different IT companies, because we like to be more hands-on, less management. I switched to systems administration myself after a few years of system programming (operating and monitoring systems in Autobahn traffic guidance systems and power utility services, all on UNIX or real-time OS systems) in assembler and C/C++. Gosh, that was quite a nostalgic comment ranting about "the good old times" - I guess I'm getting old... 🤣😂🤣 (but to be honest: we had much more fun with our old computers then than we have today with all the newer ones).

I had a Jupiter Ace back in the day, and become somewhat fluent in Forth. Had a friend who worked for a computer company that used APL of all things... talk about obscure languages! We actually started a project to implement APL in FORTH just for lunatic giggles. Nerd days....

I never did anything with BASIC, and when I did it it either failed, or was just a bunch of DATA clauses that were translated into machine language without Assembly inbetween. I thought BASIC was a crime against humanity and when I heard that Bill Gates promoted BASIC I became a vehement detractor of that ugly little idiot. FORTH is another story though. I had a lot of fun with Jupiter Ace till it failed electrically. I reprogrammed the fonts, and made floating point multiplication. On Commodore64 I had a graphical FORTH dialect called Visual Lightning or some such, and I programmed (with ease) an astrological chart viewer. BASIC fits no programming model, FORTH very well fits a bottom up function construction model like for example Scheme. FORTH could be used for embedded systems to increase their level of functionality. But it is error prone and not that easy to make test rigs for the software. Embedded in general requires hard testing for robustness.

If you have a Postscript printer, or have any old Postscript documents lying around, you're using (a descendant of) FORTH.

Did I hear you correctly? I thought I heard you say that BASIC was not Turing Complete -- is that right? Can you tell me in what regard BASIC is NOT Turing Complete?

if you search for a device called the Canon CAT with its LEAP keys,, that was written in FORTH with a fascinating man behind it called ... Jef Raskin

Better than BASIC in some ways, if you can stand an ugly misleading syntax. I can't though. For compact coding, I prefer a syntax in the style of APL (not necessarily that language). Special characters bother me much less than familiar words like THEN at the totally wrong place...