4 ms·

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

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: https://github.com/skx/foth 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.

codr7 5y ago
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 https://github.com/codr7/ampl
whartung 5y ago
> 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.
- macintux 5y ago
  > 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.
  - whartung 5y ago
    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.
    - vram22 5y ago
      Similar to what Paul Graham wrote about top down and bottom up programming (IIRC, in Lisp), in one of his essays.
- throwaway81523 5y ago
  > 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 ;).
- wrycoder 5y ago
  As I recollect, Chuck Moore seemed to be unable to write a usb driver in Colorforth.
progre 5y ago
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.
bitwize 5y ago
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.
- wrycoder 5y ago
  No parameter names instead of hyphenated parameter names.

codr7 5y ago

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 https://github.com/codr7/ampl

whartung 5y ago

> 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.

macintux 5y ago
> 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.
- whartung 5y ago
  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.
  - vram22 5y ago
    Similar to what Paul Graham wrote about top down and bottom up programming (IIRC, in Lisp), in one of his essays.
throwaway81523 5y ago
> 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 ;).
wrycoder 5y ago
As I recollect, Chuck Moore seemed to be unable to write a usb driver in Colorforth.

progre 5y ago

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.

bitwize 5y ago

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.

wrycoder 5y ago
No parameter names instead of hyphenated parameter names.