Mono 2.6 Released, Supports LLVM Generation

[kraftman]

The point is C#, Java apps are slow like hell and consume many resources and C, C++, QT apps are very fast and consume less resources.

@Blackstar

I don't know what you're trying to proof here, but I found very funny reading your arguments.

"Slow" without qualification is meaningless. Slow in what way? On what hardware? Compared to what?

Are you kidding? Let's say compared to QT apps.

[kraftman]

You have no technical arguments so you resort to making stuff up. Great!

You're not sane if you consider link at MS site, about MS product is a technical argument.

Since you seem to fail in reading comprehension, let me break my Qt-related argument down for you:
1. cross-platform toolkits add bloat compared to using native APIs directly (utorrent and ktorrent measurements illustrate this nicely).

Which measurements exactly? If those "measurements" I provided are correct it means QT is less "bloated" then native Windows API*, because Ktorrent which has more features consumes less memory then uTorrent.

2. due to #1, using Java or .Net as cross-platform toolkits means bloat, exactly like using Qt as a cross-platform toolkit.

If you meant a word "bloat" it's maybe correct. However, if part about Ktorrent and uTorrent is true, it means (like I said above) QT is less bloated then Windows API* and someone who claims QT is bloated the same way as .Net or Java is must be stupid.

3. to reduce bloat, you have to get your hands dirty and use native, platform-specific APIs directly, no matter what language you use.

How is it related to .Net or Java? Those languages are made to NOT get your hands dirty and to NOT use native, platform-specific API!

It is you who have made three ridiculous claims:
1. Java and .Net are too bloated for mobile devices (source)
2. Java and .Net are too bloated for the desktop (source)
3. There are no fast .Net apps (source)

2 and 3 are definitely true. I don't know about 1, but it's probably also true. At least they're too bloated for me.

All three claims are trivially simple to disprove:
1. The vast majority of mobile applications is written in Java (for Android, Nokia, Samsung and most other mobile phones), .Net Compact (for Windows Mobile) and, more recently, Objective-C and Mono (for the iPhone).

2. There are literally thousands of desktop applications written in Java and .Net or heavily relying on those techonologies: Eclipse, NetBeans, Visual Studio, MonoDevelop, SharpDevelop, Second Life, Sims 3, Unity3d, Paint.Net, Ati Control Center, Gnome Do, Banshee, Tomboy and every single XNA game.

And they're slow as hell.

3. Second Life started using Mono in order to improve performance (source). Not to mention all those XNA games.

This 'proof' makes me laugh - it's at page about Mono.

Do you understand that you have no argument here? You have made three ridiculously wrong statements and failed to provide any evidence to back them up.

Edit: spelling.

It is you who fell to proof a thing.

* or it means Ktorrent is less bloated then uTorrent, or it means even something else...

[Apopas]

So, do you believe that ASM-> C++ entails a bigger drop in performance and dev time compared to C++ -> C# or a smaller drop? Why?

You answer to my question with a question?

Commendable, but the vast majority of users don't choose applications like that. For example, KDE 4.x is more bloated than KDE 3.x, but almost everyone prefers the former over the latter (before someone takes issue with this again, I'm not saying KDE is bloated in absolute terms. As far as I'm concerned, it could be the most efficient DE ever conceived, but it's a fact that 4.x consumes more resources than 3.x).

In fact every user chooses the desktop/apps which gives them the best experience. This experience contains and the part of performance and because of that part a lot of people still prefer the venerable KDE3 instead of KDE4. Go to kde-look and kde-apps and you'll see that KDE3 is still alive and quite popular. But yet, the KDE developers succeeded to make version 4 fast enough, identical with KDE3 in most cases. Much faster ofcourse than Mono apps. While on the other hand Gnome developers don't do the same when they choose to build on Mono.

You display a strange sense of entitlement here. OSS developers don't owe you anything. They don't answer to you - they are free to use *their* technology of choice to develop the applications *they* like. You get to decide if you wish to use their applications or not (for technical, political or personal reasons) - you don't get to dictate their development methodologies, at least not directly.

Calling OSS developers egoists because they don't cater to *your* specific needs is flat out wrong.

Hey, I used the definiton customers as well, because I didn't speak for FOSS developers only but for proprietary as well. If I pay for the newer version of a software to find it sluggish and slower than the previous one, then it's obious that its developer proved to be rather selfish since he got my money but didn't thik the most important part of my experience as a user.
Now, if a FOSS developer chooses to do the same is totally up to him, since as you said I do not pay him. I won't disagree ofcourse but think it a bit differently. It's a totally irrelevant thing to build an application and a widely adopted desktop environment. Since the first one is usually developed by one indivindual or a small team while the second one by a community. The first one is going to be chosen between dozens of other similar apps, while the other one (ie Gnome) is the default environment of half the amount of users around the world and most of them consider their DE as the operating system itself. So, the developers by choosing to build the future of Gnome in a way a vast amount of people don't want, is rather selfish. Ofcourse if they choose to make mono an indepedent part of the actual OS and not a part of its core is aceptable, otherwise is not since we see the improvements of KDE which proves the things can be done differently.

[BlackStar]

Edit: ninja'd. This post refers to kraftman.

Facepalm.

Ok, your rational arguments have forced me to admit defeat. Mono sucks and should me obliterated from the face of earth.

Have a nice day.

[kraftman]

In fact every user chooses the desktop/apps which gives them the best experience. This experience contains and the part of performance and because of that part a lot of people still prefer the venerable KDE3 instead of KDE4. Go to kde-look and kde-apps and you'll see that KDE3 is still alive and quite popular. But yet, the KDE developers succeeded to make version 4 fast enough, identical with KDE3 in most cases. Much faster ofcourse than Mono apps. While on the other hand Gnome developers don't do the same when they choose to build on Mono.

KDE4 can be sometimes slower then KDE3, because of graphic card drivers. When I had nVidia card it was unusable, because of incredibly slow 2D. Today, it's much, much better with nVidia (but not so good as with OS Radeon driver ;>). However, graphic drivers won't make Mono fast or just not so slow.

[Apopas]

@kraftman

I only know that KDE-4.3.4 in my 5 years old Athlon with 8500GT is a true pleasure
On the other hand though, 1.5 GB of ram sometimes seem to be little which wasn;t the case with Gnome

[BlackStar]

So C++/assembly = C#/C++ in terms of performance and time a developer needs to complete a program? I highly doubt about that.

So, do you believe that ASM-> C++ entails a bigger drop in performance and dev time compared to C++ -> C# or a smaller drop? Why?

You answer to my question with a question?

Yes, you didn't say which jump you think is larger. Personally, I find the asm -> C++ transition as larger than C++ -> C#, mainly because the former hides two paradigm shifts (CPU-specific to CPU-agnostic and procedural to object-oriented), while the latter only one (native code to managed code).

Time has proven that the first two transitions were a net win (precious few people code in asm nowadays and even fewer complain that C++ is too slow for desktop applications anymore) and I believe that time will prove the native -> managed transition to be a net win. Note that I don't think .Net is the final word as far as managed environments are concerned, but it certainly seems to be a strong contender in this space right now.

Hey, I used the definiton customers as well, because I didn't speak for FOSS developers only but for proprietary as well. If I pay for the newer version of a software to find it sluggish and slower than the previous one, then it's obious that its developer proved to be rather selfish since he got my money but didn't thik the most important part of my experience as a user.

No argument from me here. If I payed for an application and it happened to perform worse than before, I'd be pretty pissed off at its developers, too.

It's a totally irrelevant thing to build an application and a widely adopted desktop environment. Since the first one is usually developed by one indivindual or a small team while the second one by a community. The first one is going to be chosen between dozens of other similar apps, while the other one (ie Gnome) is the default environment of half the amount of users around the world and most of them consider their DE as the operating system itself.

Absolutely agreed.

So, the developers by choosing to build the future of Gnome in a way a vast amount of people don't want, is rather selfish. Ofcourse if they choose to make mono an indepedent part of the actual OS and not a part of its core is aceptable, otherwise is not since we see the improvements of KDE which proves the things can be done differently.

However, here you are extrapolating from your personal preferences (native apps, no Mono) to the world ("a vast amount of people don't want"). Yes, there are people who don't like Mono. No, I don't see why Gnome developers should base their decisions on what those people like or dislike.

Personally, what I want is a stable, usable environment for my day to day use. If Gnome developers think they can do that with Mono, Python or freaking Javascript, that's fine by me. If KDE developers think that Qt and C++ is the best way, that's also fine. For me, it's the result that matters.

If I find the result subpar, I can always:
1. file bugs for my issues, or
2. try to fix those issues myself, or
3. replace the offending applications, or
4. switch to a completely different desktop environment or distro

However, what I won't do is try to impose my personal likes and dislikes upon other people and *especially* the developers of the software I use (in other words, I will file a bug for a performance issue in e.g. Gnome Do, but I won't say "you should rewrite this application in Qt because I dislike GTK"). This is basic courtesy, it's their software after all.

If worse comes to worst, there's always the aggressive fork approach taken by Gnote and numerous other applications (wasteful? Yes. But sometimes it's the only way to get something done).

[kraftman]

@kraftman

I only know that KDE-4.3.4 in my 5 years old Athlon with 8500GT is a true pleasure
On the other hand though, 1.5 GB of ram sometimes seem to be little which wasn;t the case with Gnome

Good to hear this Btw. system monitor usually reports 300MB for me on 64bit system. This looks quite strange, KDE 4.x worked fine with only 512MB.

@Blackstar

Personally, what I want is a stable, usable environment for my day to day use. If Gnome developers think they can do that with Mono, Python or freaking Javascript, that's fine by me. If KDE developers think that Qt and C++ is the best way, that's also fine. For me, it's the result that matters.

I bet results also matters for other people. It seems you deny to what you were claiming before. If only results matters to you, it should be in your interest to support faster toolkit which QT is and which is able to give you better results then Mono.

[Apopas]

System monitor usually reports 300MB for me on 64bit system. This looks quite strange, it worked fine with 512MB too.

Yeah same here. I reports less than 400 MB when I boot the system. But the preview files takes alot of RAM and when I browse my picture and video folders while play some videos, ti soon begins to use swap memory.

[Apopas]

However, here you are extrapolating from your personal preferences (native apps, no Mono) to the world ("a vast amount of people don't want"). Yes, there are people who don't like Mono. No, I don't see why Gnome developers should base their decisions on what those people like or dislike.

Personally, what I want is a stable, usable environment for my day to day use. If Gnome developers think they can do that with Mono, Python or freaking Javascript, that's fine by me. If KDE developers think that Qt and C++ is the best way, that's also fine. For me, it's the result that matters.

If I find the result subpar, I can always:
1. file bugs for my issues, or
2. try to fix those issues myself, or
3. replace the offending applications, or
4. switch to a completely different desktop environment or distro

However, what I won't do is try to impose my personal likes and dislikes upon other people and *especially* the developers of the software I use (in other words, I will file a bug for a performance issue in e.g. Gnome Do, but I won't say "you should rewrite this application in Qt because I dislike GTK"). This is basic courtesy, it's their software after all.

If worse comes to worst, there's always the aggressive fork approach taken by Gnote and numerous other applications (wasteful? Yes. But sometimes it's the only way to get something done).

Do I? check even here. We all say no ro Mono apps and you'are the only one and few others maybe who say the opposite. It's the same with java apps. The vast majority of end users find them sluggish and slow, so here we don't have few people who try to impose personal opinions but a large percentage. Even if is not the vast majority, is still a big part. And if you combine it with the fact that a lot don't want Mono for philosophical and political reasons as well (despite if you agree with them or not), we have a whole population of unsatisfied users. Now if the things lead to fork as you said, then this will be the biggest proof that Gnome's developers choosed the wrong option. because as I said earlier, it's a tottaly different thing to fork an app and totally different to for a popular desktop environment.