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:

[Anonymous Coward]

[X] in a penguin suit

And the week after that Scott McNealy will do the same.

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!

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

[Z4rd0Z]

It's called moc, the meta object compiler.

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]

And both OOo and Moz are native-compiled. I don't get where you're going with that.

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

[benwb]

Both of which are written in C++.

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

[smittyoneeach]

I'd come at what I think is your point from a slightly different angle; when coding, one freedom you want is that of picking your level of abstraction.
If you want/require crawling around in the guts of the system, go for C.
If you just want to get something completed quickly, use a scripting language like Perl or Python with a fat library.
Once you code enough, it all starts to look similar, anyway.

Re:How about still using C

[torpor]

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

RUBBISH. There are plenty of desktop apps written in C which work just fine. Great, in fact.

So, how is it that if "C" is the wrong tool for the job, in fact the job has been accomplished so many countless hundreds of times already?

There is no single solid good reason for modern C programmers to still be running into malloc or thread problems. There are -excellent- solutions to these tired old problems already available, freely and widely on the C-programming market.

Anyone who thinks we need -another- language for programming is suffering from that cancerous "NIH" syndrome that afflicts too many technology people.

C is good for the job. It does the job. Why is it then not a good tool?

Obsessive-compulsive technology invention/re-invention is cancer.

Re:How about still using C

[IGnatius T Foobar]

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?

Why would anyone write applications that require Mozilla, when Mozilla is on fewer than 10 percent of the computers out there? That's a good way to alienate your user base.

On the other hand, how many web applications out there are "IE Only" ? We know all too well that there are a lot of webmasters and ISV's out there that follow the (flawed) logic of "Well, everyone has Windows and IE, so we'll just declare that this is a requirement." Some ISV's even require MS Office to be installed (again, because "everyone" already has it).

I think it's easy to imagine ISV's writing apps that require Longhorn and XAML a couple of years after they become available. And you can be sure that the code generated by Visual Studio will quietly encourage developers to roll out Microsoft-only apps, even if the developers don't realize they're doing it.

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.

I wish I could agree with you, but way too many Microsoft competitors have fallen into the "Microsoft couldn't possibly topple us, we just have too much market share" trap. Just ask WordPerfect, Netscape, or Novell. The Microsoft threat is real, and no one is immune from the onslaught. And now that they've bought their way into Washington DC, don't expect the government to slow them down either.

Re:How about still using C

[markbthomas]

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

Bullshit.

The best case scenario for a hotspot JVM is that it produces the same code as the C++ compiler. Since it has to recompile the bytecode and run the same code as the C++ version it's mathematically impossible for it to be faster. You're just buying into the propaganda where they compare fast JVMs with crappy C++ implementation compiled with optimization switched off.

For proof: in a CPU bound simulation written for a course at University, written in different languages, Java took over an hour to run the same simulation that in C took less than 40 seconds. Heck, even interpreted Haskell beat the pants off the Java versions.

Re:How about still using C

[AndyS]

There are some things you cannot know statically.

For example, if you have a virtual method which is never used as a virtual method. C++ will have to (to be statically safe) generate a virtual method call. Java can avoid that. Hell, Java could inline it. Java can avoid calls to synchronisation if it proves it's impossible. It can delay initialisation if nothing loaded makes use of it. As well as this, in general the JITTer has whole program knowledge whereas your average C++ program consists of a large number of independant files that are linked together.

Here's an interesting link for you:
http://www.arstechnica.com/reviews/1q00/dyna mo/dyn amo-1.html

(I hate HTML, so you'll have to copy and paste). That's a bit about a project at HP to do dynamic binary optimisation at runtime. This means they can achieve similar things to Java speedwise.

This CPU bound simulation sounds fascinating. I'd love to see it - Java might not always be quite as fast as C/C++, but to be so poor screams misuse of Java (or possibly a case where there is a large amount of boxing going on which you can avoid in C).

Source code would be nice if you could provide it, or the assignment itself if you can't.

Re:How about still using C

[Srin Tuar]

What's worse is that C forces you into a certain way of thinking. ...I don't write much software...

Well, I *do* write lots of software, and I find C/C++ to be the least limiting in terms of programming style, and the most flexible. For example, I dont normally worry much about memory, but when I need to I can.

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

[Anonymous Coward]

Me too. What make bytecode language better? If the syntax and features of C# and java are better, why not come up with a compiled language with all the NICE features C# and Java?

Or are you telling me that such and such features are not possible if the language is not done on bytecode?

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

[abigor]

Actually, the grandparent is correct. Just look to common industry practises for the evidence you need: no one writes desktop apps in C any more. C++ is the de facto standard, for many reasons. And it will be replaced by one (or several) of the managed code languages.

It all comes down to time: development time, and maintenance time. C is a costly language, and companies don't want to pay for it.

Re:How about still using C

[torpor]

wtf are you talking about? "nobody writes desktop apps in C"?!!

this is rubbish! C is -still- an industry-wide, adopted, in-use, tool. everywhere i go, i see C projects. more C than anything else, in fact!

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

[abigor]

"everywhere i go, i see C projects."

Yes, you're correct - I currently code in it for a living :)

Please settle down. My point was, it's not used for DESKTOP APPS. Period (well, except in the Linux world). Talk to Adobe, MS, IBM, etc. etc. They use C++. Adobe even uses Qt.

C is everywhere, for sure, and it's an excellent tool for certain jobs. My paycheques will attest to that. But it is not a universal tool, and there are way better ways of writing desktop stuff.

Take a peek at the KDE source code sometime, if you haven't already. It is really, really impressive stuff, probably the nicest, cleanest, most productive desktop programming environment I've seen. This is possible because of their hard committment to C++ and its many features.

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!'

Re:How about still using C

[Minna Kirai]

What make bytecode language better?

The fact that most commercial software companies are allergic to the idea of giving their customers legible source code.

If interpreted programs ran as fast as bytecode (they're almost as fast), there would still be resistance because publishers don't want to send out software that can be read.

Re:How about still using C

[Sax Maniac]

Sometimes it's better to have radio box to communicate a two-state switch, when the idea doesn't have an obvious opposite. Your example of "enable" does has an obvious opposite. Sometimes you need the extra word to describe what the heck that other state is.

And graphic designers are not always good UI designers. They can make usually something pretty, but in most cases they don't know how to design interacting with information.

Whenever you see a crappy website squeezed into a unresizable 600x480 Flash window, with hand-made scrollbars that don't repeat when you hold down or do page-up/page-down, you can thank some stupid graphic designer who does not understand usability. You just know they sat there thinking Hey, my cool new scrollbars are have this awesome theme with brushed metal, it's perfect! and never actually try to use the damn thing the read the damn text.

Your graphic designer will not be able to make logical groupings of related settings. They'll just put it where it's prettiest. All the while insisting it must be color X or font Y, white blatantly ignoring the user's settings. Never mind the user set it that way because they hate color X or can't even read font Y.

Graphic designers are good for some UI bits, but heaven's sake, let them draw the icons, not decide what the icons are.

Re:How about still using C

[nikster]

i will have to bite. and to make a case for Java / desktop.

to get that out of the way: yes, java memory use is ridiculous, and Sun needs to do something about it. 16M overhead for _any_ app is not going to cut it. memory use is on top of the list for requests for enhancement, so i expect significant movement there soon.

I'll say _you_, then, haven't spent days debugging a Java memory leak.

i have. yes, the garbage collector does not free you of all worries. and especially with the listener model you will run into gc issues quick. unless you use WeakReference and simply _never_ have that problem (WeakReferences are references that do not prevent garbage collection - it's a way to make Java behave like C, exept that you don't have to dealloc - the garbage collector takes care of that for you)
using WeakReference where appropriate, you can have the cake and eat it, too.
Sun should really emphasize this more in the docs. But i wonder what the alternative is? No garbage collector? Surely, that's worse.

4. It also has horrible startup time - i think that has to do with RAM usage. it takes a while to fill 25M... so if the RAM problem goes away, this one will go away, too.

5 Swing is slow... Not true. Swing (caveat: on windows!) is hardware accelerated. E.g. it takes advantage of the graphics card, just like native apps do. That it hand-paints everything is java mythology. It was true a long time ago. [caveat: i think it might still be true on non-windows platforms]

6. It also requires quite a bit of clue to use well....
Point taken.
Swing is a relatively weak framework, some call it over-engineered, i just think it was done by people with little experience in designing GUI frameworks. On the upside, it does have a lot of things built-in.

Bottom line is, Swing is a memory hog, and the architecture (or at least the tutorials) could be better, but it is fast, and it works very well.

Both memory usage and startup time are not inherent to Java/Swing, and i am convinced that both can be improved and will be improved in the near future (1.5).

Not to mention it's cross-platform :)
The latter means that all apps i write for my company will also run on Linux. Even though that is not a requirement for any of them (and i certainly would not get any resources allocated to do a port).

Re:How about still using C

[Brandybuck]

Speaking as someonw who tried to write a small window manager for KDE and succeeded, there's an awful lot of tiny window managers that support wm-spec. Funny thing is, even though this standard originated on the KDE side, Gnome has adopted it as its own (as with everything on freedesktop.org) to the point that the mailing list for the spec is under the gnome.org domain.

So it's unfathomable to me why Gnome can't limit itself to this standard. Just that simple thing would double the number of supporting window managers.

Does the new release improve the X performance?

[Colin Smith]

Gnome/gtk kind of sucks for X performance, even compared to the Motif libraries, which are no speed demons. It makes WAN/dialup/dsl use of X even more painful than it need be.

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.

Eeek...

[Jacek Poplawski]

Very high level languages, Java, C#/Mono, frameworks, newest GNOME, newest KDE, how many buzzwords can we use at once?

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 am asking same question again - why Linux world need to copy everything from Windows world? Do not integrate, do not unify, be free.

Re:Eeek...

[Boing]

Seriously, guys. Use what you know.

So when I write code for my company in Prolog, using some obscure graphics library that was written in Sumerian by thirteenth-century monks, I'm sure that there will be no conflicts in someone else extending my work. If I leave my company, I'm sure they won't have any trouble finding someone of comparable skill with experience with those technologies.

There's value to "use what you know", but if we can slowly get everyone familiar one or two core APIs/languages/frameworks, we'll have a lot less wasted brain real estate. Not saying they can't also know their own pet libraries, but I don't want to have to learn something new every time I have to read someone else's code.

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 :)

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 :)

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++.

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.

Re:I have to say it:

[EachLennyAPenny]

Just for fun i once ran the windows version of our C++ product using wine on linux. The window menus were more snappy than the one from the native X11 version. Why is that? Probably because wine uses DGA by default, bypassing X11 altogether.

Sorry, i just stopped believing in the "X11 isn't slow" slogans some years ago. Of course you can say "the toolkits use X11 ineffectively". Might be true. But that's like saying "Windows is secure, only the applications suck".

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.

Re:Please not .net..

[mrogers]

The language isn't the problem, it's the class libraries. There are no obstacles to writing a free C# or Java compiler (as long as you don't mind chasing a moving target without the source), but a language without libraries is just a toy. If all we needed was a managed language, the free software world has dozens to choose from. We also need (at least) the following libraries:

• A modern GUI toolkit
• File and network I/O
• Decent string handling
• Common data structures and algorithms, so we don't have to write 1,000 hash tables and 1,000 quicksorts
• An interface to existing C libraries

The language also needs to be able to attract a large number of developers (which rules out Lisp, Scheme, OCaml etc) and needs to be suitable for large collaborative projects (which arguably rules out Perl, Python and Ruby).

Java/GTK/gcj seems to be the only thing that meets the requirements and works now.

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

[saigon_from_europe]

I would really like to see an environment, no matter on what platform, where I could "point and click" and make an useful app that way.

It does not work that way. I programmed a lot in Tcl/Tk (no visual tools) and VB (where you can drew screens). As a result, I spend as much time in VB as I do in Tcl. Why? Because drawing widgets on screen is only 2% of your job. Double click on button in VB IDE (to get callback function editor), and there is real "fun". There is no help from drawing tools in that phase.

There is a lot of help, of course, from debuggers, code completion and similar stuff that comes with an IDE, but there is no real help from "visual" component. Anyway, if you want to dinamically change widgets, then even visual component does not help you in that mentioned 2%.

Even worse, most common used user apps in Windows are not written in VB, but in C++. Rapid tools like Java, C# (my typoo was C$ :) - actually langs + IDEs - are big help for proprietary database business apps, but no real help for widely accepted desktop apps.

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.

Re:Visual development environment

[zhenlin]

You can almost draw a simple text editor into existence on Mac OS X. The only code needed is the serialisation/deserialisation stuff. And even that is trivial.

How to do it.

But otherwise, the parent is right. Coding an non-trivial program is non-trivial; coding a GUI on top of that even more so.

The grandparent will have to wait until software component-oriented programming becomes popular. After all, why reinvent the (exact same) wheel over and over again if you can provide a stock software component that does the trick? It is like the electronic component revolution really -- you don't really have to worry about fabricating resistors or transistors or LEDs anymore -- just worry about how to put them together (so that it works). From there, it is just solder and dike.

Re:Visual development environment

[Screaming Lunatic]

The grandparent will have to wait until software component-oriented programming becomes popular.

Hello? COM/XP-COM objects, .NET assemblies, CORBA, Java packages. Component design is already popular. Just not so in the Linux world. That is part of what Havok Pennington is trying to address in his article.

Hey, wait a minute....

[Asprin]

Did you guys switch the polarity on the temporal transducer again? It's *LIKE* a re-post, but not.

Here ya' go, from yesterday.

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.

Re:High level languages

[sig97]

It's possible to obtain a *fast* java program by compiling directly to native machine code: http://gcc.gnu.org/java/

In addition to that, you could use a native GUI - like GTK - instead of Swing, which should speed things up considerably.

Re:High level languages

[furriskey]

> 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?

Yes, I don't know whether you could call it 'a normal user application' but I use the Eclipse IDE on win2k every day, and it is indistinguishable from a native program in terms of speed.
I have written programs using the Eclipse SWT GUI library (which wraps native widgets) and their interface also performs just as fast as native .exe apps.

All anyone needs...

[nickos]

...is a nice C++ GUI framework. Once you have one of these, be it gtkmm, qt or wxWidgets you're set.

People need to avoid the language hype - C# and Java are not the way to go. There's quite enough bloatware out there already, and running code inside virtual machines does not help.

Re:All anyone needs...

[Short Circuit]

I guess I better strip Perl out of my Debian machine, then. Er...that'd kill it.

Seriously, code inside VMs has advantages, such as security and portability.

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!

[ultrabot]

Instead, you go check and find out that the Mercury and Haskell projects are sponsored by Microsoft.

These ports are just attempts by Microsoft to sell .NET to universities. Some gullible professors will no doubt swallow the bait.

You seriously thought MSFT cares about languages other than C# and VB.NET?

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.

Re:Language Evolution

[ajs]

Java's not a platform-friendly language, and as such will generally suck for writing platform-friendly apps. If you want your desktop to be a Java desktop, then fine, but if you're writing for other platforms I recommend writing the core of your application in C or C++ and the rest in Perl, Python, Scheme or one of the other languages that admits to platform specifics.

This will, of course, get much easier when all of those high-level langauges can talk to eachother through Parrot as a back-end. You'll be able to take advantage of Ruby's OO model, but accomodate a third-party library from CPAN in Perl and tie it all to a UI layer that your last project wrote in Python with no ugly transitions through object brokers or external executables. UNIX-like systems have benefited from this homogeneity for decades because of the fact that tools all have a common vision of the system, but libraries have as yet not been able to standardize on ways to communicate across calling conventions, interpreted vs compiled modes of execution and data / object models. With Parrot in that gap I see a bright future for desktop development in high-level languages (as well as many other areas).

Yes, high level languages improve productivity, and yes Java is has that attribute, but you should select a language that is the right tool for the job, and when writing desktop apps, Java is the wrong tool for most jobs.

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#.

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

[mic256]

For instance you still have manual memory management

You can actually write C++ code without pointers, new and delete (provided the libraries you use don't require it somehow). You achieve this via STL. For example, to read the contents of a text file you can use sth similar (may contain bugs, did not try to compile) :

std::list<std::string> lines;
std::ifstream fin;
fin.open("f.txt");
std::string line;
while (getline(fin, line))
{
lines.insert(line);
}

you can even create trees without pointers - to achieve this simply use a map - every node has an int id (like a primary key) - this id is a key in the map - the value is the node. The node looks like this:

struct Node
{
int myId;
int parentId;
std::set<int> children;
data custom_data;
};

and you store the nodes in a map like this:

std::map<int, Node> aTree;

By using a set you can ensure, that you won't reference several times from one parent to the same child. Such trees are very easy to store in a database, as you can imagine.

One of the problems with not using pointers is achieving polymorphism, since you cannot store derived types in a container, but it turns out that virtual functions are not that often necessary (at least that's my case).

Another issue are iterators - because of speed(?) they are not boundary checked, so if you

std::advance(it, 100);

over a vector of 50 elements and then do

obj = *it;

you have an ooops !!! you can hovewer reference elements in sequence container like this:

v.at(100);

which would throw an exception in case of a 50 element vector v.

I wonder why nobody seems to

• Use C++ w/STL and avoid pointers - they are seldom needed
• Solve the problem with iterators (implement boundary checking - that can't be that difficult!).

I have been writing C++ / Java programs for several years and from my own experience, if you really use many of C++ features and avoid certain pitfalls, there is little more Java can offer - it doesn't even have the approx. 50 algorithms that STL has!

I have also done some benchmarks for myself - if you replace STL containers with plain arrays, you get a 6x speed gain. I don't believe Java with all its objects is similar in speed to a properly coded C app - maybe both are so fast it doesn't matter, but a C app should be about 10 times faster than a similar Java app with all objects in their places!!! ;)

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.

[Anonymous Coward]

GNOME has historically been ideologically aligned with GNU, but otherwise GNU doesn't play any role in GNOME's development. There is no gnu.org people working on it AFAIK, and they have no more say if Mono should be used than Joe Random developer. In fact, I'm Joe GNOME developer, got full CVS rights etc, and I certainly don't consider or even want myself associated with GNU in any way. For the record, I fully support Mono and will agree to its inclusion if it ever comes up to the vote.

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.

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

[bizcoach]

References? Who's precisely hostile, and how?

Here are two clear examples of hostility coming directly from Mono project leader Miguel de Icaza:

• This slashdot posting is one of several instances in which Miguel has publicly spread FUD against Portable.Net, attempting to cast a shadow of legal doubt on that project because it was started before the ECMA specs were published. According to our lawyer (Eben Moglen) what was done back then was perfectly legal, but even if that wouldn't be the case, it wouldn't matter because all the old code from back then has long been removed from the codebase anyway. These matters have been explained to Miguel, but in spite of that he has continued to spread this FUD. I think this is totally unacceptable. He also calls me and the other DotGNU coreteam members "kids", and makes other false statements that however are not so significant, hence I won't discuss them in detail.
• In response to my last proposal of collaboration, Miguel first said he's interested but when I shared some more thoughts, he responded by attacking me, calling my view "intellectual dishonesty" and "an exercise in deception". Of course Miguel is free to have his own opinions, and Mono is free to respond with "no" to proposals of collaboration, but he could have said "no" without attacking me like that.

Suppose that one day Microsoft starts making SCO-like attacks against DotGNU and Mono. Miguel is well aware that this is a possibility, and here he has stated that "if Microsoft in fact owns patents to the technology and they require the licensing of those, we are willing to license those for the sake of our users and customers." Since this statement was made in the context of discussing the threat from the possibility of patents that MS may not be willing to license royalty-free to everyone, such buying of licenses (while compatible with the X11-style licensing that Mono is using for the affected code) would change the status of the affected code from being Free Software to it being source-available, "paid Microsoft license required" non-free software. (Novell would buy a license that allows them to distribute the code, but which probably wouldn't give others the right to distribute derivative works, hence the code would stop being Free Software). However we in the DotGNU project would not accept Microsoft's demands for patent royalties, even if that means that until the patents in question have been invalidated by a US court of law we can distribute some code only from ftp servers outside the US. In view of these different planned reactions to any demands for licensing royalties it seems quite possible that Novell would agree to make Mono non-free (probably still free as in beer, but no longer free as in freedom), while we'd have to fight the legal battle against MS without their help. In view of this possibility, I consider remarks from Miguel like those quoted above which attack the DotGNU project's legal position to be extremely hostile.

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

Re:XUL

[zhenlin]

Also, the article seems to talk up hype about XAML, when XUL already does the same thing, and, more importantly, XUL is not vapourware.

Hmm. Similiarly, I don't think there was much interest in doing GNOME in Java until Microsoft released their Java feel-alike.

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).

Re:Why Linux will never beat Microsoft or Apple

[Srin Tuar]

>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).

Thats why your typical windows machine is a teeming hive of virii, spyware, adware, trojans, worms, and general cruft.

I also seem to have a much quicker time of finding/installing software for my distro using its preffered install/update tool (I only have to know the name of what I want!) Than any windows chump who has to jump through hoops on various websites to find what theyre looking for.

Your perception couldnt be any more backwards.

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.

Re:What happened...

[0x0d0a]

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

Err...it hasn't changed a bit. They added support for one more language, to the other ones out there. A lot of people that bitterly hate C# went nuts over it, and have been happily misquoting Miguel and thinking that the sky is falling.

If you don't like to use C#...hey, don't use it! Use C, or C++, or perl, or Java, or whatever language you like to code GNOME apps in. If you like Lisp languages, look at cl-gtk or clg.

Re:What happened...

[Bluesman]

>They added support for one more language, to the other ones out there.

But...they haven't. The only languages supported acceptably in the environment are C, C++, and Python. Maybe Perl. Maybe Scheme. I haven't checked lately, but I doubt it. With every API change they make, they break a ton of bindings, and it's tough to keep up. cl-gtk and clg are not up to date at all. Last time I checked, I couldn't compile either on FreeBSD, or run the HelloWorld example on Linux. This was two months ago.

Not to mention, having language bindings to GTK is a far cry from the original idea of having language interoperability through CORBA. With the current development tools, writing a stable "C and Perl" Gnome app is NOT easy. You basically have to extend the C program with run-time dynamic linking, which you can do without Gnome anyway.

Gnome as a development platform is a mess. If they had stuck to the original goal, "switching" to a new language would NOT even be an issue. It would be a matter of replacing components written in one language with another. If there were a proper interface, the language and run-time wouldn't matter.

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.

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?

Re:Java, still around eh?

[Hard_Code]

"Well that is still hanging around but I see more perl/asp/php then java."

Then you must not be paying attention. Servlets/JSP is HUGE, especially in "middleware", non-end-user-visible stuff (although there are plenty of major sites run on Servlets/JSP).

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#.

some postings here scare me

[BigGerman]

The reasons to use Java or .NET/C# are not because they are "trendy".
In either case, you get secure memory management, secure code signing / redistribution, remote objects, clean OOP, and many many things the absence of which causes so many problems/bugs/exploits in C/C++ world.
The question is not if, the question is when. Portions of Windows 2003 server are already in managed code. Longhorn will be 100%. What will Linux have at that time to counter it?
Continous flame wars about which set of bindings to use?
I was impressed by the thoughts expressed in the original article but some slashdotters plainly scare me. Linux has no chance on the desktop and will face the sunset on the server if the move to managed code does not happen.
Unix-style fragmentation won't kill Linux, but the thought fragmentation will.

XAML or ????

[wasabii]

I think he's correct on point with the XAML components. All you have to do is look at what some big companies do TODAY. ActiveX is used all over the corporate world. DHTML, IE specific JavaScript hacks. MS offers a "new way to make web pages", and when you use it, you get beautiful GUIs that are fully interactive and not browser based. Will these same people use them? HELL YEAH. And what will it do? It will totally knock a Linux/Unix desktop out of hte picture unless we implement these things, or at least implement our own answers to them.

MS is successful because it makes programs people want... regardless how much the design of those programs suck. :0 They get a job done, they get people a pay check. We need to compete on the same area.

XAML, depending on it's design, gives us a great place to leverage the Unix desktop. Consider (if) it is a generic UI describing XML document... whose to say weither it's rendered using Windows or GTK? At the same time, we would be promoting XAML.

So, we need to decide. Do we implement XAML, or do we make our own better version? I for one think we should at least take a look at XAML, if it sucks, we should make our own.

Why can't the w3c define the schema for such a document?

Re:XAML or ????

[zhenlin]

No need for either.

XUL already exists. XAML is a XUL feel-alike, like C# is to Java.

Pah. It always takes Microsoft to bring already-existing ideas into the spotlight.

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.

They most certainly are the way to go.

[Inoshiro]

Developer time is a constant. Over time, it still takes a set number of man hours to implement certain algorithms in a computer language (provided it's still in the same type of language [imperitive, functional, etc]).

Computer time is a flow. Every 18 months, hardware is roughly running twice as quickly.

Arguing that virtual machine based software is inefficient is like arguinig that MPEG layer 2 audio compression is supperior to MPEG layer 3 because it takes less CPU time to decode (or MP3 vs. OGG Vorbis). Maybe that mattered on a DX4 100 Mhz machine that couldn't decode an MP3 in realtime, but it certainly doesn't matter on my XP1700+ where the bottleneck is typically the O of the algorithm, not if it's interpretted (since VMs are as fast, now, as native code in the majority of cases).

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.

I'ld like to hear more about the Parrot...

[mysticgoat]

Quoting from Havoc's blog:

The traditional open source languages such as Perl, Python, and Ruby are significantly different from Java and C# (while Java and C# are very close, as the existence of IKVM implies). Parrot tries to get these languages running on a common runtime.

My view, which will doubtless get me flamed, is that these languages aren't really the right thing for writing large desktop apps such as GNOME or OO.org, though they are nice for a lot of other purposes.

Unfortunately, Havoc says nothing about why he thinks the Parrot will not be the right thing: he merely asserts his opinion. My impression is that Parrot and Perl 6 development are both moving forward satisfactorily and offer the underpinnings needed for major projects. And of course are right in the center of open source development.

So what am I missing? Are there inherent structural flaws in these languages or the Parrot? Or do others share my personal opinion that Perl, Python, and Ruby are mostly out of favor because they aren't 133t enough to separate programmers from lusers?

(I thought this thread was sort of cold but perhaps throwing this gasoline on it will create some heat and maybe even some light.)

Yes, it did

[ultrabot]

Yes, Linux made the Unix-oriented evnvironment available to more people, but piggybacking on a current and widely-used platform != revival.

Linux made Unix viable again. Unix on fast and cheap commodity hardware. Open, unified Unix, instead of mish mash of incompatible proprietary variants.

Without Linux (and BSD's, which might be where Linux is now if Linux didn't exist), Microsoft would have collected the jackpot already. And rightly so, probably - proprietary Unices sucks, and if it's something I can't run on my home machine, I don't want to deal with it.

Also, Linux has create a Future for Unix family. Without Linux, there would be no perception of future, and every sensible manager would jump out of the sinking ship ASAP. If Windows was the "obvious way of the future", everybody would be running it already.

Remember SWT

[Kingpin]

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

IBM's SWT is mature and has native UI bindings for an abundance of platforms, GTK2 included. That's a good place to start.

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

XAML: hierarchical storage of application data

[leandrod]

Rant:

Reading The Fine Article(R), I found it unsettling that people are seeing XAML as a potential substitute for both HTML and programming, and haven't yet articulated an answer, even if a derisive one.

If it was the first time I took a real look about XAML, from the first few paragraphs of MS' introduction to it, it is clear it amounts to storing UI and other application data (not organisational data used by the application, but data used to build the application itself) in XML, that is to say, hierarchically.

Just as every time one talks about XML and data in the same breath, or OO and data, this would be a throwback to 35 years ago before Codd had defined and published the Relational Model for database management.

This is specially worrying because we see many free software advocates, and most of new hackers, married to OO instead of fundamentally saner functional programming, even if it is a marriage of convenience just to get things like garbage collection that are included in current popular OO platforms; and it is specially disappointing given that Gnome now is giving thought to a saner if partial answer, namely Gnome Storage.

Marrying Gnome Storage with some functional programming over .Net or Java perhaps could by us some sanity back, but I feel it like a kludge unlikely to produce significantly better.

Going Java or .Net may be an intelligent way of trailing MS. But to really leapfrog it where now they have a huge advantage -- and that's not now the desktop as in an user environment or office automation apps or games, but custom software development for businesses with Oracle Developer, PowerBuilder, VB, Delphi and the like --, we have to present something fundamentally and conceptually better.

Something like a functional flavor of Alphora Dataphor integrated at the systems level since the installer could be the answer perhaps; while this would be a tall order for the near future, having it in sight for, say, twenty years in the future while implementing it step by step -- for example, first the D-compliant RDBMS interfaces, then an upwards- and downwards-scalable RDBMS engine with a quasi-SQL interface for backwards compatibility, then integration in the OS, then POSIX interoperability --, would give us the initiative and reduce MS to yet another platform direction change in the future, while we'd be able to keep our perfect POSIX backwards compatibility.

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.

Question on C# vs. Java

[SloppyElvis]

I have to ask (because I don't know), are their insurmountable technical barriers that would prevent compiling both Java and C# to the same bytecode?

The author calls for an open Java VM (which is a very good call IMHO), the natural assumption is that the runtime would execute Java bytecode, as it should. Is there a reason why C# couldn't be compiled to Java bytecode, and if so, then could extensions be added to accomodate non-Java languages?

I agree that Linux needs a solid front, but many of the issues raised speak to factions that want their technology to reign supreme on Linux. Why not have a runtime that runs all languages and let the coders decide which to use?

Aside, excellent insight into the purpose of XAML. You've got to realize that Internet Explorer Longhorn Edition is going to fully support all of the vector-based rendering APIs available to XAML's GDI/GDI+ predecessor. This means a full-featured GUI that can use a rich set of Microsoft's controls will be able to execute from inside the web browser using the same code you'd write for a local application. This is a huge deal, and whether it be XUL or something else entirely, Linux needs a equivalent alternative.

Modularisation, not integration

[jandersen]

The trend in GNOME/KDE has long been towards integrating SW rather than making independent apllications. To me this is a distinct weakness, and one that makes me consider abandoning those desktops altogether.

To me useability means flexibility, which implies configurability and openness. And openness in particular means proper, exhaustive documentation - low level as well as intermediate and high level documentation. Which is more or less non-existent in current versions of Linux desktops and applications.

Another prerequisite for flexibility is modularity - not Windows style modularity, but a style of coding where modules are predominantly simple and have simple interfaces. Compare the mish-mash that is Windows, with all it's knitted spaghetti of interconnectedness, to UNIX in the old days (and, thank God, still today). The elegant simplicity of filter programs or the way inetd works illustrate what I'm talking about. This is what we need - somthing that 'as simple as possible, but no simpler', to misappropriate a well known quote.

Why not embedded scripting?

[Lodragandraoidh]

Why not keep the window manager simple - and continue with C, and embed a scripting layer (like python) that allows you to extend it to create your applications? Python has an XML parser, and other things besides that you wouldn't need to implement inside of the window management engine.

This doesn't seem like brain surgery to me...but then again, I am perfectly happy running Zope and kicking out web apps - or throwing together a python/Tk app if I need a gui for something on my desktop. I know...I am in the minority. :(

HELP THE USER AND NOT THE PROGRAMER

[edsonmedina]

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.

Right.

So do it in java so you have less work.

But... the person who is going to use it will have a bad time.

I thought the program was supposed to HELP THE USER AND NOT THE PROGRAMER.

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?

Focus!

[AdamG]

I think before the OSS community can make a decision about -how- to code a competitive Linux desktop, it needs to decide -why- to code a competitive Linux desktop. The virtues of the system clearly come from their various kinds of openness and freedom, and we need to decide which are priorities. For example, do we want to produce:

-(free-ness)A free-as-in-beer system of comparable usability and functionality to commercial systems, that levels the playing field for developing countries, small businesses, or other entities without loads of cash to spend on commercial software;

-(Freedom)A free-as-in-speech system that empowers its users with useful technology, all of which they may apply to any non-exploitative purpose they like, without subjecting them to the whims and legal departments of the corporations who own it, and which therefore poses a significant threat to any single party which might try to restrict the way people can use their own computers and the software on it;

-(Openness)A system with an open architecture, where the kernel, file system, device drivers, window manager, desktop system, file browser, print manager, etc. are all decoupled and may be substituted or can even co-exist with any number of alternatives which might suit the user's needs more precisely;

-(Technical merit) A system that is guided by technical merit above any other purpose, that in its design and implementation represents the best effort of an entire meritocratic community beholden more to engineering principles than business strategies.

These are distinct but non-exclusive goals, each of which I see supported in the OSS community. I'm not convinced that we can effectively pursue all of these at once and hope to make significant achievements toward any of them on a competitive timeframe. Because of the forking problem, an uncoordinated step forward is also a step back. Perhaps one distribution will be a landmark of usability, but to achieve that goal its designers may have compromised on extensibility and designed it very specifically for particular implementations of assorted features, or may have used non-Free software. The accomplishments of this distro would liekly be useless to an ideal system which would meet all of the above goals- at the least, applying its improvements would require duplicated effort or extra work (opening up the architecture, developing and swapping in a Free alternative to the non-Free software).

Forking is always going to be an issue where there is complete freedom, and that's fine, but then the disparate goals of the system need to be prioritized, or else a significant strategy should be developed for how they'll be pursued concurrently.

I think Havoc's post states that C/C++ is proving an inadequate solution for pursuing (Technical merit) in a way that satisfies requirements for simultaneous (Openness) and high enough usability to make (free-ness) a significant advantage over commercial alternatives. The issue, though, is that the best alternatives compromise the goal of (Freedom).

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.

In this way

[SuperKendall]

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.

I hate these step things but it's the best way in this case to explain the progression:

1) Get lots of Linux programmers using C#
2) Linux programmers find Windows Forms is just easier to use at the moment
3) Linux programmers are now Windows Programmers, waiting for a good port of Windows Forms to Linux

And that's a path that doesn't need the patent scenario others have brought up to occur.

As the old saying goes, never buy bread from the devil no matter how tasty - for there is always something wrong with the wheat.

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.

No, it is because no one optimizes the code

[r6144]

When writing in C/C++ with approprite libraries (such as glib/Qt), the straightforward solution is usually reasonably fast at the machine code level (of course the fastest algorithm may still be non-straightforward, but this is the same for most imperative languages, and functional languages seems to be at a disadvantage here), in my experiance it is usually within 50% of the optimum speed, since most C programmers know that the machine will actually be doing. However, when coding in a high-level languages, since low-level details get glossed over, many programs as it is straightforwardly written is much much slower than the optimum way (just look at numerous Java tutorials that makes some perfectly innocent-looking code 10x faster after some optimization work --- and often the original code is better in style). Benchmarks often show that Java is as fast as C, but this is when properly optimized code. In many projects, there is constant development, and optimization is usually done as an afterthought when the program has become too slow for a significant percentage of the users, which means that most of the code doesn't get much of opportunity to be optimized. With C-alikes, the best-looking code produced by competent programmers (which is quite abound) can still perform reasonably without such optimization (assuming the algorithm is good), while good-looking Java/Python code may well be much too suboptimal in performance.

I still think that much UI code do need to be programmed in a performance-conscious way. Many users have got rather slow machines, and we constantly hear cries about "THIS IS SO SLOW!", almost as often as the number-cruching scientists. Of course, for in-house work/rapid prototyping work which are used only by a few people on dedicated machines, it may not be worth the effort, but for programs ready to be used by the millions, making it 10% faster can be as valuable as making LAPACK 10% faster.

Also, C isn't that bad. Of course you need to keep track of all these memory, and I don't deny that Java/Python do make me more comfortable, I have to say that typing "g_malloc()" etc. doesn't take much thought and allows my brain to relax a bit while my hands do the mechanical job (by contrast, it does drain brain cells when trying to write Java code that don't allocate three times as much memory as actually needed or write Ocaml code that are as functional as possible. Debugging mixed-language code is much harder --- and what about your favorite language binding don't work perfectly?). Debugging memory problems can be a bit hairy, but with modern tools it is much more tolerable, and anyway subtle algorithmic bugs can also be very hard to track down. As for threading problem, well if you want to do threading and don't want to go purely functional, you pretty much have to cope with it no matter what language you use.

Disclaimer: I think I know about more computer languages than most, and I do use high-level languages in many tasks and enjoy their benefits. I just think the anti-C crowd has gone a bit too far.

Re:Python and large desktop apps

[ultrabot]

Programming is hard. It's an unnatural thing for the human mind to do.

Not in Python - it's as natural as eating or sex :).

The more code can be automatically verified and checked, the better IMHO.

That's why there should be tests that excercise your code. Static typing helps catch some trivial bugs, but it only goes so far.

It's (a) slow even with tools like Psyco a

I think this is the reason it's not considered for OO.org scale programs. Desktop programs need to be very snappy, and Python takes a hit here. Less so because of the size or scalability. google for Chandler @ OSAF.

has a wierd non-C like syntax which is a bit offputting for people who are used to C++/Java/C# style languages.

The syntax is not "weird". Actually it's much more natural than in C family languages. And someone who can't get used to a new kind of syntax of such simplicity is probably quite stupid and should not be programming anyway (note that I'm emphatically *not* referring to you here, so ease up on the flamethrower :).

1337 and lusers

[ultrabot]

Or do others share my personal opinion that Perl, Python, and Ruby are mostly out of favor because they aren't 133t enough to separate programmers from lusers?

It appears that Java programmers are considered the VB monkeys of today, so I don't think that's it.

Quite a few only use the languages they are taught at school, and with which they think they can get a job (those that don't have one or are afraid of losing their current job, that is). Therefore they avoid anything "exotic".

OTOH, avoiding Perl makes perfect sense.

how about OpenStep?

[cygnus]

.../NextStep/Cocoa? it works from Apple. Objective-C already compiles in GCC, and it's less than trivial to use preexisting C/C++ code in Obj-C, making it an easy migration path.

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.

We're missing the point

[Larthallor]

We keep talking about the best programming language for the desktop, but I think that's a bit misleading. What's most important is not the language, per se. What's important is the platform.

Look at what Microsoft is doing. They've created a platform with the CLR/.Net infrastructure. They have language products like C# and VB.Net (and J#, but no one's THAT big of a sucker) that allow the application programmer to choose a language in which THEY will be productive and/or feel comfortable. But guess what? The same resources (GUI / Network / DB / Web / etc.) are available to both. In fact, a VB.Net programmer and a C# programmer can each work on the same project and have everything work right together. Wanna know why? Because the USEFUL tools Microsoft has already written (in fast, native code) are accessed via the CLR and both programmers' code get converted to the same IL. Microsoft has created a unified ABI that all of their managed products use, so that it doesn't matter what language is chosen, you get to use all the neat toys that come with the PLATFORM.

And that's what we need. We need a virtual platform that has the following attributes:

1. Comprehensive and useful framework. It should be tuned to the needs of MODERN applications, i.e. it includes a full-featured GUI, a useful Database interface API, Network APIs, etc. The key is to provide a comprehensive foundation that programmers can use to create their apps so that they only have to write the code that is unique to their problem, not recreate infrastructure useful to many apps.

2. Provide application portability. It should be accessible only to applications via an architecture-independent bytecode system, so desktop applications written for the virtual platform will run unaltered on all compliant IMPLEMENTATIONS of this virtual platform.

With a modern JIT-ing virtual machine along the lines the JVM and CLR, the vast majority of non-platform code will run "fast enough". Making the platform bytecode engine able to pre-compile speed sensitive sections of user bytecode to native code after delivery should satisfy most people's "need for speed".

3. Have native speed. Each implementation of the platform must be written in blazingly fast native code, including the GUI! If the goal is to provide an extremely productive framework that allows developers to make useful programs in less code, it follows that the resulting programs will spend most of their "time" inside of platform code. Thus, it's gotta be FAST!

Let's be honest: Sun made a strategic mistake with writing Swing in Java. While it made it easier to only have to implement a full-blown GUI once, it was so dog-slow that until recently no one really took it seriously and it has acquired a bad reputation. In hindsight, they would have been much better off at this point to have implemented Swing natively on all supported platforms, as they do the core elements of the JRE.

4. Available to all. It must become as ubiquitous as we can make it. That means all OS platforms and that it can't be just for free/Free apps. If you want to maximize productivity for desktop programmers, it needs to become the "de facto" standard. If you're going to learn to program, THIS is what you should be able to learn at college and at your local "Learn to be a Computer Geek" training programs. If possible, implementations should be Open Source. Regardless, the platform itself needs to be protected by a community process or other trustee system to prevent hijacking by commercial interests. The idea is to provide, as a community of individuals and businesses, the infrastructure for us all to be productive.

What everyone is wrestling with is that a platform with all of these features does not yet exist. There are many platform or platform-like frameworks out there that provide some or much of this, but none of them do it all. Worse yet, the two platforms that are the closest to achieving the technical

And no mention of D...

[mattgreen]

The D language offers a nice blend of higher-level languages like C# and Java while keeping more to the notions of C/C++ (you only pay for what you use, generally). It is not suffering from hazy legal issues and doesn't believe it is saving the world. It is still in development but it looks like it is hard to beat for the sweet spot of compability (call C APIs just fine), performance, and dependencies. I dislike their generics syntax, but I can live with it.

This seems like a natural fit for developing desktop applications that don't feel like they're running under a VM, yet they are still garbage collected.

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.

*sigh*

[bonch]

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.

When did Slashdot adopt this ridiculous all-or-nothing mindset that permeates all discussions now?

There is no "mono or java desktop." We simply have C# for Linux now.

WHAT IS THE BIG FUCKING DEAL? Sorry, but it had to be asked. All these people bitching about absolutely nothing. Another language added to Gnome in the future. Great, add it to the list (C, C++, Python, Java, etc.). Even if Gnome's insides were coded in C#, it wouldn't matter because the nature of .NET (and therefore Mono, I presume) is that you can use any language you want. Ever heard of VISUAL BASIC .NET? Okay, good.

Language bindings are a nice thing, aren't they?

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.)

Yes

[bonch]

You seriously thought MSFT cares about languages other than C# and VB.NET?

Microsoft does care about developers (Developers, developers, developers!). You can write managed C, C++, Visual Basic, and other code (even J++). With Mono, I expect even more .NET bindings. It's not all C#...though that's going to be the primarily-used language in time.

D as an example.

[mchnz]

Perhaps D (which isn't open source) shows how to ground a language more in the existing C world. The D language appears to offer the strengths of Java/C# rooted more firmly in a C-based environment.

http://www.digitalmars.com/d/

Cry Havoc!

[Brandybuck]

Why should I pay any attention to Havoc? What has he really done for the desktop other than posture? Isn't this the guy that read "Usability for Dummies" then declared himself the ultimate authority on usability? Isn't this the guy that actively worked to sabotage KDE on Redhat? Isn't this the guy that cries foul everytime KDE refuses to immediately implement a FD.o suggested proposal?

Okay, okay, that's a wee bit of hyperbole in the above paragraph. I apologize. But I really want to know what this guy's resume is beyond writing a window manager and playing politics at Redhat. What makes him an expert on what programming language I should use?

If there was any sanity...

[metamatic]

...in the open source community, we'd see more effort going into GNUstep.

Works with everything we have today? Check, there's compatibility with KDE and GNOME applications as well as Motif, with window style hints too.

High level language support? Check, Objective-C provides Smalltalk-like object orientation, and automatic memory management is available. There are also bindings to Ruby and Java. You can even build Java applications with native quality look and feel.

Compatible with what programmers know today? Yup, Objective-C is a slight superset of C, so almost any programmer can get to grips with it in a weekend. (Speaking as someone who did.)

Good class libraries? Yes, modeled on NeXT's excellent work, the same foundation used to build OS X. I've written Cocoa code, it's the most painless class library I've encountered. (Yes, I write Java too and have written C++.)

Cross platform? Yes again, programs are portable between GNUstep and Cocoa without too much work--see GNUmail for an example. Non-GUI programs even port to Windows without major effort, allegedly.

Good developer tools? Again, yes. Excellent developer tools on OS X. Doubtless the free tools on Linux could use some work, but that shouldn't be too hard. We can even build them using the OS X tools if necessary.

Pretty UI? Well, I think it looks OK. Not as nice as Aqua, but it's functional.

Mature? Well, the Objective-C compiler is GCC, Apple use it for their developer tools and push back improvements, the class library design has been refined over the course of 10+ years.

Think about it, people. We could unify the Linux and Apple developer communities. All work towards one common goal. Get 10%+ desktop market share for OpenStep/OS X/GNUstep in no time.

Hell, get GNUstep up to scratch and you'd probably see developers porting their commercial applications from OS X to Linux. Wouldn't you like to see products from Adobe, Macromedia, maybe even Apple available to run on your Linux desktop?

Think about all the problems that have been solved by NeXT and Apple. Application packaging? Solved, applications are bundles of files that you can just drag-drop wherever you want to keep them, and they work.

But no, the GNOME crowd will shun a tried and tested, open source, native code solution that works today and is backed by the single biggest vendor of UNIX desktops, in favor of cloning an untested patented bytecode-based Microsoft solution. Gates and co must be laughing.

But hey, go GNOME. Let's reinvent those wheels. Maybe your next set won't be square.

one root problem

[GunFodder]

It seems like the root problem for almost all of these issues is that the JVM is not integrated into the OS. A separate JVM is launched for every application. If Java was the standard desktop toolkit then wouldn't it be possible to integrate a JVM into the OS runtime? This would greatly reduce the startup overhead, the memory usage per app, and also allow a faster GUI toolkit implementation.

When it comes to memory usage welcome to the real world of tradeoffs. I would rather pay more cash for extra memory than waste time while my apps crash because they use languages that don't protect developers from their own mistakes.

System.Windows.Forms and DotGNU

[bizcoach]

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.

This isn't true. The implementation of DotGNU Portable.NET proves that it can be implemented directly on top of X, without any need for Wine or winelib.

Re:Gnome 3.0

[Trejkaz]

That would be a laugh, actually... if GNOME 3.0 did become 100% Mono code, and Microsoft chose that exact point to withdraw GNOME's right to use the APIs. You would be able to hear the KDE crowd laughing from half way across the planet.