
Plan9 from? - tbirdz
http://www.ultratechnology.com/plan9.htm
======
samatman
Good context on why Forth didn't pan out can be found here:

[http://yosefk.com/blog/my-history-with-forth-stack-
machines....](http://yosefk.com/blog/my-history-with-forth-stack-
machines.html)

I adore Forth and feel that it's in the small handful of languages /
approaches to language that will permanently change a developer's
understanding of the field. Perhaps if GreenArrays had succeeded well enough
to make a few more generations of processor the landscape would be very
different. Perhaps not.

Given today's architecture, the impedance mismatch between the stack paradigm
and the register architecture costs Forth most of its advantage. Still, if
there's another language that allows one to write an interactive assembler for
a system with 8k of RAM, I've yet to hear of it.

The minimum investment in Forth, which I recommend to all thoughtful
developers, is reading _Programming a Problem Oriented Language_ by Chuck
Moore, Forth's inventor.

~~~
david-given
While back I wrote a Forth interpreter. (2.4kloc of portable C, passes nearly
all the ANS Forth test suite.) I recommend this to anybody interested in
programming languages; you don't have to _finish_ it, but once you get the
core interpreter working (in mine, the inner loop is two lines of C!) there's
this _aha_ moment and you finally get what the fuss is about, and you can feel
your brain expanding.

But as a programming language to work in? Well...

\- Forth has no (well, very little) runtime error checking. If your stack
underflows, and you're lucky, it'll halt and tell you. But get anything else
wrong, and it won't notice, and it'll just silently and invisibly poison its
internal state and then crash _later_ in a way that's really hard to debug.

\- The language is strongly typed. It just doesn't have any type checking, and
if you get the types wrong, it'll silently and invisibly poison its internal
state and the crash _later_ etc. You have to remember what type of object you
push onto the stack, because you need to use the right kind of word to consume
the object again. Does this word push a float? You need to know, because you
need to use FDROP instead of DROP to consume it.

\- The main culprit here is the compiler, which passes internal state around
is by pushing objects onto the compiler stack. e.g. the BEGIN word, which
starts a loop, pushes a 'dest' object onto the compiler stack. You have to
consume this with UNTIL, WHILE or AGAIN. If you use the wrong word, or exit
the definition without consuming it, it'll silently and invisibly poison its
internal state etc. So you're now mentally juggling three different stacks:
the data stack, the return stack, and the compiler stack, and if you make a
mistake _anywhere_ you're going to have a bad day.

\- There's a _lot_ of trivia to remember, which you need to remember. EXIT is
allowed inside a BEGIN..AGAIN loop. But it's not allowed inside a DO..LOOP
loop, because DO..LOOP loops are permitted to store a state object on the
return stack. I will retrieve the index of the innermost DO..LOOP loop, and J
will retrieve the index of the next DO..LOOP loop... but not if you've pushed
something onto the return stack yourself inside the outer loop. If you don't
get it right, it will silently and invisibly etc.

\- Forth's only really intended to work on bare metal, and this shows. e.g.
data space is assumed to increase from HERE up to the top of memory, and
there's no facility for disjoint data spaces. The way you define data is to
take a pointer to HERE and then just write stuff. All that stuff is defined to
be contiguous. There's no scope for, e.g., running out of heap and allocating
another block from the operating system. Oh, and try not to run out of memory,
because it will etc.

\- Stack juggling gets old very, very quickly. (Although some Forths, not
mine, support local variables.)

Where Forth really excels is as an assembler substitute, where you're will to
focus down and concentrate on every byte of source and you're going to put up
with a complete absence of error checking because you need the performance.
It's certainly great there. Being able to fit a complete interactive
environment into a tiny, tiny space is astonishingly useful for debugging. But
I'd hate to have to write anything of any great complexity in it.

I _have_ heard of type-checked Forths; here's one, although I notice it takes
a lot of liberties with the language (like not really having a return stack):
[http://www.arestlessmind.org/2009/02/03/intro.html](http://www.arestlessmind.org/2009/02/03/intro.html)

But I've never used one. I should, one day; I'm willing to believe that it's a
much more pleasant experience than raw Forth. In particular, an embedded Forth
with strict type checking but no runtime overhead sounds amazing...

(Aside: the Jupiter Ace was a Z80-based home computer from the 1980s, about
the same grade as the ZX81. It came with Forth. Javascript emulator!
[http://jupiler.retrolandia.net/](http://jupiler.retrolandia.net/) It's got
games! In Forth! Load one, do SHIFT+SPACE to exit, then 'vlist' will dump the
dictionary and 'list word' will decode a word.)

~~~
astrobe_
> Forth has no (well, very little) runtime error checking.

I don't think the standard prevents you from implementing that. If you want
it, do it.

> The language is [WEAKLY] typed. It just doesn't have any type checking

True. However, a linter that does some type checking seems possible, provided
some annotation syntax for the hard cases where it's not possible to infer
types. The thing is, despite its long existence one doesn't see many "Lint for
Forth" around, so we can guess people managed to solve this problem in a
different way.

> So you're now mentally juggling three different stacks: the data stack, the
> return stack, and the compiler stack, and if you make a mistake anywhere
> you're going to have a bad day.

The "compiler stack" is never an issue unless you overuse the
"metaprogramming" capabilities of Forth like you'd abuse macros in Lisp. I
understand you might have had that impression if you spent more time
implementing the interpreter than implementing programs.

> There's a lot of trivia to remember, which you need to remember. EXIT is
> allowed inside a BEGIN..AGAIN loop. But it's not allowed inside a DO..LOOP
> loop

Well of course you're supposed to know that the loop index is stored on the
return stack. For a Forth programmer, it's as trivial and obvious as taking
care of freeing malloc'ed memory is for a C programmer.

> There's no scope for, e.g., running out of heap and allocating another block
> from the operating system. Oh, and try not to run out of memory, because it
> will etc.

That's because it's typically not needed for various reasons. However if you
really need it you can: \- make all of your addresses relative so that your
system can reallocate the dictionary space; in other words, make your VM run
Place Independent Code (PIC). \- create a library that allows you to allocate
memory from the OS or the heap.

> Stack juggling gets old very, very quickly. (Although some Forths, not mine,
> support local variables.)

It's like saying FP is a hoax because you use mutability all the time. The
problem is not in the language, it's how you use the language.

> While back I wrote a Forth interpreter. I recommend this to anybody
> interested in programming languages; you don't have to finish it

You should really finish and actually use it because you don't understand
Forth yet.

Oh, and don't be afraid to discard standard compliance. It's a bad trade for
you: you get all the constrains and will probably never benefit from the
advantages.

~~~
david-given
> You should really finish and actually use it because you don't understand
> Forth yet.

It's interesting that you assume I never finished it.

------
robochat
This article is bonkers. How can you directly compare a programming language
to multitasking operating systems with desktop enviroments? In what sense is
this a sensible comparison? A comparison of embedded code written in C vs
Forth would make sense but starting from Plan9 and then swerving off into
embedded programming, all the while laying down a thick layer of
condescension... Maybe I'm missing something?

~~~
Sanddancer
The article was written in the year 2000. A lot has changed since then, in
pretty much every realm that he discusses. It's not a bonkers article, but it
is an artifact of an earlier era.

~~~
AstralStorm
Even in 2000 we knew the difference. The author is either naive or ignorant.
That while having an agenda to promote his own work on a niche platform.

~~~
catwell
Well, the view that we can do without "Operating Systems", or rather have the
language be the operating system, is not new. It has always been pretty
popular in the Lisp, Smalltalk, Forth... communities.

Daniel Ingalls famously wrote in 1981: "An operating system is a collection of
things that don't fit into a language. There shouldn't be one." [1] A few
years ago a paper argued that Plan 9 was basically trying to achieve that
Smalltalk vision. [2]

And if you think about it, that view is extremely fashinable today, with the
rise of unikernels [3]. Granted, they are not used for Desktop systems as of
now, but who says they won't be in a few years.

[1]
[https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....](https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html)

[2]
[https://www.cl.cam.ac.uk/~srk31/research/papers/kell13operat...](https://www.cl.cam.ac.uk/~srk31/research/papers/kell13operating.pdf)

[3] [http://unikernel.org/](http://unikernel.org/)

------
zokier
Digging bit into Forth CPUs I found this little story:
[http://www.drdobbs.com/parallel/seaforth-40c18-architecture/...](http://www.drdobbs.com/parallel/seaforth-40c18-architecture/228700748)

I must say that the diagram does remind me a little bit of TIS-100:
[http://i.imgur.com/pxA3H4N.png](http://i.imgur.com/pxA3H4N.png)

Admittedly its not that novel of a structure, but still it looks like fun
piece of kit to play with.

Otherwise, in general I think Forth has bit similar culture/community than
LISP, even if they come from very different backgrounds. Both feel smugly
superior compared to common C programmers and feel slightly bitter from being
unfairly pushed into niche. Both highlight the minimalism of their idol and
celebrate it by creating bazillion tiny implementations.

~~~
koytch
> Otherwise, in general I think Forth has bit similar culture/community than
> LISP, even if they come from very different backgrounds. Both feel smugly
> superior compared to common C programmers and feel slightly bitter from
> being unfairly pushed into niche. Both highlight the minimalism of their
> idol and celebrate it by creating bazillion tiny implementations.

Seconded. Additionally, implementing Lisp in Forth (on a Forth CPU for bonus
points) sounds like something one should try for the sheer coolness of it.

------
sebcat
What is a system call in Forth? NEXT (load an address and jump to it)? If so,
yes, forth "system calls" are faster than Plan 9s, but only because Forth
doesn't have the separation of user-/kernel land. It's really not a fair
comparison.

~~~
sp332
It has a virtual machine architecture, so it's like a unikernel application
making a system call.

------
stirner
What is the connection between Plan 9 and Forth here? Simply that they are
both replacements for widely-used software?

~~~
firethief
They both have magical powers.

------
dsr_
Needs a (2000) tag. @dang

~~~
nickpsecurity
Yeah, otherwise a reader might assume Forth has reached the performance of
OpenPOWER or high-end Xeons with less transistors than the old, Intel CPU.

------
micro_softy
"Microsoft's software makes using an old timeshareing [sic] operating system
on a PC look really great in comparison."

Amen.

I would like an APL using ASCII characters written in Forth.

~~~
samatman
Voilà: [http://cosy.com/language/](http://cosy.com/language/)

~~~
micro_softy
Reva Forth (Windows/Mac/Linux)[1] is cool but how about a Forth that does not
require an OS? 1\. No Plan9/BSD/etc.

The true beauty of Forth to me is the relative ease with which one can boot
into a Forth REPL and start controlling hardware, without an "OS".

The idea is a computer with APL as its "OS". The project at kparc.com is
closer to this idea than the one at cosy.com. What is evident in both cases
that this idea has survived. And that's good.

~~~
pmarreck
Reminds me of the old Symbolics workstations and the "Lisp all the way down"
design

------
ianai
The term to describe reading this in 2016 when it was written in 2000 is:
uncanny. So how come my tablet and cell phone aren't running Fourth/plan9?

~~~
khm
Because the OS you care about on your smartphone isn't linux or ios, it's
webkit/blink, and nobody on earth has the capital and the business case for
porting a modern web stack to anything at all different. The BSDs are allowed
to play because of POSIX, but only if they hop on the video driver treadmill.

In short, there's no money in it, which is the real takeaway from this
article.

~~~
AstralStorm
Nah, some people care about Android or iOS. Because there is money in it.

------
mmel
I was blown away by this 2011 video of Charles Moore talking about his CPU
design and running code, talking about how the different nodes are creating
the frequencies to produce the images you see on the projector -

[https://www.youtube.com/watch?v=NK1zlz67MjU](https://www.youtube.com/watch?v=NK1zlz67MjU)

------
wtbob
I've noticed in myself how awful it is to be in this industry and see the same
problems solved over and over again, with only marginal improvements — and
quite often, rather large steps back. It must be even worse for Forth
programmers.

~~~
zzzcpan
I'm on a different side. I notice a lot of great solutions to many problems,
but while the ideas are solid, they are rather poorly executed. A lot of
things are like that and would really benefit from properly executed
solutions. But the industry is not there yet, we don't have nearly enough
people with enough knowledge and experience to make things happen at a faster
pace.

------
ghshephard
Even written in 2000, the author was conflating Windows 3.x/95/98, which was
flakey as all get out, with Dave Cutler's VMS reboot, the NT kernel, which
was/is a pretty excellent OS and pretty fully baked by 1995.

------
pmarreck
Trivia, the Open Firmware boot firmware that Macs use is written in Forth (and
if you get a prompt, understands Forth):
[http://osxbook.com/book/bonus/ancient/whatismacosx/arch_boot...](http://osxbook.com/book/bonus/ancient/whatismacosx/arch_boot.html)

------
jjgomo33
Shouldn't Forth be in hype again due IoT?

~~~
chubot
It appears that the current gen of "IoT" is built on cheap SoCs which run
Linux.

Linux is millions of lines of C code already, so using Forth in that context
feels a bit ridiculous.

~~~
pjmlp
Cheaper SoCs like Arduino and Cortex-M3 run bare metal runtimes, just like on
the old days.

But yeah, I guess for single units people will just shell out 10 euro more and
use a Linux capable unit.

However there are options to use better languages than C or C++ for bare metal
embedded development, but none of them tends to be Forth, rather Basic,
Pascal, Ada, Java, .NET, Oberon variants.

------
mrfusion
What's inefficient about UNIX and Windows? I couldn't gleen it from the
article.

~~~
Avshalom
in the sense that forth programmers are talking about: that they exist at all.

~~~
marvy
Lest someone thinks you're exaggerating:

[http://archive.is/YLh6I](http://archive.is/YLh6I)

Quote:

Forth does it differently. There is no syntax, no redundancy, no typing. There
are no errors that can be detected. Forth uses postfix, there are no
parentheses. No indentation. Comments are deferred to the documentation. No
hooks, no compatibility. Words are never hyphenated. There's no hierarchy. No
files. No operating system.

~~~
AstralStorm
Less useful than assembly which at least allows comments. The only difference
is portability, which C does much better already.

Forth shoves down your throat its ancient stack model and lack of higher order
types.

~~~
marvy
Forth allows comments. The quote is just saying "why bother using them?"

~~~
piaste
That's like saying "why bother with hyperlinked text? Just put your URLs in a
footnote".

~~~
marvy
Which I notice a lot of commenters here in fact do. (Though to be fair, HN
doesn't quite support proper hyperlinks.)

------
Avshalom
Goddamned Forth Wizards making the rest of us look inadequate.

------
danbmil99
FORTH rocked.

