David,

>Thomas,
>
>>I have considered the ramifications of using multiple languages to create one .NET project. If this is done, the term “spaghetti code” will take on an entirely new meaning. Who will be the one who will have to debug such an application if something breaks or the application requires attention? How many people will have working knowledge of all languages used in such an instance?
>
>You have just pointed out an important consideration of the very interesting cross-language inheritance of .NET. In practical terms, if you take the approach that, "OK, let's build a development team. We seem to have more VB people around these days, so they can work in VB .NET, but here are few sharp C++ guys. Let's have them do some stuff in C#, and oh yeah, our old Cobol senior citizens can build some of our system, too."
>
>"Since it's all cross-language, we can each inherit from each other on various parts of the system, because it really doesn't matter any more." Until, as you said, you actually have to debug and maintain, perhaps with a different set of developers. There is a lot to be said for narrowing the focus.
>
>I think the most interesting part of cross-language might be in getting pre-built classes from the component market and subclassing them in your language of choice -- which really is what you have with the .NET Framework anyway.
>
>Good discussion...

Hmm..

Doesn't this open the door big time for having some sort of product certification or 'sticker' type program? If you're a company purchasing a third party product written in COBOL.NET wouldn't you want a certain level of certainty before you spend your $$ on it? I'm thinking something along the line of when Novell would certify NLMs...