Digital Edition

More "Doubletalk" from Microsoft, Claims Simon PhippsA corrective to all the hype about C#
More "Doubletalk" from Microsoft, Claims Simon PhippsA corrective to all the hype about C#

Does the move of C# to ISO really make a difference to programmers, or is it just a sign of continuing intense competition in the software tools market?

When Gavin Clark, of the news agency ComputerWire, heard that Microsoft plans greater adherence to ISO/ANSI standards in the upcoming release of Visual Studio.NET (codenamed "Everett" and due in the first quarter of 2003), he was quick to investigate the story by consulting with various Internet gurus-including Sun's Simon Phipps.

In today's JDJ Industry Newsletter, Phipps sets the record straight a little, feeling that he was somewhat misrepresented in Clark's final account. We stress that he is writing in his personal capacity.

(October 25, 2002) - I'm quoted by Gavin Clark of ComputerWire in his item (syndicated by The Register) about the standardization of Microsoft's C# programming language and their moves to make their C++ compiler catch up with the standards a little. My remarks there were a little truncated and consequently unclear, so I'd like to elaborate a little.

My observation was that programmers don't typically use languages to create software. They use programming languages to weave together library calls to create software. Consequently, a programmer's marketable expertise is actually in their skill with the libraries they use to create software-the programming language with which they do so is relatively unimportant. Programmers seeking to build with the Java class libraries can use the Java language, or Jython, or NetRexx, or indeed any of the 160 systems that target the Java virtual machine. Programmers using the UNIX libraries have a similar choice; programmers using Microsoft's MFC libraries a smaller set of choices; those using Microsoft's new .NET framework a similarly small set. Of course, in typical form, projecting weaknesses and engaging in doubletalk, the small range of choice is portrayed as a large one...

So what does language standardization buy us? Well, it means that we will have a basic familiarity with the programming languages we find variously implemented. But beyond that, I would suggest it doesn't buy us much. What brings value is library stability. The Java environment achieves this by the oversight of a very good standards body, the Java Community Process. UNIX achieves it via the Open Group. But what about Microsoft? Their libraries come with no promise of stability as no one but them gets a vote. Indeed, their switch from MFC to .NET Framework is probably the reason for their new-found interest in language standards. Talking about "language choice" and "language standards" is all fine rhetoric, but what programmers really need is library stability. Perhaps it's embarrassment over that which is creating the new language fervor in Redmond, to blow a smokescreen over the retraining VB and C++ programmers are facing?

About Simon Phipps
Simon Phipps, Sun's Chief Open Source Officer, is a technology futurist and a well-known computer industry insider. At various times he has programmed mainframes, Windows and on the Web and was previously involved in OSI standards in the 80s, in the earliest commercial collaborative conferencing software in the early 90s, in introducing Java and XML to IBM, and most recently with Sun's launching Sun's blogging site, He lives in the UK, is based at Sun's Menlo Park campus in California and can be contacted via

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

In these discussions, I think it's silly to place so much emphasis on the languages per se...especially in a mutually exclusive X vs. Y context. A programmer might be working in a shop that is geared toward Microsoft or another toward Open Source or whatever. I think the idea is to choose the right tools for the job. I work in a shop that uses both and I have reasons for choosing one over the other depending on the situation. They are all powerful weapons in my programming arsenal that increase my versatility and effectiveness. For that same reason, I would be disappointed if any of them were taken from me for whatever reason. To pit languages and libraries against each other is kind of ridiculous. Those aspects of the debate are what you might consider the "implementation details" of the problem. It's the malevolent practices of certain prominent software corporations that should be maligned and not the languages. In any case, maybe it's the programmers that need to platform independent.

Microsoft's move to standardize C# probably has something to do with the Mono project ( They have implemented a C# compiler on Linux and are working on the class libraries to have a complete implementation of .net that's open source and works on Linux, Darwin, etc.

What is important or even significant about Microsoft standardizing a language in which they are the only suppliers? Standardization was to set a standard for multiple compiler writers to adhere to.

It seems more like a marketing gimic to me.

While stability of "standard" libraries are important, what language you use to program in is also very important and varies based on application. The expressiveness and utility of a language for the task at hand truly impacts the quality of the design, the efficiency of execution, the ease of maintainability, as well as portability. Having stable standardized libraries available to me only makes me more productive since I do not have to re-invent the wheel at every turn. On a single platform, these libraries are usually available no matter what language I choose. However, the choice of language gives me many design and implementation choices which have a far greater impact on an application than do ready-made libraries.

To David Avraamides: "language neutrality" in .NET is strictly a PR stunt by MS to try to sway programmers away from Java. The CLR, for all intents and purposes, is a C# runtime environment. All non-C# languages supported in .NET are all bastardized versions of those languages ... because those languages generally have features which the CLR does not support, or lack features which the CLR does support. In particular, VB.NET is effectively an entirely different language from the previous VB.

To Thomas Auzinger: the lure of "reuse" to which you so fondly refer is a mirage -- yet another media hype by MS. Not only will you have to change your existing applications to call .NET functionality, you will also have to completely rewrite your applications because the .NET version of your language is different from the previous non-.NET version.

I believe MS's push for language standards in their C++ is more PR than anything else. They know that the primary language which will be used for .NET applications is C#. Why not invest in a little positive PR by making it look like MS is finally moving towards public standards? The bottom line is that the libraries in .NET which will be essential for enterprise solutions will remain proprietary and tightly under the control of MS ... the only part of .NET which is being standardized is C# and the CLR (which is only the C# language runtime, not all the support libraries that define .NET).

Programmers, er...class-lib/API technicians, are in the same boat as all technicians regarding the use and improvement of their tools-of-the-trade.
As I see it, the standardization issue for the tool makers ultimately comes down to marketability and their fundamental product strategy.
Obviously the primary goal for tool makers (Microsoft, Sun) is profitablity, but how that is played out in their product strategy reveals their perception of the marketplace (i.e. toolusers) more than anything else.
While almost everyone can agree that there should be toolset improvements, that's where the agreement ends. What those improvement are and ultimately who decides what really "improves" a there's the rub. Whether its APIs, class libs or programming languages, the issue of standardization within the user community is viewed by toolmakers for the most part as just another mental exercise.
More important to me than the exact meaning of standardization is whether standardization will ever become a fundamental purchasing determinant. If we can agree that standardization is a MUST-HAVE and it becomes a predominant market driver, I think we would be amazed at how quickly MS would embrace "open" standardization. Then the discussion of what standardization means will have relevance....

The "small choice" that Simon mentions is not quite accurate. What comes with .NET is the ability to interoperate with COM, DLLs, or any native code in a type safe manner, without having to worry about bending a pointer or crashing the runtime.

This allows programmers to integrate thousands of existing Windows application without the usual burden. Think RMI for Windows with JNI performance (in a nutshell).

Java on the server side is not going to go away overnight, but it no longer has the monopoly of being the only modern industrial strength OO language around. It would be a mistake to underestimate the effect that this interop feature of .NET has in terms of facilitating reuse at an unprecedented scale.

P.S.: I've done Java since '96, threw out my C++ books, and refused until recently to touch anything that had Microsoft on it.

This article is crap.

This, along with the "Microsoft killed Java on the desktop" article, are making me lose complete faith in the Java Developer's Journal.

Is this magazine about Microsoft or about Java?

Get serious, guys.

The article has some good points. However, I still struggle with the comparison of .NET to Java. A comparison of C# to Java is definately in order, but any company or person evaluating .NET should compare it to J2EE and the many alternatives and tools for building XML-based B2B that is what .NET is targeting. As J2EE provides flexibility and really a market of tools...those represent choices the developer must make. DotNET on the other hand provides a single solution with very good tools and lots of marketing. The initial surge of .NET into enterprise projects can be contributed to its availability and discounting. It's longevity will depend on how much of the corporate development problem space it addresses well, and the long-term costs of choosing that technology including dependence on the windows platform. As far as C# appears to be a Java knockoff with no real value over Java. If Microsoft were really in the game to provide value they would have built .NET on top of Java instead of spending efforts to produce yet another language whose purpose is to control marketshare.

That's my take anyway.


Simon's point can be taken one step further. A programmer is not only defined by what he knows and how he uses it, but the effectiveness of the program is often gauged by the longevity in the industry. Changing libraries or interfaces kills off functioning programs, or incurs huge portation costs. This inhibits a solid foundational growth based on past knowledge. While some may argue that certain programs deserve to be killed off, we find we are often re-inventing the wheel.
The strength of Fortran'68 or 72, Lisp, Cobol, C, C++, Ada, or Java is its consistancy. My worst programming days were spent figuring out the differences between ANSI C and GNU C. I would rather be working on solutions, not portation. When a language is religiously protected and starts to blosom into an environment - then programming may move into higher forms of abstraction.

The heart of this deals with having to rewrite software before being able to enhance it with newly available API features. Community controlled APIs tend to stay more backward compatible. It puts first the interest of the community--the developers. When existing APIs are changed you must revisit/rewrite code that is working, maybe quite well, before you can move forward. Not that rewriting (aka. refactoring) is bad in and of itself, but it certainly doesn't make sense if it's because of arbitrary changes made by someone else.

I don't think the article is misleading. Dot-Net is another API from MS. Java in it's basic version is a single API ... and always has been. What the JCP does is provide a bunch of APIs like EJB, Servlet, JNDI etc.

ISO committee stuff is a bit like, so what to me. Do you still program in ANSI C?

Language independance is no big deal. Teaching OO concepts to a VB programmer is much harder than teaching Java syntax to a C++ programmer.

Phipps is misleading readers by glossing over a couple of important details: He claims that there are "160 systems that target the Java virtual machine" and for .NET a "small set" of choices. But .NET was architected to be more language neutral than Java and specifically designed to support the most popular langagues like C/C++, VB, Fortran, Perl, Smalltalk and yes, even Java. Although there are non-Java tools that can be used with Java, the ones that most people want to use - C/C++ and VB/COM - are not directly supported and overly complicated to integrate with.

Furthermore, not only has Microsoft submitted C# to an industry standardization committee, but more to Phipps' point, they have also submitted the CLR (Common Language Runtime) for standardization, which is the set of APIs that really define .NET.

Java has a lot of great things going for it - enough that people don't need to make things up about the competition to make it look better.

Simon's point is not about cross language use of libraries. Rather it is about the stability of the libraries. The Java API's are "governed" by the JCP, Unix is "goverened" by the Open Group but the MFC, .Net and Win32 APIs are "governed" by Microsoft and Microsoft alone. If someone want to change the Unix or Java API specs they can't do it alone. However if Microsoft decide to change/add/delete any of their APIs noone get to say "Hey! hold your horses!"

Sure, the libraries are important, but most libraries are tied to the programming language. My Java doesn't make use of those nifty Unix libraries (at least not without the headaches of JNI) or the .NET framework, and I'd guess that C# won't call Java libraries.

So, first the language needs to be standardized, and the libraries should as well. If MSFT doesn't standardize the libraries, then I agree as those are the real key to an application and it's a huge pain to deal with changes to a library.

Subscribe to the World's Most Powerful Newsletters


The explosion of new web/cloud/IoT-based applications and the data they generate are transforming ou...
CI/CD is conceptually straightforward, yet often technically intricate to implement since it require...
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple ...
Enterprises are striving to become digital businesses for differentiated innovation and customer-cen...
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As au...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't com...
The now mainstream platform changes stemming from the first Internet boom brought many changes but d...
DXWorldEXPO LLC announced today that All in Mobile, a mobile app development company from Poland, wi...
DXWorldEXPO LLC announced today that Ed Featherston has been named the "Tech Chair" of "FinTechEXPO ...
Chris Matthieu is the President & CEO of Computes, inc. He brings 30 years of experience in developm...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: D...
Andi Mann, Chief Technology Advocate at Splunk, is an accomplished digital business executive with e...
In this presentation, you will learn first hand what works and what doesn't while architecting and d...
The Internet of Things is clearly many things: data collection and analytics, wearables, Smart Grids...
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitori...
We are seeing a major migration of enterprises applications to the cloud. As cloud and business use ...
If your cloud deployment is on AWS with predictable workloads, Reserved Instances (RIs) can provide ...
Disruption, Innovation, Artificial Intelligence and Machine Learning, Leadership and Management hear...
We build IoT infrastructure products - when you have to integrate different devices, different syste...
Consumer-driven contracts are an essential part of a mature microservice testing portfolio enabling ...