@6502coder
Well, you are quite correct, of course. And - considering that some uPs had a faster clock than others, a claim for speed was generally short-lived. I spent some time considering the advantages of subroutine threading (where a program is essentially a sequence of call instructions) vs the disadvantages (a program takes approx. 50% more space, because one extra byte precedes the subroutine address). Speed worn. Looking back at a CPU with a clocking rate 1/1000 of the present shows how quickly design has moved over 40 years.So to claim that CONVERS was faster than FORTH is to beg the question of how the FORTH was implemented.
On the topic of software reliability: You wrote
Manipulating the stack certainly does take a great deal of effort, but any program error that imbalances the stack will be quickly revealed.the programmer had to do more mental work writing it in the first place.
As for writing a compiler in AWK - that's an interesting task. So your language (THIRD) was a little 'less' than FORTH? Did you ever consider piping the output from THIRD into 'more'? That might just get 3rd promoted to 4th.
All the best
cobaka
- - - - - - - -
From @6502coder
Welcome to the world of AWK!
I once wrote a primitive FORTH interpreter in AWK. I think I called it "THIRD" -- because it wasn't quite FORTH. (That's not as bad a pun as it may seem because in fact Charles Moore wanted to name his language FOURTH (for "fourth-generation language) but the system he was working on at the time only allowed 5 letters for identifiers.)
I had a very brief look at the CONVERS document. I want to point out that FORTH was a language, not an implementation spec. That is, while most FORTHs were implemented as threaded interpreters, nothing in the language spec itself REQUIRED this. Even among the threaded interpreter implementations, there were variations: most were "indirect threaded," some were "direct threaded," others were "subroutine threaded", etc. So to claim that CONVERS was faster than FORTH is to beg the question of how the FORTH was implemented.
Regarding the "bug-free" nature of CONVERS, I would assume that, as in FORTH, most routines were very short -- Charles Moore found the idea of a program larger than a few dozen Kbytes to be totally absurd -- and thus there was less to go wrong in the first place. Also, as Jerry Pournelle once said in his Byte Magazine column (although he was actually quoting a friend of his), FORTH is basically a macro assembler language that uses the programmer as a precompiler. The two points being that a) since the programmer has to keep track of what's on the stack at all times, the language demands a mental focus that in and of itself probably tends to result in better quality code; and b) the resulting source code can very compact but that's because the programmer had to do more mental work writing it in the first place.
Pardon me for wandering off topic...but hey, you started it!
with an idiotic memory management over that 
.
. But the life time of Windows 95 was passed out...
) programming language was Fortran, Fortran77.
