I'm surprised to hear that you think her paper addresses a dated concern. I felt it's more relevant than ever. While I agree that naming collisions are not such a big problem, all the other issues she mentions are still present, and have even gotten worse.
This would require a fairly lengthy discussion and a level of frankness required in terms of discussing the realities of software profession that imho will not be well received in this forum. I didn't say her thoughts were incorrect. Simply this: it reflects the appraisals and realities of an earlier time in this profession.
Would love to discuss it and further understand your viewpoint. Feel free to be as frank as you need to be, would love to hear a radical new opinion on this.
From my experience, what she said is still highly relevant.
Maybe I can share my own viewpoint first: Imagine you want to use a third party dependency from GitHub. The first thing you will do is read the readme, which contains an architectural overview (if the project is documented well). This overview is very similar to what she describes in the paper - it's mostly prose and a few (non-formal) diagrams. Often, it's very hard to understand how the code fits into the bigger picture of the system. Also, a lot of info is implicit or only contained in prose (for example, which function do I call first?).
Wouldn't it be great if all this were standardized/codified in some way, and not just part of the documentation?
> Often, it's very hard to understand how the code fits into the bigger picture of the system.
Progressively and now quite frequently in the field, usage of 3rd party code is formulaic. Progressively, as demand for software has increased, an equally downward pressure is brought to bear on value placed on contemplation.
> Wouldn't it be great if all this were standardized/codified in some way, and not just part of the documentation?
Yes. This is a thoughtful approach and would reduce the burden for the thoughtful programmer.
