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 [email protected].

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

Featured

  • AI for GitHub Collaboration? Maybe Not So Much

    No doubt GitHub Copilot has been a boon for developers, but AI might not be the best tool for collaboration, according to developers weighing in on a recent social media post from the GitHub team.

  • Visual Studio 2022 Getting VS Code 'Command Palette' Equivalent

    As any Visual Studio Code user knows, the editor's command palette is a powerful tool for getting things done quickly, without having to navigate through menus and dialogs. Now, we learn how an equivalent is coming for Microsoft's flagship Visual Studio IDE, invoked by the same familiar Ctrl+Shift+P keyboard shortcut.

  • .NET 9 Preview 3: 'I've Been Waiting 9 Years for This API!'

    Microsoft's third preview of .NET 9 sees a lot of minor tweaks and fixes with no earth-shaking new functionality, but little things can be important to individual developers.

  • Data Anomaly Detection Using a Neural Autoencoder with C#

    Dr. James McCaffrey of Microsoft Research tackles the process of examining a set of source data to find data items that are different in some way from the majority of the source items.

  • What's New for Python, Java in Visual Studio Code

    Microsoft announced March 2024 updates to its Python and Java extensions for Visual Studio Code, the open source-based, cross-platform code editor that has repeatedly been named the No. 1 tool in major development surveys.

Subscribe on YouTube