The limit doesn't seem unreasonable given the intended purpose: very likely if someone ran into the limit using the "screen generator" (and was paying for support) it could be fixed with a simple recompile of the interpreter.
Similarly I don't think there's anything wrong with generated code not having a notion of scope.
Agreed - in fact I bet the original creators thought they were being generous allowing for 2000 variables for their gui editor!
Vendor Engineers: “Who would possibly need more than 2000 variables to make a few custom screens in our new drag and drop screen editor feature?”
Customer Engineers: “Hey we can exploit this new custom screen editor to inject our own arbitrary code! Why have they only allowed for 2000 variables? Idiots!”
You might be right but your argument rests on an awful lot of assumptions that weren’t detailed in the article.
It’s just as likely it was intended to scale the way it had and it was just poorly implemented from the outset. I’ve seen this happen plenty of times in the past where an extremely rudimentary POC is rushed into production and the official workaround is a scary chain of kludges. It was especially common in the era this BANCStar originates because compute time was expensive so it was often cheaper to code by hand and then hire typists who’d input your code and compile it, passing you a print out of any errors raised. Starting again from scratch if your basic premise sucked often wasn’t an option. Man do I not miss those days.
Similarly I don't think there's anything wrong with generated code not having a notion of scope.