Years ago I worked for a company that sold computers, software, terminals and many other things. A terminal salesperson worked out of the same office I did and as a result we often got the latest and greatest terminals to use. This was the era of “dumb terminals” connected to mini computers or mainframes some distance away. There were no graphical user interfaces. One day we received some new terminals that had keys that were programmable. I promptly programmed them to issue the most common commands that I would otherwise have had to enter letter by letter. My co-worker called me lazy. I told her I preferred to think of it as efficient. I thought of that when I ran into this quote attributed to Bill Gates.
Yesterday one of my students asked me why someone would use Select/Case rather than If/Than/Else. A fair question. Many things can be done using either construct. I suggested that they use which ever one was easier for the specific task. Easier to set up; easier to understand (usually the same thing) and easier for other people to modify. A set of nested If statements can get very confusing very easily. A Select/Case is often ideal for handling a menu of options. If/Than is usually less work to set up for a small number of items.
It also depends on the language. I find the Select/Case options much more powerful in Visual basic than the equivalent structure in C#. Some things that are easier to do with Select/Case in VB are easier to do with If statements in C#. There are few absolutes.
Looking for the easy way to solve a problem is something that comes second nature after a while. For example when debugging I start by asking myself “what is the easiest thing to fix that might take care of this problem.” But it has to go beyond that. We have to look at what is easiest for most problems we solve with computers.
I remember a bunch of years grading the APCS exam. One student had written about 10 or 12 lines to solve a particular question on the exam. It took me quite a while to figure out what was going on and the student eventually did get credit for a correct answer. The issue was that the canonical solution was one line – a simple return statement with a value was all it really required. I’ve long wondered why the student thought he (or she) required a lot of code. Did they think that perhaps a single line answer was too easy for an AP exam? I’ll never know. But maybe they would have saved a lot of time looking for a simple answer. It’s not lazy – its efficient.
2 comments:
I have the lazy part down pat. Now if I could just find those easy solutions. Every now and then I work on a Project Euler problem. Usually I have to eventually cheat and Google the answer. There are a lot of really lazy people out there.
Laziness (or "conservation of energy for more important tasks") can drive a person to look harder for patterns, to reduce the number of special cases. It's a critical trait for a programmer!
I once had a young student who immediately plunged into coding a bunch of individual cases, without ever stopping to think about how a problem might be summarized. Naturally, when another situation needed to be programmed, he created another line or block of code. He was a hard worker and had a very pleasant attitude -- never whined that something was "too much work" -- but a bit more impatience might have served him very well.
Post a Comment