What really matters is whether you understand and work with a subroutine as a single thing or a composite unit. Again the rule that each layer should have a limited complexity is justified in terms of the sliding scale of the fundamental unit of comprehension. We use hierarchies to manage complexity so that each level in the hierarchy is as simple as the next, as long as you are working with the correct unit of comprehension.
There is another more subtle problem. The unit of comprehension can change with time and who exactly is doing the comprehending. When you write a small chunk of a program you are on top of it all and your unit of comprehension might be very large – it all seems so simple that you can keep in mind many more instructions than seven. But when you come back a few weeks later your unit of comprehension has shrunk. Now it would be better if the routine consisted of just seven lines of very simple code.
When you are writing programs you are an expert – when you come back and read the same programs you are a dummy.
Top-down programming is just one example of a hierarchy in programming. They are used to organize things so that you can easily get a view of the level that you are interested in. The details of everything below is hidden and just assumed to work. It is this “detail hiding” that make hierarchies so useful in simplifying things – they contain all of the details but let you zoom out for the 1000-foot view and then drill down to the minutia as you please and as suits your level of understanding. They are not perfect but they are the best complexity hiding mechanisms we have.
Summary
Getting started on a project is always hard. The top-down approach makes it easier.
The top-down approach works by assuming that you have the subroutines needed to solve the problem at each level. You simply make use of subroutines that do not exist yet.
As you create the subroutines that you used at a particular level you create a new level which in turn may use subroutines which do not exist yet.
This results in a hierarchical solution to the problem with subroutines at each level becoming more specific.
There are problems with this approach. In particular you can get stuck and be unable to move forward because you cannot implement a subroutine. In most cases the top-down approach at least provides a way of discovering these difficulties.
The alternative approach to top-down is bottom-up and, while this sounds like a wasteful and undirected way to work, having a library of useful subroutines often does make a problem easier.
At some point in the top-down hierarchy, subroutines have to start to do things more than just call other functions.
The question of how small a subroutine has to be to be understandable is important. The magical number seven gives us a rough idea of the complexity that a human can handle and it is a guide for the best size of subroutine in a hierarchy.
More accurately a human can handle seven chunks or units of information at a time and the size of a chunk varies according to the level in the hierarchy.
A human can handle roughly seven things at a time, but it all depends on what the unit of comprehension is and this varies with time.
Hierarchies are the best mechanism we have for hiding complexity using layers each of which keeps the unit of comprehension to around seven items.
The Trick Of The Mind - Programming & ComputationalThought
The SIGBOVIK conference has just finished and its proceedings can be downloaded, but only at your peril. You might never see computer science in the same way ever again.
There are many reports that Google has removed people from its Python, Dart and Flutter teams and possibly more. What does this say about relying on Google as a source of technology for your projects? [ ... ]
