
The Oforth Programming Language - IFranckyI
http://www.oforth.com
======
luckydude
I'm a forth programmer, I've implemented an editor in forth, a more(1) clone
in forth, a grep(1) in forth and I did a bunch of stuff I've forgotten in
forth for the geophysics department at UW Madison.

I HATE forth. It's a miserable language, I just hate it.

And then I went to Sun and the boot prom language was forth, still hated it.

Then I got to PCs. The BIOS had no language and then Intel did whatever
garbage they did and I was like please, just give me Forth. It's not what I'd
do for debugging a panic but I could make it work. The Intel stuff was way
worse.

I suspect that Mitch priced himself out, otherwise we'd all be using Forth as
the boot language, I dunno what happened. But if you had asked me 20 years ago
would I be saying anything positive about forth I would have kicked you in the
XXXs. Yet here I am wishing that forth was how we dealt with a panic. We'd all
be happier.

~~~
luckydude
[I'm sticking this here because there was a dude who said this was a good
reply and I tried to reply to him and HN say s his post was deleted. I don't
know why, his post seemed pretty reasonable to me, he was asking if forth was
a good boot loader. Shrug.]

I don't for a minute think that forth is the best answer, it's an awful
answer. Even lisp, which I hate with a passion, would be a better answer
because more people have experience in lisp than forth.

Forth is just less shitty than what Intel came up with, I think it was part of
EFI, it's amazingly bad. I've designed a few programming languages and I'm not
good at it, but holy crap, I could be drunk and come up with a better answer
than Intel did. Forth is just a crappy language but it's less crappy than what
Intel did.

The idea that Forth is somehow special for boot loaders is nuts. There is
nothing, that I know of, that makes forth somehow magical for that.

What you want for the bootloader, and for the debugger that you drop into when
there is a panic, is something like C but interpreted. You want to be able to
walk a linked list of page table structures. And to its credit, Sun's forth
could do that. It's sort of twisted to think it could but it did, there were
forth words that did all sorts of kernel magic.

I think that the magic of forth was that it was tiny, back 30 years ago you
didn't want to have a lot of storage for your debugger. That's not the case
today, if someone made the case that they could make things better, here you
go, here's a gig of storage. That's a little crazy but still. Forth was cool
when a meg of storage was a crazy amount.

We can do better. Intel pushed us backwards, Forth would be a step forwards,
but man, I'd take python or Tcl (because then I'd get my pet language L,
[http://little-lang.org](http://little-lang.org)) or even perl as a better
boot language.

Froth has no special boot sauce in my opinion. It was just small.

~~~
zeveb
The real special sauce for Forth is that it's small and it's _knowable_.
Anyone who wants to learn about how elegant a computer system can be should
take a look at jonesforth[0], a Forth implemented in x86 assembly language. It
really is possible for a programmer to easily understand everything a Forth
does, which is wonderful when writing a bootloader or low-level OS.

In a lot of ways, it's a more-structured assembly language.

TCL could be cool for a low-level system too, as could be a Lisp (also: how
can anyone hate Lisp with a passion‽‽‽), as of course could be Forth. Perl &
Python are too big and not minimal enough.

0:
[https://github.com/nornagon/jonesforth/blob/master/jonesfort...](https://github.com/nornagon/jonesforth/blob/master/jonesforth.S)

~~~
luckydude
I tried to like lisp, it just doesn't fit with my brain, dunno why. I tried to
like emacs and it doesn't fit either. I'm a C/sh/vi sort of guy. I like troff,
don't care for LaTex. Some stuff just works better for me, working in C comes
very naturally to me, working in lisp was always a struggle.

I think if I had done more compiler work I'd like lisp better, I've been told
that making an AST in lisp is trivial and it is work in C.

I get your point about small and knowable, I love stuff like that.

------
lolc
The last time I looked at Forth it was to get a more powerful replacement for
the bc calculator. But the minimalistic approach of forth enthusiasts means
there is no powerful REPL.

Unfortunately Oforth doesn't seem very mature to me. To compile it, I had to
install libc6-dev-i386 and g++-multilib so it could do its 32-bit compile. Now
it fails on me with a segmentation fault. If I try the precompiled version, it
just exits with a nonzero exit-code.

So, back to bc, I guess :-)

Edit: Ah I see, it needs --i for interactive mode.

~~~
mikekchar
Forth is a concatenative language. Its REPL is pretty similar to a Lisp REPL.
Everything in Forth is accessible and it's actually common practice to
override the interpreter to implement DSLs.

Haven't spent any time looking at this, but 30 years ago I actually did quite
a lot of programming in an object oriented Forth (3D star field animation
system for the university's planetarium dome, on an Amiga with a bit of extra
hardware). I really enjoyed it.

~~~
mikekchar
Edit: Thinking about it, I realise it's actually a lot closer to Smalltalk
than to Lisp -- you have a built in editor, you build memory images that you
constantly work with, all the code is decompilable so you can refactor easily,
etc, etc

Actual edit: you'd think I could find the edit button :-P

~~~
lispm
Smalltalk does not decompile code (though one can with some limits), but works
with an integrated code management.

Interlisp-D also did that.

~~~
jecel
Actually, a bytecode to text decompiler is a very important part of the
typical Smalltalk IDE. In Squeak or Pharo, for example, you give the virtual
machine a binary file like "work.image" to start the system and it looks for
text files "work.changes" and "version4.sources" so the code browser can show
you the sources. If these extra files are missing it will complain, but will
continue to work normally. If you pay attention you will notice that the
sources have no comments and all local variables are called t2 or t5 - that is
the decompiler subtly doing its job.

~~~
mikekchar
Yeah, what I was thinking of was that the ability to create an AST from the
running image is how the refactoring browser works. I'm not really aware of
any Forth analogy, but it's fairly common (in my limited experience) for Forth
programmers to hack away in the repl, decompile what they've done and then
bung it in the block editor -- so it's kind of a manual version of the same
thing. I really wasn't trying to make any profound statement. Just noting
something that looked kind of similar :-)

------
tom_mellior
So, looking at some examples on rosettacode.org... This is basically a
Smalltalk dialect, which is good. But it is also, completely needlessly, a
Forth dialect. So instead of Smalltalk's statement separator (the period), you
"end" statements by "dropping" some value.

That is, instead of:

    
    
        foo doSomeThing.
        bar doSomeOtherThing
    

you write:

    
    
        foo doSomeThing drop bar doSomeOtherThing
    

Why?

It also has named variables (which some Forth purists don't like), but instead
of the reasonable Smalltalk syntax of

    
    
        x := baz compute: #something
    

it uses

    
    
        baz compute: #something ->x
    

for assignment.

Why?

This might eventually turn into a nice programming language, all it needs to
do is drop (haha) some of the Forth baggage and admit to itself that its
Smalltalk subsystem has everything one needs.

~~~
jabot
The "drop" is not a statement terminator or separator.

There is a stack. You push values on the stack, then you call a function. The
function takes its arguments off the stack, and pushes the return value(s) on
the stack.

If you do not need the return value (which seems to be the case in your
example) you ignore it by just removing it from the stack.

That's what the drop is for.

~~~
tom_mellior
I know. De facto it's for separating parts of the computation ("statements").

------
blunte
Forth was my second language behind Basic on the C64, and I didn't even know
what a "language" was... it was just the way I got my HP 28C to do cool
things...

------
HelloNurse
Many details suggest that it's a very mainstream object oriented design
dressed with somewhat Forth-like syntax, not an "extended" Forth.

For example, both garbage collected objects and heap allocated objects,
uncontrolled multithreading, everything is an object, arbitrary precision
integers, caring so little about the stack that ROLL is missing, gratuitously
different control structure syntax.

------
unclesaamm
Sounds a lot like Factor. I wonder how it compares?

~~~
metaobject
Here’s a HN post from 2010 drawing the comparison between Forth and Factor:

[https://news.ycombinator.com/item?id=1623697](https://news.ycombinator.com/item?id=1623697)

------
DonHopkins
PostScript is essentially a cross between Forth and Lisp.

------
protomyth
Source code looks to be GPL3.

------
sifoo
Glad to see Forth getting some attention, took me around 25 years of coding to
find it.

For those looking for a different take on the same ideas, I'm working on a
Lisp-inspired Forth here:

[https://github.com/basic-gongfu/cixl](https://github.com/basic-gongfu/cixl)

~~~
cy_hauser
Whoa. I'm afraid to look ;-) My immediate thought is, "lets combine all the
mental fun of stack juggling from forth with the tree juggling from lisp." My
brain hurts!

~~~
groovy2shoes
Combining aspects of Lisp with aspects of Forth is not a new idea. The RPN
calculators offered by HP used a language called RPL ("Reverse Polish
Lisp")[1], including a user-level version (a little more Lisp-y) and a system-
level version (a little more Forth-y). While RPL is what came immediately to
my mind, I doubt it's the only historical example of such a combination;
people have been drawing similarities between the Lisp family and the Forth
family for ages.

[1]:
[https://en.wikipedia.org/wiki/RPL_(programming_language)](https://en.wikipedia.org/wiki/RPL_\(programming_language\))

~~~
sifoo
Thank you! PostScript is another example.

~~~
groovy2shoes
While I do get _that feel_ with PostScript, as far as I can tell it was
accidental rather than a conscious design decision.

The stack-oriented nature of PostScript appears to have been influenced by the
engineers' experiences with working with some stack-oriented architectures
from Burroughs [1], rather than from Forth. Some aspects of PostScript were
influenced heavily by other languages in use at Xerox PARC during the
Interpress era [ibid], most notably Cedar, but considering that Interlisp was
also in use at the time, it's not unreasonable to conjecture that it had some
influence; however, any such Lisp influence was likely subconscious, and none
of the people working on Interpress or PostScript or their forebears seems to
explicated such an influence (as far as I can find).

Charles Geschke and John Warnock, the co-founders of Adobe, both deny any
influence from Forth, suspecting that some overlap of design requirements
between the two languages led to the shared properties [2]. I know that can be
hard to believe, given the striking similarity of the two languages, but it's
not the only time that concatenative programming would have been independently
invented: Manfred von Thun's Joy language is likewise similar to Forth, but,
again, not inspired by it. Whereas the similarity of PostScript to Forth can
be explained by a simultaneous need for portability and dynamism in tightly-
constrained environments, Joy's similarity to Forth is a result of a desire
for algebraic manipulation of program text (Forth's (somewhat) having this
property may have been a conscious design decision, but I'd bet cold, hard
cash that it was a happy accident).

Indeed, any of these stack-oriented concatenative languages are
computationally equivalent to a transformation monoid (algebra of functions
and function composition) where evaluation proceeds according to a (possibly
effectful) term-rewriting relation. Viewed in this light, the stack
effectively becomes a mere implementation detail as far as the semantics are
concerned, but I think that any language designer starting with such a
monoid+rewriting semantics, when facing reasonable implementation on real
hardware, is likely to come up with something quite similar to Forth &c. That
is to say, starting with a low-level focus on efficient and portable
implementation, or starting with a high-level focus on code representation as
algebraic terms, there's a good chance you'll wind up with something similar
to an established concatenative language, whether you mean to or not.

\---

[1]: "PostScript and Interpress: a comparison", Brian Reid: [http://tech-
insider.org/unix/research/1985/0301.html](http://tech-
insider.org/unix/research/1985/0301.html)

[2]: _Masterminds of Programming_ , Federico Biancuzzi & Shane Warden (eds.)

------
lallysingh
They're trolling o'caml, aren't they? This is wonderful.

~~~
FractalLP
No, I think OForth has been out for a long time. Probably not before OCaml, or
even close, but still not a trolling thing. Both just use "O" to symbolize
some Object stuff.

