Small Marks of Futures Past

Sometimes the oddest things show bitrot as sfnal futures diverge from our actual future.

This is from Dorothy Heydt's A Point of Honor (now available at her website in electronic format):

..."the scrolling slowed and stopped, displaying a pair of lines surrounded by asterisks: "Following 1175 lines make the tree growth respond to the wind direction. G.H."

"All the code we wrote is commented," Greg said. "Good code should be...."

Heydt generally gets UNIXy geeky things right, but between the high days of hacker and USENET culture and today some underlying details have changed so as to becone a little jarring.

The idea that you mark a functional unit of over a thousand lines in a highly optimized program by a comment was once arguably good practice, but emphasis is now put on getting the clarity by a greater number of small functions. Optimizing compilers that do inlining render the efficiency gains of avoiding multiple function calls, doing loop unrolling, and so forth, less important. No normal function should be even in the small hundreds of lines. (This is still frequently not actually true. I've seen lots of production code with thousand-line functions, but that has been invariably the result of laziness and sloppiness and not because someone was intent on saving cycles.)

Explicative clarity is gained by providing expressive function names (linkers capable of handling long symbols helped there as well):

void take_wind_input_and_generate_tree_motion()

(or, if you prefer,

void TakeWindInputAndGenerateTreeMotion())

with appropriate sub-functions.

The days of Henry Spencer's "Thy external identifiers shall be unique in the first six characters, though this harsh discipline be irksome and the years of its necessity stretch before thee seemingly without end, lest thou tear thy hair out and go mad on that fateful day when thou desirest to make thy program run on an old system" are now past: it would now be a bizarre system where the linker was so strictly constrained. (This led to function names like lstwgm() for landscape (package prefix to help insure uniqueness) tree wind generate motion.)

Frequent advice is to avoid comments where the symbol naming conventions render them redundant. (Comments are still encouraged for documentation purposes in headers which will be run through doxygen - if discussion is necessary.)

The thing making this slightly jarring is not its applicability to the programming practices for optimized code from the 1970s and 80s, but simply the fact that the story takes place in the future, at a date which is still in our future.