Any principle of 'good program structure' that applies across "computational fluid dynamics simulation, nearest neighbor classifier, relational database, enterprise inventory control, or a simple blog engine" is so vague as to be meaningless - or at least, not very interesting.
Methodology weenies are always claiming that they've got abstractions that are absolutely key across very diverse problem areas, usually without any demonstration that said abstractions are useful for solving hard problems in any areas at all.
Compared to this kind of waffly crapulousness, we should compare the classic papers on the design of, say, RISC, TCP/IP, etc. Grinding through how Tomasulo's algorithm worked on the IBM/360, for example, will greatly expand your understanding of actual computer architecture; the only weakness is that it will not especially expand your ability to Issue Pronouncements About What Good Programs Look Like.
... or more concisely, we will still be reading about 'branch and bound', 'parallel prefix', 'greedy algorithms vs divide and conquer', 'exponential backoff', 'multi-level caching', 'speculative execution', etc, long after the Revolution, when the last Object Orientation Guru is strangled with the guts of the last Functional Programming Weenie.
Methodology weenies are always claiming that they've got abstractions that are absolutely key across very diverse problem areas, usually without any demonstration that said abstractions are useful for solving hard problems in any areas at all.
Compared to this kind of waffly crapulousness, we should compare the classic papers on the design of, say, RISC, TCP/IP, etc. Grinding through how Tomasulo's algorithm worked on the IBM/360, for example, will greatly expand your understanding of actual computer architecture; the only weakness is that it will not especially expand your ability to Issue Pronouncements About What Good Programs Look Like.