When I'm trying to understand foreign code in less than enough time, I instrument it (almost always at inputs/outputs) and try to treat functions as black boxes. In an ideal world the black boxes would be working.
Data flows are as important as algorithms. See this thing from Guy Steele.
Fred Brooks, in Chapter 9 of The Mythical Man-Month, said this:
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."
That was in 1975.
Eric Raymond, in The Cathedral and the Bazaar, paraphrased Brooks' remark into more modern language:
"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."
That was in 1997, and Raymond was discussing a project coded in C, a procedural language. But for an object-oriented language, I think this aphorism should be reversed, with a twist:
"Show me your interfaces, the contracts for your methods, and I won't usually need your field declarations and class hierarchy; they'll be irrelevant."
I think, however, that practitioners of both procedural and object-oriented languages can agree on Raymond's related point:
"Smart data structures and dumb code works a lot better than the other way around."
"Smart data structures and dumb code works a lot better than the other way around."
An interesting assertion. In your link Guy Steele observes the duality between objects (where it's easy to add new data types but harder to add new operations that work on all of them) and abstract data types (where it's easy to add new operations but harder to add new data types).
Guy says that the former tradeoff is almost always the right one, but I've encountered many situations where the latter was much more convenient. It's far more preferable IMO to be able to choose which tradeoff you prefer based upon the constraints of your particular problem.
This usually is not so much a language-level problem as a cultural problem; many programmers are infatuated with OO (I know I was at one time) and unaware of the tradeoffs OO makes or when it's appropriate to use another approach. Hopefully over time multiparadigm languages like Python will help make "objects vs ADTs" more of an engineering question and less of a religious one.
When I'm trying to understand foreign code in less than enough time, I instrument it (almost always at inputs/outputs) and try to treat functions as black boxes. In an ideal world the black boxes would be working.
Data flows are as important as algorithms. See this thing from Guy Steele.
http://dreamsongs.com/ObjectsHaveNotFailedNarr.html
In particular:
Fred Brooks, in Chapter 9 of The Mythical Man-Month, said this:
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."
That was in 1975.
Eric Raymond, in The Cathedral and the Bazaar, paraphrased Brooks' remark into more modern language:
"Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious."
That was in 1997, and Raymond was discussing a project coded in C, a procedural language. But for an object-oriented language, I think this aphorism should be reversed, with a twist:
"Show me your interfaces, the contracts for your methods, and I won't usually need your field declarations and class hierarchy; they'll be irrelevant."
I think, however, that practitioners of both procedural and object-oriented languages can agree on Raymond's related point:
"Smart data structures and dumb code works a lot better than the other way around."