Forth: The Hacker’s Language (2017)(hackaday.com)
hackaday.com
Forth: The Hacker’s Language (2017)
https://hackaday.com/2017/01/27/forth-the-hackers-language/
47 comments
This PDF was generated by a neural network attempting to maximize the amount something can be from the 80's.
I will forever be reminded of this:
http://vignette2.wikia.nocookie.net/technicpack/images/9/96/...
http://vignette2.wikia.nocookie.net/technicpack/images/9/96/...
Is that a Minecraft PDP-8?
It'll be a redpower computer, programmed in forth:
https://technicpack.fandom.com/wiki/Basic_Forth_Programming
ComputerCraft (programmed in lua usually) is more common these days.
https://technicpack.fandom.com/wiki/Basic_Forth_Programming
ComputerCraft (programmed in lua usually) is more common these days.
Computercraft or that newer one, openComputers, which has the memory blocks and such similar to redpower2.
That cover, it speaks to my heart. I want to be a disciple of FORTH.
Nice little PDF.
The first paid programming contract I got, back in the late 70s, was writing a records management system for a water company .. we wrote the Forth interpreter too, for a 6502 CPU, to get low-level access to hardware such as water level sensors. A major obstacle was getting British Telecoms' permission to send data over the POTS line, but it all worked well for years. I love Forth.
I really wish there was a modern book on implementing a useful Forth for x86 or Raspberry PI out of C. Not just a pamphlet either, but a thick book covering how to choose between all the different threading options...etc.
I don't know about "modern", but you could go the traditional route and bootstrap it from Assembler (You'll find that you only have to implement a tiny number of primitives until you can start implementing the rest in Forth itself).
Chapter 9 of Leo Brodie's "Starting Forth" is the text that kicked off my implementation in the early 80s (and undoubtedly countless others): https://www.forth.com/starting-forth/9-forth-execution/
Chapter 9 of Leo Brodie's "Starting Forth" is the text that kicked off my implementation in the early 80s (and undoubtedly countless others): https://www.forth.com/starting-forth/9-forth-execution/
Does Brodie's book cover implementation though? I can code in Forth a bit already, but want to know more about implementing in a low level language.
> want to know more about implementing in a low level language.
You might check out Jonesforth [0], which is an extensively-documented Forth implemented in x86 assembly language. If you read the single source file top to bottom, you'll get a good understanding of how it is implemented. There are also ports to x86-64, ARM, and other machines.
If you're looking for something in C, you might check out Ficl. [1]
[0] https://github.com/nornagon/jonesforth/blob/master/jonesfort... [1] http://ficl.sourceforge.net
You might check out Jonesforth [0], which is an extensively-documented Forth implemented in x86 assembly language. If you read the single source file top to bottom, you'll get a good understanding of how it is implemented. There are also ports to x86-64, ARM, and other machines.
If you're looking for something in C, you might check out Ficl. [1]
[0] https://github.com/nornagon/jonesforth/blob/master/jonesfort... [1] http://ficl.sourceforge.net
I always forget about Jonesforth. Glad to see it's on GitHub now!
> Glad to see it's on GitHub now!
Ah, that github link is not the official repository. The following link appears to be the official repo:
http://git.annexia.org/?p=jonesforth.git
Ah, that github link is not the official repository. The following link appears to be the official repo:
http://git.annexia.org/?p=jonesforth.git
This particular chapter talks about implementation. It probably gets you 80%-90% to an understanding of what you need to do, and the rest should be learnable by examining other implementations, now that you know what to look for.
Must read: "Thinking Forth: A Language and Philosophy for Solving Problems" by Leo Brodie (https://www.dnd.utwente.nl/~tim/colorforth/Leo-Brodie/thinki...)
Most of the principles described in the book can be applied to any programming languages, but the book itself uses Forth. Give it a try!
If you want to learn Forth, this might be the book you need: https://www.forth.com/starting-forth/ (https://1scyem2bunjw1ghzsf1cjwwn-wpengine.netdna-ssl.com/wp-...)
Old HN discussion: https://news.ycombinator.com/item?id=13505285
---
I would also recommend checking out Factor (http://factorcode.org/, created by Slava Pestov).
More details on the programming language:
- https://concatenative.org/wiki/view/Factor
- https://concatenative.org/wiki/view/Factor/FAQ/Why%3F
- https://concatenative.org/wiki/view/Factor/Learning
Old HN discussion: https://news.ycombinator.com/item?id=9008472
---
Happy hacking!
Most of the principles described in the book can be applied to any programming languages, but the book itself uses Forth. Give it a try!
If you want to learn Forth, this might be the book you need: https://www.forth.com/starting-forth/ (https://1scyem2bunjw1ghzsf1cjwwn-wpengine.netdna-ssl.com/wp-...)
Old HN discussion: https://news.ycombinator.com/item?id=13505285
---
I would also recommend checking out Factor (http://factorcode.org/, created by Slava Pestov).
More details on the programming language:
- https://concatenative.org/wiki/view/Factor
- https://concatenative.org/wiki/view/Factor/FAQ/Why%3F
- https://concatenative.org/wiki/view/Factor/Learning
Old HN discussion: https://news.ycombinator.com/item?id=9008472
---
Happy hacking!
I recall Real3D, a DCC app originating from the Amiga and ported to Windows NT in the 90's.
It allowed plug-ins to be written in RPL (Real Programming Language) a Forth dialect.
I wrote a 5k line RenderMan RIB exporter for this app in RPL.
I remember how hard this seemed when I started but how natural working in a RPN language felt after only a few hours. It was almost as if the stack had become an extension of my brain.
Trivia: Real3D was eventually rewritten from scratch and is now called Realsoft 3D. Afaik it doesn't support RPL/Forth any more.
I wrote a 5k line RenderMan RIB exporter for this app in RPL.
I remember how hard this seemed when I started but how natural working in a RPN language felt after only a few hours. It was almost as if the stack had become an extension of my brain.
Trivia: Real3D was eventually rewritten from scratch and is now called Realsoft 3D. Afaik it doesn't support RPL/Forth any more.
That was my first ever 3D app. And Imagine. Before moving to lightwave, still on the Amiga a couple of years later.
Don't miss "Thinking FORTH" (PDF) linked from the caption of a drawing: https://www.forth.com/forth-books/
> redefine 2 as a function that will return seven, and forever after your math won’t work. (But why would you?)
I often think of myself in the past as a completely different person who seems to be capable of many surprising actions.
I often think of myself in the past as a completely different person who seems to be capable of many surprising actions.
Actually it is not uncommon to see 0, 1 and -1 defined as built-in primitives. The benefit is that in some interpretation schemes (bytecode, DTC) it is either faster or smaller, sometimes both. It also allows to ' 0 ("tick" zero, that is get the address of the next word, which in this case is some primitive zero) to pass it as a "function pointer" to another function/definition/word.
I just downloaded 4tH with macports, anyone have experience or tips with that? Seems very cool.
"4tH is a very small Forth compiler that can create bytecode, C-embeddable bytecode, standalone executables, but also works fine as a scripting language. It supports over 85% of the ANS Forth CORE wordset and features conditional compilation, pipes, files, assertions, forward declarations, recursion, include files, etc."
Home page: https://thebeez.home.xs4all.nl/4tH/
Also..anyone tried or programmed in colorForth? Sounds extremely colourful!
"colorForth uses different colors in its source code (replacing some of the punctuation in standard Forth) to determine how different words are treated."
https://en.wikipedia.org/wiki/ColorForth
"4tH is a very small Forth compiler that can create bytecode, C-embeddable bytecode, standalone executables, but also works fine as a scripting language. It supports over 85% of the ANS Forth CORE wordset and features conditional compilation, pipes, files, assertions, forward declarations, recursion, include files, etc."
Home page: https://thebeez.home.xs4all.nl/4tH/
Also..anyone tried or programmed in colorForth? Sounds extremely colourful!
"colorForth uses different colors in its source code (replacing some of the punctuation in standard Forth) to determine how different words are treated."
https://en.wikipedia.org/wiki/ColorForth
A bit of a shameless plug - I did a short course for programmers at my company whose purpose was to introduce people to programming paradigms by constructing a language semantics first in JS. The language is forth-like for simplicity and I called it "slang".
https://github.com/srikumarks/nospoon
Would like to hear if anyone thinks it is worth continuing to elaborate on.
https://github.com/srikumarks/nospoon
Would like to hear if anyone thinks it is worth continuing to elaborate on.
Oddly enough I discovered Forth when I was developing a game a few years ago.
The idea for the game was that you pilot a space ship, but your only interface was a C64-like clone. You'd have to write programs to navigate, make jumps, and explore the galaxy. Connect to space stations using a modem, and dial into their local BBS for buying and selling goods.
So I built a 6502 emulator and emulated hardware for all the subsystems (display, disk, engines, modem, etc). It really was a legit emulated system ... just that some of the addressable hardware was a space ship :P
I started out using a modified KERNAL ROM with BASIC, but ran into problems. In the first iterations of the game all the subsystems were a bit too realistic. For sensors you'd have to manually move the sensor beam around and read out results constantly. For the engines you have to manually adjust the engine thrust and read back velocity information. Same with the jump mechanic.
I figured making the subsystems realistic, as if they were real hardware that you had to write firmware for, would be interesting. But coding the "firmware" in BASIC was a nightmare, and so slow. The jump subsystem was especially problematic, because the velocity was so high. The program would point your ship at a space station in the local system, engage jump drives, and then constantly monitor distance to the station and try to disengage once you got close enough. But because of the high speeds and the need for large integers to represent the distances, the program just couldn't PEEK and react fast enough. I could never get it accurate enough to drop out of jump close to the station. So you'd spend 10 minutes crawling over there with your sub-lightspeed drives the jump.
And on top of those speed issues, BASIC was too much of a PITA when you had to do a lot of hardware manipulation and processing of large numbers (like the vast distances of space...).
So after hacking on that for awhile I looked for a better alternative. That's when I stumbled into Forth. There's an actively developed Forth for C64 (https://github.com/jkotlinski/durexforth) which even included a Vi implementation. So I could get a nicer, faster language and an editor in one package!
A bit of hacking later, and it really was a massive improvement. It was especially nice having VI.
I ended up ditching a lot of the hardcore realism in the subsystems. Even with DurexForth, which was significantly faster and handled the math better, it was still problematic coding what should be fundamental programs in this game. And it certainly wasn't fun (if a game like this could ever be considered fun).
But the journey gave me a lot of exposure to Forth, and it is such an interesting language. I definitely recommend playing with Forth, at least for a weekend, just for fun and to expand your mind a little.
P.S. As for the game, it's collecting dust. One of these days I'd like to dust it off and get back to it; I find the idea of it terribly seductive. It's like a new genre: 6502-Punk :P But I'm half tempted to drop back to BASIC, since Forth is such a foreign experience. I'd probably continue simplifying the subsystems, add a floating point co-processor, and mod BASIC to use large hardware backed floats, just to make everything easy.
The idea for the game was that you pilot a space ship, but your only interface was a C64-like clone. You'd have to write programs to navigate, make jumps, and explore the galaxy. Connect to space stations using a modem, and dial into their local BBS for buying and selling goods.
So I built a 6502 emulator and emulated hardware for all the subsystems (display, disk, engines, modem, etc). It really was a legit emulated system ... just that some of the addressable hardware was a space ship :P
I started out using a modified KERNAL ROM with BASIC, but ran into problems. In the first iterations of the game all the subsystems were a bit too realistic. For sensors you'd have to manually move the sensor beam around and read out results constantly. For the engines you have to manually adjust the engine thrust and read back velocity information. Same with the jump mechanic.
I figured making the subsystems realistic, as if they were real hardware that you had to write firmware for, would be interesting. But coding the "firmware" in BASIC was a nightmare, and so slow. The jump subsystem was especially problematic, because the velocity was so high. The program would point your ship at a space station in the local system, engage jump drives, and then constantly monitor distance to the station and try to disengage once you got close enough. But because of the high speeds and the need for large integers to represent the distances, the program just couldn't PEEK and react fast enough. I could never get it accurate enough to drop out of jump close to the station. So you'd spend 10 minutes crawling over there with your sub-lightspeed drives the jump.
And on top of those speed issues, BASIC was too much of a PITA when you had to do a lot of hardware manipulation and processing of large numbers (like the vast distances of space...).
So after hacking on that for awhile I looked for a better alternative. That's when I stumbled into Forth. There's an actively developed Forth for C64 (https://github.com/jkotlinski/durexforth) which even included a Vi implementation. So I could get a nicer, faster language and an editor in one package!
A bit of hacking later, and it really was a massive improvement. It was especially nice having VI.
I ended up ditching a lot of the hardcore realism in the subsystems. Even with DurexForth, which was significantly faster and handled the math better, it was still problematic coding what should be fundamental programs in this game. And it certainly wasn't fun (if a game like this could ever be considered fun).
But the journey gave me a lot of exposure to Forth, and it is such an interesting language. I definitely recommend playing with Forth, at least for a weekend, just for fun and to expand your mind a little.
P.S. As for the game, it's collecting dust. One of these days I'd like to dust it off and get back to it; I find the idea of it terribly seductive. It's like a new genre: 6502-Punk :P But I'm half tempted to drop back to BASIC, since Forth is such a foreign experience. I'd probably continue simplifying the subsystems, add a floating point co-processor, and mod BASIC to use large hardware backed floats, just to make everything easy.
Doesn’t Forth suffer from the Lisp curse ?
Yes. I like the language because it is so simple to implement; when I want to do live discovery on something new (hardware or software), I load up a forth and start playing. If fits everywhere and it is easy to discover stuff without having to jump through hoops.
Yes and No. Yes in that it is still relatively obscure. I mean there have been plenty of cool Forth systems built, but I'd wager more Python gets built daily than the entirety of Forth code. Does that really matter though? Not really. It isn't a single language or even a family of languages like Lisp (Common Lisp, Racket, Clojure... etc). Rather, Forth is an idea and loose federation of philosophy concerning how to best tie primitives [written in something like Assembly or C (you want a low level language for speed and simplicity), but F#, Common Lisp, Clojure, Python...etc have all been used to write Forths] to code actually written in Forth. There is no traditional compiler and usually not too many data structures outside of the stack which is used for everything. Forth goes for extreme simplicity. There are some commercial vendors and products (SwiftForth, VFXForth, 8th), but the philosophy of Charles Moore was to just write what you need for the project. It was never really meant to be Java.
there is also a powerful implementation for nodejs https://www.npmjs.com/package/force-lang
Why is it a "powerful" implementation instead of just an implementation?
> It is called Force because of its assonance of Forth and since the Force is the main power of the Jedi the files have .j (or .jedi) extension. So Force is the Jedi programmers language !
Oh.
> It is called Force because of its assonance of Forth and since the Force is the main power of the Jedi the files have .j (or .jedi) extension. So Force is the Jedi programmers language !
Oh.
[deleted]
I don't get it. Who's using this, and for what?
I don't use forth personally, but it is at a very interesting corner of the envelope.
I find it both easier to implement than C and easier to develop in than C, while being nearly as fast as C, and often lower footprint than C. It's a really good language for "I really don't want to write in assembly, but there are no decent HLLs already implemented for my target"
I find it both easier to implement than C and easier to develop in than C, while being nearly as fast as C, and often lower footprint than C. It's a really good language for "I really don't want to write in assembly, but there are no decent HLLs already implemented for my target"
Forth in general is mainly used in situations where one is in close contact with the hardware (Assembly and C are the usual competitors).
It basically lets you string together a bunch of primitives and user defined functions using a stack. It is probably the only system that is useful where a single person can understand the entire language and implementation. You have to build everything yourself though.
It basically lets you string together a bunch of primitives and user defined functions using a stack. It is probably the only system that is useful where a single person can understand the entire language and implementation. You have to build everything yourself though.
It's a good option for embedded, especially low resource embedded, applications. Provides a nicer set of abstractions than assembler and let's you create basically a tuned DSL for your problem. That said, development doesn't scale particularly well, multi-member dev teams are hard, and maintenance of someone else's code can be, shall we say, challenging.
I always wondered how Sun and Apple addressed this, as they used forth in the form of OpenBootPROM as a boot environment on various platforms. Very, very nice.
I always wondered how Sun and Apple addressed this, as they used forth in the form of OpenBootPROM as a boot environment on various platforms. Very, very nice.
I always wondered how they scaled their firmware teams myself. Really impressive stuff though:
https://www.openfirmware.org/Open_Firmware
https://www.openfirmware.org/Forth/FCode
https://www.openfirmware.org/Open_Firmware
https://www.openfirmware.org/Forth/FCode
Another interesting example for those looking for a Forth rabbit hole is the Cannon Cat (http://www.canoncat.org/) from Jef Raskin's (of Mac fame) team.
On the (much) lower end was the Jupiter Ace (https://jupiter-ace.com/jupiterace/). The Ace is a fun what-might-have-been where Forth beat BASIC for the '80s PC soul. There were commercial Forths for other PCs of the time (Apple II, Atari 800, TI99), but I guess because they were extra cost, they didn't become that popular.
On the (much) lower end was the Jupiter Ace (https://jupiter-ace.com/jupiterace/). The Ace is a fun what-might-have-been where Forth beat BASIC for the '80s PC soul. There were commercial Forths for other PCs of the time (Apple II, Atari 800, TI99), but I guess because they were extra cost, they didn't become that popular.
PostScript, which was once widely used, had a lot of Forth-like concepts in it and was stack based.
PostScript, which was once widely used
in academia. Not outside.
In fact, I don’t think I’ve ever seen a .ps file that wasn’t hosted on a .edu domain (or other countries’ equivalents.)
in academia. Not outside.
In fact, I don’t think I’ve ever seen a .ps file that wasn’t hosted on a .edu domain (or other countries’ equivalents.)
>> PostScript, which was once widely used
> in academia. Not outside.
NeXTSTEP utilized "Display PostScript"[0] for both printing and display. Apple's Cocoa can trace direct ancestry to frameworks originating in NeXTSTEP[1]. I am pretty sure this included use of PostScript in the display/printing frameworks as well, but do not have references to support that memory.
So, while '.ps' files are not often seen in the wild, as you say, a strong case can be made that PostScript was once (if not currently) widely used.
0 - https://www.oreilly.com/library/view/learning-cocoa-with/059...
1 - https://arstechnica.com/gadgets/2012/12/the-legacy-of-next-l...
> in academia. Not outside.
NeXTSTEP utilized "Display PostScript"[0] for both printing and display. Apple's Cocoa can trace direct ancestry to frameworks originating in NeXTSTEP[1]. I am pretty sure this included use of PostScript in the display/printing frameworks as well, but do not have references to support that memory.
So, while '.ps' files are not often seen in the wild, as you say, a strong case can be made that PostScript was once (if not currently) widely used.
0 - https://www.oreilly.com/library/view/learning-cocoa-with/059...
1 - https://arstechnica.com/gadgets/2012/12/the-legacy-of-next-l...
NeXTSTEP
I would argue that’s not widely used.
Apple's Cocoa can trace direct ancestry to frameworks originating in NeXTSTEP
Not sure ancestry counts.
printing
Ah, fair point, thanks. I had forgotten about that.
My original claim is incorrect.
I would argue that’s not widely used.
Apple's Cocoa can trace direct ancestry to frameworks originating in NeXTSTEP
Not sure ancestry counts.
printing
Ah, fair point, thanks. I had forgotten about that.
My original claim is incorrect.
That's kind of like saying MIDI was never widely used because you only ever saw MIDI files used to play tinny soundcard music on someone's GeoShitties site back in the day. MIDI is much more a control protocol than a file format, and it was and is used as such throughout professional music production.
Similarly, PostScript was the control language for high-end printers back in the day, so it was used extensively as the final output format for print, even if it was rarely saved off as a .ps file.
Similarly, PostScript was the control language for high-end printers back in the day, so it was used extensively as the final output format for print, even if it was rarely saved off as a .ps file.
A substantial minority (if not majority) of standard (i.e. not special-purpose) printers speak PostScript, and PDFs are a subset of it. Not sure how much more "widely used" you expect it to be :)
Hosting public PS files may be an academic thing. But commercial use wasn't rare. I did PostScript programming for Xerox Research briefly in the late 1980s.
I needed to do batches of mathematical and optical analysis of novel materials synthesized in their labs. This demanded conditional logic, statistical analysis, layout, rasterizing, and archival of results. A single PostScript file did all of the above, with handwritten and template-generated code that ran on the output device, typically a printer. Weird choice of language, maybe; I was a lone computing nerd in a lab of mad chemists. But for rapid prototyping and always having presentable results as the analysis evolved, PostScript ended up being really easy to use.
Looking back 30 years now, I think it was also impressive that it was device independent, readable and commented code, with numeric data embedded like a heredoc. I haven't seen those docs or PostScript code for decades but it wouldn't surprise me if they ran on a PostScript device or viewer today.
Anyways, commercial use of PostScript happened, if mostly internally. At that workplace it was a known and reasonable document format to distribute.
I needed to do batches of mathematical and optical analysis of novel materials synthesized in their labs. This demanded conditional logic, statistical analysis, layout, rasterizing, and archival of results. A single PostScript file did all of the above, with handwritten and template-generated code that ran on the output device, typically a printer. Weird choice of language, maybe; I was a lone computing nerd in a lab of mad chemists. But for rapid prototyping and always having presentable results as the analysis evolved, PostScript ended up being really easy to use.
Looking back 30 years now, I think it was also impressive that it was device independent, readable and commented code, with numeric data embedded like a heredoc. I haven't seen those docs or PostScript code for decades but it wouldn't surprise me if they ran on a PostScript device or viewer today.
Anyways, commercial use of PostScript happened, if mostly internally. At that workplace it was a known and reasonable document format to distribute.
Just one example from the post is microcontrollers. There's an implementation for Arduino.
> The hacker's language
No, that would be C. (In both senses of the word 'hacker'.)
No, that would be C. (In both senses of the word 'hacker'.)
http://www.atarimania.com/documents/FORTH-on-the-Atari-Learn...