4os – An operating system written completely in Forth

That right there is an excellent question. I was one of those whose first language was Basic, and I really wonder of Dijkstra was right: was I permanently damaged by learning it?

They released some of it under a look-but-don't-touch license for a while, in an attempt to build a community, and you could get a free license for the desktop version of QNX (with all the developer tools in it). I think I still have a CD somewhere. It worked pretty well.

It may even be still available, but after digging up my old Foundry27 username and password (which, surprisingly, still works), their download site is an impossible trainwreck and I was unable to find it any more.

The demo floppy, by the way, is here:

http://toastytech.com/guis/qnxdemo.html

Requires a 386 and 8MB of RAM.

I thought function level were limited to backus languages, and that factor was part of stack based, at best concatenative.

I'm really impressed with Factor. This is the first time I've heard about it. Thank you for mentioning it.

There's even an OpenFirmware song!

There was Forth for the TI99/4a back around then also.

Lol...think that was obvious satire

"how do you manage a lot of fockers at once?"

In a stack?

Check out http://fuckernetes.io/

You'd probably have a system that creates and manages the others. You could call it the mother focker.

Built using the Forth EDA tools with booleanForth and realForth for modeling the mixed-signal circuits. All on a Forth CPU hand-assembled from a stack of transistors.

Just get Mark V. Shaney an account.

It's been a while so I might not recall all the details. This is what I did on a 6502 in the 80's (the order might not be exactly right):

    - Write drivers (in assembler) for external UARTs and parallel port chips
    - Write (in assembler) enough code to get the very basics of Forth going
    - Now in Forth, write the standard set of Forth words
    - Write a rudimentary text editor
    - Write a floppy disk driver and file system management code
    - Now I have a Forth computer
 

At that point I started to use Forth for robotics. Quadrature encoder inputs. A/D, D/A and digital I/O. Eventually doing real-time PID loop. Control a single motor. Build a robot arm. Control five or six motors. Build an external LED hexadecimal display. Talk to it in Forth. Build a buttons and knobs control panel for the robot. Talk to it in Forth. Have loads of fun and learn a ton.

In other words, I had a very specific project in mind and saw it through from a bunch of chips on the workbench to a finished robot arm with user interface.

There are a million lessons to be learned in such a project.

I've actually thought about dusting off my old files and designs and putting together some kind of an educational kit to launch on Kickstarter. It could be a lot of fun.

FWIW this old school games programmer (think Atari IIRC) talks a lot about Forth: http://prog21.dadgum.com/33.html

(a lot being relative, here meaning "some")

I tried to learn it, and found Forth to be an obfuscated, write-only language.

Forth programmers give a lot of lip service to writing short, well documented, elegant words (functions) but in real-world programs I've seen the opposite: the tendency has been to long, poorly documented, and convoluted words. (At least that's been my experience with open-source Forth programs. I've heard the libraries for commercial Forths are of much higher quality, but I have not verified this myself)

Forth has been compared favorably to Lisp, but I found them to be like night and day, and Lisp (and especially Scheme) to be far more elegant and easy to both read and write.

Forth might arguably be better than assembly, but unless you have a pressing need to write the tiniest programs possible (like on some resource-starved microcontroller), I'd be hard pressed to find a reason why you'd want to use Forth instead of some higher level language that is far less painful to work with.

In fact, I've even heard some Forth fans themselves say that the point of using Forth is to write yourself something as quickly as possible that lets you program in a higher level language.

Don't get me wrong, I really, really wanted to like Forth and spent a lot of time trying to learn it, but in the end it felt like it just wasn't worth it. I might give it another go if I get heavily in to programming microcontrollers where Lisp or Scheme is not an option.

I cut my teeth using Forth for writing automated tests for storage products (pretty legacy, I'm not sure if the company uses it any more), and got hooked on it afterwards. The test system was based on a custom real time OS, and Forth was a really good fit, but it would be really hard to find developers now that understood how to work with the system. I had also bought Threaded Interperative Languages (https://www.amazon.com/Threaded-Interpretive-Languages-Desig...) and chose to roll a Forth interpreter for an 8051 dev board I had laying around, which was pretty fun, and wasn't too difficult. It's mostly just a hobby now, as I don't think there's a lot of companies out there still using Forth.

I think Forth is still useful for embedded systems, often even more so than C, especially given that it can go places that C can't. I would personally choose it for my own embedded projects, but the paradigm is sufficiently different that I would worry about finding other people who have the mental capability to write Forth that doesn't immediately devolve into something unmaintainable, or who even want to learn it in the first place. I still write little scripts with GForth sometimes too, but it's not nearly as productive as just writing some Perl or Python. If you're interested in playing with a slightly more modern concatenative language, Factor is a good choice.

I use it for scripting and as an embedded debugging language for other programs.

For instance I wrote a logging program that collects log messages sent by various sources via UDP, displays them in colours on the console and records them in different log files. It is also a HTTP 1.1 server that I use to monitor a few key data about the logs from a browser on an other machine.

The right way to use Forth nowadays is, in my humble opinion, as a template to build yourself your own interpreter that does exactly what you want (as long as you know how to do it ;-), because it has a very low barrier-of-entry implementation-wise.

The "Forth is good for embedded stuff" pitch becomes less and less true every year, because embedded micro-controllers become more and more powerful. Other small languages like Lua are becoming "good enough" on these and are more "user-friendly".

Extrapolating from myself I would say that those who stick with Forth are just liking it and/or like to have absolute control over their tools.

Forth also makes a good scripting language for many applications due to being compact and very easy to implement. Warren Wilkinson used Forth for scripting in his Common Lisp-based web forms/reports/documentation app: http://lambda-the-ultimate.org/node/3999

A while back I wrote a Forth interpreter and ended up posting a bit of a rant here about what I'd learnt from the experience, which I won't repeat; but after some more thought, I think Forth is best described as a kind of interactive super assembly language.

Writing Forth requires the same level of attention to detail and obsession with minutiae that assembly does. There's no runtime safety whatsoever. There's no syntactical safety whatsoever. It will do exactly what you tell it, even if what you tell it makes no sense. (I found myself thinking of the interpreter as the worst kind of passive-agressive cow orker. "I just assumed you had a reason for writing that floating point number to the program counter! I'm not a mind reader, you know!" "But if you wanted that loop closed at the end of the word definition, why didn't you close it yourself?" "It's not my job to remember whether that word left a float or an int on the stack. Don't you know?")

But this also gets coupled to the Forth programmer mindset, which is the ultimate YAGNI. Forth programmers don't just avoid abstraction, they consider it evil. I found a good example from Chuck Moore's website, where he compares the Linux IDE driver (thousands of lines of code) with an equivalent Forth one (two lines).

...except, of course, the Linux driver is a command scheduler to the VFS block layer. The Forth driver's just a couple of words which read and write bytes from an IDE channel. They are in no way equivalent, except that in Chuck Moore's eyes they are. The same philosphy permeates the entire language. Good Forth programmers appear to solve hard problems by ruthlessly stripping away everything irrelevant from the problem to end up with an easy one.

So, a traditional Forth system has no file system; it's easier to just remember which disk blocks you put your data in. Code portability's unimportant --- each program runs in its own customised Forth environment; avoiding platform-specific features is a waste of time. (Most Forthers I've talked to hold the ANS Forth spec in active contempt.) There's very little reusable code because each Forth solution is so tightly tied to the problem it's solving to be useless for any other problem.

Where it really excels is in an environment where you don't want any abstractions between you and the hardware --- it's brilliant on tiny, embedded devices. I don't know any other environment which can do so much in so little; being able to connect a serial terminal to a embedded processor with 2kB RAM and run commands on it is so, so useful.

I'd strongly recommend learning at least the basics of it, even if you're never going to use it. There's that wonderful Aha! moment as your mind reconfigures itself.