Ars Technica Tours Mono

Kevin Francis writes "Over the coming weeks, Ars Technica will be taking a look at Mono, including a basic introduction to Mono, MonoDevelop, and C#, and then branching out to GTK#, database access, ASP.NET, advanced C# topics, and conclude with a discussion of the future of Mono, and the C# standard. All the examples will work on Windows and Linux, with OSX support coming shortly. Part 1 of the series is online now."

Comments

looks promissing but what is it really against?

[urbieta]

Time for coders to take a closer look!

What are the methods currently used by GIMP, OpenOffice, Mozilla among others that already support multiple OS's?

Maybe Ill start learning coding with this and kill more birds with the same shot :)

Re:looks promissing but what is it really against?

[FooBarWidget]

I don't know about OpenOffice and Mozilla but your claims are definitely not true for Gimp.

First of all, Gimp is not C++, it's written in C. And Gimp contains very little to no platform-specific code. Gimp uses Gtk and Glib as portability layers. The Gimp maintainer strives to have as little platform-specific code as possible. He even wants to eventually get rid of all of the remaining little #ifdefs.

Gtk and Glib are also not littered with #ifdefs. Gtk uses Gdk as portability layer. Gdk has several implementations: X, Win32 GDI, DirectFB, etc. An implementation is automatically chosen by the configure script (or something like that, not really sure about this one), but there are very little #ifdefs.
I don't know about Glib.

"The theory is that with .NET you won't need ANY platform specfic code. If that turns out true, I will be completely amazed."

My theory is that it will end up with something like Java or all the other portability frameworks for C/C++. The simple things are portable but when you want to do some more complex things, you suddenly face the limitations. And you also have limited ways to really integrate with the platform's desktop.

Re:Will the coders use it though?

[Random Web Developer]

I am writing an app for mono that is supposed to run on linux mac and windows in the end. From what I see it's nowhere near just starting a .NET app on linux using mono.

The app clearly has to be written with crossplatform execution in mind. (I know this goes for c and java too, but some people seem to think they will run office on mono in the future.).
You need to steer clear of anything that depends on a platform.
- if you define a path, make sure you use path.combine or path.directoryseparatorchar instead of a / of \.
- don't depend on environment variables
- pay attention to casing, don't say "file.ext" when it's "File.ext"

I know it should be ovbious to any cross platform dev out there, but I just thought I'd bust some bubbles with some of the less informed.

Re:Libraries

[ajp]

Uninformed slashdotters with tin foil hats should click this link.
ECMA-335 Common Language Infrastructure (of which .NET, Rotor and Mono are implementations.)

Re:RAD tools

[Lussarn]

Glade is language independant. As long as there is libglade for mono it should work very well.

Re:Bull

[cbiffle]

And, of course, there's the fact that his latter two complaints are kind of sort of fixed in 1.5.

So... :-)

Personally, I think the C# folks make too much of a big deal about the mandatory exception handling in Java. Heard a fellow from Microsoft say "Frequently, Java folks just put an empty catch() block to catch the exception they know won't happen, so why make it mandatory?"

I've got bad news for you. I find situations like that about once a week when auditing my programmers' code, and it's almost always a situation that -can- happen, but the programmer couldn't see it.

Don't trust the programmer. I know, I am one. :-)

Re:Will the coders use it though?

[moonbender]

How is this different from Java? In my opinion Java makes things harder than it needs to be. For starters, enforced exception handling can't auto-box/unbox primitive types and doesn't support arbitrary length parameter lists String.Format() style.

Right. Of course that's all about to change - from the Java 1.5 ("5") new features site:

Autoboxing/Unboxing
This facility eliminates the drudgery of manual conversion between primitive types (such as int) and wrapper types (such as Integer). Refer to JSR 201.

Varargs
This facility eliminates the need for manually boxing up argument lists into an array when invoking methods that accept variable-length argument lists. Refer to JSR 201.

You still need to deal with exceptions - that's a bad thing?

Re:And how is this better than wxWidgets/wxPython?

[StarfishOne]

I've been playing around with (wx)Python as well lately and it rocks!

Especiall combined with:

Boa Constructor:
'A cross platform Python IDE and wxPython GUI Builder. It offers visual frame creation and manipulation, an object inspector, many views on the source like object browsers, inheritance hierarchies, doc string generated html documentation, an advanced debugger and integrated help.'

http://boa-constructor.sourceforge.net/

And the Twisted framework for network programming. http://www.twistedmatrix.com/

"Twisted Matrix Laboratories is a distributed group of open-source developers working on Twisted, an event-driven networking framework written in Python and licensed under the LGPL. Twisted supports TCP, UDP, SSL/TLS, multicast, Unix sockets, a large number of protocols (including HTTP, NNTP, IMAP, SSH, IRC, FTP, and others), and much more."

I've now got a fully asynchronous and very fast custom server running.. in less then a day from a clean start with the Python language!

I really recommend checking this out!! ^_^

Re:Will the coders use it though?

[dekeji]

Strangely that assumption is quite widespread. I think I've tracked down the source [mono-project.com] though.

Yes, you have correctly tracked down the source of that misconception. It's an easy misconception to have, given what the Mono project writes about itself.

Now, dig down a little deeper and go to the downloads. What do you see? A "Mono Stack" on the left, consisting of OSS libraries and APIs, and a .NET stack on the right, consisting of .NET libraries and APIs. You can pick one or the other, or both. Neat, huh? Now, also note the relative sizes of the Mono and .NET stacks.

Now, turn to the FAQ:

Question 132: Is Mono only an implementation of the .NET Framework?

Mono implements both the .NET Framework, as well as plenty of class libraries that are either UNIX specific, Gnome specific, or that are not part of the .NET Framework but people find useful.

Question 50: Can mono run the WebMatrix?

No. That requires System.Windows.Forms support which is not currently implemented.

Question 40: Do you fear that Microsoft will change the spec and render Mono useless?

No. Microsoft proved with the CLI and the C# language that it was possible to create a powerful foundation for many languages to inter-operate. We will always have that.

Even if changes happened in the platform which were undocumented, the existing platform would a value on its own.

What does that tell you?

• A lot of Mono software (most, in fact) already is completely incompatible with Microsoft .NET, since Mono doesn't even implement important parts of .NET, but does provide extensive non-.NET libraries that are being used by Mono applications. So, .NET compatibilty just doesn't matter to most Mono developers.
  
• People know that Microsoft could change .NET, and it generally doesn't matter to them.
  

Why is the Mono project seemingly saying one thing and delivering another? Well, in part, it's because the term ".NET" is really ambiguous. In part, it's because where their money comes from and where their commercial interests are (they aren't doing this out of religion, they are in it for commercial purposes).

So, your confusion is understandable. I wish the Mono project were clearer on their front page, too, but I suspect they have reasons for what they are doing. Either way, you should really dig a little deeper.