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.
[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) or even perl as a better boot language.
Froth has no special boot sauce in my opinion. It was just small.
This is, I guess, the uncomfortable secret about Forth :-). There's the community of Forth enthusiasts, who admire its simple, word-oriented concept, and the ease of implementation, and are super happy that you can put a working interpreter in 8K of flash and use it interactively (ok, I'm happy about that, too).
And then there's everyone who has to write Forth code but is not a Forth enthusiast, and truth is we kindda hate it.
I pained myself through writing something non-trivial in Forth and it was pretty awful. I kept hoping the enlightenment would finally hit me and whatnot but it didn't, and I haven't touched it ever since.
I got interested in Forth because of an article I read in either Byte magazine or Dr Dobb’s Journal. It was not because of the Forth language that I was curious , it was because Forth was the first TIL (threaded interpreted language) that I had encountered.
At the time, there were no Forth interpreters available locally for the only computer I had (a TRS-80 Model II running CP/M. Actually, it was my Dad’s.)
I found someone from the Forth Interest Group (FIG) who gave me a 90-page Z-80 assembly language listing for figForth, which I proceeded to type in overnight and assemble with masm, IIRC.
It worked, and sadly, I never really did much with Forth after that. But it was an interesting experience and I still think TILs are a cool idea.
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.
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.
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.
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.
The -> syntax plays nicely with the stack nature of the language. It's basically just a word that pops TOS, and as a special effect it introduces a name with that value. (IIUIC, I didn't study the language.)
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...
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.
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!
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.
[+] [-] luckydude|8 years ago|reply
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|8 years ago|reply
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) or even perl as a better boot language.
Froth has no special boot sauce in my opinion. It was just small.
[+] [-] alxlaz|8 years ago|reply
And then there's everyone who has to write Forth code but is not a Forth enthusiast, and truth is we kindda hate it.
I pained myself through writing something non-trivial in Forth and it was pretty awful. I kept hoping the enlightenment would finally hit me and whatnot but it didn't, and I haven't touched it ever since.
[+] [-] defined|8 years ago|reply
At the time, there were no Forth interpreters available locally for the only computer I had (a TRS-80 Model II running CP/M. Actually, it was my Dad’s.)
I found someone from the Forth Interest Group (FIG) who gave me a 90-page Z-80 assembly language listing for figForth, which I proceeded to type in overnight and assemble with masm, IIRC.
It worked, and sadly, I never really did much with Forth after that. But it was an interesting experience and I still think TILs are a cool idea.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] lolc|8 years ago|reply
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|8 years ago|reply
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.
[+] [-] lolc|8 years ago|reply
Edit: And with .show it even shows the stack after each evaluation. This could replace bc for me if it was packaged in Debian.
[+] [-] yiyus|8 years ago|reply
[+] [-] tom_mellior|8 years ago|reply
That is, instead of:
you write: Why?It also has named variables (which some Forth purists don't like), but instead of the reasonable Smalltalk syntax of
it uses 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|8 years ago|reply
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.
[+] [-] eequah9L|8 years ago|reply
[+] [-] blunte|8 years ago|reply
[+] [-] HelloNurse|8 years ago|reply
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|8 years ago|reply
[+] [-] metaobject|8 years ago|reply
https://news.ycombinator.com/item?id=1623697
[+] [-] DonHopkins|8 years ago|reply
[+] [-] protomyth|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] sifoo|8 years ago|reply
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
[+] [-] cy_hauser|8 years ago|reply
[+] [-] lallysingh|8 years ago|reply
[+] [-] FractalLP|8 years ago|reply