FORTH - Better than BASIC?
ฝัง
- เผยแพร่เมื่อ 23 ก.ค. 2024
- Let's look at FORTH, the obscure stack based programming language that nobody seems to use. Or do they?
After getting an Agon Light Z80 computer and discovering it can do things other than run BBC BASIC I went looking at other programs to run on it. I came across Agon-Forth and that got me thinking.
What's the point of FORTH, why's it barely used and is it really as awkward and strange as it appears? In this video I set off to find out for myself what FORTH was like.
This is not a history video or a programming video, this is a video of an experienced programmer trying to figure this bizarre language out. It uses both stacks and reverse polish notation and requires the programmer to keep track of the state of the stack as they're programming. Not unlike how assembly programmers need to keep track of the registers.
I discovered it is indeed much quicker than BASIC, but that it's so awkward to use I can see why it didn't catch on and why computers such as the Jupiter Ace failed. When you've got a choice between slow but readable BASIC and quick but hard to understand FORTH, I can see why people chose BASIC.
But that doesn't make it a bad language at all. On slow hardware FORTH is amazingly fast, and to the people who did use it the inconvenience of thinking in stacks and RPN probably wasn't an issue. It seemed popular amongst science and academic computer users who wouldn't have wanted to learn assembly, but would have been quite OK with learning RPN - their scientific calculators already used that style of data entry.
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'm not quite into my 70s, but as my beard whitened and stomach increased I started planning my seasonal work too. Except I hate other peoples children - badly brought up brats, the lot of 'em. Perhaps being Santa isn't actually a calling of mine.
@@occamraiser ahhh, but instead of agreeing to their gift demands, terrify them! Tell them about Evil Santa who eats children who lie about being good. (some theatrical teeth could come in handy here.)
It's "quirky" if you learn other things first. The first platform I ever actually did any real programming on was my HP-41CV calculator that got me through engineering in college. So right out of the box my mind was "tuned" for stack-based programming; Forth has always seemed perfectly natural and "right" to me. I can sling C and Python around "well enough" for someone who's really a hardware guy by training, but on the calculator front I still stumble if you give me an infix calculator.
what has this to do with fake court summons?
@@PeBoVision what has this to do with fake court summons?
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.
Exactly - it becomes a way of thinking, and a way of "organizing your knowledge" of the low level hardware. Back in those days you could wander into any old bookstore and find shelves full of books that delved down into how computers actually worked, at the hardware level. That's all kind of gone now, unfortunately. Everyone is into web and cloud computing and just takes the actually machinery completely for granted.
what has this to do with fake court summons?
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.
That's fair problem, know what's ironical, this happens with web development all the time.
Second system syndrome is bound to happen.
Think about how many "string" implementations C have.
@@monad_tcp You right but usually is not the language that is the problem it is the frameworks, as the trends, fashions or fads changes so the code and in big systems the attempt to change is never complete and you end with a Frankenstein with 2 SQL database,s 3 queue management systems, 4 frameworks, and 4 other NoSQL databases.
For my point of view if they wrote all using Malboge you could not see the difference.
There is a standard (actually more than one) but there seems to be a problem with the community when it comes to standards. My impression is that many members think that standardization was a mistake (this includes Chuck Moore, the inventor of Forth). One might think "Well, if you don't like the standard, you don't have to use it, you still can write your own non-standard implementation", but some of these people seem not to be able to put up with it and keep posting about how much they hate the ANS standard.
I firmly believe it was okay in super constrained first cpus, and even interactive, but its unreadable next day...
@@7alken The thing with Forth is that one has to be disciplined and keep the words short. Otherwise you will quickly have trouble to understand you own code. But if you do, the code will remain readable (for someone who knows Forth of course).
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.
@jrb_sland
glad to see i'm not the only eccentric kicking around. being a youngster at only 72 yo i also got into the 'rusty edge of technology' i have original copies of dos up to 6.22 and windows from win3 thru win10. but one of my most prized is an Osborne One and it's companion Osborne Executive. Your comment rekindled my interest in the CPM and forth. Soooo do you still have , in a transmittable form, material you use to get the forth onto the computer? I would be grateful if you could forward it so i can try it on my systems. sometimes older is still good. thanks
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.
I am willing to bet that more LOC of Forth environments have been written than LOC of non-trivial Forth applications not including the environment itself...
@@storerestore would not be so sure about it, there's a *lot* of Forth code in space applications. And this code tends to be rather complex.
Speaking of languages simple to bootstrap, LISP would be another one, with the innards explicitly described by the author in the Lisp 1.5 prog man. Using Forth is more the matter of using the right tool for the right job. I used it on a 128K Mac, back in 1985, because it was the only SDK that could fit into so little a memory. Having to interface my code the library written in Pascal was also a very useful experience, it was also about preparing stacks and jumping to the code that will consume it. And typically, this helped me months later to guide a colleague having to interface his code in C with the early Windows API. Many entries were declared with a Pascal Keyword. It was a directive about how the stack was setup, and C and Pascal precisely put the arguments on the stack in different orders. A painful troubleshooting made shorter thanks to the experience of Forth !
I wrote Forth88 and Forth87 for MSDos in the 1980s. Both were floating point versions written in assembly code and Forth. Great fun writing a computer language in itself!
@@jean-pierredesoza2340I'm an amateur system and graphics programmer, I've gotten to the point where I am sick of constantly recompiling my program every time I make a tiny change to something. What do I do? I'm sick of lua and other scripting systems, you can almost guess what I am going to do to ease the process of toying around with my project!
I am going to write a forth derived system for doing the rest of the tinkering, and for the live testing!
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.
I had a Jupiter Ace and still to this day regret letting it go. I had so much fun on it trying to learn forth.
My previous employer (oem controls) used forth as most of the products were enhancements of previous products. And they had a large code base to use as a starting point.
@@TheEmbeddedHobbyist still got one (UK Scotland)!
@@philipoakley5498 You lucky bugger 🙂
Not sure if they still sell for silly money nowadays, which is why I've never replaced it. Last time i looked they were trying to be sold for close to 1K
what has this to do with fake court summons?
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!
I tip my hat to your HC11 FORTH. I spent several years deep in it. What I love about FORTH is its expressiveness. Back in the day I even bootstrapped my own objects on top - Not really knowing what I was doing, but I heard this thing about objects, and code inheritance... I then leveraged my experience with FORTH to do OpenBOOT firmware for a startup doing SSA (Serial Storage Architecture) adapters for Sun servers - What a ride!
And I tip my hat to you. FORTH encourages solution discovery, fundamental tools supporting the goal. Sounds like you did just that in your career.
Be well, sir!@@jamesulrich5076
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!
They didn't tell me about Forth at Kit Peak I went to after a job interview at Raytheon in Tucson. Don't think I would fit in at defense companies. At Kit Peak some former Lawyer who went back to school to study physics was upgrading or installing some experiment on the main scope. She was windy up there.
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.
Have just uploaded the RTX2000 Harris CPU demo video to the cha nn el , and will upload soon the Brad Rodriguez demo of the TTL Forth CPU "PISC" amazing talks in this oktober meeting !
I found super interesting the talk with Leo Brodie and with Chuck Moore. thanks for the great content of your group.
Have not tried Forth on Pico, thanks.
what has this to do with fake court summons?
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.
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.
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
Well, Postscript borrowed the idea, but it’s not Forth. It has data types (and many of them), and it is very specialized to deal with vector images and fonts, as well as complex math, associated with rasterizing them. It was used for the same reason as Forth is used now: to create a unified, small footprint, programmable vector image generation machine that can produce complex images based on set of commands that are small in size. Back then connections were slow, but also identical image on the screen and on paper could be achieved. PDF is a pre-calculated Postscript, it works on slower processor by eliminating the need for complex calculation and thus potentially errors related to them. So PDF is not a real program in a human-readable language, as it’s partially compiled. Still, I have used my Postscript printer as a programmable calculator for simple tasks just for fun. It would do the math and print everything nicely.
No. Postscript is VERY different from forth. They both use RPN; but, there the differences end. They are completely different languages.
My apologies, I haven’t really looked at this since the 90’s, and my recollection is likely a bit distorted. I’m sorry for sharing what (turned out to be) a inaccurate knee-jerk reaction.
Also, it was called FORTH, not fourth because the 1130 file system only had 5 letter file names.
Yes, considered at the time to be a "fourth generation" programming language.
@@lorensims4846 Chuck Moore wanted to create a 4gl, yes, but he later came to like the imperative implications of "Forth".
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.
I still use it, in emulation, as my calculator. My real one has a stuck key so it stays in a cabinet on display. But it's perfect on a phone!
I still use one. And a 50g
The HP 50g is definitely the best pre-touch screen calculator ever, and possibly even better than the HP Prime, too.
Yes, loved the RPN programming in the 48.
Also, in 80's I used GraForth with Apple II
@@arealdevilsadvocate I also bought a 50G once I started to work, but at that time my needs started to move away from what a calculator can deliver, and started to use Matlab (their Simulink package is excellent) and Mupad, so my 50G and 48GX saw very little use after college. I programmed quite a bit for the 48GX, including some SysRPL programs, as a Newton-Raphson solver that integrated in the MSolve utility, I really enjoyed programming using the stack, it was very elegant. Nowadays I don't do so much maths, so Scipy cover all what I need (and programming in Python is a lot of fun).
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.
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 👍
I did that in assembly, my own stack machine, or sometimes PL/M or Modula/Pascal. That hyped Forth looked just like a scrambled BASIC-syntax to me, with keywords all over the place... Too ugly! However, many years later, I understood that Forth was a simple stack machine as well :)
Interesting. These days, I tend to use LuaJIT to put a quicky interactive shell on top of things I wish to test.
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.
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.
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.
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.
Did I hear you say BASIC isn't Turing complete? I'm just going to pretend I didn't hear that.
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.
Greenarray has the GA144 kernels Forth CPU. is a parellel asynchronous 144 FA18 Forth processors in a size of a fingernail computer. The CPU operates at 1.8V, each core demands aprox. 4microAmps at full power. so the total energy for the 144 cores working at full speed is of only 400mA which is really out of this world ! since it works asynchronous, all cores that don´t run a program are normally stopped this makes this CPU a record breaker in power demands. When you told us about the 128x128 array of CPU´s it came immediately to my mind the GA144.
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 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.
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.
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.😊
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 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.
How true. Specially about keeping functions short. The factorisation is one of my greatest pleasures with forth.
I'm glad you're getting into the Agon Light 2. I'd be really interested into seeing what you use it for. I'm considering getting one for my birthday :)
When you talked about the simplicity and elegance achievable by using the Stack, I knew you were one of us!
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 :-)
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'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!
I think there's a brief mention of that around @3:50
@@Bdoserror Somehow I missed that, thanks for the pointer!
The most common application of a forth-like language is… PostScript !
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! 😀
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.
Starflight was one of my favorite games growing up and I only found out much later in life that it was written in Forth.
I would love to see the development environment and full dictionary of that.
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.
Yes, I agree with that. The largest BASIC I’ve seen in an old school computer was Sharp BASIC and it was in a 24K ROM. Tiny BASIC on a 1802 fit into a 4K ROM with room to spare.
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!
As memory addresses got bigger (and so threaded-code implementations of Forth became impractical) byte-code interpreters replaced threaded code.
The last time I played with FORTH was with the Rockwell 68HC11 MCU that had a FORTH built in. It had a quad pin layout that was fun to try to wire wrap up. Anyway, I went and watched your hacking of smart sockets and subscribed. You're a guy I have to keep an eye on.
Still got the Rockwell Manual. Glory days!
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 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)
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.
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!
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.
There is also DX-FORTH for MSDOS which is still developped (latest version is from October 2023). There is a turnkey word which can produce .exe for DOS...
Postscript (implemented in most printers) is a Forth-like language, sharing many features of Forth and probably partly derived from Forth. Forth was used to control cameras for many of the close fly-bys of spaceships in the original Star Wars movies.
PDF as well, if you look for Forth in modern use today.
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.
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.
11:30 Why do you say that BASIC is not Turing Complete? It seems you misunderstand something...
Agreed. It has GOTO!
If your BASIC even has WHILE loops, you need to be able to break out of them dynamically. I always had more primitive BASIC that did not offer WHILE/WEND construct at all.
Yep, very confused why he would say this. Professor Brailsford says it is, that's good enough for me th-cam.com/video/RPQD7-AOjMI/w-d-xo.html&ab_channel=Computerphile
It's at least Turing complete in the same sense that FORTH is. Of course, neither actually has an implementation that is literally Turing complete because they don't have the equivalent of an endless tape strip to work with and thus can't compute anything. Real-world computational devices with predictable execution are reducible to finite state machines. Just with *a lot* of states.
@@storerestore That's one thing that always bothered me: I never* found a list of features are required for a language to be "Turing Complete" (or as much as it can be without infinite memory) besides the generic "it must be as powerful as a Turing Machine"...
For example, when comparing features in different programmable calculators, it's sometimes very obvious that some features make programming them a lot easier, and when it's missing, it feels like you're programming something much lower level, but it's not always obvious which features are essential and which are there just to make the programmer's life a bit easier.
Looking at a language like BF only makes it more confusing, as it's a pretty minimal language that's still TC. Perhaps the single feature that seems to stand out and receives the most complaints about being absent in quite a few models is indirect addressing, especially in the 8 Queens / NQUEENS benchmark.
* actually, I just found a list, but I'm not sure if it's exhaustive, on stack overflow by Gordon Gustafson on a question "What is Turing Complete?"
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.
Although hard to think of cases where it's faster than C, where compiling on a beefy PC will give you fast iteration times.
Have you tried doing embedded work with C? The code may be efficient if you hack it up the right way... but the process and the tool chain is way worse. Forth is the whole package
@@j-r-hill I have some experience in these things. Perhaps you can enlighten me as to a particular use case for FORTH?
These days most C compilers will generate much faster code. It's impressive that Forth can generate code that runs as fast as it does given the simple hardware you can run the compilation environment on and the very simple compilation model, while a decent optimizing C compiler will require several orders of magnitude more resources, but it seems to me like that has become a less useful property over the decades.
Forth systems such as VFX can be used as a cross compiler to compile code for ARM, TI, Intel etc. The code is highly optimized, and compile times are measured in seconds or fractions of a second. On these systems it takes longer to upload the binary to the target than it does to compile it. But the really big benefit is that the binary that Forth code produces is often orders of magnitude smaller than the equivalent C/C++ binaries. It really is an amazing language. But its brilliance arises from how amazingly simple it is. It is completely possible for one person to write an entire Forth compiler and supporting environment all by themselves. I know because I did it. My system has an editor, compiler and no underlying O/S and fits in 16K.
This is possible because the complier is Forth and Forth is the compiler. It may sound like I'm playing word games but I'm not. It's an absolutely brilliant concept, born out of necessity to produce something that could both run and compile on the same machine. Forth probably had the world's first REPL. Prior to Forth, one's only choice was batch processing via punch cards. I don't have the proof, but it's possible that Forth changed computing forever.
I’ve done a lot of Forth programming in the late eighties and early nineties. I used the Rockwell R65F11 processor that had a heart of the 6502 processor, some on-chip I/O (if I recall correctly), and a 3k Forth kernel ROM.
I used it for machine automation and as the embedded system in a commercial product.
It was capable of having bank switched ROM to expand its addressable memory capacity.
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.
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!
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!
One of my favorite languages to play with. Not very active with it now, but I have fond memories of trying to learn it.
Last time I used (and learnt Forth) was to make a program in Minecraft (of all things lol) on a modpack which included emulated Forth computer terminals. I thought it was Project Red 2, but can't find any information on it now. Must have been like 10 years ago
Nice video on a topic many programmers wonder about. I implemented a simple Forth on the Playstation 1, just for fun. But I would rather use C or assembly.
A form of FORTH was used on the Hp48 series calculators. It's called RPL and you could write very complex software in it.
Starting Forth is an amazing book. The funny pictures really do reinforce the material, it's long of shocking, how effective they are.
The last uses that I heard for FORTH was that it was used in some BIOS and still being used to control a telescope somewhere (I bet that there are several that still use it). I liked it in the 80's but I never used it for anything practical. I still remember the Byte special issue with FORTH in the cover then.
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…
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.
> 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.
"Banks dont need to change their software"? Are you forgetting the time an entire bank crashed because someone put an emoji in their password?
Banks suffer from the same problems that everyone else does who have a large legacy code base. The old code gets progressively harder to maintain, especially if written in languages that have fallen out of favour in the programming world. Code evolves to meet business requirements, and in that evolution needs to be maintained so you can’t get away from it.
In the world of banking for instance, many systems were written with the idea of overnight batch clearing (BACS in the UK). Then the government said that all banks needed to support faster clearing, so they needed to be updated to support the FPS. Internet banking became a thing, so code needed to be glommed on to support a web front end etc.
Now imagine the sad reality where that crash costs less than hiring multilingual COBOL experts to rewrite the supporting systems in something that's less like COBOL.
@@storerestore the sad reality is that there becomes a point where banks HAVE to replace the old code with something newer and more maintainable (I know this for a fact because I was working for a bank while they were running a project to replace their General Ledger systems throughout Europe). It simply becomes too expensive and complicated to maintain beyond a certain point and they have to bite the bullet.
@@stevetodd7383 I went to a talk by a developer at my bank, about their use of COBOL. Much of their COBOL codebase is actually left largely untouched. If it didn't work as intended, they'd have known about it some time between now and the 1970s. Of course a lot of supporting code has been moved to other languages. For example, authentication is handled by a much more modern electronic ID system that all banks and government agencies in my home country use, and there's a hefty translation layer between the web/phone app APIs and the COBOL code.
But sure, there is COBOL code that needs to be changed to account for new features. For example, handling EBCDIC encoded strings is a thing of the past, and Unicode support has been added where relevant. For that kind of work, they hire any decent developer and give them a month long course in COBOL (while on the payroll). Probably still expensive, but much cheaper than getting expert consultants.
Point is that there's no one-size-fits-all answer to this question. For a lot of banks I really think a total rewrite isn't economically feasible or at least that it's not worth it. For others, the situation may be worse. For example, if they only want to hire or consult developers with existing COBOL experience that's probably going to cost them a lot more than offering a course.
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.
Servers as well :) How many times someone had unplugged a serial console only for it return to the ok prompt !
Also the pre intel Apple macs - they all had a simple bios like firmware system which was Forth.
"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.
As for why one might prefer Forth over other languages, it should really be quite self-evident -- the interactive (outer) interpreter provides a natural command-line interface from which you invoke small segments of your program during testing. Need to run an experiment? Just whip up a quick colon definition or two and invoke it. Need to integrate that code into a larger context? Put it in a source file or code block (yes, I still use blocks), and recompile in seconds. Not tens of minutes to hours like a lot of deep embedded environments. No need to deal with ELF/COFF file format conversion, binary extraction, etc. Just straight source to binary code. THEN, once the system is more or less where you want it, you can use your Forth interpreter's features to create a turnkey application, wherein it boots into just your code (no interpreter, no dictionary, etc.). Seconds, maybe a minute or two at the slowest. Not, "Oh shit, we found yet another error in team X's code, collaborate with them, grab a fix, spend two days integrating it, spend an hour or two compiling, waiting for CI/CD to finish, deploy into whatever format you use to hot-patch a system, and test, and oh shit, found another bug after two days of effort."
Why not just use python then?
The difficult part of Forth is as I see it that it's not following the normal programming paradigms, so developers that have started with other languages basically have to re-learn.
I see it as a language that can be very useful for embedded applications where you work with integers, like servo controls. I did toy around with it a bit on a Z80 computer in school and was able to plot a measured curve of data faster than in Basic - and that was a semi-compiled bytecode Basic, not a fully interpreting (Luxor ABC80) that was considered to be a very fast Basic.
Unfortunately I just got "weirdo" looks from everyone then.
Absolutely agree. In one interview 30 years or so ago I was asked to write a short program in PostScript. Not many people write PostScript by hand and I'd not done so before, but a quick flip through the reference guide was enough to make a fair stab at it. I got the job.
It was a good interview question in my opinion. Makes you think a bit. Later on when I was interviewing people I'd try to get them to do similar interesting things to find out who could.
@@ukyoize It's the bootstrap problem. Back then you often had to start with flipping switches to load programs, or other 'crude' methods such as paper tape from a teletype, so FORTH had a really small inner interpreter allowing an easier start up. Python etc. all require a much larger ecosystem for the foundation level entry (think raspberryPi etc).
It's ultimate downfall is that it's just too flexible/good, and without someone holding the line it diverged all over the place. A bit like Git..., but that does have someone holding the line.
LOL I wrote a Forth program yesterday (on a MSP430 dev board, a tiny microcontroller with a puny amount of memory) and talked about it on discord... which is probably why YT recommended this video today. :) I'm not a Forth apologist though I have been using it on and off since the 1980s - it still has this place though on these embedded systems that can't spare much in terms of resources. Like a toaster, maybe. Or a rice cooker.
And yes, in case you were wondering - my HP49g is right here on my desk beside me. :)
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).
Funny I had to output from an enterprise silicon chip design system to PS for printing.
I don't think RPN is a serious objection to a programming language, unlike infix it doesn't require learning the precedence of a large set of operators.
The presenter doesn't appear aware that the micro revolution followed a mini-computer one, where UNIX emerged.
BASIC already had a terrible reputation because of its reliance on line number based sphagetti, which tended to cause unfortunate habits.
FORTH belongs in a museum. As for PostScript, both the language and graphics model are antiquated as they stand, but there are some interesting ideas that could be revived. For example, add lexical binding so you get proper reentrant local variables.
@@lawrencedoliveiro9104 that's pretty ironic considering local variables are allocated on the stack 😆😆
@@RobBCactive You need reentrancy for their names as well. PostScript as it stands does not make that easy to do.
A first cousin of Forth is Postscript. It''s so old fashioned that every PDF document uses it,
Seemed like it would be a good way to abstract vector instruction sets since it was a step below C but above assembly.
Enjoyed that very much. I knew Forth but did not know is was written to serve needs of astronomers originally.
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.
Here in Hull in the UK my friends Alan Winfield and Rod Goodman built a commercial computer whose actual machine language was Forth. Nokia used it to build simulators of radios.
I've used a Forth-like base to produce music software. Its simplicity and transparency makes it idea for this kind of work. I've also used it as the basis for genetic programming.
For me it remains a perfect model.
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!
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.
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).
I wrote a Forth in Z80 assembly for a TRS-80 in the 80s then couldn't figure out what to do with it.
There is a guy called tsoding daily who created his own version of forth and bootstrapped it with python, why it is called porth ❤
I see a C enjoyer in the sea of comments.
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 wrote my version in Z80 assembler after reading about it in a copy of Byte and buying a book called "Threaded Interpretive Languages". At a certain level I found Forth very similar to Lisp in that you can bootstrap the language from a small minimal kernel using itself. The main problem I had was that Forth is very much a "write only" language; come back to look at code you wrote more than a few weeks ago and it's probably easier to rewrite it than understand what you did.
All languages are write only languages if you don´t follow the discipline of commenting your code ! :)
Very true :) But I'd say that even when you have good comments describing the purpose of a new word, along with how it might transform the stack, it is still quite difficult to determine how it achieves it's purpose for anything other than fairly trivial cases just be inspecting the source. In this respect it can be more like a high level assembler for a virtual machine than a traditional language. That said, I've always had a soft spot for threaded languages in general and think studying how they work might provide a nice introduction to a class on compilers, especially code generation.
That book is phenomenal - probably the shortest implementation of the forth style interpreter loops.
LISP is still a language ahead of its time in many ways, unlike FORTH.
@@lawrencedoliveiro9104 I would say both are remarkable languages, ahead of all time in their simplicity and capacity for growth.
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.
My first job was doing data acquisition from a Philips DSO over the GPIB bus and processing the data in Forth on a Mitac 286 with that a maths Co-Pro. Fun times !
This video is great. Well done.
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!
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.
Did you notice my youtube name? That's from that FORTH book you mentioned. :)
I don't do much with FORTH any more but I sure did enjoy the years I used it. That was in the FORTH-79 and FORTH-81 days. I had a little Z80 board I'd designed for use in embedded control systems and FORTH was a perfect fit for it. I could deploy a computer that had FORTH and the application on it, but it also had simple network support so I could update the application without having to retrieve the machine, burn a new ROM, etc. Pretty good for 1981. And you could fit a lot of code into 16K of RAM with FORTH.
I did a forth project on a 6502 1Mhz system in 75. Aimed to control factory systems. Once you get the hang of it it is fun…. Havn’t seen it in years…. This was a fun trip down to memory lane….
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!.
Made a good living programming FORTH back in the day, and was the proud owner of a Jupiter ACE. There are a couple of versions of FORTH for the Raspberry Pi; I'll have to check them out! Thanks!
I use parts of forth all the time. Although the programming lang is C, the Forth threaded code and simple virtual machine are things I use regularly. Dictionary lookup is also regularly used. One thing about the Forth you use is to understand how the compiler is implemented. You can define new syntaxes and extensions in Forth. In the 80s I wrote a C compiler is Pascal, then I wrote a Forth vocab that looked a lot like Pascal so I could use Forth to compile a simple version of C.
Chuck gave a fascinating talk at StrangeLoop about his work on the Green Arrays chips. Would love to have had a chance to meet him.
I learned Forth at school, the teacher was a bit of a weirdo and ordered half a dozen Jupiter Aces, bringing them out for the more savvy kids who wanted to go beyond BASIC programming. I found it fascinating but I never went back to it. I ended up working in embedded systems for a while so it wasn't wasted!
(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.
Used FORTH when I worked for a buddy that had a contract to design remote monitoring devices for Nuclear Power Plants. We also used it when doing contract work for ATARI when they designed multiplayer arcade machines to control the intercommunications between arcade cabinets and the central processing unit.
Very interesting. I used to go to school with the guy who created the Fignition. He was very into Forth back then as well. Mr J. Skidmore.
I would like to see you cover SuperBASIC as prototyped on the Sinclair QL and compatible systems. It tried to outdo BBC BASIC for structured programming but was nowhere near as fast as BBC BASIC on the QL. It might have even been slower than Sinclair BASIC on the ZX Spectrum. It did have some interesting developmental features though.
I had both of course on the Sinclair QL, Superbasic was in Rom of the machine, and Forth was loaded from a cartridge. The power of Forth compared to the Superbasic(which was a structured basic, and very good,comparable to Pascal) was huge ! Forth run circles around S.Basic , and depending on implementation and programmer ability, it runs circles around the best C compiler. But Forth´s main strength is not only in the speed of execution, but in the speed of development, where it normally cuts in 1/3 compared to any other language I used. Forth works best near the metal, and on 68K processors you can enjoy some superb implementations thanks the addressing modes of the 68K family.
I wish i had a Jupiter Ace ZX81 Style forth machine.
I had a Jupiter ACE back in the day, and got a lot of pleasure out of it. Since then, I haven't seen FORTH being used anywhere, and I've been working on software all my career, including on embedded systems.
Loved the RPN programming in the 48.
Also, in 80's I used GraForth with Apple II
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.
it is categorized as concatenative because Forth creates lists. A Word is a list of addresses, the dictionary is a list also, etc. The term "concatenative" means exactly a list. And is wrong used, as a "type-less language", which in fact, forth is also ! Concatenative comes from LATIN catena, means “chain”
@@PeterForth not all Forth were using threaded code. Some where literally writing machine instructions. And it doesn't matter how you create your dictionaries. List was just the simpliest way to make lookup. Some systems allowed to strip dictionary completely.
I thought concatenative refers to ability to easily split and join parts of code in Forth as long as stack "interfaces" do match.
P.S. I mostly were familiar with GP-Forth, I think.
@@virkony we are talking about the MEANING of the word concatenative, which means "chain". I think you are talking of DTC or STC Forth models, which also operate in a chain of calls to addresses. this is what you call "machine instructions", is just a list of machine CALLS or JSR operations. But again, a word is just a LIST of CALLS + Address or JSR Address .So nothing wrong in what I am trying to explain. // These kind of Forth´s are called native compilers, and our development ForthWin is the best example of that. Extra bonus, there is no need of dictionary after compilation, all works with machine calls.
@@PeterForth, Sorry. I connot follow what you try to explain.
Sorry, that I misunderstood you and assumed you were talking about implementation when I saw word "list". Yes, Forth language syntax effectively is a sequence/chain of words, context for those words lookup (vocabulary) and execution (e.g. immediate words skip compilation state).
I saw only one version of threaded code (I think it was DTC) and version where indeed compiled words are put as calls making it a "list" of calls (I guess STC). But the one that used calls to words also could emit machine instructions. I also only read "Thinking Forth" Leo Brodie in some old days when I was exploring different languages and nothing more, I think. So my knowledge of terms in Forth language itself are limited.
I might have understood next from your messages:
- "Concatenative" means somethign that can be formed into sequence/chain/list (1st reply).
- Forth is indeed categorized as "concatenative" language. Though there seems to be something wrong in use of such categorization. Though, I didn't understood what exactly. (1st reply).
- Forth is "type-less language" (1st reply).
- Forth can have both linear translation where words are effectively describe list of other words and can be compilers like ForthWin (2nd reply).
Did I missed something? What point you trying to make?
P.S. Point of my first comment was that Forth language itself have more than just concrete implementation. And that's reason why influence of that language can be seen in other languages.
Wow. Had no idea FORTH was still a thing. I was introduced to RPN with my HP calculator in the mid-70s. I became aware or FORTH around 1977 when the lead programmer in our shop became interested in the games we were playing on our PDP-11/60 RSTS/E machine. This stuff enthralled us because we were an IBM 370/115 DOS/VSE house (think punch cards) the DEC gear in our house was quite different.
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.