Well, that sounds like the Holy Grail of programming to me! Such a program would necessarily be perfectly bug-free.
After all the years of effort and study that have gone into the theory of determining program correctness (halting problems and all that), it’s nice to see that the problem has finally been solved by such a seeming straightforward approach. It’s easy to miss the obvious, isn’t it?
Hungarian notation always annoyed me for exactly that reason. If you’re writing, say, C++ code to perform some sort of physics computation, then it’s not a bad idea to tag variables with their units: foo_ft, bar_kg, baz_deg, etc. (An even better idea is to stick one set of units throughout: radians, basic metric units, etc., but you don’t always have that option.) The point is that those are all doubles (or floats, or whatever); the semantic meaning of those variables is completely unknown to the compiler. On the other hand, the compiler is aware of what the types of variables are, and the syntax makes it clear to the user; writing something like ppiFoo for a pointer to a pointer to an integer just makes code harder to read for no benefit.
Another thing that’s always bothered me is styles that go too far in avoiding simple problems. In C++, for example, you can happily define ints and pointers to ints on the same line: “int x, *y;” is totally legal, for example. The (alleged) problem is that you can also write “int x, y" or even "int x, y”, which may lead some people to think that x and y are both declared as pointers to ints. There are a couple of dealing with this: Do nothing, since it’s any one familiar with C to be reading the code will be aware of that issue; declare pointers to a type and actual variables of that type, to avoid confusion; and so forth. Some places take it too far and insist that every single variable be defined on its separate line. At that point, you’re not even solving the original problem anymore. Some companies seem to go through a cycle when they have no coding standards (or people who naturally decent code themselves) to push the product out the door as quickly as possible, then switch to overcompensating and mandate an unnecessarily strict set of conventions to try to fix the original problem. Long story short, I’m glad I’m not doing that sort of work anymore.
I fondly remember line printers. I wrapped many Christmas presents in old listings. Such fun watching the results of some poor student leaving all their books on top of a line printer, not expecting it to run out of paper at an inopportune moment (the whole lid would tilt up, dumping anything left on it on the floor). I used an uppercase/lowecase print chain (what you called the thing with all the letters) maybe 2 or 3 times; virtually everything I did was with a (default) uppercase only print chain.
What was plausible, though, is that somebody wrote that compiler in machine language.
Although, even that was never quite plausible. It was a HUGE program, as you might expect of a compiler written in assembly language. But the coding style sure screamed “WRITTEN IN BARE BONES BINARY BY A TEAM OF 10,000 ELBONIANS AND TRANSLATED TO ASSEMBLY BY SOME AUTOMATED SYSTEM”.
There’s even some history behind this, or at least some of this.
The convention of using letters near the end of the alphabet for variables, and letters near the beginning of the alphabet for constants (as in, for example, the general quadratic equation in two variables: ax[sup]2[/sup] + bxy + cy[sup]2[/sup] + dx + ey + f = 0) was originated (as I recall reading it) by Descartes, who did his major work before FORTRAN was in widespread use.
The data type belongs as a suffix -num, -idx, -dat NOT the prefix.
The prefix indicates its logical grouping pers- (personnel) rc- accounts receivable dda- demand deposit account.
The practice in COBOL was to use a prefix indicating the record (row) on which the data was stored.
Much more sensible as a sort key - I may wish to see which fields of MY DATA this other person is using. I’d prefer to see that over “show me every date field” or “lets see all the indicies”.
And that COBOL non-index which looks like an index?
Only n very specific versions of PERFORM XXXXXXXX (thru XXXXXXXX) VARYING TERMS-INDX FROM +1 (BY N) UNTIL TERM_INDX >* TERMS-TABLE-LIMIT.
You could equally write:
MOVE ‘N’ TO WS-TERMS-FND-SW.
SET TERM_INDX TO +1.
PERFORM 01220-FIND-TERMS UNTIL WS-TERMS-FND-SW = ‘Y’
OR TERM_INDX > TERMS-TABLE-LIMIT.
01220-FIND-TERMS.
IF TERMS-CODE (TERM-INDX) = AR-TERM-CODE
MOVE ‘Y’ TO WS-TERMS-FND-SW
END-IF
SET TERM-INDX UP BY +1
01220-EXIT. EXIT.
(* - test is at the top - interview trivia question)
Hi all, been lurking for years, finally registered to post to this thread.
I Learned FORTRAN IV in 1967, as used on an IBM 360 Model 44, an odd mainframe especially geared towards scientific processing (as opposed to commercial data processing), with variable length floating point arithmetic available. Although we never used that advanced and specialized feature, one could define variable length operations, and the machine operator could turn a dial on the front of the CPU for how many digits would be employed!
But the point of my post concerns the debate about the use of the word ‘index’ for the controlling value of a do loop. It is simply a part of the FORTRAN language definition that the ‘variable’ in the statement
DO ‘statement#’ ‘variable’ = ‘startvalue’ ‘endvalue’ ‘increment’
is known as the loop index. I was so sure that I googled and the first 5 or 6 hits agreed, and I learned it’s called an index in Oracle looping, too.
Senegoid, it’s also possible that the program was originally written in sane assembly language, then assembled, and then the original assembly language source was lost while the binary was retained, and then disassembled back. This would be similar to my old OCRed code, though pathological in different ways (the code you had would actually work just fine, but was probably a lot harder for a human to read).
When I was learning programming (over 20 years ago), the example of a loop designed to produce a delay used “i” as its variable. The only reason given was that it was something you were unlikely to use for something else, as the favorites were x, y, z, a, b, &c.
Not liking that reason very much, I disregarded that advice.
I’ve never been a professional programmer, only writing for myself, so it has never been an issue.
Not so sure. Going only by the use of statement labels A001, A002, . . . B001, B002, . . . that might suggest what you’re thinking.
But the code was also the most horrendous stew of spaghetti code. You could open to any page and start skimming the code, and you could hardly find three to five lines in a row anywhere that didn’t have some kind of conditional or unconditional branch to some place a dozen pages away or a hundred pages away.
So, your hypothesis (written in assembly language, source lost, binary disassembled) is plausible, except for the idea that it might have originally been written in sane anything.
But hey, in assembly language, you can name your floats and ints anything you want because there are no default naming conventions at all!
A linker will often spray crud about like that, or many compilers themselves. Is it all possible that you have a disassembled object code from a compiled program?
What paradigm of compiler is it? Or given its vintage, does it have any sort of overarching design rationale or is it just ad-hoc? Any sort of table driven system can often be auto-generated and will end up a total disaster if you want to look at what it generates.
Even working through modern compiler output, once linked, it can end up an insane mess. Fortran, with its lack of recursion, might make writing for a very weird compiler. And compilers were most certianly written in Fortran. Even the first Pascal compiler was bootstrapped from a Fortran version.
Paradigm: Paleolithic spaghetti. Okay, maybe neolithic spaghetti. This was Control Data, circa late 1960’s (although I was involved in the early 1970’s). As far as I could tell, EVERYTHING was written in assembly language. Even the COBOL compiler was written in assembly language. The entire operating system was written in assembly language. I think their ALGOL compiler was written in assembly (and I had heard that it was a 17-pass compiler or something really absurd like that). Their major utility programs were written in assembly language. This was at UC Berkeley. We had the source code for all of that. CDC shipped source code with their systems (not sure if everybody got this, or only customers who paid extra). Software updates were shipped in the form of source code updates, which we applied and then re-assembled the whole source. Assembling the FORTRAN compiler could take a good hour of machine time on a CDC 6400. A large part of my job was applying those updates, reassembling, testing, and installing; and likewise for the runtime library (which at least consisted of, you know, modules ).