3 ms·

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

by 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.
astrobe_ 13y ago
I don't see where you fetch your claims from. "hard real time operation", for instance, is the responsability of the operating system. If Forth is also the OS, nothing prevents anyone from implementing real time features like in any other operating systems. "Small teams" is common practice since Brooks, even in "big projects", where the workload is split among small internal teams. "Scale": that word means nothing without a dimension. Learning Forth takes a few days, but writing one rather takes a few weeks the first time, in particular if you want to go beyond the trivial "Forth in language X" stuff that doesn't learn you a lot about how KISS operates in Forth.

by kabdib 13y ago

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.

astrobe_ 13y ago

I don't see where you fetch your claims from. "hard real time operation", for instance, is the responsability of the operating system. If Forth is also the OS, nothing prevents anyone from implementing real time features like in any other operating systems. "Small teams" is common practice since Brooks, even in "big projects", where the workload is split among small internal teams. "Scale": that word means nothing without a dimension. Learning Forth takes a few days, but writing one rather takes a few weeks the first time, in particular if you want to go beyond the trivial "Forth in language X" stuff that doesn't learn you a lot about how KISS operates in Forth.