[dewster]

I briefly skimmed [1] and their more sophisticated translation to a register VM yielded a 25% increase in code size, and not the 45% you stated? Regardless, VM to VM really isn't my point.

I still don't get the positives of why the programmer should be presented with a stack machine SW model when there is no stack machine type stack to be found in the HW. Programmers with no stack machine / language experience probably think (as I did at one point): "the stack on my HP calculator stack works great, why not base a language on that?" but it scales poorly, it gets really hairy if the stack is the only place to store things, and it's a major headache keeping the stack from going out of sync (hence Forth's clear I/O comments regarding subroutine stack use).

[throwaway17_17]

You are correct about the 25%. That was a mistake (for anyone else looking, the 45% was a decrease in the executed instruction amount from stack to register.

Correction aside, I, at some level, agree with you. The question of appropriateness/benefits of a SM model is different than considerations of the effectiveness of the code. In terms of the Forth SM model and its explicitly imperative model, I am familiar with the various complaints/arguments/critiques for varying reasons. I certainly acknowledge there is at least some burden placed due to the stack mechanics. I happen to be particularly attracted to the approach and enjoy programming that way, but that is just a preference of mine. However, I also tend to look at Forth as imperative language with which to program in what Backus describes as ‘function level programming.’ I find the benefits as listed by Jon Purdy, author of the Kitten language, in his talk about concatenative code to be compelling enough that exploration and refinement of this idea space to be valuable.

All that said, I am perfectly willing to consider that, as presented in Forth and presumably in the proposed language, SM mechanics and models are a hurdle for users of the language.