Red Hat was the main opponent against the inclusion of Mono on their products or Gnome’s core. But this is all past now and Fedora Core 5 will include Mono and some of its front row applications like Beagle and F-Spot will be too. My Take: After I got tipped on Saturday about this, I talked to Mono’s founder, Miguel de Icaza, but he seemed to be genuinely unaware of the latest happenings on Rawhide. The great news will hopefully expand Mono and make GTK# the new recommended toolkit for future Gnome applications (although this is just a personal wish at this point).
Hell Freezes Over: Fedora Core 5 to Include Mono
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
…it’s so darn cold all of a sudden!
This is amazing news and also gave me some motivation to continue with my Mono application (instead of porting it to Python…). I’m just wondering what happened to the legal reasons which they could not tell us… and how they turned into “business-related and others were strategic in nature”. I trusted Red Hat on this, so I hope it’s just a minor misunderstanding. But that doesn’t really matter now.
Re: “business-related and others were strategic in nature”.
I believe this is good news both for Fedora Linux users and Red Hat’s business in general. The Red Hat developement change to include Mono probably had to do with realizing it’s better to at least match the competition than not offer the basic tools being provided by others such as Novell. After all the two biggest company names in the Linux community are Red Hat and Novell. For Red Hat not to offer tools that can compete with Novell leaves consumers and developers questioning Red Hat’s decisions. It’s good to see Red Hat is listening to users requests.
Edited 2006-01-11 01:19
fedora to ship mono is not enough… we need better mono ide! easy gui maker, integrate autopackage builder then your wish come true
edora to ship mono is not enough… we need better mono ide! easy gui maker, integrate autopackage builder then your wish come true
I suppose you could use glade, but some sort of eclipse plugin would be nice.
Edited 2006-01-10 06:36
Better mono ide? monodevelop is one of the better ide’s that linux offers. Eclipse or Kdevelop are (arguably) the best. Autopackage will not solve the world’s problems and it will make distromaker’s lives hell as it doesn’t integrate into native package management systems.
Autopackage will not solve the world’s problems and it will make distromaker’s lives hell as it doesn’t integrate into native package management systems.
http://www.autopackage.org/faq.html
Please read the above link (all information under General) and review why this is a good thing, not a weakness in the product.
Does the inclusion in Fedora Core imply inclusion in RHEL?
Not always. But maybe. Maybe just the server-oriented stuff.
I’m not a Gnome user, don’t envision myself being one any time in the forseeable future, I just simply don’t like it.
Having said that, I think Gnome offers much and has an important role for desktop linux. I’m of a frame of mind that, even though KDE is my preference, linux desktops do need choice and I think that Gnome and KDE, with all of the offerings in between and around them, offer enough choice to meet user’s requirements instead of forcing users to comply to their system.
I’m not sure I see the relevance of mono, I never really bought into it but then I’m not a developer so maybe I’m missing something. I did think, though, that mono could risk becoming divisive to the community, particularly with Red Hat’s opposition to and Novell’s funding of, and all of the arguments in between. So for that alone, I think it’s a good thing.
As I said, I want a solid Gnome offering if only to a) ensure choice and b) ensure the KDE team stays on top of their game. So everyone wins.
Now, having said all that, it is my sincerest hope this thread will not turn into a bunch of mindless “Woo hoo! Gnome owns the desktop even more now!” or equally mindless “Who cares, Gnome sucks!”. I wouldn’t mind seeing some practical discussion on what this really means and how it impacts Gnome’s future. I’m genuinely interested. So here’s hoping…
>this thread will not turn into a bunch of mindless….
You would have helped the situation by NOT writing this paragraph at all actually. Speaking from experience…
I’m not sure I see the relevance of mono, I never really bought into it but then I’m not a developer so maybe I’m missing something…
I wouldn’t mind seeing some practical discussion on what this really means and how it impacts Gnome’s future. I’m genuinely interested. So here’s hoping…
For me (a gnome user) this means a few things.
1. Red Hat giving support to the Mono project which means that Mono as a way to make really great Apps. for GNOME is available across the big gnome distributions.
2. For me Mono apps are the “killer apps” for Gnome. I can’t live without F-Spot, Muine and (when it becomes a bit more stable even more so) Beagle. Without these apps, Gnome and Linux are pretty useless to me (well not useless but a lot less nice to use!) which means that Fedora was pretty much useless to me. Now that Fedora includes Mono, I can choose between Fedora, Ubuntu or NLD which gives me, the user more choice
3. Hopefully it means more mono developers and more really great Gnome apps! Because Mono allows developers to make great programs quickly (or at least this is what I have heard) as Mono apps are developed quicker than C++ Gnome apps, it allows programs to be released quicker.
So in conclusion, I think that Mono on Fedora is a great thing! I can’t wait to see what this will do for the mono community, and this might just give me the motivation to install Fedora Core 5 on a spare box
Why can this not be good for KDE, too? Nothing is preventing the KDE libraries from being ported to .NET. Maybe they already are–I have no idea.
Can’t KDE benefit from the C# and the .NET framework in general, allowing more developers to contribute to the project?
“Why can this not be good for KDE, too? Nothing is preventing the KDE libraries from being ported to .NET. Maybe they already are–I have no idea.
Can’t KDE benefit from the C# and the .NET framework in general, allowing more developers to contribute to the project?”
yes, it could be good for kde, and there are actually already some c# bindings (tough unmantained because of lack of interest). but KDE needs it less – Qt already offers a much superior development framework over what gnome has to offer, and mono wouldn’t spead it up significantly. also, with high-quallity python, java and ruby bindings, the need for mono is simply very small. its not that mono is bad, its just that its not much better then what is already available for KDE.
… we are now able to wwrite more ccompetitive apps in sshorter time. The competition is between WWindows and not KDE.
Browser: Mozilla/4.0 (compatible; MSIE 6.0; ; Linux armv5tejl; U) Opera 8.02 [en] N770/SU-18_0.2005.51-1_PR
Heh, I see that you posted this with a Nokia 770, cool.
Hopefully someone will take the task to create a “Mono Mobile” version of the framework, like MS has as its “.NET Compact”.
Is your “w” key stuck in the mobile?
We have it already! Look at http://sourceforge.net/projects/openvpnadmin/
Browser: Mozilla/4.0 (compatible; MSIE 6.0; ; Linux armv5tejl; U) Opera 8.02 [en] N770/SU-18_0.2005.51-1_PR
>We have it already!
This is the full mono stack, not a compact version optimized for mobiles and/or PDAs. The N770 runs a full OS so it can run the full Mono, but most mobile phones can’t.
Other distributions, like Debian, had all Mono stacks for ages now.
Really, honestly. I don’t get what’s the benefit of Mono over other solutions. What advantages does it offer, what remarkable features does it have?
Does anyone have some links comparing Mono to other alternatives (compiled code and traditional libraries, Java, Python, whatever)? (Fair and unbiased comparisons if at all possible)
Please the question is sincere, not an excuse to engage in language/framework wars. Thank you.
Mono/.NET benefits: It’s a garbage collected virtual machine. That means easy programming and portability, like Java. It’s a JIT VM, so that means the portable code is fast. The design learned a lot from Java’s mistakes, so it’s much faster and the libraries are better.
And my favorite bit: While I wait for one Java application to load, I can launch THREE Mono applications. I seem to be able to fit three Mono applications in the memory space of one Java app, too.
Java benefits: It’s a garbage collected virtual machine. That means easy programming and portability, like Mono. It’s a JIT VM, so that means the portable code is fast. The platform is tried and trusted. It has seen much investment in the VM and the libraries which is why it’s superior to Mono.
And my favorite bit: While I wait for one Mono application to load (except it doesn’t, or the wrong framework is installed (they dont seem to handle compatibility)), I can launch FOUR Java applications. I seem to be able to fit Four Java applications in the memory space of one Mono app, too!
Well it’s called mono, java is even more than stereo.
Hrm, I like mono but I couldn’t resist..
btw mono=monkey in spanish.
I dont think your last paragraph is really needed – both .NET and Java have fast and slow applications; the end result simply being an indication of the amount of optimization the application developer has done.
To me there’s two reasons Mono is in favour:
– For developers, it fits comfortably in the language spectrum between Python and C/C++ . In other words, its (at least to some of us) more suitable for larger applications than Python, but permits faster development and is less bug-prone than C/C++.
– I’m not up on the specifics, but the .NET platform just seems to be superior to Java in terms of wrapping native C libraries. Gtk# being the obvious example for us linux users.
Yes java is another high level VM. We get it.
However, just discussing mono, and meaning absolutely no offense to java (hint, hint), there many nice things about it.
First, off is C#, which learned a lot from java.
Second, is the .net framework, which is very powerful.
Third, is that many languages can be compiled to CLR and thus you have language compatability and choice.
Fourth, it is used by many windows programmers, this allows windows programmers more access to developing on Linux.
etc, etc
I think you’ve missed the tongue-in-cheek of the original poster.
Yes java is another high level VM. We get it.
Yes .Net and Mono’s CLR is another high-level VM. We get it.
First, off is C#, which learned a lot from java.
First off is Java, of which C# is a clone. Sorry but there is simply nothing compelling in C# for your 9-5 programmer – only to technology wankers. The real gains are made in the framework, which as I’ll point out is less than perfect.
Second, is the .net framework, which is very powerful.
Second are the Java classes, which are very powerful. The .Net framework is basically a set of object oriented wrappers around Win32, and many namespaces and classes have incredible deficiencies and differences in usability for the programmer – especially in the way collections are used.
Third, is that many languages can be compiled to CLR and thus you have language compatability and choice.
Third, there are only two languages in use for .Net today – VB and C#, of which C# is the most popular. Because all languages needed to be ported to work with the .Net framework you always end up with a clone of C#, except with slightly different syntax. The selling point of .Net language neutrality has long since faded into obscurity amongst .Net people. Let it go.
Fourth, it is used by many windows programmers, this allows windows programmers more access to developing on Linux.
Fourth, Windows programmers want realistic development options should they move to Linux.
A .Net clone is all very well, but it has to work at least as well as Microsoft’s version, be 100% compatible, together with all the development tools they’re used to. Giving people a direct comparison between Mono and Microsoft’s .Net is a mistake.
Failing that Windows developers would rather see something compelling and and different with tools, suppliers and ISVs to help them port their applications.
etc. etc.
I’ve never heard so much gibberish, even from an MS salesman selling .Net. What is the Mono community these days? The Microsoft .Net marketing arm?
Edited 2006-01-10 11:01
http://www.awprofessional.com/articles/article.asp?p=27114
Have you ever heard of IronPython the python interpreter embedded into the umbrella known as .Net? I didn’t think so.
C# is more of an evolution of Java rather than a clone.
From the article
====
One of the advantages of .NET over the Java world is that developers can choose their language. Unlike the Java virtual machine, the .NET Framework’s Common Language Runtime (CLR) was designed to support multiple languages, and it does. COBOL, Perl, Python, Eiffel, and many others are available in versions based on the CLR.
====
I do agree with your “Fourth” statement, but your some of your others are mis-informed at best. Please get your facts straight before spreading FUD.
ya it support some language… but their language are not complete… only a part of the implementation has been created…
not sure is a big advantage to use many language for a projet
Have you ever heard of IronPython the python interpreter embedded into the umbrella known as .Net? I didn’t think so.
Yay, a Python interpreter in .Net. Like everyone’s using that for lots of everyday practical stuff and I doubt we’ll see lots of Python applications using it anytime soon. At best it’s an academic exercise and a nice day job for someone at Microsoft.
C# is more of an evolution of Java rather than a clone.
It’s a question of whether there’s enough there to make it evolutionary. People can debate that endlessly.
From the article
====
One of the advantages of .NET over the Java world is that developers can choose their language. Unlike the Java virtual machine…..
I’m sorry. Did I miss something? I’ve just given reasons, which every .Net developer who’s using it professionally knows about, as to why language neutrality is just bogus. You lose any point you had of using a different language when you port it to .Net.
It’s also wrong to say that a JVM can’t be used by different languages, but not surprisingly, language neutrality isn’t a big hit there either.
I do agree with your “Fourth” statement, but your some of your others are mis-informed at best. Please get your facts straight before spreading FUD.
Please do think before calling everything FUD please. I know .Net, and especially Mono, people really, really do not like to be told that the supposed language neutrality of .Net and the CLR/CLI implementation is pointless, but there it is. You’ve come up with absolutely nothing new which says otherwise.
Edited 2006-01-10 15:34
segedunum, it just gets tiring having to listen to your constant bashing of everything you think is bad. You get very emotional about it and it makes no sense.
I’m sorry I like the .net mono environment. I like it enough, and it works so well with gnome, that I will wait for the debugger, etc.
Personally I don’t think of things in terms of I like this and everyone who doesn’t has something wrong with them. Every mono thread you come out with that mentality, it seems you hold the same grudge against gnome. I personally like what I like and would never hold it against someone else for not liking it. Currently I use gnome and if people like KDE over it then more power to them, I certainly don’t have an issue with that.
Simply put, you take things too personally (or something).
Beyond this I hardly care to argue anything with you, I can’t imagine a more pointless use of my time.
You’ll probably argue back saying you’re just arguing the technical merits, etc but I can’t help but feel you just have a bone to pick.
So please don’t reply to this.
>there many nice things about it.
>First, off is C#, which learned a lot from java.
They borrowed several class names, this is really nice 😉
>Second, is the .net framework, which is very powerful.
Very powerful in what area? MS platform?
If I’d like to run some MS apps on linux,
I would choose wine or crossoffice.
>Third, is that many languages can be compiled to CLR and thus you have language compatability and choice.
This is simply not true. Even MS failed to port VB to .net. What they call VB.net is not a visual basic at all. If you take English language and replace all verbs by Russian it wouldn’t become Russian it would be Ruglish.
Same goes for .net all its so called languages are not languages they try to represent.
So, what are the benefits of using mono on linux and especially on GNOME?!!
Why not using Python,Ruby or JAVA?
Regards,
Vitaliy
“It’s a JIT VM, so that means the portable code is fast. The design learned a lot from Java’s mistakes, so it’s much faster and the libraries are better. ”
I don’t know about memory use, but I think you’re giving far too much credit for speed issues. I haven’t really looked into it for a bit, but last I checked mono was significantly slower than sun’s jvm, which apart from selective benchmarking usually comes in pretty far behind c/c++. I find it to be an acceptable tradeoff for ease in coding, but I think it’s somewhat unfair to paint it as if the speed was anything but a “good enough.”
I haven’t any profiling, but the startup speed of a Mono application seems to be significantly better than a Java application.
Yeah yeah, personal subjective opinion, different applications, etc, etc.
What I can say is that waiting for Jedit to start (the little splash box doesn’t work at distracting me) is quite painful, but Muine just appears on screen with a 1 or 2 second delay at most.
To be more fair to Java, I’ve played with Java 6 a little, and startup time seems better.
I suspect Sun is responding to competition. .NET apps start showing up and suddenly startup speed is important.
Jedit uses Swing which is completely implemented in Java AFAIK, while Muine uses Gtk+ and gstreamer which are completely implemented in C, so this comparison seems a little off.
This is great news! Mono apps were badly needed in Fedora. I wonder if anything changed to make them reach this decision. The best thing about this is the rift that was created is now gone. Great news for gnome.
P.S. Yes the ide needs some work, but like all things mono, it’s getting there quickly.
P.P.S. At one point I know qt binding were being worked on, I hope that is still the case.
I think than more languages linux distro support out of the box the better.
re:The great news will hopefully expand Mono and make GTK# the new recommended toolkit for future
I don’t like the idea of making GNOME depended on Microsoft’s cur.
Why not using Python/Ruby or Java.
Now someone should fix Mono (or Mono apps). I’ve tried fspot few times and even on my Athlon64 3000+ it’s not fast, many Java apps feel faster even with Swing UI (for example Netbeans). Beagle is another story. After one or two days the process takes about 700-900M of memory, and even worse, the index files (in .beagle) take over 3 gigabytes of disk space!
I presonally think monodevelop is amazing. And with combination with glade2 you can develope mono apps easily.
But I belive with newer versions of Monodevelope and integration of Glade3 things will get much better.
http://primates.ximian.com/%7Elluis/blog/images/glade3.png
I presonally think monodevelop is amazing. And with combination with glade2 you can develope mono apps easily.
Please. Mono will never in a month of Sundays have an IDE, framework and community like Eclipse, and that’s what Red Hat are working on. (Netbeans as well come to think of it).
The development tools in particular, and the development and commercial communities are something that Mono will never have. There’s also actually a market (people paying money) for Java on Linux, server-side mostly of course. That’s what really matters, not a bunch of people getting excited over Beagle or wanking over what technology will be the standard toolkit. That’s what people around here just can’t understand.
Edited 2006-01-10 10:11
Oh brother, can you say anything without making it some kind of war?
I use jedit everyday and it suites my needs well. Good for java.
I use many mono apps as well and have started programming my own app in it and have been very impressed. Good for mono.
Is eclipse bigger, sure. Does that make mono any less of a development environment. NO!
I do seem to recall statistics showing the dramatic increase in .net development, primarily on windows. This may be windows but it makes mono that much more valid.
Why in the world does one have to detract from the other?
Oh brother, can you say anything without making it some kind of war?
Oh dear, can you not compare anything rationally without coming up with something daft and without comparing the wrong things?
Does that make mono any less of a development environment. NO!
Mono isn’t a development environment – MonoDevelop and Eclipse are. If Mono is ever to be taken seriously by anybody, including existing Windows developers, with all the hype you and others attach to it it needs a first rate development environment. It hasn’t got one.
I’ve shown Mono to a few died-in-the-wool Windows and .Net developers and they’re expecting the whole .Net framework with a Visual Studio environment to go with it. That’s what it’s going to take. As far as they’re concerned why bother with an inferior version on non-Windows platforms when you’ve already got the real thing on Windows? It strikes me that no one has ever tried out Mono on actual Windows developers who use .Net for a living. There’s this feeling that this whole Windows -> Linux thing will happen automatically as a result.
People aren’t interesting in taking things verbatim from Windows to other platforms. They simply want stuff that’s good enough.
This may be windows but it makes mono that much more valid.
Why do developers of on all platforms need to use a .Net clone?
Why in the world does one have to detract from the other?
You and others are the ones hyping it.
Is eclipse bigger, sure. Does that make mono any less of a development environment. NO!
The lack of a decent debugger is a big show stopper for Mono (in my eyes). Who the heck writes code that can’t be debugged? When will MDB finally be released and included as part of the standard Mono distribution?
I do seem to recall statistics showing the dramatic increase in .net development, primarily on windows. This may be windows but it makes mono that much more valid.
A lot of the productivity gained when using the .NET framework on windows is partly due to the excellent Visual Studio IDE. As yet, Mono has no IDE that is comparable to Visual Studio, or Eclipse. To say that productivity gained on Windows using Visual Studio is applicable to Mono is false logic.
The lack of a decent debugger is a big show stopper for Mono (in my eyes). Who the heck writes code that can’t be debugged?
Well if you want to write code in any sort of IDE then a debugger is mandatory. Writing a debugger can be a complex thing to do, however. Java, of course, has had years of development in this area and with Java app servers you can debug seamlessly over a network – something I badly miss when using other methods.
A lot of the productivity gained when using the .NET framework on windows is partly due to the excellent Visual Studio IDE.
Quite true. I think people get more than a bit confused between Visual Studio and simply the .Net framework because the two tend to be synonymous. If you look at the .Net framework and stuff like ASP.Net, many of the time saving things you can do are totally dependant on Visual Studio.
Java is by no means perfect in many areas, and Red Hat have quite a bit to do on their implementation, but to suggest that Mono is going to sweep all before it, based on what’s on offer, is a bit wide of the mark.
Who the heck writes code that can’t be debugged?
Actualy, I do. And it doesn’t even matter if debugger exists or not. I simply stopped using debuggers one day and replaced it with code execution in my head while reading code. One big benefit, brain excersize. And not even near as crash prone as debuggers. But that is just me and my preference, but you asked who…, so here I am.
As yet, Mono has no IDE that is comparable to Visual Studio
Wow, what a bullshit comment. Since you can use VS for Mono development. So yes, it has IDE 100% compareable to VS and it is named VS.
In my time I have learnt a number of things about linux. The first thing is that you cannot predict the future (example: Mono will *never* be in FC).
There already are nice Java tools to build native gnome UI’s.
Check this flash-video:
http://gladetojava.sourceforge.net/synchronizer.html
Red Hat really relies on Gnome and it was more important for them to partially heal the rift that was obviously growing than to see it keep getting wider. They probably also felt that they wanted to bolster the apps they have in Fedora and let people try out some Mono ones as well. You won’t see it in RHEL, nor will people be writing non-existent web stuff with ASP.Net.
The chances we’ll see Red Hat actually using Mono and using it for any development is pretty much non-existent. I know Eugenia thinks the sun shines out of .Net’s and Mono’s backsides but you’re not going to see GTK# emerging as some sort of recommended standard.
Red Hat’s development environment of choice is still going to be Java, but they look as if they’re concentrating on getting that completed from the server-end first and then to the desktop. It’s going to take quite a bit of work though.
yes, it could be good for kde, and there are actually already some c# bindings (tough unmantained because of lack of interest).
That was the Qt# project – I don’t think it failed for lack of interest.
I’m working on a new C# binding based on the QtRuby/Korundum bindings code and the language independent Smoke library, called ‘Qyoto’ for Qt3/Qt4 and ‘Kimono’ is the KDE superset. A first version should be ready in about a month or so. The code is under ‘trunk/playground/bindings/kimono’ in the KDE svn.
>That was the Qt# project – I don’t think it failed for lack of interest.<
Just out of curiosity, why did it fail then?
And are you able to use any of their work for Qyoto?
Just out of curiosity, why did it fail then?
Because the KDE people have Qt. I get the feeling that there just wasn’t enough to be gained from mapping Qt on to a .Net-like framework for it to be worthwhile.
This is just the type of news that makes .Net developers (such as myself) realize that the .Net platform (Mono in this case) has reached a mature enough level to have obtained approval by the *nix crowd. It’s about damn time. Incredible…
I’m not a programmer, but Mono strikes me as simply a means to an end, the end being a healthy ecosystem of good programs. I guess it is a little early to say whether that will happen. I’ve tried a few Mono programs but they are still too new and immature to do it for me and they seem to eat up an awful lot of memory. Maybe in a couple of years we’ll all be using them. But then again, maybe not. Red Hat’s move is surely a push in the right direction, though.
Have you ever heard of IronPython
Have you ever heard of Jython the Python interpreter in java? It has been available for years, even before .net existed. And all it does is really only give great examples of Python and it’s codebases versatility and flexibility.
Saying that something is the best gui builder for Linux isn’t saying much. I dare anyone to download Microsoft C# Express
(Free–http://msdn.microsoft.com/vstudio/express/default.aspx)
and tell me that anything on Linux comes anywhere near as close when it comes to development, form creation and debugging. For GUI apps everything else just pales in comparison. That’s what the parent poster is talking about.
Both Java and Mono (.Net) are nice languages/platforms/development tools). They serve their purposes – Java mainly on the server side with J2EE, and .Net mostly for quick and dirty Windows desktop apps (and now Gnome apps with Mono). I’ve even seen some fairly nice Java desktop apps (NetBeans, JEdit, Azureus, Limewire), and some nice Mono apps (Tomboy, F-Spot, MonoDevelop).
However, for desktop apps, nothing beats compiled C or C++ apps. For my day to day use, the slow load times and huge memory consumption of both Java/Swing/SWT and Mono/.Net/WinForms/GTK# apps get very annoying and counter productive. Without any exceptions, the apps I use that are done in C or C++ run faster, use less memory, are more responsive, are less buggy, generally look better, and deliver a better all around user experience.
For instance, KDevelop and QT Designer run much much faster than say, Eclipse or NetBeans, and use waaaaaaaay less memory. Another example is MS Office – my boss as 3GHz, 64bit CPU with 2 gigs of memory PC (one fast machine), and his installation of OfficeXP (which now uses .Net in it’s source code), has slow load times and slow response time (even on that ultra fast machine). Same goes with Visual Studio .Net (built with C#).
But many people argue that interpreted languages running in managed runtimes are the way to go – it’s much easier on the developer does not have to worry about manual memory management – just let the Garbage collector worry about it. But that comes at a huge price – the resources consumed by the VM, and tons of objects allocated out on the heap, and the CPU working harder. And JIT does not solve the problem completely. It improves it, but does not solve it.
And C and C++ programs don’t have to be hard, even with memory management. With C, you can use GlibC, GTK, GObject, the Win32 API, etc, and it gets easier. With C++, you can use references, smart pointers, the STL (with strings, vectors, and the like), plus you can use awesome libraries like QT, and the amount of manual memory management needed is minimized. Plus, what’s so hard about putting in a “Delete” for every “New” you have in your code? It isn’t hard – it’s just like putting in a closing curly brace for every opening curly brace. It just requires a minimum amount of discipline. Quite frankly, I’ve encountered very few C/C++ apps that had memory leakage or memory crash problems. Most of the C and C++ code I’ve written was not hard in terms of memory management. My company’s software is mostly C++ (upwards of 1.5 million lines of code), and memory management has not been a drain on productivity.
Even if a C/C++ app is very large and complicated and requires tons of manual memory management, there are tons of both free and proprietary profiling tools and memory leakage detectors, as well as both free and proprietary garbage collectors that can be used with C and C++.
It’s not that big of a deal.
Managed runtime languages have their place. But they will never be better than C or C++ for good desktop apps, in terms of end user experience. Afterall, ultimately, the end user experience is more important than developer convenience (or laziness/sloppiness).
Finally, if you are going to go for the greater productivity of interpreted/managed languages, and go with quick and dirty, you might as well go all the way and go with Python, Perl, Ruby, etc. Those are even more productive and easier. But if you want to build something of any size or capability or seriousness, in the end it is better to go with C or C++.
Edited 2006-01-10 18:08
and his installation of OfficeXP (which now uses .Net in it’s source code), has slow load times and slow response time (even on that ultra fast machine). Same goes with Visual Studio .Net (built with C#).
First I think that OfficeXP doesn’t use .NET and there aren’t slow load times (in a box like that) compared to Office 2000 for example. (XP loads faster and that’s not preloaded stuff). You don’t need .NET framework to use Office XP at all.
Visual Studio .NET is (afaik) not built with C# but with C++ (this I am not sure).
Or maybe I am wrong with both.
Despite that, I do not think that C++ is the best way to go. .NET offers Speed of Development and this is NOT Visual Basic 6 (lack of true OOP). Under .NET you’re playing the real game.
RAM consumition is more because the language needs more memory for its structures. Type Safety, GC, etc.. do not worry about the RAM.. worry about bad coding practices. RAM is cheap. Refactoring is not.
Ram is cheap, but in several years we will arrive at minimum usage of 32 GBytes and at the same time those applications will do the SAME routines as they are done right now and applications did already 1995.
Don’t believe me? Then explain me why all those antivirus applications, firewalls, browsers, text editors, drivers (e.g. ATI), control applications and hell, even Spyware need much more RAM than they did around 2000? In the end they have pretty the SAME amount of functions and didn’t get anything else.
With such attitude among programmers as “RAM is cheap, time isn’t” I could play a Nostradamus and already tell you how much RAM will Norton Antivirus will require to do the same routines (hash file, compare to the DB, go through assembly, emulate, catch IO modifications, update itself, draw a gui you get eye-cancer of) – half a gig.
Compare: the same things did NoAV 2000 behind its cancer-UI with MUCH LESS HUNGER. THE SAME FUNCTIONALITY.
It goes backwards, dear collegues.
You buy more RAM just because developer X isn’t capable of programming. Nice for him. And don’t blame managed apps for that – it is more programmer’s fault that he doesn’t release resources properly. I can understand that Firefox eats more Ram than Netscrape did (Multitabbing results more data in RAM) and I can understand that other apps which ADDED functionality grew in hunger <a bit>. But I can’t understand that I’ll require a gig of ram just to run a notepad/vim clone in a bunch of years just because development time was more important.
God<of your religion>, remove all those supercomputers (everything over 33Mhz) and let C64 rain. I hope they will learn.
AMEN REVEREND!
While I agree that Java’s GUI sucks (even those coded by Sun for Solaris9 admin tools which are dog slow, if even Sun is not capable to make fast GUI app in Java..).
I disagree about your points about C/C++.
> [C/C++] memory management has not been a drain on productivity.
Erm, for having a running application perhaps, but for having a *safe* application running?
When you see all these patch for buffer overflow, I wouldn’t be so trustful.
Sure there are GC for C and C++, but in pratice they are rarely used.
Python, Ruby are productive for small to medium program but Perl is a mess to maintain. Anyway I think that a million line project would suffer from their dynamic typing and optional variable declaration (ironically while Perl is a nightmare to maintain, AFAIK, it’s the only one to have ‘use strict’ which enforce mandatory variable declaration..).
There are good alternatives compiled, static typing and mandatory variable declaration with a GC: D, Ada..
But they lack momemtum: D too new, Ada too old, verbose.
re: While I agree that Java’s GUI sucks
many people think the same because of old implementations of swing
take a look at
Azureus – Most popular bittorent client
RSSOwl – my favorite RSS reader
Eclipse IDE – most popular open source IDE for C++,Java,Python,Ruby,PHP.
these apps were created with SWT/JFace a part of Eclipse platform (a competitor to sun’s swing).
btw Fedora5 will include ’em all.
If you want to see good examples of java swing GUI take a look at
JEdit – Reach file editor with lots of plugins
QNEXT and SPARK – very nice AIMs
JetBrains IDEA ,JBuilder, NetBeans – very powerfull IDEs (I prefer IDEA)
Swing is much faster now(java5) and it would be even faster in java6.
If we want a CLR for open source OSes, why not use Parrot?
The main thing I don’t like about Mono is that Microsoft gets to decide the direction it takes as long as the project seeks to be a clone of .NET.
Instead, I say, the open source community should “embrace and extend” .NET, in the same way .NET built on the experience of Java. Can we not make a better .NET than Redmond?
“The main thing I don’t like about Mono is that Microsoft gets to decide the direction it takes as long as the project seeks to be a clone of .NET. ”
They don’t… this is covered in the Mono FAQ, and Miguel talks about it in almost every interview about Mono.
The main thing I don’t like about Mono is that Microsoft gets to decide the direction it takes as long as the project seeks to be a clone of .NET.
That’s about the size of it.
Instead, I say, the open source community should “embrace and extend” .NET, in the same way .NET built on the experience of Java.
That’s exactly what Ximian should have done to start off with before they came up with this crazy idea. They should have looked at what was good about the .Net framework, the CLR and other parts of it, looked at the large market for Java on non-Windows platforms, what already existed in the open source world and natively compiled code and came up with something that was truly relevant. If they’d done that then the patent issues would have went away (any patents specifically only apply to compatible implementations) and they would have had a large potential market in Java in the non-Windows world and might have established Ximian as a successful business in their own right. Alas…….
Instead what we got was a load of tosh, most of it regurgitated from Microsoft, about how so much more productive .Net was when all of those supposed productivity benefits in just about all of those studies was down to Visual Studio! They then regurgitated a load of rubbish, again via Microsoft, about how applications and code written with .Net were just as fast as native ones, which there seems to be a bit of back-tracking on now:
http://tirania.org/blog/archive/2005/Dec-28.html
Just out of curiosity, why did it fail then?
It’s very hard to interface C# via P/Invoke with unmanaged C++. You usually need to write C bindings first, and that’s what the Qt# project did. They used the QtC bindings (that I originally wrote for an Objective-C Qt binding), which were a bit limited in that you couldn’t override every virtual method for instance. However, when they tried to write a better C binding they didn’t finish it.
The new Qyoto bindings use a completely different approach using transparent proxies to divert every single api call to a single SmokeInvocation.Invoke() method. That Invoke() method then interfaces with the Smoke library (also used by the PerlQt and QtRuby/Korundum projects). The method call is dynamically looked up in the Smoke runtime. This way might be slightly slower, but it avoids all the ugliness of needing a C binding. It also makes it possible for Qyoto to be the first GUI binding to use Aspect Oriented Programming, as every method call can be a point cut where you can intervene and optionally run code before and after specified method calls.
And are you able to use any of their work for Qyoto?
We haven’t really used any of Qt# code for Qyoto, although we might use some of their work on layering C# delegates on top of Qt signals/slots.
Well, if they can include Mono, they can sure as hell include decent multimedia support then, can’t they? They’re both patent ‘encumbered’. Until then, Redhat will be a 2nd rate distro in my eyes (in fact it’s vastly overrated anyways).
Dave
Nah, the situations are very different. With Mono the danger is basically all theoretical and mostly based on the fear that Microsoft will try to screw us at some point. But _right now_, the core of Mono is perfectly legal and unencumbered. Not so with mp3.