I've had lots of thoughts lately about bounded versus unbounded systems.

A book is bounded; the global library system is unbounded. A CD is bounded; Spotify is unbounded. The world is effectively unbounded, and networked computer systems tend to be unbounded too.

Many things are bigger than a human can experience, or changing faster than a human can keep up with. Many curious explorers and tinkerers are drawn to these unbounded things because they are vast, unknowable, and therefore exciting.

But what finite, bounded things are worth exploring and tinkering with?

Unbounded things can be endlessly novel and fascinating without ever rising to the level of being good or interesting. If you find something unbounded that you like, you can soak in it forever without thinking twice about it.

If you find something bounded that you like, you are stuck. You will eventually run out of new material. Whenever I near the end of a great book or a great album, I have a feeling of doom because I know that soon there will be no more.

Once you finally finish, life gets hard. You want another chapter, or another song, but there's nothing there. You're done.

If you want more, all you can do is try to feed the obsession by replaying the hell out of what you've been given. You need to examine the old material in more and more depth and examine it from every possible angle.

You may even be driven to create something new to feed the hunger inside you.

So again, what bounded things can be explored for a lifetime?

Chess is the best example I can think of: one page of rules has been handed down for millennia.

Euclid's axioms are another good example, not because they are strictly true, but because they define a useful spatial model that's pretty close to how our universe works.

Most of the programmers around here can point to a one-page language spec with the same mojo: something small and self describing like a Lisp metacircular evaluator, or a Forth primitive word set, or an index card with all of Smalltalk written on it.

Compared to chess or geometry, programming has only been around long enough to be examined by a handful of generations, let alone hundreds. But no one points to say, Java, as the language that will affect how future generations think about programming. Even though far more lines of Java have been written than these other languages, and Java has had a far larger direct impact on most peoples' lives. Why not?

I'd suggest that it's because Java is too large to be a bounded system. How many people understand all of Java, and in a doomsday scenario, how many could reimplement a compatible replacement?

Java, The Language, is widely used. Java, The Idea, doesn't exist. The language is too big and sprawling to distill a unifying, distinctive driving idea from.

(Unless you're talking about the idea of a bytecode VM used as a compilation target for a friendly language -- an idea much older than Java. The idea of everything being an object is also much older than Java. But, you certainly can't start from 1 page of rules, sit down at a computer, and wind up with a working Java interpreter five days later as an inevitable consequence.)

I'm not trying to pick on Java, btw... I have the same thoughts about C++, or Javascript, and even C, although old C versions are approaching simple enough to be re-implemented by a typical programmer with a 1 page spc and a bit of time on their hands.

is my classic example of a bounded programming language, by the way. The behavior of devotees makes this clear. There is not a large body of material written about the language. There is not a large body of source code to study. But the language is not dead. Anyone who is interested in the language and has an itch to do more with it is drawn... dare I say cursed?... to implement it, reimplement it, and tinker at length. Because there is just no other way to get deeper into it, other than making your own path. More than any other language, it is a folk language that has been reimplemented hundreds of times to satisfy some kind of deep primal curiosity.

Despite this independence, most of these Forths and Forthlikes have strong structural similarities and force similar programming patterns on their user. A whole lot of behavior inevitably falls out of a short set of rules. That's the cool bit.

Just replying to one of my older posts to retract an incorrect statement:

"There is not a large body of material written about ".

I was absolutely incorrect. There is a LOT written down. You just have to dig for it a bit. It's in books and papers, and personal webpages, and places like the archive. And most of it is pretty old.

I think the other point stands -- Forthlikes have strong structural similarities, and a lot of behavior inevitably falls out of a short set of rules.


Forth book recommendations 


There are a bunch more listed in the Forth FAQ, that I can't necessarily vouch for, not having read them: forth.org/faq/faq5.txt

Forth book recommendations 

@psf @ekaitz_zarraga "FORTH: A Text and Reference" is also good!

re: Forth book recommendations 

@d6 @ekaitz_zarraga I agree, it is! It's kind of like "Starting Forth" and "Thinking Forth" in one package. Personally I prefer "Thinking Forth" over "Forth: A Text and Reference", but I could easily understand someone preferring the latter.

Sign in to participate in the conversation
OldBytes Space - Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!