Linked by Thom Holwerda on Tue 11th Mar 2008 23:28 UTC, submitted by irbis
Mono Project "Does GNOME co-founder Miguel de Icaza's backflip over the Novell-Microsoft deal a few days ago mean that he has finally been convinced that he is on a one-way path to nowhere? Has he realised that his own project, Mono, is actually putting GNOME on a development track that can leave it open to patent claims one day? And has he realised that creating Moonlight, a clone of Microsoft's Silverlight, (with which the company hopes to trump Adobe's Flash) is not going to advance the cause of free software one iota?"
Thread beginning with comment 304728
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Destructive
by miguel on Wed 12th Mar 2008 16:29 UTC in reply to "RE[3]: Destructive"
miguel
Member since:
2005-07-27

If the Mono team was really out to help folks and promote good technology, they'd bring the strengths of the CLR to the open source community.


None of the solutions that you list are of particular interest to us, as they fail a number of tests: (a) are they multi-language platforms; (b) do they have an extensive ISV platform; (c) readily available documentation and tutorials and an ecosystem around them.

All fascinating projects, and we wish them good luck, but that is not what we want to achieve.

If you feel so passionate about them, you should join those efforts.
Helping in any one of these areas would have far-reaching, cross-platform benefits for massive segments of OSS. Instead, the Mono folks chose to write a VM from scratch and play perpetual catch-up to Microsoft ever-changing language extensions (just ask any other vendor how easy and fun it is to ride the Microsoft protocol bronco without getting bucked off). And for what? Well, let's run down a list of Mono's "strengths":


In some areas we play catch-up, but every time we do, more programmers can port their software to Linux. You probably will not hear about them on OSNews.com, they are too busy getting real work done, but we are very proud of every developer that we have moved over from Windows.

Not all software will port, and not all of it is a 5 minute job, but it is possible, and in particular for vertical applications this is fantastic.


Mono allows unencumbered, cross-platform interoperability... so long as "interoperability" is defined in such a way as to exclude GUIs, database access, and web development.


Incorrect; We do support GUI portability using Windows.Forms, granted, people need to do some work on this area if they use P/Invoke, but its a small price to pay to get your app on Linux or MacOS.

Database access, moves transparently, you obviously have never tried it out, and the same goes for web applications (honestly, the easiest of the applications to port).

Porting to a new *database* (ie, MS SQL to Postgress) typically involves more work that porting the code with Mono. If you do not mind keeping the SQL server around (and most people are not willing to migrate this piece) porting of web apps is trivial.

The rest of your comment is clearly based on opinions based on a vague knowledge of Mono, factoids, not facts.


The syntax, though, is the fallback argument. C# is beautiful, concise, fun to program in. It's also available for Vala (without the accompanying memory bloat and speed limitations of Mono) and even Parrot.


More nonsense. Mono is not about C#, its about the CLI. But even if the "syntax" was available C# has plenty of features not available in either Parrot or Vala. Facts, not speculation.

miguel

Reply Parent Score: 2

RE[5]: Destructive
by monodeldiablo on Wed 12th Mar 2008 20:01 in reply to "RE[4]: Destructive"
monodeldiablo Member since:
2005-07-06

First off, let me say that it's an honor to be arguing with you, Miguel. ;) I have tremendous respect for your hack-foo ninja skills. However, I cannot agree with many of your "facts".

None of the solutions that you list are of particular interest to us, as they fail a number of tests: (a) are they multi-language platforms;


Parrot is, by its very nature, a language-agnostic, register-based virtual machine. Dozens of languages currently target it. Vala is a meta-compiler to GObject. Its compilation infrastructure is currently being abstracted to allow for arbitrary syntax.

(b) do they have an extensive ISV platform;


As I've said before, this isn't an FOSS concern. It's a business concern. And if that's a primary goal of Mono, I'm fine with that. It's a damn good reason to start the project if the goal is to lure businesses to Linux with minimal shock, but it doesn't really have much value for those of us already on the FOSS side.

(c) readily available documentation and tutorials and an ecosystem around them.


The Parrot project has so damn much documentation, the Amazon would be leveled to put it to paper. And just as you've built an ecosystem around Mono (something you should be proud of), the resources you've invested could have done the same for any other project you chose. Mono's Linux ecosystem didn't exist before you moved in.

Broadly, all these arguments play into the hands of Java, though. It has the added benefit of being an open, collaborative project (and better speed and memory utilization). Please don't portray your decision to shadow .NET as a foregone conclusion.

Incorrect; We do support GUI portability using Windows.Forms, granted, people need to do some work on this area if they use P/Invoke, but its a small price to pay to get your app on Linux or MacOS.


And this is where everybody else (including your own project: http://www.mono-project.com/FAQ:_Licensing) raises the spectre of patents. I'm not in the mood to get on this merry-go-round again, but for those who already write software in the Linux realm (and aren't customers of yours), the threat of losing access to these interfaces is as appealing an engineering solution as building a castle on sand.

More nonsense. Mono is not about C#, its about the CLI. But even if the "syntax" was available C# has plenty of features not available in either Parrot or Vala.


Such as? Every GTK# project I've used/seen uses the same wrapped libraries as a Vala one, yet a Vala-generated application runs native, without any interpretation overhead.

I don't mean to sound like a salesman. Honestly, the investment of resources could have gone to *anything* to make the Linux development ecosystem even more developer-friendly than it already is, instead of reinventing the wheel and tying its development to an unstable partner. Your three-pronged test is just as easily satisfied by Java, Python, Ruby, or Perl as it is by Parrot. I just chose it as an example of a open source project in its infancy at the time you chose to go off and build Mono from scratch.

Respectfully,

Mono Del Diablo (ironic, huh? the name predates your project)

Reply Parent Score: 4

RE[6]: Destructive
by miguel on Thu 13th Mar 2008 02:41 in reply to "RE[5]: Destructive"
miguel Member since:
2005-07-27

First off, let me say that it's an honor to be arguing with you, Miguel. ;) I have tremendous respect for your hack-foo ninja skills. However, I cannot agree with many of your "facts".


Well, that is because your understanding of the subject is very superficial, and as such you draw your conclusion from bumper stickers.


"More nonsense. Mono is not about C#, its about the CLI. But even if the "syntax" was available C# has plenty of features not available in either Parrot or Vala.


Such as? Every GTK# project I've used/seen uses the same wrapped libraries as a Vala one, yet a Vala-generated application runs native, without any interpretation overhead.
"

Well, Mono is not an interpreter, so you got that one wrong. But engaging in this discussion is merely an exercise in an opinion on who's dick is bigger.

Your knowledge is still razor thin, or I would not have to point out all the C# 2 and 3 features (or 1) that are different from what Vala supports (iterators, query expressions, lambdas, expression trees). And then follow up with features in the framework itself (garbage collection, reflection, delegates, asynchronous invocation framework).

Miguel.

Reply Parent Score: 2