XML Feeds
Adventures in C#
by Andreas Ericsson 
Yesterday I bravely went forth into the weird world of windows programming. Recognizing the need to familiarize myself with at least *one* language and toolset that works on both Linux and Windows I decided to check out the Mono project. Since I immediately understood that the initial threshold would be far too high and tedious for me to get past, I enlisted the help of a comrade-in-arms, Martin Almström, to teach me the basics.
For our first C# project (well, mine anyways, he's a C# guru, working on a 5MLoC project for the Swedish emergency dispatch center), we decided to write a file transfer tool (toy really), where I wrote a client that connected to his server. His server-program would feed my client a file and my client would write that file to disk.
At first, it was very confusing. The idiots at microsoft just had to re-use perfectly valid C keywords but give them totally different semantic meaning. "hey! 'static', I know... err.. no, I don't". It's also quite funny to write in a language where "int" can actually be null (but only if you really ask for it). Add to that the fact that I've never written anything in a OOO (object-oriented only) language before, and the chaos is complete.
After a while though, I started seeing the nifty things about it. It's not as fast as a proper C program (and the closed-source compiler has no clue about optimizations). The source-code has the overhead of all the OOO languages, so "Hello world" requires about 10 lines of code (steep learning curve). It does have some nice features though, such as builtin-accessor-method-enforcement and "interfaces", which seem to work similar to how the linux kernel driver API works, but on a higher level.
To make a long story short, we managed to get the program to transfer the file properly, although not very efficiently. The best speed we reached was 2Mbit/sec (on a local gigabit lan). I blame myself, tbh. I have no clue how to optimally use the Stream objects in C# and was probably doing it wrong, but getting something *real* to work the first day has to be seen as quite a huge success ;-)
The upsides:
* monodevelop is a really nice IDE.
* The executable files load and run nearly as fast as C code.
* The executables are "portable" (well, you need the mono runtime to run them under Linux, but it's the easiest way I've found so far of making windows programs from Linux).
* It's fun hacking side-to-side with a friend.
* It's fun learning new languages.
The downsides:
* It's hard to find info on how to use the compiler from the command-line.
* The mono runtime is quite large.
* monodevelop sets the "runtime options" for new projects to "MONO/.NET 1.1", which means there's a lot of things you don't have (apparently, I'm no expert).
* It seems hard to link C programs to mono apps, making many of my libs useless (well, in need of rewrite, anyways).
Next time we'll probably write a GUI program, which I've never done. My secret plan is to learn this stuff well enough to write a git GUI for windows.
11/11/08 01:50:52 pm, 
4 comments
I have comments on a few of your points...
* MD defaults to the .NET 2.0 "profile" of Mono since 0.18 IIRC, and I'd recommend updating to the stable MD 1.0 at least. We're about to ship MD 2.0 Alpha 2 with debugging and C#3 support, and both are really exciting!
* Invoking C code from .NET/Mono is actually incredibly easy in simple cases, though it can get tricky when you try to marshal complex data (see http://www.mono-project.com/Interop_with_Native_Libraries).
* A minimal Mono is actually pretty small (3.7MB), but installations tend to include all the extras. It can be shrunk down even further in special cases, e.g. embedding: http://www.mono-project.com/Small_footprint
* You have a few options with GUIs. There's GTK#, for which MD has a designer (and MD uses GTK# itself). It's cross-platform, though you'd have to install GTK# on .NET to get it to run on Windows. There's also System.Windows.Forms, which has a designer on Windows, but looks ugly on Linux and Mac. There are also things like Cocoa# (Max), Qyoto (Qt), etc.
* Regarding git, we've actually been investigating porting JGit to C# so we can add a cross-platform git VCS provider to MD (MD currently only support SVN). I don't suppose you'd be interested in this? ;-)
I've been programming C about 16 years, and object-oriented PHP for the past 3, so I'm not surprised I can pick up a mix of the two quickly ("master one, master all", style of thing).
I've got MD 0.19, and it defaults to the .NET 1.1 platform. Is there some setting I can change, perhaps?
As for porting jgit to C#, I'd definitely like that (although my C# fu is still weak). What kind of functionality do you need in MD?
Michael pointed me here.
I was curious, why do you think that you can assign null to int?
The only case where this is possible is if you use a feature in C# called "nullable types" which exist basically to deal with situations where a value might not have been set, and that is a different type (it is written "int? a").
Miguel.
Yes, I'm aware of that. I just think the entire feature complicates rather than simplifies, that's all. :)
As for memory consumption, it would be as bad or better to use a separate variable that says if the original one has been set or not, and it would make the code quite a lot clearer imo.
This post has 4 feedbacks awaiting moderation...