Coding The Future Linux Desktop [updated]

the.jedi writes "With the release of GTK+ 2.4, and Gnome 2.6 due out some time next week, it seems of some the Gnome developers are looking at how they'll be coding Gnome and the rest of the Linux desktop. Havoc Pennington of Planet Gnome has written a short blog pondering and analyzing the available options as coders move towards high-level languages like java and C#. He gives a good overview and assessment of technologies like mono, OO.org's UNO framework, as well as other ways of tying new languages to the existing code base. An extremely interesting read for desktop linux hackers everywhere." Update: 03/17 14:44 GMT by T : Speaking of the future of Gnome, aeneas writes with a list of Gnome 2.6 release parties around the world (linked from gnome.org/start/2.5).

Comments

Next week I will be coding the Linux desktop:

[Realistic_Dragon]

[] in C
[] in scheme
[] in mono
[] in asm
[X] in a penguin suit
[] whilst eating a banana
[] upside down
[] badly
[] perfectly
[] in an easy to use fashion
[] as a placeholder for my terminal windows
[] to look just like Windows

Re:Next week I will be coding the Linux desktop:

[robbyjo]

For Slashdot tradition completeness sake:

[] with Cowboyneal

or

[] I don't code in Linux, you insensitive clod!

How about still using C

[Xargle]

We'd actually get a performance gain without a 4 way Xeon and gigs of memory, and apps would even downscale acceptably to mobile devices?

Re:How about still using C

[IamTheRealMike]

You've clearly never spent hours tracking malloc arena corruption, insidious thread safety bugs, or enjoyed the benefits of a clean OO syntax.

No. C has its place for sure, but for writing desktop apps it's the wrong tool for the job.

Still, I have to admit, this is something that could go so many ways. Right now Mono has the mindshare in terms of Gnome/GTK# apps, people are playing with it, liking it, there are actually unique interesting apps (like Muine) written in it etc. Where are the interesting GTK/Java apps?

On the other hand, the GNU java toolchain is nicer than Monos. GCJ is a really nice, easy to use compiler that's pretty fast and it creates ELF binaries. It fits in with the existing infrastructure, reuses our investment in ELF and the resultant apps don't have strange EXE and DLL extensions.

Java-GTK is apparently also quite a mature set of bindings, though I haven't used them so I can't say for sure.

I'm not convinced the patents thing is really valid. If Microsoft have patents on their class libs I think it massively unlikely Sun don't have patents on theirs. Worse, I suspect that even if there was a completely open source, newly designed framework that was similar to Java/.NET it would fall under those same patents.

We probably just have to ride them out.

I think Havoc is off base with the XAML comments. XAML will only be usable with the arrival of Longhorn which is in, what, 2008 now? It looks a lot like XUL, and yet where are all the XUL apps? Firebird is still the flagship XUL app, even after all this time. I certainly cannot see XAML taking over HTML anytime this century, there's simply too much investment in HTML and XAML isn't compelling enough from what I've seen to offset that.

Re:How about still using C

[Anonymous Coward]

Short and simple answer? Because higher level languages generally abstract the programmer from making low-level routines that can seriously affect how much time the programmer puts into the look and feel of an app. For me as a user, I often get annoyed at programs that do their functionality well, but have horrible UI and horrible design.

For me as a programmer, I use REALbasic (not mentioned in the article). The IDE isn't on Linux, yet, but the remote debugging works well for me. It's compiled down to native machine code, allows for expandability through C/C++ plugins, and helps me effortlessly lay out my UI. It looks like a pretty solid product

Re:How about still using C

[NonSequor]

Here's my philosophy: the computer is here to do my work not the other way around. When I write a program I want to expend my effort only on explaining how it should work and not worrying about things like memory allocation.

What's worse is that C forces you into a certain way of thinking. Other languages make it easier to work in other styles so you can actually implement the algorithm in the way that you come up with it.

I've got a nice computer and I want to take advantage of it. I don't write much software, but anything that could make it easier would be welcomed.

Re:How about still using C

[Anonymous Coward]

You've got to remember that Havoc Pennington is an amazing coder. He's managed to make a window manager with fewer features than, say, IceWM, WMaker etc., and yet it's bigger and takes up more memory! That's quite an achievement. It's like writing an editor less featureful than Pico, and yet it uses more RAM than Emacs!

A lot of these modern coders on their 3 GHz boxes don't appreciate elegance of design, nor do they think highly of efficiency. It's a shame, but c'est la vie. They're only hurting Linux's desktop uptake in 3rd world countries and businesses with millions of old machines. You think a P500 with 64M, of which there are millions, can run GNOME + OpenOffice.org + Mozilla? Linux is going to be royally screwed unless we start paying attention to efficient design and coding.

And that includes you, Havoc.

Re:How about still using C

[RailGunner]

I don't think it's a question of time invested as far as poor UI design goes, I think it's more of a problem that most engineers don't really know how to put together a User Friendly UI, because let's face it - we think the CLI is pretty user friendly.

UI's could get much easier to use if developers would just select the right widget for the job. For example: Have a two state switch? Whether some feature is enabled or disabled? Please, just use a check box. The goofy group box with the two radio buttons (one labeled "Enable" and the other "Disable") is just clutter.

Another tip? Ask a graphic designer to layout your UI, then go and implement it. Graphic Designers study the best way to graphically communicate an idea, so (speaking from experience, my wife is a graphic designer) they can be a terrific resource in laying out a UI.

Finally, if you're using any kind of graphical UI editor like MSVC, Glade, Qt Designer, etc.. it just takes a second, but line up your widgets for crying out loud. Nothing screams amateur loser like controls that don't line up correctly.

And remember - your average customer doesn't see the elegant code you wrote under the hood - they see your UI. Especially remember this when writing Linux UI's - one thing MS is fairly good at is putting together a consistent UI. Might be ugly as sin like WinXP's default, but it's consistent.

Re:How about still using C

[ichimunki]

What I don't understand is why so much attention is on Java or C#. Is it only because with runtimes these are the languages out there that compile down to some form of byte-code? Don't we then perpetuate the problem of having to match binaries and runtimes just as we now have to match binaries and platforms (thinking x86 vs. PPC and the like).

I should think we'd all be better off if more and more end-user apps were being written in interpreted languages like Ruby, Python, or Perl, using the appropriate GUI bindings (my personal favorite is Ruby-GNOME2, especially just the GTK bits, since those are supported on Windows for an added portability bonus). Porting scripts from one GUI toolkit to another is often quite possible as well since the differences are often minimal (just don't get distracted by that ever-sought Holy Grail of the Meta-Toolkit). Not only that, there appears to be some promise for the idea of using libraries written in any C-based scripting languages from any of the other C-based scripting languages (just as they have excellent capabilities for using C libraries).

Re:How about still using C

[Moraelin]

I don't know about him, but I've spent time debuging malloc/free bugs. I also earn a living with Java right now. So I have at least some clue of its advantages.

And, sorry, I think there's a reason why Java is popular on the server side, and why you don't see any killer desktop apps written in Java. And why I'd actually like it to stay that way.

Off the top of my head:

1. I'll say _you_, then, haven't spent days debugging a Java memory leak. Especially in a Swing program. One single listener you've forgot to explicitly remove can keep whole forms or even whole windows still loaded in memory. No, the garbage collector doesn't automatically free those.

2. The garbage collector does _not_ play well with the swap file. It causes each page belonging to the Java heap to be regularly paged in. Often. Several times per garbage collection pass, in fact.

So whereas a system which stuck to C or C++ will still run at full speed when I load 550 MB of programs in a 512 MB of RAM, a 100% Java system would trash to death at that point. (In fact, see point 2: much sooner than that.)

Or if only 300k out of that is Java stuff, it will act all elbows to the other apps. It will keep bringing its own pages in, and forcing everyone else to do with less memory.

And no, this problem isn't solved by compiling to ELF. As long as you have a garbage collector, it happens anyway.

3. Java RAM usage is ludicrious, especially for a system based on small utilities, like *nix is. I've actually had to write once the exact same small GUI utility in both C and Java. The C version ran in under 1 MB. The Java version allocated 16 MB right upon startup.

It gets worse from there. Even minimal string manipulation or use of trees will easily use 2-3 times more memory than in C. Stuff which in C/C++ goes on the stack, or is allocated together as part of a single struct, in Java ends up a twisty little maze of individually allocated objects, each with its own memory overhead, above the size of the data in it. A simple String is two objects for example.

4. It also has horrible startup time. No, sorry, I don't want to wait a couple of seconds just for the JVM itself to initialize, each time I launch an application. And I think that both Gnome and KDE are already proverbially slow to start as it is; they don't need to add half a minute to their startup time just because the gazillion apps they run on startup are Java.

5. Swing is slow. It insists on painting every single pixel in the window personally. Basically if you have one form in a swing window, the whole window is one big canvas, on which the individual buttons/fields/toolbars/menus/etc are rendered in software, pixel by pixel. If that's your idea of a fun desktop, may I humbly suggest setting your X to use the VESA framebuffer instead of whatever accelerated driver you're using?

6. It also requires quite a bit of clue to use well. See for example the listener leaks I've mentioned before. Or it's very easy to write GUI code that's dead slow, if you don't know what you're doing. E.g., code which takes several seconds just to fill in the values in a combo box.

Etc.

Basically, I'm all for Java and all, but I sure as heck don't want it on my desktop, if I have a choice. When I run a web browser or an IRC client program, I very much like them to be well behaved applications which don't play hardball with the paging. I also appreciate if they don't allocate 3 times more memory than they really need.

So, sure, the Gnome team is free to switch to whatever language they please. But the day they release a desktop based on Java, it'll very likely be the day when I kick Gnome as whole off my hard drive.

Re:How about still using C

[IamTheRealMike]

I assume you're referring to the size of libgcj as a reasonably complex assignment I did for a compsci class recently is only 114k on disk.

At 8mb on my system (that includes the java class library) that's pretty light. For comparison .NET on Windows weighs in at about 30mb and the Mono RPM (compressed) is about 8mb as well, so it's certainly competitive.

Re:How about still using C

[IamTheRealMike]

Um ....

1) Mozilla and OO are written in C++ not Java or C#

2) Java on a modern hotspot JVM can outperform the equivalent C++ code for stuff that isn't IO limited (ie number crunching stuff)

3) GCJ compiles Java to native code anyway.

I'm not sure I see your point.

Re:How about still using C

[bzzzt]

Well, your "example" smells like crappy Java code. There are lots of benchmarks telling more about the speed difference than your single example.
As for mathematically impossible: since the jit has access to runtime profiling information it's certainly possible to outperform a static compiler on some code. When the jit compiler is finished it stays out of the way, so the speed degradation is limited to startup time only.

Re:How about still using C

[maxwell demon]

Modern C++ compilers also have access to profiling information. Moreover, they then can optimize over the true average rather that what happens on the first few times that code is encountered (which may not be that typical).

Re:How about still using C

[pivo]

1. I'll say _you_, then, haven't spent days debugging a Java memory leak. Especially in a Swing program. One single listener you've forgot to explicitly remove can keep whole forms or even whole windows still loaded in memory. No, the garbage collector doesn't automatically free those.

Well, then I'll say you haven't spent time debugging C or C++ code. My previous job was C++ UI application development, for the last five years I've been doing Java Swing UIs. There's simply no comparing the frequency of memory leak type problems on Java and C++. I haven't had a memory leak problem in years in Java, it's just too simple to avoid.

Re:How about still using C

[AndyS]

But even so, this information might not be useful.

For example, GCC compiles per file. It doesn't compile the project as a whole, so it can't perform cross-module optimisations.

Another example, how do you efficiently optimise a library statically? Not only that, but the behaviour of the application might depend upon, for example, a read-in piece of text (to determine, for example, if it logged or not). A sophisticated JIT can then generate more optimised code than a C++ compiler over time.

There are loads of cases where a JIT can outperform a static compiler. That's not to say that static compilers don't have a large number of strengths, or can't be modified to overcome a large number of these weaknesses (whole program compilation is already pretty much there for gcj, adding it to the gcc in total might not be that difficult, likewise a runtime profiler could rely on static hints for places that might be good to optimise, akin to dynamo). But at the moment, JITs don't necessarily lose out.

Re:How about still using C

[egomaniac]

1. I'll say _you_, then, haven't spent days debugging a Java memory leak. Especially in a Swing program. One single listener you've forgot to explicitly remove can keep whole forms or even whole windows still loaded in memory. No, the garbage collector doesn't automatically free those.

I wrote a Swing application distributed by a major Internet company (trust me, you've heard of us). The application is well over a hundred thousand lines of code and has been downloaded millions of times.

Yes, you can leak memory in Java. Yes, failing to unregister a listener can lead to huge chunks of memory being retained. No, I can't see how it can take days to track such a problem down.

Java's -Xrunhprof option allows you to generate a complete map of the heap, including all references between objects. When faced with a problem like this, I took half an hour to write a program that would analyze the heap dump and tell me why a particular object was still held in memory.

Then I ran the program for a while, as memory steadily increased due to the leakage, and captured several heap dumps. A quick comparison between the various dumps pointed me towards some objects that seemed suspicious. A quick analysis, and I had an exact chain of pointers from the root set to the offending objects.

Total time to debug, including writing the heap analysis utility: under an hour.

If you have spent days debugging a problem like this, you need help. You make it sound as if the fact that you can accidentally retain an entire object graph is a problem, when it's actually a blessing in disguise. In C, you can easily leak four bytes at a time, and good luck finding it. In Java, leaks are A) much less common, and B) tend to involve many thousands of bytes, and the size of the leaks tends to makes it much easier to notice that there is a problem and subsequently track it down.

Even if, once in a great while, a Java memory leak is actually sticky enough to take days to track down, I still submit that it is light years better than the situation with C.

Swing is slow. It insists on painting every single pixel in the window personally. Basically if you have one form in a swing window, the whole window is one big canvas, on which the individual buttons/fields/toolbars/menus/etc are rendered in software, pixel by pixel. If that's your idea of a fun desktop, may I humbly suggest setting your X to use the VESA framebuffer instead of whatever accelerated driver you're using?

I humbly suggest that you take a look at the Java2D source and get a clue before you go around spouting nonsense like this. Java does indeed take advantage of hardware acceleration built into the video driver, and can even use OpenGL for its 2D rendering.

Re:How about still using C

[Anonymous Coward]

Yes, because IceWM and WMaker are written in a unicode-supported toolkit that trades a little bloat for i18n purposes..

Oh wait, they aren't! Metacity is the one that's written to be run anywhere in the world.

Honestly, if there was another GTK+ 2 window manager with all the Gnome hooks built into it to compare it to, then you'd have a platform to stand on.

Otherwise, you may as well be saying 'd00d WTF!!! why is Doom III so much slower than Wolfenstein 3D???? id is t3h sloppy coding!!11!'

Community standards...

[Chalybeous]

From the article:
The question then is: many strong proprietary companies such as Microsoft are moving full speed ahead on high-level managed language platforms. Can open source compete, or is it too unable to make hard decisions? Rephrased: is there some way we can find to move away from C/C++, without causing massive alienation and forking?

It's time to start the discussion. Rather than fooling around in the background, companies should get involved in a broad community process where we work out a common direction for the open source desktop codebase. [emphasis mine]

I'm not a coder, or technical in any form, but I can see how this makes sense. I'd love to adopt Linux but am still trying to mount /dev/clue ;-)
It's my guess that more people would want to adopt Linux distros, regardless of their flavour, if the open source OS community worked out those kind of specs as a group, so that different desktop versions of Linux were broadly the same.

(Yes, I know about the kernel, but matters that the article addresses seem to be important. IMHO, it could harm Linux in the future if different distros become too divergent, leading to a loss of interoperability or the requirement of, say, 14 different varieties of OpenOffice.org depending on your distro.)

Re:Community standards...

[maxwell demon]

I'd love to adopt Linux but am still trying to mount /dev/clue ;-)

Well, that's easy. First, download the latest 2.6 kernel (/dev/clue on 2.4 kernels is still experimental). Use a vanilla kernel, the clue patch is probably not working with the kernel your distro may offer. Then get the clue patch, apply it, recompile (configure the clue as module, building it directly into the kernel is not well tested), don't forget to make modules && make modules_install. Install your new kernel (if you use LILO, dont forget to call /sbin/lilo) and reboot. Type modprobe clue. Then look in the proc filesystem if clue has properly initialized. If not, you might have to create a /etc/clue.conf for your system (see the Clue-device-HOWTO for details, but beware that some instructions there are out of date, so check the CHANGES file of the current release). As soon as everything is running, there should be the clue device in you /dev. Now you need to activate the clue filesystem (installed together with the clue device, just do modprobe cluefs). Now you can just issue the corresponding mount command (the exact options can be found on www.cluefaq.org), and voila. To have your clue activated and mounted automatically, you should adapt your modules.conf and fstab.

You see, it's really not a problem, is it?

I have to say it:

[vasqzr]

Windows XP's Fisher Price interface is much faster than KDE/GNOME.

Flame me, call me a troll, but it is.

This is why I stick with one of the 'minimalist' window managers. Sure, I'm missing out on a lot of things, and Joe user probably needs KDE/GNOME and all their associated parts, but I don't.

On the extreme side there are still people who only use a terminal.

Please not .net..

[D-Cypell]

As a Java programmer, maybe im bias but i really hope that .net doesnt become the de-facto language on the linux client.

Feels like 10 years building a viable alternative to Microsoft and just as the goal is in sight... handing it over :o\

Re:Please not .net..

[krumms]

As a Java programmer, maybe im bias but i really hope that .net doesnt become the de-facto language on the linux client.

Feels like 10 years building a viable alternative to Microsoft and just as the goal is in sight... handing it over :o\

Bah. Programming languages are programming languages, irrespective of who came up with them. Developing software for Linux with .NET does NOT necessarily make Microsoft a winner. If it does, where's your reasoning?

Avoiding Windows Forms is your first step to ensuring Microsoft is not a winner. Look into wx.NET (however incomplete it may be, it looks promising).

Yes it's their tech, yes they're evil, no it's not the death knell for Linux.

Visual development environment

[nycsubway]

Having development environments like KDevelop and Glade are very important to the linux desktop. If these programs had more point-and-click UI design features, it would allow anyone with basic programming experience to put together a program. It's both good and bad to have this in linux though; it allows almost anyone to point and click an application together, and this will help corporations utilize a linux desktop. It also allows for the same problems that windows development has: lack of granularity in visual basic and really bad, unoriginal programs.

I think improving the visual part of KDevelop and Glade is very important. I also think leaving C/C++ and possibly Java as the languages in which the applications are written is preferable. C# is simply Java by Microsoft.

It would also be nice to have a development environment that allowed any language to drive the UI.

Re:Visual development environment

[nikster]

I completely agree with this.

The main, almost the only consideration for any desktop app is productivity.

Discussions about speed are childish. Java - the programming language - has always been fast, and if there are bindings to GUI libraries like GTK etc, the GUI will be fast, too.

Java/Swing is fast enough nowadays, too, but - having programmed many a Swing app - it's simply not a good framework. No one will be sad to see it go, especially if its replaced something better.

In order to achieve maximum productivity, one needs to have:

1) a decent programming language that follows the obvious principle that anything that can be automated should be automated. Java / C# (the Java clone) provide some of this nowadays, whereas c/c++ definitely don't.
2) a visual, well designed IDE. the productivity gains from features such as refactoring and auto-expansion / fixing etc are just huge. enormous.

side-note: For GUI design, i think the Linux community should just outright steal OS X interface builder. the genius of that application is that it does not just take care of the widgets, but that it also tells you where those widgets will look nice, following the HI guidelines. e.g. it supports the programmer in the design department as well as in programming. which is probably most needed in the linux community. It's there. Borrow from it.

And now, the rest of the story

[Anonymous Coward]

Your point is well taken, but it is rather surprising that you seem to have forgotten invention also drives economies. "They" want this waste/consumption of resources to force people to buy the Next Big Thing.

This isn't American and it isn't even Capitalist; it's Human, and probably vexed Pharoah as much as it vexes you or the lower income individual on the upgrade treadmill (MS/Software/_or_ Hardware.)

Regards,

A. C.

High level languages

[lofoforabr]

...as coders move towards high-level languages like java and C#... ... and soon Linux will not run anymore on low end systems, either requiring a super machine (like Windows) or running painfully slow.
I mean, we all like java, but have you ever seen a normal user application (with a GUI) written in java that is even a bit fast?

Re:High level languages

[iapetus]

That's largely down to the platform-independent UI code, though. Replace it with native widgets tied to Gnome and performance should be perfectly respectable.

Commercial Linux Apps

[commander salamander]

The battle for the Linux desktop has really been heating up lately, and with the planned release of several big commercial apps (Macromedia), it's getting even hotter.

As a bit of a GNOME fanboy, I hope GTK+ and friends can lure ISVs to use G-technologies when porting their programs. GNOME currently seems to have a large base of commercial support, although I've heard QT is being used in commercial development more. The integration of commercial apps with a desktop platform could be a make-or-break for said platform, especially as Linux market share grows and more Aunt Tillies and suits move off of Windows.

I've got a bone to pick with the FA though; it states that FOSS needs a new high level language and toolkit pronto if it's going to lure new developers. I haven't heard of the Adobes, Macromedias, or Intuits of the world scrambling to rewrite their apps in .NET; what makes HP think that GTKmm or QT isn't good enough? Don't believe the hype dude; the MS marketing machine has been blowing a lot of smoke up a lot of asses.

These languages are all outdated!

[seguso]

How sad: the only alternatives taken into account by Havoc are C#, Java and C++. If only the open source movement decided to embrace Mercury (logical paradigm) or Haskell/Clean (functional paradigm), and build .NET-like infrastructures for them, their productivity would be so increased that that they would surpass Microsoft before longhorn comes out. Instead, you go check and find out that the Mercury and Haskell projects are sponsored by Microsoft. Also ML and Prolog are being ported to .NET. Well, I suppose we (the OS movement) will get what we deserve for our lack of foresight.

Re:These languages are all outdated!

[fnc]

Why is this post considered funny? Functional programming languages are very expressive. Ocaml, for example, also allows OO, and have better performance than Java, acording "The Great Computer Language Shootout": http://www.bagley.org/~doug/shootout/craps.shtml

Language Evolution

[nonmaskable]

I've been professionally developing using C/C++ since 1985 on everything from device drivers to GUIs on every platform imaginable and I love C++.

BUT I've also been doing Java and C# the last three years, and they are a *huge* win in developer efficiency. Watching people working on my projects, I can see marginal developers immediately become much more productive (2x in some cases) - and I've been measuring this using several objective metrics (modules/week, LOC, PR #, time/PR).

I would rather see Java "win", but unless Sun blinks on the free/open issue _very_ quickly, I think C# will win by default.

C++ rules and will continue to do so

[NicenessHimself]

Something I posted to osnews:

Nice article Havoc!

One very key thing is that many many developers who aren't open-source fanatics still use OSS when it suites them - development tools mostly, especially mingw etc.

Now from my empirical sampling of programming buddies, I'd say these developers outnumber the OSS crowd 10 to 1. There just are so many of them, and they're going to be writing software primarily for Windows for years to come.

The key thing is supporting windows in order that we can get those developers to start writing portable code accidently rather than by design. I've already managed to get many of them to use wxwidgets but obviously C++, as Havoc pointed out, isn't best for every project.

Any OS framework has to be aimed primarily at infecting the windows world and building accidental dependance there these portable tools, so that windows apps can magically run on our alternative OSS desktop.

An OSS desktop gains momentum through supported apps making it easy for normal (windows) users to use, not through advocacy.

Never in Mono

[UltimaGuy]

My personal opinion is that Mono must never come into the code base. It is a project doomed from the start, and I don't want it polluting the code base.
Java is good, but I don't know if any actual advantage in speed or performance will be gained by using Java over C/C++
But this is a wake up call for the community to direct the course of the all important desktop environment, which if corectly done, will make Linux usable to the average Joe.

Re:Never in Mono

[IamTheRealMike]

My personal opinion is that Mono must never come into the code base. It is a project doomed from the start, and I don't want it polluting the code base. Java is good

Umm, given that the major difference between .NET and Java is that one is made by Microsoft and the other by Sun - why exactly is Mono doomed but Java good?

To be frank, I expect a good number of people will want to move up to languages like Java/C#, so the main question is which will "win".

Strategically, Java would be good. It's got a good GNU compiler, I'd guess most professional programmers are familiar with it to some extent, it has huge momentum (for instance it's taught in universities etc), it's very mature and so on. It's also not made by Microsoft - I see rabid opposition to .NET that I don't see for Java, though the reasoning behind those views is normally pretty weak. It's also got a great IDE in the form of Eclipse, that can be compiled and run as a native app.

Realistically, I think Mono/C# will win (the "language-neutral" aspects of .NET seem negligable given how intertwined most code is with the platform that underlies the language).

It's free software through and through, and it has a strong community backed by commercial support from Ximian. There's a lot of people interested in Mono, playing with it etc. Java on the Linux desktop just doesn't have that. Technical merits really aren't major concerns next to the matter of community.

The matter of whether C# or Java is better is entirely arguable at best. I find Java too anal for my tastes and too lacking in features - C# is simply Java with more features and some warts cleaned up so it gets +1 from me.

Of course, Mono can still be bummed by technical problems - while I've been very impressed by the runtime performance of GTK# apps, Mono still imposes some seriously hefty performance penalties. For instance just running "MonoDoc", a simple documentation browser, shows "mono" using 32MB RSS - that's second only to Firefox! Muine, a (very) simple music player, takes 27mb RSS. This is a not inconsiderable chunk of memory overhead. If I had less ram a few of these apps would push me into swapping heavily.

I was going to give some comparison numbers for some Java/GTK apps, but couldn't find any that I could easily compile. Scratch that idea then. I suspect they'd be lower simply through dropping the jitting overhead, but don't quote me on that.

To be frank I'd be happy to work with either, and suspect that's exactly what I'll end up having to do.

I didn't read all of it but...

[Cthefuture]

I find it interesting that C++ is not a consideration. He mentions "moving away from C/C++" but probably 99% of GNOME is C, not C++. I wouldn't be so quick to group C and C++ together like that. A lot of pain in Gtk/GNOME development is due to the pure C interfaces. I don't see many KDE developers complaining that they need "higher level" languages. They already use one: C++.

C++ offers everything Java and C# do but it also can do so much more. I mean Java and C# have only recently gotten generics. In C++ it is beyond simple to old your old C API's (although C# is pretty simple also).

Some people complain that C++ is too complex, but as Java and C# mature they are becoming just as complex. Why not make it easy get the best performance out of your hardware? Why not use a language that already has tons of power and flexibility?

As for cross platform compatibility... Both C and C++ are extremely portable. It's the API's that are not always so easy. However, this is no different than Java or C#. At some level you're using a C or C++ subsystem that needs to be ported to each platform. Why not just use it in the first place?

Re:I didn't read all of it but...

[Khelder]

The problem with C++ is that it has too much power and flexibility, much of which it inherited from C. For example, for a lot of programs, esp. desktop applications, the ability to do pointer arithmetic is a liability, not a benefit, because people will get it wrong.

C# and Java aren't much higher level than C++, but they are definite improvements because they decrease opportunities for bugs.

A lot of people talk about performance, but for many apps the difference between Java (and probably C#, but I don't know) and C++ is small enough to be irrelevant. And the gap is shrinking.

Re:I didn't read all of it but...

[Hard_Code]

Maybe because people don't want to keep constant track of memory allocation semantics. Maybe because developers don't want to have to learn a new platform library (e.g. Boost) every time they look at a new project. Maybe because the legions of programmers we expect to build tomorrow's applications will justifiable not give a damn about solving the same old problems we have been solving for decades, and instead want a consistent platform and set of APIs to get their work done safely and with minimal hassle.

"Our guys" are gonna have to fight their guys. And if "their guys" are armed with cheap CLR/VB.net/C# runtimes (meaning there will by about 10x more), we are going to freaking lose even though we have big and complicated C/C++ howitzers.

Re:I didn't read all of it but...

[IamTheRealMike]

I wouldn't be so quick to group C and C++ together like that. A lot of pain in Gtk/GNOME development is due to the pure C interfaces. I don't see many KDE developers complaining that they need "higher level" languages. They already use one: C++.

I don't think you could say that C++ is a high level language compared to C# or Java. Look at it this way - C++ usage on Windows is far, far higher than it's ever been in free software land yet pretty much all Windows developers I know who have tried .NET consider it a massive leap over what they were using before.

Now something will reach for the reply button to make a smart comment about MFC. Of course, MFC is not the only C++ API available - the ATL is even not that bad as they go. Even then, C++ is not as convenient as people would like.

For instance you still have manual memory management, and lack of thread support built into the language. You might not consider that a problem, but for instance the following code isn't guaranteed to be thread safe (and on some versions of MSVC++ isn't):

void foo() { static bar = new blah blah blah }

... because the C++ standard does not state that static constructors must be thread safe like that (it's susceptible to race conditions).

Using languages and runtimes like Java or C# helps with these issues as they were designed in from the start.

Re:I didn't read all of it but...

[PhrostyMcByte]

C++ offers everything Java and C# do but it also can do so much more. I mean Java and C# have only recently gotten generics. In C++ it is beyond simple to old your old C API's (although C# is pretty simple also).

It offers everything that they do? I've been coding C++ for a long time, where are my web service classes, my xml parsers? It's easier to use a single interface than have a ton of different libraries that can cause dependancy hell.

Some people complain that C++ is too complex, but as Java and C# mature they are becoming just as complex.

Java and C# are a lot easier than C++. A simple example:

// C++
list<string> strings;

for(list<string>::const_iterator iter=strings.begin(); iter!=strings.end(); iter++)
cout << *iter << endl;

// C#
StringCollection strings=new StringCollection();

foreach(string str in strings)
Console.WriteLine(str);

The C# one looks less intimidating. If a new developer sees both, I'm sure the only thing that might keep him from going to C# is the small speed tradeoff.

Why not make it easy get the best performance out of your hardware

JITed languages are only noticeably slower when GUI is involved. A JIT can also produce code specialized for your exact hardware- something a C/C++ compiler can't do.

As for cross platform compatibility... Both C and C++ are extremely portable. It's the API's that are not always so easy. However, this is no different than Java or C#. At some level you're using a C or C++ subsystem that needs to be ported to each platform. Why not just use it in the first place?

What is better: Porting only a single application, or porting every application? That is an especially strong question when business is involved. Creating portable C/C++ code can be challenging when you have to migrate between Linux, Windows, Mac, 32bit, 64bit, and some guys cell phone. Portable C/C++ will be bigger and look a lot uglier than equivalent Java/C#.

GNOME is GNU. Mono is hostile to GNU.

[bizcoach]

I find all this talk about GNOME possibly becoming based on Mono extremely unsettling. GNOME is part of the GNU project. The Mono project is not only not part of GNU, they're even openly hostile to the GNU efforts that they're competing with.

Re:GNOME is GNU. Mono is hostile to GNU.

[RdsArts]

It's also of shaky legal standing. Mono has no right to use the patents it does for the APIs other then a gentlemens' agreement that MS, IBM, Intel, and the other patent owners will not start charging for them.

This is important as, if they do charge, the Mono project would no longer be able to release a GPLed CLR or compiler. Even a 1$ license on the patent still means it would be GPL-incompatable.

Personally, I don't see why anyone should move to Mono. I'm perfectly happy coding in Python and Ruby until Parrot hits 1.0, when (in theory at least ;) ) I can start sharing that same code across the board.

Re:GNOME is GNU. Mono is hostile to GNU.

[lupus-slash]

We are not hostile at all to DotGNU.
We think we have a better implementation so we keep going forward with that. I don't think we're even competing since DotGNU seems to have different targets than us: for example the reason we built a JIT from the start is because we want Mono to be an efficient developer platform that enables people to move away from unsafe and difficult to use langauges: this of course would be not compatible with an interpreter design which is slow. By all means continue with the DotGNU implementation, improve it and try to build on its strengths, but don't just call us hostile only because we have a different implementation from yours.

XUL

[Anonymous Coward]

I'm not favoring XUL, but if I read ok, the article mention sthat XUL only has bindings to javascript. These are maybe the best implmented, but ti has also bindings (or being worked on) for perl, python and ruby.

Michel

Why Linux will never beat Microsoft or Apple

[Anonymous Coward]

Ok, first of all this is not a troll.

>"Do not integrate, do not unify, be free."

If I have Windows, I download a Windows binary and USE it (ok, I might have to choose the Windows version, but that's all).

If I have a Mac, I download a Mac binary and USE it (ok, I might have to choose the MacOS version, but that's all).

If I have a Linux or BSD distro, what do I need to do? Why are the end-users asked to know what their OS is? What the hell is a dependency? Why should I have to know how to compile (or even know what "compile" is)? Why can't something for Mandrake/GTK work on Slackware/Gnome?

While I agree that choices are good, this is what is slowing down Linux development (too many options to support) and is also what confuses the normal end-user (can't even *choose* what to download, I won't even get into installing the damn things).

Stop thinking as programmers and stop saying immature things like "the user should understand his PC, know about KDE/Gnome, X, insert_random_lib_name_and_version_here", because last time I checked, 99.9999% of car drivers out there only know how to fill their gas and windshield cleaner tanks. But they all still own and use their cars.

We have people who can barely use Windows or MacOSX, they would have no chance in hell with Linux.

If you take this as a flame or a troll, then you're indeed the proof that you don't have the slightess clue about what end-users want/need/understand.

Microsoft and Apple understand this YEARS ago (even if Microsoft still don't know how to make decent software at decent prices).

What happened...

[Bluesman]

...to gnome being a project that you could code for in any language?

I think this is going to bite them in the ass. Instead of putting all of their eggs in one basket, I think a better focus would be to improve all of the bindings to higher level languages. I'd REALLY like to be able to code for gnome in Lisp, but the bindings just aren't there.

Mono and KDE seem to have the right idea. They're making what looks like a first class development platform. With the limited time I have to code, if the development platform is working against me, I'm going to drop it. Gnome's development tools are awful. Kdevelop is much better, and Mono looks promising.

And wasn't this the whole point of basing Gnome on Corba in the first place, so that you could later incorporate objects from other languages? It seems to me like they haven't thought this through at all. Use of Corba seems to be extremely limited...probably because it's a pain in the ass to use and the project has done little to make it easier for developers.

If I could suggest a direction, I'd say concentrate on Gnome the development platform, instead of Gnome the Environment that Launches Mozilla and OpenOffice. The developers they'd attract will then take care of the rest. Solve the language interoperability problem, make sure bindings are up to date, and the apps will follow.

That's great if you ignore interoperability

[yoz]

The whole discussion is not actually about programming languages. It's about how you get people to agree on a coding platform that allows component A to talk to component B when the components are in different products.

Do not integrate, do not unify, be free.

Be free to have to specify each individual UI preference for every new app I use, you mean?

Be free to have to spend hours trying to get my new word processor to talk to my printer?

You're kind of missing the point re: integration, I think.

Re:Eeek...

[PhrostyMcByte]

Seriously, guys. Use what you know. Write in C++, write in Python. For GUI use GTK or QT or wxWindows, or just GNOME/KDE libs. If you write game use SDL or plib or ClanLib or anything else you will find. Do not check what is "trendy", just code.

I doubt they are using Java and Mono because they are "trendy". If anyone strays more from "trendy" things, it'll be developers. We use what is best for the job, be it C or C#.

If you have ever coded in one of these languages you would know it increases productivity beyond anything possible in C or C++. They are easier to code, easier to debug, easier to manage. Processors are getting fast enough to handle the small speed decrease of using a JIT. Languages like these are the future- C/C++ will easily be phased out as much as ASM was, as soon as the JITed languages become fast enough.

I am asking same question again - why Linux world need to copy everything from Windows world? Do not integrate, do not unify, be free.

Being so loosely integrated is one of the major limiting factors on linux advancing anywhere in the desktop world. Sure- having a ton of choices is great for development and customization, but for Joe User it is hell to have to learn so much crap to get things working. And if he asks his friend for help, chances are the friend will be using something entirely different and not be able to give much if any.

While Windows has it's faults, it is king of integration. It is also the driving force for a lot of new technologies. It sucks, but unless Linux apps want to be left behind, they have got to be more like Windows apps. Copying from them is OK in my book, so long as they don't copy MS's security practices :)

YES

[Hard_Code]

A million times YES.

Unix and C put a zillion little hammers into open source developers hands. This tool was FAST and UBIQUITOUS. Of course that was in the 60s and 70s where unarguably the software and computing landscape was wildly different. Now we have legions of happy go lucky open source developers running around solving every problem with their cute little hammer. They are painting (GUIs) with their hammer. They are reading and writing (XML) with their hammer. They are describing high level concepts with their hammer (ok, the analogy sort of breaks here). "The Hammer" has been a damn fine tool. It still is a damn fine tool for /certain problem and solution domains/. However it is not the best tool for everything (nothing is). One of the things it is probably NOT the best tool for is the vast wilderness of user-level applications, where the "value" is not in unrolling a loop with duff's device to gain 5% performance, but instead, /integrating/ components together to create something seamless for the end user. Sure you /can/ do this with C. But there is tremendous productivity gains in a high level language (and platform) for which you don't have to resolve all the same damn problems that we have been solving for decades: memory allocation, which libraries to use, consistent user interface, abstracted IO, etc. Of course my saying this doesn't make it so. But there is a big fucking wave of high level component-oriented platform coming - Java came over but for various reasons the crowd with their little hammers didn't like it (mostly because it was a rather large and foamy alternative). The CLR (.NET) alternative however is much more attractive because it can integrate so well with existing C and C++ code. And that allows you to stay 31337 and "keep it real". Good for you. Anyway, this wave is absolutely going to crush you if you don't get on it fast. It will no longer be funny when Microsoft and other proprietary vendors start reaping productivity rewards /despite/ their supposed inferior design methodology.

So don't listen to the din of hammer bearing legions. Open Source needs a damn consistent platform to compete. Pick something. Java, Mono, Parrot... There are several alternatives. (I'm a Java developer, but CLR presents obvious benefits for integration). I think Miguel has his head on right here.

So the goal really is to follow Windows?

[Junks Jerzey]

This is all so bizarre. Now, several years after Microsoft started promoting C#/.net as the way to write new Windows applications, Linux desktop developers are getting into a debate about whether to switch to C#. Why? What's the real win here? C# is a good language, but it is a far cry from Python, for example. Little, me-too babysteps is not the way to approach this. You need to be bold. Choose something with big wins and big advantages.

Note #1: I am not a Python zealot. I have some criticisms of that language, but I'll still admit that it's a huge win over C#. Huge. Period. For starters, just being able to interactively test can double your productivity.

Note #2: There will be the usual claims about performance and how you really should write everything in raw machine code, blah, blah, blah. The first rule of engineering is make it work. The second rule is make it reliable. Then you worry about making it fast. There are many options for speeding up Python, the simplest of which is simply profiling and restructuring the code. After that you have specializing compilers like Psyco, and as a distant third you have C extensions.

Re:So the goal really is to follow Windows?

[tal197]

C# is a good language, but it is a far cry from Python, for example. Little, me-too babysteps is not the way to approach this. You need to be bold. Choose something with big wins and big advantages.

From the blog, Havoc writes:

My view, which will doubtless get me flamed, is that these languages [python, etc ]aren't really the right thing for writing large desktop apps such as GNOME or OO.org

I'd be really interested to hear Havoc's reasons for this comment. I've written quite a lot of (smallish) desktop apps in Python (most of the ROX ones, in fact), and it seems ideal. I've also used Java quite a lot.

Python is in many ways similar to Java:

• Platform-independant bytecode.
• Fully OO.

But it has differences too:

• Python is much faster, both starting and running, and seems to use less resources.
• Python programs seem less prone to runtime errors (NullPointerException), and are generally more solid.
• Python is much quicker to write, easier to understand and easier to debug.

True, you loose static type checking. However:

• You can usually run your unit tests in Python in less time than it takes just to compile your Java. So you actually get more checks in less time!
• pychecker can spot many static errors.
• There is much less need for ugly work arounds from limitations of the type system, so less errors in the first place.

Java, still around eh?

[SmallFurryCreature]

Ever since I started to work in computers years back java been around as the great solution. First it would change the web. Remember all those applets? Gone. Then it would change web pages on the server. Well that is still hanging around but I see more perl/asp/php then java.

It was supposed to be cross platform. Well I use the azureus bittorrent client and it is indeed cross platform. It is also a bit of a resource hog.

And that really is my problem. While intrestting in many ways java has always left me with the impression that its insides are a mess or the people who code for it are on 2gig memory machines.

Lean and efficient are words I look for in my desktop. Java would not be the first language I would think off.

For years people been predicting the death of C and it hasn't happened yet. Could this be a clue? That perhaps all the pretenders are just that? Pretenders without any hope of ever coming close to the true king of programming languages?

If this guy really wants a mono or java desktop then let him fork gnome and code it his way. Prove that java/mono is the better way.

Surely that is the opensource way? He got an itch, let him scratch it.

As an aside, anyone know how much of suns java desktop is actually written in java?

For GOD'S SAKE

[0x0d0a]

Now, several years after Microsoft started promoting C#/.net as the way to write new Windows applications, Linux desktop developers are getting into a debate about whether to switch to C#.

AAAAAAAAAAAAAUUUUUUUUUUUUUUUUGGGGGGGGGGGGGGGGHHH HH HHHHHHHHH!

What is *wrong* with you people?

GNOME is not "switching" to C#. Linux is not "switching" to C#. KDE is not "switching" to C#. the FSF is not "switching" to C#. Miguel de Izca is likely to produce his next app in C#. Much like the other eight million languages on Linux (including Java, rep, perl, ruby, and God knows what), C# now has Linux support. It also happens to have GTK/GNOME bindings, like a whole hell of a lot of other existing languages out there. That's *it*. Jesus.

C# is a good language, but it is a far cry from Python, for example.

Great. Use Python. There are GNOME and GTK Python bindings. I suspect KDE has Python bindings. Code in Python to your heart's content. There are a handful of people that would like to use C#, and now they will use C#.

Re:Eeek...

[Ada_Rules]

I am asking same question again - why Linux world need to copy everything from Windows world? Do not integrate, do not unify, be free.

Thats an easy one to answer. We could cut to the chase and just copy everything directly from the Mac, but it is easier to let Windows copy it from the Mac first to work out the portability kinks... Then we can copy it and do it right the third time in Linux :)

Hear, Hear!

[ultrabot]

My personal opinion is that Mono must never come into the code base. It is a project doomed from the start, and I don't want it polluting the code base.

My sentiment exactly. If Gnome is going to start stockpiling stuff written in C#, it becomes something you can't rely on always being available (i.e. it's over immediately after MSFT thinks they've been entertained enough). The moment C# is starting to creep in is the time Gnome should be forked. Or at least the applications that are written in C#.

BTW, what does Sun think of C# in Gnome? They are contributing to the project, I would suppose that C# has no place in Java Desktop System ;-).

KDE is starting to look more and more appealing every day. This is a sad thing to watch - on the one hand Gnome has great initiatives and innovative people, on the other hand we have people who seem to have missed the cluetrain and can't foresee the impending demise of non-MSFT CLR.

I for one don't want out Linux desktop future to be built on Microsoft-owned land. Look at SCO, you can start litigation and fuel FUD even with less obvious IP claims than Microsoft has for Mono.

Re:Does the new release improve the X performance?

[jcupitt65]

A big part of the slowness of gtk2 is font rendering. Motif uses (or used?) XDrawString(), so text was done entirely by the server. On the downside, the quality of the text rendering was very poor.

gtk2 draws all text with pango. Pango is a high-quality unicode text renderer with an Xft2 backend. If you have an old X server, this can be pretty slow. If you have a recent XRender extension, it's almost as fast as the old XDrawString().

Owen Taylor did add an optimisation to render text more quickly for text which gtk knows is being drawn over a plain background, this helps old X servers a lot, provided you're not using a pixmap-based theme.

Re:One word... Smalltalk...

[cbiffle]

This guy's actually not as on-crack as a lot of folks may think. Squeak has no real opportunity to become a pleasant desktop environment or applications framework right now, since it looks and feels very different from everything else and can't (to my knowledge) run rootless.

HOWEVER - these are things that could be remedied.

The people who get twitchy at the prospect of a virtual machine should try Smalltalk on a 16mhz Palm. One of the main reasons for the slowness in Swing, for example, is that they're taking the MVC paradigm -- which was easy and lightweight in the Smalltalk paradigm -- and cruft it onto Java's statically-typed, heavier model.

I'm hoping that systems like Smalltalk and Self get more attention for desktop development in coming years, now that they're finally seeing a degree of revival for web apps.

+5 Insightful

[0x0d0a]

I haven't heard of the Adobes, Macromedias, or Intuits of the world scrambling to rewrite their apps in .NET; what makes HP think that GTKmm or QT isn't good enough? Don't believe the hype dude; the MS marketing machine has been blowing a lot of smoke up a lot of asses.

Yup.

Java/C# are snazzy for:

* Custom application development

* Lightweight distributed and networked systems.

* (Java at least) Cross-platform GUI apps.

* Vertical market software development.

C/C+ are snazzy for:

* Libraries

* Horizontal market applications

Until Microsoft goes out and rewrites MS SQL Server, MSIE, and Microsoft Word in C# (not going to happen, for good reasons), I don't see any reason why there should be any interest in doing the same with the core GNOME apps.

The same goes for Sun and Java. When Sun decides that Java would make a really great language for Open Office and successfully writes an efficient Java-based Office release, then it might be worthwhile considering Java for said use.

Until then, I'd suggest rnning out and actually *using* one of the desktop apps that people have written with Java. Hey...they're slow, RAM-hungry, and annoying to run on systems with different JVMs.

There have been a zillion less efficient languages proposed to replace C (and later C++) over the years. All of them failed to replace C/C++ as a general application programming language. Efficiency matters. The fact that Microsoft is pusshing a high level language and Sun is pushing a high level language (at other people -- notice failure of Wordperfect Java port for an example of why Java/C# are not good choices for horizontal market apps) does not mean that *this* year is the time to move to a high level language. I don't think anyone here wants GNOME or KDE to have a *bigger* RAM footprint, which Java would do.

Re:Eeek...

[Otter]

If you have ever coded in one of these languages you would know it increases productivity beyond anything possible in C or C++.

In practice, though, KDE development isn't as much in C++ as in a greatly enhanced C++/Qt/kdelibs environment. There's a huge difference between being able to draw on all that extra functionality and working in stock C++.

that's OSX

[rm -rf /etc/*]

OSX pretty much uses that paradigm, only with Objective-C (which was based in part on smalltalk) as the language. I can vouch for the fact that it makes a nice development model.

Two things to keep in mind

[Lysol]

I'm not convinced the patents thing is really valid. If Microsoft have patents on their class libs I think it massively unlikely Sun don't have patents on theirs.

Sun is also a hardware company and not strictly an OS/apps company. Plus, Sun is not as f-ed up as M$ when it comes to wanting to own every piece of technology they come in contact with. (Also, see last paragraph in this post.)

I think Havoc is off base with the XAML comments. XAML will only be usable with the arrival of Longhorn which is in, what, 2008 now? ...I certainly cannot see XAML taking over HTML anytime this century, there's simply too much investment in HTML..

Never underestimate an M$ technology. And I keep thinking of how many projects I've worked on where they code to IE and its standards complaint HTML that does not render in anything else. If you think that HTML is in the clear for now and the near future, you're mistaken. I think it's even a struggle now to keep people from just coding to IE. In the business world, where 99% of all the desktops run Windoze, any HTML project will probably only code to IE. For them, there's no reason not to.

I think Havoc is dead on the money with this one. XAML is a threat to HTML and it's needs to be watched and one-upped by the free/open community out there - he's bringing up the right arguments. If not, then there will be little reason for people to even use HTML at all. And like I said, if there's no reason for people to develop to an HTML standard, then there will be no reason to develop to HTML at all.

As for Mono; I also agree with Havoc here in that free alternative technologies should be developed outside M$ and not with it. Until M$ want's to be a regular member of the technology community and not the sole owner of everything, then they can't be trusted. And this is not just a rant but an opinion based on their historical behavior.
While, again, I think the Mono and dotGnu guys are doing a good job, I think their efforts are misplaced. Maybe at a minimum, provide a c# compiler like gcj. But all this Winforms and the like and doing Linux client apps in c# is going to be more of a problem than a solution.

As far as using Java to do app? Hey, at least Sun has an interest in seeing Linux succeed; read: Sun will, like IBM, make more money on Linux at some point than Solaris. M$, on the other hand with their current business model, sees NO benefits from Linux succeeding. So, again, I agree with Havoc.

Re:Python and large desktop apps

[tal197]

Well, Python is dynamically typed for one. Dynamic typing is great for scripting languages because the language gets out of your way and the rules are laxer, so you can work quicker. It's not so great for larger or more complex pieces of code where robustness is more important than having fewer rules.

Nasty type errors are really rare, though. Normally, you've either done something stupid and the code doesn't run at all (and you have to test everything at least once), or the types are right.

Of course, some languages can be really helpful with their type checking. Haskell often gives some insight into the nature of some code by giving it a more general type. But I find Java tells you nothing you didn't already know.

Python has a few other problems. It's (a) slow even with tools like Psyco.

I've looked at the output of some code from psyco and it looked just like C (provided you stick to C-compatible types, of course). Python tends to off-load critical loops into C libraries (map(), etc). Java tends to be much slower, perhaps because most of its standard library is interpreted?

Except

[SuperKendall]

As I see it, the main benefit of Mono would be the ability to run MS apps on Linux in the future.

Except that they are not poerting things like windows.forms, so just about nothing written for .Net under Windows will really run on Linux...

Mono makes a great tool for migrating Linux programmers over to Windows though.

Re:Python

[sfraggle]

Static type checking can help fix a few bugs, but as a coder, to be honest getting types confused isnt a mistake I feel I make very often. If you want solid code, the only real way to go about it is through testing, and unit tests work quite well. Unlike static checking they test all parts of the behaviour of the program. I've come to feel that the benefits of static typing arent worth it for the hassle it gives you. If you write good unit tests then type checking should be redundant anyway.

Read about Duck Typing on e2.

System.Windows.Forms and mono

[MenTaLguY]

It turns out most S.W.F client code relies too much on poking around "behind the scenes" way of pinvoke badness and the like that there needs to be a real Win32 implementation behind it.

(which is also why Microsoft is backing off of S.W.F themselves; the whole point of them going with .NET was so they could cast off the shackles of Win32 backwards-compatability, for good and bad reasons both)

That said, mono is in fact working on a S.W.F implementation in conjunction with Wine.

Don't Discount Firefox/Mozilla

[randall_burns]

IMHO one big thing that was missed here is the real potential behind technologies like Firefox/Mozilla and Javascript.

Those technologies offer a standards based means of doing UI's. The web isn't going away, and gradually browsers are getting closer to what we can do on the desktop. There are folks having some luck extending Javascript with Smalltalk features.
There already exist well supported compilers for Javascript-and those could be highly optimized with the right effort.

Javscript is _already_ well supported by Microsoft(they are supporting it as one of the major languages for the Windows Scripting Host). IMHO VBScript is just plain too buggy and ugly.

IMHO languages like Python/Perl/Ruby the best mainstream tools for Server Side Development(though Mozart-Oz has some interesting features). Client side? The browser appears to be the client of the future--and folks doing desktop stuff had best figure out how to deal with that.

A Mono developer's perpective

[lupus-slash]

Mono, Java or C++
I'll try to address some of the issues Havoc presented. Of course, I'm a Mono developer, so I'm biased, but hopefully people can see my arguments are more on the technical side than advocacy.

No rewrites please: this is a very important point: we can't just throw away the current code: we need incremental changes to not disrupt stability and compatibility. I'll just note that using Mono (and C#), interoperability with existing C code is much easier than with Java because of P/Invoke.

Calling managed code from C/C++: Havoc says it's hard, but Mono provides an easy to use interface to do that. Mono is designed to be embedded in existing applications, not just as a runtime for standalone completely managed programs. Also, it would be easy to create a shared library and header files to access managed methods seamlessly: they can be automatically generated thanks to the use of Reflection and the Mono embedding API.
I'm not sure a "simple native component system bridge" would solve the issues, mostly because simple systems are always found later to be incomplete, they get changed and become big, but with all the design warts needed to make a simple design work for not-so-simple constraints.
A minimal Mono system is currently about 2 MB on disk, but no effort yet has been put into reducing it (and I think it's entirely possible, we have been busy implementing features and leaving aside space optimizations). Of course, since the default build of the core assembly has lots of features, much of the reduction in size could be achieved by trimming features that other systems don't have:-). Even without trimming, most people will concour that 2 megabytes of disk space for a shared component is small enough in a desktop setting (and applications compiled to IL code are usually much smaller than comparable C apps anyway).

Community should decide: of course, I agree. Anything that is pushed down our throats by somebody else is not going to work for the free software and open source communities. The solution will need to be choosen because it actually solves issues the developers and the users see. Java had several years to try to attract developers from our community and it had some success in some niche areas (not for desktop applications, though). Mono has just started, but from the comments of the developers that actually used it to write new applications or port existing ones from C, it looks like we are on a good adoption path (even though we didn't release a 1.0 version yet, we are still working on debugging support and documentation is sparse).
Havoc fears the adoption of Mono or Java for the desktop would alienate people and cause forks. I don't think that will happen with Mono, because Gnome will continue to have a diversity of developers who'll prefer using the C libraries directly: Mono allows to keep and interoperate with existing code very easily and we want the migration to happen incrementally, so at first only end-user applications would be written in managed code, while the foundation would still be in C (at least, enough of the foundation to have people happyly writing their own apps in c or with the existing bindings). At that point, when a managed execution environment has proven itself to both developers and users (hopefully) we could start discussing about using it for the foundation, too, if that makes sense. I think Mono is positioned better here to allow this incremental shift of both development and espectations towards a managed runtime.

Problems with a .Net clone: Havoc claims that MS controls the platform because, even if the core is unencumbered, some assemblies are tied to MS technologies and there is non standards body or community momentum to build alternative solutions for a complete platform. Well, considering that until a couple of months ago there were 5 people developing mono, we have achieved a lot, not only in the implementation of the runtime, but also, thanks to the large commun

And what about other High level languages

[slashvar]

Each time somone talk about moving from C to some others languages, we heard about C++, C# or Java. All are kind of OOL, but whatabout typed functionnal programming languages ?

I'm using OCaml every day, for many things (in the CDuce interpreter, see www.CDuce.org, but also in other coding projects.) And it is fast (nearly as C, just take a look at this language benchmark), it is in some way safe (the famous : "Well typed programs cannot go wrong"), it has a good interaction mechanism with C librairies, programs can be compiled in native or in bytecode, OCaml native code compiler is giving very good result on many arch/OS ...

And, speaking about gnome, there's also a "wrapper" for GTK and GTK2 (called lablgtk and lablgtk2.)