Notes+10.5

Review what I expect for the OrderedCollection assignment.

Build all those functions that I suggest in the assignment (and a few more). If you can't think of a better name for the function, use the one I suggest.

An OrderedCollection, probably represented by a struct if you program in C, bundles an Array with a little knowledge about which elements are actually in use. As implemented in C, everyone who uses an OrderedCollection has to know about the care and feeding of the collection, but at least they COULD be good citizens and access the data ONLY through procedure calls.

Program Size???
Rik asked everyone to think of the biggest program they had worked on so far. Even in a lucky group with no duplicate birthdays, I was confident that confusion would ensue. How do you measure "big"? Is it just what I wrote? If you worked on part of a system, shouldn't your stuff work with the rest of the stuff? Even if your big system is a few hundred line of code that you wrote yourself, how easy is it to remember all the details of what you did? Can you read and understand your code? Think about ways you can make your code easy for someone (possibly yourself in a few months) to understand. You have probably noticed that I sneak tidbits of advice about software engineering into this class.

Legacy Systems
I'll guess that most of you students who someday get jobs in software will encounter legacy systems. You will need to make changes to "big" systems where you do not get to collaborate with the original authors (who might be gone). We can try to make things cleaner as we go. We won't have much time to talk about tools to aid in getting your head around legacy code.

Performance:
one measure is how soon can we have OUR answer (the rest of the world can take a hike). Another measure is how many useful answers can a computer deliver in a day. A fine way to reduce performance is to compute things that nobody wants.

Lazy Evaluation
Be lazy about computing things until someone wants the answer. Unless your program is entirely designed to run a wristwatch, don't bother calculating the time and formatting it until someone wants to see it. (Not compelling example) Example from logic: we know that A & B is true if both A and B are true. Suppose A and B are expressions, perhaps involving functions and who knows how much work it is to compute each one. Suppose then that the program evaluates A, and it is FALSE. It does NOT need to evaluate B.

How often to you ask your UNIX computer how much disk space is used? (du) We could burn a lot of cycles computing the number every time anything changed a file.

This seems SO obvious, but you would be surprised how often programs work too hard. Sometimes there is a valid business reason: the program is already good enough, and it does not run often: why mess with it?

Sterile Abscess
Our bodies often grow tissue around an intrusive particle, such as a splinter. It can also encase what had been a septic abscess once the microbes are defeated. The blob just sits there, relatively harmlessly. Computer systems have these also. Notable example of a sterile abscess by design: an insurance company with ancient policies which were written during the era of IBM 704, even as they were re-writing most of the company's software before Y2K, ran a 704 emulator on an IBM 360 which itself was now emulated on an IBM zSeries computer in order to print statements for those ancient policies. The IBM assembler programmers who supported the insurance sales force and the actuaries in the 1950s and 1960s are all retired, and many of them are dead: they are NOT available to help figure out what the meaning of the program is. As long as any of the policy holders live, it is cheaper to just run the old programs than to try to figure out what they mean.