The Mono debate over on the GNOME desktop developer mailing list is heating up again. Philip Van Hoof makes a compelling argument about the need for GNOME decision makers to take into consideration future developers and the over-reliance of C and GObject in GNOME. At what point does a general-purpose, high level framework and runtime become a necessity for GNOME?
When you read OSNews/Slashdot comments you’ll notice that all the time people are complaining that GNOME is evil because they are pushing Mono (based on evil MS technology) down the throats of everybody. Well, here’s an interesting quote from the linked email:
“If GNOME wants to lose software developers, it should definitely keep rejecting innovations like .NET and Mono. By the subtile way GNOME is currently already rejecting Mono and other higher programming environments, it will definitely lose for example me.”
Looks like the complainers need a reality check.
Edited 2006-07-18 23:20
I think that the problems with .NET are actually valid; until Microsoft can sign an accord with the opensource community, committing themselves to a neutral stance when it comes to opensource implementations of .NET, the GNOME developers don’t want to leave themselves open to the possibility of getting sued, losing the case, and finding that 1/2 the new desktop, written in C# and VB.NET disappears because they can no longer ship mono.
The only real alternative at the moment is Java, and Sun knows it; hence, they can screw around the opensource community till the cows come home, and ultimately, there isn’t a damn thing anyone can do about it, because the alternative is considerably worse.
If Microsoft signed the above document (the accord), it would be the death nail in Java coffin; you would have those who had stayed back because of legal risks, jump into the .NET pool and contribute to making Mono 100% compatible with the latest interation.
There are other alternatives, in terms of higher level languages; how about Objective-C and Objective-C++; as stupid as it sounds; it doesn’t have the legal implications that comes with C#; its already *there* in terms of complete language support, it would be simply a matter of providing gtk for ObjC etc. and with that, Mac developers, who are familar can transpose their skills quickly to the GNOME platform and thus encourage development on the said platform.
There’s always Python and PyGTK (http://www.pygtk.org/pygtk2tutorial/index.html).
As for Java, GCJ is making significant progress: I think someone even managed to use it to compile a Java/Qt program using it. What’s more, Java/Qt programs are actually very, very fast, as most of the work is done in the native Qt library. I tried it myself with a simple Hello World GUI, and even startup time was fast.
As for your “accord”, Microsoft has signed it in standardising most of the language with the ECMA. The problem is that certain technologies included in Mono (notably Winforms) are not a part of the standard, and are therefore vulnerable to litigation. However most developers can simply use GtkSharp to get around this (http://www.mono-project.com/GtkSharp).
As for your “accord”, Microsoft has signed it in standardising most of the language with the ECMA. The problem is that certain technologies included in Mono (notably Winforms) are not a part of the standard, and are therefore vulnerable to litigation. However most developers can simply use GtkSharp to get around this (http://www.mono-project.com/GtkSharp).
Hence, they need to sign an accord which covers the WHOLE framework, not just a small subset of the larger piece.
They’ll claim that ‘we’ll lose out competitive edge’ when in reality, there are large sections that the OSS community will never want to implement as I’m sure there are those out there who could implement something even better than what Microsoft has provided.
“The only real alternative at the moment is Java, and Sun knows it; hence, they can screw around the opensource community till the cows come home, and ultimately, there isn’t a damn thing anyone can do about it, because the alternative is considerably worse.
If Microsoft signed the above document (the accord), it would be the death nail in Java coffin; you would have those who had stayed back because of legal risks, jump into the .NET pool and contribute to making Mono 100% compatible with the latest interation. “
Oustanding points.
The fact that there are “question marks” about the legality/risk of using an open source .Net implementation makes is less attractive, indeed even a no-go, for many open source devs.
And I agree 1000% that if either Sun or MS make 100% open source friendly implimentations available of their respective platforms, they’ll gain a huge competitive edge over the other.
And, in spite of my singing the praises of Mono, there does seem to be actual technical issues. For instance, it is not completely cross platform yet, and some people have problems with crashes, and when Mono itself gets updated, the apps running on it have to be updated as well.
Perhaps Python is the way to go. It is a very nice language, and has been proven in big environements (Industrial Light and Magic, Google, NASA, Zope, etc), and has full, mature GTK bindings, it plays real nice with native C libraries (a must in Gnome/GTK development), it’s usually as fast or faster than Mono or Java, and it is 100% open source, with very little perceivable risk (and almost no objections from the community).
I don’t know if I am gonna get flamed by this but, Python, in my point of view, cannot be compared to C# or Java for they have completely different styles. Python lacks a few features that make it a simple and easy language, but is just weird for some programmers used to other frameworks (class members visibility, strong type checking, etc).
not that Python NEEDS these. It was build to be like it is now, I am just saying that it is a completely different beast.
ffs, i’m no python fan, but its well designed, way lighter-weight than some half-assed .NET clone and doesnt suffer from the patent issues.
What is the issue with simply using what is already becoming something of a standard for scripting in gui-oriented applications?
I don’t agree that pyGTK is “much lighter” than Mono. All the pygtk apps I have seen are SLOW to load, and some of them are using ridiculous amounts of memory. So before you think that python==pygtk, think again.
I would vote for some C# bindings apart from the Mono platform (is there a free compiler apart from Mono anyway? (not dotGNU please)).
C++ is aging too so I think the leap should be for something more of the 21Th century and not scripting languajes.
Well, i dunno – core GNOME apps written in C are SLOW to load, and some of them use ridiculous amounts of memory too.
Python would simply give everyone an open source, high level language to write GNOME apps in (even slow, memory hungry ones) without all the ridiculous and never-ending hand-wringing around MONO vs. Java.
Sorry, no. GTK 2.x is slower than 1.2.x, but its apps are not as slow as pygtk apps are. Usually pygtk apps are 3x slower to load.
You dont think the startup speed issues could be addressed and improved if Python was adopted as a core GNOME component?
Honestly, no. PyGTK is already deemed “stable” and “full featured” right now.
Edited 2006-07-18 23:52
Come on, is that the best you can do?
‘The current version doesnt perform that well, so it’ll never be any better’?
Apply that reasonaing to, say, GNOME 2.0 and then tell me how come GNOME 2.14 goes so much faster?
I think that misses the point. If you have a language-neutral JIT in place then you can use IronPython (or similar) or a whole host of other languages, with a performance that can approach native code. Using Python per se doesn’t provide this.
The Mono CLR implementation isn’t the only game in town, but it *is* probably more practical than many of the alternatives, at the moment.
Its quite possible that the memory and startup time issues would be *improved* using CLR, if the CLR was hosted by the desktop and ‘applications’ were loaded into an app domain within the single CLR, at least as an option.
I’m not convinced that Mono (or at least the core CLR and the GTK bindings part) is necessarily much more patent-threatened than Python. There are a lot of patents kicking around, and its rather likely that Python could be attacked, too.
I’ve been using pygtk quite a bit lately. I’ve not checked the memory usage, mainly because this is almost impossible to get any kind of handle on in a high level language anyway, but I’ve found pygtk quite fast.
TMK pygtk is a very thin layer. I get quite a few gtk errors when using it where one might think pygtk would have made some checks.
Of course, Gtk in general is slow if you’re not using it correctly. And Python itself is quite slow, so you have to know what sort of algorithms to just write in c there too.
I’d love to see python as the Gnome language. My only fear with it is that, well, it’s slow. But since Gnome has such a strong focus on C, and python/C is easy, it shouldn’t me too much to expect people to write difficult algorithms in c and the rest in Python.
Of course, if you use .Net you would be more inviting to Windows developers.
First of all Mono is no half assed .NET clone. There is hardly any reason to clone .NET ( other than the obvoius one that you can write code that runs on several platforms ). As far as Python goes it is still greatly immature despite that many years of development. Also Python is not really that fast and like most scripting languages should be used as a glue language. C# is not really the fastest language either but it seems to have matured a lot faster than Python and it also provides faster execution time. And if you really like Python there is nothing to stop you from using it.
As far as Gnome and a support language goes, I think that the team should finally focus on Gnome 3 rather than fiddle arround. That is if Gnome want to put up any fight with KDE 4 …
As far as Python goes it is still greatly immature despite that many years of development.
That is simply bullshit. Look at projects the size of Zope, the Gentoo portage system, or projects where lots of people rely on daily like the Trac software project management system, the MoinMoin wiki, bazaar-ng, the official bittorrent client. And then there’s also several desktop applications (where Python is more of a glue language thing) like Listen (a music management and playback for gnome), quodlibet, and I’m sure there are numerous others.
In my experience, those applications have performed a lot better than the mono applications I tried: f-spot, beagle and blam. Beagle and blam eating all my ram away and f-spot crashing each time I tried to import pics.
The standard python interpreter may not be as fast as the mono vm, but it is definitely more mature than the mono vm. Btw, part of the reason that mono is faster, is that it has a JIT already for some time. There is a kind of JIT compiler (allthough I think it’s more an at run-time specializer) for Python too, called Psyco, but this is not included in the official python distribution.
I also believe there are a lot more (good, supported) python libraries than there are mono libraries, and I believe that is also an indication of the maturity of the development platform.
So, I stand by my point: as of today, the Python development platform is much more mature than the Mono development platform.
Btw, I do agree that Python should (currently) not be used for any type of application. C# and Python are not the best language for the same set of applications. But in my opinion, Mono simply isn’t there yet to be useful for the applications it should be able to handle. And I think the same goes for Java, even though I think Sun finally getting closer with Java Mustang (for using Java for desktop applications in any case).
But who knows…. maybe over time, Python and Ruby come with powerful vms with smart JITs that give those languages approximately the same performance as a language like C#. Who knows what happens then…
Edited 2006-07-19 08:39
The good thing about the Python vs. Mono debate is that it’s not going to be a theorical one among programmers. Instead, it will be users who will have the final word. Right now, there are quite some Mono and Python apps to use and compare. My own experience is that Python apps work better.
We just have to wait and see how Mono apps (Banshee, Muine, f-spot, beagle, Diva,…) compare to Python ones (Quodlibet, Listen, Exaile, Bittorrent, Pitivi, Jokosher, Istanbul, Serpentine…) and we’ll have the answer as of which one fits better in Gnome.
Because python uses way too much ram and cpu time over C apps therefore making it slow for desktop applications?
Just look at bittorrent and then compare it to utorrent.
Python, Perl, Java, Mono and every language that uses a virtual machine or a garbage collector shouldn’t be used for desktop applications.
Maybe it’s time you bought a new computer; one from this millenia…
A decently written high-level language program won’t reveal lagginess from its virtual machine/interpreter.
Example: Gaim vs amsn, Gaim vs gajim, etc.
Hell, even Inkscape uses a garbage collector!
Python is significantly slower than most other languages at a similar level (some interpretation system, garbage collection, advanced features like reflexivity, etc), however, I think it gets a bad rep because it’s also a favorite introductory language for quite a few people to write their first “major” program. This means you get some complex algorithms written in Python, and not necessarily in the most efficient form they could be done in Python: So the program seems slow.
It’s not impossible to write a decently fast program in Python or any other “slow” language.
And it’s not impossible to write a slow program in C (Firefox/Thunderbird).
And bittorrent runs fine here. Although, I did have a glitch with it the other day where it decided a file was corrupt when it was fine. But that’s logical.
And bittorrent runs fine here. Although, I did have a glitch with it the other day where it decided a file was corrupt when it was fine. But that’s logical.
It’s not really a matter of running fine, but performance… µtorrent is definitely more efficient than competing programs, especially the original BT implementation in Python. To my experience with a similar load (about five torrents), µtorrent was using about 15MB RAM while Azureus (Java) and BT (Python) were using over 100MB…. It’s just a shame that it isn’t cross-platform.
Perhaps Python code is easy to maintain, but the price to pay is a bit high. RAM might be cheap, it doesn’t mean we should abuse it.
You can’t accurately measure the memory usage of any program, and it’s even harder with a Java program. I doubt Azureus really used that much, much of it was likely the Java VM and libraries.
Much of that is probably for some performance reason: Memory is cheaper than CPU cycles these days.
And not all interpreted languages have to be slow or RAM hungry. Lua is a good example of a very good optimized interpreted language (used mostly for games, but whynot for desktop apps in the future?):
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=p…
http://dada.perl.it/shootout/craps_cpumem.html
Just nitpicking but… Python doesn’t use garbage collection. At least not on the usual sense (actually having a garbage collector), it uses reference counting. Objects are released immediately after their last reference goes away.
I find the title a litle journalist and far from “Heat up”, but man, I love to see these discutions, just take a look to the names of the People who is discussing, Havoc, Jeff, Federico, etc, pure quality developers, I read the blogs of these guys every day at planet.gnome.org and see them talk about the future of GNOME inspires me.
Hmmn. Whilst integrating products like Python and Mono into GNOME will certainly attract more programers, what is the expense in terms of GUI speed and responsivness? Can linux, an OS touted to run well on old hardware, afford to have it’s most popular window managers require dual core CPU’s just to run acceptably?
Run on old hardware? Linux? Please. Thats always been a legend. While stripped down linux, the OS can exist on the smallest of small embedded systems, For an old desktop pentium II era, Win2k beats any distro of linux running any desktop. I WISH i could find a linux distro that ran acceptably on a PII 400 with 64 Mb of Ram on a 2 gig HD. Its not like I’ve been looking for the past two years or anything.
The weak point is the amount of ram. I’m fairly sure that Win2k with an uptodate internet explorer or firefox won’t be very comfortable on 64mb ram either. If you want to run a desktop on that machine, then add a stick of 128mb ram. It’ll run win2k decently and it’ll run debian stable decently too. (xfce probably, even though I think that Gnome/KDE would be decent too on a total of 192mb ram)
Since you consider win2k, you could also consider an older version of a linux distro, like Debian GNU/Linux 3.0 (a.k.a. woody), which was released on 19th of July, 2002. (thus more recent than the initial release of win2k) Debian gave security updates for Debian 3.0 till the end of june 2006. I think I read security updates for Win2k will be stopped at the end of july 2006. So, I think you didn’t really look very good then in the past two years. (Debian 3.1 was only released on April 19th, 2006) If I’m not mistaken Debian 3.0 still used xfree 3.3.6 and had mainly gtk-1 applications. If you use that in combination with Windowmaker or xfce3, you would have had a very snappy desktop on that Pentium II 400Mhz with 64mb ram. I know because I ran it on a Pentium 120Mhz with 64mb ram…..
I think that “Linux runs good on old hardware” should be interpreted as “if you want to put some effort in it, you can configure a linux system to run well on older hardware”. If you choose the right software, you can run an up-to-date kernel and up-to-date software on an old pentium with reasonable performance. Of course, one cannot expect miracles. If your hardware simply does not have the power to play an H.264 encoded high definition movie trailer, then it’s not gonna miraculously work when you try it with linux.
I WISH i could find a linux distro that ran acceptably on a PII 400 with 64 Mb of Ram on a 2 gig HD.
http://www.damnsmalllinux.org/
http://featherlinux.berlios.de/
I honestly can’t think why the core should be writed with a script oriented languaje like python, to me is simple out of the question, for hight level apps. maybe but not for the core.
Here is a good video made at Sydney Linux users group about Mono and why its important to the Linux Desktop effort
http://media.slug.org.au/james/James%20Dumay%20-%20I~*~…
other formats also available
http://media.slug.org.au/james/
And if anyone can put together a C app like Banshee in the same dev time and make it 1.2Mb then i’ll shake their hand.
Banshee, f-spot, Diva and Beagle are all great mono apps.
And if anyone can put together a C app like Banshee in the same dev time and make it 1.2Mb then i’ll shake their hand.
Well, there’s Quod Libet, you know? Kick-ass PyGTK music player.
Wow. I just apt-got quodlibet, which I’d never heard of before, and if that’s an example of pygtk’s slowness, I’ll take about 50 more of those pygtk apps please.
Zippy and functional. And unlike rhythm box, when I tell it to play something it just plays it instead of popping up a window telling me why it can’t.
Thanks for the pointer.
“Can linux, an OS touted to run well on old hardware, afford to have it’s most popular window managers require dual core CPU’s just to run acceptably?”
No, it can’t. Interpreted languages run fine, but they take huge ammount of resources and load time with GUI libraries.
Most of the core libraries/functionality should be compiled to native. C language is not the best for OO libraries (C++ should be used instead) not for applications. As Torvalds said, C is for developing kernels and libraries. Applications should be written in more easy to use languages, like C++(debatable), Python, Ruby, Java, C#.
But the problem is if you have lots of applications, made in Python as an example, running in your system then you need memory. Lots of memory. It’s the tradeoff: programmers can create better software faster, but you need a powerfull machine. Though we are in 2006; we must look at the future, not the past.
But the problem is if you have lots of applications, made in Python as an example, running in your system then you need memory. Lots of memory. It’s the tradeoff: programmers can create better software faster, but you need a powerfull machine. Though we are in 2006; we must look at the future, not the past.
Looking at the future without taking account of the past is very naive… Don’t forget that your average user is more likely to use a computer “from the past” rather than the latest dual/quad-core offering with GBs of RAM.
That said, applications using interpreted/evolved languages don’t have to be slow and/or memory hungry… Usually, experienced programmers don’t have much problem with perceived speed and/or RAM consumption. For instance, they don’t open or keep stuff needlessly. They don’t let the GC do all the dirty job: they are doing their own part in memory management. They won’t choose an O(n^3) algorithm when they know better. In other words, an easy-to-use language won’t substitute competence.
Edited 2006-07-19 01:08
“like C++(debatable)”
Yes, debatable indeed. C++ adds syntactic sugar to C, but does nothing to increase developer productivity (and no, simply calling methods by “object.method(params)” instead of “function(object, params)” doesn’t increase productivity).
Between C and C++ I choose C. It is a cleaner language, with much better support across platforms/compilers, and it makes keeping stable ABIs a much easier task. This is, in fact, the main reason stuff like GTK is written in plain C (and most other libraries too).
But you are right, neither of them are a good fit for non-performance critical applications. For that I choose Python, with all the critical parts implemented as native libraries (in C).
I believe that the following quote from phillip people should read and re-read
Yet THEY will be the ones that will build compelling applications. WE
will burn out and WE will eventually stop development. FACE THIS.
Im not advocating mono either way but I do believe this is food for thought.
Haha, the translation is:
“Students and people tinkering in their spare time like bleeding edge stuff because it’s more exciting. But since the good ones usually end up writing software for a living they will abandon the open source society when they start getting productive.”
I’m sure everyone here has experienced the following psychological
phenomenon many times:
It’s psychologically difficult to change your favourite programming
language, especially if you’ve been using it for years. You spent a
lot of time mastering it, and now abandoning it would be admitting
that what you know and, in some sense, what you are is not useful any
more. This is a shocking news so you try to deny it. This defence
mechanism is not specific to programming languages (“desktop
applications are for losers who can’type, I only use a command line”)
or even to computer science. “Purity” is often the word used to
defend the old system.
I’m not saying that one should always adopt new solutions because they
are new. Far from it. What I mean is that, in making important
decisions, one should always be aware of psychological factors that
cloud objectivity.
It’s psychologically difficult to change your favourite programming language, especially if you’ve been using it for years. You spent a lot of time mastering it, and now abandoning it would be admitting that what you know and, in some sense, what you are is not useful any
more.
It’s also (in my opinion) the sign of a poor programmer, or at least a narrow minded one, who will be unwilling to see the benefits of a different language.
I had that same attitude when I finished university, and having used Java for 95% of stuff. I got a temporary job using Visual Basic for a few weeks, the my first real job was programming Perl. Now I am competent at both Perl and Java I use both, and choose the best one for the job. I also intend to learn more languages. I see now that learning another language helps you think about problems in different ways.
“C++ is aging too so I think the leap should be for something more of the 21Th century and not scripting languajes.”
Well, C# and Java are just C++ without the awfull (powerfull) things. The 21th century languages you talk about are dynamic languages (yes, aka scripting languages).
Dynamic languages is not the same as scripting languages. Objective-C and Smalltalk, for example, are dynamic languages, but are not scripting languages.
I mean languages that are hightly UML 2.0 compatible and with all the good goodies a modern languaje must have and C++ simple lacks.
Interestingly, slashdot has an article today about speed of various
high-level languages:
http://it.slashdot.org/article.pl?sid=06/07/18/0146216
One of the comments mentions “The Computer Language Shootout”
http://shootout.alioth.debian.org/
which shows a comparison of the performance of various programming
languages at various tasks.
Mono haters claim that MS will eventually sue them because of IP that Mono supposedly appropriated from MS. That’s nonsense. As an IP owner, Microsoft has an obligation to defend its IP and mitigate damages. It can’t allow Mono to plod along knowingly for years with its IP — and then suddenly claim that it wants to sue for damages. But Mono has been a going concern for years already. The time for MS to claim damages has passed. Anybody who clings to this canard is simply not credible, in my opinion.
“””As an IP owner, Microsoft has an obligation to defend its IP and mitigate damages”””
This is a common misconception. You are confusing copyrights and patents with trademarks. What you say is true for trademarks. But it is not true for copyrights and patents.
I believe that one of the reasons for GNOME staying with C is not
speed but portability (almost any system has a C compiler). As
far as speed is concerned, modern high-level languages (C#, Python,
Lisp, Haskell, …) are perfectly fine, I think, for not-too-demanding
desktop applications. One can always rewrite the performance-critical
parts in C; one critical interrupt handler is not a reason for writing
an entire app in assembler.
Staying with C means abandoning things like garbage-collection, true
objects and polymorphism, namespaces, and many other useful features.
In the name of portability GObject provides poor man’s
reimplementations of those features by using explicit reference
counting, preprocessor magic, namespaces emulated by underscore-laden
naming conventions, and other nasty schemes. It’s almost like
inventing a new (rather ugly) programming language.
Is this a sensible price to pay for extreme portability? Are
higher-level languages, not to mention C++, really so non-portable?
Do mainstream desktop apps really have to run on ENIAC?
“Portability” was always a specious argument: when Gnome was started every system had a C and C++ compiler, as the two were often bundled together. KDE went with C++, and consequently has almost as many ports (Python, Ruby, Java, Perl*).
However by going with a language that had native OOP support, they made the process of creating the underlying libraries much easier, and the process of creating the bindings to modern languages a lot easier too, as all modern languages have either come with OOP support built in, or – as in the case of PHP – added it to the language rapidly after release.
The GObject system, and the choice of C as the language of the underlying framework, makes development of the underlying framework quite difficult. In particular, enormous amounts of boiler-plate code and macros are required to handle the things that come built in with OOP languages with modern error-handling techniques.
At the time, Gnome went with C for two reasons:
(1) C programs were slightly faster than C++ programs, and lot faster to start up. However the KDE project brought into existence a large body of frequently used C++ code, and some motivated developers, so the performance of programs compiled in G++ has gone up significantly
(2) C was considered the lingua franca of Unix systems, and there was a certain amount of inertia and luddism in its advocacy for a new desktop. Tradition – in many ways – beat out common sense.
I’ve always felt that going with C was a mistake, and that basing one of the major Unix desktops on such an excessively complicated foundation would only lead to trouble in the road ahead. Time will tell I suppose.
——————————
[*] Perl only has Qt support at the moment: http://perlqt.sourceforge.net/
Edited 2006-07-19 12:35
Actually, it is easier to generate language bindings from C than it is from C++. Which is why I believe GNOME has more language bindings than KDE does.
“Portability” was always a specious argument: when Gnome was started every system had a C and C++ compiler, as the two were often bundled together
What BS is that ? Does base object class mean sth to you ?
Every system doesn’t have GCC as its core c++ compiler, and switching compiler means all kind of nightmare for C++ (far less for C).
The KDE FAQ still warns you to use the same compiler version for compiling all of KDE and Qt.
The GObject system, and the choice of C as the language of the underlying framework, makes development of the underlying framework quite difficult
Sure, but it’s basically done now.
In particular, enormous amounts of boiler-plate code and macros are required to handle the things that come built in with OOP languages with modern error-handling techniques
What you say is misleading. There are a lot of macros yes, so that you can make OOP calls without writing countless lines of code.
That means you have to learn a new OOP syntax just for Gnome. I’d understand if you don’t like that, but that’s all there is to it.
The official Gnome 2 developer’s guide book explains this very well. There’s a bit of habit to get, and then it’s easy.
At the time, Gnome went with C for two reasons
I don’t like your two reasons.
You sound like things like “the developers knew C better”, “C++ is more difficult”, “the autoconf system is better tailored for C”, … do not count.
You say going with C was a mistake. Where did you see the mistake ?
I’ll have to take jabs at KDE to stop your nonsense : which system still works very well with autoconf ?
Gnome added OOP to C, and that’s a problem to you. KDE use Qt that uses moc to add messaging/slots to C++ (which is included in GObject too) but that’s not a mistake to you. Is the C++ binding to Gnome irrelevant ?
There is still no problem with Gnome as to the choice of the core language, except for people that dislike C and want to see it dead.
The constant bugs discovered in C++ code with each revision of GCC that is stricter than the precedent, show that C++ is not the panacea fans of this language want us to believe. Look at the weekly KDE digest to see the number of language bugs still discovered today.
I like KDE too, but I think these language wars are nonsense and non productive. A programmer should choose the language he feels he will be faster with.
You sound like things like “the developers knew C better”, “C++ is more difficult”, “the autoconf system is better tailored for C”, … do not count.
To a large extent they don’t. If C++ is better, but developers prefer C, which is the best language to use? C++ obviously: being better, once the developers make the leap, they should be more productive.
You say going with C was a mistake. Where did you see the mistake ?
In the extreme difficulty in maintaining code. KDE changed it’s file-selection dialog in a single patch in a point release: it took Gnome a full six months of effort to do the same. That’s only the tip of the ice-berg, Evolution was nearly pitched out of Fedora due to the volume of bugs in it (http://lwn.net/Articles/179628/). For a long time may different applications in Gnome had their own toolbar widgets that did not respect the overall settings. The list goes one
I’ll have to take jabs at KDE to stop your nonsense : which system still works very well with autoconf ?
Indeed, who is still using Autoconf, a collection of scripts in a macro language hardly anyone understands anymore, and who is moving to a new and more powerful build system that is easier to get to grips with?
Gnome added OOP to C, and that’s a problem to you.
My problem is that it’s easier to use OOP techniques in a language that natively supports them, than in a language that has had to have it added after the fact and which, moreover, has no decent support for strings or error-handling
KDE use Qt that uses moc to add messaging/slots to C++ (which is included in GObject too) but that’s not a mistake to you. Is the C++ binding to Gnome irrelevant ?
This is a valid point. However the moc makes it easy to program in C++, and provides features few other languages provide. Moc and C++ are a superior alternative to a lot of other languages out there. However even C++ is preferable to C/GObject.
There is still no problem with Gnome as to the choice of the core language, except for people that dislike C and want to see it dead.
Good lord, that’s quite a dramatic slant on things! I don’t want to see C dead (though I think it’s time is drawing to a close). I just think that in the modern era, there are a lot of other languages out there that provide more powerful abstractions without any significant performance issues. These abstractions in turn help to improve development speed and – by reducing the lines of code – reduce the incidence of bugs.
The constant bugs discovered in C++ code with each revision of GCC that is stricter than the precedent, show that C++ is not the panacea fans of this language want us to believe.
This is a specious argument: the fact that G++ has been eliminating several non-standard extensions to C++, while GCC has not been eliminating as many extensions from C, does not mean that C++ is inferior to C. Further, if you look at the kernel developer list, you’ll see that kernel developers have had some frustrating times dealing with changes in GCC’s support for certain C features. I do agree that C++ is a pretty poor language, however for the development of a desktop environment and its infrastructure, I think it was a better choice than C.
I like KDE too, but I think these language wars are nonsense and non productive. A programmer should choose the language he feels he will be faster with.
The problem is that in a group effort, you should choose the language that the group, and the people who will join the group in the future, can be most productive with. It’s not about personal preference. Further, you need to look at the problem domain to see what language features will be needed: it is broadly accepted that OOP dramatically increases the ease with which GUIs can be developed, therefore it would have seemed to be an obvious choice to go with an OOP language.
Personally I wish one of that had gone with Object-Pascal and FPC…
In the extreme difficulty in maintaining code. KDE changed it’s file-selection dialog in a single patch in a point release: it took Gnome a full six months of effort to do the same. That’s only the tip of the ice-berg, Evolution was nearly pitched out of Fedora due to the volume of bugs in it (http://lwn.net/Articles/179628/). For a long time may different applications in Gnome had their own toolbar widgets that did not respect the overall settings. The list goes one
Oh, please. You don’t maintain any GTK+ code, don’t tell me how harder it is compared to C++.
KDE’s initial file selection dialog had a thought out API which wasn’t tied to the UI. This was a mistake that was made in GTK+, and later fixed. cairo, dbus and gtk+ itself prove your little example adds nothing to your theory.
Evolution is an entirely different beast. It’s a complex application built on a complex platform (Bonobo). Again, “C vs C++” has nothing to do with its problems.
To a large extent they don’t. If C++ is better, but developers prefer C, which is the best language to use? C++ obviously: being better, once the developers make the leap, they should be more productive.
“Using C++ is premature optimization.” – Slashdot comment
In the extreme difficulty in maintaining code.
Which code? The GTK+ library? Or the code in your application?
KDE changed it’s file-selection dialog in a single patch in a point release: it took Gnome a full six months of effort to do the same.
How does this make C++ better than C?
KDE changed it’s file-selection dialog in a single patch in a point release: it took Gnome a full six months of effort to do the same.
And this is because the file dialog is written in C++?
That’s only the tip of the ice-berg, Evolution was nearly pitched out of Fedora due to the volume of bugs in it (http://lwn.net/Articles/179628/).
Are you saying if Evolution was written in C++, its volume of bugs will
be lower? If so, where’s your proof?
For a long time may different applications in Gnome had their own toolbar widgets that did not respect the overall settings.
That’s because GTK+’s toolbar API is flexible. It allows developers to
determine the look and behavior of the toolbar. This means developers
can override overall settings depending on how appropriate that is.
Indeed, who is still using Autoconf, a collection of scripts in a macro language hardly anyone understands anymore,
About 90% of *nix.
d who is moving to a new and more powerful build system that is easier to get to grips with?
You mean a largely untested and experimental build system.
problem is that it’s easier to use OOP techniques in a language that natively supports them, than in a language that has had to have it added after the fact and which
How so?
moreover, has no decent support for strings or error-handling
Ever heard of Glib?
Good lord, that’s quite a dramatic slant on things! I don’t want to see C dead (though I think it’s time is drawing to a close). I just think that in the modern era, there are a lot of other languages out there that provide more powerful abstractions without any significant performance issues. These abstractions in turn help to improve development speed and – by reducing the lines of code – reduce the incidence of bugs.
C++ is not the epitome of good abstractions either. In fact, it is an example of how a language should not be designed.
This is a specious argument: the fact that G++ has been eliminating several non-standard extensions to C++, while GCC has not been eliminating as many extensions from C, does not mean that C++ is inferior to C. Further, if you look at the kernel developer list, you’ll see that kernel developers have had some frustrating times dealing with changes in GCC’s support for certain C features. I do agree that C++ is a pretty poor language, however for the development of a desktop environment and its infrastructure, I think it was a better choice than C.
Libraries and frameworks are the most practical criteria for determining the effectiveness of building desktop applications, not languages.
The problem is that in a group effort, you should choose the language that the group, and the people who will join the group in the future, can be most productive with. It’s not about personal preference. Further, you need to look at the problem domain to see what language features will be needed: it is broadly accepted that OOP dramatically increases the ease with which GUIs can be developed, therefore it would have seemed to be an obvious choice to go with an OOP language.
OOP does not magically guarantee the success of a project, neither does using an OOP language. GTK+ and GNOME are highly successful and well designed projects, yet the core of either libaries is not written in an OOP language.
I will just ignore in my reply most of your comment, since others already replied to them but…
> [*] Perl only has Qt support at the moment:
> http://perlqt.sourceforge.net/
is just bugging me.
As far as I can remember, we have gtk2-perl (ignoring gtk1 stuff) since 2002. And it is listed as a complete version of the Gtk2 library up to the 2.10 version.
Am I completely wrong here or are you just spreading lies to make your statements look better ?
I think he meant Perl has Qt support but no KDE support, unlike the other languages he mentioned.
“Portability” was always a specious argument: when Gnome was started every system had a C and C++ compiler
Except for one thing: A C compiler is entirely different from a C++ compiler. Knowing there is a C compiler, and knowing what C spec you are compatible with virtually ensures compilability. C++ compilers do not have that benefit. But at this point, gcc works on just about … everything … so who cares right?
C++ is the major reason I won’t develop KDE apps. I just despise that language with such a burning passion! I know many people who feel the same way.
But yes, C does keep the riffraff out, but maybe that’s not such a bad thing.
“when Gnome was started every system had a C and C++ compiler”
Yes, but the C++ standard is big and full of cloudy spots, so compatibility between compilers varies greatly.
Then there is the problem of name mangling, which keeps changing even today, breaking ABI compatibility. Maintaining binary compatibility between releases of a library is a difficult enough job without having the compiler backstabbing you at every opportunity.
GTK has a very high number of languange bindings because it has a stable, and less complex ABI. Compare GTk with Qt in this respect and you will see what I mean.
Actually, looking at the current benchmarks, Mono holds up quite well against C++.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=c…
However, when you compare Mono Vs Python, python looks not so hot:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=c…
If we are to move towards the newer languages, Mono for now at least would seem like a good choice. Java also holds up well.
Finally, D by Digital Mars is getting very good benchmarks, although it’s still in beta. I wonder if D would be worth a look?
Maybe you’re looking at different graphs and tables. The tables I see that you’ve linked show Mono’s memory consumption to be 5x that of the corresponding C++ app. 5x!! If all GNOME apps were developed on Mono, what would that mean? Would you like GNOME to take 5x more memory than it currently does, while providing the exact same functionality?
Speed wise, it ain’t too hot either. It averages 2x slower than C++. So it’s gonna take 5x the memory and run 2x slower. This isn’t “holding up well”. This is getting obliterated.
p.s. I know GNOME as well as most of it’s apps are written in C. Still the results for C++ are usually relevant to C.
Any system that uses garbage collection will have much greater memory use than a tuned C or C++ application, particularly if its using a JIT and the compiled code is process-private and/or its threaded and uses immutable objects extensively to reduce locking. And 2x is hardly a problem speed-wise for the bulk of an application’s logic.
No-one’s suggesting that the core widget set should be reimplemented in a JIT system – this related to applications, and ease of construction is very important.
I’d trade 2x execution speed for ease of development any day.
I’d trade 2x execution speed for ease of development any day.
So, after a week, you end up with an application that is 2 orders of magnitude slower than the original. This is why I don’t like this attitude of… “oh, a factor 2 is hardly problematic”.
I’m exaggerating, but that’s the danger I see in this, programmers seem to be really eager to trade in speed for anything these days. And I believe that’s how we end up with slow and bloated applications.
Any system that uses garbage collection will have much greater memory use than a tuned C or C++ application…
I don’t think this has to be true. The performance of a garbage collector becomes better as the memory available for the collector increases (obvious, since when you have more memory available for the same program, you’ll trigger fewer garbage collections). However, it should be feasible to get decent performance from a tuned garbage collector with “a bit more” memory used than a tuned C/C++ application. How much memory the application allocates really depends on the policy of the garbage collector.
A policy is for example “if you see that 70% of the heap contains live data, then double the heap size”. So if you have a 1 megabyte heap, and 750 kilobyte is in use, then the collector would allocate 2 megabyte to satisfy future memory allocations. Now, suppose that the highest amount of data is live during the run of your application is let’s say 900 kilobyte. A version with perfect manual explicit allocation would at most use 900 kilobyte. The garbage collected application with the aforementioned policy will use 2000 kilobyte, because this simple collector would only trigger collections when the heap overflows, thus when it reaches the full 2000 kilobyte (even though at that time not even half of the heap would contain live data). So it’s easy to see how a simple garbage collector with a simple collection policy can eat all your ram away. If for example in this case, we would have decided to only double the heap size when 95% of the heap contains live, active data, then the application would only have allocated 1 megabyte. But…. since the heap would only be half as big, a garbage collection would be triggered much more often and the program would have become more expensive in terms of cpu usage.
Also one of the problems is that many programmers have become really careless about the memory management of their application. I think we need (better analysis in) smarter compilers which can allocate objects on the stack whenever possible to remove pressure from the garbage collector. And maybe we need to go one step further and combine garbage collection with both stack allocation and region-based memory management.
“So, after a week, you end up with an application that is 2 orders of magnitude slower than the original. This is why I don’t like this attitude of… “oh, a factor 2 is hardly problematic”.”
And 2 times 50 microseconds is, what, 100 microseconds? Can a human even see the difference between that? Fact is, most desktop applications spend 99% of their time waiting for user input. Besides, the GUI toolkit is usually written in C/C++, the scripting language will have no effect on that. You only fear “slowness” because you don’t understand in what context they actually matter.
Besides, computer time is cheaper than developer. You can buy a more powerful computer for less money than you can hire a developer to write an app that’s twice as fast.
Edited 2006-07-19 10:54
Besides, computer time is cheaper than developer. You can buy a more powerful computer for less money than you can hire a developer to write an app that’s twice as fast.
This is not just a matter of the price but also of distribution: Imaging a developer is able to save 1 MB of memory consumption in ten hours work. This is a waste of resources if he’s the only user of the application. One the other hand, if his patch is distributed to a million users, that’s something completely different.
Additionally, the user’s memory and computing power is a public resource to the developer in your statement: Just like fishing grounds, you gotta be careful that you don’t overuse it! In contrast to fishing grounds, you may the one who’s application gets a kick by the user due to over-use. This is no argument for a open source developer but it certainly is for a proprietary one. 😉
Usually, I’d agree to your statement but it’s good to keep it mind that wasting memory or computing power usually affects several thousands of users if not millions.
Well, my (garbage collection) experience is with writing services that cache plenty of data, and which continuously generate and publish data in response to realtime updates.
These generate a lot of short-lived objects, but also some garbage that finds its way past the first few generations. And the net effect is that you do need plenty of memory to avoid spending a lot of time in gc.
Of course, this sort of application is, according to some speculators here, a bad thing to write in Java because of the performance, but I can categorically say that the performance is fine and saturating network links isn’t difficult.
I think you miss the point about the threading and immutability: this virtually guarantees that you will create (and discard) more objects than you might typically do in a C or C++ application. Many will die quickly in the eden heap of course, but the effect of this is once again a space/time one and the developers have chosen to use space rather than a
copy-on-write-iff-shared with interlocks on the share count.
I agree that the VM should allow smarts that can handle stack-based stuff and boxing options etc, and that’s why I think the CLR is better than the JVM: it had the benefit of hindsight in its design and Anders is a very clever guy, with a lot more customer focussed experience than the Sun fellows who designed the JVM.
The problem with using lots of JVM/CLR apps on the desktop is not what happens when you have *one* app, its what happens when you have a dozen or more: but conversely you needn’t run separate logical apps in separate physical VMs, and that’s where having some native support in the desktop would help. The best solution would of course be to have a generalised VM interface that allowed the user to mix and match and run apps with multiple VMs (presumably CLR, JVM and Parrot at least).
CLR need not be slow, BTW. Look here: http://www.grimes.demon.co.uk/dotnet/man_unman.htm
Of course, mono CLR performance and Microsoft CLR performance are two different issues.
(the grandparent post was a reply to your comment, but for some reason ended up in the wrong place of the thread)
That sort of application that creates lots and lots of short-lived objects is indeed stressing the garbage collector heavily. You are right, with garbage collection, there is always this space/time tradeoff.
On the other hand, sometimes (when the short-lived objects are merely data-holders and it is clear when they are no longer used) it is possible to make a pool of objects and reuse those same objects. This would put less stress on the collector and the application would likely run with the same (or increased) performance but with less memory use. This is actually the programmer doing a bit manual memory management.
(taken from your original comment)
Any system that uses garbage collection will have much greater memory use than a tuned C or C++ application, particularly if its using a JIT and the compiled code is process-private and/or its threaded and uses immutable objects extensively to reduce locking.
I understand about the JIT needing to be loaded in memory itself and the JIT-compiled code, and this leading to higher memory use. However, I do think that for most applications this will only be a small part of the total memory usage. (just a guess)
I do not understand the comment about threading and immutability? I mean, yeah, if you make more objects immutable and you need to create more new objects because of that, then the collector will have more work or use more space. But I don’t really understand why the C++ application would create less objects? Because in the C++ application, one would prefer to use locks?
I do think you are right about the CLR/JVM. Sun probably looked mainly at using JVMs on servers, neglecting performance on the desktop.
The reference to the CLR benchmarks. Well.. isn’t that the kind of code that is the easiest to JIT-compile? I mean… it seems that it’s mostly pure computation of a FFT. Something that I assume, is fairly easy for the JIT to compile. I think it becomes more interesting when one also takes into account the creation of objects, method calls, etc… I also imagine that the Microsoft CLR will have better performance than Mono globally.
2 orders of magnitude slower
While usage of the word “magnitude” makes any argument sound more impressive, I’d like to point out that 2 orders of magnitude would actually be 100 times slower.
And the memory usage argument is neglible since GC apps pool memory and if you wan’t it back you can usually call a function to clean-up. Otherwise it’s using memory that is free. Now if you are running a server you may need every MB… but then you aren’t running a DE.
java could be a very nice solution for gnome
java have a very big community, most used language on sourceforge
java have a lot of ide: netbean, eclipse, idea, jbuilder
java have many great opensource software engineering to create better software
and now with gcj we can build program for many os, hardware…..
Thats mostly true.
The only reasons against [java,mono] are political ones… I dont want use _any_ mono apps and many people want use java ones (despite java IS faster than mono
see http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lan… ) …
Fortunately its OSS – if we dont like [#,j]Gnome we can use KDE or XFCE
peace
“Looking at the future without taking account of the past is very naive… Don’t forget that your average user is more likely to use a computer “from the past” rather than the latest dual/quad-core offering with GBs of RAM.”
True, but you won’t advance if you stay in the middle of both. And I’m not talking about the need for dual core processors and 1GB of memory. 3 years old PCs will do. But not because there’s still people with K6 300Mhz out there you are going to have all apps coded in C because they run faster.
“That said, applications using interpreted/evolved languages don’t have to be slow and/or memory hungry…”
Yes they have. They are interpreted, so they are slower than their C equivalents. That’s not apparent for simpler apps or command line applications. But GUI intensive applications coded in a non compiled language usually eat much more memory. I don’t know if the bindings are the problem…
“Usually, experienced programmers don’t have much problem with perceived speed and/or RAM consumption”
It’s not about it being perceived. If you only run 1 or 2 python apps that take each 15-20% of your available memory, that may not be a problem. Add a couple more and the perceived slowness will be real.
“For instance, they don’t open or keep stuff needlessly. They don’t let the GC do all the dirty job: they are doing their own part in memory management”
Well, GC are there to do the dirty job. Why would I need a GC if I just can “delete you;” ?
“They won’t choose an O(n^3) algorithm when they know better.”
Even a O(1) algorithm will be slower if completely implemented in Python than a C/C++ counterpart.
“In other words, an easy-to-use language won’t substitute competence.”
Very true. But not all programmers are really competent. Look at the Windows market. There are a lot of VB programmers that know shit. Do we want them in the OSS camp? Sure we do. Let them use Python, not C. Let the Python interpreter take care of memory allocation/freeing.
Very true. But not all programmers are really competent. Look at the Windows market. There are a lot of VB programmers that know shit. Do we want them in the OSS camp? Sure we do. Let them use Python, not C. Let the Python interpreter take care of memory allocation/freeing.
And this seems to me to be the core issue.
They are going to continue to teach people C, we will not hit a point in the future when we suddenly stop having C programmers.
The question is: If a programmer cannot handle C, if they need a poor-man’s programming tool like Mono to handle something, do you really want them working on Gnome to begin with?
Yes, I know a lot of people who use VB to program, and those I know are more competent than the average programmer… I would be happy to have them write a music player, or some sort of cheesy non-3d game, or even a web browser… but I would not want them working on my core GUI… as far as I’m concerned there is one reason to use a higher level language for programming and one reason only: you don’t want to spend the time on getting something else to work.
Fine, that works for most things. You don’t need to code a frontend for oggenc in C to make it work…
But do you want to give an easy way to allow that mentality to sneak into the team that makes the core system?
Do you want to bend over for people who “can’t be bothered” to learn C? Don’t you think that reflects in some way on their future performance in the project?
Or maybe that’s just me…
True, but you won’t advance if you stay in the middle of both. And I’m not talking about the need for dual core processors and 1GB of memory. 3 years old PCs will do. But not because there’s still people with K6 300Mhz out there you are going to have all apps coded in C because they run faster.
Perhaps, but I am still mystified when that little weather applet uses over 20MB of RAM… I have no problem with putting a K6 desktop to rest, but I would still ask myself questions if something trivial didn’t ran on it.
As for the rest, I believe you missed my point… Many people are complaining that language X is slow because of application Y and Z. Still, I have seen some Python/C# applications with better ressource usage than C counterparts because they were well developed/designed. Experience and competence have a lot to do with the quality of an application.
On GNOME… It wouldn’t be a bad idea to support an higher level framework for applications, even those shipping with GNOME like gedit, epiphany and evolution. I am pretty sure it would improve the pace of development. As long as the programmers have optimisation in mind, since I don’t want another 1GB stick for running Evo.
If only Mono wasn’t developed with Microsoft compatibility in mind… I’d like to know why they are so hellbent in staying compatible with an ever-moving target when they seem to have the skills for setting up their own framework.
“””Perhaps, but I am still mystified when that little weather applet uses over 20MB of RAM… I have no problem with putting a K6 desktop to rest, but I would still ask myself questions if something trivial didn’t ran on it.”””
On my machine, with plenty of ram so nothing is swapped out, the weather applet shows 11M resident with 8M shared. So if I turned it off, I’d save 3M. Still non-trivial. But a long way from 20M.
How can anyone say the legal issues are solved? Did something happen I haven’t heard about?
MS is explicitly allowed to charge licensing fees for its standardized CLR, as long as they’re “reasonable” and not “exclusionary.” It would be kind of hard to argue that Mono isn’t using the standard, and it would also be hard to object to, say 10 cents for installing the runtime or 1 cent per program that links to it. That would give GNOME a massive headache if they tried to collect the money or raise funds to pay it themselves, it would conflict with OSS licenses, and it would outrage the free software zealots. GNOME would find itself having to stop distribution and roll back a few years while everything got rewritten in good old C. I doubt it would be worth bothering: the project would be dead before they finished.
Maybe something better than C/C++ is needed (Disclaimer: I have no GNOME dev experience; I do have C# experience, and hate it.) Is C++ so bad, and a (supposedly) improved version of it (C#) so good, that it’s worth tying the future of the entire project to something owned and controlled by MS? If it’s really necessary to go through the agony of switching, there are better choices (if it’s a C-like bytecode language w/ garbage collection, I’d take Java (faster and more mature); I’d take Objective-C in a second; given bindings, almost any scripting language would be preferable.)
How can anyone say the legal issues are solved? Did something happen I haven’t heard about?
Well, as long as the topic has already come up, I must admit this is something that puzzles me.
The .Net core implementation is pretty free and clear, it the Windows bits that are patent laden. The mono licensing page explains that this means you’re ok to leverage mono’s implementation of .net for linux, as long as you’re not also trying to leverage it for Windows specific bits. Which is where my confusion comes from, because my understanding was that the whole point of mono (and the primary reason for Novell’s sponsorship) was to enable cross-platform development without having to port Windows applications?
Then there’s the Open Patent Initiative, which basically says that if Microsoft tries to sue a project like mono, then Novell and others will use their patents to sue Microsoft for patent infringement on unrelated technologies mostly relating to those patents on e-comm/xml implementations that Novell acquired.
I understand the concept of MAD, I did grow up during the cold war. But I don’t see how this could give Sarbanes-regulated companies the warm and fuzzies to comfortably and *knowingly* deploy technology that infringes IP (which Sarbanes explicitly prohibits). So I still see that as being a huge blocker for widespread commercial acceptance of mono unless they’re going to scrap the idea of porting Winforms et al. altogether or can work around the patents. Of course Sarbanes doesn’t apply outside the US, but it’s kind of hard for Novell to ignore the US market. Novell offers IP indemnity to customers purchasing their enterprise linux products, but where does that leave anyone using community sourced mono?
And while I was scrolling the mono licensing page, I noticed a portion stating that anyone contributing code to the C# compiler or mono runtime engine has to assign copyrights to Novell in order to permit Novell the option of allowing select customers to deploy it under non-GPL/LGPL licensing, effectively without providing back modifications. Whaaaa?
Or is mono simply intended now to become a framework for linux similar to yet not compatible with .net?
I’m not trying to flame or start anything here, but I am confused. I will confess I’m not a mono advocate, though I’m not entirely a hater either (although the package management in Suse 10.1 came pretty damned close to making me one). If mono helps advance OSS and desktop linux, I’m all for it whether I choose to use it or not.
EDIT: Just read JeffS post above, which came in before mine, so that addresses some of the questions. I’m still not completely convinced the patent issue is a non-issue though…
Edited 2006-07-19 04:24
Look at it this way (and I’m talking about the Mono/GTK# stack):
Show me a patent Microsofts owns, that covers some aspect of .NET. (This is mostly rhetorical, as to my knowledge no one is aware of any patents explicitly related to it)
Now, does Mono infringe on this patent? Does Python? Does Java? (or by extension, is the patent invalid due to prior art?)
A fact many people use to derive .NET is its similarity to Java. And it certainly is similar.
What kind of patent could there be that Mono infringes, that Java isnt prior art for, and that Mono could not work around with an alternate implementation? I wonder.
Show me a patent Microsofts owns, that covers some aspect of .NET. (This is mostly rhetorical, as to my knowledge no one is aware of any patents explicitly related to it)
The issue of patents with .Net is a bit more complex than the usual ‘the ECMA stuff is fine!’ answers you get back from various clueless people, and I’ve touched on it before on previous articles.
Microsoft has a handful of pretty broad ranging patents (and they can simply come up with more) that would affect not just Microsoft’s specific APIs, but all APIs and stuff such as the CLR, CLS etc. If you look at the ECMA specs they specify practically nothing, and you simply need to reverse engineer or bootstrap with Microsoft’s stuff if you want to get anywhere. The ECMA specs aren’t really standards to implement anything complete at all.
Microsoft does have patents that apply specifically to the .Net concept, and implementing the CLR and the stuff inside the ECMA that is required for using it – and they can always come up with more. People have tried to dodge the issue by saying the the ECMA stuff is safe, but it isn’t. At the moment, the ECMA stuff is covered by a RAND agreement that Microsoft has made clear a while ago that you have to agree to – and you agree to that with Microsoft, not the ECMA:
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2887217…
Now, it’s pretty clear that Microsoft has a broad idea of licensing there, and they haven’t changed their minds on that. At the moment, the RAND terms that the ECMA specifies is keeping things just about rosy – and those terms are highly, highly flimsy:
http://www.ecma-international.org/memento/codeofconduct.htm
The problem is, are those RAND terms guaranteed into the future? The answer is no. It does not stop a company like Microsoft patenting anything they submit, as long as they license it under RAND terms. However, should Microsoft decide to leave the ECMA, or make the ECMA standards they have submitted untenable by revoking the flimsy RAND agreement, then there is absolutely nothing to stop Microsoft going after licenses from people who’ve implemented their technology. After all, if you’re adhering to the standards you can’t claim ignorance or that you somehow don’t qualify. Mono clearly does. Claiming that Mono simply reproduces .Net is highly flimsy as well, because what’s .Net?
What kind of patent could there be that Mono infringes, that Java isnt prior art for, and that Mono could not work around with an alternate implementation? I wonder.
This is something Microsoft has been a bit more clever about. They know they can’t just have patents stick to every bit of software out there like others have done. What they’ve done in their patents is to refer to various concepts that are specific to .Net, the CLR, CLI and the framework. Should you choose to implement something similar in Java or Python, the patent actually excludes you. What Microsoft wants to do is protect their own technology and what they see as their own ‘intellectual property’.
In short, it’s a bit of a timebomb when you do some reading around. Even if nothing legally happens, Microsoft can just use it to scare the living daylights out of everyone until they either won’t touch Mono with a bargepole or get scared about what hypothetically might happen – like with the ‘MP3 patent’ – and even that’s more flimsy than the .Net stuff.
It gives developers a nicer development framework than C withougt significant increase in memory usage and loading speed, witch is still very mutch apreciated nower days, mind you.
What i see as the main problem with Gnome development is the inexistence of a good RAD framework in witch you could build stuff using python. Or any other language that allows to throw C or C++ to the mix to speed up you crutial parts of the code. With a nice, tightly integrated interface designer (VB, Kdevelop, Borland C++ Builder, #Develop…), not something like stetic/glade container based crap, where you have to learn how to place a god damn button in a freakin form.
Just my 0.02€.
I, for one, think that Mono is great. It’s highly productive, fun to work with, has a great IDE (MonoDevelop), GTK# is much nicer to work with than regular GTK+ and GObject, and the execution speed is more than exceptable.
Legality is a complete non-issue. Gnome Mono development uses C# and CLI, both ECMA standards as submitted by Microsoft. And GTK# is completely a Mono add on, with no MS entaglement. The only legally questionable bits of Mono are Windows Forms, ASP.Net, and ADO.Net. Those are reverse engineered proprietary, non standard, patented MS technologies. However, MS won’t sue (and it can’t on the ECMA bits or GTK#), because it’s in MS’s best interests to have a healthy implementation of .Net that runs on other platforms. They gain business from customers who would otherwise reject .Net in the interest of avoiding vendor lock-in. Plus, for Gnome development, WinForms, ASP.Net, and ADO.Net are completely irrelevant. They’re just there for app migration (from Windows to Linux) purposes.
Now, any interpreted langage is not going to execute as fast as compiled languages. And they are going to use more memory. This is why most commercial software, and retailware, is written in C/C++. But any DE or platform needs of higher level interpreted languages/platforms for RAD. Just look at how fantastically successful, for better or worse, Visual Basic is, and how it has helped Windows gain it’s dominance.
I’m sometimes a loud critic of MS products (and their business practices), but .Net and C# are damn fine technologies. They embrace, refine, and extend Java, to produce a really nice development tool. Why shouldn’t open source embrace and extend all of Microsoft’s (and by extension Sun/Java’s) hard work. In the end, we’re all standing on the shoulders of giants, if we’re smart.
Finally, core Gnome needs to remain C. However, applications need a higher level language/platform that is both highly productive and very powerful. Mono fit’s that bill perfectly.
However, MS won’t sue (and it can’t on the ECMA bits or GTK#), because it’s in MS’s best interests to have a healthy implementation of .Net that runs on other platforms. They gain business from customers who would otherwise reject .Net in the interest of avoiding vendor lock-in.
No, I think MS isn’t happy at all that their product is used on other and especially free platforms without their consent. Remember, the development of C# and the framework weren’t for free, but they know they are going to earn the money back, ’cause people with buy the IDE and they will run it on a MS product.
Mono just means that their idea/product is being used while they never get a cent for it, which must have not been the plan of MS.
I, for one, think that Mono is great. It’s highly productive, fun to work with, has a great IDE (MonoDevelop), GTK# is much nicer to work with than regular GTK+ and GObject, and the execution speed is more than exceptable
None of these are compelling reasons to make Mono apps part of the Gnome core, which is the topic here.
The bindings are enough.
Legality is a complete non-issue
You must be new here.
Why shouldn’t open source embrace and extend all of Microsoft’s (and by extension Sun/Java’s) hard work. In the end, we’re all standing on the shoulders of giants, if we’re smart
They do, Gnome has the bindings for most of these languages (except Ruby perhaps).
Finally, core Gnome needs to remain C. However, applications need a higher level language/platform that is both highly productive and very powerful. Mono fit’s that bill perfectly
So you agree that Mono doesn’t need to be part of Gnome core, which is what the devs in the article are asking for …
Legality is a complete non-issue. Gnome Mono development uses C# and CLI, both ECMA standards as submitted by Microsoft. And GTK# is completely a Mono add on, with no MS entaglement. The only legally questionable bits of Mono are Windows Forms, ASP.Net, and ADO.Net. Those are reverse engineered proprietary, non standard, patented MS technologies. However, MS won’t sue (and it can’t on the ECMA bits or GTK#)
Unlike W3C, ECMA does not require patent releases for technologies it puts its stamp on. There is absolutely nothing stopping a company from charging for use of its patents in implementations of an ECMA standard.
linux users do not want to see .exe and .dll files on their systems.
what is in a name? nothing. it doesn’t matter. irrational as it might be, the linux community is never going to embrace .net for reasons good and bad. better off pushing an open java.
All the Mono applications I have on my system cannot run for more than 2 hours without crashing. In addition they consume lots of memory and are slow. Everytime I update Mono, I have to recompile all my mono applications. My conclusion is that Mono is not stable enough to get into GNOME.
Python has seen over 10 years of development. It is high level, it is dynamic, it is exceedingly popular among free software hackers, it is versatile and it fits the needs of GNOME better than Mono will ever be. Mono is moving target chasing .NET’s tail. Is that the direction we want GNOME moving towards?
Python is no slower than any Mono application I have on my system. In fact, I’m developing an app in Python which launches faster than an equivalent application written in C! If your Python applications are launching slower, file a bug report.
Mono is great to help .NET developers transition their applications to Linux. And that’s about it. What frustrates me the most however is the instability of Mono applications at least when compared to the Python applications I have written and tested.
When Mono matures and stabilizes with respect the ever evolving .NET, then we can rethink adding it to GNOME. Otherwise I encourage developers to look into Python for desktop application development, if C is not their cup of tea. The Python bindings for GNOME are very mature and well maintained. And I’m speaking from experience. Besides, the Python bindings are already a part of GNOME.
Edit: I also forgot to mention Python runs on more OS platforms than Mono, especially the *BSDs. Last I checked Mono is only officially supported on Linux.
Edited 2006-07-19 08:12
All the Mono applications I have on my system cannot run for more than 2 hours without crashing. In addition they consume lots of memory and are slow. Everytime I update Mono, I have to recompile all my mono applications. My conclusion is that Mono is not stable enough to get into GNOME
The only Mono app that keeps running on my desktop is beagle, and it does not take lots of memory (when I adopted it, this bug was fixed). I don’t have to recompile it every time I update Mono either, as long as it’s very minor revisions. The apps are not really slow, but definitely slower than C Gnome apps though.
Python has seen over 10 years of development. It is high level, it is dynamic, it is exceedingly popular among free software hackers, it is versatile and it fits the needs of GNOME better than Mono will ever be
Perhaps it is so. But I still remember the switch from Python 2.2 to 2.4. And I’m sure Gentoo devs remember it very well too, as it was a nightmare, as Portage is python based. Not so bad for me, but I fear the next python version that is soon to be released. Or rather I don’t, I know I’ll have to recompile every python app, not a big deal.
But for Gnome, I have then to kill all the sessions for upgrading, which I didn’t have to do before. That’s because, Gnome already include important functions written with python (like some notifications or plugins). Granted, all of them are not necessarily part of the Gnome core, but are so important, that I don’t think one good Gnome desktop won’t use them.
Python is no slower than any Mono application I have on my system
GCompris and the famous bubble bobble clone of which I forgot the name helped prove years ago that Python could be used for desktop apps. Just don’t base your core on Python, or be prepared to never upgrade or suffer.
When Mono matures and stabilizes with respect the ever evolving .NET, then we can rethink adding it to GNOME
Mono is too intrusive for now anyway.
The only Mono app that keeps running on my desktop is beagle, and it does not take lots of memory (when I adopted it, this bug was fixed). I don’t have to recompile it every time I update Mono either, as long as it’s very minor revisions. The apps are not really slow, but definitely slower than C Gnome apps though.
I can’t even get Beagle working well on my system. A process called “beagle-helper” consistently used 97% of my CPU resource over two days. I had to turn Beagle off. The upgrade from Mono version 1.1.4 to 1.1.6 broke “all” my Mono applications. Mono, as well as Java, applications take a toll on my system that I have not seen any Python applications do. Compared to Python, the Mono virtual manager takes a considerable amount of time to initialize. Thus making the startup time of Mono applications relatively long. I don’t really care about this, however. In my opinion, Mono needs more time to mature.
Perhaps it is so. But I still remember the switch from Python 2.2 to 2.4. And I’m sure Gentoo devs remember it very well too, as it was a nightmare, as Portage is python based. Not so bad for me, but I fear the next python version that is soon to be released. Or rather I don’t, I know I’ll have to recompile every python app, not a big deal.
But for Gnome, I have then to kill all the sessions for upgrading, which I didn’t have to do before. That’s because, Gnome already include important functions written with python (like some notifications or plugins). Granted, all of them are not necessarily part of the Gnome core, but are so important, that I don’t think one good Gnome desktop
won’t use them.
GCompris and the famous bubble bobble clone of which I forgot the name helped prove years ago that Python could be used for desktop apps. Just don’t base your core on Python, or be prepared to never upgrade or suffer.
That’s odd. If I remember correctly, you can install multiple versions of Python on the same system. Gentoo in particular supports a system called slots that makes it possible. I remember there was a period I had Python versions 2.3 and 2.4 installed on my system. I don’t recall ever recompiling/reinstalling Python applications during a Python upgrade. I believe Python has mantained backward compatibility since 2.0 or 2.2. And 2.5 to be released sometime in the next few weeks will also be backward compatible.
I can’t even get Beagle working well on my system. A process called “beagle-helper” consistently used 97% of my CPU resource over two days. I had to turn Beagle off
I use the stock versions, and all is well.
The upgrade from Mono version 1.1.4 to 1.1.6 broke “all” my Mono applications
I won’t deny this, it happens to me randomly between versions too.
Fortunately, I avoid Mono as much as I can, I only have beagle and I think autopano-sift (IIRC). Beagle daemon is pretty resistant to mono version change, not the GUI apps.
Mono, as well as Java, applications take a toll on my system that I have not seen any Python applications do. Compared to Python, the Mono virtual manager takes a considerable amount of time to initialize. Thus making the startup time of Mono applications relatively long. I don’t really care about this, however. In my opinion, Mono needs more time to mature
There used to be a time when Python (or was it pygtk ?) had lots of memory leak too. I had a bittorrent client eating all my memory before.
Well, it’s finished now. I had the same problem with azureus, plus it was very slow : I never installed the java bindings again.
Python had a better fate because I needed GCompris for my daughter desktop (and now for all the Gnome desktops).
That’s odd. If I remember correctly, you can install multiple versions of Python on the same system. Gentoo in particular supports a system called slots that makes it possible
There were a lot of problems in the transition, and 2.4.0 was not stable at all and a lot of apps where no longer working.
Portage guys had to maintain their old Python revision for a long time.
I don’t recall ever recompiling/reinstalling Python applications during a Python upgrade
I’m talking 2.2 to 2.4 (or was it 2.3 to 2.4 ?). 2.4.x did not require any recompilation of all the apps.
I heard that the KDE guys are thinking to “standardize” on a high level language for rapid development, so developers who would use VB on Windows have sth. equivalent for KDE. The two languages in discussion i think are Ruby and Python. Ruby seems to evolve fast and seems to be very popular, particular through projects like Ruby on Rails. I don’t know how mature the Ruby bindings are though and how speed and memory consumption compares to other languages. Alexandria is an application written in Ruby.
I heard that the KDE guys are thinking to “standardize” on a high level language for rapid development, so developers who would use VB on Windows have sth. equivalent for KDE. The two languages in discussion i think are Ruby and Python.
It would be insanity to base a DE entirely on an interpreted language. At least Ruby doesn’t have a compiler for it…yet. I don’t know if Python has a compiler…but as long as you can’t compile Python via GCC I wouldn’t bet on a DE being standardised on Python.
Like mentioned: Python/Ruby are nice as glue languages, and really simple stuff, but not full blown GUI apps.
VM languages are particularily bad at startup performance and memory usage. Now, these are exactly the things desired for desktop applications.
Microsoft tried to build Vista with .NET. They failed, and built the entire product with proven technology. I don’t see a reason why Mono will succeed where Microsoft failed.
In other words, the desktop will have to be programmed in native code languages. C is one of them. If it is too lowlevel for you, choose Pascal, or another high level native code language.
.NET is a hype just like Java. It is here to stay, just like Java. But it will not conquer the world.
The main reason that VM-based languages are poor as you describe is the overhead of loading the VM. This doesn’t mean that it’s not something that can’t be solved.
Java web applications, for example, run within a container within a single VM, meaning that the VM need be started only once — at boot time, for all the apps and new apps can be loaded into/flushed out of the VM. That approach needs to be extended to the desktop environment in a sane way.
Further, VM initialization could also be sped up by using a checkpointed pre-initialized VM and loading that.
FWIW – I’m a computational biologist and write various things in all sorts of languages (PERL, R, Java, PHP, Postscript, bash, C, C++, and a few obscure ones). I definitely use certain languages for certain types of tasks, but overall I probably have the most respect for Java. While benchmarking Lucene recently under Linux, I was getting ~100ms load times for the Java VM 1.5 (from cache). I’m unconvinced that 100ms would be a significant barrier to use on the Desktop.
Further, I really like the idea of automated bindings. At one time I had written a toolkit that automatically wrote C++ bindings for Java and vice-versa (to make native code interfacing easier). It’s cake to do and I’m surprised you don’t see more tools that do the same between a wider array of languages.
I have given thought about using Oberon (the OOP successor to Pascal) as a base for user apps for this same reason. If it wasn’t for mindhsare issues this could be nearly ideal.
KDE 4 is using Javscript for it’s frontend.
One point which is missing in the whole discussion is the Version of the GTK# bindings. Nobody have mentioned it here or on the mailinglist (as far as i can see). As long as Gtk# can’t offer up-to-date Gtk+ bindings it can’t be an issue to integrate Mono and Gtk# into GNOME. GTK# supports GTK+2.6. All GNOME Platform Bindings support already GTK2.10! As long as Gtk# can’t keep up with the Gtk+ development it’s completely useless to for integration into GNOME which always build on the newest version of Gtk+.
“As far as Python goes it is still greatly immature despite that many years of development.”
As far as Mono goes it is still greatly immature despite that many years of development.
While I’m sure that is not really the case it’s about as true as your Python statement, ie it is uninformed and lacking any kind of basis in reality.
“And if you really like Python there is nothing to stop you from using it. ”
And if you don’t like Python there’s nothing stopping you from not spreading uninformed FUD about it.
Edited 2006-07-19 11:05
“Btw, I do agree that Python should (currently) not be used for any type of application.”
Zope, Trac, quodlibet and BitTorrent etc aren’t applications?
Edited 2006-07-19 10:56
“KDE 4 is using Javscript for it’s frontend.”
What on earth are you talking about? A *frontend* for KDE4?
“I heard that the KDE guys are thinking to “standardize” on a high level language for rapid development”
I don’t personally see any advantage in standardizing on Python for KDE RAD, and can’t see anything wrong with developing and promoting high quality development environments for both Ruby and Python.
“It would be insanity to base a DE entirely on an interpreted language.”
Of course the KDE project isn’t going to change from C++ to Ruby or Python for implementing the KDE libs and core apps.
“Like mentioned: Python/Ruby are nice as glue languages, and really simple stuff, but not full blown GUI apps.”
No this is wrong. QtRuby/Korundum or PyQt/PyKDE use more memory than the equivalent C++ apps, but you can build substantial GUI apps that are responsive with them. A good example of a large app is the Eric3 IDE written in PyQt. Because the libraries they wrap are written in C++, the bindings languages themselves don’t have to be that fast because nearly all the code being executed is within the libraries and not in the application itself.
One the other hand if the GUI app has a serious amount of code being executed like a graphics intensive game, then you would notice a slowdown if it was written in say Ruby.
— Richard
“It would be insanity to base a DE entirely on an interpreted language.”
It works just fine and dandy for the ROX desktop. Although if by *entirely* you mean that it would be the *only* language in existence that could be used then, yes but so would base one entirely on C or C++ or Mono or Java etc too.
“but as long as you can’t compile Python via GCC I wouldn’t bet on a DE being standardised on Python.”
Why? Because having to fiddle with horrors like autoconf and all kinds of different platform quirks is much better than not having to?
Is the benefit of ~2 seconds faster start time such a gigantic issue?
“Like mentioned: Python/Ruby are nice as glue languages, and really simple stuff, but not full blown GUI apps.”
Nonsense.
Edited 2006-07-19 11:09
I have been writing application commerically for .NET on mobile platforms since MS shipped their MS VS 7.0. And my opinion is very clear: It sucks!
In the beginning of the project we were concerned over the performance of the system and our concern turned out to be correct. When in need of a fast, responsive system only native code can be used. I believe we have spent the same amount of time in performance optimizing .NET ( by writing critical code in C++ ) and expanding CF .NET ( due to lack of functionality in the .NET CF on Windows CE ) as we have developing the applications.
To me it seems that if Mono is to be used for mobile devices it better out perform the MS .NET CF or else it is completely useless.
Admittedly, the .NET allows non-programmers to write applications and programmers to quickly produce a lot of applications. However, it does not produce better code. Programmers tend to get more “relaxed / lazy” due to the fact that a garbage collector will “clean the memory”. Quality have certainly gone down as well as performance.
If I had to advice anyone about programming on mobile devices my advice would be to skip .NET. I don’t know of the performance of Java on mobile devices but I know the .NET CF performance and it’s very poor. OK, I have no experience with Mono on mobile devices or embedded systems but at least the MS version sucks performance wise. I have problems seeing that Mono would outperform ( both in speed and stability ).
Personally, I have 2 more opionions:
1st. I work with MS platforms and tools. But this doesn’t mean that I’m a true believer. I like Open Source and contribute myself. At the time of writing I’m porting a Linux 2.6 kernel to our embedded system ( XScale 398 MHz, 64 MB RAM / 64 MB Flash ) for the fun of it and to get to know the performance of Linux in embedded systems. Maybe with a Java interpreter installed.
2nd. I work with high performing systems. I do not care about programmer wannabes ( meaning people with no programming skills what so ever who wants to create applications ). I help people who wish to learn how to program a system but not just by making software by clicking around and copy / pasting code. Therefore, .NET, Basic etc. are only fine if the performance is right. I think that it’s important to destinguis between 2 types of people: Those who know how to program ( maybe not the platform – but they can learn ) and those who wants to call themselves programmers just by using some framework like the .NET. The latter cannot expect any higher performance from their system.
Interestingly most comments concentrate on the “what is better” issue and fail to address the bigger picture. In my opinion the main question is “what belongs into the GNOME core and how we complement this very core?” Because these components are delivered in a timely fashion, tested together, translated, etc. This is the question which sparcled the endless sweet flame wars about “what product/technology is better”.
The core is written in C with portability and speed in mind and this is a good thing(tm). Valid concerns are rised that attracting new developers which will build the cool killer apps of tomorrow is not possible if they are not able to fast code they ideas in some higher level language. But surprise, surprise – one already _can_ code in a high level language for GNOME. And not only one of them is available. The problem with this approach is that their virtual machines eat memory. And if you have one MONO, one Python and one Java app running, you’ll pay with memory for the three VM’s executing the three applications. This is the only reason I can think of for choosing one “official” high level language for the desktop – for preventing too high memory consumption.
Another aspect rised in the GNOME thread is that the desktop now is kind of naked. It comes with very few applications like calculator and text editor. I see this too as a good thing(tm). Two solutions for remeding the situation without bloating the core are possible: let the distributions package additional software or make meta packages for multimedia, games, development, language bindings… The drawback of the first approach is that the packages are not officialy “blessed” from the GNOME hackers with translations, timely releases, etc. The second one is better in this regard but still does not address the increased memory consumption because of the need for supporting several virtual machines.
So the question “what is better?” is only meaningful in the context of the question: “how do we want to deal with the need for RAD in GNOME?” One questions – many different roads each with its own quirks…
Did linux sneeze?
THe mono team continues to dig the Linux grave.
Javascipt is being used in KDE 4 for the for scripting of applications.
Quotes:
“# scripting instead of C++
# using ECMAScript (aka JavaScript) as the default language for widgets”
“redesigning applications so they are able to be optimized better. For example, the desktop and panels are being merged into one app, which also provides for functionality now only available in Superkaramba. The resulting design allows us to much more efficiently share application launch, graphics, and geometry coordination data while also avoiding the overhead of multiple processes where just one will do quite fine. This will allow people to have quite flashy desktops (or even simple plain ones) that are snappier and take fewer resources.”
http://www.linuxdevcenter.com/pub/a/linux/2006/01/12/kde4.html?page…
Gnome should support scripting at a high level for the apps to talk but not something like Mono as it’s too large. Am I on track?
Widgets are the same as Dashboard, Konfabulator and the new Vista thing etc. Not widgets as in toolkot widgets.
He was talking about VB-programmers so I don’t think he was talking about the big full blown gui apps. I think it would be nice if I’d start programming a small program I’d know which one to choose, now it’s like oh there’s python, there’s ruby there’s mono, there’s java there’s… If they’d pick a standardized language it’d make it easier for newbies.
not tested without a jvm…
i done some test with
http://www.laboiteaprog.com/article94-5
http://www.laboiteaprog.com/article94-5
i took the code from javabench
gcj is better day after day
there a lot more java programmer then c# with mono
C++ could be nice too…… stop to said is difficult…. just say kde, every week there are many people who joins kde…. can you say that for gnome? no
I haven’t even stepped into GNOME as the C looks very raw wordy. Quite scary although I do like raw stuff sometimes. I have only worked with C++ in QT.
Also I will try WXWidgets before I try GTK because I noticed at least they get their back buffer clearing right. That makes a statement. VLC player.
On OpenSuse 10.0, Banshee took a seemingly long time (longer than say XMMS or Amorak) to load my playlist. This slight lag is a turn off when selecting which software I will use.
Software like Beagle, Google Desktop, and Spotlight are very important in today’s world of ever expanding hard drive sizes. However, Beagle is the only real solution on Linux. Do you just kill off Beagle due to Mono? Who would start a similar project? The only distributions who would see any reason to create a desktop search program would be an enterprise oriented distribution. Both Novell and Red Hat use Beagle by default, and Ubuntu and Debian have not concerned themselves with this issue. So, unlese Debian and Ubuntu create their own solution, Beagle will be the program for complex hard drive searching.
I never used F-Spot that much, but I liked what I saw. Some have complained about the closed nature of Picasa (as well as the poor job in “porting” it to Linux), so F-Spot is the best option for Gnome users who want free software. Like Beagle, F-Spot fills a void, and I think more distributions would be willing to adopt this program than fund/create a mono-less alternative.
As to speed, I see lots of posts about progamming languages that relate to the speed/ease of use debate. As somebody who is not a programmer, I don’t not understand much of the technical details, but I can see the larger picture. The more programmers laugh off speed/memory issues with the arguement, “Memory, hard drives, and processors are getting cheaper, faster, and bigger with each passing day”, the more Linux runs the risk of becoming bloated. The Linux community can sit back and laugh at the very high requirements for Vista, but they could soon find themselves in a similar position one day.
As poorly as I have described Mono, there is another important point to consider. If the programming community decided to kill off Mono by refusing to write with it, how far back does this keep the Linux community? F-Spot and Beagle, for example, fill a void where Apple can say, “Look at what we have, you can’t get this anywhere else, its part of the Mac experience.” Linux is working hard to gain parity with MS and Apple on the desktop front, and Mono is a part of these gains. I, and others, have complained about Linux companies reinventing the wheel with respect to certain applictions. For example, Red Hat with Pirate/Pup when other solutions exist (Synaptic, Yumex, Smart). So, wouldn’t rewriting Mono apps in python/ruby/java/whatever fall into the aforementioned problem? Shouldn’t the Linux community act like a community and work together to solve problem instead of working independently? I don’t know what the solution is, but Mono is taking a more central position with respect to Linux, and both adopting and opposing Mono create their own problems.
However, Beagle is the only real solution on Linux. Do you just kill off Beagle due to Mono? Who would start a similar project? The only distributions who would see any reason to create a desktop search program would be an enterprise oriented distribution. Both Novell and Red Hat use Beagle by default, and Ubuntu and Debian have not concerned themselves with this issue. So, unlese Debian and Ubuntu create their own solution, Beagle will be the program for complex hard drive searching.
Beagle isn’t really entrenched, there’s far too many people that still have trouble with it, even if you peruse the Suse forums you’ll find that the advice often given is to simply disable it.
Plus KDE 4.0 is going to have a pretty deeply embedded search system of it’s own that is already looking fairly slick. There was some debate about whether or not to waste time porting one to 3.5.x, and the decision was to focus on the upcoming major release. That search technology can be picked up by any distribution supporting KDE, which would be pretty much all of them, enterprise, community or commercial.
Also worth pointing out that Beagle is a standard for Novell and Fedora, but not Red Hat, who has resisted using mono in the enterprise products for various reasons and only acquiesced on Fedora because of the patent-crossfire situation that was created and the relatively limited liability. Point worth considering.
I’ve got no problems giving Beagle credit, when it was working on my desktop (KDE no less) it did more or less exactly what you would expect it to do and did it reasonably well when it wasn’t sending my CPU into overdrive.
But given everything I’ve read about mono and my experience with Beagle and Suse’s monster of a package management system, I’d have to question the logic of using something like mono for core system components, something that runs as a daemon and is more or less a depedency of the basic OS, especially since there seems to be a consensus that using mono or any other high-level managed language does lead to higher resource utilization, offset by faster development time.
FSpot, Banshee, fine, they’re applications, they use memory, and when they’re done, they release it. Maybe they have bugs, can’t necessarily pin that on mono alone, bug-ridden software in linux is hardly unique.
But Beagle and Zen sit in the background using resources constantly, which pretty much means that they’re denied to the rest of your system. My understanding is that MS dropped .Net from core system components in Windows for a similar reason. So this puzzles me.
I guess my basic problem with services like Beagle and Zen is that mono was chosen as the framework for the sake of using it, not because it was decided with would make the best choice for what is ultimately required. Novell clearly has an agenda there and needs to be careful.
Like I said before, I have nothing against mono in concept and I support anything that advances the state of OSS or desktop linux.
I do think though it needs to evolve a little more and gain acceptance; right now I feel like I’m having it rammed down my throat sometimes (by Novell that is), so it’s leaving a bad taste in my mouth. I suspect some in the Gnome community feel similarly about it becoming a dependency, albeit for different reasons, but there should be a choice. Best tool for the job, right?
I’m glad to hear about the KDE 4.0 search feature. With respect to Novell ramming Mono down your throat, yeah they are. In fact, they are rewriting pretty much everything in Mono, for better or worse. The fact that OpenSuse and Fedora use Mono (I think Mono is in Debian testing as well) means that it will one day make it to SLED, RHEL, Debian Stable, etc. As much as I like Gnome, I hope they don’t adopt any technology that would create bloat.
Why does it obsolutely have to be a C variant?
Because Lazarus is not known yet to enough people. It will slowly get better.
Because Lazarus is not known yet to enough people. It will slowly get better.
Not even remotely possible. Pascal-Lazarus combo to be core gnome. I even doubt one single app made with lazarus could make in core Gnome. Hell, I’m willing to bet.
Why?
1. Lazarus form editor breaks every HIG rule gnome has, by every aspect. gtk design is based on cointainers and layouts. Default form editing in lazarus is with fixed container across the form to be delphi alike. I could bet that every decent gtk coder would overturn in grave for this fact alone.
2. Wheel reinvention. By reinventing controls, instead using default ones. By not reinventing it as gtk defines. You should admit that lazarus-fpc people work more on achieving delphi vcl feel and look than gnome.
3. Because there is no bindings for gnome except gtk?
If you don’t believe, try submitting app which you think it is most fitting for the inclusion.
You are right, lazarus tend to imitate VCL,but if we talk only about the languaje (forget about lazarus) Object Pascal is well structured, easy to learn, and Object Oriented besides is not interpreted and is as fast as C.
> Not even remotely possible. Pascal-Lazarus combo to be core gnome. I even doubt one single app made with lazarus could make in core Gnome
Correct, I don’t think that is what the Lazarus developers are targeting, they are more looking at applications like OpenOffice.org or Evolution and I convinced it is a matter of time before we will see such a Lazarus project.
That said, it should be no problem to develop a pure GTK app (no LCL) with the proper container usage and therefore an app that will comply to GNOME guidelines. The question is IMHO more wether the GNOME team will tolerate a Pascal compiler in its build toolchain.
As much as I’m proponent of mono for apps (mono simply rocks for GUI apps). Would I like it to be in the core of gnome?
NO.
Would I like python?
NO.
C++?
NO.
Why?
1. Something not being core of gnome is not equal to being forbidden to write in.
2. Add C++, mono, add python, add java, add haskel, add god knows which language. You suddenly end up with more dependancies you want. Releases will start to suffer. Downloading gnome will be made of 1GB of VMs and 100MB of gnome. Now fit this on 256MB flash or live CD.
3. Core should be simple, straight forward and as basic as possible. C is enough.
4. Something not being in core does not mean it can’t be included. Distros decide what will be running inside not gnome. Nicest example is SLED10.
5. Inclusion of all VMs and languages will just put more strain and requirements on distro makers. Addition was always simpler than subtraction when someone is considering packaging a distro.
6. For now default libraries are straight forward. after inclusion? NOT. There will be more glue code than actual library code. And you’ll never know which VM (or more) you run at this time in your app.
7. What would follow next? Inclusion of every god damn database in core gnome? Why not include KDE and kernel while they’re at it?
Core (all 3 parts as they are now should stay as is). But maybe adding 4th part (aka. World and if it would be separated into VM Worlds even better) would not be bad, it would give the same opportunity and at the same time contain all benefits of current environment
1. Gnome wouldn’t suffer.
2. One could decide on using it or not (or which one if separated).
3. Maintenancy would be straight forward
4. Easier deployment decisions and packaging
You’ve missed the entire purpose of this discussion.
Right now what you described in #2 is what is happening. The idea of picking a standard high level language is to keep most people on one high level language, so as to avoid #2.
#3 is impossible with c. Gobject is just not straightforward and simple
. It takes a lot more mnemonic than, say, using a language with constructs for inheritance in the like.
And of course, you’ll be able to do Gnome in c until Gnome isn’t written in c.
Right now what you described in #2 is what is happening. The idea of picking a standard high level language is to keep most people on one high level language, so as to avoid #2.
[sarcasm]Yep, and while you are at it, do rewrite gnome in that language…[/sarcasm]
Ok, first part was a sarcastic remark. You can’t just say “to hell with it, lets pick another language”
#3 is impossible with c. Gobject is just not straightforward and simple
. It takes a lot more mnemonic than, say, using a language with constructs for inheritance in the like.
In that case I would vote for C++. No matter how much I hate C++. It would be only logical successor. Least deps, least changes.
And of course, you’ll be able to do Gnome in c until Gnome isn’t written in c.
Is that a mistake? I suspect you were trying to write c#.
Now, that wouldn’t be gnome anymore. That would be another desktop.
No. If anything, a proper superset of C, objective-c would be the logical successor. C++ is not a good C successor as it doesn’t compile all C code.
Now, that wouldn’t be gnome anymore. That would be another desktop.
Gnome is not defined by its implementation but by the environment it creates. If Microsoft rewrote its Windows desktop in C# so that the interface was entirely the same would it no longer be Windows?
Most of the rest of what you said was no coherent enough for me to understand. Maybe we’re on different wavelengths here…
No. If anything, a proper superset of C, objective-c would be the logical successor. C++ is not a good C successor as it doesn’t compile all C code.
Yep, you’re right
Gnome is not defined by its implementation but by the environment it creates. If Microsoft rewrote its Windows desktop in C# so that the interface was entirely the same would it no longer be Windows?
Yeah, in MS case, you’re right. They control everything. In FOSS, this would be harder. I imagine that quite a few of developers would oppose this and rewriting would result in fork (aka. different name and different desktop, there can’t be two Gnome desktops).
You would simply have a mexican standoff between two groups of developers. Either that or you posses some magic power to persuade each and every developer which language is the best.
And if not? Wwhich project would retain name Gnome? Original or rewrite (which has not even started yet)?
Most of the rest of what you said was no coherent enough for me to understand. Maybe we’re on different wavelengths here…
I guess you mean sarcasm part. Hope fork explanation is now better than previous sarcasm.
There’s been some complaint about pygtk being slow, so I thought I’d address that.
http://www.public.iastate.edu/~chris129/code/pygtk_proof.zip
Run time and testpy.pyc within the “time” functionality of bash and you get something like this:
[chris@rachelanne Pygtk_proof]$ time python testpy.py
real 0m0.253s
user 0m0.188s
sys 0m0.056s
[chris@rachelanne Pygtk_proof]$ time ./test
real 0m0.095s
user 0m0.060s
sys 0m0.016s
That’s three times slower, which sounds pretty reasonable for a python program
. Especially since it’s not drawing anything, which I skipped because:
a.) Getting a time with the main loop involved is pretty difficult.
b.) The drawing is done by the library, the wrapper has nothing to do with that, so that time should be constant anyway.
Pygtk is acceptably slower than gtk.
All this talk about using higher level interpreted languages for Gnome application development has brought up a lot of valid points.
There are problems associated with using anyone of them. They all use lot’s of memory. They all have varying degrees of upgrade problems. Using muliple VMs is a real cpu/memory hit, let alone just one of them. They are all sort of “ify” on their maturity, paticularily when it comes to Gnome app development.
Then there is plain old C, and GTK. C is about 36 years old, and still going strong. It’s ranked second (to number 1 Java) in language popularity by Tiobe. It’s second on SourceForge (again, to Java). It’s the primary laguage of most OS kernels, device drivers, and embedded systems. It is, along with C++, the most commonly used language for commercial software and retailware. Most of MS’s programs are plain old C, or C++, using the Win32 API. Most Gnome apps remain C, with a smattering of C++, Python, Java, Perl, and Mono.
C is very consistent across platforms. Most C compilers are 100% standards compliant, as C is a minimal langauage and standard (and thus easy to meet the standard). While most C++ compilers are not 100% standards compliant, as the C++ standard is huge and complicated and very difficult to meet.
And then there is Glade for easily making GUIs with drag and drop, and Anjuta as the IDE for managing, compiling, debugging, and packaging the project. These are very good tools.
And even though C does not support OOP natively, it is fully supported through libraries (GObject). I have the Gnome2 Developer’s guide, and it explains it well. It’s a little harder than a language that natively supports OOP, but not that much harder. And as a benefit you get a more consistent ABI, and cross platform/compiler compatibility.
I guess ultimately it boils down to, for productivity’s sake, to tools, not the language. Tools are where it’s at for developer productivity. Using good tools, a dev can be very productive with plain old C and GTK+.
And, apps written in plain old C tend to be faster and use much less memory than apps written in any other language.
So, Mono, Java, Python, whatever else, should always be considered add-ons, and not a required part of core Gnome.
Again.
The point of standardizing on one language:
1.) Maintenance for bindings is concentrated one one language, so you know they’re excellent in at least one other language.
2.) Most apps will be written in this. So, with any luck, you’ll only need one high-memory-cost VM running. Otherwise people will write in python, c#, and Java and you may have all three running…
3.) A rapid development language is needed to complement a rapid development environment. And while those sorts of things won’t be seen in Gnome proper, many people do need to rapidly develop their own small tools. Tools are great, but there are still problems in C which tools haven’t fully solved:
a.) Stack corruption can be quite difficult to narrow down.
b.) Heap corruption involves complex software like valgrind to track automatically. In order to have your app run even close to a reasonable speed with valgrind you need the latest hardware (2 years ago you just accepted that it ran real slow).
Those things are going to add at least some time onto your devel, although you can mostly get around them by paying a speed price: Use gc and allocate your buffers on the heap.
Having assured support for one high level language would help Gnome to, hopefully, have fewer high level languages used in its extra applications.
If they want .net though, I think it’d be good to wait for Mono to mature a little more. Maybe when they switch out the garbage collector.
I find strange that noone is concerned about who defines the technology. Mono is an implementation of a Microsoft defined technology.
Yes CLI is an ECMA standard but who has a say on the evolution of that platform? What if we don’t like what .Net 3.x and/or C# 3.x turn out to be?
It seems to me that much of the discussion is about the technical and legal reasons for and against using Mono.
And that’s great. I have no strong position for or against.
But it seems to me that looking to recent history yields an analogous situation: Linus Torvalds’ decision to go with Bitkeeper for the Linux kernel.
Linus became focused on the technical argument and lost sight of the fact that it was a poor fit for his particular development team. Not a poor fit for the kernel, but for the team. He obsessed on his personal opinion about “not using an inferior tool for idealistic reasons” and forgot that it wasn’t just his opinion that mattered.
A substantial portion of his team had issues with BK ranging from trivial, to medium, to large. And despite whether their fears and concerns were right or wrong, justified or not, those fears and concerns did not just “go away” with time. They continued to smolder until finally whatever forces that were keeping the structure stable couldn’t handle it anymore and Linus had to code like hell to replace BK on short notice. (Yes, I know that technically LM withdrew the license, but only because the situation had become intolerable even to him.)
I see a very similar situation here with Gnome and Mono. It is very important to understand that it does not matter what the “truth” is about the technical and legal issues (pro and con) surrounding Mono. All that matters is perceptions and opinion. And as with BK and the kernel developers, I don’t see perceptions and opinions changing all that much over time.
And for that reason, I believe that making Mono a Gnome standard would hurt Gnome development in the end.
Edited 2006-07-19 19:31
On repeated point in this thread is that users run into big trouble if they, for intance, launch a Java app, then a Python app, then a Mono app, and then whatever other VM/interpreted language. Each one of those VMs/interpreters use a large chunk of memory by themselves, but if all are running at once the system will be brought to it’s knees. And just think about all those objects out on the heap, waiting to be collected by their respective garbage collectors.
The answer is one standard VM, that is capable of running multiple languages, and can run GTK+ bindings with no problem.
Mono could do this, as it already runs C#, Java, Basic, Boo, and Python.
However, the MS IP issue is something that won’t go away, and it is far too risky to standarize on a VM that is controlled by one corporation, and a corporation that has a very poor history for it’s business practices and lawfulness, and for being quite hostile towards open source.
The JVM is a decent candidate, as it not only runs Java, but also Python (Jython), and Groovy, and can theoretically run others. It’s IP owned by one corporation, but also has a JCP, and has open source implementations, and Sun intends to fully open source Java, and Sun does not have a big anti-open source history. However, the JVM runs Java well, and Jython users like it, but there isn’t much else that Gnome devs will like.
Maybe, just maybe, Parrot will be the answer. It’s being designed in conjunction with Perl6 (yet to be released), but it’s designed to run any language. We’ll see how it goes. But the thing is, Parrot is not owned by a corporation, and it is fully open source, being available in both the GPL and the artistic licens.
Edited 2006-07-19 21:53
“Perhaps, but I am still mystified when that little weather applet uses over 20MB of RAM…”
That’s the problem with these languages. Perhaps for more complex projects you get to a point where you add a couple of more MB to the RSS memory used by the application, but then it’s a complex program, worth that. But I look at something like Tomboy, a note taking application (on steroids if you want), and I think it should have been developed in C/C++, not mono. Evolution, coded in C is horribly slow (don’t know if it’s GUI developers fault or GTK fault). I stopped using Evolution because of this perceived slowness.
“Experience and competence have a lot to do with the quality of an application.”
I give you this.
“On GNOME… It wouldn’t be a bad idea to support an higher level framework for applications, even those shipping with GNOME like gedit, epiphany and evolution. I am pretty sure it would improve the pace of development. As long as the programmers have optimisation in mind, since I don’t want another 1GB stick for running Evo.”
GNOME’s problem is the lack of a framework, if I compare it with KDE. GNOME has an assorted set of libraries (many of them are really well done), but no framework for building complete and integrated applications easily. And you cannot build your framework on mono’s shoulder, because that limits applications to being done using the CLR. The CLR may be powerfull, but it doesn’t fit Python or Perl or Ruby or C or C++.
“If only Mono wasn’t developed with Microsoft compatibility in mind… I’d like to know why they are so hellbent in staying compatible with an ever-moving target when they seem to have the skills for setting up their own framework.”
Well, Mono is a clone of .NET, so it must stay compatible with .NET or will loose interest outside of GNOME’s field.
Speed is usually an issue with the design of a program more than its host language. Let me give you an absurd example of how something can be badly coded quickly, vs doing it correctly:
Say we have a gtk textview, this is the thing that shows paragraphed text, like the textbox you type into on your web browser. It has a textbuffer which stores the actual text. So, let’s say you wish to append the string ”
Yo!
” to it (”
” means endline).
buffer.set_text(buffer.get_text() + ”
Yo!
“)
That line is actually wrong anyway, you need a couple of easy to get parameters in get_text, but I thought they’d crowd the point. The point is this is easy, and quick, and simple to understand. It’s also slow. Gtk provides a better way:
buffer.insert(buffer.get_end_iter(), ”
Yo!
“)
Still a one liner, but this is much faster with the way Gtk is designed. What if we wanted it in the middle? It just gets uglier from there.
You can make the same easy mistakes in C as you can in any high level language. C programmers can just get away with a couple extra mistakes, small mistakes.
I can’t stand Python, I’m not sure I like C# (or CRL) and I only use C when I have to… but wait! It’s so *easy* to link or connect or wrap-around my language of choice to the necessary C libs, and forget about it from there!
My Ruby apps can use the Oracle (via DBI) libs, my Common Lisp programs can call the OpenLDAP functions, and even li’l ol’ Java can connect… Whereas even C++, with it’s (usually) internally-obfuscated function-names can be an absolute PITA to link against, so I **definitely** don’t want to be forced down the Python/C# route and then have my language of choice become “not really supportable” — I don’t care how popular you all think they are!
I am pretty familiar with all that I was referring to stuff beyond widgets though just general desktop tools that are using Javascript in KDE. I don’t think that it’s only being used for their Widget system although that’s a prime example.