This is a how-to-write-a-FORTH tutorial that I wrote a few years ago. It's particularly nice that you get to see how various control structures are implemented, like IF, CASE and even comments!
Working through Jones Forth got me up to speed on both understanding how Forth works and getting my hands dirty with some practical assembly coding.
Once I got a better idea of Forth, I also realized that Jones stays in assembly for rather long. He builds up the entire interpreter from raw assembly words, because you need the interpreter to start parsing textual Forth source. But you if you could somehow write Forth before the interpreter is put together, it would be quite natural to switch to Forth much earlier. And it turns out you can do that. Jones even defines the `defword` macro. But for some reason he makes very little use of it. Rewriting most of the code leading up to INTERPRET using defword was a fun exercise.
The next step would've been making the whole system bootstrapping by rewriting the assembler in Forth, but x86 machine code generation is hairy enough that I bailed out at this point.
All fair points. I was reading over it again today thinking that it would have been better to write more of it in FORTH. At the time I was prematurely optimizing I think.
I've used jonesforth in the past few weeks as a basis for implementing my own Forth, but for RISC-V (and soon, maybe Xtensa).
It's an excellent codebase; thank you very much! I've changed the design a slight bit so far -- but the vague signature of jonesforth is really still there, I think!
Thanks, I've loved that piece for a while. I had written a couple of subroutine-threaded forths before that, but you helped me cross the border into indirect threading.
I'm a embedded software dev and write code all day in C. Sure enough forth comes up in conversations once in a while as does other ideas like Python, JS, Lua etc..
Of all the alternatives to C, Forth is the only one which groks hardware. This is particularly important for embedded development. Any realistic alternative to C must understand interrupts, memory mapped registers etc.. Forth is the only one in which this is possible. Every other example I've seen always uses C for "low-level" access or a libraries. If you need to do that, then you won't win over embedded devs like me. It's much easier to write good embedded C code (no mallocs etc) than having to debug FFI.
Having said all that, my mind doesn't understand Forth. I'm too used to seeing code in C or even assembly to fully understand Forth. Nevertheless things like https://github.com/jeelabs/mecrisp-stellaris are really cool and are a realistic alternative to C.
> Any realistic alternative to C must understand interrupts, memory mapped registers etc.. Forth is the only one in which this is possible. Every other example I've seen always uses C for "low-level" access or a libraries.
Forth is a great little language, and a perfect example of how to to do a surprising amount with very little. For more complicated embedded work, however, I've been deeply impressed with Philipp Oppermann's tutorial on writing a kernel in Rust: http://os.phil-opp.com/ You have to limit yourself to Rust's "core" library (instead of the usual "std"), and you won't have a heap until you write one, but it's surprisingly nice. Well, except for debugging double faults. That's never nice. :-/
Yeah, but Rust is much more complex than Forth, and really hates baremetal: you can do baremetal in Rust, but it's idiomatic to minimize contact. That works really well in some cases: OS work, for example.
But if you're working in a raw microconroller, you're going to be touching metal constantly, and you won't want anything you don't use slowing you down.
In short, Rust is great, but it doesn't beat Forth in Forth's biggest problem space: programming embedded systems under exceptionally tight size/speed constraints.
Not to mention that Rust is not interactive and doesn't allow for dynamic, incremental development. Forth brings the rapid, extremely tight feedback loop one sees in Lisp or Smalltalk to hardware.
Comparing it to Rust is missing this point entirely. Finally, let's not forget that Forth has been empirically validated multiple times in this domain (e.g. NASA has used Forth on board satellites and spacecraft).
Rust is entirely unproven in the hardware/microcontroller space (some would say in general), so I tend to view posts like ekidd's ("for more complicated embedded work") as projecting/wishful thinking.
Good point: I was going to bring this up, but I already had in another post, and I didn't think anybody who wanted rust on their hardware wouldn't care, as they quite clearly liked compiled languages.
But this is a huge draw for Forth, speaking as a Lisp user.
> Forth is the only one in which this is possible. Every other example I've seen always uses C for "low-level" access or a libraries. If you need to do that, then you won't win over embedded devs like me.
Is there any reason he would have heard of those? They're all pretty fringe, arguably moreso than Forth, for some of them.
Some of these do look neat: I've had an interest in both Ada and Oberon, although I haven't been able to get over the verbosity and unpleasant syntax of either (it's not COBOL, or anything, but it's not nice).
OTOH, I am immediately suspicious of any product that claims it's professional and also has BASIC in the name...
Ada is not fringe. It's used by many large companies, although less and less these for new projects these days. There are some huge Ada codebases being maintained in industry, particularly in the aviation industry.
You are right. I completely forgot about ADA and representative clauses. I remember reading that representative clauses mapping to register fields. And to be fair, basic and pascal also can be used for bare metal stuff.
Ada isn't a dynamic language, so it doesn't really apply here; you don't get to use it in the ways like Forth; like having a boot ROM with an Ada REPL (laugh).
Of course there are other systems programming "monolithic executable" programming languages that allow straightforward access to memory mapped hardware registers.
Some years ago when Java was relatively new, I had come across this company Esmertec, which was making Java toolchains for embedded devices. Site seems to be still there, not sure about the company:
I wrote a proprietary app in Lisp (using Clozure Common Lisp) for Windows. In the licensing code, I needed to get the list of network adapters and also the volume ID of the installation drive. It was easy to call the Win32 functions directly. Note that enumerating the adapters requires walking linked list of C structures returned by the GetAdaptersInfo function (to which you have to specify an allocated memory buffer where that list will be stored.) I did that all in Lisp; not a line of C.
Yep. If nothing else, just about all of them have the asm keyword. That's non-standard (but almost always present) in C compilers, and "conditional" in C++ (i.e. the keyword is in the standard, but the semantics are implementation-defined).
And yeah, it's a given that it's going to be non-portable.
Given asm, implementing a Turbo C-style int86() function seems pretty trivial. It might even be doable as a macro.
Not to mention that you could just use C identifiers in the asm block willy-nilly:
int foo(int c)
{
int r;
asm {
mov ax, 0x0b00
int 0x21 /* poll stdin for input */
mov ax, offset c /* get address of `c` */
call bar /* call other C function */
mov r, dx /* save the result in `r` */
}
return r;
}
Or something like that — it's been a while. Those were the days! GCC's (and I'm assuming clang's is much the same) inline assembly is a joke in comparison. I remember, when I first encountered it, flipping back-and-forth through the GCC docs looking for how people actually do inline asm with GCC...
Forth is really neat. It's a rare langauge that has the same abilities as C to deal with hardware, but is a higher level language than assembly, and isn't C. Most languages in common use today have reached a level of abstraction where direct hardware interaction is either impossible or discouraged.
Also, my time with Lisp has taught me that interactive environments are A Good Thing, and Forth is exceedingly interactive, and has better native introspection than many Lisps (when your guts are strewn across the floor, it's hard to hide them).
But for all that is good about it, Forth does have its problems: depending on how well your problem maps to the stack, Forth can be exceedingly painful.
I really, really wanted to like Forth. I love learning new languages and different paradigms from those I know already. The fact that Forth was really tiny and yet very powerful and could do meta-programming in a Lisp-like way (though I hadn't yet learned Lisp at the time to fully appreciate what this meant) was also very attractive.
Unfortunately, learning Forth was a real let down. Forth turned out to be way too much of a write-only language for me, with lots of convoluted, hard to understand code. The Forth community preaches simplicity and using short, clear, well documented words (functions). But the reality, at least in most of the open source Forth code I've seen was the opposite, with long, convoluted, poorly documented words being the rule rather than the exception. I've been told that commercial Forth code is a lot better in these respects, but I haven't verified that.
I've also heard even Forth fans tell me that the whole point of Forth is to write yourself something more pleasant than Forth to work in as quickly as possible. Since I don't have an interest or need to write programming languages myself, I'd just rather start with something more pleasant from the beginning, and skip the painful stage of having to work with Forth.
In very resource constrained environments where your only alternative to assembly is Forth, Forth might be the best choice. But since I don't do most of my programming in such environments, I really don't see the point of using Forth at all.
Finally, after learning Forth, I went on to learn Lisp and then Scheme, and fell in love. Those (especially Scheme) really were super clear and easy to both write and read, and felt far more powerful and not at all painful. I felt far more productive in them, and would now far rather use a tiny Scheme or even Lisp on a resource constrained system, if at all possible.
Have you looked at Clojure? It's a modern Lisp that feels designed to be simple, yet powerful. It works on the JVM/.NET/JavaScript platforms, so it's reach is almost universal.
It turns out to be very portable because the assembler code is only about 1000-2000 lines. The rest is implemented in Forth itself. They use indirect threading to produce very dense code. They kept even most of the debugging symbols inside the code and kept the forth interpreter itself in the code.
At one point 10ish years ago the starflight source code was posted online by one of the authors, but it went back down pretty quickly. Someone might have a copy though. A few of the files are on archive.org, but not the main body.
is based on these documents and I filled some gaps of the symbol table. To start the game they used the word "LET-THERE-BE-STARFLIGHT", in the binary you see only part of it: "LET-TH".
I wish this "someone" would provide a full copy of the archive :)
It is similar, but the compiled code here is not fully architecture independent like for the Z-machine. Each word in Forth is compiled to a function pointer. So the Forth code vary for another architecture or when you recompile. But thanks to debugging symbols this is easily reverse engineered and you can easily figure out what is "+" or "-" for example.
I like Factor, but staying small and innovative, I really like what Charles Childers has done with Retroforth. He has implemented a newer version running on a smaller VM Nga (the older was Ngaro) called Retro 12 [1]. Very cool stuff.
> But Forth is also like a high-wire act; if C gives you enough rope to hang yourself, Forth is a flamethrower crawling with cobras. There is no type checking, no scope, and no separation of data and code. You can do horrible things like redefine 2 as a function that will return seven, and forever after your math won’t work. (But why would you?) You can easily jump off into bad sections of memory and crash the system. You will develop a good mental model of what data is on the stack at any given time, or you will suffer. If you want a compiler to worry about code safety for you, go see Rust, Ada, or Java. You will not find it here. Forth is about simplicity and flexibility.
When it comes to working on a large project in a team, I suspect Forth doesn't scale.
Think of why Go works so well for Google: it's designed for code bases that are maintained by many people. And almost every design decision that was made for that goes against the spirit of Forth.
It's too flexible; you can change anything about the system so any Forth code ends up deeply personal, and specific to the current task. It's a language for individual artisans, which is another reason why it works well in the embedded space. But it's not hard to see how it all goes up in flames when you're in a large team.
> Think of why Go works so well for Google: it's designed for code bases that are maintained by many people.
There's another dimension of this that works for Google, though, and it's one that people particularly here should take note of.
As far as I can tell, Go is a language where the solution to a given expressive problem is usually "write more code." There's nothing subtle or clever to leverage into a multiplier, like there is with Forth or LISP. You don't write a DSL. You don't factor out largely common implementation details. You may well not create composable subcomponents for some intermediate level. Instead, you put in the time, turn the crank, and create whatever straightforward code solves your concrete problem at the level it's written, straightforward if verbose. It's similar to how MJD describes working in Java (http://blog.plover.com/prog/Java.html ), except you're missing some of Java's expressive power and you have some of Pascal's to make up for it.
There's a degree of simplicity to it.
An organization like Google is not lacking in any way resources to have developers produce more code. Or understand it, if any issues with expressivity to volume ratio ever makes a given codebase difficult to grok.
Does your organization have those resources?
Do you?
The answer to that question (along with who you're competing with) might tell you whether you should be using a Google language or a hacker language.
...And Forth's DSL's are worse than most, by virtue of having minimal syntax, and being bound by the stack. So it's not just the Lisp problem again: it's actually worse.
> When it comes to working on a large project in a team, I suspect Forth doesn't scale. [...] It's too flexible
If, in any language, flexibility is a problem for a larger team, fire the lead developer. The article does a good joint pointing out that using that flexibility is usually a sign of code smell.
which is actually a truly message-passing based arch with 144 clockless "cpus". Each cpu is actually so limited that forth is one of the few languages that makes programming this tricky platform viable.
Worth playing; if you enjoy programming challenges within limited environments, you would be hard pressed to find better games than the Zachtronics set of games.
I'd love to think of something to do with GreenArrays, although AFAICT they're kinda dead. The idea is fascinating, but I honestly don't know what I would use it for.
I came to Forth-like languages via PostScript, which has the advantage of a huge built-in graphics library. It very naturally introduces concepts like higher order operations, code as data and data as code.
I really lament that PDF and the victory of Motif meant the end of PostScript for most purposes. Sadly I was a bit too young for NeWS, and there seems no emulation available anywhere. Ghostscript itself isn't exactly tooled for actual programming...
Back in the 90s the most popular train route web site in Germany used to send you a PS file for printing on Linux (they did something more native for Windows). And that was basically a serious of quite easy to understand line drawing and text positioning instructions.
And I think it was jwz who had some cassette cover sheets where you put in the song and artist data by editing the PostScript file itself.
There is a decent amount of Forth publications out there, but nothing that really takes you from A->Z in building your own Forth based off of Assembly or C. JonesForth helped me conceptually understand parts of Forth, but there is a lot missing there for me to be able to start from scratch. I would pay $ for a real book in the vein of "Land of Lisp" that shows you how to build a Forth compiler/editor and how to extend it...the pros/cons of different design decisions like direct/indirect threading.
You might find R. G. Loeliger's book "Threaded Interpretive Languages: Their Design and Implementation" [1] interesting. Here's a review [2]. The comments on that review list some online resources that might also be useful.
It's long out of print, but used copies are cheap, and scans are readily findable on the net.
I wrote a comment a while back outlining how to do a FORTH-like language from scratch by starting with a simple calculator and expanding it, writing in C with optional assembly optimizations. This was aimed at people who have less knowledge of FORTH-like systems than you do, I think, but if you are curious here it is [3].
No I'm thinking of LoL, but I meant the irreverence and comical simplicity like Leo Brodie's Starting Forth, but also focusing on how to write one from scratch (you are correct LoL doesn't do this).
FORTH variation #1,000,001: I took John Walkers' AtLast as a core, and extended it in several directions, some I believe quite significant. My use case for FORTH has been as a live debugger that lets me interact with a running Real Time system, an environment where breakpoints are not very useful (except in crashes) because they only allow for post-mortem examination, but a RT system needs to be watched while it is runnung to more quickly discern pathologies.
Extensions that saved me the most agony:
1: Use of stack frame comments to actually define local variables and enforce the in - out stack transform. While at this I also added the comment string to the word definition in an additional help link. Thus:
> help do_it
in1 in2 -- out : return in1 * in2
> 3 6 do_it .
36
>
Note the [:] and [;] redefs for compiler words, had to do this to accommodate nesting, locals, stack frames, while not compromising regular FORTH.
all variables are local in scope to the containing word. Defining variables inside ditto. Had words for listing contents of these too.
I later extended this to include nested word definitions, dynamically allocated variables, and stack frames that will unwind these on execution error. Gone were stack frame size errors, a missed dup or drop no longer fatal, indeed dup and drop not really necessary any more.
2: Structured data debugging aides: a few words and a C header parser allowed me to dump or modify readable contaents of application structs, and to call into application functions.
3: along the same lines of nested definitions, I was able to associate sub-dictionaries with graphical views along their heirarchy. This was a later addition, applied to VNOS. Lots of little things became manageable with this paradigm. In particular, allowed me to do a scoped local console (as a debug object instantated in a View), and to insert message overrides into the VNOS messaging mechanism, effectively adding what turned out to be a really powerful scripting system. Done as an object too - current version includes Perl 5 and Lua (almost ready).
And yes, concurrency is a concern, and being sure not to call non-re-entrant (errant:) functions, but hey, ypu'd likely be surprised at how good a pattern recognizer ther Human Brain is here.
Over-all, I think I used this system with a good half-dozen different CPU architectures and their OS's, also in the high level VNOS GUI (originally put my FORTH into it for debugging purposes, but that was rapidly out-grown).
Forth is a hacker's language only when we take a narrow definition of "hacker" as someone who cares about making a device field-programmable in the easiest, smallest way that doesn't completely suck, and can somehow get things to work without caring what the code looks like or whether anyone understands it, including the same hacker seventeen months later.
Mentioning APL in this context makes me picture an 8 bit home computer with an APL interpreter. I mean, the C64 had all kinds of weird symbols on its keyboard, too. And the magazines would save quite some pages for their source code listing compared to BASIC...
For Forth, that's an easy answer: when you think "hacker" you're thinking of people working on the Big Iron. Forth's niche was small machines, so while it had a good bit of popularity on the micros, its influence on the mainframe hackers, with their "we hate micros" ethos, was minimal.
I suspect younger programmers can't even begin to imagine what it was like. I learned to program on the Commodore 64. The default language was (Microsoft) Basic. Line numbers. Only flow control IF, GOTO, and GOSUB/RETURN. No loops, no ability to write functions, nothing like a define or a macro.
And then I got my hands on a Forth. Functions. Control structures. Maybe they weren't fancy by modern standards, but they were easily an order of magnitude better than Basic's, and you had the ability to write new ones fairly easily. Quick compiles, code which was both small and fast. Easy inline assembly code for when you needed even more speed. It was a dream come true.
We younger programmers started with Scratch. Sure, it makes pretty pictures, and you don't have to type, but it has only global and object-local variables, barely has function calls, and is generally awkward.
It wasn't until the 2nd or 3rd time I'd used it that I actually figured out how to make sense of it and run something (for Scratch's definition of "run").
To be honest I've progressed extremely slowly with CompSci/programming over the past 18 years I've been using them (got my first computer around 7-8) - I started with QBasic, been shouting at PHP for way too long, I have a basic understanding of C I badly need to develop, and I'm moving toward playing with Lua next - and I hardly consider myself a dyed-in-the-algorithms academic type with a brain that's unable to understand Scratch. (In fact, I'd argue that the best programming teachers would be precisely those types of people, and if they were unable to understand Scratch that would be a major problem.)
Rather, I firmly believe Scatch's UI is a disaster, and horribly unintuitive to use. Other languages are beset with grammatical idiosyncrasies; with Scratch you have to learn the UI before you can learn the... few parts of the language that are actually there.
I'm concerned that systems like Scratch are so widely used; I fear that it's an even worse mind-scrambler than the bad sides of BASIC. Of course, like BASIC, there are good sides, and it teaches the basics without presenting a Mt. Everest-sized learning curve. Perhaps https://en.wikipedia.org/wiki/Dartmouth_BASIC was the Scratch of 1964, and I'm just griping about the dilutory effects of educationally-targeted software in this day and age and "modern" GUI design.
Scratch is also really slow/laggy on my old laptop (Thinkpad T43), I can't imagine how bad it is for schools with limited hardware.
When I used Scratch 1.4, I don't recall the UI being too bad, and it ran pretty fast: Smalltalk is pretty good at that. But I'm generally pretty good at picking up these sorts of things, and my computer wasn't particularly slow.
If you want a Real Language presented the same way, Snap! (descended from BYOB) is essentially a Scheme in Scratch's clothing.
But the two real draws of Scratch were its hackability and its community. Back before Scratch 2.0 ruined everything, Scratch was written in Smalltalk, and using a widely-known hidden feature, you could examine the source code and make whatever changes you wanted with relative ease, resulting in a healthy community of mods and derivatives which explored new features and ideas, or those that the official team had dropped by the wayside (like Mesh, a fully-featured networking system).
Scratch's community was likewise excellent: I spent a lot of time lurking in the Scratch Advanced Topics forum - a sort of off-topic general programming section, where people far smarter than I discussed modifying Scratch, improving the website, and whatever programming projects they happened to be working on (usually web programming in PHP - it was the mid 2000s, after all).
Ah, I encountered Scatch 2.0. I'll definitely check 1.4 out, it looks a lot more accessible and reasonable. I would have loved to have encountered something like this at 14 or 15.
I suspect the reason Scratch felt slow to me is that 2.0 is some kind of HTML5 and/or Flash mess now - you're right, Smalltalk is really fast. I spun up Squeak to check something on this T43 yesterday, and everything was really snappy. I have no reason to expect Scratch will be any slower.
Also, I wouldn't be surprised if a reasonable bit of the exploration everyone did was motivated by the fact that they were "hacking" the platform :P
There seems to be a sad lack of excellent online communities nowadays; I've long looked for sites to complement HN, but without success.
I just had a look at Snap! which is interesting. It definitely flatlines this laptop though, I had to try it on a faster machine. But I'm running the tree animation demo right now, and it looks awesome....
>Also, I wouldn't be surprised if a reasonable bit of the exploration everyone did was motivated by the fact that they were "hacking" the platform :P
Nor would I. Even at the age of 8, before I was really able to understand the code, there was a thrill to it, in a cracking-open-the-toy kind of way.
And it helps that Smalltalk does exploration better than just about any other language/environment. You can just open up any Smalltalk app and extend/take it apart using the same tools the developers did to build it.
>There seems to be a sad lack of excellent online communities nowadays; I've long looked for sites to complement HN, but without success.
Lainchan (a sort-of cyberpunk/whatever chan) is quite popular with some of the people who are here on HN. It's a very different atmosphere, but it does emphasize actual good discussion. And it's got a containment board for politics, which always helps.
At the very least, their magazine (https://lainzine.neocities.org) is worth looking at, if not for the generally interesting articles, than for the outright strangeness of a lot of it.
Wow, nice! At 8 (1999) I was given a probably-6-or-7-year-old 286 running DOS 3.3 with nothing on it. That got swapped for an XT a couple years later, which I discovered Qbasic on and got tangled up in for way too many years :S. Smalltalk would have been awesome to discover at that age, moreso a toy with sekret doors and passages in it for me to discover :D
I was recommended Lainchain a couple months ago, actually, but nobody mentioned the magazine, which is really cool. I am not impressed that the ASCII art generation paper in Vol.1 has any associated source code!! The rest of the magazine content and design is really interesting too.
For what it's worth, after a bit of research [1], I discovered Commodore Basic 2.0 had simple FOR loops (which I think I used and forgot), and the ability to create functions which encode a single one-variable mathematical expression (which I don't think I ever knew about).
I forget what the name was, but I used a Microsoft Basic on the IBM PC platform a few years later which was light years better than the C64 Basic. Still gave it up ASAP after learning C, mind you.
And it is dead simple to implement. I did it in common lisp 3 years ago for an IRC-bot - a lazy Sunday afternoon and 50 lines of code later I was done.
I would not want to write code in Forth on a regular basis, but reading (and making an effort to really understand it) definitely made me a better programmer.
The main reason I fell in love with the HP 48 calculator series was the RPL programming language, which could be described as the pragmatic lovechild of Forth and Lisp - think Forth with higher-order functions.
My first program was written in FORTRAN IV and it compiled and ran in the summer of 1967. After that, I learned APL, Z80 assembly, and BASIC.
The August 1980 issue of BYTE magazine was all about FORTH. I read it cover to cover, then sent to the Forth Interest Group for a copy of the implementation guide and the 8080A listing of Forth.
I typed it all in, including comments but changed the 8080A mnemonics to Z80 mnemonics. After the typos were corrected and the I/O routines modified to run under TRSDOS it ran as advertised. Then I optimized the code for Z80 which made it both smaller and faster.
My job then took me from Tandy's manufacturing plant to the R&D department where I wrote assembly code for another product but continued to work on Forth as a side project. Management said that they would be willing to release it as a product if I could get a signed statement declaring Fig-Forth to be in the public domain. I tried repeatedly to get people at the Forth Interest Group to sign but was never successful. This is the reason Radio Shack never released Forth, though many people in R&D used my code internally. They especially liked the ease of number base conversion.
From Tandy, I went to an industrial equipment manufacturer where I wrote a lot of assembly for embedded applications. I ported CP/M to run on TRS-80 model 12. The need arose to read input from a graphics tablet via serial, process the input and output a bitmap. My estimate on the length of time it would take to write this for the CP/M machine extended past the deadline.
I combined my Forth code with the drivers for the Model 12. The boot procedure for Model 12's consists of reading 26 128-Byte sectors from Track 0, Side 0 into memory and jumping to the loaded code. I changed to format of the remaining tracks (both sides) to 9 1K sectors and a 256 byte sector (double density). My boot code prompted to press the F1 or F2 key, then read all the 256 byte sectors on side 0 or side 1 (depending on F1/F2) into memory. I added a FSAVE word which wrote memory to the 256 byte sectors. I had a Forth operating system. I wrote the code for the application in Forth, performed the necessary scanning and conversion and output the desired bitmap with time to spare.
I highly recommend learning assembly for at least one processor. Without it, you can only know about Forth, you don't really know Forth. I understand how directly threaded code (DTC) works but I prefer the indirectly threaded code (ITC) model of Fig-Forth as it seems more elegant to me.
I still have an x86 machine running Windows XP which will run the 16-bit code but it will not run on my Windows 7 system. I am looking at ciforth [1] which is a 32-bit implementation. I intend to get it running under Windows 7.
Forth is a really good system for a command line environment. As far as readability goes, the code itself has such high information content that it is difficult. It is up to the programmer to add abundant comments which make reading the code unnecessary in most cases.
Part 1: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth...
Part 2: http://git.annexia.org/?p=jonesforth.git;a=blob;f=jonesforth...
(github mirror: https://github.com/AlexandreAbreu/jonesforth/blob/master/jon... https://github.com/AlexandreAbreu/jonesforth/blob/master/jon...)
Previous HN comments: https://news.ycombinator.com/item?id=10187248