Doug -On Aug 31, 2012, at 9:36 AM, doug foxvog wrote: At least COBOL from the beginning encouraged (semi-)readable variable
names -- at a time when FORTRAN was pushing I, J, N for integers and
X, Y, Z for floats and in-line comments were rare.
True, but...
M0101 is a perfectly fine COBOL variable name. M0101 was also known as MSTR-POL-NO in a different environment in the same company. They are just 2 of the 70+ "policy number" names/labels.
Favorite story:
At one point I was chewing on this "good names" issue with an old goat (a creator of Nomad).
He offered that in the early 1960s he was "messing around" with Fortran compilers.
At the time Fortran variable names were restricted to 6 (?... I don't remember exactly... just brutally short & cryptic) characters. The proposal came down from the Fortran powers-that-be to expand to 8 character names... and he FAUGHT it! Six was plenty.
He offered this glimpse into his misspent youth with a heavy sigh... "how dumb could I be?"
The point here though is just because a language has the capability to have long, descriptive names, "descriptive" is very much in the eye of the creator... and may be something altogether different in the SME/analyst/programmer who comes along 20 years later.
The semantics of the business is buried in these schemas that can be many decades old... how does the SW help make such opaque labels meaningful?
BTW... this is not an exercise constrained to RDBMS engines such as DB2, Oracle, Sybase, SQL Server, etc.
As John Sowa points out new layers are built on old layers... I doubt if I've seen any mention of Adabase, IMS, S2000, IDMS, VSAM, or M204 in these conversations |