More like, one company created a drag-and-drop editor for their enterprise software, and the customer decided to edit the byte code it output.
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!
I would have agreed with you if it weren’t for the other limitations, like the hard limit of 2000 variables and constants and lack of scoping forcing larger projects to reuse variables in multiple unrelated places.
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.
> 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.
