3 ms·

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 pro

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.

masklinn 5y ago
None of these is relevant under the original concept / assumption of this basically being the description file for a UI-generated system, though. 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.
- laumars 5y ago
  I’ve developed on those systems and that’s a hardware imposed limit due to the, then current, technology. Which this 2000 var limit is not.
mjw1007 5y ago
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.
- Closi 5y ago
  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!”
- laumars 5y ago
  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.

masklinn 5y ago

None of these is relevant under the original concept / assumption of this basically being the description file for a UI-generated system, though. 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.

laumars 5y ago
I’ve developed on those systems and that’s a hardware imposed limit due to the, then current, technology. Which this 2000 var limit is not.

mjw1007 5y ago

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.

Closi 5y ago
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!”
laumars 5y ago
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.