It’s a little unfair that people are referring to this as a bad programming language where it’s actually effectively a save-file that has been reverse engineered to edit it beyond its original scope and functionality.
Compiled java bytecode is also not the best programming language, albeit admittedly much better than this!
The hard limit of 2000 variables / constants is little different from the hard limit of <some amounts of kbytes> of memory you get in various systems.
Similarly I don't think there's anything wrong with generated code not having a notion of scope.
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!”
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.
You make it sound like they decided to do that for fun. They decided to do that because the drag-and-drop editor was unfit for purpose.
Unfit for their purpose - it probably satisfied the purpose that BANCStar was selling it for.
It sounds like they just realised that this feature of BANCStar would let them inject their own arbitrary code to allow deeper modification of the system than what was intended, which was not within the scope of the original feature.