On interoperable and portable environments

or, as Chris over at hpcanswers.org asks, Why did Microsoft release C#?
And what has this got to do with HPC? Quite a bit. Call it an opportunity that is currently in the state of being missed by the maker of C#. More about that in a moment.

Chris postulates

that C# is a way to have more developers build software for Windows, and thus generate greater customer demand.

Possibly, though I think it is a bit more complex than that. Basically my take on things is that the whole Java fiasco hurt Microsoft … not technologically, not in a market sense. More along the lines of an “ego”, if one can ascribe such a thing to a corporate entity. They tried embrace and extend with Java and surprise, Java revealed itself to be the marketing “gimmick” that it was. Basically my take is that Microsoft was burned with Java.
Microsoft did not have a real response to Java, though to be honest, I am not at all convinced it really needed one. Java claims or has claimed to be write-once-run-anywhere. This is unfortunately not even close to accurate. You can only do this on Sun-blessed platforms. Which means any non-blessed platforms might not work. That is, though Java purports to provide an open platform, it is in fact a closed and tightly controlled platform. To this day (and please correct me if I am wrong), I cannot get a modern up-to-date Java for our Itanium2 box, or for our old (and now defunct) Irix box. This isn’t from a lack of interest of users in such boxes, it is because Java has been used as a marketing tool for OSes and machines that Sun wished to sell. Java is a Sun brand.
There is nothing wrong with Java being a Sun brand. It is just not a cross platform development technology as it has been touted.
So here we have one annoyed Microsoft and this Java bit. Microsoft responded with something that looked a great bit like Java, but wasn’t. They fixed lots of warts, and did some other things. It is still IMO far too verbose for my tastes. But they controlled it. And offered it as an alternative to Java. And built a marketing and branding program around it (.Net). Soon everything was .Net. Apple came out with .Mac. The GNU folks came out with .Gnu. The marketing and branding world was beset with “dot-something.or.other”. That is, apart from Mono.
Mono sought to make an open and interoperable version of C# and .Net like components. This is the continuing saga of a missed opportunity. Sun was pushing Java hard, for everything. Including into spaces such as HPC where it really has no business. I can’t run Java on a Cray. Or on other large supers. But thanks to the open source nature of Mono, I can (in theory) run it on these platforms. At least it is some patches away from being useful, but it is available.
Sure, you can run gcj, and it kinda sorta works. Until you hit modern Java features. And then it kinda sorta doesnt. And yeah, you can have the same set of ugly Java windows on any supported platform. Seeing those windows, one wonders what sort of not-invented-here view the Java development groups had.
Back to C#. Through Mono, we can run it pretty much anywhere. That means C# programs can run on Linux clusters. On large unix supers. On any platform which has a successful build of C# through Mono. Same programs that run on windows.
Do you see the missed opportunity? Should be glaringly obvious. And it was the basis for my original thoughts on the best way for Microsoft to enter the technical computing market. C# can talk to all manner of windows apps. Which means that you can use it to glue apps together. Sort of like Perl can be used to glue apps together across many platforms. And to a degree like Python. But C# is the windows blessed method. So with C# running on a linux cluster, happily talking to and updating a nice excel spreadsheet, and other bits on a desktop …
Ok, I can do that today, for the most part in Perl. And possibly Python. While I like developing in Perl, it is not blessed by Microsoft as the glue code for their desktop. OTOH, the Gnome folks are using Mono based tools all over the place to glue bits together on the Linux desktop. Couple this with glue code running on the cluster … All you need is a Microsoft blessing of Mono (basically have it pass the regression tests) and suddenly you have a) an interoperable platform for Microsoft and Linux folks to deploy, b) a very low barrier on-ramp for Microsoft to enter into the large and rapidly growing HPC market, without trying to create their own as they appear to be attempting to do now, and c) Microsoft sort of removes the last reasons anyone might have for using Java. Multiple birds, one stone, nothing but up-side.
I am not betting on them to do this though. Because they wouldn’t be able to control it. And C# like Java is a part of the .Net brand. My gosh, what would happen if C# were suddenly interoperable across all platforms … why it would bring chaos. It would bring …. developers … and installed base … and …. revenue … and new platforms and markets with a better story than the existing incumbent ….
<sarcasm>Nah… too simple. Couldn’t work.</sarcasm>
.Net was born of a need to control a market. It was/is a brand. It has rapidly morphed into a platform. Not an open one. But it could be. Unlike the other “open” platform, this one could be viable in HPC and many other areas.
It won’t happen. Chris was right, though I think the rationale is more complex than suggested.
Maybe Ruby will run nicely everywhere and talk to everything. Runs great on windows and linux. Is open source. Easy to extend.

2 thoughts on “On interoperable and portable environments”

  1. I think anything is better than Java. I’m just glad that Microsoft is finally entering the HPC space because they can actually produce good development tools, even if they are proprietary. And you’re right, programmers willing to sacrifice a little performance for greater productivity would be better suited with Ruby.

  2. I was hoping that Microsoft would focus on the development tools/environment and help make that better/portable. Unfortunately this does not appear to be their strategy. They prefer the replacement approach.
    Productivity is important. I like gsl (Gnu Scientific Library) because it is easy to use. It is not particularly fast nor is it threaded, nor is it parallel (at last look). This is giving up lots of performance in the name of productivity, and given how we build machines to help people maximize performance and productivity, this is a … problem …
    But a solvable one.

Comments are closed.