Jim Blizzard wrote, noting that these were this thoughts and not those of Microsoft.
...I hope this isn't the start of another write once / run anywhere push. The Java crowd lives with this all the time and it turns into the now-famous tag of write once / debug everywhere. And it can lead to some pretty disappointing application performance.
It's a noble goal - to run anywhere. But is it reality? A Linux "version" of .NET. An HP-UX "version" of .NET. A Solaris "version" of .NET. An AS/400 version of .NET. The Windows(TM) version of .NET.
If this is to happen it has to happen right. And there aren't any public (or private that I know of) plans to make this happen right.
It would be a shame to see developers hobble their .NET applications to the least common denominator.
Do you really want to go there?
Jim, yes, I really do want to go there, and I agree that must it done right. "Right" must be an open, shared and fully committed to process to succeed. It must occur at all levels. The noble goal must be encouraged and fostered through-out the environment. So when you frame this as "hobbling" strikes me as doing anything but that. It offers reason and justification to not seek the noble goal.
Consider that the CLR already is running on multiple different Operating Systems: they just all happen to come from Microsoft. Consider what pain we avoid by writing CLR-based applications (w/r/t unmanaged code) when porting 32-bit code vs. 64-bit code. The write once/run anywhere goal is an inherent strength of the CLR, not a weakness. The same applies to the compact framework code. Would you call a Compact Framework application "hobbled" compared to WinForms application? I wouldn't, nor would I say that the PocketPC is "hobbled" relative to the full client PC. Comparing their abilities relative to each other shouldn't be the issue: comparing them relative to the goodness of fit to the problem to be solved should be. If the shoe fits, wear it.
Its great that we have a hardware abstraction layer with the OS and CLR together. This allow us to use the same tools and techniques more or less regardless of this problem. The CLR has been a great success at hardware abstraction. At the same time, the CLR has tremendous potential to continue to act and evolve as an OS abstraction as well layer. That's what we should be championing.
The roadblock -- as I see it -- is that totality of .NET isn't OS abstracted enough. Any implementation specific forks in a CLR are poison. But so are having IP barriers (real or not) when implementing CLRs and BCLs. Anything that limits a consistent implementation of the full value of .NET impairs its path toward ennoblement.
I am a Windows bigot. It is the OS of choice in my world. I appreciate that others have a different reality. .NET is potentially an outstanding medium for us to materialize our work in each other's worlds.
We must not see the noble goal with "win-lose" at a technical level and allow that to discourage us. Performance is not the only metric of success. The noble goal is the ultimate win-win at a much higher level.
Ugh, my laptop battery was dead, so I had to break out a real notebook at breakfast. You wouldn't really think that would make a difference, but it does...
- What do you think of GeoCode/GeoURL/LoaclFeeds -- assuming they come back? If so, why? As part of the redesign of HDRinc.com, I'd love to see us use this techology more, considering we're a national firm with a strong community involvment preference.
- Ever tried creating an expando (drill down) report in Reporting Services without using the wizard?
- When the B2 bits of Yukon ship, we really need to talk about the building in encryption of data types.
- Dave did a bang-up job with Indigo last night and Mike's afternoon MSDN session was excellent. I'm way beyond happy with the turn out both events had.
- The copy of Visual Studio Enterprise Architect we had the user group drawing went to Student. Another soul saved from WebMatrix.