←back to thread

19 points chipwits | 2 comments | | HN request time: 0.408s | source
1. anyfoo ◴[] No.42241705[source]
I have a soft spot for FORTH. I don’t know if it makes for elegant larger programs at all, but it’s really easy and elegant to bootstrap a port of FORTH itself, and then use it to perform more and more complex system tasks. That’s probably why it was chosen for e.g. OpenBIOS.

It’s the only language/environment where I can imagine starting from nothing but a simple machine language monitor, to quickly achieve a foundation for a full environment, which is wild… (and nowadays most likely only of academic interest).

Lately, I’ve taken a liking to embedded forth, because it allows me to, say, build layers of forth vocabulary to control I2C devices, potentially starting by even writing I2C bit banging itself in forth first, and then progressively building higher levels of abstraction, but all of that completely ad-hoc and interactively on the forth prompt.

It’s a really great way to explore devices hardware-wise, without having to write a lot of boilerplate C or rust code on an external development environment.

Again, I don’t know if anything like that translates well into writing large, user-facing applications. Maybe the article will tell me?

replies(1): >>42241777 #
2. idatum ◴[] No.42241777[source]
> It’s a really great way to explore devices hardware-wise, without having to write a lot of boilerplate C or rust code on an external development environment.

Yes, second this. It's why I still use Forth. A UART and picocom (for example) and I'm interacting with an MCU. No complex (bloated) tooling needed for prototyping and learning. I've used this with STM32 devices and lately a Raspberry Pi Pico.