All, or almost all, of us who have taken Algebra level math or higher know that, as the levels progress, the allowance for calculators increases. For grade school math through Algebra, I was not allowed to use a calculator (in Algebra, an exception was made for trig functions, but that was it), but the math had to be done by hand. The reason is obvious: if you have to do it yourself rather than punching it into the calculator, you will learn the concepts not the operation of your new Itanium TI-7819922-ZETA. In Calculus and Physics, we were allowed to use more powerful calculators. Each step of the way, the emphasis was on learning how to do the math and  the calculator was a tool. The problem with the calculator as a tool is that it can do several levels of the math before it. This is a real time saver if you know the work that the calculator is doing, but a reliance on it can destroy your understanding of mathematics if you allow the calculator to do your work for you.

Why am I bringing this up? Have I had a sudden, wonderful burst of nostalgia? No, I've been doing some contracting work with the wonderful ASP.NET controls made by Telerik. They really are good components and, for many features can slice development time. "Great," you're asking, "what does that have to do with calculators?" Just be patient, I'm getting there. What I noticed about the documentation for Telerik's controls was that a lot of information and "Quick Start" information is given in terms of using Visual Studio's form designer. Now, to their credit, the raw classes and tags are there, but the emphasis, as with many texts, is on using the pretty GUI tools. This got me thinking about what Visual Studio is. It is a wonderful tool and, like Telerik's controls, can be used to shorten development time, particularly on large projects. The problem is, however, the people who use VS without fully understanding what is going on under the hood. What code is being generated, what techniques are being used. I'm sure we've all seen code where things were labeled TextBox1, Button2, etc. Usually, I've found is that the people who leave those names in tact are the ones who do not really muck around in the code. They try to cobble visual data sources to visual controls, writing as little code as they can possibly get away with. The result is, of course, bad code. It is analogous to the person who survived algebra by punching numbers into his calculator. He moved on from one level to the next, but he never really understood the concepts involved. In this sense, Visual Studio is like a calculator: a timesaver for the adept, and a pitfall for the novice.

I am not saying that Visual Studio is bad or shouldn't be used any more than I would say that a calculator is bad and shouldn't be used. The final point is that Visual Studio, and tools like it, need to be used in their place. And they should never, EVER be used to teach the concepts.