
Collapse OS – Why Forth? - crousto
https://collapseos.org/forth.html
======
megameter
If I had to put my finger on why Forth is hard for most programmers, it's like
this: the structured program theorem suggests using sequence, selection, and
iteration to control program logic. Assembly code on hardware architectures
will assign all meaning sequence-relative, late-binding the selection and
iteration. Forth doubles down on this sequence-first approach through a more
versatile assignment mode(the stack) while only minimally accommodating the
other two. That makes it easy to implement, while not explicitly addressing
expressability.

Forth written "flat" with shallow data stack usage is assembly by another
name, a wrapper for load-and-store; Forth that does everything with intricate
stack manipulation is a source of endless puzzles since it quickly goes write-
only.

But, like any good language with meta expression capabilities, you can work
your way up towards complex constructs in Forth, and write words that enforce
whatever conceptual boundaries are needed and thus check your work and use the
system as a compiler. That's what breaks Forth away from being a simple macro-
assembler. But you have to write it in that direction, and design the system
that makes sense for the task from the very beginning. That falls into an
unacceptable trade-off really easily in our current world, where the majority
of developers are relatively inexperienced consumers of innumerable
dependencies.

~~~
theamk
For me, the main problem with forth is a lack of names -- most languages
(functional or imperative or even declarative) assign names to things --
things like function parameters, temporary values and so on.

Even Prolog, which is as far from traditional structural program as one can
go, usually has descriptive names for unbound variables.

Compared to this, Forth is very name-terse. You get "function names" at best,
and nothing else. This really makes programs much harder to understand, as it
requires one to remember much more things while reading the code.

~~~
TurboHaskal
Note that Forth also supports locals. These will consume and remove N members
from the stack so you can summon them as needed prior to calling the words.

But as someone that really got into Forth this year, I can assure that it does
get better once you get more familiar with the language. I used to write
commenting the stack effects on each line and now I barely need them as I
write words in one sitting without that much effort.

Other developers are doing tacit programming in J or Haskell, pipe forward
operators in F# or OCaml and threading macros on Lisp dialects and they seem
to do fine.

~~~
mumblemumble
It's been a long time since I did anything substantive with Forth, but, as I
recall, the big problem here is that most Forth guides get so excited to show
you how much rope the language gives you that they forget to teach you how not
to hang yourself with it. So you're kind of left to figure out all the little
idioms and best practices for stack management all on your own.

~~~
no-s
>> So you're kind of left to figure out all the little idioms and best
practices for stack management all on your own.

That was my experience learning Forth in the 80's. Initially I tried to add
compositional features I was familiar with from APL and Lisp. I raged against
the limitations of the cell and schemed to use a typed stack. Eventually I
became one with PAD and was able to ALLOT peace to my code. At some point I
ranted on how the idiom of counted strings could be generalized to all sorts
of useful sin and had an epiphany. 2ROT on!

------
jstanley
If this gets you interested in z80 hardware, I would recommend building an
RC2014: [https://rc2014.co.uk/](https://rc2014.co.uk/)

I built an RC2014 after CollapseOS was posted last year, and thoroughly
enjoyed it.

I ended up adding a front panel, complete with switches and lights, to allow
toggling in and executing code without a ROM, and also wrote a HTTP/1.0 server
for CP/M (which was an enormous headache for lots of different reasons). Never
did get around to running CollapseOS on it though.

~~~
mdbauman
I love this project, and check in on it every few months. I particularly like
the idea of scavenging hardware:

> With a copy of this project, a capable and creative person should be able to
> manage to build and install Collapse OS without external resources (i.e.
> internet) on a machine of her design, built from scavenged parts with low-
> tech tools.

I'd be interested in trying to build my own proof-of-concept, but my hardware
experience pretty much starts and stops with kids' electronics kits from 20
years ago.

Assuming I can scavenge a Z80, what would be a logical next step? What
books/other resources should I be reading to learn more?

~~~
jstanley
Definitely read (at least the first chapters of) the Z80 cpu manual:
[http://z80.info/zip/z80cpu_um.pdf](http://z80.info/zip/z80cpu_um.pdf)

It gets a bit dry when it gets to the bit that documents the individual
instructions, but the overview before that point is well worth reading.

Once you've done that and you're trying to write code, this page is a good
reference for the instructions:
[http://clrhome.org/table/](http://clrhome.org/table/)

To build a scavenged machine, you'll need a Z80 CPU, a clock source (I think
an RC oscillator would be the simplest working setup?), probably some sort of
ROM, an SRAM, some sort of IO device (probably a Z80 SIO/2 for serial), and a
5V power supply. I think that should be all that is required. Then you need to
load your code into the ROM at address 0.

Then you can connect the SIO to a USB serial cable (e.g. FTDI) and communicate
with your Z80 using a modern PC.

I can't remember if the SIO/2 needs external address decoding logic, maybe you
could cope without it if you are happy for it to use up every address?

But building an RC2014 would be easier and more likely to result in a working
machine, and would give you almost all the knowledge required to build a
scavenged one later if you still want to.

~~~
mbauman
Thank you for your thorough answer. Especially when you frame it like that,
the RC2014 sounds like like a fun next step. I'll definitely look into it.

~~~
jstanley
You're welcome.

For help and support, the rc2014-z80 mailing list is quite active:
[https://groups.google.com/forum/#!forum/rc2014-z80](https://groups.google.com/forum/#!forum/rc2014-z80)

And I'd also happily receive RC2014 or Z80-related questions by email
(available in profile), although I'm not much of an expert compared to many of
the people who are active on the mailing list.

------
zentiggr
I think I've had my own moment of clarity that spans both Forth(s) and Lisp(s)
and explains why neither is as common as other languages.

In most common languages, there is a complicated base spec that covers many
cases and defines a broad range of affordances, plus libraries and libraries
that expand on an already fleshed out collection of tools and etc.

Forths and Lisps give you the core of an environment, and let/expect you to
build on the foundation to create your own implementation. Like someone else
in this thread said, N programmers, N dialects. Or, more accurately, every
Forth program is its own DSL for accomplishing its work.

~~~
sahil-kang
I think you can draw this ‘core of an environment’ parallel between Forth and
Scheme: both are small languages and they emphasize growing the language to
the problem domain [1]. Common Lisp, on the other hand, is a large language:
implementations provide much more than a foundational core, and a fairly
comprehensive list of libraries exists. I think RPG’s Worse Is Better
highlights some of the reasons why CL isn’t as popular as other languages [2].

[1]
[https://youtube.com/watch?v=_ahvzDzKdB0](https://youtube.com/watch?v=_ahvzDzKdB0)

[2] [https://www.dreamsongs.com/WIB.html](https://www.dreamsongs.com/WIB.html)

~~~
pkage
Off topic, but this (from RPG's Worse is Better) sounds very familiar:

> Part of the problem stems from our very dear friends in the artificial
> intelligence (AI) business. AI has a number of good approaches to
> formalizing human knowledge and problem solving behavior. However, AI does
> not provide a panacea in any area of its applicability. Some early promoters
> of AI to the commercial world raised expectation levels too high. These
> expectations had to do with the effectiveness and deliverability of expert-
> system-based applications.

------
ojnabieoot
I hate this headline but the project is very cool. People like me who were
ignorant should start here instead of the Github to get a better sense of the
design goals (and why they are using Forth):
[https://collapseos.org/forth.html](https://collapseos.org/forth.html)

~~~
MaxBarraclough
I've read that page and I'm still wondering why they're using FORTH.

C has excellent portability and performance. The article agrees with the
general consensus that C is also generally a better language for the
programmer. So why use FORTH? What does it matter that it can do cute things
with self-hosting? What does 'compactness' matter?

If the goal is to build a portable means of writing programs for Z80 and AVR,
why not develop a C-like language, or an IR, or put work into developing a
serious optimising C compiler targeting the Z80? I get the impression that's a
relatively unexplored area for (rather niche) compiler research.

~~~
zentiggr
The rest of the storyline of this page covers what I think is the core concept
that Chuck Moore started from, and defines Forth as its own environment: the
core of the language that needs to be defined in order to write and execute
Forth words is surprisingly small. Once you have the core words in place, you
can layer on exactly the constructs you need.

I won't claim to be a proficient Forth author, but I've used it to accomplish
a couple of rather odd one-off projects, and it is amazing how much you can
do, as long as you're not expecting graphics or networking or huge storage
needs.

Compactness matters because when you're trying to bootstrap into a tiny (or
hacked together custom build) environment, the tiny bootstrap footprint means
you can be up and rolling that much faster.

C is all good, I've been writing it for a long time, but I'd much rather get a
Forth core going in raw assembly than even a stripped down to brass tacks C
compiler.

~~~
MaxBarraclough
Seems like an IR would make sense here. Perhaps a stack-based one. If you need
a compact program representation, that doesn't mean you have to use FORTH as
your source language.

~~~
richdougherty
I think the argument against a custom IR is that once you start optimising
your IR for compactness you'll probably end up near Forth in the design space
anyway. As you say perhaps making the IR stack-based.

Once you're at that point you may as well just use Forth, especially since
it's got a proven ability to work in these kinds of resource contrained, self-
hosting/self-bootstrapping environments.

~~~
MaxBarraclough
> you'll probably end up near Forth in the design space anyway

Good point. Related to this, FORTH can be treated as a target platform for
compilers, although I don't think there are many mature compilers that do
this.

I wonder if CollapseOS will ever seriously target heavyweight platforms like
x64 (and not just through emulation with libz80). I suppose that's out scope,
but it would open the door to JIT.

> you may as well just use Forth

Presumably it could be a little more compact if a less human-readable
variation were used, no? FORTH uses _DROP_ and _THEN_ , which could be
shortened at the cost of readability.

------
bsaul
First time i hear about this project and i love it.

I often talk with a friend who's an historian, and that makes me realize how
our relationship with time, as an industry, is extremely short sighted.

The internet archive is an immensely valuable project, as well as all the
websites archiving old documentation, etc. But i don't think a lot of people
realize the value of things they're destroying everytime they execute a delete
statement in a DB or a filesystem.

This Collapse OS ambition to be able to "bootstrap" something useful over any
kind of primitive hardware and sustain the passage of time ( or catastrophic
event) may have an immense value in the future.

~~~
onetom
DELETE statement... That's far too obvious. With every UPDATE statement you
are forgetting the past, yet it's still the goto DB paradigm! It's okay to
constantly lose information apparently...

And it's not like we don't have alternatives. There is Datomic of course, but
also juxt/crux and DataHike.

------
Narishma
> The Z80 asm version of Collapse OS self-hosts on a RC2014 with a 5K shell on
> ROM, a 5K assembler binary loaded in RAM from SD card (but that could be in
> ROM, that's why I count it as ROM in my project's feature highlights) and 8K
> of RAM. That is, it can assemble itself from source within those resources.

Meanwhile, you can't compile rustc on a 32-bit system because it runs out of
address space...

------
dreamcompiler
There seems to be a common conception that Forth is always interpreted by some
kind of virtual machine. But it's quite possible to compile Forth all the way
down to native machine instructions with no loss of interactivity and without
losing the rapid bootstrap capability the author describes. Such a Forth runs
almost as fast as C ( _almost_ because modern out-of-order and other processor
optimizations probably don't work well on compiled Forth code).

I used this approach when I bootstrapped a Forth compiler on the TI 34010
graphics chip in a similar fashion as the author. It even had local variables
so you didn't drive yourself mad thinking about the stack all the time.

My favorite commercial example of such a Forth was Mach 2 Forth on the early
(pre-OSX) Macs. I don't know if any modern Forths do down-to-the-metal
compiling or local variables, but I'd be interested to find out.

~~~
ehaliewicz2
> local variables

I believe most modern forths will have these, gnuforth does for example.

> down-to-the-metal compiling

I think there are some that do this, but back in the day, the opinion of lots
of forth programmers was that threaded code was good for the 90% of the
program where performance didn't matter, and added an inline assembler for
areas where it did.

~~~
Someone
And of course, you can always add support for local variables yourself. For an
example, see
[http://turboforth.net/resources/locals.html](http://turboforth.net/resources/locals.html),
which takes 808 bytes to implement. That’s hefty, for some systems where one
would use Forth, but, FTA, _“Placing key values in locals will actually both
increase peformance, and make your code smaller”_ , so you can earn that back
if you use the facility enough)

------
krick
I thought this is pretty fun project and the idea is just cool right away, but
then I went on reading and was surprised by the fact it seems the author is
serious. I would be really curious to hear his opinion on why the supply
chains should collapse before 2030. Obviously, there wouldn't be a shortage of
people in the comments who can start speculating on why it might happen, and,
of course, I myself also can provide a couple of feasible scenarios, but
nobody of us were serious enough to actually start this project, so _his_
opinion on the matter is somehow quite more interesting to me than it would
normally be.

~~~
arcadeparade
If you had told me last year that we would have a pandemic, lockdown, massive
economic recession and job loss and now riots and protests etc and all at the
same time I probably wouldn't have believed it. I'm starting to think the
world is a lot more fragile than we all thought.

~~~
wwright
Not “we all” thought — plenty of people have been saying this would happen for
years. Specifically, epidemiologists and black people. Maybe we should listen
more!

------
TheUndead96
The weird thing about history is that it only makes sense backwards. Someone
500 years in the future might think of this as the Gutenberg printing press.
It is often difficult to appreciate the magnitude of actions in the present.

~~~
hutzlibu
Why should they think that?

The gutenberg press was used in the real world. There are lots of OS being
used in the real world for real work.

So why should someone in 500 years think this is more relevant, than for
example Linux?

And if there is a real collapse, then I also do not really believe everyone
makes a run for collapseOS. There are other options: all the ones, tinkerers
and hackers use already today.

~~~
TheUndead96
We don't know how history will pan out. Just wanted to share the weird feeling
I sometimes have about current events. For all we know, post-collapse
technology could be based off QMX reverse-engineered from luxury vehicles.
It's just fun to think about how events can have that unexpected butterfly
effect. I sometimes catch myself with the implicit belief that we are "late"
in the story of history. But given the possible expanse of time, we might be
the "hunter-gatherers" of a civilization we cannot even begin to comprehend.
This might just be the second of the dark ages.

------
onetom
I'm surprised that no one has mentioned
[https://flashforth.com/](https://flashforth.com/)

There is no intriguing backstory for it, like for CollapseOS, but it's a ~6
kiloword, practical 4th environment for Microchip PIC microcontrollers, which
are a lot simpler than Z80, btw... The source code is trivial to understand
too. My father is still using it daily to replace/substitute Caterpillar
machine electronics or build custom instruments for biological research
projects.

We started with Mary(Forth) back then, when the first, very constrained PIC
models came out, with 8 deep stack and ~200 bytes of RAM. Later we used the
[https://rfc1149.net/devel/picforth.html](https://rfc1149.net/devel/picforth.html)
compiler for those, which doesn't provide an interactive environment.

I made a MIDI "flute" with that for example, which was fabricated from sawing
out a row of keys from a keyboard and used a pen house as a blow pipe and a
bent razor with a photo-gate as the blow-pressure detector...

There are more minimal Forth OSes, which might be more accessible than a
Z80-based one.

I would think those are more convenient for learning, how can you have video,
keyboard and disk IO, an interactive REPL and compiler in less than 10KB

I remember, I played a lot with
[https://wiki.c2.com/?EnthForth](https://wiki.c2.com/?EnthForth)

But if you really want to see something mind-bending, then you should study
Moore's ColorForth! I found it completely unusable, BUT I've learnt immense
amount of stuff from it:
[https://colorforth.github.io/](https://colorforth.github.io/)

There are more usable variants of it, btw. Also worth looking into Low Fat
computing:
[http://www.ultratechnology.com/lowfat.htm](http://www.ultratechnology.com/lowfat.htm)
I think it's still relevant today.

------
RodgerTheGreat
I'm delighted to see that hsoft took suggestions about Forth to heart, and
that it has lead to both simplification and enrichment of the project.

------
tarkin2
I love this project. Thank you for posting it. The idea of a post collapse
operating system reminds me of slackware/subgenius’s old slogan: “...the world
ends tomorrow and you may die!”

I’ll be trying to compile collapseos, write forth and load slackware on
floppys in a few years then. (Will systemd survive civilisation’s collapse,
especially when it caused it, that is the question....)

~~~
mhd
For me this is slightly into Poe's Law territory: Is this actual prepper
mindset, or tongue-in-cheek?

~~~
tarkin2
Thanks. I'd never heard of that law before. I think he's serious. I'll
appreciate his work both pre and pos civilisation collapse. I like his
software aesthetic too.

Maybe I'm getting old, maybe I'm seeking more control, maybe the world has
come needlessly complex, but there's a certain appeal about returning to more
manageable days, where it was possible to fit a software and hardware system
in your brain, and your brain was swimming with ideas on how to use a limited
system rather than drowning in layers of complexity.

~~~
mhd
I liked playing the Fallout games, I grew up with 8 bit machines, so I'm all
in at using a post-apocalyptic scenario as a setup for a though experiment
tech stack. In a "ha ha only serious" manner.

But on the other hand, real preppers scare the effing s out out of me.

------
mlang23
Forth is one of the last languages on my list. Whenever I read something like
this article, I want to learn it. The advice at the end of the article seems
interesting. Does anyone have any resources that might help with this?

~~~
japanoise
A Forth shibboleth is that you have to implement your own in order to
understand it. Try reading the assembly, then forth source, for jonesforth:
[https://github.com/AlexandreAbreu/jonesforth](https://github.com/AlexandreAbreu/jonesforth)

This is how I learned.

~~~
mlang23
Oh wow, thanks. That is pretty much exactly what I was looking for.

~~~
gmfawcett
Original repository and introductory article:

[http://git.annexia.org/?p=jonesforth.git;a=shortlog](http://git.annexia.org/?p=jonesforth.git;a=shortlog)

[https://rwmj.wordpress.com/2010/08/07/jonesforth-git-
reposit...](https://rwmj.wordpress.com/2010/08/07/jonesforth-git-repository/)

~~~
mlang23
For anyone stumbling over this and having trouble to build it, I had to figure
out two things: 1\. When building on x86_64 Debian, I had to install linux-
libc-dev:i386 to get /usr/include/i386-linux-gnu/asm/unistd.h. I also had to
adapt the include path to have it actually found. 2\. If you see a segfault
when running the executable, you likely need to remove -Wl,-Ttext,0 from the
build command. At least on my system, it fixes the segfaults and now
jonesforth runs as expected.

------
haolez
> Some Forth enthusiasts like the language for itself. They think that its
> easier to express much of the logic of a program in this language. Many
> books and tutorials are touting this. [...] That's not my opinion.

In my opinion, it's not that FORTH code is hard to read, but that FORTH gives
the programmer so much freedom that every program becomes its own microcosm of
DSLs.

~~~
DonHopkins

        : C(-; LICK SMILE NOSE WINK ;
    

( See my profile for more microcosmic FORTH DSLs! )

c(-;

[https://news.ycombinator.com/user?id=DonHopkins](https://news.ycombinator.com/user?id=DonHopkins)

------
pwdisswordfish2
[https://collapseos.org/why.html](https://collapseos.org/why.html)

"That being said, I don't consider it unreasonable to not believe that
collapse is likely to happen by 2030, so please, don't feel attacked by my
beliefs."

Triple negative? Quadruple negative? (If we count the second "don't".)

Compare something like:

"I consider it reasonable to believe that collapse is unlikely to happen by
2030, so please, don't feel attacked by my beliefs."

It is almost as if the grammatical structure reflects the life perspective of
the author.

~~~
csb6
This is the perfect comment - pedantic, snarky, and more focused on the
superficial features of the article than the content, mixed in with some
grammatical pseudo-psychology. Check, check, check, and check! This is peak
tediousness. Well done!

------
mshockwave
this might be a dumb question but can someone briefly explain why Forth is
more suitable over C or other languages in general on post-apocalyptic OS?

~~~
yellowapple
\- It's tiny and dead simple to implement

\- It sits very close to assembly

\- It allows high-level programming like in C

\- The concept of pushing/popping things onto/off the stack is a relatively
straightforward programming model when done consistently

One of the old competitors to the likes of UEFI and uBoot is OpenFirmware
(also known as OpenBoot), for which the primary UI is a Forth shell;
OpenFirmware was the BIOS equivalent for Sun's SPARC workstations/servers (and
still is for Oracle's/Fujistu's SPARC servers, last I checked) and most POWER
hardware (including "New World" PowerPC Macs), among others. About the most
delightful pre-boot environment I've used; it's a shame it didn't catch on in
the x86 or ARM space.

~~~
fouc
Also works great with graphics. PostScript is similar to Forth.

~~~
yesenadam
I got into Forth recently - using Gnu Forth - but got bogged down at my
inability to do graphics. There are hardly any Forth programming videos of any
kind online, besides the "101" kind, but I found one by a guy who managed to
get graphics/windows going, I think with GForth. (Can't find it on youtube
now.) Looked mega-complicated. So lately back into Tcl/Tk, which also
satisfies my "bizarre, powerful and very cool language" itch but actually
makes graphics/windows super-easy. I do think Forth is awesome though!

After getting into Forth I got into PostScript, which does have most of the
Forth fun/freedom taken out of it. It's not usable for GUI-type programming is
it?

~~~
kjs3
Look at Sun NeWS and Display PostScript for GUIs written in PostScript
(well...an extended PostScript).

------
bitwize
This is the kind of malarkey I'd get up to on a personal project of mine.
Like, I wonder if I'd get farther if I'd written it in
Forth/TinyScheme/Erlang? May as well completely overhaul it and find out!

------
jvanderbot
I feel sheepish for being on that thread as a detractor, after reading this
post.

------
messe
Nice. Must revisit my own Forth OS, or maybe just start contributing to this.

------
redisman
Love this project. I wonder why not make it run on smartphones? I'd imagine
that's the vast majority of computers out there today. Easier to find a
working smartphone than retro consoles.

~~~
Cthulhu_
Usually it's nontrivial to get anything custom to run on a smartphone, they're
pretty locked down like that compared to more general hardware.

------
Koshkin
CollapseOS? Meh. What we need is ApocalypsOS. Something to play Tetris on
after having hauled a bucket of wellwater (and some wood) to the 23-rd floor
apartment where I try to survive.

------
MaxBarraclough
On the topic of compactness: is FORTH ever used in the demoscene?

As I understand it, they tend to write assembly, and compress the resulting
machine code, for decompression at runtime.

------
dang
See also
[https://news.ycombinator.com/item?id=21182628](https://news.ycombinator.com/item?id=21182628)
from last year.

------
jbb67
I want to learn forth now. Where can I find a modern usable forth that works
well on windows to make real programs? Does such a thing even exist?

~~~
TurboHaskal
You can do just fine with the free versions of SwiftForth and VFX Forth as
long as you don't mind that they are 32bit only.

If you end up liking it and want 64bit, you can buy iForth for 100 EUR. It's
what I use.

These are all amazing optimizing compilers.

If you care about OSS: Don't waste your time with GForth. If you want
something simple that you can hack yourself, take a look at pforth.

~~~
anthk
This. Pforth works really well and the ".S" word is straightforward, while pfe
is not. GForth is too difficult; altough you can code for the Game Boy with
it, but in order to learn, pforth is more than enough.

------
fouc
I keep hoping that a Rubyist will someday do the same thing for Forth like
José Valim did for Erlang, with Elixir.

------
monadic2
Is the focus on forth to rapidly bootstrap from more than just z80, or for
readability, or for some other concern?

~~~
messe
Not the developer, just a forth enthusiast. But I'd imagine it's the ability
to rapidly bootstrap on other architectures. Readability is just a bonus on
top of that.

The focus of CollapseOS is, well, an OS that can be used after society has
collapsed, something running on scavenged chips on hand-soldered boards (in
the worst case scenario).

The original logic was the Z80 is still pretty prevalent, so it was thought to
be a good choice to base the OS on.

Turns out that a Forth interpreter/compiler is incredibly easy to write (just
a few hundred bytes of a assembler, a few thousand at the upper end), so by
using Forth they hugely expand the range of scavengeable chips.

------
pwdisswordfish2
Here is a Forth you can use on Linux and Windows

[http://web.archive.org/web/20080828064920/http://ronware.org...](http://web.archive.org/web/20080828064920/http://ronware.org/reva/wiki/stable)

------
garmaine
Forth is Lisp, but with composition as the basic operator instead of
application. The result, of course, is a wildly different language but one
which inspired the same degree of fanaticism among its adherents in their
search for simplicity and elegance.

A truly under appreciated language imho.

~~~
RodgerTheGreat
I rather disagree with your first sentence. Forth is not Lisp, nor is Prolog
or APL Lisp, and none of these languages are one short conceptual leap away
from the others. Even a very rudimentary Forth can express concepts which have
only hazy correspondences in a Lisp, like words which twiddle the return stack
or yield a variable number of results on the parameter stack.

I find it misleading _at best_ to casually intimate that Lisp is some kind of
ur-language which exemplifies simplicity and thus lies at the root of any
design space. Fans of Lisp are overly eager to stake claim upon ideas which do
not belong to their language.

I don't mean to bite your head off about it; this is just a trope I find
tremendously frustrating.

~~~
garmaine
The core of Lisp is a small set of rules about abstraction and application
using lists. Forth, at its core, can be formalized with the exact same set of
rules (one to one correspondence) but with stacks and composition as the
operator. The languages are very VERY different, but there is a similar bare
bone formal framework at the bottom.

~~~
maxsun
I'm very new to Forth, but find this intuition really appealing; do you know
of any examples that demonstrate/prove this correspondence?

~~~
garmaine
It’s only the newer “concatenative” languages that have explored this forms
correspondence. See this essay by Jon Purdy (author of Kitten) on “why
concatenative languages matter”:

[http://evincarofautumn.blogspot.com/2012/02/why-
concatenativ...](http://evincarofautumn.blogspot.com/2012/02/why-
concatenative-programming-matters.html?m=1)

------
imode
If the author wants their code to survive the apocalypse, they should generate
Turing Machines that have a simple shim interpreter for low-power
architectures. The benefit of this is you can build an interpreter for a TM in
wood or other simple materials. Semi-Thue systems also fit.

~~~
imode
I don't get why this is downvoted.

~~~
carapace
Me neither. I like it but the limiting factor on post-apocalyptic digital
electronics will be access to datasheets, eh?

It would be interesting to build a minimal useful CPU out of fluidics.
[https://en.wikipedia.org/wiki/Fluidics](https://en.wikipedia.org/wiki/Fluidics)

~~~
imode
Definitely. Or mechanical logic gates. But the surface area would very quickly
become an issue for such a project, and you'd need to assume only a certain
few tools.

~~~
carapace
True. I wonder what kind of computations people would need to do that would
make it worthwhile to make big, slow computers?

I bet it would be easier to make up "sacred dances" that incorporated
processing in the motions of the dancers.

And let's not forget that a human with an _abacus_ can do a great deal of the
math required for everyday life. :-)

------
detaro
somewhat OT, but are there any active Forth communities/forums to follow if
one wants to see what people get up to with it?

------
tibbydudeza
And all I wanted was a pipboy.

------
johnisgood
Why not Factor? :P

~~~
TurboHaskal
Because Forth is more (less?) than a Smalltalk on RPN.

------
RandomGuyDTB
It's odd to highlight that Forth is 50 years old, considering C is 48 years
old and still in very heavy use in operating systems development.

~~~
CameronNemo
Perhaps Forth has changed less than C in that time. The C of 48 years ago can
look quite different from modern C.

~~~
RodgerTheGreat
There has never been one Forth. In a world with N Forth programmers, one can
expect roughly N implementations of Forth. Perhaps closer to 2*N. An ANS spec
exists, but most Forth programmers would say it misses the point.

Forth is a collection of ideas and philosophies toward programming as much as
it is a language. Two stacks and a dictionary. Threaded code (direct,
indirect, token, subroutine, etc...). Collapsed abstractions. No sealed black
boxes. Tight factoring.

C has changed. Forth is everchanging.

~~~
throwaway17_17
This is a slightly off topic question for you, do you think the attributes you
named are required for having a “Forth” or are they just the most common
implementation characteristics? My current pet language project certainly
looks Forth-like, with different semantics and a modal dependent type system,
but is not threaded nor does it have the traditional stacks and dictionary. I
don’t know if I’d call it a Forth, but maybe it is?

~~~
RodgerTheGreat
"The dictionary" can be implemented in many ways; simple or clever, namespaced
or not. A language without any form of local or global name binding would
presumably need quotations ala Joy/Factor, which means your stacks probably
have to store _objects_ rather than raw numbers. This tips the scale in the
direction of a higher-level language.

The stacks are likewise a description of semantics rather than implementation.
Some Forths keep the top few stack elements in registers to reduce overhead.
If the return stack isn't user-accessible (r> >r etc.) then, again, you're
straying closer to a higher-level functional language than a Forth.

There are many kinds of threaded code. For example, subroutine-threaded code
uses native subroutine call instructions in word bodies and does away with the
inner interpreter. Threaded code is a natural consequence of disentangling
conventional "activation records" into two stacks which grow and shrink
independently. You could have a Forth without threaded code, I suppose.

Some Forths attempt to "seal off" or otherwise obscure some parts of their own
internal workings from "user programs". This is more common among dialects
which try to adhere to ANS specs, like GForth. This isn't a total anathema to
Forthiness, but it tends to introduce additional complexity. If a word is
useful for implementing a forth kernel, why couldn't it be useful in
implementing other functionality, too?

If you're building something higher-level which vaguely resembles Forth, it's
probably better to describe it as a concatenative language. A dependent type
system doesn't sound very Forthy, imo.

~~~
throwaway17_17
I don’t think you’re wrong in your assessment. But just for fun I will point
out that I probably assumed a bit to far when I stated no dictionary, there is
a name binding mechanisms for ‘words’, but I have a quote form as well. Also,
while I would say the language is functional, it is also intended to be low
level, ideally, the base of the language is a dependently typed pseudo-
assembly language, but the modal type system and homoiconic syntax enable
building words that are semi-macros. It is, at this point, basically my
attempt to blend Forth’s philosophical leanings with category/type theory. But
thanks for the reply, outside perspectives are always great for me to hear.

------
undershirt
> Forth doesn't elegantly describe complex algorithms… However, this mental
> pain does makes you question your need for complexity… This is something
> that I think few developers are familiar with and is hard to describe with
> words. It needs to be experienced.

Nice framing, that it’s not an intellectual argument you can make to justify
the benefits of drawbacks (i.e. an infamous red flag of stockholm syndrome),
so you have to point to the experience of the thing itself (“you had to be
there”).

~~~
hxegon
Or there are experiences which have hard to describe intangible qualities that
are hard to put logically. Not sure why you have to reach for stockholm
syndrome here.

~~~
undershirt
my comment was way off the mark, didn’t realized it sounded sarcastic. i was
instead trying to appreciate his approach to the intangible—pointing to direct
experience to avoid stockholm criticism.

