I'll always vote up submissions referencing anything FORTH related. For me FORTH is as much fun as lisp appears to be for others. I've never really done much with it, but I always like the simplicity and the ability to reason about it.
Sure FORTH has problems of its own, but it's always nice to use. I've hacked up a couple of simple FORTH-like systems over the years, most recently this one which was inspired by a thread on this site:
A lot of people go through guides of writing a lisp, I'd love to urge people to try writing a simple FORTH interpreter instead, or even something somewhat related such as TCL.
> A lot of people go through guides of writing a lisp, I'd love to urge people to try writing a simple Forth interpreter instead, or even something somewhat related such as TCL.
See, that's the problem. Writing a Forth interpreter, to be blunt, is not writing in Forth. You should be writing applications in Forth, not interpreters. It's great to marvel at the simplicity of a Forth interpreter, until you have to use it in anger for an actual application.
I've made several semi-serious "hobby" stabs at working with Forth, and, for me, it's a tough row to hoe. I look at something like F83 and marvel that someone was able to pull that off in that environment. I simply don't think I've used it enough and cross the line where I'm not constantly fighting...something to get anything done and thus my projects (or my patience) get derailed and I move on to something else. I've never gained any real momentum. F83 is actually quite robust (given it platform), and while gForth and such are better, it's not THAT much better. The core language is the same, though there are some more utilities.
My Pooh brain may simply not be able to cope with it properly. Could just be me. But a lot of Forth practitioners are kind of tired of all the "Look I have my own Forth" posts, vs actual working code doing something interesting besides Yet Another NEXT.
The Forth "enthusiast" community reminds me of the Pharo community. A community focused on writing Pharo to write Pharo, rather than applications on top of Pharo. They're constantly rewriting something (and making great strides!), but in the end you just get a great tool for making a great tool, and nobody (it seems) is making actual projects with it.
A lot of folks get a lot of "stuff" done using all sorts of languages and such, and showcase their wares, with the focus being on the application and the problem they solved. Forth focuses on Forths. And I know this is not universal, folks use it every day in industry and such, and there's even a couple nice videos showing "Forth in action", but much of the notoriety of Forth is the simplicity of the system, rather than the applications written on top of it.
> See, that's the problem. Writing a Forth interpreter, to be blunt, is not writing in Forth. You should be writing applications in Forth, not interpreters. It's great to marvel at the simplicity of a Forth interpreter, until you have to use it in anger for an actual application.
I get the impression Chuck Moore would argue "writing in Forth" means designing a custom language and custom hardware in tandem.
Forth is one of those systems that blurs the distinction between Application and Language. In truth you push your Application down in to "Forthisms" while uplifting Forth in to your "Applicationisms" and, eventually, like trains in the desert, they meet somewhere in the middle.
Same here. Inspired by Forth I made a single stack language that I could embed in the narative text for a text adventure game I made as a part of a mystery geocache.
The idea was that I would code the interpreter in Python because it's a nice language to get shit done in. Then I would port the code to php for easier hosting.
In the end, I never did the php part, I just hosted the python game code on a cheap vps.
Had I known I'd end up on that route I would probably just embedded inline python code, but getting my own custom language working was great fun.
Forth is like Lisp's dual. Postfix instead of prefix, no delimiters at all instead of parens out the wazoo, no memory management at all instead of GC, no type system at all instead of dynamic typing. But they both support similar dynamic, interactive, iterative programming styles.
Forth fans live in what seems to be a world of delusion. They rail against modern software, claiming to have an enlightened "system", and yet cannot communicate anything about the real capabilities of their system. If you ask most Forth users "what do you do in Forth?" the answer is almost always "writing a Forth". There seem to be very few people who are interested in using it for any other problem domain. I can't shake the feeling it is mainly hype.
Forth is a notorious "write-only language", it's hard to decipher what your code is doing after you've written it.
As someone that spent a couple of years dabbling in forth before moving on to Ruby, I became a lot more appreciative of the sheer readability of Ruby, and ruby-inspired languages like coffeescript & elixir.
However I still have a soft spot for the ethos of Chuck Moore. Abstractions are something that we should be wary of as programmers.
I tried it, and it felt more like a fantasy computer game, like TIS-100 or something, rather than a real language. It felt neither easy to write nor read, and I'm not sure what problem it solves with "software" in general that other languages don't. Ruby is a great language for sure, and actually it has some of the DSL capabilities of Forth
> it's hard to decipher what your code is doing after you've written it.
Not in my experience.
I even recycled "throw-away" scripts - thing that were written as "write-only" - a couple of times. I also continuously improve my dialect, so sometimes I break the utilities I've made for work. One of them has been working 24/7 for years (probably longer than your time playing with Forth), during which I have modified it to better fit my evolving needs more than a couple of times.
At least in the sector where I work, web stuff, Haskell is relatively usable. The same can't be said for Forth. Maybe it's the opposite in the hardware world?
It seems like modern languages adopt more and more ideas from functional programming as time goes by (garbage collection, closures and higher-order functions, parametric polymorphism, immutable values, algebraic types). Modern languages designed for general-purpose use are mostly hybrids, and the functional influence has been steadily growing over the decades.
It's hard to claim FORTH is "hype" while not being delusional about how few people actually have used it (and how high the percentage of very accomplished FORTH authors there are out of the whole of FORTH users). There is exceedingly little "hype" about FORTH, because the number of people who genuinely are aware of anything about it as simple as "FORTH is a postfix, stack-based language" is probably under 2000 worldwide, especially given most of its users happen to be dead now.
To extend the hype metaphor in your comment, FORTH is like the really good, really under-the-radar niche local artist that a bunch of critically-acclaimed, really hyped bands like.
There is a commercial forth called 8th that has a few thousand users and has support for ODBC, a few native databases, Bluetooth, can run on iOS, Android, Mac, Linux, Windows, has a GUI, can cross-compile to different systems, matrices, constraint solver, I/O for a lot of common formats...etc. It's a cool language that has the same abstraction as Python, but can go lower as well.
8th resembles Forth about as much as Javascript resembles C. There is a superficial similarity but 8th underneath is dynamically typed, garbage collected, etc, while Forth is close to assembler. That said, 8th is cool.
I think it's more than superficial. Word definitions are done the same and you concatevatively build up your DSL in the same manner. Nothing keeps any other Forth from having a GC, it's just that many are thin layers over the hardware and are used in applications where a GC is unnecessary.
In general, I kinda get what you're saying though in that JS and C share a syntax and are very different. However, 8th still is stack based and has all the hallmark Forth words like "dup", "rot", "pick"... etc that clearly mark it as part of that language family.
Sure, and JS has "for", "while", etc. The issue is the mindset during use, which is completely different between Forth and 8th. You could also look at Oforth, which is like 8th despite having Forth in its name, and which is free (oforth.com).
PostScript also has dup, rot and pick, though the last two are given different names, and it's stack-based. PostScript is a derivative of FORTH, but it isn't FORTH. While a FORTH can be object-oriented (more than a few have been), have any which way of memory management and so forth, it might be more generous to describe 8th as its own descendant thing to stop Moore from rolling in his... bed. He's still alive; we aren't saying grave yet.
8th does sort of get rid of the ethos of FORTH, which is a pretty important part of a language.
I would totally agree it runs somewhat counter to Moore's ideas of insanely low fat computing, but Moore isn't the sole viewpoint on Forth (big as he is and with being the creator and a freaking genius). How big are other Forth's like GForth? It's still a Forth right? I just think you're being over specific, but to each their own.
Gforth is a fairly large Forth but it is still a Forth in the sense that cells can hold untyped machine addresses, etc. You can write realtime applications in Forth (deterministic execution paths, no gc delays etc), it has its own weird metaprogramming model, etc. I don't think 8th is anything like that. I haven't used 8th though.
It's pretty under the radar. Your perception is probably being influenced by your online forum of choice. HN has around a dozen members who frequently post FORTH-related content, and a moderator that has sympathy for the language and frequently offers second-chances to posts about it.
I can definitely think of underground bands more popular than it and significantly more well known than it despite still being absolutely under the radar, because it only has, upper bound, ten thousand people who actually program in it. That's basically a single college radio station play's worth.
HN is absolutely not the most popular tech forum in the world (most stories struggle to get half a thousand votes, and the actual rate of access for HN is so low that dang is alarmed when he sees more than sixty logged-in queries a second[0]), and reddit just reposts what's on HN.
You're conflating "I read this" with "The world reads this." This is a common error. The trick is to realize that your experience with the internet is not universal, and that it is unlikely you are the average user in any group you're in.
Further, it doesn't even show up on the subreddit you mention very often; I just checked the reddit BigQuery database and FORTH posts don't collect a portion of upvotes worth mentioning in any given year.
Also: Using superfluous question marks for emphasis is a reddit habit. It should not be done on HN, because it is annoying and lowers the quality of discussion; the guidelines forbid uppercase-emphasis for this reason, and this is more egregious.
No one here is hyping Forth, they're conversing about and in some cases expressing admiration for what is an amazing and fun little language. Some FORTH systems can fit into less than 10 kilobytes of memory.
FORTH was invented in 1968, and was first used outside of Moore's lab by 1970. I could only wish one of my works was still being trash-talked on HN 53 years from now! You can't pay for that kind of "hype".
> This use of color further reduces the syntax, or punctuation, needed. It also makes explicit how the computer will interpret each word.
As always when colorForth is mentionned, I'm personally colorblind so I'm glad stuff like that isn't more popular. The red takes me a long time to parse, especially if I don't know the part is supposed to be red. There is a value in plain text.
Charles Moore was once criticized for this and he pointed out you could just use font instead I think.
Keep in mind he generally builds these things for himself based off of his own needs. I can't remember if this is default for the GreenArrays chips though, so perhaps that doesn't hold in all situations.
> Charles Moore was once criticized for this and he pointed out you could just use font instead I think.
I think that would be terrible too but people seem to love their fancy fonts, italics and ligatures, at least in the JS world, like here https://miro.medium.com/max/1200/1*hE_nLB776KUDXPERE_3cXw.pn.... I honestly don't see the point and find it harder to read but to each their own.
> Keep in mind he generally builds these things for himself based off of his own needs. I can't remember if this is default for the GreenArrays chips though, so perhaps that doesn't hold in all situations.
This was more of a general comment about the idea.
Ah gotcha. I recalled someone getting upset about it being difficult for those reading code via braille (iirc) or maybe they weren't upset, but were just asking about it lol.
Oh no I'm not upset at all, in a way I find the idea very cool, adding a dimension to code with a visual indicator is a great idea. But as someone that would be badly affected by it, I'm glad it's not done.
Totally understandable. My father is color blind too (particularly red/green), so I totally get that. I just dumbly assumed the comment was because you were bent out of shape as 90% of the internet seems to be these days :). My apologies.
There's a twitch streamer(tsoding) doing a FORTH like language from first principles.
I've watched a couple of episodes and went started my own. I learned a bit of arm64 assembly, and now I have both an interpreter and a compiler to M1 binaries. Very fun experience.
One day I'll slap a F#/OCaml'esque syntax on top of it with typed functions, structs, interfaces and see if it works.
At their core(it seems to me), concatenative languages are about function (words) composition.
So, instead if having "words", I would make them functions, with typed arguments, and simple argument matching (no more dups and swaps). This would probably make the language less flexible, but will make it more readable.
Maybe I'm not using the proper FP function term. I don't mean functions as objects that you can store or pass around or higher order functions. Just take some arguments from stack, and return some values.
What I mean is that FORTH words seem to be functions taking stuff from stack and pushing stuff back. The composition is done by chaining them together.
This probably works fine with repl driven development(same as in lisp), you find out during development that your words cannot be composed. But as mentioned by others it may make the code hard to read, having to keep the state id the stack at all times in your head.
I was thinking just adding a light syntax, ex:
let add a b =
a b +
// optional type annotation
let square a =
a a *
let add-square =
add square
Maybe add some type inference, support for structs, match expressions. But at the core keep the low level FORTH nature, with an interpreter and compiler.
It remains to be seen if it's possible to reach a balance here. FP programmers may be disappointed this is not a proper FP language, while FORTH programers may say it's a syntax ridden abomination.
I would say with some tooling (editor support, test framework, god forbid package manager), it can be an interesting option for embedded development.
Nah fam, like I said, go nuts. Even if something exists, reimplementing it is great for the challenge/intellectual curiosity/fun factor. I learned Ada by reimplementing Unix utilities in it.
Silicon Valley programming wiz finds himself transported to a magical world. Spellcraft is archaic and stagnant. What's a curious hacker to do? Bootstrap a new magical 'programming' environment - using Forth, obviously!
54 comments
[ 4.3 ms ] story [ 27.1 ms ] threadSure FORTH has problems of its own, but it's always nice to use. I've hacked up a couple of simple FORTH-like systems over the years, most recently this one which was inspired by a thread on this site:
https://github.com/skx/foth
A lot of people go through guides of writing a lisp, I'd love to urge people to try writing a simple FORTH interpreter instead, or even something somewhat related such as TCL.
Once they're not interesting anymore, Lisp is the next step.
https://github.com/codr7/ampl
See, that's the problem. Writing a Forth interpreter, to be blunt, is not writing in Forth. You should be writing applications in Forth, not interpreters. It's great to marvel at the simplicity of a Forth interpreter, until you have to use it in anger for an actual application.
I've made several semi-serious "hobby" stabs at working with Forth, and, for me, it's a tough row to hoe. I look at something like F83 and marvel that someone was able to pull that off in that environment. I simply don't think I've used it enough and cross the line where I'm not constantly fighting...something to get anything done and thus my projects (or my patience) get derailed and I move on to something else. I've never gained any real momentum. F83 is actually quite robust (given it platform), and while gForth and such are better, it's not THAT much better. The core language is the same, though there are some more utilities.
My Pooh brain may simply not be able to cope with it properly. Could just be me. But a lot of Forth practitioners are kind of tired of all the "Look I have my own Forth" posts, vs actual working code doing something interesting besides Yet Another NEXT.
The Forth "enthusiast" community reminds me of the Pharo community. A community focused on writing Pharo to write Pharo, rather than applications on top of Pharo. They're constantly rewriting something (and making great strides!), but in the end you just get a great tool for making a great tool, and nobody (it seems) is making actual projects with it.
A lot of folks get a lot of "stuff" done using all sorts of languages and such, and showcase their wares, with the focus being on the application and the problem they solved. Forth focuses on Forths. And I know this is not universal, folks use it every day in industry and such, and there's even a couple nice videos showing "Forth in action", but much of the notoriety of Forth is the simplicity of the system, rather than the applications written on top of it.
I get the impression Chuck Moore would argue "writing in Forth" means designing a custom language and custom hardware in tandem.
Forth interpreters were traditionally written in Forth, and if you do it that way, that counts imho ;).
The idea was that I would code the interpreter in Python because it's a nice language to get shit done in. Then I would port the code to php for easier hosting.
In the end, I never did the php part, I just hosted the python game code on a cheap vps.
Had I known I'd end up on that route I would probably just embedded inline python code, but getting my own custom language working was great fun.
As someone that spent a couple of years dabbling in forth before moving on to Ruby, I became a lot more appreciative of the sheer readability of Ruby, and ruby-inspired languages like coffeescript & elixir.
However I still have a soft spot for the ethos of Chuck Moore. Abstractions are something that we should be wary of as programmers.
I feel lisp is very similar, an inverted sort of forth, I've never tried lisp but it seems to be a much easier language to work with than forth.
Not in my experience.
I even recycled "throw-away" scripts - thing that were written as "write-only" - a couple of times. I also continuously improve my dialect, so sometimes I break the utilities I've made for work. One of them has been working 24/7 for years (probably longer than your time playing with Forth), during which I have modified it to better fit my evolving needs more than a couple of times.
What influence has Forth had?
also I don't know if it's still the case but mac used openfirmware fcode/forth
- a vt100 terminal emulator
- a pacman clone
- a text editor
- a plotting utility for an HP plotter
- an interface for a Coulter counter
Probably other stuff I have forgotten now.
To extend the hype metaphor in your comment, FORTH is like the really good, really under-the-radar niche local artist that a bunch of critically-acclaimed, really hyped bands like.
8th resembles Forth about as much as Javascript resembles C. There is a superficial similarity but 8th underneath is dynamically typed, garbage collected, etc, while Forth is close to assembler. That said, 8th is cool.
In general, I kinda get what you're saying though in that JS and C share a syntax and are very different. However, 8th still is stack based and has all the hallmark Forth words like "dup", "rot", "pick"... etc that clearly mark it as part of that language family.
8th does sort of get rid of the ethos of FORTH, which is a pretty important part of a language.
I can definitely think of underground bands more popular than it and significantly more well known than it despite still being absolutely under the radar, because it only has, upper bound, ten thousand people who actually program in it. That's basically a single college radio station play's worth.
You're conflating "I read this" with "The world reads this." This is a common error. The trick is to realize that your experience with the internet is not universal, and that it is unlikely you are the average user in any group you're in.
Further, it doesn't even show up on the subreddit you mention very often; I just checked the reddit BigQuery database and FORTH posts don't collect a portion of upvotes worth mentioning in any given year.
Also: Using superfluous question marks for emphasis is a reddit habit. It should not be done on HN, because it is annoying and lowers the quality of discussion; the guidelines forbid uppercase-emphasis for this reason, and this is more egregious.
[0] https://news.ycombinator.com/item?id=26473226
FORTH was invented in 1968, and was first used outside of Moore's lab by 1970. I could only wish one of my works was still being trash-talked on HN 53 years from now! You can't pay for that kind of "hype".
As always when colorForth is mentionned, I'm personally colorblind so I'm glad stuff like that isn't more popular. The red takes me a long time to parse, especially if I don't know the part is supposed to be red. There is a value in plain text.
Keep in mind he generally builds these things for himself based off of his own needs. I can't remember if this is default for the GreenArrays chips though, so perhaps that doesn't hold in all situations.
I think that would be terrible too but people seem to love their fancy fonts, italics and ligatures, at least in the JS world, like here https://miro.medium.com/max/1200/1*hE_nLB776KUDXPERE_3cXw.pn.... I honestly don't see the point and find it harder to read but to each their own.
> Keep in mind he generally builds these things for himself based off of his own needs. I can't remember if this is default for the GreenArrays chips though, so perhaps that doesn't hold in all situations.
This was more of a general comment about the idea.
I wonder if simply choosing better colors depending on the type of color blindness would be a quick fix, starting with not using red and green.
I've watched a couple of episodes and went started my own. I learned a bit of arm64 assembly, and now I have both an interpreter and a compiler to M1 binaries. Very fun experience.
One day I'll slap a F#/OCaml'esque syntax on top of it with typed functions, structs, interfaces and see if it works.
At their core(it seems to me), concatenative languages are about function (words) composition.
So, instead if having "words", I would make them functions, with typed arguments, and simple argument matching (no more dups and swaps). This would probably make the language less flexible, but will make it more readable.
Anyway, FORTH is nice.
Interesting idea. Wouldn't it require some compiler magic, though? E.g. you can't type a Y combinator.
What I mean is that FORTH words seem to be functions taking stuff from stack and pushing stuff back. The composition is done by chaining them together.
This probably works fine with repl driven development(same as in lisp), you find out during development that your words cannot be composed. But as mentioned by others it may make the code hard to read, having to keep the state id the stack at all times in your head.
I was thinking just adding a light syntax, ex:
let add a b = a b +
// optional type annotation
let square a = a a *
let add-square = add square
Maybe add some type inference, support for structs, match expressions. But at the core keep the low level FORTH nature, with an interpreter and compiler.
It remains to be seen if it's possible to reach a balance here. FP programmers may be disappointed this is not a proper FP language, while FORTH programers may say it's a syntax ridden abomination.
I would say with some tooling (editor support, test framework, god forbid package manager), it can be an interesting option for embedded development.
Which is not a bad thing. Go nuts. Just realize that there may be some degree of prior art for what you're doing.
I was planning to investigate this space just for fun. Most likely nothing will come out if it and that's ok, it's just a learning opportunity.
Silicon Valley programming wiz finds himself transported to a magical world. Spellcraft is archaic and stagnant. What's a curious hacker to do? Bootstrap a new magical 'programming' environment - using Forth, obviously!
Great fun!
https://www.baen.com/the-wiz-biz.html