Forth - How many know about and use it?

[gnuarm]

I've been a user of Forth for a long time, but I've never become an expert.  The only active Forth community I know of is the newsgroup, comp.lang.forth which is fairly active. 

I'm just curious how popular this language this among the hardware oriented crowd.  The language is close to the metal so to speak and its interactive nature makes it ideal for working on or with hardware. 

I know python is popular with the rPi crowd.  Not sure what is mostly used on the Arduino.  I do know Forth is available for those platforms and many others.  In fact, it is hard to find a processor Forth hasn't been ported to. 

Anyone here using it, why or why not?

[JohnnyMalaria]

I used to play around with Forth years ago on my Sinclair ZX Spectrum. I even remember typing in a Z80 assembler listing of FIG Forth.

I hadn't realized it was still going strong and would certainly take a look. After all, the RP really should use a language that uses RP.

[gnuarm]

There are many, many Forths out there.  The one I prefer at the moment is Mecrisp by Matthias Koch.  It is implemented on the TMS430 family as well as many ARMs (a long list of boards supported) and even other devices like the rPi and even an FPGA custom stack processor. 

http://mecrisp.sourceforge.net/

[exe]

At some moment in time I was attracted by its power and simplicity and wanted to use for a microcontroller (I think it was atmega or something), it was in early-mid 2000x. But reverse polish notation doesn't land in my brain. Contrary, forward polish notation is how I think about expressions. I guess that's why I didn't use it.

[james_s]

Isn't Forth the built in language in the ROM of Sun workstations? If so then I know about it and have used it, but I can't claim to "know" it.

[grumpydoc]

Isn't Forth the built in language in the ROM of Sun workstations?

Yes, it is (never used it though).

Postscript is also "related" to Forth, in that it is also a stack-oriented language.

[Syntax Error]

Forth, this is the first mention I've heard in decades! Back in the day, our school had a Jupiter Ace computer. But it used Forth, so no-one knew how to program it. Not even our science teacher, and he knew the Jedi language Fortran. So I expect it became just another paperweight in the headmaster's office.

Go Forth and COMPILE : https://en.m.wikipedia.org/wiki/Jupiter_Ace

[bd139]

On and off. Nothing serious. It’s a thing of beauty though.

Worth pointing out CollapseOS as well which is a Forth implementation of “minimal computing to bring civilisation up again”. Mostly because it’s just about the only software platform that is manageable in one’s head: https://collapseos.org/

[Stray Electron]

  I have the Forth ROM for a HP-71 but never used it. I also have Charles Moore's PolyForth for the IBM PC and I used that way back in the day but it's a self booting 5 1/4" floppy disk so it would be difficult, if not impossible, to use it today. Unless I dug my old IBM PC out of the closet and if it still runs.

  Two friends of mine, Bob Shannon and Steve Robertson, wrote a primitive but extensible OS for the HP-1000 computer in Forth.

[gnuarm]

Isn't Forth the built in language in the ROM of Sun workstations? If so then I know about it and have used it, but I can't claim to "know" it.

I believe that is open boot which is based on the Forth concept. 

Forth is a collection of words (functions).  Programs are written by stringing words together with all parameters passed on an explicit stack.  This removes a lot of the syntax and overhead making it practical to include the compiler in even tiny MCUs.  The compiler functions are available to be used by application programs, for example parsing input numbers and words.  It can be pretty easy to work with and tested interactively. 

I've written a program to manage a test fixture and provide data to the Windows paste buffer so the operator can paste it into a spread sheet rather than have to copy it.  Otherwise my Forth code has all been for internal functions in MCUs for various tasks.

[gnuarm]

  I have the Forth ROM for a HP-71 but never used it. I also have Charles Moore's PolyForth for the IBM PC and I used that way back in the day but it's a self booting 5 1/4" floppy disk so it would be difficult, if not impossible, to use it today. Unless I dug my old IBM PC out of the closet and if it still runs.

  Two friends of mine, Bob Shannon and Steve Robertson, wrote a primitive but extensible OS for the HP-1000 computer in Forth.

Forth has come a long way since then.  Charles Moore has written booted machine level Forths for the PC that he uses to design chips.  One was the GA144 with 144 processors all running at peak rates of 700 MIPS.  It's not a typical massive CPU as each processor node has very limited memory and is intended to be used more like the logic blocks in an FPGA.  I refer to the chip as a FPPA, Field Programmable Processor Array. 

[SiliconWizard]

There is a regular here who is a long-time user of Forth. He'll probably be able to tell you a few things if he gets a chance.

Apart from the Jupiter Ace (which was pretty much as bad as a ZX81  but with Forth instead of Basic), there was this oddity, the Canon Cat, a much more interesting (but obviously more expensive, clearly not in the same league) machine, not well known, the OS of which was written in Forth.

https://en.wikipedia.org/wiki/Canon_Cat

[gnuarm]

The Cannon Cat rings a bell.  I expect I've heard of it in the Forth newsgroup. 

My interests are more along the lines of current use in embedded programming.  I guess I'm curious as to how many (or how few) users of Forth there are in the world outside of the Forth newsgroup and SVFIG.

[BitsnBytes]

I have never used Forth why?

The answer is simple C programming language outshines every programming language in bare metal programming.
However some languages like microPython is gaining fame in some areas of embedded system.

Regards.

[gnuarm]

I have never used Forth why?

The answer is simple C programming language outshines every programming language in bare metal programming.
However some languages like microPython is gaining fame in some areas of embedded system.

Regards.

Interesting that you claim C "outshines" Forth for bare metal programming when you acknowledge never using it. 

I was specifically referring to running on a small embedded target.  I guess these days people consider a rPi to be a small embedded target.  Or are you talking about targets like a CM0 ARM or an 8 bit PIC?

[BitsnBytes]

I was specifically referring to running on a small embedded target.  I guess these days people consider a rPi to be a small embedded target.  Or are you talking about targets like a CM0 ARM or an 8 bit PIC?

Yeah I am talking about bare metal programming. 8-bit, 16-bit, 32-bit microcontrollers. ARM based too like STM32.

Am I wrong? Is Forth better than C?
Sorry I don't know much about Forth, actually I have biased opinion about C...

[JohnnyMalaria]

I was specifically referring to running on a small embedded target.  I guess these days people consider a rPi to be a small embedded target.  Or are you talking about targets like a CM0 ARM or an 8 bit PIC?

Yeah I am talking about bare metal programming. 8-bit, 16-bit, 32-bit microcontrollers. ARM based too like STM32.

Am I wrong? Is Forth better than C?
Sorry I don't know much about Forth, actually I have biased opinion about C...

In one regard, Forth is closely to the bare metal of the CPU than C - namely, the use of the stack. Forth uses reverse polish notation for (just about) everything. i.e., if you want to add two numbers together, you push them both on the stack and then issue the command:

2 5 add .

will give 7 (. prints the number at the top of the stack).

In C, pushing/popping the stack is hidden from the programmer but the executable code the compiler generates will typically push values onto the stack prior to calling the appropriate routine.

However, at the CPU's register level, C closely resembles the metal, as it were. Forth doesn't. Indeed, in some ways, the only way that Forth directly maps to the underlying processor is through the bit length of the word used.

The stack/RPN concept can be extremely powerful. It is neither better nor worse than C. It's different. I am aware than some implementations of Forth exist as usable from within compilers for other languages, such as how many C/C++ compilers can accommodate assembler.

[JohnnyMalaria]

pretty much as bad as a ZX81

What was wrong with a GBP99 computer that gave millions of teens access to something they could only otherwise dream about. All of the ZX-81's peculiarities (and even more so for the ZX-80) forced you to be very creative with your programming. You'll notice this question about Forth as pulled quite a few people like me out of the wood work (i.e., learning programming on cheap computers as teens in the UK in the early 1980s).

[gnuarm]

I was specifically referring to running on a small embedded target.  I guess these days people consider a rPi to be a small embedded target.  Or are you talking about targets like a CM0 ARM or an 8 bit PIC?

Yeah I am talking about bare metal programming. 8-bit, 16-bit, 32-bit microcontrollers. ARM based too like STM32.

Am I wrong? Is Forth better than C?
Sorry I don't know much about Forth, actually I have biased opinion about C...

Until "better" is defined I don't know how to answer that question.  I use Forth because of the simplicity of operation on the target.  Most target processors have enough memory to host the development tool.  Since Forth is interactive that means only needing a PC to act as a terminal and file storage.  Word definitions (subroutines) are typically one or a very few lines and so can be written and debugged interactively at the terminal interface. 

Typically languages like C or python use the PC as the compiler and must use some form of debugger to interact with the target.  I find these tools to be more awkward than the terminal interface.  In another thread someone was talking about conventional languages being easier to debug than HDLs because you can single step on the target.  I can't think of a less effective tool for debugging. 

But I'm not looking to debate which language is better.  I was just asking how many are familiar with it and/or use it.  I'm trying to gauge the amount of interest in discussing it. 

Forth is based on a virtual machine that is stack based, so the language uses RPN.  That alone throws most people and so they never learn the more interesting bits of the language.  So I'm not looking to proselytize or convert.  That is far too uphill a climb for my tastes.  Speaking of tastes, I'm ready for something to eat.

[gnuarm]

The stack/RPN concept can be extremely powerful. It is neither better nor worse than C. It's different. I am aware than some implementations of Forth exist as usable from within compilers for other languages, such as how many C/C++ compilers can accommodate assembler.

I would not say the RPN notation is what makes Forth "powerful" really.  What it does is to relieve the language of the burden of explicit operands along with the burden of the required syntax and typing. 

When designing FPGAs in the 90's I learned VHDL because I was working with the US government, rather than Verilog which is more popular with the comms industry.  VHDL could not be any more opposite from Forth in requiring EVERYTHING to be explicit (talk about typing burden!)  It is functional for me however, because the debugging environments are so different.  With HDL simulations are used to test the design where every signal can be easily probed.  So the REPL method works through simulation.  In Forth it is explicit in that the code can be compiled on the target, run on the target and the result examined on the target.  (Print in REPL doesn't need to be literal and can be examining a signal in simulation, reading a result in interactive execution or reaching a breakpoint and examining a variable in emulation). 

I just find the use of a debugger on a target to be a bit more awkward and another thing to learn, manage, kept up to date and to go wrong.  With Forth everything that can go wrong is built into the language.  lol

[thinkfat]

I vaguely remember coding a Mandelbrot demo on a C64 35 years ago. To see if it was any faster than the built in Basic.

[JohnnyMalaria]

The stack/RPN concept can be extremely powerful. It is neither better nor worse than C. It's different. I am aware than some implementations of Forth exist as usable from within compilers for other languages, such as how many C/C++ compilers can accommodate assembler.

I would not say the RPN notation is what makes Forth "powerful" really. 

The stack/RPN combination, not just RPN per se.

[gnuarm]

The stack/RPN concept can be extremely powerful. It is neither better nor worse than C. It's different. I am aware than some implementations of Forth exist as usable from within compilers for other languages, such as how many C/C++ compilers can accommodate assembler.

I would not say the RPN notation is what makes Forth "powerful" really. 

The stack/RPN combination, not just RPN per se.

Ok, to me that is the enabler that allows the tool to be easily implemented and resident on a small target.  But it is these aspects that make the language useful to me.  Without the interactive command line it's just another quirky language to me. 

There are many words that users write that are not RPN and in fact the language has many words that are not RPN.  For example VALUE is used for a variable with syntax of just using the variable name to return the value and using TO with the variable name to assign the value.  With the word VARIABLE the address is returned and the words @ and ! are used to read the value or to write the value. 

[JohnnyMalaria]

Um, okay. I wasn't really expecting a debate on my opinion. The combination of a stack-oriented programming mentality and the RPN that fits naturally with it is a powerful feature that makes Forth what it is. That's all.

[gnuarm]

Ok, sorry if I seemed argumentative.  Thanks for your comments.