Magnus Therning wrote:
I'll certainly try to look into all of that. However, I suspect your suggestion doesn't scale very well. On my original code it's easy, it was less than 10 lines, but how do I know where to start looking if it's a program of 100 lines, or 1000 lines? The problem could occur in an updated library that I just use... Well you get the idea :-)
A library function is supposed to tell you its time usage, memory usage, file usage, ... generally resource usage, as part of its specification. A 100-line program is not supposed to be a monolith. It is supposed to be a combination of 10 functions (or 10 parts; I'll call them functions anyway), 10 lines each. Each function is supposed to come with its specification too, which again tells you its resource usage. To reason about the 100-line program, you only need to reason about 10 lines of specifications. To reason about a program that calls a library function, you only need to plug its specification --- emphatically not its code! --- at the call site, and proceed. (It remains to reason that each 10-line function conforms to its 1-line specification, but we agreed that 10 lines are ok. It also remains to reason that the library function conforms to its documented specification, but that is the author's job, and again the author can apply the same divide-and-conquer to stay tractable.) To reason about a 1000-line program, again it is not supposed to be a monolith. It is supposed to be a combination of 10 functions, each 100 lines. The 1000-line program is 10 lines of specifications combined. We already know how to deal with each 100-line function... You get the idea. Divide-and-conquer. Abstraction. Modularization. Separation of Concerns. That is how reasoning about programs scales. That is how writing programs in the first place scales. That is how anything at all scales. Some suggested musings: "Rome is not built in one day" or whatever the proverb's wording is. Intelligent Design vs Random Mutation. Is your program invented or discovered?