Call me a Heretic but...
Karl wrote a long comment in my "All I needed to know..." piece. I really liked his comments: they resonated enough with me that I wanted to share my response with the community. While we may not agree, neither of us are wrong, I think, we're just looking at things differently. After all, anybody that hangs out with a Siamese just has to be ok in my book.
The only reason we don't know who is to blame is because Microsoft hasn't done a good job of keeping us informed. They brought all these speculations onto themselves.
I agree with part of this. They haven't done themselves any favors by not communicating more about when to expect what. That said, I don't feel that there is need to blame anybody, nor is there anything to be gained from speculating about it. I choose to put my energy into to constructive things (well, other than killing my liver.)
I also know how much I liked people breathing down my neck for bits when I knew how much work there was to be done. We were told that these are technical previews -- not even betas. I can't understand why we can't put two and two together here.
Yukon is just another namespace for Whidbey...it's nothing...there is no dependency,
As much as I hate to say, that's missing my point. There doesn't have to be a literal dependency at all, but there is a logical one. You're also missing the my other point: Yukon is the next version of SQL Server. That's far from some as trivial as you make it sound.
And lets not forget that with Whidbey and Yukon, there's a shared IDE UI. I don't know about you, but I find it senseless to have one UI for managing databases (enterprise manager) and two others (query analyzer and the VS.NET IDE) for developing against them.
no more so than System.Data.SQLClient.
Again, no, that's just not the case. There's also System.Data.SqlServer and System.Xml that have a lot of interworking with Yukon. Now, you may be saying "fine, but what exactly is Whidbey getting out of the relationship?" Let's start with XQuery and XML Views, which will... eventually... be generically available. That leads to XPathDocument2, which gives you a fast, editable cursor on any XML data source. That stuff might not be around if it wasn't for the work they had to do to work with SqlServer.
And let's not lose sight of the real step forward here, there's been a lot of work to make .NET work on top of another thread and memory pool manager. Is Yukon the first product to see that benefit? Sure! Is it the last? I doubt it.
Yukon is to Whidbey what a Maker Hook is to a Worm - just one of many ways to get around.
Partially. Both Whidbey and Yukon are Maker Hooks on the CLR, which is really the worm (and there, the spice) in my view of the world.
The problem is that VS.Net has large number of issues, from critical problems (mucking up html) to lacking key features (generics). From my point of view, I couldn't give a rats ass about Yukon. I want some of those issues fixed now, and I needed some of them fixed last week.
I think I see what our difference is now. To me, Whidbey isn't the just the VS.NET IDE -- its both the CLR and the IDE. Yukon isn't just the RDBMS, its the RDBMS and the CLR.
I hear a lot about VS.NET having a lot of problems. Fine, don't use it. You don't have to. I learned .NET using TextPad and the command line.
I guess I also need to experience this "code mucking issue" for myself. I couldn't really give a dang if it reformats my HTML -- its just markup anyway. Maybe I'm just not worried about the right thing. Now, if it munges your HTML (as it likes converting © to the symbol then yes, I have the same beef as you do. What do I do about it? I try to stay out of design mode if that's going to be an issue for me. All that said, I really do want to keep an open mind: you have more specific examples, contact me with them.
As to generics, yes, they are nice. That said, I've gotten along since 1999 (when I first started with .NET) without them.
Your analogy couldn't be more right. Except instead of the spice being the worm and vice versa, it's really the Harkonnens (Microsoft), using it's spice monopoly (Whidbey) to somehow increase the profits of its Whale Fur (Yukon) industry. We don't care about the Whale Fur industry..and worst yet, you can't convience us that the two are related!
Why did I know somebody was going to compare MS to the Harkonnens. I don't agree. They are functioning more like the Navigators Guild in my mind. They want the spice to be more than just... spice, they want to use it to fundamentally change how the (or at least their) Universe works. They want to use the Spice accelerate all of their products, not just some section of them. They also have a lot of mind opening to do.
Its pretty obvious why too: COM is a dead-end and 64-bit platforms. Haven't you wondered why MS hasn't been banging that drum more loudly, or why the 32/64 chips are in play? I suspect the real truth there is that that all the pain felt migrating from 16-bit to 32-bit is twice again as bad when going from 32 to 64. To me, that's more of less the whole reason for .NET. Not because we needed .NET to make pretty web pages or gee-whiz desktop apps, but because Microsoft sees where all of this headed and how they really had to get something way better if they were going to survive in that world.
Frankly, I think I could say the same thing as you. I really don't care about the client-end technologies much and see ASP.NET as that preverbal "whale fur" that I could live without. Nor is it up to me to convince you of anything. Sure, I tried drinking the "water of life" so speak, and so far, it hasn't killed me. That doesn't make me the Kwisatz Haderach, though. I think we all have to find our own shorting of the way.
A beginning is the time for taking the most delicate care that the balances are correct. This every sister of the Bene Gesserit knows. -- Manual of Muad'Dib