4 ms·
To the grand parent: you're not supposed to look at generated code, if you have changes you're supposed to re-generate it. So at some level, that's the 'why' th
by marktangotango 11y ago
To the grand parent: you're not supposed to look at generated code, if you have changes you're supposed to re-generate it. So at some level, that's the 'why' that happens.
In Cobol 85, all variable are global to the program, and statically allocated at program start up. It's not uncommon for a Cobol program to import 10's or 100's of 'copybooks' and have 100-1000's variables in the global scope. They are, however, name spaced after a fashion.
My experience with this came from a similar behemoth mainframe app; 35 MLoc, 15,000 programs, thousands of jobs, running a batch and interactive green screen app that a company hosted. Was the source of about $500M a year in revenue.
- engi_nerd 11y ago>To the grand parent: you're not supposed to look at generated code, if you have changes you're supposed to re-generate it. Generated code? What do you mean? (I have no familiarity with VB6 at all. I have written quite a bit of code in C, Python, and MATLAB). Besides, all this was handwritten (I eventually had a conversation with the code's original author while at a party). The guy was crazy enough to write all of that by hand. I genuinely think the effort made him a little unhinged. And of course he could have been lying...
- bootload 11y ago"Generated code? What do you mean? (I have no familiarity with VB6 at all." I think the parent is referring to generated COBOL code.