6 ms·

So this is pretty interesting (especially as a Forth programmer), however was this ever open sourced, or even still available?

by rpcope1 10y ago

freehunter 10y ago
Question: I've looked at Forth a number of times and I think it's a fascinating looking language but I've never bothered picking it up. I've also never had a chance to talk to a Forth programmer. Can you tell me what type of application you're working on, if it's legacy or new development, and your thoughts on when to choose Forth over something else? From what I understand, Forth is mostly used as an embedded "OS" when a traditional OS wouldn't cut it. Is that accurate? Sorry, it's just not a terribly common language, but it certainly is interesting.
- lawpoop 10y ago
  FWIW this old school games programmer (think Atari IIRC) talks a lot about Forth: http://prog21.dadgum.com/33.html http://prog21.dadgum.com/33.html (a lot being relative, here meaning "some")
  - agumonkey 10y ago
    Also scientists (circa late 80s); http://soton.mpeforth.com/flag/jfar/vol5/no2/article1.pdf http://soton.mpeforth.com/flag/jfar/vol5/no2/article1.pdf Forth VS Fortran for "typed generic" linear algebra (same routine be it real, complex, ...) and proto OOP. Enjoy the read.
    - smaddox 10y ago
      Nice. I love the comparison of the simplex minimization implementations for FORTRAN and FORTH.
  - jamesgeck0 10y ago
    This article he linked recently is also worth a read. http://yosefk.com/blog/my-history-with-forth-stack-machines.html http://yosefk.com/blog/my-history-with-forth-stack-machines....
- pmoriarty 10y ago
  I tried to learn it, and found Forth to be an obfuscated, write-only language. Forth programmers give a lot of lip service to writing short, well documented, elegant words (functions) but in real-world programs I've seen the opposite: the tendency has been to long, poorly documented, and convoluted words. (At least that's been my experience with open-source Forth programs. I've heard the libraries for commercial Forths are of much higher quality, but I have not verified this myself) Forth has been compared favorably to Lisp, but I found them to be like night and day, and Lisp (and especially Scheme) to be far more elegant and easy to both read and write. Forth might arguably be better than assembly, but unless you have a pressing need to write the tiniest programs possible (like on some resource-starved microcontroller), I'd be hard pressed to find a reason why you'd want to use Forth instead of some higher level language that is far less painful to work with. In fact, I've even heard some Forth fans themselves say that the point of using Forth is to write yourself something as quickly as possible that lets you program in a higher level language. Don't get me wrong, I really, really wanted to like Forth and spent a lot of time trying to learn it, but in the end it felt like it just wasn't worth it. I might give it another go if I get heavily in to programming microcontrollers where Lisp or Scheme is not an option.
  - Someone 10y ago
    "Forth has been compared favorably to Lisp" In some contexts, that's true. Lisp needs insane amounts of RAM to get a decent REPL running (I can't find figures for the original 704 implementation (did it even have a REPL or was it compiled?), but I guess easily 20kB or more), while forth runs its REPL happily in a tenth of that space. If you are bootstrapping the firmware for a device, where bootstrapping means that you have to write the code interfacing with any of the hardware before you can use it, and you can find enough I/O pins to use for a serial port, a forth REPL is both easier to implement and way more useful than a lisp one. And if your device doesn't have much memory, it may be your only realistic option.
  - greghendershott 10y ago
    > In fact, I've even heard some Forth fans themselves say that the point of using Forth is to write yourself something as quickly as possible that lets you program in a higher level language. That was the main point for someone I know: Forth was how they'd bootstrap a new system to be useful in a few days. I don't think they do this anymore. This mattered more in say the 1980s when truly new personal computer hardware was coming on the market fairly frequently.
- rpcope1 10y ago
  I cut my teeth using Forth for writing automated tests for storage products (pretty legacy, I'm not sure if the company uses it any more), and got hooked on it afterwards. The test system was based on a custom real time OS, and Forth was a really good fit, but it would be really hard to find developers now that understood how to work with the system. I had also bought Threaded Interperative Languages (https://www.amazon.com/Threaded-Interpretive-Languages-Design-Implementation/dp/007038360X https://www.amazon.com/Threaded-Interpretive-Languages-Desig...) and chose to roll a Forth interpreter for an 8051 dev board I had laying around, which was pretty fun, and wasn't too difficult. It's mostly just a hobby now, as I don't think there's a lot of companies out there still using Forth. I think Forth is still useful for embedded systems, often even more so than C, especially given that it can go places that C can't. I would personally choose it for my own embedded projects, but the paradigm is sufficiently different that I would worry about finding other people who have the mental capability to write Forth that doesn't immediately devolve into something unmaintainable, or who even want to learn it in the first place. I still write little scripts with GForth sometimes too, but it's not nearly as productive as just writing some Perl or Python. If you're interested in playing with a slightly more modern concatenative language, Factor is a good choice.
- astrobe_ 10y ago
  I use it for scripting and as an embedded debugging language for other programs. For instance I wrote a logging program that collects log messages sent by various sources via UDP, displays them in colours on the console and records them in different log files. It is also a HTTP 1.1 server that I use to monitor a few key data about the logs from a browser on an other machine. The right way to use Forth nowadays is, in my humble opinion, as a template to build yourself your own interpreter that does exactly what you want (as long as you know how to do it ;-), because it has a very low barrier-of-entry implementation-wise. The "Forth is good for embedded stuff" pitch becomes less and less true every year, because embedded micro-controllers become more and more powerful. Other small languages like Lua are becoming "good enough" on these and are more "user-friendly". Extrapolating from myself I would say that those who stick with Forth are just liking it and/or like to have absolute control over their tools.
  - Someone 10y ago
    "It is also a HTTP 1.1 server" You may have mostly implemented one of the things on my list of "ridiculous things I would like to see": a forth-based web server that accepts code URLs. For example GET foo.com/2/3/+/. would return a text file containing the number '5', and GET foo.com/:/square/dup/*/; would define a new function (technically, that should be a PUT, but who cares, for a ridiculous idea?) Of course, this should follow the forth philosophy, so URLs like GET foo.com/forget/forget would work 'fine'. Connecting such a contraption to the internet might not be the brightest idea, but I think it can be made (more or less) safe by executing every request from within a highly restricted vocabulary. I would guess that's how you implemented your http request handling, but likely only for one-word URLs. If so, the rest is just a REPL that uses slashes as word separators, so it is easy to write.
    - yellowapple 10y ago
      FaaS: Forth as a Service. I love it.
- sedachv 10y ago
  Forth also makes a good scripting language for many applications due to being compact and very easy to implement. Warren Wilkinson used Forth for scripting in his Common Lisp-based web forms/reports/documentation app: http://lambda-the-ultimate.org/node/3999 http://lambda-the-ultimate.org/node/3999
- david-given 10y ago
  A while back I wrote a Forth interpreter and ended up posting a bit of a rant here about what I'd learnt from the experience, which I won't repeat; but after some more thought, I think Forth is best described as a kind of interactive super assembly language. Writing Forth requires the same level of attention to detail and obsession with minutiae that assembly does. There's no runtime safety whatsoever. There's no syntactical safety whatsoever. It will do exactly what you tell it, even if what you tell it makes no sense. (I found myself thinking of the interpreter as the worst kind of passive-agressive cow orker. "I just assumed you had a reason for writing that floating point number to the program counter! I'm not a mind reader, you know!" "But if you wanted that loop closed at the end of the word definition, why didn't you close it yourself?" "It's not my job to remember whether that word left a float or an int on the stack. Don't you know?") But this also gets coupled to the Forth programmer mindset, which is the ultimate YAGNI. Forth programmers don't just avoid abstraction, they consider it evil. I found a good example from Chuck Moore's website, where he compares the Linux IDE driver (thousands of lines of code) with an equivalent Forth one (two lines). ...except, of course, the Linux driver is a command scheduler to the VFS block layer. The Forth driver's just a couple of words which read and write bytes from an IDE channel. They are in no way equivalent, except that in Chuck Moore's eyes they are. The same philosphy permeates the entire language. Good Forth programmers appear to solve hard problems by ruthlessly stripping away everything irrelevant from the problem to end up with an easy one. So, a traditional Forth system has no file system; it's easier to just remember which disk blocks you put your data in. Code portability's unimportant --- each program runs in its own customised Forth environment; avoiding platform-specific features is a waste of time. (Most Forthers I've talked to hold the ANS Forth spec in active contempt.) There's very little reusable code because each Forth solution is so tightly tied to the problem it's solving to be useless for any other problem. Where it really excels is in an environment where you don't want any abstractions between you and the hardware --- it's brilliant on tiny, embedded devices. I don't know any other environment which can do so much in so little; being able to connect a serial terminal to a embedded processor with 2kB RAM and run commands on it is so, so useful. I'd strongly recommend learning at least the basics of it, even if you're never going to use it. There's that wonderful Aha! moment as your mind reconfigures itself.

So this is pretty interesting (especially as a Forth programmer), however was this ever open sourced, or even still available?

by rpcope1 10y ago

So this is pretty interesting (especially as a Forth programmer), however was this ever open sourced, or even still available?

freehunter 10y ago

Question: I've looked at Forth a number of times and I think it's a fascinating looking language but I've never bothered picking it up. I've also never had a chance to talk to a Forth programmer. Can you tell me what type of application you're working on, if it's legacy or new development, and your thoughts on when to choose Forth over something else? From what I understand, Forth is mostly used as an embedded "OS" when a traditional OS wouldn't cut it. Is that accurate? Sorry, it's just not a terribly common language, but it certainly is interesting.

lawpoop 10y ago
FWIW this old school games programmer (think Atari IIRC) talks a lot about Forth: http://prog21.dadgum.com/33.html http://prog21.dadgum.com/33.html (a lot being relative, here meaning "some")
- agumonkey 10y ago
  Also scientists (circa late 80s); http://soton.mpeforth.com/flag/jfar/vol5/no2/article1.pdf http://soton.mpeforth.com/flag/jfar/vol5/no2/article1.pdf Forth VS Fortran for "typed generic" linear algebra (same routine be it real, complex, ...) and proto OOP. Enjoy the read.
  - smaddox 10y ago
    Nice. I love the comparison of the simplex minimization implementations for FORTRAN and FORTH.
- jamesgeck0 10y ago
  This article he linked recently is also worth a read. http://yosefk.com/blog/my-history-with-forth-stack-machines.html http://yosefk.com/blog/my-history-with-forth-stack-machines....
pmoriarty 10y ago
I tried to learn it, and found Forth to be an obfuscated, write-only language. Forth programmers give a lot of lip service to writing short, well documented, elegant words (functions) but in real-world programs I've seen the opposite: the tendency has been to long, poorly documented, and convoluted words. (At least that's been my experience with open-source Forth programs. I've heard the libraries for commercial Forths are of much higher quality, but I have not verified this myself) Forth has been compared favorably to Lisp, but I found them to be like night and day, and Lisp (and especially Scheme) to be far more elegant and easy to both read and write. Forth might arguably be better than assembly, but unless you have a pressing need to write the tiniest programs possible (like on some resource-starved microcontroller), I'd be hard pressed to find a reason why you'd want to use Forth instead of some higher level language that is far less painful to work with. In fact, I've even heard some Forth fans themselves say that the point of using Forth is to write yourself something as quickly as possible that lets you program in a higher level language. Don't get me wrong, I really, really wanted to like Forth and spent a lot of time trying to learn it, but in the end it felt like it just wasn't worth it. I might give it another go if I get heavily in to programming microcontrollers where Lisp or Scheme is not an option.
- Someone 10y ago
  "Forth has been compared favorably to Lisp" In some contexts, that's true. Lisp needs insane amounts of RAM to get a decent REPL running (I can't find figures for the original 704 implementation (did it even have a REPL or was it compiled?), but I guess easily 20kB or more), while forth runs its REPL happily in a tenth of that space. If you are bootstrapping the firmware for a device, where bootstrapping means that you have to write the code interfacing with any of the hardware before you can use it, and you can find enough I/O pins to use for a serial port, a forth REPL is both easier to implement and way more useful than a lisp one. And if your device doesn't have much memory, it may be your only realistic option.
- greghendershott 10y ago
  > In fact, I've even heard some Forth fans themselves say that the point of using Forth is to write yourself something as quickly as possible that lets you program in a higher level language. That was the main point for someone I know: Forth was how they'd bootstrap a new system to be useful in a few days. I don't think they do this anymore. This mattered more in say the 1980s when truly new personal computer hardware was coming on the market fairly frequently.
rpcope1 10y ago
I cut my teeth using Forth for writing automated tests for storage products (pretty legacy, I'm not sure if the company uses it any more), and got hooked on it afterwards. The test system was based on a custom real time OS, and Forth was a really good fit, but it would be really hard to find developers now that understood how to work with the system. I had also bought Threaded Interperative Languages (https://www.amazon.com/Threaded-Interpretive-Languages-Design-Implementation/dp/007038360X https://www.amazon.com/Threaded-Interpretive-Languages-Desig...) and chose to roll a Forth interpreter for an 8051 dev board I had laying around, which was pretty fun, and wasn't too difficult. It's mostly just a hobby now, as I don't think there's a lot of companies out there still using Forth. I think Forth is still useful for embedded systems, often even more so than C, especially given that it can go places that C can't. I would personally choose it for my own embedded projects, but the paradigm is sufficiently different that I would worry about finding other people who have the mental capability to write Forth that doesn't immediately devolve into something unmaintainable, or who even want to learn it in the first place. I still write little scripts with GForth sometimes too, but it's not nearly as productive as just writing some Perl or Python. If you're interested in playing with a slightly more modern concatenative language, Factor is a good choice.
astrobe_ 10y ago
I use it for scripting and as an embedded debugging language for other programs. For instance I wrote a logging program that collects log messages sent by various sources via UDP, displays them in colours on the console and records them in different log files. It is also a HTTP 1.1 server that I use to monitor a few key data about the logs from a browser on an other machine. The right way to use Forth nowadays is, in my humble opinion, as a template to build yourself your own interpreter that does exactly what you want (as long as you know how to do it ;-), because it has a very low barrier-of-entry implementation-wise. The "Forth is good for embedded stuff" pitch becomes less and less true every year, because embedded micro-controllers become more and more powerful. Other small languages like Lua are becoming "good enough" on these and are more "user-friendly". Extrapolating from myself I would say that those who stick with Forth are just liking it and/or like to have absolute control over their tools.
- Someone 10y ago
  "It is also a HTTP 1.1 server" You may have mostly implemented one of the things on my list of "ridiculous things I would like to see": a forth-based web server that accepts code URLs. For example GET foo.com/2/3/+/. would return a text file containing the number '5', and GET foo.com/:/square/dup/*/; would define a new function (technically, that should be a PUT, but who cares, for a ridiculous idea?) Of course, this should follow the forth philosophy, so URLs like GET foo.com/forget/forget would work 'fine'. Connecting such a contraption to the internet might not be the brightest idea, but I think it can be made (more or less) safe by executing every request from within a highly restricted vocabulary. I would guess that's how you implemented your http request handling, but likely only for one-word URLs. If so, the rest is just a REPL that uses slashes as word separators, so it is easy to write.
  - yellowapple 10y ago
    FaaS: Forth as a Service. I love it.
sedachv 10y ago
Forth also makes a good scripting language for many applications due to being compact and very easy to implement. Warren Wilkinson used Forth for scripting in his Common Lisp-based web forms/reports/documentation app: http://lambda-the-ultimate.org/node/3999 http://lambda-the-ultimate.org/node/3999
david-given 10y ago
A while back I wrote a Forth interpreter and ended up posting a bit of a rant here about what I'd learnt from the experience, which I won't repeat; but after some more thought, I think Forth is best described as a kind of interactive super assembly language. Writing Forth requires the same level of attention to detail and obsession with minutiae that assembly does. There's no runtime safety whatsoever. There's no syntactical safety whatsoever. It will do exactly what you tell it, even if what you tell it makes no sense. (I found myself thinking of the interpreter as the worst kind of passive-agressive cow orker. "I just assumed you had a reason for writing that floating point number to the program counter! I'm not a mind reader, you know!" "But if you wanted that loop closed at the end of the word definition, why didn't you close it yourself?" "It's not my job to remember whether that word left a float or an int on the stack. Don't you know?") But this also gets coupled to the Forth programmer mindset, which is the ultimate YAGNI. Forth programmers don't just avoid abstraction, they consider it evil. I found a good example from Chuck Moore's website, where he compares the Linux IDE driver (thousands of lines of code) with an equivalent Forth one (two lines). ...except, of course, the Linux driver is a command scheduler to the VFS block layer. The Forth driver's just a couple of words which read and write bytes from an IDE channel. They are in no way equivalent, except that in Chuck Moore's eyes they are. The same philosphy permeates the entire language. Good Forth programmers appear to solve hard problems by ruthlessly stripping away everything irrelevant from the problem to end up with an easy one. So, a traditional Forth system has no file system; it's easier to just remember which disk blocks you put your data in. Code portability's unimportant --- each program runs in its own customised Forth environment; avoiding platform-specific features is a waste of time. (Most Forthers I've talked to hold the ANS Forth spec in active contempt.) There's very little reusable code because each Forth solution is so tightly tied to the problem it's solving to be useless for any other problem. Where it really excels is in an environment where you don't want any abstractions between you and the hardware --- it's brilliant on tiny, embedded devices. I don't know any other environment which can do so much in so little; being able to connect a serial terminal to a embedded processor with 2kB RAM and run commands on it is so, so useful. I'd strongly recommend learning at least the basics of it, even if you're never going to use it. There's that wonderful Aha! moment as your mind reconfigures itself.