Lack of Standards Lessens .NET's Appeal

The last decade has seen software companies attempt to foster sales by producing new products that make the earlier versions obsolete. Some say this approach will be their downfall.

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 editor@visualstudiomagazine.com.

Lack of Standards Lessens .NET's Appeal
In the Guest Opinion, "Save the Hobbyist Programmer," Kathleen Dollard wrote about the need for a simple language for hobbyists/part-time programmers [April 2004]. I"VS.NET Needs a Novice Version," Patrick Meader wrote about the need for a novice version of VS.NET [June 2004]. This issue has arrived because of the evolution of languages and the software industry. The intent was to foster sales by producing a new product and making the earlier version obsolete. Microsoft (like other vendors) even went so far as to drop technical support for the older versions.

Compare this to the old software language model where languages were standardized (such as Fortran 77). Companies, such as IBM, made money not by selling the language, but by selling the compiler (or interpreter) for the particular platform. In some cases, they also made money by promoting add-ons and tool sets. In the old model, the language was—more or less—in the public domain. The language was promoted by many hardware vendors, software vendors, and solution providers.

This latter model fostered buy-in by the post-secondary education system. Languages were standardized, and therefore programming could be taught without visible connection to any particular software or hardware vendor. There was some understanding that the language was pervasive and would remain so (for example, COBOL).

In the 1990s, we saw the emergence of software houses attempting (to varying degrees of success) to assume control over languages. Whereas various C and C++ compilers had been popular in the '80s and '90s under the old model, this would not work for the new model. Hence, Microsoft started developing C#, which, not surprisingly, works exclusively in the Windows platform environment.

The new model is self-defeating. The lack of standards in this field can be devastating in both the economic and the management sense. As an analogy, imagine the automotive industry where the car manufacturers indicate that they will no longer service the 1994 models, and that the new 2005 models will require a different form of fuel and new tire sizes (so don't bother saving your old ones).

Back to the novice or part-time programming issue: In the '80s, Basic (GW-BASIC and all its other forms) provided this service. The late '80s and into the '90s, we had the XBase languages (Clipper, FoxPro) and the C/C++ languages. After that, the model changed. Proprietary interests trumped standardization. One can even see this in the Java language, which, in my opinion, should have been the next step in evolution. Instead, we saw vendors attempting to control the language and its evolution to their own ends.

We now have a void. No current language fits the novice or part-time programming requirements. The current software language model is not conducive to such change. Will it ever be resolved? Probably not until the fiscal situation with the vendor(s) changes.

As for me, I will not migrate to VB.NET. I have written a few million lines of XBase code and a few million lines of VB5/VB6 code. Even so, I would categorize myself as a part-time programmer—my main employment is network and DBMS administration. There is no compelling reason for me to upgrade to VB.NET; the costs are not justifiable. VB is supported only on the Windows platform. I, like many of my peers, work on a variety of hardware/software platforms. I would like to have tools that work on the widest possible area; I attempt to avoid restrictive ones.

Frank Molnar

About the Author

This story was written or compiled based on feedback from the readers of Visual Studio Magazine.

comments powered by Disqus
Upcoming Events

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.