colorForth (2009)(colorforth.github.io)
colorforth.github.io
colorForth (2009)
https://colorforth.github.io/cf.htm
54 comments
> 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'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.
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.
Similar to what Paul Graham wrote about top down and bottom up programming (IIRC, in Lisp), in one of his essays.
> Writing a Forth interpreter, to be blunt, is not writing in Forth.
Forth interpreters were traditionally written in Forth, and if you do it that way, that counts imho ;).
Forth interpreters were traditionally written in Forth, and if you do it that way, that counts imho ;).
As I recollect, Chuck Moore seemed to be unable to write a usb driver in Colorforth.
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.
No parameter names instead of hyphenated parameter names.
Second that, starting with Forth allows getting to the interesting parts faster.
Once they're not interesting anymore, Lisp is the next step.
https://github.com/codr7/ampl
Once they're not interesting anymore, Lisp is the next step.
https://github.com/codr7/ampl
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.
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.
> 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.
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.
Each word has a 4-bit field correspond to its purpose so you could use some other method than color. https://colorforth.github.io/parsed.html
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 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.
That's true, if the editor supports importing your own color (like syntax highlighting often does) it's not a problem.
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.
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.
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.
No worries!
Well so it as a matter of fact was designed for people with poor vision.
The Wiz Biz, by Rick Cook
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
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
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.
Anyway, FORTH is nice.
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.
Sounds like you're in the process of reinventing Factor.
Which is not a bad thing. Go nuts. Just realize that there may be some degree of prior art for what you're doing.
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'm vaguely familiar with Factor and hopefully not in process of reinventing it.
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.
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.
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.
> So, instead if having "words", I would make them functions, with typed arguments
Interesting idea. Wouldn't it require some compiler magic, though? E.g. you can't type a Y combinator.
Interesting idea. Wouldn't it require some compiler magic, though? E.g. you can't type a Y combinator.
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.
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.
In many forths you can have what they call locals, so your example can be:
: add {: a b :} a b + ;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.
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.
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.
> There is a commercial forth called 8th
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.
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.
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.
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.
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.
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).
Is oforth still being developed?
Forth is not under the radar in any sense. It is much more popular and well known than any underground band.
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.
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.
If I see it frequently on HN (possibly the most popular tech forum in the world??) and also /r/programming, then it is NOT underground.
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.
[0] https://news.ycombinator.com/item?id=26473226
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
Some things I have written in 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.
- 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.
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.
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.
> 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.
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.
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
Yeah that's one of the most intriguing parts of Forth I thought, the everything-is-a-DSL, the metaprogramming, the language-is-a-bytecode-VM, etc.
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.
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.
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".
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".
The same is true for functional programming fans, except that Haskell is hyped a lot more than Forth ;)
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.
What influence has Forth had?
What influence has Forth had?
Haskell is very widely used though, that is not a reasonable comparison.
some bits about threaded bytecode and code size are very interesting though
also I don't know if it's still the case but mac used openfirmware fcode/forth
also I don't know if it's still the case but mac used openfirmware fcode/forth
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:
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.