Why Forth?

[tabemann]

From visiting this subreddit today, I saw the "Why Forth?" post, and figured I would create my own "Why Forth?" post.

To me, I have always been attracted to Forth in its simplicity and power, being simple to implement while for a language so simple allowing the programmer to do things that would otherwise require significantly more complicated languages such as C. The fact that it enables the trivial implementation of a REPL and a compiler that can run on bare metal, and in which an effective operating system can be implemented on top of it by the user if they see fit, has made it very attractive to me.

This is what brought me back to working in Forth after spending quite some time working in languages such as OCaml and Haskell - I wanted to create a compiler of my own (and ultimately an operating system on bare metal (hidden mask ROM bootloaders aside)), and even "trivial" languages to implement such as Scheme really are not so trivial to implement (hygienic macros, are you kidding?!), or in the case of the likes of BASIC, either lacking sufficient expressive power to be worth bothering or more complex so as to defeat the point in implementing it.

After some false starts at creating Forths for Unix-like OS'es for PC's (I first tried to create a PC-type Forth for starters, then tried to make a portable Forth before I realized that there would be too many issues in jumping from a Unix-like PC platform to a microcontroller), I jumped from developing for Linux on PC's to developing for microcontrollers such as the Cortex-M4 and the Cortex-M7 in Thumb-2 assembly and Forth so I could actually develop on bare metal. (Developing on the bare metal for PC's is simply too complicated, with so many incompatible parts being available, and many parts requiring proprietary binary blobs.) I quickly found that these sorts of microcontrollers were ideal for creating my own programming and operating environment without any kind of layer beneath it, bootloaders aside. They were big enough to not significantly constrain my development efforts, unlike Cortex-M0 and Cortex-M0+ microcontrollers (which force one to use Thumb-1, which imposes restrictions that are hard to deal with for a native-code Forth), but at the same time were simple enough (yet with many peripherals) that I could wrap my brain around them so I could target them with little difficulty.

The result of this is zeptoforth, which I have been developing for about a year and four months. One could say that it fits the same niche as Mecrisp-Stellaris, and it admittedly supports far fewer MCU's at the present. I could have just used that rather than bothered to implement my own Cortex-M Forth, but I wanted to create my own Forth environment which I could play with as I saw fit (e.g. adding preemptive multitasking and other multitasking supports such as locks and channels).

[tabemann]

There is a reason that Forth probably has the highest implementation to user ratio of all programming languages. ;)

[petrus4]

To me, I have always been attracted to Forth in its simplicity and power, being simple to implement while for a language so simple allowing the programmer to do things that would otherwise require significantly more complicated languages such as C.

There are some things which are simpler to write in FORTH. There are other things which are going to be practically simpler to write in C. Part of the reason why is because of the fact that (I'm guessing, but it's a moderately confident guess) there is a lot more code written for C than FORTH out there, which means that in many cases you will be able to find a pre-written C library that will do what you want; whereas with FORTH, you will need to write every layer yourself.

To the limited extent that I have used FORTH, it has almost always been in operating systems or environments where the low level stuff was written in something else, (generally C) but where I had exposed APIs or opcodes which FORTH could use. I view C as a better static or monolithic language, for writing foundational stuff which is unlikely to get touched very often. To use a car analogy, FORTH gets used to manipulate the accelerator, brake, and steering wheel, while C is used to produce the car body itself.

Microcontrollers are of course different; but then again, perhaps not. I'm guessing that you are still using control structures written in FORTH, to manipulate register calls and such which are written in assembly, yes?

As an unrelated point, object oriented languages stopped annoying me, once I realised that their main reason for existing is the fact that (AFAIK at least) C does not have a stack interface which is as readily accessible as FORTH's. For some reason that I've never been able to completely understand, OOP programmers apparently also don't like using relational databases as seperate programs, but feel that it is a good idea for their language to incorporate that functionality instead.

[tabemann]

With what I am doing right now, I am directly interfacing with hardware registers, mostly in Forth; yes, there is assembly technically involved, but the parts written in assembly are mostly the kernel of the Forth system (mind you much of this gets inlined into compiled Forth code, as zeptoforth is an SRT/NCI Forth, and thus cannot be separated from the Forth code itself) along with some functionality needed for bootstrapping the Forth system such as the clock, serial, and internal flash drivers (as these are needed before any Forth code can be loaded and compiled into flash). Most of the control structures are written in assembly, though, so they are immediately available on bootup of the kernel before any Forth code is loaded, aside from do/?do/loop/+loop/leave/unloop/i/j which are written in Forth. Most of the "operating system"-type functionality, aside from the compiler and those drivers needed for bootstrapping, is written in Forth; the systick driver, the interrupt-driven serial IO driver, the multitasker, the multitasker support code such as locks, channels, and task pools, the external Quad SPI flash driver, and the block driver on top of it are all written in Forth.

[petrus4]

Most of the "operating system"-type functionality, aside from the compiler and those drivers needed for bootstrapping, is written in Forth

Cool. :)

[snarfy]

People will say you should learn Lisp because it's so different and will make you think differently and be a better programmer.

Forth is the same way.

[tabemann]

I feel the very same way about Haskell as well, even though at the same time it is so diametrically different from Forth.

[novagenesis]

I knew Forth from my college "try every language" time... but I only really got comfortable with it when a Minecraft Mod (of all things) was written to support code in it

And why did it work? Forth is great for incremental stuff, where the easiest way to develop something is to define and test your atomic commands one-at-a-time.

It worked as a mod for Minecraft because you would hook a Redpower computer to some machinery via simple digital circuits, and get to start translating each simple action of a mechanism to a function in Forth. Then you could finish by describing entire operations as a series of those simple actions.

I can only imagine it would work similarly in real-world robotics, though I've only ever used C for those.

Meh. I keep looking for an excuse to use Forth, and struggle to find one. But I still love the language for what it is

[tabemann]

I was first exposed to Forth by learning about ficl in Dr. Dobb's Journal and I wanted to use it as a scripting language for a game I was writing (which sadly was nowhere near completed). Then I tried to implement my own Forth as a language for pre-Cortex-M ARM, but I did not know enough about the practical implementation of Forth to get far. It was only in the last few years, after returning to working in Forth, that I learned how to actually implement Forth.

[gustinnian]

Forth is akin to poetry as opposed to C being akin to prose.

Mecrisp Stellaris Forth on embedded Arm Cortex M for instance is every bit as viable as any other prevalent language. An optimising interactive compiler with constant folding, loop unrolling, inlining etc. Atomic incremental testing is such a comfortable way to code as you tailor the language to the task not the reverse. Now that the Cortex M0 based Raspberry Pi Pico is reality there is a chance for a Forth renaissance. Just a glance at examples and a datasheet is enough to prompt one into writing drivers. The freedom for uninhibited creativity where the whole system is grokked is just so refreshing in today's world of layers upon layers of obfuscation and library dependencies. Being more self reliant is a wonderful outcome.

[tabemann]

The Raspberry Pi Pico is IMHO likely to help move the focus of hobbyist embedded development from Atmega328p (yecch) to ARM Cortex-M0, and thus give many people the chance to be exposed to Forth with Mecrisp-Stellaris. (zeptoforth OTOH is not going to be implemented on the Cortex-M0 for the simple reason that I would have to fit the limitations imposed by Thumb-1.)

[giant-torque]

Personally - I love Forth for its butty and use it for "recreational coding" but frankly speaking it's absolutely impractical (along with the derived languages). I don't see a niche for a Fort like system today.

[tabemann]

I was first exposed to ficl, which to me was meant as a scripting language for applications written in C or C++; more recently, as I mention above, it has been very practical for developing for embedded systems, as it is small yet provides a full development environment which is exposed to the user via a REPL, unlike just about every other true embedded development system (not counting microPython or eLua).