It's not exactly about Forth, but Forth is what made me to write this note.

1 Pre-history

1.1 First steps

When I've just learned how to program, there were new major discoveries every day. Each new thing opened a way to writing new kinds of programs, and I was eager to apply that new knowledge in some new programs. Of course, it slowed down after some time, once the most common concepts were discovered, and further it required to learn more, and often was less exciting. Now I'm spending most of my "discovery" time on learning maths which I don't really apply.

But back to those first years: probably it's a common observation that the better one knows how something works, the better one can apply (or use) it. And a similar one, closer to programming: if you can't implement something, you don't understand it. Putting those two together, it makes one to look for more than a few common languages, which, chances are, one has learned as first ones.

1.2 Assembly and C

From what I knew, there were high-level languages and low-level ones (though I didn't consider anything but assembly as low-level back then), where high-level ones were just simplified/refined versions of assembly. Assembly allowed to write efficient code, as well as to read any compiled code; and I thought of it as of something on which everything else is based. Though, after some writing, I grew tired of reading and writing pretty much the same constructions all the time, which could easily be replaced with a straightforward syntax substitution, and backed a bit – to C, which seemed pretty similar to assembly, in that it had no massive layers of magic between machine code, which gets actually executed, and C code. Also, it made me to look on programs through an imaginary debugger: programs written in higher-level languages were very messy and nearly impossible to read, as opposed to relatively nice C programs, and great assembly ones. In that sense, assembly looked like the most simple language.

I'd still suggest anyone interested in programming to learn assembly basics, in order to know what happens under the hood, and what do all those standard errors (e.g., stack overflow) mean.

Though there were (and still are) big gaps in the whole picture, what made (and still makes) me to look for more.

1.3 SICP and the Dragon Book

It was 8-9 years ago when I've heard of SICP for the first time, and then there were a few attempts to read it, with big delays and reading from the beginning each time (and that was pretty boring, to read what I've read before, but otherwise it was hard to get what's it about). Laziness and procrastination contributed, of course, though I also blame DrScheme, which I've used before Emacs (and which wasn't all that nice). Moving completely to GNU/Linux and Emacs really boosted learning of new languages, providing all the necessary tools, though leaving me without games and some programs which I liked back then. Still missing games, though there's plenty of other (and probably more useful) things to play with.

But what have made me to actually go through SICP (not to the end though, but most of it, at least), was back in the Windows days – the Dragon Book: it partially filled the gap between assembly and high-level languages (showed how the latter can be compiled into the former), and made me to understand, and to appreciate, how elegant and simple Scheme really is – together with SICP, of course. It was another point of view on what "simple" means, and Scheme was a language which specification one could easily read and remember, and that one can implement easily as well – unlike even C specification. And, of course, AST is particularly clear there, too: paredit is perhaps the closest thing to structural editing which I've used.

1.4 Purely functional programming

Though Scheme isn't pure, I've always tried to avoid its non-pure features, but that path leads to Haskell and similar languages. It's pretty similar to the previous section, but the point was about parsing and implementation there, and here I'd like to mention one more view on simplicity: lambda calculus, the computational model of those languages. Pretty much like assembly, in that it's the base of functional languages, but more simple, more elegant, and much closer to the languages which are built on it, than assembly to high-level imperative ones. Also, not affected by arbitrary decisions of specific implementations.

1.5 Type Theory, formal reasoning, and further

This includes a journey into the motivation behind lambda calculus, a better understanding of programming in general and of the ways to write correct programs, and even makes to look on programming as on a part of mathematics. As opposed to previously mentioned discoveries, it doesn't just add to the picture, but opens a bigger one, with a lot of new missing parts, and which, in turn, makes the initial picture to look different. The related languages here are Coq, Agda, and mostly Idris.

1.6 Other things

There's plenty of other parts I don't see or see vaguely: operating systems and hardware, for example, and the latter goes much further – into physics.

2 Forth

2.1 More pre-history

Some years ago, I've been told about Forth, by the same person who pointed SICP to me originally. In particular, it was jonesforth, and I've postponed its reading – for years. Though kept it in mind, and found its description rather interesting, but not enough to find a few hours that it takes to read, in those few years. I've also read about it (and a similar language, called Joy – which I haven't read much about yet, though it seems quite interesting as well) later, when was looking for ways to eliminate [named] variables in a language, other than De Bruijn indices and combinatory logic; probably will write about the purpose of that in a separate note. So, it was around for quite some time, and only recently I've actually read it – and it turned out to be a particularly nice (and easy to make) discovery.

2.2 Basic description

Forth could be described as an imperative stack-based concatenative language. Sounds unusual and interesting, but also sounds a bit like a useless esoteric language. It also could be said that its implementation may be pretty minimalistic – but the same applies to Scheme, and to various esoteric languages. Initially, I've also been told that it may have a minimalistic assembly implementation (which jonesforth is, together with a good description), what sounded nice, but, well, doesn't sound like a big deal for some weird esoteric language.

2.3 The discovery

Turns out it's not that weird and esoteric! Hence, it's a minimalistic assembly implementation of a usable language, in which other languages can be implemented – considerably more easily than in assembly. The best part is that it shows a simple way from assembly to high-level languages: just like the Dragon Book, but in the opposite way.

Before Forth, I've imagined such climbing as a process of writing rather big amount of assembly code, to get a compiler of a C-alike language – with a proper parser, though not necessary with any kind of optimization: a kind of task that could be done, but not something I'd try to do over a weekend, and hence quite shady. That's approximately what I thought of parsing and compilation before reading the Dragon Book: not absolutely magical, but something shady and complicated.

2.4 One more nice thing

There's almost no prerequisites for reading jonesforth.[Sf]: just some familiarity with assembly basics is required, and the rest is a few clever tricks, which allow to quickly climb from assembly to an interactive Forth environment.

3 Conclusion

Nothing new here, actually – more of a reminder: there's always something new and exciting to find, a part of the whole picture to fill or to refine; sometimes it's not even buried deeply, and initial exploration doesn't take much time. Perhaps it's not easy to look for something that you don't know to exist, yet it's the only way to find out that it exists.

4 Update: kitten

Kitten is a typed concatenative language, quite interesting to play with. The typing happens over whole stacks there.