| > Write-only, because only the functions (‘WORDS’) are named - no parameter names. Depends on who is the writer... > There are also no local variables in standard Forth Named locals variables are in the standard, as an optional extension. Because not everyone want them. > you have to push (and pop!) them from the separate return stack That's the main reason why the return stack is exposed to the programmer, yes, but there are other techniques like putting some of the data that are used throughout the program in (global) variables. you generally choose depending on how much simplification you gain and how much modularity you lose etc. > Accessing parameters is done by manipulating the stack, which makes the code opaque after a year or so Depends on how you write and comment. > Named constants and variables are all global. So, it is very difficult for a team to use Standard Forth as vocabularies to isolate functions, constants, and variables that is supposed to help with name clashes. Many variants like Retro have some sort of namespace mechanism. Did you actually use Forth in a team context? > These failings could be at least partly forgiven if Forth was fast. But it isn’t, because most words are short and all the stack manipulations are done with subroutine calls Not a problem, because you design your programs to minimize stack juggling. Less overhead, more readable, one stone, two birds. My dialect which uses very naive subroutine threading (it just executes lists of function pointers) can rival with Lua (non JIT) on certain tasks because my Forth doesn't spend its time doing useless stuff like looking up an hash table. The speed of Forth is not in its bytecode interpreter. It's in the simplifications it encourages. > It’s possible to write an inlining, optimizing compiler, but then the simple layout of code in memory is lost, and quick introspection using a memory dump becomes nearly impossible I have written a few decades such a thing for the 8086, and I would say the lack of introspection was never a problem. When you write such a system, the hex machine codes sticks quickly in your head. I think I wrote a disassembler for the lulz, but an hex dump was probably my main "introspection" tool. > I wrote a Forth a few decades ago I wrote several Forth systems in the last few decades. The latest one I wrote is my goto-tool and serves me almost daily. |
Unless working in assembly or something of that sort, tend to I comment only on noteworthy matters pertaining to specific logic, not recurring units of basic program structure and their routine connections.