4 ms·

I love Forth and used it extensively for many years. I wonder how much real use it is seeing today. I remember a situation many years ago where a friend of mi

I love Forth and used it extensively for many years. I wonder how much real use it is seeing today. I remember a situation many years ago where a friend of mine chose to code his embedded product in Forth. As the company grew it became difficult to find programmers. As things got to the point where acquisition started to become a possibility Forth became a liability. He had to convert the entire code base to C in order to remove objections. I pitched in and helped with the effort. While it wasn't terribly difficult it did take time and cost money. That experience probably marked the last time I used Forth on an embedded system. Every time I considered the idea for my own work I remembered what happened to him. As a result I pretty much stayed with C/C++ for embedded work from that point forward. My gut feeling is that today Forth is a liability for most applications outside cases where there might be an existing code base that must be leveraged. EDIT: I still think it is important for programmers to learn about TIL's and Forth. You'd gain valuable perspective and a different way to see and approach problems.

voltagex_ 13y ago
Although it didn't sell well, the WikiReader [1] ran Forth. [1] http://yannramin.com/2009/10/16/the-wikireader-cool-device-future-hackability/ http://yannramin.com/2009/10/16/the-wikireader-cool-device-f...
- dvdkhlng 13y ago
  The WikiReader does have a Forth interpreter embedded in its firmware, but doesn't run it by default. It is activated when pressing the right buttons at boot and allows developers to access a Forth console via serial debug-cable and/or compile Forth programs from Forth sources contained in the built-in micro-SD card. As Forth is very low-level and allows direct access to memory (and thus memory-mapped registers), it makes testing hardware quite efficient (and fun). What makes you believe the WikiReader didn't sell well? AFAIR quite the opposite.
  - synchronise 13y ago
    Just reading this topic, turns out you can grab this for $11.99 + p&h from Amazon. http://www.amazon.com/WikiReader-WR-01-Pocket-Wikipedia/dp/B002N5521W/ http://www.amazon.com/WikiReader-WR-01-Pocket-Wikipedia/dp/B... I'm actually considering getting one of these for that price, would be an interesting device to tinker with FORTH.
bcoates 13y ago
Stories like this always astound me. Learning Forth is probably less difficult than the average GUI widget library. Anyone who I'd trust around a C compiler could probably become a serviceable Forth coder in a weekend. Do moderately bright kids not get exposed to HP RPN calculators anymore?
- coolsunglasses 13y ago
  >Do moderately bright kids not get exposed to HP RPN calculators anymore? No, they learn BASIC (maybe) on the TI graphing calculators.
- smoyer 13y ago
  I did exactly that ... learned FORTH to get a job and (almost) immediately started helping with embedded systems using assembly and C.
- robomartin 13y ago
  Well, for what it's worth all we have at home are HP calculators. I taught my oldest kid to use them. He's the only kid in his school with an HP41. His math and science teachers didn't know how to use it.
kabdib 13y ago
A friend of mine wrote a big embedded system in FORTH. He was really pragmatic, and his code was good. It's one of the few success stories of FORTH that I know of: Very well structured, well-documented, and it performed well. A few years later he and his team had converted it to C, too, since they couldn't find people to work on it. I recently re-read _Starting FORTH_ and was again struck by how simple the language is. It's perfect for things like system bringup (which is what we used it for at Atari) and other small applications where you don't need complex data structures or hard real time operation, and your team is small. Beyond that, FORTH doesn't appear to scale. That's also an important lesson. Every embedded engineer should write a FORTH kernel. It's small enough to take just a few days to get something running. It's a valuable lesson in "just enough, and lots less than you think you need".
- rwmj 13y ago
  That was certainly my experience writing a small FORTH kernel. The immediate problems are: lack of dynamic allocation, and poor handling of complex functions. Of course you can write your own dynamic allocation routines, but that will make your FORTH less than simple. [I'll assume here that garbage collection is probably out of scope for tiny embedded systems -- I'm just talking about lack of malloc/free-like functionality] The standard advice is to break up functions into smaller and smaller units, but I found you can only go so far doing that, and in any case it just leads to having lots of small functions to understand which is a type of complexity in itself. Being effectively forced to use the stack to store and pass intermediate results around is highly non-intuitive for programmers used to more common languages.
  - astrobe_ 13y ago
    > the immediate problems are: lack of dynamic allocation That's not an "immediate" problem, far from it. I've written a standalone Forth system. I could boot it from a floppy, modify its source, and recompile it in less than a minute on an anachronistic 8086-based laptop. Then I ported to C in order to be able to play with the zillions of libraries one can find on Windows and Linux, to play with GUI and 3D Engines. I did implement heap functions, but it was more for the fun of it than because I needed them. > poor handling of complex functions. Other languages would let you create function/methods that spread over dozens of pages, but this is universally considered bad form. Forth isn't designed for bad form, which is indeed a serious competitive handicap nowasdays. > Of course you can write your own dynamic allocation routines, but that will make your FORTH less than simple So you either say "Forth sucks" or you can say "Are there better ways?". If you add up the overhead of heap allocation structures, the size of the malloc/free functions and the overhead of calling malloc/free, you'll find out that often, over-allocating static structures is just as good, memory-wise. Moreover most systems, including many embedded systems, have plenty of resources. So it doesn't really matter if you waste some kilobytes because you're over-allocating. > having lots of small functions to understand which is a type of complexity in itself Ravioli code versus Spaghetti code has always been a conundrum. In the end you just can't set an arbitrary limits on the size of definitions/functions/methods. I think the correct criteria is that you definitions are semantic units. As Brodie points out in Thinking Forth, if you can describe your definition in one short sentence, it is ok. If you do that and still end up with lots of definitions, it is likely that the problem you are trying to solve is itself complex. > highly non-intuitive for programmers used to more common languages That's to me a funny reproach, because my definition of a programmer is to be able to absorb and adapt to new languages, styles and paradigms in no time. You know that feeling when you try to explain what's your job exactly and people think you're talking witchcraft? Our job is to deal with non-intuitive, occult siliconic forces.

voltagex_ 13y ago

Although it didn't sell well, the WikiReader [1] ran Forth. [1] http://yannramin.com/2009/10/16/the-wikireader-cool-device-future-hackability/ http://yannramin.com/2009/10/16/the-wikireader-cool-device-f...

dvdkhlng 13y ago
The WikiReader does have a Forth interpreter embedded in its firmware, but doesn't run it by default. It is activated when pressing the right buttons at boot and allows developers to access a Forth console via serial debug-cable and/or compile Forth programs from Forth sources contained in the built-in micro-SD card. As Forth is very low-level and allows direct access to memory (and thus memory-mapped registers), it makes testing hardware quite efficient (and fun). What makes you believe the WikiReader didn't sell well? AFAIR quite the opposite.
- synchronise 13y ago
  Just reading this topic, turns out you can grab this for $11.99 + p&h from Amazon. http://www.amazon.com/WikiReader-WR-01-Pocket-Wikipedia/dp/B002N5521W/ http://www.amazon.com/WikiReader-WR-01-Pocket-Wikipedia/dp/B... I'm actually considering getting one of these for that price, would be an interesting device to tinker with FORTH.

bcoates 13y ago

Stories like this always astound me. Learning Forth is probably less difficult than the average GUI widget library. Anyone who I'd trust around a C compiler could probably become a serviceable Forth coder in a weekend. Do moderately bright kids not get exposed to HP RPN calculators anymore?

coolsunglasses 13y ago
>Do moderately bright kids not get exposed to HP RPN calculators anymore? No, they learn BASIC (maybe) on the TI graphing calculators.
smoyer 13y ago
I did exactly that ... learned FORTH to get a job and (almost) immediately started helping with embedded systems using assembly and C.
robomartin 13y ago
Well, for what it's worth all we have at home are HP calculators. I taught my oldest kid to use them. He's the only kid in his school with an HP41. His math and science teachers didn't know how to use it.

kabdib 13y ago

A friend of mine wrote a big embedded system in FORTH. He was really pragmatic, and his code was good. It's one of the few success stories of FORTH that I know of: Very well structured, well-documented, and it performed well. A few years later he and his team had converted it to C, too, since they couldn't find people to work on it. I recently re-read _Starting FORTH_ and was again struck by how simple the language is. It's perfect for things like system bringup (which is what we used it for at Atari) and other small applications where you don't need complex data structures or hard real time operation, and your team is small. Beyond that, FORTH doesn't appear to scale. That's also an important lesson. Every embedded engineer should write a FORTH kernel. It's small enough to take just a few days to get something running. It's a valuable lesson in "just enough, and lots less than you think you need".

rwmj 13y ago
That was certainly my experience writing a small FORTH kernel. The immediate problems are: lack of dynamic allocation, and poor handling of complex functions. Of course you can write your own dynamic allocation routines, but that will make your FORTH less than simple. [I'll assume here that garbage collection is probably out of scope for tiny embedded systems -- I'm just talking about lack of malloc/free-like functionality] The standard advice is to break up functions into smaller and smaller units, but I found you can only go so far doing that, and in any case it just leads to having lots of small functions to understand which is a type of complexity in itself. Being effectively forced to use the stack to store and pass intermediate results around is highly non-intuitive for programmers used to more common languages.
- astrobe_ 13y ago
  > the immediate problems are: lack of dynamic allocation That's not an "immediate" problem, far from it. I've written a standalone Forth system. I could boot it from a floppy, modify its source, and recompile it in less than a minute on an anachronistic 8086-based laptop. Then I ported to C in order to be able to play with the zillions of libraries one can find on Windows and Linux, to play with GUI and 3D Engines. I did implement heap functions, but it was more for the fun of it than because I needed them. > poor handling of complex functions. Other languages would let you create function/methods that spread over dozens of pages, but this is universally considered bad form. Forth isn't designed for bad form, which is indeed a serious competitive handicap nowasdays. > Of course you can write your own dynamic allocation routines, but that will make your FORTH less than simple So you either say "Forth sucks" or you can say "Are there better ways?". If you add up the overhead of heap allocation structures, the size of the malloc/free functions and the overhead of calling malloc/free, you'll find out that often, over-allocating static structures is just as good, memory-wise. Moreover most systems, including many embedded systems, have plenty of resources. So it doesn't really matter if you waste some kilobytes because you're over-allocating. > having lots of small functions to understand which is a type of complexity in itself Ravioli code versus Spaghetti code has always been a conundrum. In the end you just can't set an arbitrary limits on the size of definitions/functions/methods. I think the correct criteria is that you definitions are semantic units. As Brodie points out in Thinking Forth, if you can describe your definition in one short sentence, it is ok. If you do that and still end up with lots of definitions, it is likely that the problem you are trying to solve is itself complex. > highly non-intuitive for programmers used to more common languages That's to me a funny reproach, because my definition of a programmer is to be able to absorb and adapt to new languages, styles and paradigms in no time. You know that feeling when you try to explain what's your job exactly and people think you're talking witchcraft? Our job is to deal with non-intuitive, occult siliconic forces.