Mono 2.6 Released, Supports LLVM Generation

[he_the_great]

EDIT: As for the other point, it had better be something profound; general purpose programming languages are general purpose.

The second point wasn't directed toward you. but yeah.

[sreyan]

Because it is at great risk of Microsoft-control, since C# is a Microsoft-created Microsoft-specific programming language. Besides, it is almost exactly like Java. Why not just use Java, since it is Opensource?

C# is an ECMA standard. Yes it is Microsoft created but this means nothing there. Microsoft does have patents on .Net of course. Which might pose a problem.

Yes it is almost like Java except C# has:
Operator Overloading
User Defined Casts
Explicit Interface Member Implementation
Delegates/Lambdas

Of course you don't have to have these features since they don't really get you anything new but they do save time.

My time as a developer is valuable.

[smitty3268]

Yeah, C# started out as a clone of Java, but it's far surpassed it.

Remember when Java didn't have enums? These days features like partial classes, lambda expressions, and variable and dynamic types, all make Java look rather restricted in comparison.

The event handling system is much nicer as well, and a lot of stuff is nicer from a c-ish perspective, like operator overloading and unsafe code blocks.

Now, all that said I'm still not sure I think C# is something a desktop app should be written in. I think the only one I've used so far that seemed good was Paint.NET, and I'm sure they went to a lot of work to make that run as well as it does.

[Hoodlum]

My time as a user is also valuable and mono/.Net/Java are horrible, slow and painful to use for a user compared to traditional C/C++ software. The fact F-Spot / Vuze and the like have any start up time at all is a travesty, look at (for a windows example) utorrent. That is how software should be. Easy to use, quick and memory efficient. Sure you could say that i'm one of those powerusers that prefer extremely minimal interfaces(though utorrent isnt exactly) that get the job done quickly (aren't we all here? I assume we all use the command line) but I also know average users *DESPISE* this bloated crap that java and .net produce. It almost as much a scourge as flash is on the internet.

Heh, every day there are just more and more reasons to stick to KDE 4.3+.
I was a gnome user since it's inception, when very few even considered it but the stagnation recently has just been too much. The fact it still not only looks but feels and is used in a similar way to windows 2000 without a tremendous amount of customization is a joke.

They've been spending the last few years catching up to kde 3 on the app side (ie remaking what we already had but in GTK - a waste of time and effort) and totally forgotten about the basics, y'know the actual interface, not just "lets not have more than a billion check boxes as it confuses users" - that is obvious. I mean the whole experience, being able to get on with it as you would any other modern interface without a large amount of hassle customizing. Yeah I'm sure someone will come in and mention gnome shell - and yes I do think it will be an improvement (how could it be worse?) but it remains to be seen how much of one.

On the GTK side that is another horrible toolkit. I'm sure it's very good for the gimp and other such image manipulation apps - it is very flexible but it's also slow. Both to develop with and in performance. I dunno I just really don't see much "gnome specific" innovation coming out. I see things like gstreamer that are brilliant and I wouldn't change at all and other gnome-started initiatives but I don't see much unique to gnome that is really any significant improvement in recent times. The majority of changes seem to be things like brazero - great app btw - but it is essentially K3B (which has been around for years) remade in GTK. Just a huge waste of time. QT is not the scourge, you can use KDE apps without being the son of the devil. It is very tiresome seeing the same things remade every other day when people could just work on visual qt-gtk integration and avoid all this wasted effort so we can focus on things we actually lack for once.

In summation I'm in favour of not remaking the same apps in a different language / toolkit / whatever for no other reason than whim. I'm also in favour of a good user experience such as what you get qith a QT app, fast, can be visually attractive. Unlike the Java / Mono experience - Slow. Oh and for reference I have serveral fast PCs. The only one I cannot tell between a Java / Mono app and "the real thing"tm is on the one machine I have an SSD in. You shouldn't need an SSD to make a lightweight application instant. That is unacceptably horrendous performance. We might as well go back to visual basic if we care about development time over user experience and end result.

[BlackStar]

My time as a user is also valuable and mono/.Net/Java are horrible, slow and painful to use for a user compared to traditional C/C++ software. [...] look at (for a windows example) utorrent. That is how software should be. Easy to use, quick and memory efficient.

[...]

I'm also in favour of a good user experience such as what you get qith a QT app, fast, can be visually attractive.

I'll get back to the other points when I return from work, but I have to comment on this: you cannot recreate utorrent on Qt. You simply cannot. If you try, it will be slower, much more bloated and (probably) less visually attractive than the current implementation.

It is not the choice of language that makes utorrent so lean and mean (although it certainly plays a role) - it is the choice to kill portability in favor of efficient, platform-specific code. Vuze is so huge and bloated in comparison, *mainly* because it tries to be generic and cross-platform, which means duplicating and recreating a huge amount of code and/or using a huge and bloated cross-platform toolkit (like Qt, Gtk or wxWidgets).

You could reproduce utorrent in C# with minimal size overhead if you resorted to invoking win32 directly and ngened the resulting binary (this means native code, i.e. no JIT on startup). Yeah, this translates to no WinForms, no GTK#, no WPF - but it can be done, if size and startup times are your greatest concerns.

The issue is not that Java/Mono/.Net/Python are inherently horrible. The issue is that developers relying on those technologies generally favor other things than pure speed and memory consumption: stability, ease of development, ease of maintainance. However, good Java/Mono/Python developers can and *will* optimize for startup time, speed and memory consumption (check out Paint.NET for an example). The disparity you are seeing is a matter of priorities rather than an unsolvable issue.

[kraftman]

Have you used a language that isn't C/C++, specifically C#? Either you don't know what problems are C# is trying to solve or you don't know what it is like to program in a language where those problems are solved.

Your talk is similar to C# followers propaganda like the one Icaza.

I'll get back to the other points when I return from work, but I have to comment on this: you cannot recreate utorrent on Qt. You simply cannot. If you try, it will be slower, much more bloated and (probably) less visually attractive than the current implementation.

Tell this Ktorrent devs. Btw. can you tell my why? While QT is cross-platform can you proof its apps can't be optimized for Linux in example? And why ktorrent launch as fast as utorrent, looks better or not worse and even have more options? Btw. mentioning performance when talking about C# is very funny.

It is not the choice of language that makes utorrent so lean and mean (although it certainly plays a role) - it is the choice to kill portability in favor of efficient, platform-specific code. Vuze is so huge and bloated in comparison, *mainly* because it tries to be generic and cross-platform, which means duplicating and recreating a huge amount of code and/or using a huge and bloated cross-platform toolkit (like Qt, Gtk or wxWidgets).

You could reproduce utorrent in C# with minimal size overhead if you resorted to invoking win32 directly and ngened the resulting binary (this means native code, i.e. no JIT on startup). Yeah, this translates to no WinForms, no GTK#, no WPF - but it can be done, if size and startup times are your greatest concerns.

The issue is not that Java/Mono/.Net/Python are inherently horrible. The issue is that developers relying on those technologies generally favor other things than pure speed and memory consumption: stability, ease of development, ease of maintainance. However, good Java/Mono/Python developers can and *will* optimize for startup time, speed and memory consumption (check out Paint.NET for an example). The disparity you are seeing is a matter of priorities rather than an unsolvable issue.

Show me example. I can show you if you want: tomboy and F-spot - increadibly slow and bloated. I don't want someone to sacrifice speed and memory usage for easy of development or maintainance. I wouldn't care about Gnome, you can put there whatever you want and make it slow cow, but till it's important Linux DE, so I don't want to make it depend on trash like mono etc. You've got to be kidding about stability, because java apps I tried usually weren't stable.

[Hoodlum]

Before I start I want to make clear that I do not care about the ongoing philosphical debate about mono - this is purely about the factual performance divide and inferior user experience with it.

I'll get back to the other points when I return from work, but I have to comment on this: you cannot recreate utorrent on Qt. You simply cannot. If you try, it will be slower, much more bloated and (probably) less visually attractive than the current implementation.

KTorrent is a good example of a fast memory efficient QT client - it is faster than all of the mono or java clients out there. It is as fast even on a P III 600mhz I have in the other room. This just lost you any kind of credibility. Have you even used KDE before? Deluge using GTK is okay. Though not quite up to utorrent / KTorrent levels but that's because of gtk - it is still infinitely faster than any of the mono/java clients.

It is not the choice of language that makes utorrent so lean and mean (although it certainly plays a role) - it is the choice to kill portability in favor of efficient, platform-specific code.

This is somewhat true, but another good example would be gnote vs tomboy. Tomboy is a joke in terms of performance by comparison and it barely does anything. If i wanted a version of gedit that was 500x slower java or .net would be my choice - but nobody does.

Vuze is so huge and bloated in comparison, *mainly* because it tries to be generic and cross-platform, which means duplicating and recreating a huge amount of code and/or using a huge and bloated cross-platform toolkit (like Qt, Gtk or wxWidgets).

I'm not sure I agree with this, mostly because there are huge numbers of examples that show this to be false.

Ever remember Overnet? (progression of edonkey that made KAD that emule and the like currently support popular). Qt based, ran on windows linux and mac, used almost no ram(sub 20mb, possibly half that), extremely fast even on 500mhz processors or the like. Oh edonkey is another example of the same, Teamspeak, Mumble, any KDE apps the list goes on and on.

So it shows that this simply is not true - even with the same type (p2p) of app. Try KDE on windows (any app, they are all fast and memory efficient) - Then try Vuze or pretty much any java or .net app - they run like crap. Hell I even have a small app for eve online (EvE Mon) built for *windows only* which takes up very little disk space(just a skill monitor that ticks up essentially) - it still runs like a dog compared to say the opera browser which does far more.

So this brings us to one of three conclusions, either:
1) There are 0 people in the world who know how to write .net apps efficiently (unlikely) or
2) The language makes it so difficult / impossible to do so that no one actually has (possible) or
3) By doing so you give up the very reasons to pick the language in the first place (likely).

Any of which make it a bad choice.

You could reproduce utorrent in C# with minimal size overhead if you resorted to invoking win32 directly and ngened the resulting binary (this means native code, i.e. no JIT on startup). Yeah, this translates to no WinForms, no GTK#, no WPF - but it can be done, if size and startup times are your greatest concerns.

Two things:
1) The result would be inferior to anything else were you to do this UNLESS you spent significantly more development time on it (defeating the point) and
2) If you're not using JIT you might as well be writing in C/C++ anyway - It's like a solution looking for a problem.

The issue is not that Java/Mono/.Net/Python are inherently horrible. The issue is that developers relying on those technologies generally favor other things than pure speed and memory consumption: stability, ease of development, ease of maintainance.

Can you find a single example of a fast .Net app? I have never seen one - I have seen apps that are fast *for .net apps* but nothing that compares to C / C++ and there is a reason: it is not designed to compare in speed to those. But as i said before - if we're going the route of quick / easy development and forgetting about the user experience like this we may as well be using visual basic or something equally as horrendous.

However, good Java/Mono/Python developers can and *will* optimize for startup time, speed and memory consumption (check out Paint.NET for an example). The disparity you are seeing is a matter of priorities rather than an unsolvable issue.

I have used Paint.NET it is a good app and quick for a .net app. Of course I could compare it to Krita which is infinitely faster on any platform you want to try it on, though.

Again it is a suboptimal choice. And no I'm not saying QT is the savior of the world, it isnt, but I am saying that .net/java still massively lags behind in terms of performance with no actual benefit on the user side, only negatives. It seems the only way in which you can actually get it to perform well (by comparison to C/C++ in this case) is by giving up the very features you picked the language for - so why bother with it at all?

It is simply not acceptable (from a user standpoint) for you to require what I have on my main machine to run these apps as quickly as C / C++.

Here is an example in the case of tombody vs gnote

Significantly slower than gnote on:

2.4ghz dual core laptop
4gb of ddr3
500GB drive (32mb cache sata 3gb/sec)

_ This is what it takes for there to be no noticable difference _

4ghz Quad core
8gb 2000mhz 9-9-9-24 DDR3
The fastest 120GB SSD you can buy.

Until this is solved (it wont and can't be because of the design) it is simply not a good solution.

There is a reason Java / .Net aren't used as the main platform on which all mobile apps are based (an area where cross platform portability is of upmost importance - an area they would shine if it were possible for them to perform well). It is because there are limited resources. They are so significantly slower that neither are used for this. I should also point out how well maemo runs - currently based on GTK and moving to QT in that same situation.

Unfortunately resources are always limited with any device so they will not be considered until performance no longer matters. This will never be the case because we will always use that performance to do more with the same device - so again they fill no role and fit no niche. A solution looking for a problem.

[kraftman]

For a comparison:

utorrent (32bit WinXP) - 8MB+
qbittorent (utorrent equivalent, 64bit Kubuntu) - 12MB+
ktorrent (two torrents running, some plugins enabled, 64bit Kubuntu) - 15MB+

Put your favourite C# or java bittorrent client here

I bet qbittorent and ktorrent can consume even less memory if you'll use some compiler flags. Btw. utorrent != qbittorent, but maybe it shows we can mark the part about memory usage as a myth.

[BlackStar]

KTorrent is a good example of a fast memory efficient QT client - it is faster than all of the mono or java clients out there. It is as fast even on a P III 600mhz I have in the other room. This just lost you any kind of credibility. Have you even used KDE before? Deluge using GTK is another example of the same thing.

I won't get into the KDE vs the world debate, we've been there before and there are more than enough threads for that discussion. I will simply state that KTorrent is not as efficient as uTorrent as far as disk space or memory consumption is concerned and that is a fact.

Go on, check yourself: ktorrent and utorrent. The first uses a 2MB bootstrap installer (that then downloads Qt and half the internet for installation), while the latter is a 282KB standalone application.

(Edit: see also kraftman's results above).

*That's* the price you pay for going cross-platform (and if you think Qt is lightweight, you are either insane or you haven't tried building its source manually).

This is somewhat true, but another good example would be gnote vs tomboy. Tomboy is a joke in terms of performance by comparison and it barely does anything. If i wanted a version of gedit that was 500x slower java or .net would be my choice - but nobody does.

I challenge you to compare the two applications on features, disk size and memory consumption. *Prove* that Gnote is better - or don't mention this at all.

Ever remember Overnet? (progression of edonkey that made KAD that emule and the like currently support popular). Qt based, ran on windows linux and mac, used almost no ram(sub 20mb, possibly half that), extremely fast even on 500mhz processors or the like. Oh edonkey is another example of the same, Teamspeak, Mumble, any KDE apps the list goes on and on.

Does any of those "efficient" KDE apps run on a 486 with 16MB of RAM? Because utorrent does.

See, I can move the goalposts too. Computers become faster and delevopers take advantage of this.

Also Opera doesn't use Qt on Windows, it uses native APIs directly.

So this brings us to one of three conclusions, either:
1) There are 0 people in the world who know how to write .net apps efficiently (unlikely) or
2) The language makes it so difficult / impossible to do so that no one actually has (possible) or
3) By doing so you give up the very reasons to pick the language in the first place (likely).

Any of which make it a bad choice.

You forget another possible conclusion:
4) use a less efficient, more bug-prone language like C++, thinking it will magically make your code "faster" and more "memory efficient". Hint: neither of these is true, even for very experienced developers

(Edit 3, summary of the link above: the unoptimized C# implementation run faster than several iterations of the C++ version. It took 6 iterations for C++ to finally beat C# - and this is for some of the most experience developers you could possibly find out there!)

Gain some real-world development experience and ask yourself which is the best choice again.

Two things:
1) The result anything else were you to do this UNLESS you spent significantly more development time on it (defeating the point) and
2) If you're not using JIT you might as well be writing in C/C++ anyway - It's like a solution looking for a problem.

Point #1 is true, but you should keep in mind that: (a) in many cases, the app is fast enough already and (b) even with the extra optimization you'd still likely complete your app sooner than you'd be able to complete the (unoptimized) app in C++. Which is why Google for example uses "slow" Python rather than "fast" C++.

Point #2 is where it becomes obvious that you have absolutely no idea what you are talking about. Ahead-of-time compilation is a post-processing step that takes your jittable binary and converts it to native code for the target system. It is an installation-time or compile-time procedure. You are still writing in C#, this procedure simply ensures your code will start up and run faster.

There is a reason Java / .Net aren't used as the main platform on which all mobile apps are based [...]

iPhone is Objective-C and Mono. Android and every other mobile phone runs Java.

Edit 2: spelling.

[BlackStar]

Care to back that one up? There are a few things in favour of Java as a language and implementation compared to C#:

- (Full) Support on more clients - BSD, Solaris, Linux, Mac
Even with all the polish mono has been gaining, when working with modern features of .Net, you will still have problems(Especially with the whole Window Preserwtf crap). Those are facts.

- Java version numbers vs. .Net version numbers
Like with everything Microsoft did they fell into the hole of the ol' Service Pack. While it's certainly possible to develop and test for certain releases of .Net, it's impossible to test whether your stuff works with certain Service Packs/Patches, which do break things like API. Especially fun when coding for things like Windows mobile, where you have no physical access to the device.

- Namespaces vs Packages
Seriously, am I the only one creeped out by this?

Also in terms of Web-support(which granted, shouldn't be a job for C# in the first place), frameworks out of std, and of course deployment/ developer tools Java easily takes the crown.

Which leaves you with speed, C-like syntax, a good std-lib/framework...

Gotta agree with you on the python-part, even though I just started learning that...

Yup, C# has anonymous methods, lambdas, events, extension methods, linq, better generics, better exceptions, value types and unsafe code (when you need it) - yes, all of these features really *do* make a difference in development efficiency. Java has a more mature runtime, but that's about it...

I don't see how testing for a .Net SP is worse than testing for different Java versions. Empirically, I've had roughly the same number of issues running Java apps on different runtime version compared to running .Net apps on different runtime versions.

Namespaces vs packages - what do you mean? One of the most annoying things in Java is that filenames must match namespace/class names for public classes. Yes, it's good practice but enforcing it on the compiler level is *infuriating* for a large number of developers (myself included). Apologies if you meant something different.

Edit: web support is not a matter of language, it's a matter of library stacks. Personally, I think that Python beats both on this front, but that's just me. Other people swear by PHP, Ruby, Java, C# and so forth. Someone has even created server-side Javascript! I don't really see what this has to do with the language vs language argument.