current state of Microsoft .NET
[my rebuttal]
One assessment I agree with Mr. Grimes on is what a total waste of time VB.NET was. He was a little harsh on the size of the .NET Framework - for enterprise intranet rich client development it's no big deal to install 25 MB on the client workstation. I know one thing for sure - I'd much rather develop our rich clients using C# .NET rather than C++ and MFC/ATL.
He's also correct that WinFS was another MS misstep - just like the Object File System a decade before it. Google local search coupled to conventional file systems will rule. Turning the file system into one big SQL server storage system was a bad idea - chiefly because of the burden it places on developers to devise storage format concepts that accommodate this approach (and where's the ORM solution that eases all the pain?). And just how normalized will that storage be (and secure in an isolated sense)? Where's the crisp distinction of data borders that we have today with files?
The real problem with LongHorn is that it's so far behind the curve. On Mac OS X I'll soon be enjoying the Tiger release. Given the Mac's already existing easy-to-use advanced UI (with cool 3D effects) and the new Tiger features, LongHorn will be long preempted elsewhere before it ever sees the light of day in a shipping version. The next couple of years will be a wonderful time to jump ship from Windows to Mac - can you say "Mac Mini". (Now I can relegate my Windows boxes to being headless servers - the same way I use my Linux boxes. That way they can't cause me near so much pain and sorrow.)
And then on the server-side - well ASP.NET is pretty much a one trick pony. Not a very rich server-side development environment to work with there, alas. The puke of .NET Remoting or Web Services over HTTP - pick your poison. Yeah Indigo might finally provide a managed messaging implementation (just like ORM this is another feature of .NET that was axed back in '99/00 timeframe when I was still there), but Microsoft's idea of heterogeneous messaging is “between different versions of Windows”. The prominent JMS implementations will be over a half decade old in maturity by the time Indigo is shipping code. The leading JMS vendors are already heterogeneous in both programming language and platform that are supported for messaging.
Indigo as described would indeed address some of what is retrograde about ASP.NET and Web Services combo as they exist today (except that there’s still the issue of addressing transparent clustering for scaling and high availability - as well as replicating transactional distributed caching that will enable capitalizing on 64-bit address space and multi-gigabyte RAM in current generation servers). It is just that with the years of maturity of the enterprise Java platform, where all these capabilities already exist in spades, the question any responsible IT staff will ask is why put all of one’s eggs in one “Microsoft basket” - and for a set of technologies that are a year or much longer from being shipping code? Microsoft historically has done well with the mid-tier and lower-tier IT crowd of VB developers, but for really serious enterprise IT development needs they've always been a day late and a dollar short.
One assessment I agree with Mr. Grimes on is what a total waste of time VB.NET was. He was a little harsh on the size of the .NET Framework - for enterprise intranet rich client development it's no big deal to install 25 MB on the client workstation. I know one thing for sure - I'd much rather develop our rich clients using C# .NET rather than C++ and MFC/ATL.
He's also correct that WinFS was another MS misstep - just like the Object File System a decade before it. Google local search coupled to conventional file systems will rule. Turning the file system into one big SQL server storage system was a bad idea - chiefly because of the burden it places on developers to devise storage format concepts that accommodate this approach (and where's the ORM solution that eases all the pain?). And just how normalized will that storage be (and secure in an isolated sense)? Where's the crisp distinction of data borders that we have today with files?
The real problem with LongHorn is that it's so far behind the curve. On Mac OS X I'll soon be enjoying the Tiger release. Given the Mac's already existing easy-to-use advanced UI (with cool 3D effects) and the new Tiger features, LongHorn will be long preempted elsewhere before it ever sees the light of day in a shipping version. The next couple of years will be a wonderful time to jump ship from Windows to Mac - can you say "Mac Mini". (Now I can relegate my Windows boxes to being headless servers - the same way I use my Linux boxes. That way they can't cause me near so much pain and sorrow.)
And then on the server-side - well ASP.NET is pretty much a one trick pony. Not a very rich server-side development environment to work with there, alas. The puke of .NET Remoting or Web Services over HTTP - pick your poison. Yeah Indigo might finally provide a managed messaging implementation (just like ORM this is another feature of .NET that was axed back in '99/00 timeframe when I was still there), but Microsoft's idea of heterogeneous messaging is “between different versions of Windows”. The prominent JMS implementations will be over a half decade old in maturity by the time Indigo is shipping code. The leading JMS vendors are already heterogeneous in both programming language and platform that are supported for messaging.
Indigo as described would indeed address some of what is retrograde about ASP.NET and Web Services combo as they exist today (except that there’s still the issue of addressing transparent clustering for scaling and high availability - as well as replicating transactional distributed caching that will enable capitalizing on 64-bit address space and multi-gigabyte RAM in current generation servers). It is just that with the years of maturity of the enterprise Java platform, where all these capabilities already exist in spades, the question any responsible IT staff will ask is why put all of one’s eggs in one “Microsoft basket” - and for a set of technologies that are a year or much longer from being shipping code? Microsoft historically has done well with the mid-tier and lower-tier IT crowd of VB developers, but for really serious enterprise IT development needs they've always been a day late and a dollar short.
posted by rogerv at
12:14 AM
3 Comments:
Interesting turn of phrase at the end there. Though often many days late, MS never seem to be a dollar short, do they?
By
Joe Parks, at 3:24 AM
Hee, hee - yeah, "dollar short" is a poor metaphor for a deficient deliverable when talking about Microsoft.
By
rogerv, at 6:59 AM
"(except that there’s still the issue of addressing transparent clustering for scaling and high availability - as well as replicating transactional distributed caching that will enable capitalizing on 64-bit address space and multi-gigabyte RAM in current generation servers)"
Hmm. Sounds like you are looking for Coherence.NET ;-)
By
Anonymous, at 7:33 AM
Post a Comment
<< Home