MONO - lost it's way?
-
I was very excited about MONO for a couple of years there and posted here about it but I'm starting to get the impression it has badly lost it's way. The original concept was to be able to build cross platform .net apps that would run in windows under Microsoft .net or on a mac or linux box etc. So far they have replicated most of .net 2 under mono but for some reason have left out maddeningly basic and important methods like Decimal.Round which is critical for financial software, things like being able to set the cursor to a waitcursor which predates even .net 2. That being said they are now apparently leaping ahead to some .net 3 stuff and promising silverlight support in a couple of months. It has all the hallmarks of a project where everyone is leaping ahead to the fun bits and dropping the ball on the fundamental bits. The other big glaring problem is there is no 3rd party library support worth mentioning, so no reporting, no ui stuff etc. I tried to get Telerik and Infragistics and DevExpress together with MONO, in fact the MONO head dude did get in talks with them. Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work. Although they all seem to use the same fundamentel p/invokes which led the MONO people to say that they would come up with some sort of shim layer to support that which would instantly give everyone using all those nifty 3rd party component libraries the MONO market as well. That never materialized and has since not been mentioned at all. In fact they point people to a list of "MONO" supported .net libraries but there is nothing on there that would work for a serious commercial application developer and besides it breaks the whole point of write once run everywhere that was the original promise. Sadly I think MONO is still years away from being what it was supposed to be this year. Sure you can write trivial little sample apps that run on mono.net and ms.net but try to do anything more and you better write it for MONO and accept it's going to be very limited compared to other apps out there.
"110%" - it's the new 70%
"Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work." Actually, the .NET Framework makes heavy of P/Invoke too. Are you going to slam that too while your on a roll?
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
-
I was very excited about MONO for a couple of years there and posted here about it but I'm starting to get the impression it has badly lost it's way. The original concept was to be able to build cross platform .net apps that would run in windows under Microsoft .net or on a mac or linux box etc. So far they have replicated most of .net 2 under mono but for some reason have left out maddeningly basic and important methods like Decimal.Round which is critical for financial software, things like being able to set the cursor to a waitcursor which predates even .net 2. That being said they are now apparently leaping ahead to some .net 3 stuff and promising silverlight support in a couple of months. It has all the hallmarks of a project where everyone is leaping ahead to the fun bits and dropping the ball on the fundamental bits. The other big glaring problem is there is no 3rd party library support worth mentioning, so no reporting, no ui stuff etc. I tried to get Telerik and Infragistics and DevExpress together with MONO, in fact the MONO head dude did get in talks with them. Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work. Although they all seem to use the same fundamentel p/invokes which led the MONO people to say that they would come up with some sort of shim layer to support that which would instantly give everyone using all those nifty 3rd party component libraries the MONO market as well. That never materialized and has since not been mentioned at all. In fact they point people to a list of "MONO" supported .net libraries but there is nothing on there that would work for a serious commercial application developer and besides it breaks the whole point of write once run everywhere that was the original promise. Sadly I think MONO is still years away from being what it was supposed to be this year. Sure you can write trivial little sample apps that run on mono.net and ms.net but try to do anything more and you better write it for MONO and accept it's going to be very limited compared to other apps out there.
"110%" - it's the new 70%
John Cardinal wrote:
So far they have replicated most of .net 2 under mono but for some reason have left out maddeningly basic and important methods like Decimal.Round which is critical for financial software...
Why don't you just derive a Decimal subclass and overload the Round() method? It sounds easy enough to me but I don't know the situation...
############################################# A comment from some code: "The devision operations in the SET function calls are intentional, do not change them, they will prevent a software bug from causing the robot to drive through twelve cubical walls"
-
John Cardinal wrote:
So far they have replicated most of .net 2 under mono but for some reason have left out maddeningly basic and important methods like Decimal.Round which is critical for financial software...
Why don't you just derive a Decimal subclass and overload the Round() method? It sounds easy enough to me but I don't know the situation...
############################################# A comment from some code: "The devision operations in the SET function calls are intentional, do not change them, they will prevent a software bug from causing the robot to drive through twelve cubical walls"
That's just an example, for my main application there are over a 250 methods either not implemented yet or flagged as todo with issues. I'm not even counting the p/invokes in there that are a result of the 3rd party ui and reporting components I use. The whole point was supposed to be that you can take a binary built for microsoft.net and simply run it in MONO, no need to change the code at all. I and most other commercial developers are not going to change a single line of working, tested, released to the public code simply to cater to an unknown market size that we might get with MONO. If it was really just able to run under MONO then it's all good.
"110%" - it's the new 70%
-
"Turned out that most ".net" libraries on the market make heavy use of P/Invokes to work." Actually, the .NET Framework makes heavy of P/Invoke too. Are you going to slam that too while your on a roll?
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
Neil Cowburn wrote:
Are you going to slam that too while your on a roll?
Yikes! slam is a pretty loaded word, I've brought up perfectly valid points here. P/Invokes are the tip of the iceberg really, there are over 250 methods that are still not implemented or flagged as TODO in MONO when I scan it with MOMA for my main application I was thinking would benefit if it could run in MONO. The real issue is that over a year ago when I scanned the same app with MOMA it was pretty much the same situation. So in a year there has been no progress on fundamental basic items in the framework, however I see they are leaping ahead to .net 3 and silverlight etc. It's clearly lost it's way when the fundamentals aren't being taken care of. As for the .net framework making heavy use of p/invoke, I have no personal knowledge of that nor do I really understand your point either way. The goal of MONO is to have a complete reproduction of the microsoft .net framework as per the submitted spec. In a completely separate issue 3rd party component library vendors are advertising 100% managed .net code which turns out to be false advertising. Would have been a non issue if MONO hadn't come along, now it's clear that they won't be supported on MONO and MONO themselves have backed away from the promise of a support library of some kind for the p/invokes that are most commonly used. Which turns the whole thing around to where it was at the start: useless for anything more than a very primitive application.
"110%" - it's the new 70%
-
If Mono is open source, you can fix what is not working for you. That's the purpose of Open Source, me thinks. If everybody waits for somebody to do it we'll never get there.
I didn't start the project, I don't have the resources of Novell who is using in-house developers to supposedly complete it. I'm merely pointing out that they have lost their way, they were supposed to be much further along than they are now. This is not a classic open source project by any stretch of the imagination although it appears to be suffering from the same factors that doom most open source projects: no one wants to work on the boring stuff.
"110%" - it's the new 70%
-
Neil Cowburn wrote:
Are you going to slam that too while your on a roll?
Yikes! slam is a pretty loaded word, I've brought up perfectly valid points here. P/Invokes are the tip of the iceberg really, there are over 250 methods that are still not implemented or flagged as TODO in MONO when I scan it with MOMA for my main application I was thinking would benefit if it could run in MONO. The real issue is that over a year ago when I scanned the same app with MOMA it was pretty much the same situation. So in a year there has been no progress on fundamental basic items in the framework, however I see they are leaping ahead to .net 3 and silverlight etc. It's clearly lost it's way when the fundamentals aren't being taken care of. As for the .net framework making heavy use of p/invoke, I have no personal knowledge of that nor do I really understand your point either way. The goal of MONO is to have a complete reproduction of the microsoft .net framework as per the submitted spec. In a completely separate issue 3rd party component library vendors are advertising 100% managed .net code which turns out to be false advertising. Would have been a non issue if MONO hadn't come along, now it's clear that they won't be supported on MONO and MONO themselves have backed away from the promise of a support library of some kind for the p/invokes that are most commonly used. Which turns the whole thing around to where it was at the start: useless for anything more than a very primitive application.
"110%" - it's the new 70%
There's an old saying, "If you're not part of the solution, you're part of the problem." If you have issues with the "fundamentals" not being present in Mono, why don't you implement them yourself and contribute them back to the community instead of moaning?
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
-
There's an old saying, "If you're not part of the solution, you're part of the problem." If you have issues with the "fundamentals" not being present in Mono, why don't you implement them yourself and contribute them back to the community instead of moaning?
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
You're taking this all very personally for some odd reason. Signing up with an account just to reply to this thread. Whatever the case welcome to CodeProject and know that we tend to have opinions here that you might not agree with from time to time. Saying it's better to light a candle than curse the darkness doesn't in my opinion negate the quality of the information I provided. Perhaps you are not aware that I was a major proponent of MONO here for some time. I'm not moaning about it, I'm rectifying my prior posts which were all very supportive of MONO. As the person that kept bringing it to the attention of the community when it seemed to be going somewhere fast and had big promise and relevance to people here. I felt an obligation to ensure that I report the facts on how it all turned out.
"110%" - it's the new 70%
-
You're taking this all very personally for some odd reason. Signing up with an account just to reply to this thread. Whatever the case welcome to CodeProject and know that we tend to have opinions here that you might not agree with from time to time. Saying it's better to light a candle than curse the darkness doesn't in my opinion negate the quality of the information I provided. Perhaps you are not aware that I was a major proponent of MONO here for some time. I'm not moaning about it, I'm rectifying my prior posts which were all very supportive of MONO. As the person that kept bringing it to the attention of the community when it seemed to be going somewhere fast and had big promise and relevance to people here. I felt an obligation to ensure that I report the facts on how it all turned out.
"110%" - it's the new 70%
BTW, it's Mono, not MONO :) I'm not the one taking this personally. You are. You're miffed because after a year, no one was implemented the class you need. Did you attempt to implement it yourself? Probably not. You seem to be missing the point of one the core principles of Open Source -- growth is achieved through community contribution. Not once in this thread have I seen you say anything along the lines of "Hey, something is not quite right here. Let's get together and do something about it", which would be in the spirit of the Open Source movement. Have you reported these facts back to the Mono community? I'd say that would be a better course of action.
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
-
BTW, it's Mono, not MONO :) I'm not the one taking this personally. You are. You're miffed because after a year, no one was implemented the class you need. Did you attempt to implement it yourself? Probably not. You seem to be missing the point of one the core principles of Open Source -- growth is achieved through community contribution. Not once in this thread have I seen you say anything along the lines of "Hey, something is not quite right here. Let's get together and do something about it", which would be in the spirit of the Open Source movement. Have you reported these facts back to the Mono community? I'd say that would be a better course of action.
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
Neil Cowburn wrote:
You're miffed because after a year, no one was implemented the class you need
Miffed wouldn't be accurate, disillusioned would be closer to the mark and for the record it isn't "one" class it's over 250 methods which have seen no movement in over a year. To say I need them is inaccurate, I really don't "need" Mono at all, I was excited about it, I thought it would be a good way to add sales to our existing market. I'm a business person besides being a developer and I think it's not an exaggeration to say that rather than myself needing Mono, Mono actually needs the opinions of people like myself for a long term future. When you still can't set a wait cursor after all this time it's pretty obvious no one is putting a priority on commercial application developers that can't afford to throw away all consideration of usability.
Neil Cowburn wrote:
Have you reported these facts back to the Mono community? I'd say that would be a better course of action.
Yes Miguel is aware of my concerns and I've faithfully run and submitted my MOMA reports every quarter since it first became available as a tool.
Neil Cowburn wrote:
You seem to be missing the point of one the core principles of Open Source -- growth is achieved through community contribution.
I'm well aware of the core principles of open source. In fact I oppose the idea of open source software on principle for any purpose except infrastructure; the category that Mono falls into which is nuts and bolts "plumbing" that supports applications. For example the Firebird project falls in that category as well which I support wholeheartedly. As a full time working developer with a small software company I have no spare time to involve myself with Mono development other than a potentially half-assed, when-I-can kind of effort which I don't think is appropriate for any serious work. I do have the perspective and share the views of a *lot* of commercial software developers who, last time I checked, were one of the coveted target markets for Mono. I'm sure Novell would have more than a passing interest in attracting more commercial apps to Linux and they *do* have and are applying the resources appropriate to the project. Sadly it seems to be losing it's way in exactly the manner that most open source projects do: no one wants to do the dirty work.
-
Neil Cowburn wrote:
You're miffed because after a year, no one was implemented the class you need
Miffed wouldn't be accurate, disillusioned would be closer to the mark and for the record it isn't "one" class it's over 250 methods which have seen no movement in over a year. To say I need them is inaccurate, I really don't "need" Mono at all, I was excited about it, I thought it would be a good way to add sales to our existing market. I'm a business person besides being a developer and I think it's not an exaggeration to say that rather than myself needing Mono, Mono actually needs the opinions of people like myself for a long term future. When you still can't set a wait cursor after all this time it's pretty obvious no one is putting a priority on commercial application developers that can't afford to throw away all consideration of usability.
Neil Cowburn wrote:
Have you reported these facts back to the Mono community? I'd say that would be a better course of action.
Yes Miguel is aware of my concerns and I've faithfully run and submitted my MOMA reports every quarter since it first became available as a tool.
Neil Cowburn wrote:
You seem to be missing the point of one the core principles of Open Source -- growth is achieved through community contribution.
I'm well aware of the core principles of open source. In fact I oppose the idea of open source software on principle for any purpose except infrastructure; the category that Mono falls into which is nuts and bolts "plumbing" that supports applications. For example the Firebird project falls in that category as well which I support wholeheartedly. As a full time working developer with a small software company I have no spare time to involve myself with Mono development other than a potentially half-assed, when-I-can kind of effort which I don't think is appropriate for any serious work. I do have the perspective and share the views of a *lot* of commercial software developers who, last time I checked, were one of the coveted target markets for Mono. I'm sure Novell would have more than a passing interest in attracting more commercial apps to Linux and they *do* have and are applying the resources appropriate to the project. Sadly it seems to be losing it's way in exactly the manner that most open source projects do: no one wants to do the dirty work.
I'm amazed that even after all this discussion, you still have yet to take the intiative propose a solid, constructive solution. Maybe you're just apathetic. Afterall, by your own admission, "... no one wants to do the dirty work.
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------
-
I'm amazed that even after all this discussion, you still have yet to take the intiative propose a solid, constructive solution. Maybe you're just apathetic. Afterall, by your own admission, "... no one wants to do the dirty work.
------------------------- Neil Cowburn Principal Partner OpenNETCF Consulting, LLC -------------------------