Back to the Future

Does it make sense to learn the intricacies of code today that might become obsolete or change significantly tomorrow? It depends, say readers.

• By Readers of Visual Studio Magazine
• 01/01/2005

Letters to Visual Studio Magazine are welcome. Letters must include your name, address, and daytime phone number to be considered for publication. Letters might be edited for form, fit, and style. Please send them to Letters to the Editor, c/o Visual Studio Magazine, 2600 El Camino Real, Suite 300, San Mateo, CA 94403; fax them to 650-570-6307; or e-mail them to [email protected].

Back to the Future
Regarding Patrick Meader's Editor's Note, "It's Only Code" [December 2004], I think the key to better understanding change in technology as it relates to coding protocol resides in one word: qualify.

The reader gets a better sense of the technological landscape if technology writers qualify what they're writing about in relation to the technology profiled. However, qualifying topics in a general fashion is not enough—authors must qualify them specifically. For example, when explaining the coding protocol necessary to create autocomplete functionality in a combo box, an author should note clearly and concisely that VS 2003 coding protocol differs significantly from that of VS 2005. In VS 2005, autocomplete represents a property attribute of the combobox control, and as such, changes the nature of how it is called and coded. In VS 2003, you must create autocomplete code; in VS 2005, you can call it. Profiling these specific distinctions in code allows readers to make an informed decision on what code is important to learn based on subjective priority.

Does it make sense to learn the intricacies of code today that will become obsolete or change significantly in coding protocol tomorrow? The answer to that question depends. Is the reader just curious about the upcoming version of software, or is he/she relying on the article's information to develop functionality in a client's application today?

Reader priorities for knowledge are varied, and writers should be sensitive to this dynamic if the objective is to convey information of interest to readers. This is especially important when you consider what Microsoft has been promoting in VS 2005. Among several promotional points, one of the most salient involves the claim that VS 2005 requires 50 percent less code to accomplish the same thing you could do in VS 2003. After evaluating VS.NET 2005 beta 1 myself, I must say this claim appears to have substantial merit.

By qualifying the technology while articulating points clearly and concisely, not only will technology articles be poignantly challenging to write, but they will be fascinating to read as well.

Brice Richard, Washington, D.C.

I'm a departmental programmer and an MCSD using VB6, and I'm glued to my desk all day. I dutifully read articles about .NET and study on the train and at home when I can (there's no time for training at work—I've got deadlines). I'll ignore Longhorn and Whidbey until they're out for a year or more. I work at a major financial company, which is only about 20 percent converted to XP from Windows 2000. Our laptops should be converted from NT by the end of the year.

At home, I'm renovating our kitchen, but I'll be watching the Yankees play the Red Sox tonight instead. We're going out with our neighbors this weekend. I'm afraid real life gets in the way of learning new technology. And there's no time for vaporware in my schedule. And sometimes the new technology isn't as good as the old. I thought DAO was great. The exalted flat object model of ADO didn't impress me, and it made my programming life more difficult. ADO.NET's return to a bloated object model impresses me even less. I'll continue to use DAO if it gets the job done.

Has anybody been able to read the 9/11 Commission Report and read about Whidbey too? I think I've got my priorities straight. Whidbey and Longhorn don't make my list.

John Procyk, Hoboken, N.J.