Additional profile information on Alfred Thompson at Google+
This is the fifth of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.
To many Construct the program in logical units seems pretty logical (no pun intended). After all what is the alternative - illogical units? But at the time the book was written huge monolithic programs were common place. A lot of beginners still code the same way today though. The way to understand this proverb is the understand that by "logical units" what is meant is a lot of units that are logically complete and relatively independent.
A logical unit handles a set of logic, instructions for a single purpose, that is small and easy to understand. The standard I have heard is that a unit should fit on one page of paper. Some would say one screen. Traditionally a sheet of computer paper back in the line printer days was 66 lines. The traditional screen held 24 lines. Today of course with screens coming in all sorts of sizes and fonts allowing us to get a lot on a piece of paper these sorts of arbitrary line counts don't make much sense.
Think about is as the amount of code one can look at and keep in ones head at one time. Could you, after spending a small amount of time reviewing the code, reproduce it from memory? If not it is clearly too long. To really understand and debug (or better yet make sure there are no bugs before actually testing it) you have to be able to get it really deeply into you head.
A logical unit should do one thing and do it really well. It should be easy to understand so that if it needs to be changed or debugged someone new can look at it and understand it in totality. The last thing one wants to do is guess what is going to happen. Not a problem in a reasonably sized logical unit.
Mark Guzdial (CS Faculty at Georgia Tech) had a recent post about Information Technology students not studying data structures. Frankly it blew my mind. Data structures is such a fundamental aspect of computer science and information technology that I find it hard to understand students skipping around it. It's not like it is hard really.
The Advanced Placement AB exam covers a lot of data structures. That is in fact the larger part of what makes the AB course more involved than the A course. High school students can and do grasp these concepts. So what is the excuse for university Information Technology students not studying them? This I have trouble grasping.
Computer science is more than just programming but data structures, while on one level is real computer science, is so basic to professional programming that I think a programmer would be seriously handicapped without some knowledge of it. I think that all programmers should at least know how linked lists, trees, queues and stacks work. It's really about a way of thinking as much as using the specific structures.
What do you think? Does every programmer need data structures or can someone who is an Information Technology major get by without them?
The IEEE History Center announced recently that they have added 75 oral histories to their collection.
There are interviews with all kinds of engineers and not just computer or Internet related people. Anyone interested in the history of engineering will likely find this collection of interviews of value. It is not just American engineers either. There is a while collection of interviews (in English) with Japanese engineers.
On the computer and electronics side though there are interviews like Robert Noyce talking about the events that led to his development of the integrated circuit. Wm. Ross Aiken talking about the invention of the CRT (Cathode Ray Tube). Vinton Cerf talking about the ARPANET and the origins of the term "Internet." And many more.
This looks to be a link that students doing research papers or just learning about how we got where we are would find useful and helpful. Just the thing to bring up during National Engineering Week too!