In this second and final part of my interview with Ted Shelton, Borland's chief strategy officer, Shelton focuses on Microsoft .Net's support for multiple languages and reveals a hidden .Net stumbling block.
The most striking passage for me was Shelton's convincing argument that developers who program in languages other than Visual Basic, C++, or C# may actually find .Net a hospitable environment. (I'd been advised by several developers that unless you bite the bullet and learn C#, the native language, you'll sacrifice too much power and productivity.) Shelton returns, in the end, to the future of Web services and the dangers of building the Web services protocol stack too high. I hope you'll find his comments as engaging and provocative as I did.
Wouldn't someone who uses another language be frustrated working in .Net? Is there any point in developing in a language other than C#?
The languages that matter are C++, C# (because Microsoft says it's important), Visual Basic, Java, and Delphi. If you take those five programming languages, you have 80 percent of all the professional developers in the programming world.
Microsoft is at least able to appeal at some level to all five of those categories--and Java is able to appeal to one. Now, will Java developers be frustrated when they find that J2EE is not all there in .Net and they have to learn a different framework? Yes, but at the same time they'll be able to be productive in that environment--they'll be able to get work done. Will the C++ developer be frustrated, especially because if you really want to do C++ development you have to drop out of the .Net Framework? Yes. But at the same time can they get work done using C++? Yes. So I think that there's sort of a "good enough."
What about Visual Basic 6 developers? Isn't it a rough transition for them going from a scripting language to Visual Basic .Net, an object-oriented language?
From the evolutionary perspective, they've been being tugged in that direction for a while. If you can make the object-oriented parts of it simple enough, so that people who are script-oriented aren't frightened by it, how hard is it to get them to flip over? The syntax is the same; the application architecture is somewhat different.
I'm not at all downplaying the challenge that Microsoft has in getting people to adopt VB .Net and ultimately C#. It's clear that that's the path they want the VB developer to go down. But in comparison to the problem of convincing someone to learn Java? That's really what you're fighting against. Is a Visual Basic developer going to go and learn VB .Net or is he going to go to Java? He's not going to go to Java. Java is actually really hard--at least today.
I think the unrecognized threat [to the Java community] is that .Net is actually a very technically elegant solution set…although there are some problems with it. I think every new technology has to be treated as being a set of undiscovered problems. I certainly don't think the developer community ever thought .Net out of the box was going to be a panacea. In fact I think the slow adoption rate of .Net has more been a result of people anticipating problems than real problems.Give me an example of a real problem.
Well, it's easy to pick on Microsoft around security issues. And .Net definitely has its share of problematic areas around security for applications. I know that there have been some issues with running applications in their secure sandbox and knowing that you can rely on the security parameters that you're setting up around the application. It's not so much a problem of it being insecure as it is of it being a complex environment to run an application in. So you start having issues around whether your application is running safely in that environment and what you can do and what you can't do.
There's a set of things that Microsoft can fix and there's a set of things that development tools like ours can fix. We've always been able to make it easier to develop for the Microsoft operating system than Microsoft has.
So bringing things back to Web services--one of the fundamental ideas that .Net was built on--what's your take on where we're headed?
One of the funny things that happened on the way to the altar as everyone decided to get married to Web services is that the fundamental difference in Web services got lost. One of the things that's different between Web services and CORBA is that CORBA is really a very transactionally oriented technology that's intended for synchronous communications between applications. And Web services is really this new, interesting idea of asynchronous communications and message-based or service-based architectures.
So what is it everybody wants to do? They want to take Web services and pound it back into the transactional, synchronous communications model they already know how to program to.
I'm hopeful that a new generation of software architects will ultimately comprehend the value and applicability of the looser, message-based architecture and you'll see all sorts of new kinds of things emerge--but that takes time. That takes a lot of time. And in the meantime, I think we're going to see a world in which each of the different platform vendors try to use Web services as a way to promise interoperability with their competitors, while at the same trying to differentiate themselves by creating a "better" implementation of the technology within their own stack. And so you see Microsoft saying, "Yeah, .Net does communicate with other non-.Net services technologies, but boy, if you use it in a .Net environment, it's faster, it's more secure, it's more reliable."
Well, everybody has to make money, right?
Well, I guess it's a just question of…at what level do you create highways and make sure that they're the right width for all the vehicles…and make sure the vehicles aren't too wide...and at what point do you add ski racks to some of them. I think we're still at the point of building highways. I'm disappointed that the marketplace is differentiating too early.
Is .Net a more elegant solution? TalkBack below or e-mail Eric.
