Linked by Thom Holwerda on Tue 26th Jul 2005 20:48 UTC
Mono Project Mono is an open-source implementation of Microsoft's .NET for Linux and other operating systems. In this article, Tim Anderson interviews project leader Miguel de Icaza. Why is Mono now partnering with Mainsoft to ease migration to J2EE?
Thread beginning with comment 9742
To read all comments associated with this story, please click here.
Some Realism Setting In?
by segedunum on Wed 27th Jul 2005 13:56 UTC
segedunum
Member since:
2005-07-06

I'm pleased to see someone has listened to me, slightly anyway ;-).

It's nice to see that Mainsoft are at least injecting some real-world business sense into Mono - namely that there is no demand whatsoever for Mono/ASP.Net powered applications servers, or in many environments, even ASP.Net powered Microsoft servers. Apart from that, they seem to regurgitate the same stuff.

The Grasshopper compiler converts your compiled ASP.NET project into Java byte code, for deployment on a J2EE application server;

This is the thing that I think is just plain lunacy. Aside from the fact that I have a hard time seeing the advantages of running a machine within a machine most of the time anyway, what on Earth is the logic in converting one set of bytecode to another? All you're doing is running two different virtal machines, both running above native code, for no reason whatsoever. Is that worth the hassle of the so-called productivity benefits .Net and ASP.Net supposedly bring? No, it damn well isn't and no J2EE user is going to allow that anywhere near their servers.

In many environments I have seen a need for .Net clients and J2EE servers to communicate, but there are many very and more reliable ways and many products on the market for doing that.

"The hole that Mainsoft’s product fills is one that Microsoft has not been able to penetrate with ASP.NET...So that market is very hard for Microsoft to penetrate."

This is the thing that really does make me roll on the floor and laugh and then shake my head in disbelief when I think of Mono.

You notice here that Miguel has no other option but to equate the success and penetration of Mono with the success and penetration of .Net and Microsoft in the enterprise space. You can't have one without the other, because if there's no demand for Microsoft and .Net there's no demand for Mono, and for Mono to succeed Microsoft has to have got there first. Does anyone see how incredibly stupid that is?! Microsoft would have to displace all of the J2EE infrastructure out there, and then there may actually be some scraps of demand for Mono. Where do you think that will put open source software?

Miguel might be a talented technical person and Mono might be a good technical achievement, but when it comes to what will work in the real world, and real-world demand, he's a fish straight out of water.

"The development model in ASP.NET is lighter than the development model with J2EE. J2EE has taken this approach of Model-View-Controller, which is a beautiful thing from an academic perspective, but it does add a burden."

I do not know where this MVC thing comes from with Java. It is perfectly possible to write a very simple layered system with Java and J2EE without buying into MVC at all. MVC is there, and always has been, when you have difficulties you need to solve with communication between multiple layers of your system. You don't need to use it though, and in terms of that complexity, that's a bridge .Net hasn't even got to yet.

At Ximian we consulted with a number of software companies. They said, ‘We can develop applications 20 to 25% faster than with ASP.NET than we can with J2EE.’

Err, no Miguel. That's something you picked up out of one of Microsoft's surveys when you were trying to bolster demand. If you cut the complexity you don't need from your J2EE systems, you can quite easily cut your development time and that cut in development time is also dependant on good development tools and IDEs.

The reason why that apparent complexity exists with Java is simply because people have been using Java for many different and complex systems over the years. If .Net ever approaches that kind of usage then you'll see frameworks like Struts and Hibernate that apparently increase the complexity of everything. The problem is, people tend to buy into these frameworks without evaluating them.

Even then though, the actual development time should be pretty insignificant compared to the analysis and design stages of your project, and if you do that properly, that will also cut your development time more significantly than any fancy new technology ;-).

I asked de Icaza what is the current state of adoption for Mono in the Enterprise. He says that the numbers are not being tracked.

Non-existant, that's the current state.

We do know that a lot of the existing open-source applications are now being certified to run directly on Mono.

That's not going to help Mono's adoption or help pay for itself.

Pretty much all of the desktop efforts are built on Mono.

Blah, blah, blah. There's simply no evidence for that apart from the usual Beagle/F-Spot stuff that isn't significant for Novell at all. They're not even Novell software either.

"It enables the large number of VB.NET and C# people to target a platform other than Windows."

Yes, and any company migrating will need to migrate to Microsoft's .Net first to enable that to happen, not to mention the things they increasingly won't be able to port ;-). And then they're somehow magically expected to move Mono because they simply think running all this stuff on Linux as well is going to be wonderful :-).

It had an application for provisioning and human resources management that was running on ASP.NET. The company which developed the application came to Mono for help with porting.

So Mono cannot possibly get away from .Net compatibility then. And what are the developers actually using (and even using to compile) to develop this application? Visual Studio and Microsoft .Net? And what happens when these development tools start using and linking directly into technology like Indigo which Mono will probably never support? And if Mono starts having to steer people away from these technologies are people going to be confident doing that considering that they are still using Microsoft technology and development tools? Which way are they going to go?

The wheels are going to fall right (and are falling) off the wagon with that kind of thinking.

De Icaza made some sharp comments concerning Indigo, the next-generation Windows technology which replaces COM+ and .NET Enterprise Services

Well of course he did. Since Mono isn't going to be able to reproduce Indigo for various reasons he needs a plausible reason not to do it ;-).

They wanted to have something simpler than Corba, and created Ice [Internet Communication Engine], which works in Java, C++, PHP, and of course any of the .NET languages.

Thanks for the admission about CORBA. Most people have known that for years.

"So when people ask me about Indigo I say well, you can get Ice today. Ice has everything you can dream of. You can try it out for free, for free applications, or you can buy a commercial license. Ice is fantastic, and people deserve to know more about it."

My God. Miguel de Icaza talking about a dual/multi-licensed piece of software, and recommending people use it. No wonder it's called ICE!

but in reality moving from say WebSphere to BEA is unlikely to be easy

It is if you keep away from the vendor specific stuff. I'd love to know how they think moving from .Net to Mono (or even vice versa ;-)) is any better.

The company promotes Grasshopper in conjunction with a high-end J2EE server as a means of adding scalability to .NET, yet it has not attempted to port the System.EnterpriseServices libraries

If they haven't ported that then any interest any company may have had will end there.

Finally, if you would like to try Mono, you can now do do in a pain-free manner by downloading a new live CD.

Tried the Live CD. Thought it was a great idea, and everyone seems to be doing it these days.