I hear you.. I can see the issue this way -

With respect to COM not scaling. I think this is a bit of an open-ended statement. Is there something intrinsic about COM not scaling, or is it in the implementation? Is the burden too much on developers that they have to know too much? Is this a problem with COM per se, or in the implementation of COM?

Robert has often told me the fundamental problem with XML is that you have to know what you are doing right now..< bg >. He is right. However, I would submit that it is not a problem with XML per se. Rather, it is a problem with the implementation. Perhaps I am splitting hairs here, being too semantical. I am not sure I care since in the end, there are issues with people being able to implement the technology.

On one hand, I like the idea of removing uneccessary complexity. i.e., afford developers to time to concentrate on the problem instead of robbing the developers of time because they have to struggle with implementing technology. Technology is supposed to be the great enabler, not the time robber.

The issue I have right now with .Net is the safety net. The question is "Does a safety net exist?" If you buy into it, is it a one-way onramp? Does it constitute a destination with no return. I like having options. COM provides options. I can get into it as deep as I want. .Net is forcing folks to buy into the concept 110%. I beleive being on the cutting edge when it makes sense. I don't see how being on the bleeding edge here makes good business sense. I say this in light of your comment - you can do just about all of it today. I for one am going to let others take the big risk. I will be watching and evaluating. But for sure, I am not going to make huge investments until the dust settles. I see no gain by diving head-first now as opposed to gradually phasing in over a one year period.

Simple is best - that is my mantra...


As for COM not scaling, as a sweeping statement, it is one I cannot agree with. First off, you need to define what you mean by "scaling"...

< JVP >



>> these need to be looked at in a very pragmatic way. FWIW, I think Rick puts forth a lot of good circumstantial evidence to imply that the whole thing may not match the hype. We will have to see. For me - the proof will be in the apps.
>
>Just for clarification, that's not really what I'm saying. I've changed my view to a little more upbeat since I've been playing with VS.Net, but my point is that a) you can do just about everything that .Net will do today and b) Microsoft has to deliver 100% on the promise, which means, performance, stability and administratibility (nice word, huh?), which are the things that are wrong with the current platform.
>
>
>>Personally, I don't know what the problem was with COM and components. It works. Constantantly pulling the rug from under developers is a royal pain in the ass. I don't care of a company you are - somebody - it is going to bite you in the rear.
>
>COM doesn't scale. That's the short of it... It's also hard. You have to know way to much about the architecture to use it effectively. Most developers don't and consequently write apps that are dog slow and don't scale. You can build scalable, fast COM based apps, but it takes a lot of know how. With .Net all of the COM bullshit is hidden away in the framework and you don't have to worry about threading models, marshalling etc.
>
>Microsoft is taking a gamble, but in the end I believe it's one that they have to take to move forward. They need to make sure they can deliver all that has been promised which is a lot!