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

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