Hacker News Reader

Comment by bxparks | Hacker News Reader

I always get the impression that people spend more time writing Forth interpreters, rather than writing Forth programs to solve actual problems.

View on HN

Forth exposes both problems and solutions that aren't germane to the bulk of everyday computing systems:

1. I want to debug my assembly code with a REPL

2. I don't want abstraction, I want minimalism

3. I want to write solutions in the context of specific hardware

When you have all three, you have Forth's wheelhouse. Minimalism means you do get a sense of "seeing the Matrix" - the machine is controlled precisely to your specification. But as soon as you think that you can layer on a more abstract idiom, even those that are usually conventional in high level programming, it also reveals that it really won't help you do that. Either you DIY that abstraction, or you revert to the same load-store imperative paradigms you'd use for a large assembly program.

The answer everyone else is using is to add an operating system and an application language as a starting assumption, and then slowly grind through every issue caused by giving up control at the base layer to these more automatic systems.

I think there is a reasonable place for Forth as a runtime target for compiled code, but the style of code that it supports prefers "flat" designs, like dataflow/FBP languages, because of the explicit stack. Once you aim towards Algol and Lisp and start automating stack movements, the programs become coupled to that design and way of thinking.

> The answer everyone else is using is to add an operating system and an application language as a starting assumption, and then slowly grind through every issue caused by giving up control at the base layer to these more automatic systems.

The OS community generally understands in theory, although this is much less accepted in practice, that mechanism and policy should be separated as much as possible. Forth, operating systems, Smalltalk, etc. all converge on making programmed systems, if in substantially different contexts, and this becomes a question of layering abstractions. A Forth-like OS that would solve your problems is related to microkernels and exokernels. Minimality and simplicity is essential for foundational services.

I know that's what I do! It's a fun exercise, and Forth is uniquely suited to writing Forth interpreters. Forth really only has a few areas where it excels and they are incredibly niche ones at that.

We did write Forth to solve actual problems, but that was back in the 1980's, when computers used to have a Forth based BIOS, or solving engineering problems on a HP-48 (yes I know RPL isn't exactly Forth).

I started like this. My current system, which is the second or third attempt, serves me every day. I have some kind of server that has been running 24/7 for maybe a decade, and it is my go-to language for testing, prototyping and other throwaway scripts - which I actually frequently salvage, despite the fact that they were written for a version of the system that no longer exists because I'm still tinkering with it and don't care about backward compatibility much.

It's a fantastic way to bring up new hardware at the bare metal layer and do nontrivial things. But unless you're Jeff Raskin or something, building out, say, a word processor or something of similar complexity is a bit more daunting.

It’s a fun activity, and if you still solve “real problems” on a 6502, then it’s because you really want to anyway.

That being said, Forth is great for “exploratory programming” of hardware. I rarely, but still sometimes bootstrap Forth for that reason.

Here's what I'm hearing:

How would you design a Forth interpreter to encourage more people to solve actual problems with it? :)

This might be a bit out of date since I haven't looked in a few years, but my sense is that the standard libraries and documentation are often lacking. A batteries included standard library for gForth that could conveniently do basic things like make an HTTP request, display a dialog, or play a sound, without having to awkwardly bind to C APIs, would be really nice.

Not sure that will swing it, have a look at https://github.com/JohnEarnest/Mako/tree/master Which is basically a Forth for games, that runs on the JVM, and in the browser.

The issue as I see it, is that you have to have a model of the datastack in your head at all times. That's fine for your own code, but for other people's code, stack diagrams will only take you so far.

The ability to scan code, rather than reading it, allow you to mentally drill down when you are ready. Forth requires immersion.

Something like https://xorvoid.com/forsp.html I'm guessing is really the bridge. Something that allows variables without being too complex.

Reply on news.ycombinator.com